 |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||
IBM Workplace プログラミング・モデルの概要 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sami Shalabi, Senior Software Engineer, Lotus レベル：中級 原文の掲載：2006年01月04日 更 新 日：2006年03月31日更新  原文はこちら
この記事では、IBM Workplace プログラミング・モデル、J2EE および Eclipse プログラミング・モデルの拡張について解説します。これらの IBM Workplace 拡張には、従来の WebSphere Portal 拡張 (ユーザー登録とプロファイル、柔軟なナビゲーション、コンテンツとアプリケーションの集約、ブランディング、カスタマイズ、パーソナライズ、検索) と、テンプレートおよび複合アプリケーション関連の新しい拡張セットが含まれます。 この記事では、IBM Workplace プログラミング・モデルを概念レベルで考察します。その際、最も重要なトピックを取り上げ、基礎的な内容は他のドキュメント (たとえば、製品マニュアルなど) に譲ることにより、概念の単純化に重点を置いています。この記事で取り上げたいくつかの概念は、IBM Workplace 製品群にまだ完全には実装されていません。このため、この記事ではフレームワークとモデルの背景となる「理論」を説明します。将来のリリースでは、概念が完全な形で実装されるでしょう。 この記事は、J2EE または Eclipse でのプログラミング経験のある方を対象に書かれています。
概要IBM Workplace プログラミング・モデルは、次の 3 つの基本概念に基づいて構築されています。
これらの概念は、プログラミング・モデルの基礎となります。それでは、それぞれの概念について詳しく見ていきましょう。 コンテンツ ユーザーの作業対象となるすべてのものは、何らかの形式を取るコンテンツと考えられます。IBM Workplace プラットフォームは、複合コンテンツを操作する (そして、それに関連したコラボレーション機能を活用する) ためのフレームワークをユーザーに提供します。私たちの定義に基づくと、文書ライブラリー、Domino データベース、メール・メッセージ、Instant Messaging のメッセージ記録、Microsoft Word 文書、ニュース項目、WebSphere Portal ページなどは、いずれもコンテンツとなりえます。 コンテンツの各インスタンスは、次に示すいくつかのコア・メタデータ・プロパティーを持っています。
指定されたコンテンツのインスタンスの URI とは、タイプ ID とインスタンス ID とバージョン ID (省略可能) を加えたものです。バージョン番号は省略可能で、省略された場合は、コンテンツの最新のアクティブ・バージョンが使用されます。IBM Workplace では、この URI を WPID と呼びます。WPID を使用すると、さまざまなシステムで生成された ID を柔軟に表すことができます。 コンテンツの各インスタンスは、それ自身に関する定義を持っています。定義の形式は、コンテンツタイプに特有のものです。コンテンツは、他のコンテンツを参照する、または含むことができます。コンテンツが他のコンテンツを含むとき、含まれているコンテンツの定義は、含んでいるコンテンツ (コンテナ) の定義に沿って管理されます (これが、参照と包含の相違点です)。 各コンテンツタイプは、それ自身に関連する 1 つ以上のサービスのリストを宣言します。特定のコンテンツタイプは、それ自身が含むまたは参照することができるコンテンツタイプとしてのサービスのリストを指定できます。各コンテンツタイプは、Render サービスという 1 つのサービスを必ず実装しなければなりません。これ以外にも、オプションの定義済みサービスとして、Lifecycle サービス、Template サービス、Membership サービス、Search サービスなどがあります。コンテンツタイプは、サポートするサービスのリストにこれらのサービスを含めることも、含めないこともできます。 各コンテンツタイプは、それに関連するユーザー役割の特定のセットを持っています。これらのユーザー役割は、コンテンツタイプでのアクセス権セットと結び付けられています。コンテンツは、動的に生成してシステムに追加することができます。コンテンツは永続的または一時的のどちらも可能で、ユーザー用にパーソナライズすることにより、ユーザー自身がコンテンツの動作をカスタマイズできます。また、各コンテンツタイプはそれに関連する測定値を持っています (リソース管理に使用されます)。これには、サイズ、最終アクセス時刻などが含まれます。 コンポーネント コンポーネントは、特定のコンテンツタイプのために特定のサービスを実装します。たとえば、コンポーネントは、Mail コンテンツタイプのために、Render サービスや Search サービスを実装できます。 コンポーネントは、それに関連するコンテンツタイプのために、自分自身を特定のサービスのプロバイダーとして (拡張ポイントを使用して) 動的に登録します。複数のコンポーネントが 1 つの特定のサービスを実装することはできますが、特定のコンテンツ・インスタンスに対し、特定のサービスのプロバイダーとして同時に登録できるのは 1 つのコンポーネントだけです。たとえば、Document Library コンテンツタイプ用に Render サービスがあります。この情報は、Content Type Registry と呼ばれるレジストリで維持されます。 各コンポーネントに特有の状態は、コンテンツの各インスタンスと共にプラットフォームによって維持されます。たとえば、PortletSession はポートレットのユーザー対話の状態を維持するために使用でき、URL にはコンポーネントによって使用される状態が含まれることがあります。コンポーネントは拡張ポイントを介して拡張できるので、コンポーネントを変更せずに、新しい機能を既存のコンポーネントに追加できます。 コンポーネントは、他のコンポーネントが実装できる新しいサービスを定義できます。これにより、他のコンポーネントはこのコンポーネントと統合できます。たとえば、Search Federator コンポーネントは Search サービスのインターフェースを定義できます。他のコンポーネントは、フェデレーテッド・サーチと統合するためにこのインターフェースを実装する必要があります。コンポーネントは、それ自身に関連する構成も持っています。 コンポーネントは、イベントを発行したり受け取ったりすることができます。これらのイベントは、コンポーネントによって管理されているコンテンツへの変更、または状態の変更によって起動されます。ここで重要なことは、イベントを発行するのは、コンテンツではなくコンポーネントである点です。ただし、イベントはコンテンツと関連しています。 コンポーネントは、他のコンポーネントによって提供されたサービス (たとえば、WebSphere Member Manager などのディレクトリー・サービス) に依存することもできます。また、コンポーネントはその実装を特定のサービスに依存することもできます。たとえば、Siebel ポートレットは Siebel Mediator サービスに依存します。 コンポーネントは、さまざまなテクノロジーを使用して実装できます。これには、ポートレット、ステートレス・セッション Bean、Web サービス、ポートレット・サービス、POJO サービス、Eclipse プラグイン、OSGi サービス、SCA コンポーネントなどがあります。コンポーネントとサービスの関係を図 1 に示します。 図 1. コンポーネントとサービスの関係  テンプレート テンプレートはコンテンツタイプの 1 つで、コンテンツの基本特性を保持します。テンプレートは、複合コンテンツの新しいインスタンスを作成するための命令セットです (XML ファイルで表されます)。 テンプレートは、変更可能点 (POV: points-of-variability) を含みます。POV は、コンテンツの新しいインスタンスの生成時に使用されるテンプレート・インフラストラクチャーへの入力 (ユーザーが提供または自動入力) を表します。これらの POV 値は、コンテンツのインスタンス生成時に、パラメーターとしてコンポーネントに渡されます。 テンプレート・インフラストラクチャーは、コンテンツタイプに特有の作業を実行するために、Templateable サービスを実装しているコンポーネントを使用します。たとえば、Document Library コンテンツタイプに定義された Templateable サービスは、テンプレート化する目的 (たとえば、POV の取得とテンプレートへのシリアライゼーション) のために文書ライブラリーと対話します。テンプレート、コンポーネント、コンテンツの関係を図 2 に示します。 図 2. テンプレート・インフラストラクチャー、コンポーネント、コンテンツの関係 
複合アプリケーション「複合アプリケーション」とは、コンポーネントの複合を基本構造モデルとして持つアプリケーションのクラスのことです。このようなアプリケーションを作成するには、カタログからコンポーネントを選択して設計サーフェス (design surface) に配置し、コンポーネント間を相互接続し、目的の動作を作成します。IBM Workplace プログラミング・モデルでは、この設計サーフェスをページと呼び、相互接続をワイヤーと呼びます。さらに、アプリケーションを表すアイテムの集まり全体を複合アプリケーションと呼びます。このモデルのもう 1 つの重要な特長は、アプリケーションの状況に応じたビューを持つことです。これらのビューは、アプリケーションでのユーザーの役割とアプリケーションのビジネス・プロセスの状態という 2 つの主要概念に基づいて構築されます。最初の概念では、ユーザーの役割によって、ナビゲーションのどの部分 (たとえば、アプリケーション内のどのページ) を表示するかが決められます。2 番目の概念は同じモデルに従いますが、複合アプリケーションによって使用されるビジネス・プロセスの現在の状態に応じて、ビジネス・シナリオを達成するためにどのコンテンツとコンポーネントを表示するのかが決められます。表示内容を制御するこの 2 つの方法は、結局のところ、作業をなしえるために最適なツールをユーザーに与えるだけでなく、複合アプリケーションを使用する主な動機となります。 開発者は、コード・ライブラリー、オブジェクト指向のクラス・ライブラリー、およびその他のメカニズムを用いて再利用を実現してきましたが、ポータルの出現 (および、ポータルでのコンポーネント・モデルの標準化) により、アプリケーションを複合化するための新しく、より柔軟なメカニズムがもたらされました。これにより、独立ソフトウェア・ベンダー (ISV) と企業内の開発者は、標準コンポーネント・モデルに基づいてコンピューティング資産を再利用するより良い方法が得られます。 このフレームワークを構成する複合アプリケーションは、次のようなさまざまな特徴を持っています。
コンポーネントの Render サービス Render サービスは、IBM Workplace プログラミング・モデルにおける基本的な UI 構築ブロックです。このサービスは、次の 2 つの形式でもたらされます。
どちらのサービスも、その環境に特有のプログラミング・モデルに適合します。 ポートレット ポートレットは、Web ポータルの基本的な UI 構築ブロックです。ポートレットは、ライフサイクル、ユーザーごとのカスタマイゼーション、集約、他のコンポーネントとの統合などの共通機能を管理するコンテナー内に存在します。このコンテナーは、ポータル・コンテナーと呼ばれます。ポートレットは、J2EE Servlet API に基づく JSR 168 Portlet API と呼ばれる標準 API を使用して構築されます。 表示パート 表示パートは、リッチクライアント UI の基本的な UI 構築ブロックです。表示パートは、ライフサイクル、ユーザーごとのカスタマイゼーション、集約、他のコンポーネントとの統合などの共通機能を管理するコンテナー内に存在します。このコンテナーは Eclipse Workbench と呼ばれ、表示パートは Eclipse フレームワークを使用して構築されます (図 3 参照)。 図 3. ポータル・コンテナーとコンポーネントを含む Eclipse Workbench の関係  ページ ページはコンテンツタイプの 1 つで、コンテンツの基本特性を保持します。ページの主な目的は、コンポーネントの Render サービスへの設定済み参照の集まりをレイアウトすることです (たとえば、WebSphere Portal Server では Render サービスはポートレットと呼ばれ、リッチクライアントでは表示パートと呼ばれます)。各ページはナビゲーションに表示される指定可能なコンテンツの一部です。各ページによって、行および列方向にコンポーネントをどのようにレイアウトするのかが定義されます。ページが選択されると、対応する Render サービス (たとえば、Portlet JSR 168 API、Eclipse View API) の呼び出しを介して UI が収集され、ページがレンダリングされます。ページがコンテンツであることに加え、コンポーネント参照もまたコンテンツです (図 4 参照)。 図 4. ページでのコンポーネントの使用方法  プロパティー・ブローカー 1 つのコンポーネントを介してビジネス・データとオペレーションを公開することには多くの価値がありますが、コンポーネント同士を連携することでより大きな価値を得られます。複合アプリケーションでは、コンポーネントは、相互のデータ交換、データへの反応、イベントの起動、イベントへの応答を行う必要があります。各コンポーネントは、他のコンポーネントの実装に影響を与えることなく、ページに追加したり、ページから削除できます。このレベルの連携を実現するメカニズムをプロパティー・ブローカーと呼びます。 プロパティー・ブローカーを利用すると、コンポーネントはその型付けされたデータ・アイテムをイベントとして公開し、他のコンポーネントによって公開されたデータ型に基づいて、実行したいアクションを宣言できます。 プロパティーを提供するコンポーネントはソース・コンポーネントと呼ばれ、ソース・コンポーネントが公開するプロパティーは出力プロパティーと呼ばれます。一方、プロパティーを受け取るコンポーネントはターゲット・コンポーネントと呼ばれ、ターゲット・コンポーネントによって受け取られるプロパティーは入力プロパティーと呼ばれます。プロパティー・ブローカーを利用すると、ターゲット・コンポーネントは受け取るプロパティー/データに基づいてアクションを提供できます。これにより、コンポーネント間で状態とワークフローの調整が可能になり、私たちの複合モデルが大幅に機能拡張され、サポートが強化されます。 プロパティーは、ワイヤーの作成を介して相互に接続されます。このワイヤーは、1 つのコンポーネント参照で定義されたプロパティーを他のコンポーネント参照内のプロパティーに接続するために使用されます (図 5 参照)。2 つのプロパティー間で唯一共通しなければならないのは、データ型です。たとえば、あるコンポーネント内のカスタマー ID を別のコンポーネント内の検索キーに接続できます。最初のコンポーネントが現在のカスタマー ID を発行するたびに、プロパティー・ブローカーはその文字列を検索キーと呼ばれるプロパティーに変換し、2 番目のコンポーネントに通知します。2 番目のコンポーネントはその状態を更新し、検索キーの検索結果を表示します。 図 5. ワイヤーで相互接続された 2 つのコンポーネント  最後に、ワイヤーについて考慮すると、ワイヤーもコンテンツタイプの 1 つであり、コンテンツの基本特性を保持しています。プロパティー・ブローカーは、ワイヤーに保存されている情報に基づいてコンポーネントと対話します。プロパティー・ブローカーとの対話は、コンポーネントの PropertyListener サービスと PropertyProvider サービスを介して行われます (図 6 参照)。 図 6. プロパティー・ブローカーとコンポーネントの関係  コミュニティー ほとんどすべての複合アプリケーションでは、ユーザーは必然的に複合アプリケーションと対話したり、複合アプリケーションを使用します。通常、これらのユーザーは、自分自身が誰であり、何ができるのかを示す明確な役割を持っています。しかし、複合アプリケーションの場合は、特定の役割モデルを持つ任意のコンポーネントを複合用のコミュニティー役割のセットに対応させる必要があります。 このような状況で、各コンポーネントは、ユーザーに割り当てることができる独自の役割のビューを持っています。たとえば、ディスカッション・コンポーネントを構築して、Moderator 役割と Contributor 役割を理解することができます。これらの役割は、コンポーネント役割と呼ばれています。しかし、このディスカッション・コンポーネントを仮想クラスルーム複合アプリケーションで使用したい場合もあります。複合アプリケーションの観点から見ると、ユーザーに割り当てられる役割は Teacher と Student です。これらの役割は、コミュニティー役割と呼ばれています。複合アプリケーションを設計するときは、コミュニティー役割をコンポーネント役割にマッピングすることが必要です。たとえば、Teacher を Moderator にマッピングし、Student を Contributor にマッピングします。このマッピングをコミュニティー役割のマッピングと呼びます。以上のことは、コミュニティーと呼ばれる別の重要な概念を表しています (コミュニティーは、「メンバーシップとアプリケーションの役割」と呼ばれることもあります)。 通常、コンポーネント役割が割り当てられるのは、コンポーネント自体ではなく、コンポーネント内のコンテンツのインスタンスであることを理解することが重要です。これは、J2EE 役割の場合です。 コミュニティーはコンテンツタイプの 1 つで、コンテンツの基本特性を保持します。コミュニティーは、コンテンツのインスタンスに関連するユーザーの情報を取得します。コミュニティー内の各アイデンティティー (ユーザーまたはグループ) は、役割 (コミュニティー役割) を割り当てられます。この役割は、アイデンティティーが他のコンテンツで受け取るアクセス権を定義します。これを役割マッピングと呼びます。最後に、コミュニティーは、それ自身が関連するコンポーネントの Membership サービスを介してコンテンツと対話します (図 7 参照)。 図 7. コミュニティーとコンポーネントの関係  コンテキスト 複合アプリケーションの特定のインスタンスで、コンテンツの集まりが作成され、アプリケーションに結び付けられます。たとえば、仮想クラスルーム・アプリケーションでは、ページの集まりが作成されます。ページの 1 つに、ディスカッション・フォーラムのインスタンス (つまり、コンテンツ) をレンダリングするディスカッション・フォーラム・コンポーネントが含まれることがあります。この例では、アプリケーションに関連するすべてのコンテンツは、「コンテキスト」と呼ばれるものの中で維持されます。コンテキストの目的は、ユーザーのコミュニティー、ワイヤー、すべてのコンテンツへの参照など、複合アプリケーションに関するすべてのものを取得することです。そして、参照そのものも、参照に関する追加メタデータを含むことができます (たとえば、コンテンツのライフサイクルが、コンテキストのライフサイクルに結び付けられているかどうかなど)。 コンテキスト自体はコンテンツタイプの 1 つで、コンテンツの基本特性を保持し、複合アプリケーションに関するすべての「接合」情報を取得します。コンテキストは、さまざまなサービスを介してコンテンツと対話します。たとえば、Introspection サービスを使用してコンテンツに関するメタデータを取得したり、Lifecycle サービスを使用して、ライフサイクルがコンテキストに結び付けられているコンテンツを削除します。 図 8. コンテキストとコンポーネントの関係  複合アプリケーション 次に、複合アプリケーションそのものについて説明します。複合アプリケーションはコンテンツタイプの 1 つで、コンテンツの基本特性を保持します。複合アプリケーションは、コンテキストを使用して複合アプリケーション (参照、ワイヤー、およびコミュニティー) に関するすべての「接合」情報を取得します。しかし、複合アプリケーションは、その内部に 1 つのコンテンツタイプを含める必要があります。それはページであり、ページはコンテキストに対する指定可能なユーザー・エクスペリエンスを表すために使用されます。複合アプリケーションのすべてのコンポーネントと、その相互関係を図 9 に示します。 図 9. 複合アプリケーションのコンポーネント  複合アプリケーションは、疎結合のコンポーネントのセットから次の方法で組み立てられます。
通常、複合アプリケーションへのナビゲーションは、複合アプリケーションのカタログ UI を介して実現されます。たとえば、チームスペースの場合は、各チームスペースが複合アプリケーションです。チームスペースには、ユーザーがアクセスできるチームスペースのリストを表示するチームスペース・カタログ・ポートレットからアクセスします。チームスペースを訪れるためにユーザーがカタログ内のエントリーをクリックすると、複合アプリケーションが適切な方法で開かれます (図 10 参照)。 図 10. カタログ内の複合アプリケーション  複合アプリケーションのもう 1 つの重要な特徴として、複合アプリケーションがカテゴリーに分類されていることが挙げられます。これらのカテゴリーは、関連するアプリケーションをグループ化する目的を持つとともに、複合アプリケーション用の重要な組織構造でもあります。カテゴリーはフォルダーのように機能するので、特定のカテゴリーでアプリケーションを検索できます。しかし、カテゴリーは定義済みのセットだけに限定されず、ユーザーが定義し、カスタマイズすることも可能です。複合アプリケーションがカテゴリー内に存在するのと同様の方法で、複合アプリケーションを作成するテンプレートも同じ論理カテゴリー内に存在します。たとえば、チームスペース・カテゴリーには、すべてのチームスペース (チームスペース・カテゴリーに含まれる複合アプリケーション) とチームスペース・テンプレート (チームスペース・カテゴリー内のアプリケーションの作成に使用されるテンプレート) が論理的に含まれています。 図 11. カテゴリーに分類された複合アプリケーションとテンプレート  この時点で、プログラミング・モデルを構成する重要な概念について明確に理解することができました。それでは、テンプレートが複合アプリケーションにどのように適用されるのかを見ていきましょう。
テンプレートと共にすべてを配置するテンプレートは、複合コンテンツ (たとえば、複合アプリケーション) のインスタンスを生成する命令のセットです。前述のように、複合アプリケーションで表されるすべての部分は、実際にはコンテンツなので、テンプレートに加えることができます。つまり、複合アプリケーションのテンプレートには、ページ、コミュニティー、ワイヤー、コンテキスト、その他のコンテンツ (複合アプリケーション内でコンポーネントを機能させるのに必要なもの) を作成するために必要な命令が含まれています。また、テンプレート内のコンテンツの各部分はコンポーネントを意味していて、各コンポーネントは、テンプレートのインスタンス生成時に必要な POV の定義に寄与します。複合アプリケーションとテンプレートのライフサイクルを図 12 に示します。 図 12. 複合アプリケーションとテンプレートのライフサイクル  各部分が相互にどのように連携するのかを明らかにするために、テンプレートのインスタンス生成の流れを調べましょう。典型的な流れとしては、エンド・ユーザーが何らかの UI (通常は、アプリケーション・カタログによって表されます) でテンプレートを使用して、アプリケーションのインスタンス生成を選択することから開始します。テンプレートの XML 定義がロードされ、プラットフォームのテンプレートのインスタンス生成サービスへと渡されます。このサービスはテンプレート XML を解析し、コンポーネントによって構成されているすべての POV を抽出します。 値を持たず、ユーザーによる入力が必要なすべての POV 用に、エンド・ユーザーから値を取得する UI が提供されます。ユーザーはフォームに入力し、POV 値を送信します。これで、テンプレート・インフラストラクチャーは、テンプレートを実現するために必要なすべてのものを入手したことになります。テンプレートのインスタンス生成サービスは、テンプレート内の各コンテンツの定義に順番にアクセスし、対応するコンポーネントの Lifecycle サービスを (POV の正しいサブセットと共に) 呼び出します。次に、コンポーネントは渡された情報と POV 値を使用して、自分自身のコンテンツのインスタンスを生成し、新たにインスタンス生成されたコンテンツの識別子を送り返します (コンポーネント間のインスタンス生成の順序とデータの流れについて、これ以外の詳細な情報がありますが、この記事では取り上げません)。このプロセスが完了すると、複合コンテンツが作成されます。これが、複合アプリケーションを表します。 テンプレートのインスタンスが複合アプリケーション内に生成された後、ユーザーはテンプレート/アプリケーション・エディターを使用して、テンプレートを編集および更新することができます (「ツール」セクションで後述します)。このツールは複合アプリケーションのインスタンスを更新する目的を持ち、コンポーネント、ワイヤー、ページ、役割およびコンテンツの追加/削除を可能にします。 テンプレートは、ベスト・プラクティスの再利用を可能にする繰り返しパターンの作成に常に用いられます。一般的に、テンプレートはプロトタイプを使用して作成されます。たとえば、通常、適切に書式設定され、セクションが配置された既存の文書から文書テンプレートが作成されます。また、既存のデータベースからは Domino データベース・テンプレートが作成されます。IBM Workplace 製品のテンプレートは、プロトタイプを再利用するこのパターンに基づいて構築されます。つまり、テンプレートのシリアライゼーション・サービスを介して既存のコンテンツの一部を再利用可能なパターンに変換することにより、テンプレートを作成します。複合アプリケーションのテンプレートの場合も、既存のアプリケーションからテンプレートを作成できます。 テンプレート・エディターは、ユーザーが現在のアプリケーションからテンプレートを生成することを可能にする UI です。アプリケーション ID は、要求に応じて、テンプレートのシリアライゼーション・サービスに渡されます。次に、複合アプリケーション内のすべてのコンテンツに順番にアクセスし、コンテンツの新規インスタンス (現在のインスタンスに似ているインスタンス) の作成に使用する XML フラグメントを返すよう各コンテンツに求めます。これは、各コンテンツのコンポーネントの Templateable サービスを呼び出すことによって行います。結果として、新しい複合アプリケーションの作成に必要なすべての XML を含む 1 つの XML ファイルが得られます。POV も同様に扱われます。Templateable サービスを使用して、シリアライゼーション・プロセスの一部として POV 用のコンテンツを検索します。 テンプレート・インフラストラクチャーとコンポーネントの関係を図 13 に示します。 図 13. テンプレート・インフラストラクチャーとコンポーネントの関係 
ランタイム表示このセクションでは、ブラウザーとリッチクライアントの両方で、ランタイム上でどのように表示されるのか説明します。ブラウザーの場合、ユーザーはアプリケーションのカタログから選択することで、複合アプリケーションにアクセスします。選択することにより、WebSphere Portal サーバーに HTTP リクエストが発行されます。サーバーは発行されたリクエストを解釈し、レンダリングするアプリケーションとページを決定します。選択されたページ定義に基づいて各コンポーネントの Render サービスが呼び出されます。これらのサービスは、プロパティー・ブローカーとワイヤーを使用して相互に対話します。すべてのコンポーネントが自分自身のコンテンツのレンダリングを完了すると、結果が 1 つの集約ページにまとめられ、HTML としてブラウザーに送り返されます (図 14 参照)。図 14. Web ブラウザーにレンダリングされた複合アプリケーション  リッチクライアントもブラウザーと同様の方法で動作しますが、HTML をブラウザーに返す代わりに、ページ、ワイヤー、およびコンポーネントの XML 記述がリッチクライアントに返されます。この XML 記述を Rich Client Platform Markup Language (RCPML) と呼びます。この場合、クライアントのランタイムは RCPML を解釈し、複合アプリケーション内の各アプリケーションに対し、クライアントサイドのコンポーネントを使用することにより、クライアント上で複合アプリケーションを作成します (図 15 参照)。 図 15. リッチクライアントにレンダリングされた複合アプリケーション  クライアントだけに見られる追加の特徴として、アプリケーションに対応するコンテンツをクライアントのローカル・ストアに複製する機能があります。これにより、オフラインでアプリケーションを使用できるようになります。
ツールIBM Workplace 製品をサポートする開発ツールにとって、統一されたプログラミング・モデルは大きな資産となります。数多くの異なるツールを統合することに時間と手間を費やすことなく、開発者は単一のモデルを想定し、そのモデルを活用するツールを作成できます。そして、設計目標とニーズに応じて、幅広いオプションをユーザーに提供することに注力できます。各ツールによって作成された成果物は、共有し、再利用することができます。さらに、図 16 に示すように、すべてのツールは単一のランタイムをターゲットにすることが可能です。図 16. 複合アプリケーションおよびコンポーネントの構築に使用されるツール  専門知識を有するユーザーは、プログラミングの経験がまったくない、またはほとんどない場合でも、テンプレート・ビルダーを使用して、ランタイムをカスタマイズしたり、簡単なフォームのテンプレートを構築できます。これに対し、迅速なアプリケーション開発環境を必要とする企業開発者は、IBM Workplace Designer を使用できます。また、ソリューション開発者は IBM Rational Tool や IBM Workplace Toolkit などの幅広いツールを使用し、コーディングを介して究極の自由度を得ることができます。 これらのツールによって構築したコンポーネントは、複合アプリケーションへ組み込み、プロパティー・ブローカーによって相互接続し、最終的にさまざまなターゲット・クライアントにデプロイすることができます。
次のステップは？この記事では、IBM Workplace プログラミング・モデルについて解説し、このプログラミング・モデルが複合アプリケーションの概念をどのように変革したのかを明らかにしました。複合アプリケーションのモデルを正しく認識し、IBM Workplace がこのモデルをサポートすることにより、インターネットおよびイントラネット・アプリケーションの迅速な開発とデプロイメントがどのように実現されるのかをご理解いただけたと思います。
リソース学習
筆者について（原文のまま）Sami Shalabi is a Senior Software Engineer with the IBM Workplace server team, based in Westford, Massachusetts. He is the lead architect of the collaborative application infrastructure and has been with Lotus/IBM since the late 1990s. Previous to Lotus Workplace, Sami has worked on both Lotus QuickPlace and Lotus Domino. Sami holds both Bachelors and Masters degrees in Electrical Engineering and Computer Science from MIT.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
