Avitek Medical Record 1.0

1. アーキテクチャの概要

Avitek Medical Records サンプルアプリケーション (MedRec) は、次に示すように、クライアント、サーバ、データストアの 3 層が相互に独立した従来の 3 層アーキテクチャモデルに従って設計および実装されています。

プレゼンテーション層 : プレゼンテーション層は、あらゆるユーザ対話を担当する層です。クライアント層とも呼ばれます。
サービス層 : サービス層は、アプリケーションのビジネスロジックをカプセル化する中間層です。サービス層は、データストアなどの各種バックエンドシステムと対話しながら、異機種クライアントからのリクエストを処理します。この層はサーバ層とも呼ばれます。
エンタープライズ情報システム (EIS) 層 : エンタープライズ情報システム層は、従来のアプリケーションやデータベースのようにデータを提供したり格納したりするシステムを表します。EIS 層はデータストアとも呼ばれます。

以下の節では、各層について詳しく説明します。

1.1. アーキテクチャ概要図

以下は、MedRec のアプリケーションアーキテクチャの概要を表す Visio の図です。

MedRec アーキテクチャ概要図 (Microsoft Visio ビューアが必要です)。

以下の表に、MedRec を構成する各アプリケーションの概要図を示します。

表 1 サブシステム概要図 (Microsoft Visio ビューアが必要です)。

図	説明
Admin アーキテクチャ概要図	MedRec の管理者用アプリケーションのコンポーネント間の対話を表す。
Patient アーキテクチャ概要図	MedRec の患者用アプリケーションのコンポーネント間の対話を表す。
Physician アーキテクチャ概要図	MedRec の医師用アプリケーションのコンポーネント間の対話を表す。

2. プレゼンテーション層

プレゼンテーション層は、アプリケーションデータの収集と表示を担当し、MedRec アプリケーションの全体的なユーザエクスペリエンスを提供します。

2.1. 設計上の考慮事項

この節では、MedRec のプレゼンテーション層のアーキテクチャに関する設計上の考慮事項について概説します。プレゼンテーション層の設計に関するあらゆる判断の基準になる目標は次のとおりです。

スケーラブル

プレゼンテーション層について最も重要な設計上の考慮事項は、大量の同時リクエストを処理できるように十分な堅牢性を持たせることです。しかも、リソースの使用量を制御するために、プレゼンテーション層はサイズを小さくする必要があります。

拡張可能で保守が容易

プレゼンテーション層は、拡張性を備え、しかも保守の容易さを損なわないように設計する必要があります。そのためには、アプリケーションの特定のコンポーネントまたはコンポーネントセットに対する変更を、対象の機能に無関係なアプリケーションの他の部分を修正することなく行えるように、層をモジュール化する必要があります。さらに、新しいプレゼンテーション機能を作成する場合、プラグイン可能な方法で行う必要があります。そうすることで、基礎コンポーネントまたはピアコンポーネントを変更せずに新しいコンポーネントを簡単に組み込むことができます。

アプリケーションの相互依存性の最小化

プレゼンテーション層は、層と層の間の通信を必要最小限に抑えるように設計する必要があります。「拡張可能で保守が容易の目標と同様に、依存する層への変更が他の層にまで広範囲に影響しないように、層を分割することが非常に重要です。

2.2. MedRec プライマリクライアント - Web アプリケーション

プレゼンテーション層は複数の異なるクライアントで構成され、クライアントごとに固有のユーザと使用方法があります。プレゼンテーション層は、それらの要求に応じるための手段を MedRec アプリケーションに提供しなければなりません。

最初のバージョンの MedRec は、HTML ベースのクライアントに重点を置いています。ユーザはブラウザを使用して、プレゼンテーション層に対して HTTP リクエストを実行し、プレゼンテーション層からの応答を解釈します。この種類のクライアントは、一般に Web アプリケーションまたは webapp と呼ばれます。

MedRec は、2 つの異なる Web アプリケーションで構成されます。MedRec を管理する管理者用アプリケーションと、MedRec の患者ユーザ用アプリケーションです。

2.3. Web アプリケーションアーキテクチャの概要

アーキテクチャの設計要件を満たすため、Web アプリケーションフレームワークを使用して、プレゼンテーション層の共通機能をコンポーネントに論理的に統合します。これらのコンポーネントがアプリケーションの構築単位になります。

以下の節では、実証済みの Web アプリケーション設計の概念について説明し、Struts と呼ばれるフレームワークを紹介します。MedRec のすべての Web アプリケーションは、Struts に基づいて開発されています。

2.3.1. Model-View-Controller 設計パターン

プレゼンテーション層は、Model-View-Controller (MVC) Model 2 のパラダイムに従います。MVC パラダイムでは、アプリケーションのプレゼンテーション層を独立したコンポーネントに分割します。各コンポーネントは連携して動作し、対話型の Web 機能を提供します。MVC パラダイムのコンポーネントは次のとおりです。

· Model は、収集されてユーザに表示される情報を表します。情報はエンティティのデータ表現にカプセル化され、コンポーネントからコンポーネントへと渡されます。

· View は、ユーザにデータを表示する処理およびユーザからデータを取り込む処理を担当します。

· Controller は、受信するリクエストを処理し、プレゼンテーションのフローを調整します。

J2EE の実装では、JavaBean を Model、JavaServer Pages を View、および Java サーブレットを Controller として MVC を適用します。.JavaBean は、属性を持つ標準の Java オブジェクトであり、JavaServer Pages に取り込まれるデータまたは表示されるデータの論理的な集合を表します。JavaServer Pages には、HyperText Markup Language (HTML) と埋め込み Java コードが含まれます。HTML はページレイアウトを決定し、Java は JavaBean に含まれるデータを表示するために必要な処理を行います。

