 |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
WebSphere Portal V5.1.0.1プログラミング・モデルを活用する：第1部：モデルの概要 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Stefan Liesche, WebSphere Portal and Workplace Foundation Lead Architect,IBM レベル：初級 原文の掲載：2005年12月14日 更 新 日：2006年08月25日更新  原文はこちら(US)
はじめにWebSphere Portalプログラミング・モデルは、J2EEプログラミング・モデルの拡張です。このプログラミング・モデルを使用して、WebSphere Portalプラットフォームの豊富な機能を活用するWebアプリケーションを実装します。 これには、コンポーネントをページ階層に組み込む集約と統合、柔軟なナビゲーション、コンテンツとアプリケーションの集約、ブランディング、カスタマイズ、パーソナライズ、コンテンツ管理、文書管理、検索などが含まれます。 ポータルが原理的にどのように動作するのかを図1に示します。 図1.ポータルの原理:画面上でのアプリケーション統合  ユーザーはポータルと対話します。ポータルはさまざまなバックエンド・アプリケーションと対話し、ユーザーのためにこれらをまとめて、単一のブラウザー・ウィンドウ、つまりポータル・ページへと集約します。 また、WebSphere Portalは、これらのコンポーネントを1つのコンテキスト内に統合します。この機能は、画面上での統合と呼ばれることがあります。ユーザーのアプリケーションはポータルによって統合され、単一のウィンドウに表示されます。 このため、エンド・ユーザーは、多くの異なるシステムからの内容を、ユーザーにとって意味のある1つのコンテキストで、統一されたビューとして入手できます。 この強力な機能により、企業はユーザーに、広範囲に分散したITインフラストラクチャー内で、アプリケーションの複雑なネットワークを扱うための統合および統一された作業方法を提供できます。 異なるITシステムを異なるユーザー・インターフェースで扱う代わりに、ユーザーは単一のユーザー・インターフェースを用いて、1つのITシステム、つまりポータルを扱うだけでよいのです。 WebSphere Portalプログラミング・モデルは、集約ステップを異なるレベルでカスタマイズできるさまざまなAPI、SPI、JSP、Taglib、およびディスクリプターで構成されています。 この記事の目的は、このモデルを使用してポータルのどの部分をカスタマイズおよび拡張できるかについて、その概要を説明することです。
モデルの各部を調べるポータル・ページは、ポートレットによって生成された異なるマークアップ・フラグメントで構成されています。 すべてのポートレット・フラグメントを収集し、クライアントに送り返される単一ページを作成するプロセスは、集約と呼ばれています。これを図2に示します。 図2.ポータル・ページの集約  集約の流れは次のようになります。
ポータルとSOAサービス指向アーキテクチャー(SOA)は、アプリケーションの機能をサービスとしてエンド・ユーザー・アプリケーションまたは他のサービスに配布する分散システムを構築するためのアプローチです。SOAは、これらの異なるサービスを統合および管理するメカニズムを提供します。ポータルはSOAの概念にどのように適合するのでしょうか。ポータルは優れたユーザー・インターフェース(UI)のサポートをSOAに提供します。ミドルウェアがライフ・サイクル(ユーザー単位のカスタマイズ、集約、他のコンポーネントとの統合など)の共通機能を処理するのに対し、開発者は、ポータルの構築ブロックであるポートレットを使用することで、アプリケーション固有の機能に重点を置くことができます。 ポータルは、SOAランタイムがサービスを組み合わせて統合する方法と似た方法で、UIを集約および統合する機能をもたらします。コンポーネントUIはより大きく価値のあるUIへと集約され、ITサービスの単一ビューをユーザーに提供します。ユーザーは、この1つのUIだけをマスターすれば済みます。もともと個別に設計されたアプリケーションを新しい機能として統合できます。ポートレット間通信を使用して、コンポーネントを統合できます。たとえば、電子メール・ポートレットがコラボレーション・ポートレットと通信し、受信ボックスにフィルターを設定し、送信者がオンラインでチャット可能なときだけ受信済みメールを表示する、といったことが可能です。この機能は、どちらのオリジナル・アプリケーションでも利用できません。 ポータル・モデルの驚くべき結果として、オンデマンド・ビジネスの機敏さが改善されたことが挙げられます。システム管理者は、プログラミングなしに新しいアプリケーションを作成するアプリケーション・インテグレーターになることができます。必要なのは、新しいページの定義、ページへのポートレットの追加、ポートレット間のワイヤリング、権限の設定です。セルフサービス・ポータルにより、ユーザーは自分自身の必要性に応じて作業環境を調整できます。このため、アプリケーション開発者はポータル・アーキテクチャーによって解放され、新しいビジネス・バリューの構築に専念できます。 ローカル・ポートレットのサービス・インターフェースとプロトコルは、Java Portlet Specification によって定義されます。Web Services Remote Portlet(WSRP)はポートレットのリモート・レンダリングの標準で、ポータルが複数のリモート・ソースからコンテンツを集約することを可能にします。WSRPはWebサービスの統合機能をプレゼンテーション指向コンポーネントに拡張し、プラットフォーム、実装言語、およびベンダー間でビュー・レイヤーを共有できるようにします。追加のプログラミングを行うことなく、コンテンツとアプリケーション・プロバイダーのサービスを検出し、標準に準拠したアプリケーションに組み込むことができます。
成果物：ポートレットポートレットは、ポートレット・アプリケーションの基本的な構築ブロックです。この記事では、JavaPortlet APIまたはプログラミング・モデルについて触れない代わりに、WebSphere Portal特有の拡張に重点を置いて説明します。Portlet APIの詳細については、「リソース」を参照してください。タグ・ライブラリー JSR168は、ほとんどの共通ポートレット仕様の機能(アクションの作成やURLのレンダリングなど)についてのタグ・ライブラリーを定義します。また、JSP Standard Template Library(JSTL)は、JSPの追加共通機能(反復、フォーマット、国際化対応)を提供します。WebSphere Portal は、他の国際化対応の拡張を使用可能にするポートレットについての追加タグ・ライブラリーを提供します。 標準タグ・ライブラリーが十分でない場合に限り、アプリケーション固有のタグ・ライブラリーをポートレット・アプリケーションに含める必要があります。 ブローカーによるポートレットの対話 現在、Java Portlet Specificationが提供するポートレット間のデータ共有のサポートには制限があります。ポートレットは、他のポートレットとデータを共有するために、同じWebアプリケーション内のポートレット・セッションだけを利用できます。 WebSphere Portalは、ブローカーによるポートレット間の対話メカニズムの概念を提供します。すべてのポートレットはブローカーとの対話機能を登録し、ブローカーはポートレット間の対話を推進します。ブローカーは、「ポートレットは、型付きプロパティーのプロバイダーであり、コンシューマーである」という原理に基づいて動作するため、プロパティー・ブローカーと呼ばれています。ポートレットは、プロパティーの提供と消費の権利を直接登録するか、プロパティーを消費および提供するアクションの登録を介してこれを間接的に行います。プロパティーに関連する型付き情報を使用することにより、プロパティー・ブローカーは異なるポートレットに属するプロパティー間の互換性を判断できます。これによって、疎結合で高度に対話的なアプリケーションが可能になります。ポータル管理者は、実行時に統合されるようにポートレット間の結び付きを定義できます。 ポートレット間通信のプログラミング・モデルは、既存のJSRポートレットのAPIメソッドprocessActionを使用して、ポートレットにプロパティーの変更を通知します。このため、これらのポートレットはIBM拡張をサポートしない環境でも実行できます。IBM以外の環境では、プロパティー・ブローカーの特殊なアクションは起動されません。 通常、ポートレット・アプリケーションの開発者は、ブローカーによる基本的な連携メカニズムを利用するために、(通常のポートレット開発を超える)追加のプログラミングを求められることはありません。代わりに、開発者はプロパティーとアクションをWSDLファイルでブローカーに宣言する必要があります。WebSphere Portal V5.1.0.1では、プロパティー・ブローカーのメカニズムは、同じページ上のポートレット、または異なる2つのページ上のポートレットだけに制限されています。
ポートレット・フレームワークより複雑なポートレット・アプリケーションを作成するときにフレームワーク使用すると、多くの開発作業を節約できるだけでなく、これらのポートレット・アプリケーションが適切な設計となり、維持しやすくなります。WebSphere Portalは、Struts、Java Server Faces、および、JSF Widget Libraryの3つのフレームワークをサポートします。Struts Strutsは最も古いWeb開発フレームワークの1つで、非常に大きな開発者コミュニティーと非常に優れたツールのサポートを持っています。StrutsはApache[Struts]のオープン・ソース・プロジェクトで、サーブレットおよびJSPプログラマーにマルチページのModel-View-Controller(MVC)フレームワークを提供するために作成されました。Strutsはサーブレット用に開発されたため、ポートレットに対してはそのままでは機能しません。ポートレットは、アクションおよびレンダリング・フェーズと共に、インターフェースに厳密に組み込まれたMVCパターンを持ちます。また、ポートレットとサーブレットの要求/応答は異なるので、適合させる必要があります。WebSphere Portalは、WebSphere Portal上でJSR168ポートレットをサポートするよう変更された特殊なバージョンのStrutsV1.1ライブラリーを提供します。 Java Server Faces(JSF) Java Server FacesはJava Webアプリケーション用のUIフレームワークで、Java Community Processを介して標準化されました。これはたいへん新しいフレームワークなので、ポートレットについて考慮しており、ポートレットとサーブレットに対してそのままで機能します。UIコンポーネントに加え、JSFは、ステート・ハンドリング、検証、およびこれらのコンポーネントのイベント処理についてのインフラストラクチャー・サポートも提供します。JSFは、ポートレットと共に適切に動作する強力で柔軟性の高いフレームワークです。 WebSphere PortalはJSFライブラリーを含めることによってJSFをサポートするため、テーマとスキンはこのUIフレームワークを活用できます。Rational Application Developerは、ツールのサポートを行います。ウィザードを使用してJSFベースのポートレットを作成できます。また、ポートレットが用いる追加JSF UIウィジェットを使用することもできます。 JSF Widget Library(JWL) Rational Application Developerによって提供されるJWLは、ポータルとポートレット・プログラマーがJSFをベースとした追加ウィジェットを使用できるようにします。このライブラリーの大きな特長の1つとして、これらのウィジェットがクライアント機能を持つことが挙げられます。ウィジェットは、ビューを更新するためにクライアントで処理を実行できます。これによってサーバーとのやり取りが削減され、応答時間が劇的に短くなるため、ユーザー・エクスペリエンスが飛躍的に改善されます。他のポートレットと同様に、これらのウィジェットを使用するWebSphere Portalポートレットをデプロイできます。
成果物：テーマとスキンJ2EE JSPモデルは、Webアプリケーションの構築時に、プログラミングの役割を設計の役割から切り離すためのベースを提供します。WebSphere Portalは、より明確な分離と高い柔軟性を持つフレームワークを提供することにより、これを進化させています。WebSphere Portalのテーマとスキンは、適切に定義された成果物(JSPとCSSクラスを含む)によって、ユーザー・エクスペリエンスのブランディングとルック・アンド・フィールのアスペクトを分離しています。トポロジー・モデルで参照されるテーマとスキンの実装を単に置き換えることにより、ユーザー・エクスペリエンスのブランディングと全体のルック・アンド・フィールを簡単に変更できます。WebSphere Portal V5.1.xでは、テーマとスキンを適用しなければならないディレクトリー構造を定義するため、テーマとスキンをWebSphere Portalにデプロイすることができます。テーマはページのルック・アンド・フィール(ブランディングを含む)のアスペクトを制御します。スキンは、ポートレット・コントロールを公開します。テーマとスキンを円滑に機能させるために、ポートレットのプログラマーは、グローバルに定義された標準CSS形式クラス(JSR 168およびWSRPで定義されたものなど)を実装で使用する必要があります。これにより、個別に開発されたポートレットが同じページに集められ、同じチームによって開発されたポートレットのように表示されます。 WebSphere Portal5.1のデフォルトのテーマの一部を図3に示します。どのテーマも、ページ用のテーマとして選択できます。また、これらのテーマをテンプレートとして使用して、カスタム・テーマを作成できます。 図3.WebSphere Portal5.1のデフォルトのテーマの一部  ポートレット・ウィンドウをレンダリングするWebSphere Portal V5.1のデフォルトのスキンの一部を図4に示します。テーマの場合と同様に、スキンをカスタマイズしたり、独自のスキンを作る際のサンプルとして使用できます。 図4.WebSphere Portal V5.1のデフォルトのスキンの一部  テーマとスキンに関する情報は、Theme ListモデルおよびSkin Listモデルを介してプログラマチックに取得できます。これらのモデルは、テーマ・オブジェクトとスキン・オブジェクトを公開しています。これらは、特定のテーマまたはスキンに関する情報を入手するために使用します。
成果物:ポートレット・サービスポートレット・サービスは、名前からもわかるように、ポートレットによって使用されるサービスです。サービスの種類には、WP5.1と共に出荷されるデフォルト・ポートレット・サービスとカスタム・ポートレット・サービスの2種類があります。ポートレット・サービスのプログラミング・モデルは、ポートレットAPIで指定されていない機能をポートレットに提供するためのフレームワークを定義します。ポートレットは、このようなサービスを標準JDNI検索を通じて取得できます。インターフェースの定義では、ポートレット・サービスはまったく制限されていません。一般に、ポートレット・サービスはポートレットAPI(ポートレット要求など)からオブジェクトを入力パラメーターとして受け取ります。一部の(IBM独自の)ポートレット・サービスは、WebSphere-Portalの一部として提供されますが、カスタム・サービスをポータルに追加することもできます。 ポートレット・サービスには、ほぼ独立する次の2つの観点があります。
ポートレット・サービスのプログラミング・モデルはシングルトン・ベースです。これは、ポートレット・サービスのポートレット・エンティティー固有のインスタンスがないことを意味します。このため、ポートレットのinitメソッドでサービスを検索し、それをインスタンス変数に格納するプログラミング手法が推奨されています。 WebSphere Portal V5.1.0.1は、次のポートレット・サービスを提供します。これらのサービスは、一般的な使用を目的としたAPIです。
次のサービスはSystem Programming Interface (SPI)です。より複雑で、高度な用途を目的としています。
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
