レベル: 初級 Ann Fred, Staff Software Engineer, IBM, Software Group
Stan Lindesmith, Staff Software Engineer, IBM, Software Group
2003年 2月 01日 ソフトウェア設計者の中には、ソリューションを実装する際に、常に最新テクノロジー利用しようとする人たちがいます。また、なじみの深い、時の試練に耐えたプラットフォームを使い続けようとする人たちもいます。StanとAnn Marieはこの記事で、彼らのWebアプリケーションおよびポートレットの開発経験を活かして、ポートレットが読者のアプリケーションに適しているかどうかを見極める手助けをします。2人はまた、読者の関心を引くトピックについて詳しく述べている参考文献を、多数提示してくれています。
ポートレットとは? ポータルとは? ポータル・サーバーとは?
読者は、「ポートレットとは何か?、ポータルとは何か?、ポータル・サーバーとは何か?」と疑問に思ったことがあるのではないでしょうか。この記事で私たちは、それぞれの疑問に対する簡潔な答えを示し、さらに詳細な情報が必要な場合に参照すべき文献を紹介します。ポートレット、ポータル、およびポータル・サーバーがどのようなものであるのかを十分に理解すると、読者のプロジェクトにどれを使用するべきかを、適確に判断できるようになります。
WebSphere Portalサイトには、次のような、IBMによるポータルの実用的な定義が掲載されています。「ポータルは、ユーザーのニーズおよび責任に応じて個別設定された、多様な情報、ビジネス・プロセス、および人間と対話するための、セキュアな単一ポイントである。」ポータルによってWebアプリケーションに付け加えられる機能と、ウィンドウ・マネージャー (Microsoft Windowsなど) によってオペレーティング・システム (DOSなど) に付け加えられる機能との間には、かなりの類似性があります。ポータルもウィンドウ・マネージャーも、ともに、アプリケーションと対話するための、一貫性のある統一された方法を提供します。
ポートレットは、WebSphere Portalサイトによると、「ポータル・ページ上でユーザーが目にすることのできる可視的なアクティブ・コンポーネントである・・・。最も単純に表現すると、ポートレットはポータル内で動作するJavaサーブレットである。」図1 は、2つの可視コンポーネントを含むポータル・ページの例を示しています。それぞれの可視コンポーネントは、ポートレットと呼ばれます。この例では、1つのポートレットにより、指定したURLにユーザーがアクセスでき、もう1つのポートレットにより、メモ・テキストがユーザーに提供されます。
図1. ポートレットを2つ含むポータル・ページの例
ポータル・サーバーは、アプリケーションの接続、統合、管理、およびすべてのポータル環境で必要となる画面表示などの、共通サービスを提供します。機能面では、ポータル・サーバーはユーザーにポートレットを提供します。
WebSphere Portal Server サイト（日本語サイト）には、ポートレット、ポータル、およびポータル・サーバーに関する情報が豊富に掲載されています。ポートレットやポータル・サーバーに関する基本的な概念になじみの薄い方には、手始めとしてこのサイトをお勧めします。また、WebSphere Portal Serverの開発者および管理者向けに特化された技術サイト、WebSphere Portal Zone もお勧めです。
注: 私たちはIBMのJavaプログラマーであるため、WebSphereソフトウェアに関する経験は豊富ですが、競合他社の製品についてはほとんど経験がありません。自分たちが知っていることを書くようにしているため、この記事で紹介する参考文献および例のほとんどは、IBMサイトおよびWebSphere製品に関するものです。ただし、ここで述べる内容のほとんどは、IBMだけに特有の事柄ではありません。読者の会社でどのようなポータル・サーバーを使用しているとしても、ポータル、ポータル・サーバー、およびポートレットの基本的な概念および特性は、非常に類似しています。私たちは、この記事がポートレットの使用を考慮しているすべての読者のために役立つことを期待しています。
Javaサーブレット、JavaServer Page、およびMicrosoft Active Server Pagesテクノロジー
Javaサーブレット、JavaServer Pages (JSP)、およびMicrosoft Active Server Pages (ASP) テクノロジーは、Webアプリケーション用の信頼できる開発プラットフォームです。これらのテクノロジーは、広く認められた標準と、それらを開発およびテストするための豊富なツールを備えた、成熟したプラットフォームです。
サーブレットは、本質的には、Webブラウザーの機能を拡張するための標準的な方法です。これは、CGI (Common Gateway Interface) スクリプトに取って代わるために設計されています。標準API (アプリケーション・プログラミング・インターフェース) が用意されており、Webアプリケーションを実装するために開発者が「組込み」ます。サーブレット・エンジンには、いくつかの便利で時間の節約に役立つ機能が備わっています。例えば、ネットワークから送られたHTTP要求を使いやすいHttpServletRequestオブジェクトに変換する機能、プログラマーが応答に使用する出力ストリームを提供する機能、そして使いやすいHttpServletResponseオブジェクトをネットワークに送り返すHTTP応答に変換する機能などです。サーブレット・エンジンにはまた、要求と要求の間でユーザーを記憶しておくことのできる、便利なセッション管理機能も備わっているため、複数の要求で使用可能なリソース (データベース接続など) を割り振ることができます。サーブレットは、ポートレットと同じように、ビジネス・データとWebブラウザー・インターフェースとの間の橋渡しを行います。サーブレットには、移植性がきわめて高いという利点があります。今日使用可能な、どのようなWebアプリケーション・テクノロジーと比較しても、より多くのWebサーバーまたはWebアプリケーション・サーバー、また、より多くのプラットフォームで実行することができます。詳細については、SunのJava Servlet Technologyページを参照してください (参考文献にリンクが示されています)。
 |