送信時、JSP は JavaBean を含むリクエストをサーブレットにディスパッチします。サーブレットは WebLogic Server 内部でリクエストを処理し、実行内容と呼び出すバックエンドサービスを決定します。その後、このサーブレットから次の JSP またはサーブレットに制御権が渡されます。

Model-View-Controller の詳細については、Sun の「Web-Tier Application Framework Design」を参照してください。

2.3.2. Struts フレームワーク

Struts は、Jakarta が開発したオープンソースの Web フレームワークです。Struts は Web アプリケーションを構築するための枠組みを提供します。この枠組みには、アプリケーション固有のロジックを拡張する多数のクラス、インタフェース、およびプロトコルが含まれます。Struts は、コンポーネントの定義と対話を XML ベースのコンフィグレーションファイルに抽象化することにより、Web アプリケーションの複雑さを隠します。

Struts では、Controller はアクションと呼ばれ、単一のアクションクラスから継承されます。このアクションクラスは、受信するリクエストを処理し、Struts のコンフィグレーションファイルでマップされている適切なカスタムアクションにリクエストをリダイレクトします。Struts では、ビューを標準の JavaServer Pages として定義し、モデルを Struts のフォーム Bean から継承する JavaBean として定義します。

詳細については、「Struts」を参照してください。

2.4. MedRec Web アプリケーションアーキテクチャ

MedRec の Web アプリケーションは、Struts フレームワークを使用して開発されています。MedRec の最初のバージョンである MedRec 1.0 は、Struts 1.0 に基づいて構築されます。以下の節では、 MedRec の Web アプリケーションフレームワークのアーキテクチャについて詳しく説明します。

MedRec Web アプリケーションは、標準の Web コンポーネントで構成されます。情報の収集と表示には JavaServer Pages (JSP) を使用します。Java サーブレットまたはアクションへの情報の送信には、標準の HTML フォームを使用します。Java サーブレットやアクションは、機能を次のような論理グループに分類します。

· ユーザの登録

· 医療記録の作成

· 医療記録の表示

フォームの送信時、JSP タグおよび Struts は、収集した情報を JavaBean に格納し、オブジェクトをリクエストにアタッチした後、リクエストをアクションに送信します。

処理する情報がアクションに渡されると、アクションは JavaBean に対して自己検証を要求します。JavaBean の属性に固有の検証がその JavaBean によって実行され、該当する場合はエラーフィールドに適切なエラーメッセージが格納されます。エラーが見つかった場合、アクションはエラーメッセージを表示する適切な JSP に JavaBean を渡します。

JavaBean が有効である場合、アクションはサービス層の対話、JavaBean の処理、およびプレゼンテーションのフローを処理します。

MedRec の Struts 実装の概略図については、「MedRec の Struts 実装図」を参照してください (Microsoft Visio ビューアが必要です)。

2.4.1. MedRec と Struts の相違点

MedRec は、Jakarta の Struts を用いて MVC モデル 2 を実装していますが、主に 2 つの点で従来のアプローチとは異なります。

· MedRec の Struts の実装では、Web 層からサービス層への通信がコントローラ内に維持されます。Model モデルコンポーネントは、データ構造体のカプセル化と表面レベルの検証のみを担当します。従来のアプローチでは、モデルはデータのカプセル化だけでなくビジネスサービスロジックも担当します。

· サービス層が返すカプセル化されたデータは、ユーザから提供または収集された情報を表すオブジェクトとして集約または再編成されます。これは、サービス層から取得したオブジェクトをプレゼンテーションビューに送る従来のアプローチとは異なります。

これらのアプローチの違いは、モデルコンポーネントをサービス層から切り離し、複雑な部分をコントローラコンポーネントに集中させるという目的に沿ったものです。このアプローチでは、データの流れではなくデータとデータの特性に Model の重点を置いています。MVC パラダイムでは本来コントローラが制御を担当するため、コントローラコンポーネントがレイヤ通信を担当するのが論理的です。

2.5. 定義済みコンポーネント

以下の節では、Web アプリケーションを構成する各コンポーネントが担当する処理について説明します。

2.5.1. JavaServer Pages

JavaServer Pages (JSP) は、HTML と埋め込み Java コードで構成されます。Java コードは、JavaBean からのデータ作成と JavaBean へのデータ表示のみを担当します。JSP 内部にビジネスロジックは実装されません。

JSP 開発の根底にある目的の 1 つは、ロジックコードとプレゼンテーションコードを効率的に分離することです。必要に応じて、Java コード (通常はタグライブラリ関数) と HTML コードを混在させて使用することで、アプリケーションデータを論理的に収集して表示するために必要な機能を提供します。

各 JSP は、ローカライズされたリソースコンポーネントからアプリケーションメッセージを取得します。詳細については、次の「ローカライゼーション」を参照してください。

JSP が直接アクセスされることはありません。JSP の入出力フローはすべてアクションにより制御されます。

詳細については、「JavaServer Pages」と『WebLogic JSP プログラマーズガイド』を参照してください。.

2.5.2. JavaBean

JavaBean またはプレゼンテーション Bean は、JSP から収集する属性または JSP 内に表示する属性のすべてをカプセル化する標準の Java オブジェクトです。これらのオブジェクトは、オブジェクト自身のデータ構造体の検証も担当します。

JavaBean は、Web アプリケーションに特有のものです。サービス層から取得したデータ構造体は値オブジェクトと呼ばれ、1 つまたは複数の JavaBean に変換されて JSP に表示されます。同様に、取り込んだユーザデータを含む JavaBean は、1 つまたは複数の値オブジェクトに変換されてサービス層に渡されます。これらの変換は JavaBean 内部で処理されます。

