WSRP(Web Services for Remote Portlets)入門

SOA(Service-Oriented Architecture)でWSRPを使う

WSRP(Web Services for Remote Portlets)を紹介しましょう。WSRP仕様は、ポータル・アプリケーション内にマークアップ断片を生成する、SOAPベースのWebサービスを強化する方法を定義しています。WSRPでは一連の共通アプリケーションを定義しており、これを利用すれば、ポータル開発者が何ら追加プログラミングを行わなくとも、リモートで実行しているポートレットを、そのポータルのページで実行できるようになります。エンドユーザーから見ると、そのポータル内でポートレットが実行しているように見えますが、実際には、ポートレットはリモートで実行しているポートレット・コンテナーの中にあり、その対話動作はSOAPメッセージの交換を通して行われます。SOA(Service-Oriented Architecture)とWSRPの組み合わせは強力であり、追加的な開発やデプロイ活動を行うことなく、プレゼンテーション指向のポートレット・アプリケーションを発見し、再利用することができるようになります。

Bryan Castle (castle_bryan@bah.com), Senior Consultant, Booz Allen Hamilton

Bryan CastleはBooz Allen Hamiltonのシニア・コンサルタントです。専門は、SOA(Service-Oriented Architecture)や、J2EEプラットフォームを使用した分散コンピューティングなど、Webベースの技術ソリューションの開発です。



2005年 4月 15日

WSRPと、その関連技術を見る

ここ数年の間に、SOA(Service Oriented Architecture)という言葉は流行語になりましたが、その概念には、基本的に特別新しいものはありません。SOAは多くの場合、技術コミュニティーの中で取り上げられますが、エンドユーザーに与える影響はどうなのでしょうか。エンドユーザーは、自分が必要とするWebサービスを見つけるために、サービス・ディレクトリーをクエリーするでしょうか。さらに、エンドユーザーがWebサービスの存在を知っていたとしても、どのようにそのWebサービスと通信するのでしょう。Webサービスと対話動作するクライアントやUIを書くのでしょうか。答えはおそらく「ノー」でしょう。ではSOAは、サービスに対するエンドユーザーにとって、直接的な何か利益があるのでしょうか。これも、おそらく「ノー」でしょう。いやつまり、これまでは、「ノー」だったのです。WSRPは新興技術として、最近では、IBM®やBEA、Oracle、Microsoft® などポータル市場で活動する主要な会社すべてを含め、業界としてのサポートを獲得しつつあります。WSRPが最終的な目標としているのは、WebサービスとSOAの利点を、エンドユーザーにもたらすことです。

WSRP仕様は、技術標準の採用を促進するための協議会であるOASIS(Organization for the Advancement of Structured Information Standards)の活動の成果です。WSRPのバージョン1.0仕様は、2003年8月に最終版がまとまり、現在は、2005年中頃に発行予定のバージョン2.0に向けた作業が行われています。ポータル市場で活動する主要な会社すべてがOASISのWSRP Technical Committeeに参加しているため、WSRP技術は今後も業界で広く受け入れられるはずです。OASISのWSRP仕様では、プラグ可能な、プレゼンテーション指向のWebサービスと通信するための、共通な、適切に定義されたインターフェースを定義しています。こうしたサービスは、ユーザーとの対話動作を処理し、ポータルが集約するためのマークアップ断片を提供します。

上記の定義で使用した、重要な用語の幾つかには、特に注意する必要があります。まず、サービスがプレゼンテーション指向である、ということは、そのサービスが、エンドユーザーが直接やり取りできるユーザー・インターフェースを提供する、ということを意味します。これは、プログラム的なレベルでリクエストを処理し、レスポンスを生成するような、これまでのWebサービスとは劇的に異なります。この仕様では第二として、ポータルがサービスと通信し、エンドユーザーにページを表示するために必要なマークアップ断片を収集するための方法を規定する、共通な、適切に定義されたインターフェースを定義しています。正にこの共通インターフェースによって、リモートのコンテナーで実行しているポートレットを、ポータル・アプリケーションが汎用的に利用できるのです。

WSRPは、SOAPやWSDL、UDDI(参考文献)など、既存のWebサービス標準の上に構築されていることに注意してください。この記事では、最も一般的なWSRP使用シナリオ(つまりポータル内で利用されるHTMLマークアップ断片の生成)に焦点を当てますが、これはWSRPが他のマークアップ言語をトランスポートできないことを示すわけではありません。図1は、こうした技術スタックの中におけるWSRPの位置づけを示しています。