ASPおよびJSPテクノロジー
Microsoft Active Server Pages (ASP) テクノロジーもJavaServer Pages (JSP) テクノロジーも、ともに、Model-View-Controllerデザイン・パターンを実現するための明快なプログラミング方法を開発者に提供しますが (詳しくは、参考文献を参照)、両者の間には顕著な相違点があります。
読者のソリューションを展開するために、どのWebサーバーおよびプラットフォームを使用する必要があるのか考えてください。プロプラエタリーなテクノロジーを使用するのか、あるいはオープン・スタンダードに基づくテクノロジーを使用するのかを、検討する必要があります。ベータ・ソリューションの提供を開始した後のことも考えるなければなりません。高い拡張性やスケーラビリティーが要求されるのでしょうか?
「Comparing JavaServer Pages and Microsoft Active Server Pages Technologies」という記事は、これら (およびそれ以外) のそれぞれの事項を分析しています。参考文献に、この記事へのリンクを用意してあります。
|
|
JSPページは、実際にはサーブレットの一種です。各JSPページは、舞台裏で自動的にサーブレットに変換されます。サーブレットと同じように、JSPページは、開発者が要求および応答オブジェクトにアクセスできるようにします。開発者は、応答の出力ストリームに出力を書き込みます。開発者の中には、誤ってサーブレットをJSPページで完全に置き換えてしまう人がいますが、理論的には、両者は使用法が異なり、相互に補完し合うものです。JSPページは、出力を生成するための、便利な構文を提供します。その構文は、Java、JSPの特殊な構文、およびブラウザー表示のためのマークアップ (HTMLやJavaScriptなど) が組み合わされたものです。それに対し、サーブレットは純粋なJavaテクノロジーであり、ビジネス・データをやり取りするための簡潔な手段を提供します。多くの開発者にとってなじみの深いModel-View-Controller設計は、サーブレットとJSPページを合わせて使用する際に役立ちます。Modelは、ビジネス・データと、その読み取りおよび更新に役立つオブジェクトです。Controllerはサーブレットであり、ユーザーのWebブラウザーから要求を受け取り、Modelを使用して要求を処理し、JSPページのために必要な情報を1つのオブジェクト (通常はBeanと呼ばれます) に手際よくまとめます。JSPページはViewであり、サーブレットから得られた情報を、分かりやすく、見栄えのよい方法で表示します。サーブレットをサポートするものであれば、どのようなプラットフォームでもJSPページをサポートします。(JSPページの詳細については、参考文献を参照してください。)
ASPページの機能は、サーブレットおよびJSPページに似ています。ASPページを使用すると、ユーザーは対話式のWebページを体験することができます。ASPページはまた、開発者がMVC設計を利用し、ActiveXコントロールを使用してビジネス・ロジックを画面表示から分離できるようにします。ASPページは、Microsoftの .NETプラットフォームと簡単に統合することもできます。ただし、サーブレットおよびJSPページとは異なり、ASPページはJavaポートレットとは互換性がなく、また、ポートレットに簡単に変換する方法もありません。ActiveXコントロールを使用する関係で、(読者が使用したいプラットフォーム向けに移植および橋渡しを行う、サード・パーティー製プログラムを見付けることができないかぎり) ASPページはWindowsプラットフォームでなければ使用できません。全般的に、ASPページは、Javaテクノロジーほどには多くのWebサーバー、Webアプリケーション・サーバー、およびオペレーティング・システムとの互換性がないため、私たちはサーブレットおよびJSPページのほうが気に入っています。
完全を期すためには、CGIスクリプトについても説明する必要があるでしょう。CGIスクリプトは、サーブレット、JSPページ、およびASPページが登場するまでは、対話式Webサイト用に好んで使用されたテクノロジーでしたが、今は時代遅れとなってしまいましたので、どのような用途であっても使用することはお勧めできません。まだ頑固にCGIを使用している開発者もいますが、そういう人たちは、しなくても済む苦労をたくさん味わっています。私たちがこの記事でお話しする新規テクノロジーのほうが、開発も、デバッグも、保守も、はるかに容易です。CGIには多くの制約事項、パフォーマンス上の問題、およびセキュリティーの欠陥もあります。コストを重視する場合には、最新テクノロジーを無料でサポートする、すぐれたWebアプリケーション・サーバーを入手することができます。Sunが提供しているJava Web Services Developer Pack、およびApache Software Foundationによるオープン・ソース・プロジェクトJakarta、Tomcat、およびJetspeedを検討してください。Apacheサーバーは実動システムにも適しています。(リンクについては、参考文献を参照してください。)
ポートレットについて
ポートレットは、最新のWebアプリケーション開発テクノロジーです。JSR 168 (参考文献を参照) にポートレットの仕様が規定されていますが、ポートレットはまだ完全には標準化されていません。例えば、WebSphere Portal ServerのポートレットはBEAポータル・サーバーでは機能しません。これは、BEAアプリケーション・サーバーがWebSphere Portlet APIをサポートしていないためです。また、サーブレットのような確立されたテクノロジーに比べると、ポートレットの開発に利用可能なツールは、それほど多くありません。しかし、そうであるからといってポートレットを敬遠することはありません。標準化が完了すれば、既存のポートレットを新規標準に適合するように変換するのは簡単なはずです。ポートレットを開発するためのツールキットはすでに使用可能であり、開発ツールは絶えず改善されています。WebSphere Studio用のポータルおよびモバイル装置用ツールキットについては、WebSphere Studio Zoneをお調べください。
熟練したポートレット開発者の人数は、サーブレット、JSP、およびASPの経験豊かな開発者の人数にはとうてい及びません。しかし、これらの比較的古いテクノロジー (特にサーブレットおよびJSPのテクノロジー) の経験を積んだ開発者は、ポートレットの書き方を短期間で簡単に習得することが可能です。開発者にとって、コスト効率の高さ (および退屈な作業を軽減させる) という点では、ポートレットを作成する場合のほうがサーブレットの場合よりも有利です。これは、通常であれば開発者が自身で用意する必要のある多くの機能を、ポータル・サーバーが提供してくれるためです。
ポートレットは、実際には特殊なタイプのサーブレットであって、サーブレットと同様に、ユーザー・インターフェースを提供するためにJSPページを使用します。Portlet APIはServlet APIを継承し、サブクラス化したものです。つまり、ポートレットはサーブレットで可能なことであれば、振る舞いに多少の違いがあり、また、いくつかの追加機能が付け加わりますが、どのようなことでも行うことができます。最も顕著な振る舞いの違いは、要求の処理方法です。サーブレットが処理する「doGet」要求と「doPost」要求は、HTTP GETおよびPOST要求にマップされ、ポートレットが処理する「doView」要求と「doEdit」要求は、Webブラウザーから直接得られるのではなく、ポータル・サーバーから得られます。PortletLogが若干改善され、標準のServlet APIよりもロギングおよびトレースの機能が向上しています。また、WebSphere Portal Serverによって行われたもう1つの改善により、ポートレットの国際化対応サポートが向上しています。また、Portlet APIを使用すると、自分のポートレット・アプリケーションおよびポートレット・インスタンスに関する構成情報にアクセスできるようになります。
ポートレットには、サーブレットではまったく使用することができない多くの標準機能も備わっています。そのうちの重要な機能の1つとして、各種のユーザーのデバイスに応じてのさまざまなJSPページを自動的に使用するための組み込みサポートがあります。これにより、最新のWebブラウザーを備えたデスクトップ・コンピューター、機能が限定されたWebブラウザーをもつ旧型コンピューターまたはパームトップ型のコンピューター、携帯情報端末、およびWeb対応の携帯電話などの、多くの装置で使用できるポートレットが作成できるようになります。最小公倍数に合わせたプログラミングを行う必要はありません。基礎になる1つのビジネス・ロジックを再使用して、さまざまな装置タイプに合わせて複数のインターフェースを用意しておけば、ポータル・サーバーが、各ユーザーに最も適したものを選択してくれます。さらに、複数のポートレット・コントローラーを用意することもできます。これにより、それぞれの装置タイプごとに異なるページ/アクション・シーケンスを使用することができます。
Portlet APIによって提供されるもう1つの機能は、メッセージおよびイベントを処理する能力です。ActionListenerは、ページ内で行われたユーザー・クリックをアクション・イベントに変換します。アクション・イベントは多くのJavaプログラマーにおなじみの使いやすいモデルです。WindowListenerは、ポートレットが最大化、最小化、または復元されたときなどに、ポータルから得られたウィンドウ・イベントをポートレットに通知します。MessageListenerを使用すると、あるポートレットから別のポートレットに送信されるメッセージを処理することができます。
ポートレットには、何通りもの方法でカスタマイズできるというという、別の重要な機能もあります。開発者がポータル・サーバーによって提供された標準のCascading Style Sheetを使用すると、そのすべてのポートレットが同じ外観になります。企業は、各社の特有なスタイルを反映させて、ポートレットのテーマおよびスキンを作成することができます。これにより、すべてのポートレットが (サード・パーティーによって開発されたものも含め)、自動的にその新規スタイルに変更されます。
また、ユーザー・グループごとにポートレットをカスタマイズすることもできます。ポートレットの使用許可をいくつかのユーザー・グループに割り当てると、使用許可を得ていないユーザー・グループは、自分のポータル内でもそれらのポートレットを使用できないようになります。また、ポータル・サーバーはグループのメンバーシップを簡単に判断する機能を備えていますので、ポートレットの出力を、現行ユーザーが属しているユーザー・グループごとに変更することもできます。ポータル・サーバーは、既存のLDAPディレクトリーを使用して、ユーザー・グループをインポートすることができます。また、ユーザーが新規のユーザー・ディレクトリーを作成することもできます。
3番目のタイプのポートレット・カスタマイズは、ユーザー設定です。ユーザーは、ポータル管理者が設定した制限に従って、どのポートレットを自分のポータルに含めるのか、また、それらのポートレットをどのページに配置するのかということなど、開発者によって変更が許可されている、任意の設定を決定することができます。例えば、ユーザーが相場速報ポートレットをユーザー自身の株式のポートフォリオによってカスタマイズできるようにして、その情報を該当ユーザー用のPortletDataオブジェクトに保管することができます。そのユーザーがログアウトして戻ると、次回のlog in時には、直前のセッションで保管された設定が渡されます。
WebSphere Portal Serverおよびその拡張機能では、これ以外にも、コンテンツ・マネージメント、トランスコーディング、音声サポート、オフライン・ブラウズなどの、多くの有用な機能が提供されます。ポートレットの開発を選択すると、そうした機能も使用可能になりますが、それらについては、この記事では扱いません。これらの拡張機能の詳細については、WebSphere Portal Server（日本語サイト） ホーム・ページ、およびWebSphere Portal Zone を参照してください。
ポートレットとWebサービス
Webサービスも、最新のWebアプリケーション開発テクノロジーです。Webサービスは、Web経由で記述、公開、位置指定、および起動することのできる、モジュール性の高いアプリケーションです。これらのモジュール性の高いアプリケーションは、疎結合の、動的にバインドされたコンポーネントです。Webサービス、および現実の世界のビジネス問題へのWebサービスの適用に関する概要としては、「Webサービスのベスト・プラクティス」シリーズ をお勧めします。
ポートレットと同じように、Webサービスはまだ完全には標準化されていませんが、標準化作業が着々と進行していますので、今すぐにWebサービスを使用しても差し支えありません。WebSphere SDK for Web Services など、開発ツールもすでにいくつか使用可能になっています。
Webサービスは、オブジェクト指向設計を論理的に拡張したものです。開発者は、機能を実装して、その機能を (APIを介して) Webサービスとして定義することができます。アプリケーションが作成され、インターフェースが定義されると、Webサービスが使用可能になり (つまり、公開され)、サービスの顧客 (リクエスター) がそれを使用できるようになります。図2 に示すように、このアーキテクチャーには、3種類の異なるユーザーがあります。Webサービス・プロバイダー は、モジュラー・アプリケーションを定義し、Webサービス・ブローカー に対してそのアプリケーションの公開を依頼して、Webサービス・リクエスター が自分のアプリケーションで利用できるようにします。この図には、これらの3種類のユーザーが行うアクション (公開、検索、およびバインド) も示されています。Webサービス・アーキテクチャーの詳細については、「Web Servicesアーキテクチャーの概要」(developerWorks、2002年9月) を参照してください。
図2. Webサービスは公開-検索-バインド・アーキテクチャーです
Webサービスは、それ自体を外部世界に対して示すために、サービス記述言語を使用します。データを定義して直列化するためのさまざまな標準については、「Finding your way through Web service standards」(developerWorks、2002年12月) を参照してください。
ポートレットが最も真価を発揮するとき
Webアプリケーションおよび情報を 手近な1つの便利な場所にまとめたい場合、ポートレットは最適な選択肢になります。開発の目標がこれとは異なる場合にはでも、以下のポートレットおよびポータル・サーバー機能を検討してみてください。利用してみたいと思うものがあるかもしれません。
- ポートレットは、多くのクライアント装置で使用できるように拡張することができます。ユーザーは、コンピューターからコンピューターへ、またモバイル装置からモバイル装置へと移動しても、必要な情報およびアプリケーションを使用することが可能です。
- ポートレットを使用すると、コンテンツをさまざまなユーザー・グループ向けに簡単にカスタマイズすることができ、また、個々のユーザーは自分のニーズに合わせてコンテンツを再配置および調整することができます。
- ポータル・サーバーが提供するテーマおよびスキンとともにCascading Style Sheetsを使用することにより、ポートレットの外観を統一したり、見栄えを迅速に変更したりすることができます。また、自社のイメージやスタイルが適確に反映されるように、独自のテーマおよびスキンを作成することもできます。
- ポートレットはWebサービスとして公開できますが、そのことにより、ポータル・サーバー環境の外部にある企業も、それらのポートレットを使用するためのプログラムを、簡単に書くことができるようになります。
- WebSphere Portal Serverは国際化対応に関して、優れたサポートを提供しますが、それは、Webアプリケーション・サーバーが提供するものを凌駕しています。海外のユーザーのために (中国語のような2バイト文字言語や、アラビア語のような双方向言語の場合にも) 適切な表示が行われるようなポートレットを、簡単に開発することができます。
- ポートレットを使用すると、複雑なアプリケーションをいくつかのタスクに分割しやすくなります。一般に、1つの密接に関連したタスクのグループは、1つのポートレットに相当します。WebSphere Portal Serverの管理ポートレットがそのよい例です。図3 で、管理タスクがどのようにカテゴリー (PortletやPortal Settingなど)、関連タスクのグループ (Manage User、Manage User Groups)、および単一タスク (Search for user、Create new user) に分割されているのか注意してください。
- ポートレットを使用すると、読者のアプリケーションに後から機能を簡単に追加することができます。新規機能が大規模である場合には、新規ポートレットを作成します。小規模な更新の場合には、ユーザーの個別の設定を損なうことなく既存のポートレットを更新することができます。
- ポートレットは、他のWebアプリケーションと同じようにファイアウォールとの相性が優れています。標準のWebプロトコルを使用して情報を受信し、表示します。
- すべてのユーザーに対しても、ポートレットを一度インストールして構成するだけで済むため、各コンピューターで独立のアプリケーションを構成するよりもはるかに簡単です。これは、他のWebアプリケーション・テクノロジーにも当てはまります。
- ポータル・サーバーは、Webアプリケーション・サーバーと連動して、セキュリティー、インストール・サポート、信頼性、および多くのユーザーのための可用性を提供しますので、こうした機能のために開発労力の多くを費やす必要がなくなります。
- 一度ポータル・サーバーへの投資を行うならば、その先進的な機能の有用さにお気付きになることでしょう。とりわけ、コンテンツ・マネージメント、トランスコーディング、音声サポート、オフライン・ブラウズが、その最たるものです。
図3. ポートレットは密接に関連しあったタスクのグループです
別のソリューションのほうが適切な場合
ポートレットは、あらゆる設計上の課題を解決できるわけではありません。次のように、ポートレットではうまく対処できない場合も、いくつかあります。
- 複雑なユーザー・インターフェースは、ポートレットにうまく変換できません。HTMLやWMLなどのマークアップ言語では記述できないインターフェースもあります。EclipseやVisual Basicなどの統合開発環境 (IDE) をHTMLで実装することを想像してみれば、このことが理解できるはずです。このような用途には、ネイティブ・アプリケーションやJavaアプリケーションのようが適しています。(複雑なユーザー・インターフェースを使用していて、ポートレットを利用したい場合、WebSphere Portalサポート4.2はStrutsをサポートしますので非常に役立ちます。StrutsはApache Jakartaプロジェクトの一部であり、詳しい情報はStrutsサイトに記載されています。参考文献にリンクがあります。)
- 絶えずデータを更新する必要のあるようなユーザー・インターフェースも、ポートレット向きではありません。あるポートレットを更新した場合、そのページ全体に含まれているすべてのポートレットを再描画する必要が生じます。したがって、特別な指定をせず、あるポートレットが更新された度に、すべてのポートレットに関し、自動的に新しいデータを再ロードさせることは、一般的に言ってお勧めできるやり方ではありません。他方、ポートレットに「最新表示」オプションを用意しておいて、ページをいつ再ロードするのかをユーザーに選択させることができます。図4 は、IBMの従業員ポータルからの最新表示リンクを含む株式ポートレットの例です。このリンクは、株式ポートレットを再ロードしますが、ポータル・ページの残りの部分も再ロードします。ユーザーがページを最新表示する頻度は、予測できないため、データが古くなってはいけないような場合には、Webアプリケーションではなく、ネイティブ・アプリケーションまたはJavaアプリケーションを使用してください。
図4. 更新が必要なデータ
- 高度に対話的なユーザー・インターフェースは、Webアプリケーション一般、特にポートレットには、うまく変換することができません。ドロップダウン・リスト内の項目の選択など、なんらかのアクションをユーザーが行ったときにインターフェースが自動的に変更されるようにしたい場合には、フォームを実行依頼してページ全体を再ロードするか (この方法は面倒です)、あるいはスクリプト言語を使用してポートレットを再描画することができます (この方法は困難です)。スクリプト言語を使用する場合には、サポートしたいすべてのデバイスでそれが機能することを確かめる必要があり、また、ユーザーのうちの誰かがスクリプトを使用不可にしていてもポートレットが機能することを確かめる必要があります。モバイル・デバイス向けには、おそらく、スクリプトを使用しない代替のJSPページを用意する必要があります。ネイティブ・アプリケーションやJavaアプリケーションのほうが、Webアプリケーションよりも簡単に対話を高度化させることができます。
- ポートレットは、「自分の根城」でしか存続することができません。ポータル・サーバー環境の外部にあるWebページに移動するようなリンクがポートレットに含まれている場合には、移動先からポータルに戻ることが困難になりますので、注意してください。フレームを使用することは許されません (内部フレームの使用は許されますが、Microsoft Internet Explorerユーザーでなければそのフレームを見ることはできません)。ポップアップ・ウィンドウおよびスクリプトは、通常は、モバイル・デバイスで使用することはできません。読者のアプリケーションがポータル・フレームワークに適しない場合、そのアプリケーションを不具合な振る舞いのポートレットに、無理やり作りこむということは避けてください。
- 他のアプリケーションにサービスを提供したい場合には、まず最初にWebサービスを作成することを検討してください。Webサービスを実装すると、それを使用するためのポートレットを作成し、他のアプリケーションと共用するためにそのWebサービスを公開できるようになります。上記の株式ポートレットは、その格好の例になります。株価情報サービスをWebサービスとして作成し、株価情報ポートレットおよびその他のアプリケーションで使用できるようにすることができます。この場合、株価が一定の価格に達したときにテキスト形式のポケットベル・メッセージをユーザーに自動的に送信するようなプログラムを作成することもできます。
- 読者の会社にまだポータル・サーバーがなく、またただちにそのための投資を行う予定がない場合には、とりあえず、JSPページを出力用に使用するサーブレットとしてアプリケーションを実装してください。このアプリケーションは、後でいつでもポートレットに変換することができます。
- ポートレットは完全には標準化されていなく、まだ他のJavaテクノロジーほど多くのプラットフォームではサポートされていません。さしあたり、サポートされるサーバー・プラットフォームにある、1つのポータル・サーバーだけを使用するようにしてください。こうしたトレードオフが受け入れがたい場合、最初のうちはサーブレットとしてアプリケーションを実装しておいてください。後でそれをポートレットに変換することができます。
|
どうやって開始するのか?
ポートレットが次期プロジェクトとして最適のテクノロジーであると決断した読者には、おそらく、開発を始めるために役立つ情報が必要となることでしょう。ポートレット開発の詳細については、この記事では扱いませんが、WebSphere Portalについて詳しく学ぶ際に役立つ記事およびチュートリアルのリンクを示します。
WebSphere Developer Technical Journal とdeveloperWorks は、ともに、ポートレットを作成するために役立つ、優れた技術的なハウツー記事を多数掲載しています。これらのアーカイブを検索して、参考になる記事を見付けてください。
ポートレットの開発を始める人のために適したチュートリアルとして、「WebSphere Portal Programming: Pervasive Portlet Development」(WebSphere Developer Technical Journal、2002年7月) および「WebSphere Portal V4プログラミング、第1回: ポートレット・アプリケーション・プログラミング」(developerWorks、2002年8月) があります。また、WebSphere Application Developerと、ポートレットを作成するためのポータル・ツールキットの使用方法も調べておくことをお勧めします。上記のものよりも古いシリーズ記事ですが、「WebSphere Portal Server Development Using WebSphere Studio Application Developer」(WebSphere Developer Technical Journal、2002年4月) が参考になると思います。ポートレットとともにWebサービスを使用することも検討してください。クイック・チュートリアルとして、developerWorksの記事「独自のポートレットおよびWebサービスの作成」(developerWorks、2002年4月) があります。
正規の講習をお望みの方は、IBM Learning Services（日本語サイト） をご覧ください。ポータルおよびポートレットの開発者のためのクラスが掲載されています。この記事の執筆時点でお勧めしたいのは、IBM WebSphere Portal Version 4 Application Development (コース・コードPW531) です。IBM WebSphere Portal Version 4 Administration (コース・コードPW431) でもコースが用意されています。WebSphereカテゴリーに進んでそれらのコースを探すか、あるいは検索フィールドにコース・コードを入力してください。これらのクラスは、かなり役に立つものになると思います。
謝辞
この記事を校閲し、貴重な意見を提供してくれた同僚たちに感謝します。レビューしてくれた人の中には、この記事で参照されている文献の著者もいます。
参考文献
著者について | 
| | Ann Marie Fredは、ノースカロライナ州にあるIBM Research Triangle Park Labに勤務するソフトウェア・エンジニアです。彼女は数年間にわたり、Javaのグラフィカル・アプリケーション、サーブレット、アプレット、ポートレット、およびWebアプリケーションの開発経験を積んできました。Ann Marieが最も関心を寄せているのは、パーベイシブ・コンピューティングとWebアプリケーションです。彼女の現在のプロジェクトは、IBM WebSphere製品を管理するためのポートレットの開発です。Ann Marieは1999年にデューク大学よりコンピューター・サイエンスの学士号を取得しています。現在は、チャペルヒル市にあるノースカロライナ大学の大学院でコンピューター・サイエンスを学んでいます。 |
| | | Stan Lindesmithは、ノースカロライナ州のResearch Triangle ParkにあるIBM Pervasive Computing Labに勤務するソフトウェア・エンジニアです。彼は、IBMの無線ソフトウェア製品向けのJavaアプリケーションの開発を数年間経験しています。Stanが最も関心を寄せているのは、パーベイシブ・コンピューティングです。彼の現在のプロジェクトは、IBM WebSphere製品を管理するためのポートレットの開発です。Stanは、1990年にミズーリ州ローラにあるミズーリ大学より、コンピューター・サイエンスの学士号と応用数学の学士号を取得しています。そして、1992年にミシガン州立大学よりコンピューター・サイエンスの修士号を取得しています。 |
記事の評価
| 