JSP でのプレゼンテーションを簡略化するため、JavaBean の属性の型はすべて java.lang.String です。値オブジェクトはこれとは異なり、属性はオブジェクトの型に固有です (たとえば、日付は java Date データ型)。これらの変換は JavaBean 内部で処理されます。

検証が必要な JavaBean には、データ値に無効な情報がないか確認するメソッドが含まれています。検証は、値の存在および予期されるデータパターンとの一致に限定されています。属性が無効と見なされた場合、ローカライズしたアプリケーションリソースによって適切なエラーメッセージが提供されます。エラーメッセージはエラーマッピングクラスである ActionErrors に格納されます。JavaBean 構造体に固有の検証ヘルパーメソッドは、その JavaBean のローカルメソッドです。一般的な検証ヘルパーメソッドが BaseBean で提供されています。

すべての Bean は、一般的な属性とヘルパー機能を持つ BaseBean オブジェクトを拡張します。BaseBean は、Struts によるコールバック検証の実行に使用される org.apache.struts.action.ActionForm を拡張します。

詳細については、「JavaBeans」および「JSP での JavaBean の使い方」を参照してください。.

2.5.3. タグライブラリ

タグライブラリは、JSP に共通するコア機能をカプセル化した Java クラスパッケージです。これらのクラスを JSP 内でタグとして使用します。

タグライブラリを使用すると、一般的な機能が提供されるだけでなく、Java コードと HTML コードを簡単に切り分けることができます。Java と HTML を明確に分離することで、JSP の保守が容易になります。

表 2 に、MedRec Web アプリケーションで使用するタグライブラリの簡単な説明を示します。

表 2 MedRec タグライブラリ

タグ名	説明
Bean	Bean および Bean のプロパティへのアクセスに便利なタグを含む Struts ライブラリ。スクリプト変数とページスコープ属性を通してページの残りの部分からアクセスできる新しい Bean の定義にも役立つ。
HTML	入力フォームの作成に使用するタグ、および HTML ベースのユーザインタフェースの作成に便利な一般的なタグを含む Struts ライブラリ。
Logic	出力テキストの条件付き生成の管理、出力テキストを反復生成するオブジェクトコレクションのループ処理、およびアプリケーションフローの管理に便利なタグを含む Struts ライブラリ。

詳細については、「Tag Libraries」、『Struts User Guide』および『WebLogic JSP プログラマーズガイド』を参照してください。

2.5.4. サーブレット

サーブレットまたはアクションは、Web アプリケーションの中心的な Controller です。Web サーバまたはプロキシレイヤからのすべてのリクエストは、アクションによって処理されます。アクションモジュールは、アプリケーションタスク別に分かれています。たとえば、すべてのクライアント登録機能は、Register という 1 つのアクションによって処理されます。アクションは主に、リクエストから取得した JavaBean に対して実行するコントローラロジックで構成されます。JavaBean に自己検証が要求され、その結果に基づいて、JavaBean はビジネスロジックを処理するために値オブジェクトとしてサービス層に渡されるか、クライアントによる再検証のためにプレゼンテーションビューに戻されます。

各アクションは、選択された子アクションの動作に応じて、BaseAction または BaseLookupDispatchAction を拡張します。BaseAction は通常の基本的なアクションに対して使用され、BaseLookupDispatchAction は、単一の JSP から行われた複数回のリクエスト送信の処理に使用されます。両方の基本コンポーネントは、セッション管理、ロケール管理、リソースのルックアップ、エラー処理などの一般的な機能と、インターセプトの役割をカプセル化します。

BaseAction は、org.apache.struts.action.Action を拡張します。BaseLookupDispatchAction は、org.apache.struts.actions.LookupDispatchAction を拡張します。Struts のアクションクラスは、リクエスト間のプロキシとして機能するとともに、拡張したアクションで実行するアプリケーションロジックとして機能します。拡張子が「*.do」の URL リクエストはすべて、各 Web アプリケーションの web.xml 記述子に定義されたアクションクラスにマップされます。アクションクラスによってリクエストが解析され、Struts のコンフィグレーションファイル struts-config.xml 内のマッピングに従ってその後の処理が決定されます。たとえば、「Login.do」へのリクエストは、ログイン機能が管理されている LoginAction にマップされます。アクションおよび Struts コンフィグレーションの詳細については、『Struts User Guide』を参照してください。

すべての JSP はアクションからサービスの提供を受けます。 JSP は直接アクセスされません。JSP の入出力フローはすべてアクションにより制御されます。

詳細については、「Java Servlets Technology」、『Struts User Guide』および『WebLogic HTTP サーブレットプログラマーズガイド』を参照してください。

2.5.5. ServiceLocator

ServiceLocator は、サービス層で使用可能なサービスをルックアップします。サービスには、EJB、JMS キュー、および JDBC 接続プールへのハンドルがあります。ServiceLocator は、サービスハンドルへのシングルポイントアクセスです。この抽象化によって、サービスルックアップの統一的なメカニズムが提供されます。ServiceLocator では、サービスをキャッシュすることによってパフォーマンスを向上できる場合があります。

詳細については、「Service Locator」を参照してください。

2.5.6. ユーティリティ

アクションおよび JavaBean は、ユーティリティクラスを使用して一般的な機能を実行します。

表 3 に、MedRec の Web アプリケーションで使用するユーティリティモジュールの簡単な説明を示します。

表 3 MedRec Web アプリケーションユーティリティ

名前	説明
BeanHelper	JavaBean の配列および java.util.Collections から値オブジェクト (またはその逆) への変換機能を提供する。
JNDINames	サービス名用に定数値を提供する。
MedRecWebAppUtilities	日付の書式設定や java.lang.String の検証と操作などのさまざまなプレゼンテーション機能を提供する。
MedRecMessageProperties	ローカライズされたプロパティファイル内の MedRec メッセージへのアクセスを提供する。

