 |
|
|||||||||||||||||||||||||||||||||||||||||||
IBM Workplace Collaboration Servicesの内部構造IBM Workplace Collaboration Servicesを構成するレイヤーを調べる |
||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||
Bob Balaban, Executive Consultant, IBM レベル：初級 原文の掲載：2006年01月31日 更新日：2006年12月15日更新  原文はこちら (US)
長い間IBM Lotus Notes/Dominoを使用しているユーザー(特に、単なる電子メール以上の使い方をしているユーザー)は、その豊富な機能と強力なプラットフォームにより、あらゆる種類のコラボレーティブ・アプリケーションを作成できることをよく理解しています。しかし、Lotus Dominoベースのアプリケーションのパワーと、IBMのJ2EE(Java 2, Enterprise Edition)フレームワークおよびその製品群を組み合わせることで、どのような利点を得られるのかを認識しているユーザーは多くありません。また、一部の人々には、3つの主要J2EE製品である、IBM WebSphere Application Server、IBM WebSphere Portal、およびIBM Workplace Collaboration Servicesの実際の違いが明確に知られていないようです。多数のIBM製品がWorkplace製品ファミリーとして提供されています。この記事では、Workplace Collaboration Servicesとそれを構築するもとになるアーキテクチャーについて取り上げます。 この記事の目的は、これらの3つのJ2EE製品が実際にどのようなレイヤーで積み重ねられ(下から、WebSphere Application Server、WebSphere Portal、Workplace Collaboration Servicesの順)、1つのまとまりを形成しているのかを明らかにすることです。また、Lotus Dominoをこれらの各レイヤーと統合する方法の概要や、各タイプの統合で解決しなければならないさまざまな問題についても解説します。 さらに、Lotus DominoとJ2EEに関してはサーバーサイドの統合が話題になりますが、今後1、2年でLotus Notes ClientがどのようにJ2EEリッチ・クライアントへと進化するのかについても概要を示します。 技術的基盤:J2EEとWebSphere Application Serverそれでは、多くの人々が問うのをためらう「J2EEとは何か?」という質問から始めましょう。J2EEは、Sun Microsystems社が所有する、Javaベースのプラットフォームまたはフレームワークの仕様であり、この上でWeb指向のアプリケーションが実行されます。IBMなどの多くのベンダーがこの仕様に適合する製品を実装していますが、J2EEは製品ではありません。もちろん、J2EEは宗教ではなく、状況に応じて使用するツールです。 J2EE全体の構想は、アプリケーションをホスティングするための、ベンダー・ニュートラルな(したがって、システムに依存しない)方法を提供することです。J2EEは、アプリケーションのメタモデル(アプリケーションの構築に使用するコンポーネントとツールのセット)と、アプリケーションの実行を支援するサービスの集まりで構成されるプラットフォーム(一連のJava API)を提供します。 このプラットフォームは、その上でホストするアプリケーションにパフォーマンスとスケーラビリティーを与えるよう設計されています。パフォーマンスの点はかなり明確です。人々は、J2EE基盤上で実行するアプリケーションに十分なパフォーマンスを望んでいます。スケーラビリティーは少しわかりにくいですが、一般的には、パフォーマンスまたは応答時間を大幅に低下させずに、システムの負荷を高める(たとえば、ユーザーの追加やトラフィックの増加など)方法を持つことを意味します。一般にJ2EEが、特にWebSphere Application Serverがこれをどのように実現するのでしょうか。図1に、基本的なJ2EEアプリケーション・サーバーのアーキテクチャーの概要を示します。 図1.重要なコンポーネントを示す基本的なJ2EEアーキテクチャーの図 最初はこの図に少し圧倒されるかもしれませんが、主要なコンポーネントを異なる色の円で囲むことにより、全体像がより説明しやすい部分に分けられています。 左側の緑色の円は、「Applet container」と「Application client container」と記されたボックスを囲んでいます。これは、システムのクライアント・サイドを表します。この2つのボックスは、HTTP矢印とSSL矢印を介して「Web Container」ボックスに接続されています。これは、Javaクライアント(スタンドアロンのJavaアプリケーションまたはブラウザー・ベースのアプレット)がHTTPワイヤー・プロトコルを使用してJ2EEプラットフォームとコミュニケートすることを示します。特定のアプリケーションURLをアプリケーション・コンポーネントの「アドレス」に変換し、コマンドを適切にルーティングすることは、プラットフォームの役割です。 開発者が作成する実際のビジネス・コンポーネントは、オレンジ色の円で囲まれています。JavaServer Pages(JSP)とサーブレットは、URLで直接アドレスを指定できます。一般的に、JSPとサーブレットは、さまざまな種類の入力(バックエンド・システムへのデータ照会など)を処理し、その結果を要求元のクライアントにレンダリングします(多くの場合、HTML形式またはXML形式です)。JSPとサーブレットはWebコンテナー(Web Container)のコンテキストで実行され、これらの集まりは、イメージ・リソース、他のJavaクラス(JavaBeans)、および構成設定と相まって、Webアプリケーションと呼ばれるものを形成します。 他のタイプのJ2EEビジネス・コンポーネントで開発者によるプログラミングが可能なEnterprise JavaBeans(EJB)は、これとは少し異なります。EJBはWebコンテナーでは実行されませんが、代わりにEJBコンテナー(EJB Container)でのホスティングを必要とします。EJBとWebアプリケーションでそれに対応するものとの間の多数の違いには触れませんが、簡単に述べると、 EJBはデータベース・トランザクションの管理とリレーショナル・データベースからの読み取りおよび書き込みを指向しています。Webコンポーネント(JSPとサーブレット)とEJBを組み合わせたアプリケーションは、エンタープライズ・アプリケーションと呼ばれます。JSPとサーブレットだけで構成されるアプリケーションを持つことはできますが、EJBには、それ自身を呼び出すためのJSPまたはサーブレットが必要です。WebクライアントをWebコンテナーに接続する矢印とは異なり、WebコンテナーをEJBコンテナーに接続する矢印は、HTTPプロトコルを表していません。HTTPの代わりに、より複雑でセッション指向のIIOPというワイヤー・プロトコルが使用されます(これは、Lotus Domino CORBAクラスが使用するものと同じIIOPトランスポートです)。 最後に、青色の円は、すべての主要なJ2EEアプリケーション・サーバー製品がサポートする共通APIサービス・レイヤーを示します。このレイヤー内の各ボックスは、標準化された次のJava APIを表します(すべてのJava APIを示すリストではありません)。
Webコンテナーのサービス・レイヤーとEJBコンテナーのサービス・レイヤーが同じであることに気付いた方もいるでしょう。これは偶然ではなく、どちらのコンポーネントのセットも、機能を実行するために同じサービスを使用できます。 ビジネス・アプリケーションを作成するには、必要に応じて、JSP、サーブレット、またはEJBを記述します(あるいは、IBMのRational Application Developerなどのツールを利用して、これらのコンポーネントを生成します)。次に、パッケージにまとめたコンポーネントをアプリケーション・サーバーにデプロイします。デプロイ後、アプリケーションはURL呼び出し(JSPまたはサーブレット)またはIIOP要求(EJB)に応答し、処理を実行します。 WebSphere Application Serverプラットフォームは、数多くのアプリケーション・サービス(データベース接続、ディレクトリー・サービス、メッセージ・キューなど)を提供することにより、これらのコンポーネントが適切に実行されるようにします(ただし、効率のよいコードを書くことなど、一部は開発者の負担となります)。これによって、アプリケーション開発者はこれらのサービスのコードを書くことから解放され、アプリケーション・コンポーネントをJ2EEの別の実装に移行する可搬性が高まります。これらのすべてのサービスが標準化されているからです。 また、WebSphere Application Serverは、お客様のアプリケーションにスケーラビリティーを与えるように設計されています。実際に、これは何を意味するのでしょうか。もし、アプリケーション(および、それが実行されるプラットフォーム)が外部の負荷(たとえば、ユーザーの増加など)に対して敏感な場合は、コンポーネントのコードをいっさい変更せずに、アプリケーションの各部を複数のコンピューターに分散することにより、CPUのボトルネックを解消できます。おそらく、このことはJ2EEのようなアーキテクチャーの最大の価値でしょう。つまり、一例として、JSPとサーブレットを1つのコンピューターに配置し、EJBを別のコンピューターに配置することも可能です。接続はすべてWebSphere Application Serverによって管理されるため、コードの変更はまったく必要ありません。このため、スケーラビリティーの調整は(アプリケーションが適切にコーディングされているものとして)、主に開発者のタスクではなく、システム管理者のタスクとなります。もちろん、1つのアプリケーション用のコンピューターの数を増やしすぎても、ネットワークのオーバーヘッドの負荷が潜在的に高まるので注意が必要です。1つですべてを解決できる方法はありません。 これまでに、IBM WebSphere Application Serverとは何か、これがパフォーマンスとスケーラビリティーの観点でどのようにアプリケーションに利点を与えるのかについて、簡単にまとめました。WebSphere Application ServerはIBM WebSphere PortalとIBM Workplace Collaboration Servicesの両方の基盤となるレイヤーであるため、この点をまとめておくことは重要です。 では、これはLotus Dominoにとってどのような意味を持つのでしょうか。これは複雑な問題で、私たちはこの点についてさまざまな角度から多数の記事を書いてきました。簡単に全体像を答えると、Lotus Dominoが持つ豊富でコラボレーティブなアプリケーション機能をWebSphere Application Serverのスピードおよびスケーラビリティーと正しく組み合わせると、大きな利点を得られる可能性がある、ということです。Lotus Dominoは、ワークフロー、プログラム機能、データ統合、および迅速なアプリケーション開発のすべての面でたいへん強力で優れていますが、アプリケーションの非常に大きな負荷をさまざまな理由で処理できないことがあります。特に、Webエージェントは、使用状況が非常に高水準のときに弱点となります。これは、URL呼び出しを受けるたびに、NSFからターゲット言語のインタープリター(LotusScript、Java、@関数など)にエージェントが新たにロードされるからです。これに対し、WebSphere Application ServerのJSPとサーブレットは一度だけロードされ、そのコードはWebコンテナーのJava仮想マシン内に常駐します。同時の要求は、異なるJavaスレッドに簡単に呼び出されます。 これは、次のことを意味しています。負荷が高い状況でLotus Domino Webアプリケーションのパフォーマンスが低下する場合は(主に、ビジネス・ロジックにWeb Query OpenエージェントとWeb Query Saveエージェントが使用されている場合)、Web Query OpenエージェントまたはWeb Query Saveエージェントの一部をWebSphere Application Serverで実行されるサーブレットとしてコーディングし直すことにより、パフォーマンスが改善される可能性があります。もちろん、これを行ってもLotus Dominoの重要な機能は失われず、Lotus Domino Javaクラスを使い続けることができます。 結論:パフォーマンスの問題を抱えている場合は、Lotus Domino WebアプリケーションとWebSphere Application Serverを統合することに意味があります。WebSphere PortalとWorkplace Collaboration Servicesを理解すると、Lotus Dominoをこれらの製品と統合することにより、さまざまな問題を解決できることがわかるでしょう。
WebSphere Portalレイヤー:集約されたUIとデバイスからの独立性WebSphere Application Serverがパフォーマンスとスケーラビリティーに関するものであるのに対し、WebSphere Portalはユーザー・エクスペリエンス(UIと呼ばれていました)に関するものです。WebSphere Portalの主な付加価値は次のとおりです。
実際に、IBM WebSphere PortalはWebSphere Application Serverアプリケーションです。これは、JSP、サーブレット、およびEJBの集まりで、WebSphere Application Server構成上にデプロイされています(他のPortal製品も、関連するアプリケーション・サーバー・プラットフォーム上で同様に動作します)。Portalコードによって、開発者はバックエンド・アプリケーションの各タイプごとに個々のポートレットをインプリメント(または、既製のものをデプロイ)することができます。実際に、ポートレットは単に特殊化されたサーブレットであり、その目的は、特定のバックエンド・アプリケーション(Lotus Dominoデータベース、Webサイト、Lotus Domino Webメールなど何でもかまいません)にアクセスし、そのアプリケーションのレンダリングをWebSphere Portalに提供することです。次に、Portalはこのようなすべてのレンダリングを複数の領域を持つ画面に集約し、ユーザーに表示します。いくつかのサンプル・ポートレットが表示されたブラウザーのPortal画面の例を図2に示します。 図2.複数のアプリケーションが画面上に集約されたサンプルのPortalのスクリーン・ショット ポートレットはどこから入手するのでしょうか。IBM Workplace Soluations catalogでは、多くのポートレットを無料で利用できます(無料でないものもあります)。ここで必要なものが見つからない場合は、次に簡単な方法として、IBMや他のベンダーから提供されているポートレット構築ツールを使用します。これらのツールはコードを直接操作しないインターフェースを持っていて、ポートレットが何をするのかをユーザーが記述すると、自動的にそのコードが作成されます。 このツールでもニーズを満たせない場合は、IBMが提供するEclipseベースの開発環境であるIBM Rational Application Developerを使用して、独自のポートレットを作成します。Rational Application Developerには、Portalのテスト環境、多数の組み込みツール、ポートレットの構築作業を容易にするウィザードが含まれています。 ポートレット・モデルの長所は、各アプリケーションが、画面全体を占有しているかのように動作できることです。ポートレットの役割は、バックエンド・アプリケーションへのフックを提供し、そのアプリケーションのレンダリング(通常は、HTMLまたはXML)をWebSphere Portalに渡すことです。この後、WebSphere Portalはアプリケーションのレンダリングを画面上のどの位置に表示するのかを決定します。 図3は、図1に描かれているJ2EEの部分を拡大したもので、Portalレイヤーが一番上(この場合、実際には左側)に示されています。1つの例として、Lotus Domino Web AccessポートレットがLotus Domino Serverにアクセスし、ユーザーの電子メールのレンダリングを提供しています。WebSphere Application Server / J2EEの図は縮小されて横向きになり、これとクライアントのラップトップの間にPortalレイヤーがあります。 図3.ポートレットを介して複数のバックエンド・アプリケーションにアクセスするWebSphere Portal もう一度問いますが、これはLotus Dominoにとってどのような意味を持つのでしょうか。WebSphere Portalには、Lotus Domino NSFをPortalインターフェースに公開する、すぐに使用可能ないくつかのポートレットが含まれています。さらに、IBM Portlet Builder for Dominoを使用すると、Lotus Dominoアプリケーション用の独自のラッパーを作成し、デプロイできます(あるいは、サード・パーティー製のポートレット・ビルダーのいずれかを購入します)。 Lotus DominoをWebSphere Application Serverと統合することでパフォーマンスとスケーラビリティーの問題を解決できるのに対し、Lotus DominoアプリケーションをWebSphere Portalと統合することはUIに関わることになります。これを行うことにより、Lotus DominoアプリケーションをPortal環境に組み込み、UIの集約とデバイスからの独立という利点を得られます。 この違いは重要で、目的が誤っていると、トラブルだけを招くことになります。パフォーマンスの問題を解決するためにLotus DominoアプリケーションをWebSphere Portalと統合することはなく、同様に、ポータル・インターフェースを得るためにLotus DominoアプリケーションをWebSphere Application Serverと統合することはありません。
Workplaceレイヤー: パッケージ化されたアプリケーションとリッチ・クライアントPortalからIBM Workplace Collaboration Servicesには、どのような方法で移動するのでしょうか。その答えは、レイヤー経由です。これを最も簡単に説明すると、Workplace Collaboration Services(および、Workplace Services ExpressなどのWorkplace関連製品)は、WebSphere Portal上に実装されたアプリケーションのセットです。多くの意味で、Workplace Collaboration ServicesはPortalアプリケーションです。しかし、WebSphere Portalはブラウザー・クライアントおよびハンドヘルド・クライアント向けであるのに対し、Workplace Collaboration Servicesには、製品のサーバー部分からユーザーのデスクトップにインストール(または、プロビジョニング)されたリッチ・クライアントが含まれています。Workplace Managed Clientと呼ばれるこのリッチ・クライアントも、以下で説明するように、IBM Lotus Notesの次のメジャー・リリース(コード・ネームはHannover)との組み合わせで、重要な役割を果たします。 Workplace Collaboration ServicesがPortalフレームワーク上で配布する主なパッケージ・アプリケーションには、次のものがあります(すべてを網羅したリストではありません)。
Workplace Collaboration ServicesとWorkplace Services Expressは、どちらもWebSphere Portalアプリケーションとして実装でき、Lotus DominoをWebSphere Portalと統合したときと同様に、Lotus Dominoをこの2つの製品と「画面上」で統合できます。つまり、既存のLotus Dominoアプリケーションをラップするために、ポートレットを構築、購入、または既製のものから入手することになります(前の図3の例を参照)。 Workplace Managed Client 2つのWorkplace製品の大きな違いは、Workplace Services Expressがブラウザー(および、ハンドヘルド)指向であるのに対し、Workplace Collaboration ServicesはIBM Workplace Managed Clientをデプロイするオプションを用意している点です。Lotus Notesのユーザーは、すでにリッチ・クライアントとその利点について理解しています。しかし、Workplace Collaboration ServicesとWorkplace Managed Clientが登場するまでは、J2EEプラットフォームには、アプリケーションをデプロイするリッチ・クライアントがありませんでした。 Workplace Managed ClientはLotus Notesとさまざまな点で大きく異なっています。その例を以下に示します。
Eclipse / Workplace Managed Clientのプラグイン・アーキテクチャーは非常に強力です。実際に、Workplace Managed Clientで使用できるプラグインの1つにLotus Notes 7があります(Lotus Notes 7を独立してコンピューターにインストールしなければなりませんが、インストール後は、Workplace Managed Clientによって認識され、ユーザーはWorkplace Managed Clientのウィンドウ内でLotus Notesを起動できるようになります)。 このため、Workplace Managed Clientは、アプリケーションの集まりを表示する単なるブラウザー・ウィンドウを大きく超えた存在となります。Workplace Managed Clientは、画面上の統合を次のレベルに高めることにより、真のコンポジット・アプリケーションとしての基盤を構築します。Workplace Managed Clientはプログラム可能なクライアントであり(独自のEclipseプラグインを記述できます)、IBMから提供されるWorkplace Managed Client APIを使用することにより、クライアント・サイドのコンポーネント(従来からのポートレット、Lotus Notesベースのアプリケーション、またはカスタム・コーディングされたプラグイン)どうしが相互にコミュニケートし、データを共有することができます(適切なセキュリティーは設定します)。 この種類のクライアント・サイドの機能は、Lotus Notesを組み込むだけでなく(複製とオフラインでの使用に対する完全なサポートを含む)、それを超えた能力を持ちます。EclipseのUIは、Lotus Notesでは不可能であった方法で、カスタマイズと拡張が可能です。カレンダー・ビューにカスタムUIが必要ですか?問題ありません。独自のプラグイン・ビューアーを記述し、Workplace Managed Clientのイベント・モデルにフックすればよいのです。ユーザーが電子メールを送信したときに、何か特殊な機能を実行したいですか?これも問題ありません。カスタム・イベント・ハンドラーを記述できます(Javaプログラミングに習熟している必要があります)。 これは、従来からのLotus Notes Clientにとって、将来的にどのような意味を持つのでしょうか。Lotus Notes Clientは、なくなってしまうのでしょうか。それは絶対にありません。Lotus Dominoは、IBM Workplaceによって置き換えられるのでしょうか。これも絶対にありません。実際に、2つのプラットフォームは進化しており、多くのユーザーが理解し、愛用してきたLotus Notes/Dominoの機能をまったく失わない重要な方法でマージされようとしています。 Lotus NotesとWorkplaceリッチ・クライアントの進化: 対等なマージ 現在、Lotus Notes ClientとWorkplace Managed Clientは、大きく異なる別のものに見えます。この状況では、どちらかが「勝利」し、ユーザーは一方のプラットフォームからもう一方のプラットフォームにアプリケーションを移行せざるをえない、などという憶測が生まれてくるかもしれません。 しかし、これは一時的な状況でしかありません。2つのクライアント・プラットフォーム(Lotus NotesとWorkplace Managed Client)は、従来のLotus Notes Clientの次のメジャー・リリース(コード・ネームはHannover)でマージされる予定です(このコード・ネームは、製品が最初に発表されたドイツの都市にちなんで名付けられました)。Hannoverは真に革新的です。これは、基本的にはまだLotus Notesですが、全体のUIはEclipseオープン・フレームワーク上に再構築され、Lotus Notesコンポーネントは、コンポジット・アプリケーションのクライアント・スペースにおける第一級のコンポーネントになります。さらに、Lotus Notesコンポーネントは、Lotus Domino ServerまたはWorkplaceサーバーからプロビジョニングされます。 これが意味することは、Hannoverにアップグレードすることにより、お客様はLotus Notesを使いながらも、Workplaceリッチ・クライアントの利点(ポータル・インターフェース、サーバーによる管理/プロビジョニング、拡張可能なUIなど)を得られることです。さらに、これはEclipseにラップされた真のLotus Notes Clientであるため、既存のすべてのLotus Notes/Dominoアプリケーションを変更なしにHannover環境で実行できます。 従来の独立したLotus Notes/Domino構成も、IBMによって提供が継続されます。どのユーザーも、意志に反して新しいHannoverクライアントの採用を強制されることはありません。しかし、統合されたリッチ・クライアントの利点は非常に大きいため、ほとんどのお客様がスムーズに移行し、満足な結果を得られるものと予測されています。
レイヤーごとに異なる利点それでは、なぜIBM Workplaceなのでしょうか。繰り返しになりますが(過去数年間、この点に関して混乱が大きかったので)、IBM Lotus Notes/Dominoはなくなりません。 IBM WebSphere Application Serverに組み込まれたJ2EE基盤テクノロジーは、組織がアプリケーションをデプロイできる高速でスケーラブルなプラットフォームをもたらします。Lotus DominoをWebSphere Application Serverと統合することにより、Lotus Dominoが提供する豊富でコラボレーティブな機能を一切失うことなく、大規模なLotus Domino Webアプリケーションに固有なパフォーマンス・ボトルネックの一部を解消することができます。 WebSphere Application Server上のPortalレイヤーは、パーソナライズされたデスクトップを提供します。ナレッジ・ワーカーはこのデスクトップ上で独自のワークスペースを構築し、画面上でのデータ統合を用いて、重要なアプリケーションを1箇所に集めることができます。 WebSphere Portal 上のIBM Workplaceレイヤーは、プリパッケージされた一連のアプリケーション、既存のLotus Dominoアプリケーションをポータル化された環境に公開する機能、およびプロビジョニング用の強力な新しい管理オプションを提供します。さらに、現在、Workplace Collaboration Servicesは、オンライン作業のエクスペリエンスをより一層改善するWorkplace Managed Clientをユーザーに提供します。Workplace Managed Clientの最新のバージョンは、Lotus Notes 7用のプラグインをサポートします。Lotus Notesの次のメジャー・リリースは、実際に従来のLotus Notes ClientをWorkplace Managed Clientとマージしたものであり、両者の機能を大幅に強化します。これは、Lotus NotesがWorkplace Managed Clientによって置き換えられるのではなく、双方がより良くなる対等なマージです。
リソース学ぶ
筆者について（原文のまま）Bob Balaban is an Executive Consultant with the Business Transformation Team in the Workplace, Portal and Collaboration division of IBM Software Group. Previously, Bob worked on NOI, LotusScript, and agents in Lotus Notes initially as a Lotus employee, and then later as a member of Iris Associates. Before Lotus Notes, he worked at Lotus on spreadsheets and other products, earning a U.S. patent for the Version Manager feature in 123/W.
|
||||||||||||||||||||||||||||||||||||||||||||