図1. WSRPは既存のWebサービス技術の上に存在する
図1. WSRPは既存のWebサービス技術の上に存在する

ポータルとポートレットを定義する

WSRPの世界に飛び込む前に、ポータルとポートレットという用語が、具体的に何を意味するかを明確にしておくべきでしょう。ポータルの定義は、解釈の仕方によって変わってきます。10人のソフトウェア技術者に聞けば、それぞれ異なる10の定義が返ってきます。この記事でのポータルとは、ポータルのルック・アンド・フィールも、ポータルに含まれるコンテンツやアプリケーションも、どちらもエンドユーザーがカスタム化できるようなWebベースのアプリケーション、と考えることができます。さらにポータルは、コンテンツやアプリケーションのアグリゲーターとして、あるいはユーザーのツール・セットやアプリケーションへの単一エントリー点と考えることもできます。

これでポータルが何かは分かりましたが、ではポートレットとは具体的に何なのでしょう。ポートレットは、ポータル・ページの内部で任意数の類似の実体と共に実行している、ミニチュアのWebアプリケーションと考えることができます。ポートレットは、コンテナーによって管理されるWebコンポーネントであり、リクエストを処理でき、動的コンテンツを生成することができます。ポートレットには、標準に基づくものと、そのポートレットをホストするポータル独自のものという、2種類があります。2003年10月に承認されたJava Portlet Specification (JSR-168) では、J2EEベースのポータル・プラットフォームのためのAPIを定義しています。JSR-168の目標は、JSR-168準拠の任意のポートレットが、JSR-168仕様をサポートする任意のポータルにデプロイできるように、一連の標準を提供することです。図2は、通常のポータル・モデルを示しています。ポータルは、任意の数の別々なポートレットをホストするポートレット・コンテナーを持っています。こうしたポートレットはそれぞれマークアップ断片を生成し、最終的にポータルがこれらをつなぎ合わせ、エンドユーザーに表示される完全なページを作ります。

図2. ローカル・ポートレットからマークアップを集約するポータル
図2. ローカル・ポートレットからマークアップを集約するポータル

なぜWSRPが必要なのか

Webサービスが、プラットフォームに依存しないサービスを構築するための機構を提供するのであれば、そして、JSR-168がポートレットを開発するための標準を定義するのであれば、なぜWSRPが必要なのでしょう。答えは単純です。Webサービスでは、バックエンド・サービスを再利用できますが、WSRPでは、ユーザー・インターフェース全体を再利用できるのです!

例えば、ポータルのエンドユーザーに対して、相場記号を入力することで株価を見られる機能を提供したいとしましょう。皆さんは、正にこの機能を提供するWebサービスが、おそらく既に存在していることを知っています。このサービスを行うWebサービスのUDDIレジストリーの中で、株価参照サービスを検索することができます。そうしたサービスが見つかったら、次に、そのWebサービスを利用し、そのWebサービスにバインドすべきクライアントをコード化する必要があります。また、ポータルのユーザーがサービスと対話動作できるような、ポートレットを開発する必要があります。Webサービス・ツールキットを使うことによって、Webサービス・クライアントの開発は比較的楽にできるかも知れませんが、ユーザー・インターフェースの開発は簡単ではありません。さらに、新たに開発したポートレットとWebサービス・クライアントを、ポータル・サーバーにデプロイするというプロセスが待っています。エンドユーザーに対して株価参照サービス機能を提供するために、一日中、相当な量の新コードを開発し、コンパイルし、デプロイする羽目になるのです。サードパーティーが開発した株価参照サービスを利用すれば、開発時間は削減できますが、ポータル・ユーザーが使えるようにするためのフロントエンド・アプリケーションの開発、デプロイのプロセスは、面倒な上、非常に時間がかかるのです。

同じ例をWSRPを使って構築すると、ずっと容易に、ポータルの中に株価参照ポートレットを統合できます。ポートレット自体を探してUDDIディレクトリーをブラウズするか、あるいは、ポートレットのレジストリーをブラウズできるような機能をエンドユーザーに提供すればよいのです。いったんStock Quote Portlet(株価参照ポートレット)が見つかりさえすれば、それをポータルに追加するのは、マウスを2、3回クリックするだけです。ポートレットはWSRPを通して使用されるため、カスタム・コーディングやデプロイ活動は全く必要ありません。エンドユーザーはWSRPについて何も理解する必要がなく、ポートレットが実際にはリモートのプロデューサーによってホストされていることすら知る必要がないのです。エンドユーザーが知っているのは単に、使用可能なポートレットのディレクトリーがあり、そこから適当なものを選択できる、ということだけです。これ以上簡単なものがあるでしょうか。