2.5.7. プロパティファイル

プロパティファイルは、名前と値の組み合わせを保存したシンプルテキストファイルです。名前に基づいて値を取得し、取得した値をユーザに表示するか、アプリケーション内のリソースのコンフィグレーションに使用します。

表 4 に、MedRec の Web アプリケーション内部で使用するプロパティファイルの簡単な説明を示します。

表 4 MedRec の Web アプリケーションのプロパティファイル

名前	説明
log4j.properties	Log4J ロギングメカニズムのコンフィグレーション。このプロパティファイルは、事前にロードされるサーブレット Log4Init 内で初期化される。
ApplicationResources.properties	プレゼンテーションのタイトル、テキストタグ、およびエラーメッセージを含む。ロケールごとに ApplicationResources プロパティファイルがある。

2.5.8. コンフィグレーションファイル

コンフィグレーションファイルは、アプリケーションのリソースの動作を定義するために使用する XML ベースのファイルです。

表 5 に、MedRec の Web アプリケーションで使用するコンフィグレーションファイルの簡単な説明を示します。

表 5 MedRec の Web アプリケーションユーティリティのコンフィグレーションファイル

名前	説明
web.xml	サーブレットデプロイメント記述子。Web アプリケーションのコンポーネントを定義する。これには、サーブレットデプロイメント、タグライブラリ、コンテキストパラメータ、URL マッピング、およびログインコンフィグレーションが含まれる。詳細については、「XML DTD for the Servlet 2.3」を参照。
weblogic.xml	WebLogic Web アプリケーションデプロイメント記述子。セキュリティ、HttpSession パラメータおよび JSP パラメータを定義する WebLogic サーバ固有のコンフィグレーション属性を含む。詳細については、「weblogic.xml」を参照。
struts-config.xml	Struts コンフィグレーションファイル。Web アプリケーションコンポーネントおよびコンポーネント間の関係を定義する。コンポーネントには、フォーム Bean、アクションサーブレット、およびディスパッチマッピングが含まれる。Struts コンフィグレーションファイルの詳細については、「Struts Configuration File」を参照。

2.6. ローカライゼーション

MedRec Web アプリケーションは、Struts ローカライゼーションフレームワークを使用して、インターナショナライズされたコンテンツを表示します。MedRec は、最初から英語と日本語用にローカライズされています。

2.6.1. リソースファイル

MedRec をローカライズする前に、Web アプリケーションのコンテンツをインターナショナライズします。この処理は、Web アプリケーションを英語で開発し、その後コンテンツを他の言語に翻訳することによって行います。Web アプリケーションのコンテンツは、アプリケーションのリソースファイル内で管理されます。サポートされている言語ごとにリソースファイルがあります。

2.6.2. 文字エンコーディング

Web アプリケーションの入出力フローはすべて、UTF-8 (Unicode Transformation Format、8 ビット形式) の文字エンコーディングを使用してエンコードされます。入力を UTF-8 としてエンコードするために、エンコーディングフィルタを使用して、クライアントからのすべてのリクエストおよびクライアントへのすべての応答がインターセプトされます。エンコーディングフィルタの役割は、文字エンコーディングを UTF-8 に設定することだけです。

2.6.3. ローカライズテキストの表示

リソースプロパティファイル (上記の「プロパティファイル」を参照) を使用することを Struts に指示するには、JSP に <html:html locale="true"> が含まれている必要があります。Struts で <bean:message> タグが検出された場合、キー値に基づいて、ユーザのロケールに応じたローカライズテキストが取得されます。ロケールが不明な場合、ブラウザのデフォルトのロケールが使用されます。

2.6.4. ロケールの変更

MedRec のスタートページにあるリンクを使用してロケールを変更できます。ロケールを変更すると、変更したロケールはユーザの HttpSession に格納されます。また、将来のロケールのルックアップに備えてクッキーにも書き込まれます。

Struts のローカライゼーションの詳細については、「Internationalized Messages」を参照してください。

2.7. 例外処理

Web アプリケーション内で発生した例外またはサービス層から取得した例外は、すべてクライアントの例外として捕捉され、再送出されます。クライアントの例外には、元の例外とエラー発生後にアクセスできるリンクが含まれます。また、発生した問題の詳細や問題からの回復手順などの追加情報が含まれる場合もあります。クライアントの例外、および Web アプリケーションフレームワークで発生するその他すべての例外は、Web アプリケーションの基本クラス内で捕捉され、Java エラークラスに変換されます。その後、このエラークラスは、エラーメッセージとリンクを統一された方法で表示する一般的なエラーアクションクラスに渡されます。

2.8. ロギング

MedRec Web アプリケーションでは、ロギングメカニズムとして Log4j を使用します。ロギングは、MedRec WLS ドメインディレクトリのルートにある log4j.properties ファイル内にコンフィグレーションされます。このファイルが、Web アプリケーションの起動時にロードされる Log4jInit クラスを介して読み込まれます。ロギングレベルは、log4j.properties 内のパッケージ名によって制御されます (「log4j.category.*」を参照してください)。各クラスで、log4j の Logger クラスのインスタンスを取得します。そこから、log4j のロギングメソッドを使用して特定の文字列をいつどのようにロギングするかを決定します。

2.8.1. ロギングレベルの変更

ロギングレベルを変更するには、log4j.properties を編集してパッケージカテゴリを FATAL、ERROR、WARN、INFO、またはDEBUG の中から必要なロギングレベルに設定します。その後 Web アプリケーションを再デプロイします。

