Sun Java Enterprise System 2005Q4 技術の概要

Java Enterprise System ソリューションアーキテクチャーの例

Java Enterprise System は、広範なソフトウェアソリューションをサポートします。

多くのソリューションは、開発作業を行わずに、Java Enterprise System に含まれるコンポーネントを使ってすぐに設計および配備できます。その他のソリューションには、新しいビジネスまたはプレゼンテーションサービスを提供するカスタム J2EE コンポーネントの開発を必要とする、広範な開発が必要になる場合があります。これらのカスタムコンポーネントを SOAP (Simple Object Access Protocol) インタフェース標準に準拠する Web サービスとしてカプセル化することができます。多くのソリューションは、この 2 つの方法を組み合わせて使用します。

ここでは、前の節のアーキテクチャーの概念に基づき、Java Enterprise System がすぐに使用できるソリューションをどのようにしてサポートするのかを示す例を取り上げます。

エンタープライズ通信のシナリオ

企業は、一般に従業員間の通信、特に電子メールサービスやカレンダサービスをサポートする必要があります。そのような企業は、内部の Web サイトやその他のリソースに対する個人向けにカスタマイズされたアクセスを企業全体にわたる認証および承認サービスに基づいて従業員に提供すると便利であるとみなします。また、それらの企業は、シングル Web サインオンによりすべてのエンタープライズサービスへのアクセスが可能になるように、すべてのエンタープライズサービスで従業員のアイデンティティーを追跡することを望みます。

多数のビジネス要件の一部の例である、このような特定のビジネス要件を次の表にまとめてあります。

表 2–4 ビジネス要件の要約: 通信のシナリオ

ビジネス要件 

説明 

必要な Java ES サービス 

シングルサインオン 

セキュリティー保護されたエンタープライズリソースおよびサービスへのアクセス (Web アクセスはシングルサインオンの単一の ID に基づく)。 

アイデンティティーサービス 

メッセージング 

カレンダ 

従業員と外部との電子メールメッセージング。 

電子的な従業員用のカレンダ機能や会議の設定。 

通信サービスと共同作業サービス 

ポータルアクセス 

電子メール、カレンダ、内部 Web ページなどの通信サービスへの単一の Web ベースの個人向けにカスタマイズされたアクセスポイント。 

ポータルサービス 

さらに、企業には、これらのサービスを提供するソフトウェアシステムのパフォーマンス、可用性、ネットワークセキュリティー、およびスケーラビリティーに関する要件があります。

シナリオ例の論理アーキテクチャー

表 2–4 で示したポータルサービス、通信サービス、およびアイデンティティーサービスを Java ES コンポーネントを使用して配信するための論理アーキテクチャーを次の図に示します。このアーキテクチャーは、Messaging Server の論理的に異なる設定を、それぞれが異なるサービスを提供するために、別々のコンポーネントとして扱います。

図 2–7 エンタープライズ通信のシナリオの論理アーキテクチャー

エンタープライズ通信シナリオの例の論理アーキテクチャーを示す図。

コンポーネントは、標準の論理層を表す横の次元、またインフラストラクチャーサービスレベルを表す縦の次元に配置されています。コンポーネント間の対話は、分散型インフラストラクチャーサービスとしての各コンポーネントの機能 (インフラストラクチャーサービスレベル間の対話) または階層アプリケーションアーキテクチャー内の各コンポーネントの役割 (論理層内または論理層間の対話) に依存します。

このアーキテクチャーでは、Directory Server に格納されたユーザー情報にアクセスする Access Manager が、プレゼンテーション層の Portal Server およびその他の Web ベースコンポーネントに対する、シングルサインオン認証および承認の仲介役として機能します。Messaging Server コンポーネントには、データ層のメッセージストア (Messaging Server-STR)、ビジネスサービス層の送信および取得コンポーネント、プレゼンテーション層の HTTP アクセスコンポーネントおよび Communications Express が含まれます。

論理アーキテクチャーは、さまざまな Java ES コンポーネント間のインフラストラクチャーサービスの依存関係も示します。たとえば、Portal Server は、メッセージングチャネルとカレンダチャネルには Communications Express を利用し、認証および承認サービスには Access Manager を利用します。これらのコンポーネントは、今度は、ユーザー情報および設定データのために Directory Server を利用します。多数のコンポーネントは、Web Server が提供する Web コンテナサービスを必要とします。

Java ES ソリューションの論理設計の詳細については、『Sun Java Enterprise System 2005Q4 配備計画ガイド』を参照してください。

シナリオ例の配備アーキテクチャー

論理アーキテクチャーから配備アーキテクチャーに移行する際には、サービス品質要件が最も重要になります。たとえば、保護されたサブネットやファイアウォールを使用して、バックエンドデータへのセキュリティーバリアを設けることができます。多くのコンポーネントの可用性とスケーラビリティーの要件は、複数のコンピュータにコンポーネントを配備し、ロードバランサを使用してレプリケートしたコンポーネント間に要求を分散することによって満たすことができます。

ただし、より高い可用性要件の水準が適用された場合や大量のディスク容量が必要な場合は、他の可用性ソリューションの方が適しています。たとえば、Messaging Server ストアに Sun Cluster を、Directory Server にマルチマスターレプリケーションを使用できます。

Java ES ソリューションの配備設計の詳細については、『Sun Java Enterprise System 2005Q4 配備計画ガイド』を参照してください。