test

Sun Java Enterprise System 2005Q4 配備計画ガイド

論理アーキテクチャーの例

ここでは、Java Enterprise System ソリューションの論理アーキテクチャーの例をいくつか示します。これらの例は、論理コンポーネントを多層アーキテクチャーの適切な層に配置する方法を示します。 その後、ユースケースを調べることで、コンポーネント間の関係を分析します。ここで示される論理アーキテクチャーの例を、Java Enterprise System ソリューションの論理アーキテクチャー設計を理解する基礎として使用してください。

最初の例は、Messaging Server の論理的に区別されるコンポーネントがほかのコンポーネントとどのように対話するかを示す、基本的な Messaging Server ソリューションです。2 番目の例は、約 1,000 〜 5,000 人の従業員を持つ中規模企業に適した、アイデンティティーベースの配備ソリューションの論理アーキテクチャーを示しています。

Messaging Server の例

次の図は、Messaging Server 配備の基本的な論理アーキテクチャーを示しています。この論理アーキテクチャーは、Messaging Server に必要な、論理的に区別されるコンポーネントのみを示しています。この後の各図は、これらのコンポーネント間の関係を示しています。

注 –

「アイデンティティーベースの通信の例」で示されているように、通常、Messaging Server の配備は、ほかの Java Enterprise System コンポーネントを含む企業ソリューションの一部です。

図 4–4 Messaging Server 配備の論理アーキテクチャー

多層アーキテクチャーに配備された Messaging Server シナリオの論理コンポーネントを示す図。

次の表は、「Messaging Server の例」に示されているコンポーネントについて説明しています。

表 4–5 論理アーキテクチャー上の Messaging Server コンポーネント

コンポーネント 

説明 

電子メールクライアント 

電子メールの参照および送信に使用するクライアントアプリケーション。 

Messaging Server MTA

電子メールメッセージを受信、ルーティング、転送、および配信するために、メッセージ転送エージェント (MTA) として設定された Messaging Server。 

Messaging Server MMP

検索および保存用の適切なメッセージストアに接続をルーティングするために、メッセージマルチプレクサ (MMP) として設定された Messaging Server。MMP は Directory Server にアクセスしてディレクトリ情報を検索し、適切なメッセージストアを決定します。 

Messaging Server STR

電子メールメッセージの検索および保存用のメッセージストアとして設定された Messaging Server。 

Directory Server

LDAP ディレクトリデータに対するアクセスを提供します。 

論理アーキテクチャーでは、Messaging Server コンポーネント用のサービスのレプリケーションを指定しません。たとえば、企業の配備では、通常、着信と発信で異なる MTA インスタンスが作成されますが、「Messaging Server の例」は 1 つのMTA コンポーネントだけを示しています。論理コンポーネントの複数インスタンスへのレプリケーションは、設計上の意思決定として、配備設計フェーズで行います。

Messaging Server ユースケース

ユースケースは、アーキテクチャーの論理コンポーネント間の関係を識別する上で役立ちます。ユースケースに基づいてコンポーネント間のインタラクションをマップすることで、コンポーネントのインタラクションを図で表現できます。 その図は配備設計で役立ちます。

通常、配備設計の前に、各ユースケースを分析してコンポーネントのインタラクションを決定します。次の 3 つのユースケースは、Messaging Server の場合に一般的なケースで、論理コンポーネント間のインタラクションを示しています。

Procedureユースケース 1: ユーザーが正常に Messaging Server にログインする

手順

  1. 電子メールクライアントは、ログイン情報を Messaging Server マルチプレクサ (MMP) に送信する。

  2. MMP は、ユーザー ID とパスワードの検証を Directory Server に要求する。

  3. Directory Server は MMP に検証結果を返す。

  4. MMP は、Messaging Server メッセージストア (STR) にメッセージリストを要求する。

  5. STR は、Directory Server にユーザーの LDAP レコードを要求する。

  6. Directory Server は、ユーザーの LDAP レコードを STR に返す。

  7. STR は、MMP にメッセージリストを返す。

  8. MMP は、電子メールクライアントにメッセージリストを転送する。

    ユースケース 1 の Messaging Server コンポーネント間のデータフローを示す図。

Procedureユースケース 2: ログインしたユーザーがメールを参照し、削除する