WSRP、その背後にあるもの

WSRPの登場者

WSRPが実際にどのように動作するかを説明する前に、WSRPアーキテクチャーの中にある、様々な可動部品について簡単に調べてみましょう。下記の図3は、WSRPアーキテクチャーにおける主な登場者のそれぞれと、マークアップ断片を集約する上でポータルが果たす役割を説明しています。この図のポータルは、1つのプロデューサーからのWSRPポートレットのみを使用していますが、任意数の生成側からのWSRPポートレットをポータルが使用できない理由は何もありません。WSRP仕様では、WSRPアーキテクチャーの中に登場する者として、下記を定義しています。

  • WSRPプロデューサー: WSRPプロデューサーは1つ以上のポートレットを提供し、一連のWSRPインターフェースを実装するWebサービスであり、これによってコンシューマーに対し、共通のオペレーション・セットを提供します。プロデューサーは実装によって、1つのポートレットのみを提供する場合もあれば、幾つかのポートレットをデプロイ、管理するためのランタイム(またはコンテナー)を提供する場合もあります。WSRPプロデューサーは真のWebサービスであり、WSDLと一連のエンドポイントが完全に揃っています。WSRPでのプロデューサーはそれぞれ、標準のWSDL文書を使って記述されます。
  • WSRPポートレット: WSRPポートレットは、WSRPプロデューサー内部に生存する、プラグ可能なユーザー・インターフェース・コンポーネントです。そして、そのプロデューサーが定義するインターフェースを通して、リモートからアクセスされます。WSRPポートレットは、自明なWebサービスではありません(直接アクセスすることはできず、その親のプロデューサーを通してアクセスしなければなりません)。
  • WSRPコンシューマー: WSRPコンシューマーはWebサービス・クライアントとして、プロデューサーが提供するWSRP Webサービスを呼び出し、またそうしたプロデューサー(1つまたは複数)が提供するポートレットとエンドユーザーが対話動作できるような環境を提供します。WSRPコンシューマーの最も一般的な例は、ポータルです。
図3. リモート・ポートレットからマークアップを集約するためのWSRPコンシューマーとして動作するポータル
図3. リモート・ポートレットからマークアップを集約するためのWSRPコンシューマーとして動作するポータル

WSRPインターフェース

WSRPは、先に少し触れた通り、全てのWSRPプロデューサーが実装すべき、そしてリモートで実行しているポートレットとWSRPコンシューマーが対話動作するために使用すべき、共通インターフェース・セットを定義しています。こうしたインターフェースを標準化することによって、リモートで実行しているポートレットとポータルが、汎用的に対話動作できるようになります。このインターフェースが、WSRP準拠の任意のプロデューサーと通信するための、よく定義された機構となっているためです。WSRP仕様では、全てのプロデューサーが実装すべきインターフェースとして、2つの必須インターフェースと、2つのオプション・インターフェースを規定しています。

  • サービス記述インターフェース(Service Description Interface、必須): WSRPプロデューサーはサービス記述インターフェースを使って、潜在的なコンシューマーに対して機能を宣伝することができます。WSRPコンシューマーは、このインターフェースを使ってプロデューサーをクエリーし、プロデューサーがどのようなポートレットを提供するのか、またプロデューサー自体に関する追加的なメタデータを発見します。このインターフェースは、提供されている一連のポートレットを発見するための機構として動作するだけではなく、コンシューマーがこのインターフェースを利用して、プロデューサーの技術的機能に関する追加情報を判定することもできるのです。プロデューサーのメタデータに含まれる情報の中には、プロデューサーが提供する任意のポートレットとコンシューマーが対話動作を始める前に、プロデューサーが登録やクッキーの初期化を要求するか否かについての情報が含まれる場合もあります。
  • マークアップ・インターフェース(Mark-up Interface、必須): WSRPコンシューマーはマークアップ・インターフェースを使うことによって、WSRPプロデューサー上でリモート実行しているポートレットと対話動作することができます。例えば、コンシューマーはこのインターフェースを使って、エンドユーザーがポータル・ページからフォームを送信する時に、対話動作を実行することができます。あるいは単純に、ポータルが、ポートレットの現在の状態に基づいた最新のマークアップを入手する必要があるかも知れません(例えばユーザーが『更新』をクリックした場合や、同じページの別のポートレットとの対話動作が起こった場合など)。
  • 登録インターフェース(Registration Interface、オプション): WSRPプロデューサーは登録インターフェースを使うことによって、WSRPコンシューマーがサービス記述インターフェースやマークアップ・インターフェースを通してサービスと対話動作する前に、何らかの登録を行うようにWSRPコンシューマーに要求することができます。この機構によって、プロデューサーは特定なタイプのコンシューマーに合わせて、振る舞いをカスタム化することができます。例えばプロデューサーは、提供された一連のポートレットを、ある特定なコンシューマーに合わせてフィルターにかけることができます。さらに登録インターフェースは、プロデューサーとコンシューマーが対話を開始し、お互いの技術機能に関する情報を交換するための機構として動作します。
  • ポートレット管理インターフェース(Portlet Management Interface、オプション): WSRPコンシューマーはポートレット管理インターフェースを使うことによって、リモートで実行しているポートレットのライフサイクルにアクセスできるようになります。コンシューマーはこのインターフェースを利用することによって、ポートレットの振る舞いをカスタム化することができ、あるいはリモートで実行しているポートレットのインスタンスを破棄することさえできます。

