|
|
この章では、連合ポータルの主体と論理部分について説明し、それらの対話方法について解説します。またこの章では、推奨されている多くのベスト プラクティスを、連合ポータルの開発者のために紹介します。「その他のトピックおよびベスト プラクティス」を読む前に、この章を再確認することをお勧めします。さらにこの章では、連合の基盤となっている主要な標準技術である WSRP (Web Services for Remote Portlets) について説明します。
連合ポータルの主体は、図 3-1 で示されているように、プロデューサ、コンシューマ、およびエンド ユーザです。
コンシューマは Web アプリケーションで、リモート ポートレットを収集し、それらを統合ポータルでエンド ユーザに提供します。エンド ユーザはブラウザを使用してポータルを表示し、ポータルと対話します。WebLogic Portal では、ポートレットを統合でき、さらにブックとページも統合できます。詳細については、「ブックとページの統合」を参照してください。
通常、コンシューマは、ポートレットのビジネス ロジック、データ、ユーザ インタフェース部分は内包しません。コンシューマが行うのは、プロデューサが配信するユーザ インタフェース マークアップを収集し、そのユーザ インタフェースをユーザに提供することだけです。
| ヒント : | 多くのビジネス ロジック処理はプロデューサ アプリケーションで実行されますが、インターセプタというコンシューマ側のクラスを記述することもできます。インターセプタを使用すると、WSRP メッセージの内容をプログラム的に検証し、その内容に基づいて特定のアクションを実行できます。インターセプタについては、「インターセプタ フレームワーク」で説明しています。 |
コンシューマは管理の中枢です。したがって、多くの時間コンシューマに係わるのは、通常は開発者ではなく管理者です。管理者は、リモート ポートレットの参照、使用、ユーザの管理、資格の設定などを担当します。
プロデューサも Web アプリケーションで、通常、コンシューマとは別のリモート システムで実行されます。プロデューサは、コンシューマ ポータルに提供されるポートレットのコンテナとして動作します。プロデューサは、リモート ポートレットのユーザ インタフェース、データ、およびビジネス ロジックを内包します。コンシューマが管理の中枢であるのに対し、プロデューサはアプリケーションの中枢です。したがって、開発者は実際のポートレット コードを記述し、それらのリソースをプロデューサにデプロイします。
| ヒント : | すべての WebLogic Portal アプリケーションは、デフォルトでは、コンシューマでもありプロデューサでもあります。したがって、すべての WebLogic Portal アプリケーションは、リモート ポートレットをホストでき、それらを使用できます。 |
プロデューサとコンシューマの詳細については、「プロデューサとコンシューマについて」を参照してください。
WebLogic Portal では WSRP プロトコルが拡張されており、ブックとページを統合する機能が組み込まれています。この機能は、統合する必要のあるポートレットが多数ある場合に便利です。ポートレットは、プロデューサ アプリケーションのブックおよびページにグループ化でき、グループ化すると、それらを 1 つずつ使用するのではなくグループとして使用できます。詳細については、「リモート ポートレット、ページ、ブックの作成」および「ライブラリへのリモート リソースの追加」を参照してください。
WSRP (Web Services for Remote Portlets) は、リモート ソースからのコンテンツとインタラクティブ Web アプリケーションを集約するための Web サービス プロトコルです。WSRP は、連合ポータルの基盤となる主要標準規格です。実質的に WSRP により、リモート ポートレット、分散しているポートレットを統合ポータル ページに実行時に結合することができます。
WSRP は、アプリケーション ロジックとプレゼンテーション ロジックの両方を提供します。これは、標準的な Web サービスやデータ指向の Web サービスとは異なる点です。これらの Web サービスの場合、ビジネス ロジックは組み込まれていても、プレゼンテーション ロジックがないため、すべてのクライアントがそれぞれにそのロジックを実装しなければなりません。
データ指向アプローチは多くの実装において効果を発揮しますが、ビジネス アプリケーションの動的な統合にはそれほど適していません。たとえば、注文ステータスの Web サービスをコマース ポータルに統合するには、ステータス サービスの結果をポータルに表示するコードを作成する必要があります。WSRP を使用すると、プレゼンテーション ロジックが Web サービスに組み込まれているため、アプリケーションとサービスの動的な集合が可能になります。これにより、統合用のプレゼンテーション ロジックを開発する必要はなくなり、注文ステータス サービスがポートレットとしてコマース ポータル内のあらかじめ決められた位置に表示されるように要求するだけで済みます。
| ヒント : | WSRP 標準の作成を担当しているのは、OASIS (Organization for the Advancement of Structured Information Standards) です。BEA Systems は、OASIS の WSRP 1.0 技術グループの積極的なメンバーであり、将来の仕様の拡充に向けてこの標準化の取り組みの一端を担っています。完全な技術仕様などの WSRP の詳細については、次のサイトを参照してください。http://www.oasis-open.org/committees/wsrp/ |
WSRP を理解する方法の 1 つは、他の Web プロトコル、HTTP と比較することです。最も普及している HTTP では、ブラウザを使用してリモート Web アプリケーションを表示し、それらのアプリケーションと対話します。ブラウザは、HTTP を使用してリモート HTTP サーバと通信し、(たとえば、フォームを送信することで) データを送信したり 、マークアップ (通常は HTML) を取得したりします。WSRP も、これと類似したプロトコルで、サーバ アプリケーションとクライアント アプリケーションの間で機能します。WSRP の用語では、サーバはプロデューサと呼ばれます。プロデューサは、クライアント (つまり、コンシューマ) の通信相手であるサービス (通常はポートレット) をホストします。
コンシューマは、HTTP のブラウザと同じく、マークアップを取得して、ユーザの対話をプロデューサに送信します。プロデューサは実際のポートレットをホストし、一方コンシューマはそれらのポートレットのプロキシを内包します。コンシューマは、WSRP を使用してリモート ポートレットからマークアップを収集し、エンド ユーザに提供します。エンド ユーザはそのマークアップを使用して対話を行います。エンド ユーザ側では、リモート ポートレット、またはプロキシ ポートレットとローカル ポートレットは区別されません。
ただし、WSRP コンシューマはブラウザより高機能です。コンシューマは、ブラウザと異なり、以下を実行できます。
つまり、WSRP プロトコルでは、WSRP プロデューサが実装する一連の Web サービスが定義されています。コンシューマはこれらの Web サービスを表示し、これらの Web サービスと対話します。つまりコンシューマは、プロデューサからユーザ インタフェースの断片を取得し、その断片を表示し、ユーザがそれらの断片と対話できるようにします。WSRP プロトコルにより、プロデューサがホストするアプリケーションのクライアントとしてコンシューマは動作できます。
この節では、WebLogic Portal のプロデューサとコンシューマの実装について説明します。この節では、次のトピックについて説明します。
プロデューサは、ポートレットをホストするコンテナ Web アプリケーションです。コンシューマは、プロキシ ポートレットを介して、リモート ポートレット (プロデューサがホストするポートレット) を収集しユーザに提供します。すべてのアプリケーション コード (ページ フロー、バッキング ファイル、Java クラス、コントロール、EJB など) はプロデューサ側にあります。コンシューマが行うのは、マークアップの断片をプロデューサから受信することだけで、これらは収集されユーザに提供されます。
図 3-2 は、連合ポータルのコンポーネントを図で表したものです。WebLogic Portal の WSRP 実装では、パーソナライゼーション、カスタマイズ、ユーザ管理などの、通常の WebLogic Portal サービスを追加できます。したがって、リモート ポートレットで、ローカル ポートレットと同じルック アンド フィールを利用でき、またローカル ポートレットと同じレベルのポータル セキュリティを利用できます。
| ヒント : | すべての WebLogic Portal にプロデューサ実装とコンシューマ実装の両方が含まれます。つまり、すべての WebLogic Portal がプロデューサおよびコンシューマとして機能できます。WebLogic Portal のプロデューサ実装およびコンシューマ実装の技術的な詳細については、dev2dev の Web サイトにある技術関連のホワイト ペーパー「インサイド WSRP」を参照してください。 |
WebLogic Portal は、単純なプロデューサと複雑なプロデューサの 2 種類をサポートしています。これら 2 種類のプロデューサについて説明する前に、WSRP プロトコルのパーツ、プロデューサに実装する必要のある処理 (必須処理)、オプションの処理について理解しておく必要があるのでそちらを先に説明します。
表 3-1 は、WSRP プロトコルが定義している必須処理とオプション処理のリストです。WSRP 対応のプロデューサでは、必須サービスの説明処理とマークアップの処理を最低限実装する必要があります。ご覧のように、WebLogic Portal の単純なプロデューサと複雑なプロデューサは、サポートする処理の種類が異なります。
単純なプロデューサは、WSRP プロトコルの基本機能のみをサポートします。これらの基本機能を使用する場合、プロデューサを完全な WebLogic Portal ドメインにデプロイする必要はありません。たとえば、単純なプロデューサは、基本 WebLogic Server ドメインにデプロイできます。
| ヒント : | WebLogic Server ドメインでの単純なプロデューサのコンフィグレーションについては、「WebLogic Server プロデューサのコンフィグレーション」を参照してください。 |
このような制限があるにもかかわらず、次の理由により単純なプロデューサを使用する必要がある場合があります。
「基本的な WebLogic Server ドメインでの WSRP の使用」の節では、(非ポータル) WebLogic Server 環境を WSRP プロデューサとしてコンフィグレーションして、Struts または Java ページ フローに基づいてポートレットを公開できるようにする方法を説明しています。公開されたポートレットは、通常の WebLogic Portal ドメインで実行中のリモート ポートレットとして利用できます。
複雑なプロデューサは、WSRP 1.0 プロトコルを完全サポートし、さらにポートレット間通信、ポートレットのルック アンド フィールなどの拡張機能もサポートします。また複雑なプロデューサでは、パーソナライゼーション、カスタマイズ、ユーザ管理セキュリティ機能などの、その他の WebLogic Portal 機能も利用できます。これに対して、単純なプロデューサでは、これらの WebLogic Portal 機能は利用できません。
デフォルトでは、すべての WebLogic Portal アプリケーションが複雑なプロデューサです。複雑なプロデューサで公開されるポートレットは、WebLogic Portal アプリケーションで利用できる API と機能を使用できます。
| ヒント : | プロデューサにデプロイするポートレットで API の呼び出しを使用するのが不適切な場合があります。これは、ブックおよびページなどの、コンシューマ アプリケーションにデプロイするポータル アーティファクトにプロデューサがアクセスできないからです。プロデューサのポートレットを開発するためのプログラミングのベスト プラクティスについては、「その他のトピックおよびベスト プラクティス」を参照してください。 |
/WEB-INF/wsrp-producer-config.xml ファイルの <registration required> 要素を false に設定することで、登録を無効にできます。 /WEB-INF/wsrp-producer-config.xml ファイルの <portlet-management required> 要素を false に設定することで無効にできます。
複雑なプロデューサは、必須 WSRP インタフェース、オプション インタフェース、および拡張インタフェースを内包します。単純なプロデューサは必須インタフェースを実装します。複雑なプロデューサでは WebLogic Portal が必要ですが、単純なプロデューサは基本 WebLogic Server ドメインにデプロイできます。図 3-3 は、これらの関係を図で表したものです。
表 3-2 は、標準プロデューサの機能と複雑なプロデューサの機能を比較した表です。
先にも述べたように、すべての WebLogic ポータルは、デフォルトでリモート ポートレットを使用できます。WebLogic Portal コンシューマの実装は、WebLogic Portal フレームワームに厳密に統合されています。
プロデューサ上でホストされるリモート ポートレットを使用するには、プロデューサが提供するポートレットに関する情報を、コンシューマからプロデューサに要求する必要があります。最初にコンシューマは、プロデューサの WSDL URL を使用してプロデューサに接続します。この最初の接続で、プロデューサとそのサービスが利用可能かどうか確認されます。次にコンシューマは、プロデューサが提供するポートレットの説明をプロデューサに要求します。プロデューサは、プロデューサが提供するポートレットと関連するメタデータについて説明した SOAP メッセージを使用してコンシューマに応答します。この通信を図で表したものが図 3-4 です。
プロデューサにデプロイされているポートレット、ブック、およびページを検出するための WSDL URL を、必ずしも把握しておく必要はありません。WebLogic Portal には、リモート プロデューサのポートレットを、メタデータ キーワードを使用して検出できる検索機能が備えられています。これらの検索の基盤となっている技術は、UDDI (Universal Description、Discovery and Integration) レジストリと呼ばれています。UDDI は広く知られている標準技術です。Administration Portal では、図 3-5 のように、プロデューサのポートレットを名前で検索できます。
この検索ツールを使用すると、プロデューサとプロデューサが提供するポートレットを検索できます。
コンシューマがプロデューサのメタデータを受信すると、メタデータはコンシューマに追加され、リモート ポートレットを作成できるようになります。リモート ポートレットは、プロデューサでホストされるポートレットのプロキシです。リモート ポートレットがポータルまたはデスクトップに追加されると、WebLogic Portal フレームワークは WSRP プロトコルを使用してポートレットをポータル ユーザに提供します。ユーザにとっては、リモート ポートレットのルック アンド フィールはローカル ポートレットと同じです。提供されたポートレットがリモートでホストされていることにユーザは気付きません。さらに、リモート ポートレットは、それらが常駐するポータルから特定のスタイル、レイアウト、およびテーマを継承します。ユーザにとって、この統合はシームレスです。
| ヒント : | 先にも述べたように、WebLogic Portal では、インターセプタというコンシューマ側のクラスを作成できます。インターセプタを使用すると、WSRP メッセージの内容をプログラム的に検証して、その内容に基づいて特定のアクションを実行できます。インターセプタについては、「インターセプタ フレームワーク」で説明しています。 |
WebLogic Portal コンシューマは、RFC2109 の規定に従いクッキーを処理します。
NAME が前のクッキーと同じで、Domain 属性値および Path 属性値が前のクッキーのこれらの属性値と正確に (文字列的に) に一致する Set-Cookie 応答ヘッダにより、古いクッキーが新しいクッキーに置き換えられます。Set-Cookie の Max-Age 値が 0 の場合、古いクッキーおよび新しいクッキーは破棄されます。portletHandle およびエンド ユーザ (コンシューマはこれらのユーザのためにプロデューサを呼び出します) に固有で、この特定のペアに対してのみ再提供可能です (ServiceDescription.requiresInitCookie=perGroup の場合、portletHandle は initCookie() から返されるクッキーのグループの 1 つに属します)。
リモート ポートレットは、明確なライフサイクルを経過します。次のシナリオのうちのどれが要求されたかに基づき、このライフサイクルの手順は実行されます。
重要なのは、これらのライフサイクルの段階が相互に分離していることを理解することです。この節で後ほど説明しますが、開発者がプロデューサでホストされるポートレットを記述する場合、この分離を考慮する必要があります。たとえば、表示段階でポータルは対話段階と同じ HTTP 応答またはリクエストを受信するとは限りません。
この節では、インターセプタでリモート ポートレットのライフサイクルに影響を及ぼす方法については説明しません。インターセプタは WSRP メッセージをインターセプトするコンシューマ側のクラスで、それらのメッセージの内容に基づき特定のアクションをプログラム的に実行できます。インターセプタについては、「インターセプタ フレームワーク」で説明しています。
| ヒント : | この節では、「その他のトピックおよびベスト プラクティス」で説明されているベスト プラクティスの多くを開発者のために紹介します。プロデューサのポートレットを作成する開発者にとって、リモート ポートレットのライフサイクルを理解することは特に重要です。このライフサイクルを理解すると、根拠のない推定を行わないようにしたり、一般的な誤りを回避したりできます。 |
表示は、リモート ポートレットのユーザ対話とは無関係に発生します。表示段階では、リモート ポートレットの状態は変更できません。たとえば、ポータル ページが更新されると表示が発生します。
たとえば、フォームを送信したり、リンクをクリックしたりすることで、ユーザがリモート ポートレットと対話すると、対話段階が発生します。
イベントが発生すると、リモート ポートレットの 3 番目のライフサイクルが発生します。イベントは、リモート ポートレットのポートレット間通信の最適なメカニズムです。
プロデューサにデプロイされたポートレットが表示依存関係を持つと、リモート ポートレットの 4 番目のライフサイクルが発生します。
| ヒント : | この節では、リモート ポートレットのライフサイクルの段階について概説します。このテーマの技術的な詳細については、dev2dev の Web サイトにある BEA ホワイト ペーパー「インサイド WSRP」を参照してください。 |
リモート ポートレットがコンシューマ ポータルに表示されると、明確な一連の手順が必ず発生します。ポートレットをまったく同じ状態で再表示する必要がある場合 (たとえば、ユーザが単にページを更新する場合)、表示段階が必ず実行されます。ユーザがリモート ポートレットと直接対話すると、対話段階という異なる段階がトリガされます。対話段階については次の節で説明します。
通常の (連合でない) Web アプリケーションの場合、たとえばリクエストを JSP に送信すると、リクエストしたページのマークアップが返され、それらを受信します。連合ポータルでは、プロデューサがホストするポートレットからマークアップ断片が返され、それらが 1 つのページに構成されてユーザに表示されます (または、ローカル ポートレットとプロデューサにデプロイされているポートレットが混在したページが表示されます)。コンシューマの仕事は、プロデューサに接続すること、マークアップを取得すること、統合ポータル ページにそれを表示することです。
図 3-6 では、ポートレットがプロデューサ上に存在し、そのポートレット (リモート ポートレット) のプロキシがコンシューマ ポータル上に作成されています。次の節では、コンシューマにポートレットを表示するのに必要な一連の手順をリストし、それらについて説明します。
コンシューマは、リモート ポートレットを表示するために、最初に SOAP メッセージを構成してプロデューサに送信する必要があります。これらの初期手順は、次のとおりです。
コンシューマの最初の仕事は、プロデューサのメタデータを検索することです。開発者または管理者がリモート ポートレットを作成すると、(コンシューマ上の) WebLogic Portal は各プロデューサについてのメタデータを受信し、内部に保存します。
ブラウザが Web サーバのクライアントとして動作するように、コンシューマはプロデューサのクライアントとして動作します。たとえば、ブラウザはサーバ上のセッションを追跡するクッキーを保持します。同じように、コンシューマは、ポータルの各ユーザのプロデューサ セッションを追跡するクッキーを保持します。コンシューマは、コンシューマと対話するユーザごとに、各プロデューサとのセッションを 1 つ保持します。
プロデューサは、コンシューマから SOAP メッセージを受信した後、次の手順に従い要求されたポートレットを表示し、ポートレットのマークアップをコンシューマに返す必要があります。
手順 1、2、および 3 で、プロデューサはポートレットの HTTP 環境を作成します。プロデューサは、HTTP リクエストではなく SOAP リクエストを受信するため、SOAP リクエストから情報を取得し、ポートレットの適切な HTTP 環境 (サーブレット リクエスト オブジェクトと応答オブジェクト、セッション、ポートレット状態など) を再作成する必要があります。
プロデューサは、複雑な機能を提供するかどうかを決定する必要があります。WebLogic Portal は WSRP 拡張機能とオプション インタフェースを実装しています。これらの拡張機能とオプションにより、WebLogic Portal プロデューサは、ユーザ管理、資格、ポートレット プリファレンス、イベント処理などの機能を提供できます。場合によっては、これらの拡張機能なしのプロデューサ ポータルをデプロイする必要がある場合があります。したがって、プロデューサは、これらの機能を有効にするかどうかを決定する必要があります。単純なプロデューサと複雑なプロデューサについては、「プロデューサとコンシューマについて」を参照してください。
従来の Web アプリケーションでは、たとえば、JSP ページの URL は JSP ページをホストする Web サーバを常に参照します。連合ポートレットでは、URL はプロデューサではなくコンシューマを常に参照します。これは、プロデューサが実際にはユーザ クライアントにアクセスできない場合があるからです。プロデューサは、たとえば、ファイアウォールの背後に配置されている場合があります。プロデューサは、URL を適切に管理するために、コンシューマを参照する URL の作成方法を把握している URL リライタを内包しています。
| ヒント : | プロデューサのポートレットを開発する場合、必ず WebLogic Portal API とタグを使用して URL を作成してください。これらの API とタグは、連合環境で適切に機能する URL の生成方法を把握しています。詳細については、「URL による結合の回避」を参照してください。 |
この段階で、プロデューサはポートレットを表示します。プロデューサによりポートレットの新しいセッションが作成されている場合、または新しいクッキーが追加されている場合があります。プロデューサはこれらの情報をすべて収集し、コンシューマへの応答を生成します。
コンシューマは、プロデューサ マークアップ断片をプロデューサから受信します。コンシューマはこれらの断片を使用して、ユーザに表示できるポータル ページを構成する必要があります。これを行うために、コンシューマは次の最終手順を実行します。
このサイクルは、コンシューマのキャッシュが無効であれば、ポートレットが表示されるたびに実行されます。
前の節で説明した表示ライフサイクルと同じく、リモート ポートレットとの対話も明確な一連の手順に従います。たとえば、ユーザがページ フロー ポートレットを介してフォームを送信すると、対話が発生します。通常、プロデューサ上の JSP は、ビジネス ロジックの実行などバックグラウンド アクションを実行し、応答を準備します。
ご覧のように、リモート ポートレット対話で実行される手順は、単純な表示で実行される手順とほぼ同じです。図 3-7 で強調表示されているのが異なる点で、この節で説明します。
| ヒント : | 重要なのは、リモート ポートレット ライフサイクルの表示段階と対話段階は分離しているということを理解することです。この分離は、プロデューサのポートレットの開発方法に大きく影響します。表示段階においてポータルは、対話後に受信した HTTP 応答またはリクエストと同じ HTTP 応答またはリクエストを受信するとは限りません。このことに関する詳細およびその他の実用的なアドバイスについては、「その他のトピックおよびベスト プラクティス」を参照してください。 |
ユーザがリモート ポートレットと対話するとき、コンシューマは最初に SOAP メッセージを構成してプロデューサに送信する必要があります。これらの初期手順は次のとおりです。太字で示された手順は、すでに説明した表示段階の手順と異なります。
プロデューサは、コンシューマから SOAP メッセージを受信した後、次の手順を実行してポートレット アクションを呼び出し、要求されたポートレットのマークアップを生成し、そのポートレットのマークアップをコンシューマに返す必要があります。太字で示された手順は、すでに説明した表示段階の手順と異なります。
この手順では、コンシューマが送信したアクションをプロデューサでリプレイする必要があります。プロデューサは、このアクションを要求した送信元を直接的には認知しません。ビジネス ロジックの実行後、ロジックの結果を表示するページを準備する必要があります。たとえば、ユーザがログイン フォームを送信した場合、ログインが成功した後、ポートレットはログインが成功したことをユーザに知らせる別のページを返す必要があります。
リクエストの処理後、プロデューサはポートレットの状態に対する変更を収集する必要があります。この状態は、コンシューマが収集してエンド ユーザに表示できる、マークアップ断片の形式でコンシューマに返されます。
太字で示された手順は、すでに説明した表示段階の手順と異なります。
このサイクルは、コンシューマのキャッシュが無効であれば、ポートレットが表示されるたびに実行されます。
表示段階と対話段階はどちらもリモート ポートレットで実行可能です。ユーザがポートレットと直接対話しないけれども、ポートレットの更新が必要な場合、表示段階が必要です。たとえば、ユーザがページ上の 1 つのポートレットと対話する場合、ページ上の他のポートレットを変更したり非表示にしたりする必要はありません。
表示段階はユーザの対話で必ずしも駆動されるわけではないので、冪等です (プロデューサは、コンシューマが送信したポートレット状態と同じポートレット状態を返します)。単にページを更新する場合、データベースからデータを再生成する必要はないので、これは適切です。同様に、表示段階では、モードと状態の変更は許可されていません。
| ヒント : | 分離した表示段階および対話段階はリモート ポートレットに固有のものではありません。ローカル ポートレットも同様に表示段階と対話段階を組み込んでいます。 |
表 3-3 は、これらの 2 つの段階の特徴をまとめたものです。これらの 2 つの段階が分離しているのは、ポートレットと対話する場合に限り、ポートレットの状態を変更できるようにするためです。たとえば、ポートレット A からフォームを送信し、その後同じポータル ページのポートレット B と対話する場合、ポートレット A の状態またはビューをポートレット B の更新時に変更する必要はありません。ポートレットの状態は、そのポートレットと直接対話する場合に限り変更する必要があります。対話段階は必ずユーザ対話によって駆動されます。一方、表示段階は、任意の回数だけ発生させることができ、駆動も任意です。
イベントによるポートレット間の通信を可能にするために、WebLogic Portal では、WSRP プロトコルが拡張され、リモート ポートレットのライフサイクルに 3 番目の段階が追加されています。この拡張により、ポートレットは対話段階でイベントを開始できます。イベントはリモート ポートレットに登録できます。ただし、プロキシ ポートレットがイベントを受信した場合、プロキシ ポートレットはプロキシであるため、そのイベントをローカルで処理できません。リモート ポートレットは、イベントをプロデューサに送信して、プロデューサにそのイベントを処理してもらう必要があります。その後、プロデューサ上のポートレットがイベントを開始し、プロデューサがそれを必要に応じて処理します。
| 注意 : | WebLogic Portal IPC フレームワークは場所に依存しません。つまり、このフレームワークでは、どこでイベントが発生するかは問題ではありません。コンシューマのポートレットとプロデューサのポートレットは、どちらもイベントをリスンおよび開始できます。 |
この段階は対話段階とほぼ同じです。主な違いは、対話段階では、ポートレットはユーザ対話データを取得し、応答でポートレットのナビゲーション状態を変更する点です。ポートレットはイベントを開始することもできます。
イベント処理段階では、ポートレットはユーザ対話を受信するのではなく、別のコンポーネントが起動したイベントを必ず取得します。プロデューサは、イベントへの応答で、ポートレットの状態を変更でき、またさらにイベントを生成できます (イベント チェーンに保存されます)。プロデューサがイベントを生成すると、このサイクルが繰り返されます。
WebLogic Portal では、個々のポートレットに関連する特定の依存関係を指定できます。依存関係は、通常、カスケーディング スタイル シート (CSS ファイル) と、JavaScript (JS) ファイルなどのスクリプト ファイルが関連します。ポートレットの依存関係は、.portlet ファイルが参照する XML ファイルでコンフィグレーションします。この依存関係ファイルには、ポートレットが依存する CSS ファイルおよびスクリプト ファイルが明示的にリストされます。
WebLogic Portal では WSRP プロトコルが拡張されているため、リモート ポートレットはプロデューサから表示依存関係を取得できます。
WebLogic Portal アプリケーションは、簡単に言うと、コンシューマとプロデューサの両方の役割を実行することも、どちらか一方の役割を実行することもできます。WebLogic Portal は、以下を処理するようにコンフィグレーションされます。
図 3-9 は、エンド ユーザ、コンシューマ、およびプロデューサ間のアクションの流れを表したシーケンス線図です。この図では、プロデューサとエンド ユーザ間の仲介役としてコンシューマが動作する場合の概念が強調表示されています。
WSRP の WebLogic Portal 実装の技術的な詳細については、次に示す BEA の技術関連のホワイト ペーパーを参照してください。
この BEA ホワイト ペーパーは、コンシューマとプロデューサ間で発生するメッセージングについて詳細に説明しており、またプロデューサでホストされるポートレットを記述する開発者のために、ベスト プラクティスに重点を置いています。
このドキュメントの目的は、WSRP 1.0 仕様の主要概念についてチュートリアル形式で説明することです。このドキュメントは、OASIS (Organization for the Advancement of Structured Information Standards) が管理しています。OASIS は WSRP 標準の作成を担当しています。BEA Systems は、OASIS の WSRP 1.0 技術グループの積極的なメンバーであり、将来の仕様の拡充に向けてこの標準化の取り組みの一端を担っています。
  
|
