ここでは、Java Enterprise System ソリューションの論理アーキテクチャーの例をいくつか示します。これらの例は、論理コンポーネントを多層アーキテクチャーの適切な層に配置する方法を示します。 その後、ユースケースを調べることで、コンポーネント間の関係を分析します。ここで示される論理アーキテクチャーの例を、Java Enterprise System ソリューションの論理アーキテクチャー設計を理解する基礎として使用してください。
最初の例は、Messaging Server の論理的に区別されるコンポーネントがほかのコンポーネントとどのように対話するかを示す、基本的な Messaging Server ソリューションです。2 番目の例は、約 1,000 〜 5,000 人の従業員を持つ中規模企業に適した、アイデンティティーベースの配備ソリューションの論理アーキテクチャーを示しています。
次の図は、Messaging Server 配備の基本的な論理アーキテクチャーを示しています。この論理アーキテクチャーは、Messaging Server に必要な、論理的に区別されるコンポーネントのみを示しています。この後の各図は、これらのコンポーネント間の関係を示しています。
「アイデンティティーベースの通信の例」で示されているように、通常、Messaging Server の配備は、ほかの Java Enterprise System コンポーネントを含む企業ソリューションの一部です。
次の表は、「Messaging Server の例」に示されているコンポーネントについて説明しています。
表 4–5 論理アーキテクチャー上の Messaging Server コンポーネント
コンポーネント |
説明 |
---|---|
電子メールクライアント |
電子メールの参照および送信に使用するクライアントアプリケーション。 |
電子メールメッセージを受信、ルーティング、転送、および配信するために、メッセージ転送エージェント (MTA) として設定された Messaging Server。 |
|
検索および保存用の適切なメッセージストアに接続をルーティングするために、メッセージマルチプレクサ (MMP) として設定された Messaging Server。MMP は Directory Server にアクセスしてディレクトリ情報を検索し、適切なメッセージストアを決定します。 |
|
電子メールメッセージの検索および保存用のメッセージストアとして設定された Messaging Server。 |
|
LDAP ディレクトリデータに対するアクセスを提供します。 |
論理アーキテクチャーでは、Messaging Server コンポーネント用のサービスのレプリケーションを指定しません。たとえば、企業の配備では、通常、着信と発信で異なる MTA インスタンスが作成されますが、「Messaging Server の例」は 1 つのMTA コンポーネントだけを示しています。論理コンポーネントの複数インスタンスへのレプリケーションは、設計上の意思決定として、配備設計フェーズで行います。
ユースケースは、アーキテクチャーの論理コンポーネント間の関係を識別する上で役立ちます。ユースケースに基づいてコンポーネント間のインタラクションをマップすることで、コンポーネントのインタラクションを図で表現できます。 その図は配備設計で役立ちます。
通常、配備設計の前に、各ユースケースを分析してコンポーネントのインタラクションを決定します。次の 3 つのユースケースは、Messaging Server の場合に一般的なケースで、論理コンポーネント間のインタラクションを示しています。
電子メールクライアントは、ログイン情報を Messaging Server マルチプレクサ (MMP) に送信する。
MMP は、ユーザー ID とパスワードの検証を Directory Server に要求する。
Directory Server は MMP に検証結果を返す。
MMP は、Messaging Server メッセージストア (STR) にメッセージリストを要求する。
STR は、Directory Server にユーザーの LDAP レコードを要求する。
Directory Server は、ユーザーの LDAP レコードを STR に返す。
STR は、MMP にメッセージリストを返す。
MMP は、電子メールクライアントにメッセージリストを転送する。
電子メールクライアントは、参照するメッセージを Messaging Server マルチプレクサ (MMP) に要求する。
MMP は、Messaging Server メッセージストア (STR) にメッセージを要求する。
STR は、MMP にメッセージを返す。
MMP は、電子メールクライアントにメッセージを転送する。
電子メールクライアントは、メッセージを削除するアクションを MMP に送信する。
MMP は、メッセージを削除するアクションを STR に転送する。
STR は、データベースからメッセージを削除し、MMP に確認を送信する。
MMP は、電子メールクライアントに削除の確認を転送する。
電子メールクライアントは、クライアントで作成したメッセージを Messaging Server メッセージ転送エージェント (MTA) に送信する。
MTA は、ユーザー ID とパスワードの検証を Directory Server に要求する。
Directory Server は MTA に検証結果を返す。
MTA は、Directory Server で、各受取人の宛先ドメインをチェックする。
Directory Server は、各受取人の宛先ドメインを MTA に返す。
MTA は、各受取人にメッセージを転送する。
MTA は、Messaging Server メッセージストア (STR) にメッセージを転送し、送信トレイにメッセージを保存する。
MTA は、電子メールクライアントに確認を送信する。
この例では、約 1,000 〜 5,000 人の従業員を持つ中規模企業用のアイデンティティーベースの通信を示します。通常、論理アーキテクチャーの設計を行なうためには、徹底的なビジネス分析の後に詳細な技術要件分析を行なう必要があります。ただし、これは理論上の例であるので、次のビジネス要件が決定されたものと仮定します。
企業の従業員は、内部の Web サイト、通信サービス、カレンダサービス、およびその他のリソースに対する個人用カスタマイズされたアクセスを必要としている。
企業全体の認証と承認により、内部の Web サイトなどのサービスに対するアクセスが許可される。
1 つのアイデンティティーは、すべてのエンタープライズサービスにおいて追跡され、内部の Web サイトなどのサービスへのアクセスを許可するシングルサインオンが有効になる。
この例のユースケースでは、ログイン手順、電子メールの参照、電子メールの送信、ポータルの個人用カスタマイズ、カレンダの同期、およびその他の類似のユーザーアクティビティーについて詳細化されています。
次の図は、このタイプのアイデンティティーベースの通信ソリューションに対する論理アーキテクチャーを示します。
通常、この種の配備ソリューションの場合、ソリューションが提供するサービスに対するユーザーのインタラクションを説明する多数の詳細なユースケースがあります。この例では、ユーザーが Web ブラウザクライアントからポータルにログインするときの、コンポーネント間のインタラクションを取り上げます。例では、ログインシナリオが次の 2 つのユースケースに分割されています。
ユーザーがログインし、認証されると、Portal Server はユーザーのポータル設定を検索する。
Portal Server は、電子メールおよびカレンダ情報を検索して、Web クライアントに表示する。
2 つのユースケースは、1 つの拡張されたユースケースと考えることができます。しかし、この例では、単純化のためにユースケースは分割されています。
Web ブラウザクライアントが、ユーザー ID とパスワードを Portal Server に送信する。
Portal Server は、Access Manager に認証を要求する。
Access Manager は、ユーザー ID とパスワードの検証を Directory Server に要求する。
Directory Server は、ユーザー ID とパスワードを検証する。
Access Manager は、Directory Server にユーザープロファイルを要求する。
Directory Server は、ユーザープロファイルを返す。
Portal Server は、Access Manager にユーザー表示プロファイルを要求する。
Access Manager は、ポータル設定を返す。
ポータル設定が Web ブラウザクライアントに表示される。
ログイン、認証、およびポータル設定の検索が正常に完了したあと、Portal Server は、Messaging Server MMP に電子メールメッセージを要求する。
MMP は、Messaging Server STR にメッセージリストを要求する。
STR は、MMP にメッセージリストを返す。
MMP は、Portal Server にメッセージヘッダーを転送する。
Portal Server は、Communications Express にカレンダ情報を要求する。
Communications Express は、Calendar Server バックエンドにカレンダ情報を要求する。
Calendar Server バックエンドは、Communications Express にカレンダ情報を返す。
Communications Express は、Portal Server にカレンダ情報を転送する。
Portal Server は、すべてのチャネル情報を Web ブラウザクライアントに送信する。