2.8.2. デフォルトロギングレベル

デフォルトロギングレベルは次のとおりです。

· log4j.category.org.apache.struts=WARN

· log4j.category.org.apache.commons.logging=WARN

· log4j.category.com.bea.medrec=INFO

Log4j の詳細については、「Log4j Project」を参照してください。

3. サービス層

サービス層は、MedRec のビジネスロジックを処理するアプリケーションのエンジンです。プレゼンテーション層などのクライアントから、または Web サービスなどの外部クライアントからリクエストを受け取ります。ビジネス固有のロジックを適用し、エンタープライズ情報システム層と対話してデータを格納または受信することにより、リクエストを処理します。処理サイクルを完了するために呼び出し元のクライアントに情報を返すこともあります。また、非同期処理の消費リクエストを渡すことにより、他のアプリケーションと通信することもできます。

3.1. 設計上の考慮事項

以下の節では、MedRec のサービス層アーキテクチャの設計上の考慮事項について概説します。サービス層の設計に関するあらゆる判断の基準になる目標は次のとおりです。

スケーラブル

サービス層の設計に関する主な考慮事項は、MedRec が多数のクライアントからの大量の同時リクエストを処理できなければならないことです。しかも、リソースの使用量を制御するために、サービス層はサイズを小さくする必要があります。

適応性

サービス層は、Java クライアント、XML ベースのクライアント、専用ハンドヘルドデバイス、.NET クライアントなど、さまざまな種類のクライアントに対応します。MedRec は特徴は、さまざまなタイプのユーザや外部システムとのインタフェースすることです。ユーザやシステムごとに異なるニーズに対応する必要があります。

拡張性とモジュール化

サービス層は、各コンポーネントの役割や機能が明確に定義されるように設計します。たとえば、ビジネスロジックは、セッション Facade という排他的なコンポーネント内に配置します。同様に、EJB ホームや JMS トピックのようなサービスのルックアップは、共通のファクトリコンポーネントに配置します。このように設計すると、アプリケーションの保守が容易になり、アプリケーションの拡張に対応できます。

アプリケーションの相互依存性の最小化

サービス層は、層と層の間の通信を必要最小限に抑えるように設計します。依存する層への変更が他の層にまで広範囲に影響しないように、層を分割することが重要です。たとえば、データストレージのベンダを変更する場合に備えて、サービス層とエンタープライズ情報システム層の結合をゆるやかにします。

3.2. MedRec サービス層アーキテクチャ

MedRec のサービス層を主に構成しているのは、Web アプリケーション、Web サービス、ワークフローアプリケーション、および将来のクライアントアプリケーションからのリクエストを互いに連携して処理する Enterprise JavaBean (EJB) です。サービス層の中心は、MedRec のビジネスロジックの大部分をカプセル化するステートレスセッション EJB です。これらのステートレスセッション Bean は、セッション Facade と呼ばれ、受信するすべてのリクエストを処理します。セッション Facade は、処理を完了するために、コンテナ管理によるエンティティ EJB、その他のステートレスセッション EJB、Java Messaging Service、およびヘルパーモジュールと対話します。

MedRec のすべての EJB は EJB 2.0 仕様に基づいています。

3.3. 3.3. 定義済みコンポーネント

以下の節では、サービス層に関連する各コンポーネントの役割について説明します。

3.3.1. 値オブジェクト

値オブジェクト (VO) は、ある層から別の層に渡される関連するデータの集合をカプセル化します。値オブジェクトは、属性および各属性のゲッターメソッドとセッターメソッドを持つ標準の Java クラスです。通常、値オブジェクトは、エンティティ Bean に 1 対 1 でマップされます。

MedRec の内部で、エンティティ EJB はエンタープライズ情報システム層から情報を取得し、他のコンポーネントで消費される値オブジェクトに変換します。同様に、クライアント層に取り込まれたデータは、値オブジェクトに変換された後、サービス層に渡されて消費されます。これらの変換により、異なるクライアントがサーバ層と通信できるようになります。詳細については、以下の「エンティティ JavaBean」を参照してください。

すべての値オブジェクトは、一般的な属性およびメソッドが含まれるベース値オブジェクトクラスを拡張します。

詳細については、「Value Object」を参照してください。

3.3.2. セッション Façade

セッション Facade は、サービス層のビジネスロジックを含むステートレスセッション EJB です。ビジネスロジックには、リクエストに適用する医療記録に関連したビジネスルールやシステムルールのほか、システムにおけるコンポーネントの認識のようなアプリケーションロジックも含まれます。セッション Facade の第 1 の目的は、ビジネスロジックを適用するだけでなく、層の役割をさらに分割し、相互依存性を最小限に抑えることです。

セッション Facade は、リクエストを処理するために、値オブジェクト、エンティティ EJB、メッセージングサービスやその他の J2EE サービスといったサービス層の他のコンポーネントと対話します。複雑なトランザクションを簡略化するために、この集約された制御がセッション Facade 内部に保持されます。クライアントプログラムは、多数の規約を管理するのではなく、1 つのコンポーネント (セッション Façade) とインタフェースします。

通常、セッション Facade はユースケースと 1 対 1 でマップされます。MedRec では、システム内の個々のアクタに共通する機能をグループ化することにより、セッション Facade を派生させます。たとえば、Admin セッション Façade には、MedRec の管理業務に共通する機能 (患者登録リクエストの承認や受信する医療記録のアップロードなど) が含まれます。

詳細については、「Session Façade」および『WebLogic エンタープライズ JavaBeans プログラマーズガイド』を参照してください。

3.3.3. エンティティエンタープライズ JavaBean