リスト1は、必須インターフェースとオプション・インターフェースの両方をサポートするサービスのWSDL定義の例です。

リスト1. WSRPサービスに対するWSDL定義の例
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:urn="urn:oasis:names:tc:wsrp:v1:bind" 
                  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                  targetNamespace="urn:myproducer:wsdl">
  <wsdl:import namespace="urn:oasis:names:tc:wsrp:v1:bind" 
        location="http://www.oasis-open.org/committees/wsrp/
        			specifications/version1/wsrp_v1_bindings.wsdl"/>
  <wsdl:service name="WSRPService">
    <wsdl:port name="WSRPBaseService" 
    	       binding="urn:WSRP_v1_Markup_Binding_SOAP">
	<soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
	              location="http://myproducer.com:7007/portal/producer"/>
    </wsdl:port>
    <wsdl:port name="WSRPServiceDescriptionService" 
               binding="urn:WSRP_v1_ServiceDescription_Binding_SOAP">
	<soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
	              location="http://myproducer.com:7007/portal/producer"/>
    </wsdl:port>
    <wsdl:port name="WSRPRegistrationService" 
               binding="urn:WSRP_v1_Registration_Binding_SOAP">
	<soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
		      location="http://myproducer.com:7007/portal/producer"/>
    </wsdl:port>
    <wsdl:port name="WSRPPortletManagementService" 
               binding="urn:WSRP_v1_PortletManagement_Binding_SOAP">
        <soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
		      location="http://myproducer.com:7007/portal/producer"/>
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

UDDIレジストリーを使用してポートレットを見つける

ポータルを使用する主な利点の一つは、ポータルのユーザーが、自分が利用したいように一連のアプリケーション(ポートレット)をカスタム化できることです。ユーザーは独自のページを作り、そのユーザーが必要と判断する、新しいポートレットを追加することができます。ところが、ユーザーがポータルをカスタム化するためには、ユーザーは、どんなポートレットが利用できるのかを知らなければなりません。1つの(場合によっては複数の)中央レジストリーがあれば、ポータルのユーザーは動的に新しいポートレットを発見してバインドすることができ、ユーザーの特定な要求に合致した作業環境を構築できるようになります。

中央レジストリーをポートレット・プロバイダーの観点から見ると、彼らが提供するポートレットを公開したり、記述したりできるようになるため、彼らにとっても中央レジストリーは同じように重要です。プロバイダーは、自分のポートレットを効果的に表現するテキスト記述やカテゴリー分け、その他のメタデータを提供でき、そのためコンシューマーはこうしたサービスを、効率的に発見できるようになります。当然のことですが、誰にも存在を知られないのであれば、コミュニティーに対してポートレットを提供する意味はないのです。

UDDI(Universal Description Discovery Interface)は、正にそうした機構を提供するものであり、共有すべきポートレット・サービスを持つWSRPプロデューサーと、作業環境を強化するための新しいアプリケーションを探すWSRPコンシューマーが集まる場所となります。UDDIはWebサービス発見のための標準となっているため、ポートレット発見の骨格の役割をUDDIが果たすのは、ごく自然と言えるでしょう。ただしポートレット発見には、ちょっとした問題があります。ポートレットは実のところ、真のWebサービスではないのです。

