Sun Java System Communications Express 6 2004Q2 管理ガイド |
第 2 章
Communications Express の概要Sun JavaTM System Communications Express 6 2004Q2 では、統合された Web ベースの通信およびコラボレーションクライアントが用意されています。このクライアントでは、インターネットサービスプロバイダ、企業、OEM などのニーズを満たすことができます。
Web ベースのクライアントであるため、Communications Express の 3 つのクライアントモジュールであるカレンダ、アドレス帳、メールは、アクセスが Web サーバーに、表示がブラウザによって異なります。
製品の特徴この章には、以下の節があります。
高レベルのアーキテクチャ
カレンダおよびアドレス帳は、任意の Web コンテナに単独のアプリケーションとして配備され、このマニュアルでは、統合 Web クライアント (UWC) と総称されます。
図 2-1 高レベルのアーキテクチャ
Messenger Express は、Messaging Server の HTTP サービスを Web ベースで使用するスタンドアロンのメールアプリケーションです。Messenger Express は、カレンダモジュールおよびアドレス帳モジュールと同じシステム上に配備されなければなりません。Messenger Express は、Messaging Server の HTTP サービスを Web ベースで使用するスタンドアロンのメールアプリケーションです。Messenger Express は、カレンダモジュールおよびアドレス帳モジュールと同じシステム上に配備されなければなりません。
UWC は Sun ONE Application Framework である JATO をベースにしています。UWC にアクセスするための HTTP 要求を処理するには、J2EE 準拠の Web サーバーが必要です。
それぞれのユーザー要求は、専用のアプリケーションコントローラサーブレットに渡され、このサーブレットは要求をメール、カレンダ、アドレス帳などの適切な通信クライアントモジュールに委任します。アプリケーションサーブレットは要求の委任前に、UWC にアクセスしようとするブラウザクライアントに有効な HTTP セッションが存在するかどうか確認します。有効な HTTP セッションが存在しない場合は、コントローラサーブレットが要求フローを認証プロセスに送ります。
認証プロセスは、Web フィルタおよび認証サーブレットの組で処理されます。
- Identity Server SSO フィルタ: Identity Server のシングルサインオンメカニズムを使用して Sun Java System Identity Server とのセッションが確立されているかを確認します。有効な Identity Server セッションが見つかった場合は、UWC の HTTP セッションを作成し、チェーン内のほかのフィルタに制御を渡します。そうでない場合は、セッションを作成せずに制御を渡します。
- Messaging SSO フィルタ: Messaging SSO メカニズムに参加している Portal Server や Messenger Express などのピア Sun Java System アプリケーションとのセッションが確立されているかどうかを確認します。
- LDAP Auth フィルタ: このフィルタは、Sun ONE LDAP Schema, v1 をサポートするアプリケーションに対応するために使用します。また、Identity Server SSO および Messaging SSO フィルタの両方で、HTTP セッションの作成に失敗した場合にも使用します。このフィルタではユーザー名およびパスワードを使用して、UWC に設定された認証 LDAP に対するクレデンシャルを検証します。クレデンシャルが認証されると、HTTP セッションを作成し、要求を次のフィルタに転送します。
- 匿名アクセスフィルタ: 有効なセッションがない場合、このフィルタが http://host:port/?calid=calid という形式の URL が存在するかどうかを確認します。この形式の URL が存在する場合は、匿名アクセスを行います。
- 認証サーブレット: 認証サーブレットでは、任意の Web フィルタが UWC に HTTP セッションを作成できたかどうかを判断します。有効なセッションを見つけられなかった場合は、要求をユーザーのログインページに送り、ユーザー名とパスワードの入力を求めます。Identity Server が UWC で有効な場合は、UWC ログインページが表示されます。
Identity Server ページで入力したクレデンシャルは、LDAP サービスなど、設定済みサービスのいずれかを使用して、Identity Server が認証します。
Communications Express ログインページ経由で送られたクレデンシャルはUWC 用に設定された認証 LDAP に対して認証されます。
クレデンシャルが送信されて認証されると、UWC の有効な HTTP セッションを取得するために、要求はもう一度フィルタを通ります。
有効なセッションの存在を認証サーブレットが判定すると、要求をアプリケーションコントローラにリダイレクトします。アプリケーションコントローラでは、要求されたクライアントモジュールを表示します。
Sun Java System Communications Express は、以下の 3 つのモジュールで構成されています。
- メール: メールアーキテクチャでは JavaScript を使用して、ユーザーインタフェースを提供し、HTTP プロトコルで Sun Java System Messaging Server とやりとりし、データをフェッチします。
- カレンダ: カレンダモジュールのプレゼンテーション層は、Sun ONE Application Framework に基づいています。データ層は Java API for Calendar (JCAPI) にアクセスし、HTTP ベースのプロトコルで Sun Java System Calendar Server とのデータ交換を可能にします。
- アドレス帳: アドレス帳アーキテクチャでは、プレゼンテーション層に XML/XSLT を、データストレージに LDAP を使用しています。データストレージは LDAP SDK API を使用してアクセスされます。
各クライアントモジュールは、さらに Sun ONE Application Framework モジュールとしても定義されており、モジュール固有のコントローラサーブレットによって処理されます。
UWC 用に定義されている JATO モジュールは以下のとおりです。
- ベースレベルモジュール: オプションの確認などのアプリケーション全体のすべての作業やアプリケーションレベルの初期化は、ベースレベルモジュールが処理します。このモジュールのコントローラサーブレットは UWCServletBase で、URIが「base」であるすべての要求を処理します。その他のすべてのモジュールのコントローラサーブレットは、このサーブレットから継承されます。
- カレンダモジュール: カレンダアプリケーションに属するすべてのビューとモデルは、このモジュールが処理します。このモジュールのコントローラサーブレットは CalModuleServlet で、URIが「calclient」であるすべての要求を処理します。
- メールモジュール: メールアプリケーションに属するすべてのビューとモデルは、このモジュールが処理します。このモジュールのコントローラサーブレットは MailModuleServlet で、URIが「mailclient」であるすべての要求を処理します。
- アドレス帳モジュール: アドレス帳アプリケーションに属するすべてのビューとモデルは、このモジュールが処理します。このモジュールのコントローラサーブレットは ABModuleServlet で、URIが「abclient」であるすべての要求を処理します。
要求フローの概要
UWC に対する要求は、以下のフェーズを初期化します。
- 認証: Web フィルタがユーザーセッションを作成します。
- セッション作成: ユーザーセッションが作成されると、以下のアクションが実行されて、ユーザーセッションの残りでアプリケーションを有効にします。
- UI レンダリング: このフェーズでは、完了した要求によって、表示用に結果のページが出力されます。
- 要求転送 (送信): ユーザーが入力して送信したデータに対して、サーバーレベルの検証が実行されます。検証の成功または失敗に応じて、要求が適切なターゲットに転送されます。
- エラー処理: エラーまたは例外が発生すると、要求に関連するエラーページが表示されます。
- 匿名アクセス: 匿名カレンダでは、表示されているカレンダに対して、「読み取り専用」アクセスに制限されます。匿名カレンダには、予定のリスト表示、日別、週別、月別、および年別表示が表示されます。メール、アドレス帳、およびオプションタブの内容は匿名アクセスでは表示されません。
初期化
UWC では、ユーザーセッション中にアプリケーション全体で共有される多くのオブジェクトを参照します。これらのオブジェクトは、新規のユーザーセッションが作成されたとき、またはアプリケーションが開始したときに初期化されます。初期化は、以下のようにカテゴリ分けできます。
アプリケーションの初期化
アプリケーション全体のオブジェクトすべてが、アプリケーションの範囲でキャッシュされます。
- 認証およびアプリケーション設定: 認証およびアプリケーション設定のパラメータは、WEB-INF/config ディレクトリの uwcauth.properties および uwcconfig.properties にあります。アプリケーション設定の詳細は、アプリケーションの開始時にロードされます。認証パラメータは、UWC が最初にアクセスされるときに使用されます。
- ドメイン設定: ドメインの設定は、ユーザーのドメイン LDAP エントリと uwcdomainconfig.properties ファイルに格納されます。UWC 用の各定義済みドメインが読み取られて、格納されます。次に、アプリケーションはドメイン設定の詳細をキャッシュから取得します。毎回 LDAP から読み取ることはしません。
- リソースバンドルキャッシング: すべての i18n 文字列、イメージパス、およびその他のローカライズおよびカスタマイズ可能な項目が、1 回読み取られてキャッシュされます。
- LDAP プール: アプリケーションの開始時に、ユーザーおよびグループの LDAP の接続プールが作成されます。プールは、アプリケーションが停止すると、削除されます。
ユーザーセッションベースの初期化
新規のユーザーセッション用に、以下が初期化されます。
モジュールレベルの初期化
モジュールレベルの初期化は、要求が特にモジュールの URI に対して行われたときに、実行されます。
カレンダストア、カレンダ設定、カレンダデータの各オブジェクトは、ユーザーのカレンダモジュールに対するモジュールレベルの初期化の例です。