第 4 章 論理設計
ソリューションライフサイクルの論理設計フェーズでは、ソリューションの論理コンポーネント間の相互関係を示す論理アーキテクチャーを設計します。論理アーキテクチャーと技術要件フェーズの使用パターン分析から、配備シナリオが形成されます。 これは、配備設計フェーズへのインプットとなります。
この章で説明する内容は、次のとおりです。
論理アーキテクチャーについて
論理アーキテクチャーは、ソリューションの実装に必要とされるソフトウェアコンポーネントを特定し、コンポーネント間の相互関係を示します。論理アーキテクチャーと、技術要件フェーズで決定されたサービス品質要件により、配備シナリオが形成されます。配備シナリオは、次のフェーズである配備設計で行なわれる配備アーキテクチャーの設計の基礎となります。
論理アーキテクチャーを設計する際は、ユーザーにサービスを提供するコンポーネントだけでなく、必要なミドルウェアサービスおよびプラットフォームサービスを提供するその他のコンポーネントも特定する必要があります。インフラストラクチャーサービスの依存関係と論理層は、この分析を実行するための 2 つの相補的な手段となります。
インフラストラクチャーサービスの依存関係と論理層は、Sun JavaTM Enterprise System が基づくソリューションアーキテクチャーの 3 つの次元のうちの 2 つです。次に示す 3 つの次元は、「論理アーキテクチャーについて」にも示されています。
-
インフラストラクチャーサービスの依存関係: エンタープライズサービスを提供する、対話型のソフトウェアコンポーネント。これらのソフトウェアコンポーネントは、分散型のコンポーネントが相互に通信したり相互動作したりすることを可能にする基本のインフラストラクチャーサービスのセットを必要とします。
-
論理層: ソフトウェアコンポーネントの論理的構成を表す層。 提供するサービスの性質に基づいて、ソフトウェアコンポーネントの論理的および物理的な独立性を表しています。
-
サービス品質: システムのサービス品質。 パフォーマンス、可用性、スケーラビリティーなど、ソフトウェアソリューションの設計上および運用上の特定の側面を表します。
注 –
Java Enterprise System アーキテクチャーの概念に関する詳細については、『Sun Java Enterprise System 2005Q4 Technical Overview』の「Java Enterprise System アーキテクチャー」の章を参照してください。
論理アーキテクチャーでは、必要なコンポーネントとそれらの依存関係を示すことで、インフラストラクチャーサービスのレベルを表します。また、論理アーキテクチャーでは、プレゼンテーション、ビジネス、およびデータの各サービスを表す論理層にコンポーネントを割り当てます。これらの層には、最終的にクライアント層からアクセス可能です。サービス品質要件は論理アーキテクチャーでモデル化されませんが、配備シナリオにおいて、論理アーキテクチャーと対応付けられます。
論理アーキテクチャーの設計
論理アーキテクチャーを設計する際は、技術要件フェーズで特定したユースケースを使用して、ソリューションに必要なサービスを提供する Java Enterprise System コンポーネントを決定します。また、最初に特定したコンポーネントにサービスを提供するコンポーネントもすべて識別する必要があります。
Java Enterprise System コンポーネントを、それらが提供するサービスの種類に応じて多層アーキテクチャー内に配置します。多層アーキテクチャーの一部としてコンポーネントを理解することは、あとで、コンポーネントによって提供されるサービスをどのように分散するか決定する上で役立ちます。 また、スケーラビリティーや可用性などのサービス品質を実装するための戦略を決定する上でも役立ちます。
さらに、セキュアアクセスゾーン内に配置された論理コンポーネントの、別のビューも提供できます。セキュアアクセスゾーンの例は、「アクセスゾーン」の節を参照してください。
Java Enterprise System コンポーネント
Java Enterprise System は、エンタープライズサービスを提供する、対話型のソフトウェアコンポーネントで構成されています。 これらを使用して、企業のソリューションを構築できます。次の図は、Java Enterprise System が提供する主要なソフトウェアコンポーネントを示しています。Java Enterprise System コンポーネントとそれらが提供するサービスの詳細については、『Sun Java Enterprise System 2005Q4 Technical Overview』を参照してください。
図 4–1 Java Enterprise System コンポーネント
コンポーネントの依存関係
論理アーキテクチャー用に Java Enterprise System コンポーネントを特定する際は、サポートするコンポーネントも識別する必要があります。たとえば、Messaging Server を論理アーキテクチャーに必要なコンポーネントとして特定した場合、Directory Server と、場合によっては Access Manager も論理アーキテクチャーに含める必要があります。Messaging Server は、ディレクトリサービスに関して Directory Server に依存し、シングルサインオンを必要とするソリューションに関して Access Manager に依存します。
次の表は、Java Enterprise System コンポーネントの依存関係を示しています。主要コンポーネント間の依存関係を視覚的に表現したものについては、「コンポーネントの依存関係」を参照してください。論理アーキテクチャーを設計する際は、この表とそれに付随する図を参照して、設計における依存コンポーネントを決定します。
表 4–1 Java Enterprise System コンポーネントの依存関係|
Java Enterprise System コンポーネント |
依存するコンポーネント |
|---|---|
|
Message Queue Directory Server (省略可能) |
|
|
Messaging Server (電子メール通知サービス用) Access Manager (シングルサインオン用) Web Server (Web インタフェース用) Directory Server |
|
|
Access Manager (シングルサインオン用) Calendar Server Messaging Server Instant Messaging Web Server (Web インタフェース用) Directory Server |
|
|
Directory Server |
|
|
なし |
|
|
Application Server Web Server Directory Server |
|
|
Access Manager (シングルサインオン用) Directory Server |
|
|
Directory Server (省略可能) |
|
|
Access Manager (シングルサインオン用) Web Server (Web インタフェース用) Directory Server |
|
|
Portal Server チャネルの使用を設定する場合に必要なコンポーネント: Calendar Server Messaging Server Instant Messaging Access Manager (シングルサインオン用) Application Server Web Server Directory Server |
|
|
Portal Server |
|
|
Access Manager (省略可能、アクセス制御用) |
注 –
「コンポーネントの依存関係」に示されている Java Enterprise System コンポーネント間の依存関係には、コンポーネントのすべての依存関係が一覧表示されているわけではありません。「コンポーネントの依存関係」には、インストール計画時に考慮する必要のある依存関係は一覧表示されていません。Java Enterprise System の依存関係の全リストについては、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』を参照してください。
図 4–2 Java Enterprise System コンポーネントの依存関係
Web コンテナサポート
前節の「コンポーネントの依存関係」では、Portal Server および Access Manager が稼働する Web コンテナについては説明されていません。この Web コンテナは、Application Server、Web Server、またはサードパーティー製品によって提供されます。Portal Server または Access Manager を含んだ論理アーキテクチャーを設計する場合は、それらのコンポーネントに必要な Web コンテナを必ず考慮してください。
Messaging Server によって提供される論理的に区別されるサービス
論理的に区別される次のサービスを提供する別個のインスタンスを提供するように Java Enterprise System Messaging Server を設定できます。
-
メッセージ転送エージェント
-
メッセージマルチプレクサ
-
メッセージエクスプレスマルチプレクサ
-
メッセージストア
Messaging Server のこれらの各種設定は、別個の物理サーバーに配備可能で、論理アーキテクチャーの別個の層に表すことができる機能を提供します。Messaging Server のこれらの設定は、異なる層にある論理的に区別されるサービスであるため、論理アーキテクチャーを設計する際は、それらを論理的に区別されるコンポーネントと考えます。論理的に区別されるコンポーネントの例は、「論理アーキテクチャーの例」の節を参照してください。
次の表は、Messaging Server の論理的に区別される設定について説明しています。
表 4–2 Messaging Server の設定|
サブコンポーネント |
説明 |
|---|---|
|
SMTP 接続の処理、電子メールのルーティング、および適切なメッセージストアへのメッセージの配信を行なうことで、電子メールの送信をサポートします。MTA コンポーネントは、企業外部から送信された着信電子メールまたは企業内部から送信された発信電子メールをサポートするように設定できます。 |
|
|
電子メールメッセージの検索と保存を提供します。 |
|
|
IMAP または POP のいずれかのプロトコルを使用して電子メールクライアントのメッセージストアにアクセスすることで、電子メールの検索をサポートします。 |
|
|
Web ベース (HTTP) クライアントの代わりにメッセージストアにアクセスすることで、電子メールの検索をサポートします。 |
アクセスコンポーネント
Java Enterprise System には、システムサービスへのアクセスを提供するコンポーネントもあります。 このアクセスは多くの場合、企業のファイアウォール外から行なわれるものです。メッセージマルチプレクサ用に設定された Messaging Server など、Messaging Server の一部の設定では、ネットワークアクセスも提供されます。次の表は、システムサービスへのリモートアクセスを提供する Java Enterprise System コンポーネントについて説明しています。
表 4–3 リモートアクセスを提供する Java Enterprise System コンポーネント|
コンポーネント |
説明 |
|---|---|
|
拡張されたディレクトリアクセス、スキーマ互換性、ルーティング、および複数の Directory Server インスタンス間でのロードバランスを提供します。 |
|
|
内部ポータルやインターネットアプリケーションなど、Portal Server のコンテンツやサービスへの、企業ファイアウォール外からのセキュリティー保護されたインターネットアクセスを提供します。 |
|
|
Portal Server に対する、モバイルデバイスからのワイヤレスアクセスおよび音声アクセスを提供します。 |
|
|
Web ベース (HTTP) クライアントの代わりにメッセージストアにアクセスすることで、電子メールの検索をサポートします。 |
「アクセスゾーン」の節の例で示されているように、リモートアクセスを提供するコンポーネントは、通常、セキュアアクセスゾーンに配備されます。
多層アーキテクチャー設計
Java Enterprise System は、提供する機能に応じてサービスが各層に配置される多層アーキテクチャー設計に特に適しています。各サービスは論理上独立していて、同じ層のサービスまたは異なる層のサービスのいずれからもアクセス可能です。次の図は、企業アプリケーションの多層アーキテクチャーモデルです。 クライアント、プレゼンテーション、ビジネスサービス、データの各層が示されています。
図 4–3 多層アーキテクチャーモデル
次の表は、「多層アーキテクチャー設計」に示されている論理層について説明しています。
表 4–4 多層アーキテクチャーの論理層|
層 |
説明 |
|---|---|
|
情報をエンドユーザーに提示するクライアントアプリケーションが配置されます。Java Enterprise System の場合、これらのアプリケーションは、通常、メールクライアント、Web ブラウザ、またはモバイルアクセスクライアントとなります。 |
|
|
エンドユーザーにデータを表示するサービスを提供し、ユーザーがプレゼンテーションを処理および操作できるようにします。たとえば、Web メールクライアントまたは Portal Server コンポーネントの場合、ユーザーは、受信した情報の表示内容に変更を加えることができます。 |
|
|
通常、プレゼンテーション層またはビジネスサービス層のほかのサービスに提供するデータ、またはクライアント層のクライアントに直接提供するデータをデータ層から取り出す、バックエンドサービスを提供します。たとえば、Access Manager は、ほかの Java Enterprise System コンポーネントにアイデンティティーサービスを提供します。 |
|
|
プレゼンテーション層またはビジネスサービス層のサービスによってアクセスされるデータベースサービスを提供します。たとえば、Directory Server は、ほかのサービスに LDAP ディレクトリアクセスを提供します。 |
多層アーキテクチャー設計には、いくつかの利点があります。多層アーキテクチャーでの機能に応じたサービスの配置は、配備設計フェーズで、ネットワークにどのようにサービスを分散するか決定する上で役立ちます。また、アーキテクチャー内のコンポーネントがほかのコンポーネントのサービスにどのようにアクセスするかについても確認できます。この視覚化により、可用性、スケーラビリティー、セキュリティーなどのサービス品質ソリューションの計画が行ないやすくなります。
論理アーキテクチャーの例
ここでは、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 の例」に示されているコンポーネントについて説明しています。
表 4–5 論理アーキテクチャー上の Messaging Server コンポーネント|
コンポーネント |
説明 |
|---|---|
|
電子メールクライアント |
電子メールの参照および送信に使用するクライアントアプリケーション。 |
|
電子メールメッセージを受信、ルーティング、転送、および配信するために、メッセージ転送エージェント (MTA) として設定された Messaging Server。 |
|
|
検索および保存用の適切なメッセージストアに接続をルーティングするために、メッセージマルチプレクサ (MMP) として設定された Messaging Server。MMP は Directory Server にアクセスしてディレクトリ情報を検索し、適切なメッセージストアを決定します。 |
|
|
電子メールメッセージの検索および保存用のメッセージストアとして設定された Messaging Server。 |
|
|
LDAP ディレクトリデータに対するアクセスを提供します。 |
論理アーキテクチャーでは、Messaging Server コンポーネント用のサービスのレプリケーションを指定しません。たとえば、企業の配備では、通常、着信と発信で異なる MTA インスタンスが作成されますが、「Messaging Server の例」は 1 つのMTA コンポーネントだけを示しています。論理コンポーネントの複数インスタンスへのレプリケーションは、設計上の意思決定として、配備設計フェーズで行います。
Messaging Server ユースケース
ユースケースは、アーキテクチャーの論理コンポーネント間の関係を識別する上で役立ちます。ユースケースに基づいてコンポーネント間のインタラクションをマップすることで、コンポーネントのインタラクションを図で表現できます。 その図は配備設計で役立ちます。
通常、配備設計の前に、各ユースケースを分析してコンポーネントのインタラクションを決定します。次の 3 つのユースケースは、Messaging Server の場合に一般的なケースで、論理コンポーネント間のインタラクションを示しています。
ユースケース 1: ユーザーが正常に 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 は、電子メールクライアントにメッセージリストを転送する。
ユースケース 2: ログインしたユーザーがメールを参照し、削除する
手順
-
電子メールクライアントは、参照するメッセージを Messaging Server マルチプレクサ (MMP) に要求する。
-
MMP は、Messaging Server メッセージストア (STR) にメッセージを要求する。
-
STR は、MMP にメッセージを返す。
-
MMP は、電子メールクライアントにメッセージを転送する。
-
電子メールクライアントは、メッセージを削除するアクションを MMP に送信する。
-
MMP は、メッセージを削除するアクションを STR に転送する。
-
STR は、データベースからメッセージを削除し、MMP に確認を送信する。
-
MMP は、電子メールクライアントに削除の確認を転送する。
ユースケース 3: ログインしたユーザーが電子メールメッセージを送信する
手順
-
電子メールクライアントは、クライアントで作成したメッセージを 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 つの拡張されたユースケースと考えることができます。しかし、この例では、単純化のためにユースケースは分割されています。
ユースケース 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 ブラウザクライアントに表示される。
ユースケース 2: Portal Server が電子メール情報とカレンダ情報を表示する
手順
-
ログイン、認証、およびポータル設定の検索が正常に完了したあと、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 ブラウザクライアントに送信する。
アクセスゾーン
論理アーキテクチャーのコンポーネントを表す別の方法は、アーキテクチャーでセキュリティー保護されたアクセスがどのように提供されるかを示すアクセスゾーンにコンポーネントを配置することです。次の図は、Java Enterprise System コンポーネントを配備するためのアクセスゾーンを示しています。各アクセスゾーンは、インターネットおよびイントラネットを経由するセキュリティー保護されたリモートアクセスをコンポーネントがどのように提供するかを示しています。
図 4–5 アクセスゾーンに配置された論理コンポーネント
次の表は、「アクセスゾーン」に示されているアクセスゾーンについて説明しています。
表 4–6 セキュアアクセスゾーンとその中に配置されたコンポーネント|
アクセスゾーン |
説明 |
|---|---|
|
イントラネットとインターネット間の、ファイアウォールによって実施されるポリシーが適用されるインターネットへのアクセス。内部アクセスゾーンは、通常、エンドユーザーが Web をブラウズしたり電子メールを送信したりするために使用します。 インターネットに直接アクセスして Web ブラウズすることが許可される場合もあります。しかし、通常は、インターネットに対するセキュリティー保護されたアクセスが、外部アクセスゾーンを通じて提供されます。 |
|
|
重要なバックエンドサービスに対するセキュリティーバッファーとして機能し、インターネットに対するセキュリティー保護されたアクセスを提供します。 |
|
|
重要なバックエンドサービスに対する制限付きのアクセスを提供します。これらのサービスには、外部アクセスゾーンからのみアクセス可能です。 |
「アクセスゾーン」には、前出の例で示されていた論理層は示されていませんが、代わりに、リモートアクセスおよび内部アクセスを提供するコンポーネント、これらのコンポーネントとファイアウォールなどのセキュリティー手段との関係、および実施する必要のあるアクセスルールの視覚的説明に焦点が当てられています。アクセスゾーンを示す図と組み合わせて多層アーキテクチャー設計を使用し、計画中の配備の論理モデルを提供します。
配備シナリオ
完成した論理アーキテクチャー設計だけでは、ソリューションライフサイクルの配備設計フェーズに進むには不十分です。論理アーキテクチャーと、技術要件フェーズで特定したサービス品質 (QoS) 要件を対応付ける必要があります。論理アーキテクチャーと QoS 要件の対応付けにより、配備シナリオが構成されます。第 5 章「配備設計」で説明するように、配備シナリオは、配備アーキテクチャーの設計の開始点となります。
- © 2010, Oracle Corporation and/or its affiliates