先に述べた通り、WSRPの世界には、真のWebサービスであるWSRPプロデューサーと、自分のプロデューサーが提供するAPIを通さないとアクセスできないWSRPポートレットがあります。WSRPポートレットは、論理的にはサービスと考えることができますが、コンシューマーが直接呼び出すことのできるAPIは持っていないため、真のWebサービスではありません。しかし、ポートレット発見では一般的に、エンドユーザーが自分のポータル・ページに追加すべきポートレットを探します。エンドユーザーにはWSRPプロデューサーの概念もなければ、WSRPの土台を理解すべき理由もありません。しかしポートレットは、そのプロデューサーを通してしかアクセスできないため、WSRPポートレットもWSRPプロデューサーも、レジストリーの中で公開する必要があるのです。

ただし、いったんコンシューマーがレジストリー内でポートレット・サービスを見つけると、ポートレットのメタデータには、コンシューマーがプロデューサーと直接連絡を取り、ポートレットを使用するために必要な全情報を含むことに注意してください。ポートレット発見機構はあくまでも、プロデューサーがそのポートレット・サービスを記述できるようにするための、そして潜在的なコンシューマーがそのサービスを見つけられるようにするための中央の場所として動作します。

図4. WSRPに関して典型的な、公開-発見-バインドの使用シナリオ
図4. WSRPに関して典型的な、公開-発見-バインドの使用シナリオ

図4は、典型的な使用シナリオであり、通常は次のようなステップで行われます。

  1. プロバイダーが一連のポートレットを開発し、WSRPプロデューサーを設定して、WSRPポートレットとして公開します。プロバイダーはこうしたポートレットをコミュニティーで使用できるように、中央のUDDIディレクトリーでポートレットを公開します。UDDIはWebサービス・インターフェース自体を公開するので、プロバイダーはおそらくこの作業を、カスタム構築したUI、あるいはUDDIサーバーが提供するUIを通して行うでしょう。
  2. エンドユーザーは、あるポートレットを自分のポータルに追加しようとします。そのユーザーのポータルが提供するツールを使って(あるいは、このために特別に書かれたカスタム・ツールを使って)、ポートレットの検索を実行します。ユーザーは自分のポータルに追加したいと思うポートレットを見つけると、そのユーザーのポータル・ページに、新しいポートレット・アプリケーションを気軽に追加します。あるいは、ポータル管理者がポートレットに対するUDDIレジストリーを検索し、ポータルの内部レジストリーにポートレットを追加することによって、エンドユーザーがポートレットを使えるようにします。
  3. 新しいポートレットを追加したページにユーザーがアクセスすると、今やそのページには、リモートで実行するポートレットが含まれています。その背後でポータルは、リモート・プロデューサーに対してWebサービス・リクエストを行います。そしてプロデューサーは、ポータル・ページに統合できるように、ポータルに対するマークアップ断片を返します。しかしエンドユーザーは、WSRPの核心的な詳細から、完全に隔離されています。エンドユーザーに分かるのは、自分のポータルに新しいアプリケーションを継ぎ目なく、容易に統合できるということだけなのです。

まとめ

この記事では、WSRP(Web Services for Remote Portlets)を紹介し、新しいアプリケーションを既存のポータルに簡単に統合するために、WSRPの力を活用する方法を解説しました。WSRPの登場によって、バックエンド・サービスの再利用にとどまらず、プレゼンテーション指向のサービスも再利用できるのです。WSRPを利用すれば、プレゼンテーション指向のWebサービス・ネットワーク全体の開発が、どれほど容易になるかを考えてみてください。いったんこうしたサービスが用意されれば、ポータルのユーザーは、こうしたサービスを幾つでも容易に発見、利用することができるのです。開発者がカスタム・アダプターを作ったり、クライアント・コードをビルドしたり、ポートレットをローカルにデプロイするために時間を費やす必要はありません。ポータル作業環境にポートレットを追加することが、マウスを2、3回クリックするだけで済んでしまうのです。

この記事では、WSRPの背景にある技術的詳細のうち、ごく表面的な点に触れただけですが、フロントエンド・アプリケーションの共有、再利用を促進するための強力な機構として、WSRPが果たす役割の概要は理解して頂けたと思います。WSRPに関する、さらに詳細な情報に関しては、下記の参考文献を参照してください。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services, XML
ArticleID=245552
ArticleTitle=WSRP(Web Services for Remote Portlets)入門
publish-date=04152005