手順

  1. 電子メールクライアントは、参照するメッセージを Messaging Server マルチプレクサ (MMP) に要求する。

  2. MMP は、Messaging Server メッセージストア (STR) にメッセージを要求する。

  3. STR は、MMP にメッセージを返す。

  4. MMP は、電子メールクライアントにメッセージを転送する。

  5. 電子メールクライアントは、メッセージを削除するアクションを MMP に送信する。

  6. MMP は、メッセージを削除するアクションを STR に転送する。

  7. STR は、データベースからメッセージを削除し、MMP に確認を送信する。

  8. MMP は、電子メールクライアントに削除の確認を転送する。

    ユースケース 2 の Messaging Server コンポーネント間のデータフローを示す図。

Procedureユースケース 3: ログインしたユーザーが電子メールメッセージを送信する

手順

  1. 電子メールクライアントは、クライアントで作成したメッセージを Messaging Server メッセージ転送エージェント (MTA) に送信する。

  2. MTA は、ユーザー ID とパスワードの検証を Directory Server に要求する。

  3. Directory Server は MTA に検証結果を返す。

  4. MTA は、Directory Server で、各受取人の宛先ドメインをチェックする。

  5. Directory Server は、各受取人の宛先ドメインを MTA に返す。

  6. MTA は、各受取人にメッセージを転送する。

  7. MTA は、Messaging Server メッセージストア (STR) にメッセージを転送し、送信トレイにメッセージを保存する。

  8. MTA は、電子メールクライアントに確認を送信する。

    ユースケース 3 の Messaging Server コンポーネント間のデータフローを示す図。

アイデンティティーベースの通信の例

この例では、約 1,000 〜 5,000 人の従業員を持つ中規模企業用のアイデンティティーベースの通信を示します。通常、論理アーキテクチャーの設計を行なうためには、徹底的なビジネス分析の後に詳細な技術要件分析を行なう必要があります。ただし、これは理論上の例であるので、次のビジネス要件が決定されたものと仮定します。

この例のユースケースでは、ログイン手順、電子メールの参照、電子メールの送信、ポータルの個人用カスタマイズ、カレンダの同期、およびその他の類似のユーザーアクティビティーについて詳細化されています。

次の図は、このタイプのアイデンティティーベースの通信ソリューションに対する論理アーキテクチャーを示します。

多層アーキテクチャーに配備されたアイデンティティーベースの通信シナリオの論理コンポーネントを示す図。

アイデンティティーベースの通信シナリオ例のユースケース

通常、この種の配備ソリューションの場合、ソリューションが提供するサービスに対するユーザーのインタラクションを説明する多数の詳細なユースケースがあります。この例では、ユーザーが Web ブラウザクライアントからポータルにログインするときの、コンポーネント間のインタラクションを取り上げます。例では、ログインシナリオが次の 2 つのユースケースに分割されています。

2 つのユースケースは、1 つの拡張されたユースケースと考えることができます。しかし、この例では、単純化のためにユースケースは分割されています。

Procedureユースケース 1: ユーザーが正常にログインし、ポータルがユーザーの設定を検索する

手順

  1. Web ブラウザクライアントが、ユーザー ID とパスワードを Portal Server に送信する。

  2. Portal Server は、Access Manager に認証を要求する。

  3. Access Manager は、ユーザー ID とパスワードの検証を Directory Server に要求する。

  4. Directory Server は、ユーザー ID とパスワードを検証する。

  5. Access Manager は、Directory Server にユーザープロファイルを要求する。

  6. Directory Server は、ユーザープロファイルを返す。

  7. Portal Server は、Access Manager にユーザー表示プロファイルを要求する。

  8. Access Manager は、ポータル設定を返す。

  9. ポータル設定が Web ブラウザクライアントに表示される。

    ユースケース 1 のアイデンティティーベースの通信シナリオのデータフローを示す図。

Procedureユースケース 2: Portal Server が電子メール情報とカレンダ情報を表示する

手順

  1. ログイン、認証、およびポータル設定の検索が正常に完了したあと、Portal Server は、Messaging Server MMP に電子メールメッセージを要求する。

  2. MMP は、Messaging Server STR にメッセージリストを要求する。

  3. STR は、MMP にメッセージリストを返す。

  4. MMP は、Portal Server にメッセージヘッダーを転送する。

  5. Portal Server は、Communications Express にカレンダ情報を要求する。

  6. Communications Express は、Calendar Server バックエンドにカレンダ情報を要求する。

  7. Calendar Server バックエンドは、Communications Express にカレンダ情報を返す。

  8. Communications Express は、Portal Server にカレンダ情報を転送する。

  9. Portal Server は、すべてのチャネル情報を Web ブラウザクライアントに送信する。

    ユースケース 2 のアイデンティティーベースの通信シナリオのデータフローを示す図。