サービス層では、コンテナ管理による永続性エンティティエンタープライズ JavaBean を使用して、エンタープライズ情報システム層に配置されたデータベースに格納されているデータを操作します。

エンティティ EJB のアクセスは、すべてセッション Facade によって制御されます。つまり、エンティティ EJB がアプリケーションデータを取得する場合は、セッション Facade を通して取得する必要があります。このような設計は、制御機能を集中させるという原則に従った設計です。

3.3.3.1. パフォーマンスに関する考慮事項

以下の節では、EJB 全体のパフォーマンス向上のために使用する EJB 機能について概説します。

3.3.3.1.1. ローカルエンティティ

MedRec のエンティティ EJB は、ローカル EJB インタフェースを実装し、JNDI ツリーをエクスポーズすることなくデプロイされます。ローカル EJB は参照によって呼び出されるため、負荷の高いリモート呼び出しを行う必要がありません。この機能により、サービス層は同じ Java 仮想マシン (JVM) 内のクライアントにエンティティ EJB の参照を返すことができます。

3.3.3.1.1.1. 値オブジェクトの使用例

MedRec の層の独立性および適応性に関する設計上の考慮事項を満たすために、ローカル EJB はある程度使用されるだけです。サービス層と他の層を組み合わせる必要はほとんどありませんが、サービス層は、呼び出し元が同じ JVM 内に存在するかどうかにかかわらず、呼び出し元クライアントに対応できる必要があります。

たとえば、同じ WebLogic インスタンス内にデプロイした Web アプリケーションは、ローカル EJB を使用できます。しかし、この WebLogic インスタンスの外部にある専用システム (ハンドヘルドデバイスなど) の場合、ローカル EJB は使用できません。さまざまな種類のクライアントに対応する必要があるため、共通の標準的なデータ配信メカニズムである値オブジェクトを使用します。すべてのエンティティ EJB には、EJB 自身の属性を値オブジェクトに変換する機能があります。

3.3.3.1.2. フィールドグループ

多くの場合、クライアントの関心の対象は、エンティティ EJB が提供するデータのサブセットです。必要な属性のみを返すためにフィールドグループが使用されます。フィールドグループはエンティティ EJB の記述子内で定義し、特定のファインダメソッドに関連付けます。このファインダメソッドが呼び出されると、コンテナは属性のサブセットのみを取得する必要があると解釈します。この機能は、呼び出し元クライアントと関連性のない関係がエンティティ EJB にある場合に、特に便利です。

3.3.3.2. WebLogic-EJB-QL

ファインダメソッドは EJB-QL を使用して定義しますが、EJB 2.0 に実装されていない一般的な SQL 機能を利用するには、WebLogicEJB-QL を使用します。具体的には、エンティティ EJB のコレクションで取得したデータを必要な属性の集合を基準にソートする場合、WebLogicEJB-QL ORDERBY を使用します。

詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズガイド』を参照してください。

3.3.4. メッセージ駆動型エンタープライズ JavaBean

サービス層では、メッセージ駆動型 EJB (MDB) を使用して、非同期の作業負荷を処理します。クライアントを関与させずに信頼性の高い処理を実現する必要がある場合は、MDB を使用すると大きな利点があります。

この節では、MedRec での MDB の使用方法について概説します。MedRec の機能は、信頼性の高い MDB の大量トランザクション処理能力を活用するように設計されています。

3.3.4.1. 電子メール

MedRec は、MDB を使用してすべての電子メール送信を処理します。メールメッセージは JMS キューに配置されます。JMS キューでは MDB が電子メールの配信を保証します。

3.3.4.2. XML アップロード

MDB は、受信する XML の医療記録をアップロードします。XML ドキュメントを変換するクライアント駆動型のプロセスを使用する代わりに、MedRec のプロセスは論理的な処理単位に分割されています。クライアントは、最初に XML ドキュメントを値オブジェクトに解析します。次に、MBD が要素の格納処理を行うキューにコンポーネントを渡します。

詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズガイド』を参照してください。

3.3.5. ServiceLocator

ServiceLocator は、サービス層で使用可能なサービスをルックアップします。サービスには、EJB、JMS キュー、および JDBC 接続プールへのハンドルがあります。ServiceLocator は、サービスハンドルへのシングルポイントアクセスです。この抽象化によって、サービスルックアップの統一的なプロトコルが提供されます。ServiceLocator では、サービスをキャッシュすることによってパフォーマンスを向上させることができる場合があります。

3.4. 例外処理

サービス層の中で発生するすべての例外は、ログに記録された後、呼び出し元のクライアントに送出されます。サービス層には、2 種類のビジネス例外があります。

3.4.1. MedRecException

MedRecException は、サービス層のビジネス例外です。この例外は、アプリケーションのデータまたは動作がアプリケーションロジックに組み込まれたビジネスルールに違反することが判明した場合に発生します。

3.4.2. DuplicateAccountException

この例外は、既存ユーザの登録時に発生します。

3.5. ロギング

サービス層は、ロギングメカニズムとして Log4j を使用します。サービス層は、Web アプリケーションから Log4j コンフィグレーションを継承します。詳細については、第 2.8 節を参照してください。

4. エンタープライズ情報システム層

MedRec エンタープライズ情報システム層は、リレーショナルデータベース管理システムで構成されます。この層はレガシーシステムまたは Web サービスとも呼ばれます。

4.1. PointBase

MedRec アプリケーションデータは PointBase で管理されます。PointBase は、Java で記述された、プラットフォームに依存しない組み込みリレーショナルデータベースです。PointBase は WebLogic Server に付属しています。

PointBase の詳細については、「PointBase」を参照してください。

4.1.1. MedRec スキーマ

WebLogic Server には、DEMO というサンプルの PointBase データベースが付属しています。MedRec スキーマは、このデータベース内にあります。

