2 アーキテクチャとリクエストの処理

この章では、Content Portlet Suite (CPS)のアーキテクチャの概要を説明し、ポートレットのリクエスト処理のためのイベントについて大まかなシーケンスを説明します。内容は次のとおりです。

第2.1項「CPSアーキテクチャの概要」
第2.2項「Model-View-Controllerフレームワーク」
第2.3項「リクエストの処理」

2.1 CPSアーキテクチャの概要

CPSポートレットはRemote Intradoc Client (RIDC) APIを使用して、Oracle WebCenter Content Serverと通信します。ポートレットAPIファサードは、ポートレット・コンテナ内に共通の操作を抽象化するので、Oracleのフレームワークは、同じハンドラ・コードを使用する様々なプラットフォームで動作できます。ポートレットの動作はカスタムMVCフレームワークにマッピングされ、このフレームワークがRIDC APIを使用して必要なタスクを実行します。

ポートレットは、CHECKIN_UNIVERSALおよびGET_SEARCH_RESULTSといった標準コンテンツ・サーバー・サービスのコンシューマです。これらのサービスは、RIDC APIを使用してポートレット・コントローラからディスパッチ・ハンドラによってコールされます。詳細は、Oracle WebCenter Content Content Server開発者ガイドのRemote Intradoc Client (RIDC)に関する章を参照してください。

2.2 Model-View-Controllerフレームワーク

CPSでは、オープン・ソースの Struts and Tilesフレームワークに基づいて、Model-View-Controller設計パターンが使用されますデータのプレゼンテーションは、データを取得および整理するロジックから分離されます。model(モデル)はデータ・アクセス層をカプセル化するUCPMレイヤー、view(ビュー)はユーザー・インタフェース要素としてモデルをレンダリングするJSPページ、controller(コントローラ)はイベント(通常はユーザーのアクション)を処理してイベントに応答し、モデル上で変更を呼び出すPortletDispatchハンドラです。

図2-1 MVCフレームワーク

「図2-1 MVCフレームワーク」の説明

2.3 リクエストの処理

ポートレット・リクエスト処理のイベントの大まかなシーケンスを次に示します(Searchポートレットに基づきます)。

ユーザーが問合せを入力して、「検索」ボタンをクリックします。
アクション URLが構築されて、ポートレット・コンテナにルーティングされます。ポートレット・コンテナは、適切なポートレット(この場合はSearchポートレット)にコマンドをルーティングします。
Searchポートレット上でprocessActionがコールされます。
Searchポートレットは検索パラメータ(構築されたURLの一部)を取得してRIDCメソッドをコールし、これによってコンテンツ・サーバーのSEARCHサービスが実行されて、検索レスポンスがポートレットに返されます。
ポートレット・コンテナは、ページ上の各ポートレット(Searchポートレットを含む)でレンダリングをコールし、各ポートレットは受信したデータを使用して(つまりデータをリフレッシュして)、HTMLフラグメントをユーザーに表示します。

図2-2 ポートレットのリクエスト処理

「図2-2 ポートレットのリクエスト処理」の説明

注意A: The アクション・リクエストはレンダリング・リクエストの開始前に終了する必要があります。

注意B: レンダリング・リクエストがトリガーされる順番は決まっていません。これらは順次または同時に実行されます。

ポートレットAPIファサード

ポータル・ベンダーは標準を様々に実装するので、各アクション・ハンドラは、様々なポータル・ベンダー間のコードの非互換性からファサードのユーザーを保護するインタフェースを提供するファサード・オブジェクトにアクセスできます。