5. Web サービス

医療業界の特質上、MedRec には、複数の医療機関とのインタフェースを提供し、さまざまな種類のクライアントに正確な情報を適時配信する機能が必要です。この複雑な要件を満たすため、MedRec の機能をエクスポーズする標準のメカニズムとして Web サービスを使用します。

Web サービスは、Web ベースのアプリケーションであり、XML、HTTP、および SOAP などのオープンスタンダードを使用して他の Web ベースのアプリケーションと動的に対話します。原則として、サービス層のコンポーネントはインターネットを通して一般にエクスポーズされます。パブリッシュされた URL によって、サービスの説明と通信に関する情報 (入出力など) が定義されます。

詳細については、「WebLogic Server: Web サービス」を参照してください。

5.1. MedRec の実装

MedRec ユーザのニーズを満たすために、Web サービスの代理を使用して特定の MedRec 機能をエクスポーズします。

5.1.1. 5.1.1. MedRec Web サービスの代理

MedRec Web サービスの代理は、EJB です。この代理 EJB は、サービス層内部の詳細からの、あるレベルの抽象化を提供します。この分離によって、MedRec の設計目標の 1 つであるモジュール化をサポートし、サービスに対する変更が呼び出し元コンポーネントに与える影響を最小限に抑えます。さらに、Web サービスの代理は、セキュリティ、トランザクション、およびコンテナが提供する利点などの EJB 機能を利用できます。

5.1.2. 5.1.2. MedRec Web サービスの代理のアセンブル

MedRec Web サービスの代理 EJB は、Web サービスにアセンブルされます。MedRec は、WebLogic Ant タスクを使用してこれを行います。

詳細については、「Ant タスクを使用した WebLogic Web サービスのアセンブル」を参照してください。

5.1.2.1. autotype

Web サービスをアセンブルするには、最初に autotype Ant タスクで非組み込みデータ型を対応する XML スキーマデータ型に変換し、Web サービスラインタイムがクライアントに構造体を通知できるようにします。

5.1.2.2. source2wsdl

次に、source2wsdl Ant タスクによって Web サービスコンフィグレーションファイルである web-services.xml を生成します。

5.2. Web サービスとしてエクスポーズした MedRec の機能

サービス層の機能は、MedRec ユーザのニーズに基づいて代理 EJB にエクスポーズできます。

5.2.1. 医師

MedRec の患者情報は、医師のオフィスなど、医療機関のアプリケーションから使用できるようにする必要があります。MedRec では、医師アプリケーションから患者の検索、患者のプロファイルや医療履歴の取得、診断や処方箋などの通院情報の記録を実行できます。

5.2.2. 企業の人材登録

MedRec は、新しい患者を登録する機能もエクスポーズしています。この機能は、企業の人事部が従業員に追加の福利厚生を提供する場合に役立ちます。

6. セキュリティ

MedRec のセキュリティは、WebLogic Server のセキュリティフレームワークを利用しています。MedRec Administrator の管理には、WebLogic Server のデフォルトセキュリティコンフィグレーションを使用します。MedRec Patient の管理には、カスタム認証プロバイダと WebLogic Server のデフォルトセキュリティコンフィグレーションを組み合わせて使用します。MedRec の管理者用および患者用 Web サイトは、両方とも URL パターンマッチングによって制約されます。

詳細については、「WebLogic セキュリティ」を参照してください。

6.1. MedRec のユーザ

MedRec が管理するユーザは、Administrator と Patient の 2 種類です。以下の節では、それぞれのユーザについて概説します。以下の節では、各ユーザの概要を説明します。

6.1.1. Administrator

MedRec Administrator ユーザは、WebLogic のデフォルトセキュリティコンフィグレーションによって保持および管理されます。ユーザ名、グループ、およびロールは、WebLogic の組み込み LDAP サーバ内に格納され、WebLogic Server Administration Console で表示、作成、更新、および削除されます。

6.1.2. Patient

MedRec Patient ユーザは、リレーショナルデータベース管理システム内の一連のテーブルで管理されます。患者のログイン資格、プロファイル、およびグループの関連付けがリレーショナルデータベースに格納されます。患者のロールおよび患者のグループの関連付けは、WebLogic Server の組み込み LDAP サーバに格納されます。2 つのデータセットは、RDBMS および LDAP の両方に格納されている共通グループ名によってリンクされます。

6.2. MedRec のグループ

MedRec では、MedRecAdmins と MedRecPatients という 2 種類のグループを使用します。以下の節では、それぞれのグループについて概説します。

6.2.1. MedRecAdmins

MedRec Administrator ユーザは MedRecAdmins グループに割り当てられます。MedRecAdmins グループは、WebLogic Server の組み込み LDAP サーバ内に存在し、WebLogic のデフォルトセキュリティコンフィグレーションに含まれるユーザに割り当てられます。

6.2.2. MedRecPatients

MedRec Patiesnt ユーザは MedRecPatients グループに割り当てられます。患者グループの関連付けはリレーショナルデータベースで管理されます。MedRecPatients グループは WebLogic Server の組み込み LDAP サーバにも存在します。MedRecPatients グループは、RDBMS にある MedRec 患者情報と MedRec の WebLogic Server セキュリティコンフィグレーションを関連付けます。

6.3. MedRec のロール

MedRec では、MedRecAdmin と MedRecPatient の 2 種類のロールを使用します。以下の節では、それぞれのロールについて概説します。

6.3.1. MedRecAdmin

MedRec Administration のリソースは MedRecAdmin ロールによって制約されます。このロールは MedRecAdmins グループのみに割り当てられます。MedRecAdmins グループに関連付けられているユーザには、MedRecAdmin ロールが割り当てられます。

6.3.2. MedRecPatient

MedRec Patient のリソースは、MedRecPatient ロールによって制約されます。このロールは MedRecPatients グループのみに割り当てられます。 MedRecPatients グループに関連付けられているユーザには、MedRecAdmin ロールが割り当てられます。

6.4. セキュリティレルム

以下の節では、MedRec のセキュリティコンフィグレーションについて概説します。

6.4.1. 認証

認証とは、クライアント、ユーザまたはシステムプロセスの身元を証明または確認するプロセスのことです。WebLogic Security フレームワークでは、Java Authentication and Authorization Service (JAAS) クラスを用いて、信頼性とセキュリティを確保しつつクライアントに対する認証を行います。

このフレームワークの中心は認証プロバイダです。認証プロバイダは、ID 情報を記憶したり、転送したり、その情報が必要な場合にシステムのさまざまなコンポーネントで利用できるようにしたりするメカニズムです。MedRec では、WebLogic 認証プロバイダとカスタム MedRec サンプル認証プロバイダという 2 種類の認証プロバイダを使用します。

J2EE および WebLogic 認証の詳細については、それぞれ「JAAS」および「WebLogic 認証」を参照してください。

6.4.1.1. WebLogic 認証プロバイダ

WebLogic 認証プロバイダを使用して、MedRec Administrators、Administrators のグループ、およびグループメンバシップを管理できます。WebLogic Administration Console は、WebLogic Security フレームワークを通じてプロバイダ (デフォルト認証プロバイダ) を呼び出し、組み込み LDAP サーバに格納されているユーザやグループを作成、表示、更新、および削除します。このフレームワークは、クライアントの認証リクエストが送信された場合にも、このプロバイダを呼び出します。デフォルトでは、WebLogic 認証プロバイダはそのまま使えるようにコンフィグレーションされます。

デフォルト認証プロバイダの詳細については、「WebLogic Security の管理」および「WebLogic Security プロバイダ」を参照してください。

6.4.1.2. MedRec サンプル認証プロバイダ

MedRec サンプル認証プロバイダは、セキュリティサービスプロバイダインタフェースを実装するカスタムプロバイダです。この標準のインタフェースによって、カスタムプロバイダを WebLogic Security フレームワークと統合できます。MedRec サンプル認証プロバイダは、管理対象 Bean (MBean)、LoginModule、およびデータベースの代理で構成されます。クライアント認証リクエストが送信されると、これらのコンポーネントがセキュリティフレームワークと連携して動作し、ログイン資格およびグループメンバシップを取得、検証、および格納します。

MedRec サンプル認証プロバイダは、Patient ユーザおよび Patient ユーザのグループメンバシップを取得し、リレーショナルデータベースに格納します。Patient ユーザ情報を LDAP の外部に格納することにより、アプリケーションでデータベース管理システムの柔軟性と能力を利用できます。Patient のリレーショナルデータと Patient の LDAP データ (ロール) 間の関係を維持することにより、MedRec は WebLogic のセキュリティフレームワークを利用できます。

カスタムプロバイダの詳細については、「WebLogic Security サービスの開発」を参照してください。

6.4.1.3. 認証プロバイダのコンフィグレーション

認証プロバイダは、WebLogic Administration Console を使用して、各プロバイダに「認証の並べ替え」と「制御フラグ」を設定してコンフィグレーションします。各認証プロバイダの制御フラグは SUFFICIENT に設定します。SUFFICIENT は、プロバイダが成功した場合に認証プロセスが完了することを示します。

6.4.1.3.1. MedRec のコンフィグレーション

認証リクエストが送信されると、ユーザの存在とログイン資格を検証するために、最初にデフォルトの認証プロバイダが呼び出されます。ユーザが見つからない場合、フレームワークは次に MedRec サンプル認証プロバイダを使用してユーザの存在とログイン資格を検証します。どちらのコンフィグレーション済みプロバイダでもユーザが見つからない場合、認証は失敗します。ユーザが見つかった場合、セキュリティフレームワークは次のプロバイダを呼び出しません。

ログインシーケンスのコンフィグレーションの詳細については、「JAAS 制御フラグ」を参照してください。

6.4.2. 認可

認可とは、ユーザの ID などの情報に基づいて、ユーザと WebLogic リソースとのやり取りを管理するプロセスのことです。WebLogic Server では、認可プロバイダはユーザと WebLogic リソースとの対話を管理して、整合性、機密性、および可用性を確保します。

WebLogic リソースは、基底の WebLogic Server エンティティを表す構造化オブジェクトです。セキュリティロールとセキュリティポリシーを使用すると、WebLogic リソースを権限のないアクセスから保護できます。セキュリティポリシーは、認可プロバイダのデータベースに格納されます。デフォルトでは、WebLogic 認可プロバイダがコンフィグレーションされ、セキュリティポリシーは組み込み LDAP サーバに格納されます。

6.4.2.1. MedRec の実装

クライアント認証リクエストが送信されると、ユーザのログイン資格およびグループメンバシップが格納されます。保護された WebLogic リソースがアクセスされた場合、セキュリティフレームワークは、ユーザのグループに関連付けられているロールを収集し、収集したロールに基づいて認可の可否を判断します。

MedRec のセキュリティは、URL リソースコンポーネントを使用して、Administration および Patient Web アプリケーションに適用されます。このコンポーネントは URL パターンにセキュリティポリシーを適用します。すべての HTTP リクエストは一致する URL パターンがないか評価されます。ポリシーによってパターンが保護されている場合、フレームワークはリクエスト元のユーザが認可されているかどうかを判断します。

WebLogic リソースの詳細については、「WebLogic リソースのタイプ」を参照してください。