レベル: 中級 Nicholas Chase, President, Chase and Chase, Inc.
2003年 10月 01日 MetroSphere.comの構築の経緯をたどるこのシリーズの第3回では、チーム・リーダーであるNicholas Chase氏が、さまざまな事例を利用してIBM Patterns for e-businessに概説される一般的な状況をいくつか考察し、アプリケーション・アーキテクチャーやプロジェクトの開始に役立つサンプル・コードを紹介します。この記事では、コラボレーション、アクセス統合、およびWebSphere Portalパターンに焦点を当てながら、他の人々の経験を活用し、チームのプロジェクトに適用していきます。
MetroSphere.com
MetroSphere.comは、WebSphere Portalで構築されたオンラインのテクニカル・コミュニティーであり、情報マーケットプレイスです。完成したMetroSphere.comでは、コンサルタント、プログラマー、およびテクニカル・ライターが、情報、ヒント、テクニックを集めて共有したり、それぞれの好みに合せてカスタマイズしたポータル・コンテンツを表示することができます。MetroSphere.comは、個人および企業が技術情報やサービスを販売したり交換する場所というだけでなく、新規および既存のプロジェクトにおける、より生産性の高いコラボレーションおよびワークフローを可能にします。Studio Bの記事、チュートリアル、およびヒントで構成されるこのシリーズでは、MetroSphereポータルの構築を読者の皆さんと一緒に体験していきます。
大学で講師をしていたとき、どのプログラミング言語を教えていようと、学生が質問するのは常に同じ種類の機能の構築方法であることに気付き、そこで初めてソフトウェア開発におけるパターンについて意識するようになりました。彼らの質問は当然のことでした。確かに、これまでとは全く異なる革新的な機能も存在しますが、それは極めてまれなことであり、ほとんどの人は、既に誰かがどこかで解決した問題を解決するためにアプリケーションを作成しています。もちろん、利用することが許されたとしても、過去の類似したプログラムをそのまま借用することはできません。あらゆる状況にはそれぞれに固有で特定の要件があり、その環境もさまざまです。しかし、これまで蓄積されてきたあらゆる開発ソリューションを再利用できたらどんなに素晴らしいでしょうか。
多くの意味で、それがIBM Patterns for e-businessの背後にある概念です。よく知られたデザイン・パターンでは、特定のソフトウェア開発の状況を取り上げ、その問題を解決するための最適なソリューションを説明します。Patterns for e-businessではこの概念をさらに一歩進め、最終的にソフトウェア・デザインに影響を与えるビジネス上の問題にも対処しています。システム設計者は、現在検討中の問題についてあてはまるビジネス・パターンを決定し、ソリューションの実装に使用するアプリケーションを探すことができます。場合によってアプリケーション・パターンはさらにランタイム・パターンに分割され、特定の製品やアーキテクチャー、さらにはサンプル・コードが適用されます。
もちろん、WebSphere PortalでMetroSphere Webサイトを構築することは決まっています。では、なぜこれらのパターンに留意する必要があるのでしょうか。答えは簡単です。既に類似したソリューションが存在するのならば、それを一から設計したくないからです。同様のソリューションを誰かが既に考えていたとしたら、彼らの到達した最終的な結論を知っても損はありません。無駄な努力に費やす数日に比べたら、パターンについての本を読む数時間は何でもありません。
結局、時間を有効に過ごすことができました。サイトの構築方法については明確な案を持っていましたが、このパターンを検討することによって、これまで検討していなかった別のアーキテクチャーがあることがわかりました。また、後から機能を統合する方法についても知ることができ、それを頭の隅に置きながらフェーズ1を構築することができました。さらに、既に選択したアーキテクチャーの検証にも役立ちました。
プロセスを開始するにあたり、まずは基本的なビジネス・パターンについて調べてみました。
ビジネス・パターン
このシリーズの第2回でも説明したように、どのようなWebサイトの開発でも中心となるのは解決するべきビジネス上の問題であり、そのため頻繁に現れるさまざまなビジネス・パターンを検証してみることは意味のあることです。現在、Patterns for e-businessのサイトでは、以下の4つのビジネス・パターンが文書化されています。
セルフサービス : おそらく最も一般的なパターンであり、ユーザーが企業データと対話する必要がある状況で構成されています。たとえば、アカウント情報の表示、要求の実行、検索の実行を可能にするサイトではこのパターンを使用します。これはユーザー対企業 (U2B) パターンとも呼ばれます。
コラボレーション : このパターンでは、通常 (必ずしもそうであるとは限りませんが)、達成すべき共通の目的を持ったユーザー・グループ間で対話する必要がある状況が概説されています。たとえば、インスタント・メッセージ、ニュースグループ、e-mailディスカッション・リストはこのカテゴリーに含まれます。これはユーザー間 (U2U) パターンとも呼ばれます。
情報集約 : このパターンには、複数のデータベースなど、さまざまな情報源から情報を収集してユーザーが使用できるようにする状況が含まれます。たとえば、さまざまなウェブログの統計情報を収集するBlogdexや、多数のサイトからRSSフィードを収集するNews Is Freeなどのサイトはこのパターンを使用します (詳細については参考文献を参照してください)。これはユーザー対データ (U2D) パターンとも呼ばれます。
拡張エンタープライズ : これは企業間でシステムを接続する必要がある状況を考慮したものであり、公開されるWebで使用されることは通常ありません。たとえば、納入業者のシステムと接続し、ジャストインタイムの納品を実施する企業はこのパターンを使用します。これは、企業間取引 (B2B) パターンとも呼ばれます。
MetroSphereはユーザー間のコラボレーションに焦点を当てたサイトなので、コラボレーション・パターンが適していると思われます。しかし最終的には、少なくとも情報集約パターンも使用します。またセルフサービス・パターンや拡張エンタープライズ・パターンも使用する可能性があります。幸運なことに、1つのパターンに制限されることなく、すべてのパターンは組み合わせて使用することができます。実際これらは組み合わされることが多く、ある共通した状態でたびたび使用されるので、実際に2つの統合パターンが文書化されています。
統合パターン
Patterns for e-businessサイト (参考文献を参照) には、現在アプリケーションのフロントエンドとバックエンドを扱う2つの統合パターンが文書化されています。
アクセス統合 : アクセス統合パターンは、ブラウザーや携帯電話など、ユーザーが異なるデバイスを使用する状況を対象にしていますが、さまざまなアプリケーションの情報を1つのユーザー・インターフェースで表す必要がある状況も対象となります。たとえばYahoo! はその検索エンジンからの情報とともにニュースやさまざまな情報を提供していますが、視覚的に一貫性があります。これは代替デバイスの代替形式でも使用できます。
アプリケーション統合 : アプリケーション統合は、アクセス統合のパターンをより複雑にしたものです。アクセス統合では、さまざまな情報源からの情報をユーザーに返す状況を対象にしているのに対し、アプリケーション統合では、さまざまな情報源からの情報を組み合わせて新しい情報源を作成する状況を対象にしています。たとえばMockerybirdでは、onfocus.comのBook Watchの書籍リストを利用し、AmazonのWebサービスでその書籍に関する情報を検索して、Google APIを使用してその情報をニュース項目やWebサイトにリンクさせています (これらのサイトの詳細については参考文献を参照してください)。より企業に関係のあるレベルでは、いくつかのデータベースから情報を取り出すカスタマー・リレーションシップ管理ツールでこのパターンを使用します。
フェーズ1では必要ないと思われましたが、Patterns for e-businessサイト (参考文献を参照) の統合パターンのセクションで、アプリケーション統合パターンに類似したソリューションを探してみました。現時点ではアクセス統合パターンが役立つように思えますが、さまざまなデバイスを考慮し、おおよそ類似したさまざまな機能を装備しておく必要があります。
これには、コラボレーション・パターンと同様にさらに調査が必要です。しかしその前に、1つの質問に答えなければなりません。より複雑にすることなく、これらの2つのパターンを組み合わせることはできるのでしょうか。
複合パターン
いくつかのパターンは頻繁に組み合わせて使用されることが多く、結局はその組み合わせ自体がパターンになっていることがわかりました。Patterns for e-businessサイトには、4つの組み合わせ方法、つまり複合パターンが文書化されています。
電子商取引 : このカテゴリーはかなり広く、特定のアプリケーションから (アプリケーション統合を使用) 情報を入手する (情報集約を使用) ためにシステムにログインする (セルフサービスを使用) ユーザーから、拡張エンタープライズ・パターンを使用してビジネス・パートナーとのシステム統合を可能にするシステムまでが対象になります。必要に応じて、その他のパターンも混ぜ合わせることができます。
e-marketplace: e-marketplaceシステムは、商品やサービスを売買するために複数の取引先が対話できるよう、特別に設計されたものです。
ポータル : ポータルは、通常、情報集約を介して収集された情報へのアクセスを提供しますが、正式には、アクセス統合パターンともう一つ別のビジネス・パターンで構成されます。たとえば、MetroSphereの場合、ポータルはアクセス統合とコラボレーションで構成されます。
アカウント・アクセス : このパターンには、アカウントにアクセスして情報を収集したり、アカウント情報を変更できるシステムが含まれます。このアクセスは、銀行や株券のポートフォリオを確認するような個人的なものであったり、カスタマー・サービス担当者を介したアクセスのように間接的なものであったりします。
拡張されたビューを見て、MetroSphereでは、これらの少なくとも3つのパターンを利用することがわかりました。ポータル・パターンに加えて、ユーザーがコンテンツを売買するためには今後e-marketplaceパターンが必要になり、自身のアカウント情報を制御するためにはアカウント・アクセス・パターンも必要になります。
しかし現時点では、ポータル複合パターンの実装に集中しなければなりません。
ポータル複合パターン
IBM Patterns for e-businessサイトから引用した図1 に示すように、さまざまなビジネス・パターンを組み合わせたポータル複合パターンを作成するには、アクセス統合パターンを実装しなければなりません。混乱を避けるため、さまざまな種類の情報を一貫性のある状態でユーザーに表示しなければならないことを考えれば、これはもっともなことです。
図1. ポータル・パターン
このパターンを確かめることで、ポータル複合パターンを使用すれば、私たちの計画に後から別のビジネス・パターンを統合しても問題がないことを再確認できました。
これで現状を把握し、実装する2つのパターンの詳細を調べる準備ができました。
コラボレーション・ビジネス・パターン
コラボレーション・ビジネス・パターンは、本質的に親しみやすいものでなければなりません。このパターンには、e-mail、ディスカッション・グループ、インスタント・メッセージなどのアプリケーション、つまりユーザー間で情報を共有しなければならないあらゆる状況が含まれます。含まれる範囲がかなり広いため、実際には、コラボレーション・ビジネス・パターンに関連する次の4つの異なるアプリケーション・パターンがあります。
Point-to-Point (U2Uトポロジー1)
Point-to-Pointアプリケーション・パターンは、同期的なピアツーピア・アーキテクチャーがその中心となります。中央サーバーはなく、各ユーザーは相手のIPアドレスを知っている必要があります。相手のユーザーも、その時点でログインしている必要があります。この1つの例がMicrosoft NetMeetingの使用です。これはユーザー数が比較的少なく、ネットワークが静的な場所に構築されている状況でのみ実現可能です。いくつかの市販のツールも使用できますが、多くの場合、ソリューションが始めからコード化されており、低レベルのネットワーク・プロトコルについての知識が必要となるため、問題になることがあります。興味深いことに、ファイル共有システムGnutellaはこのカテゴリーに含まれるのですが、ユーザー数を増やすことができない場合もあります。また、会話に参加する両方のユーザーが同時に存在してログインしていなければならないという制限もあります。
ストアとリトリーブ (U2Uトポロジー2)
このパターンはPoint-to-Pointソリューションよりもシンプルで、ユーザーが情報を中央サーバーに送信し、受信者がそのサーバーにログインして情報を入手する状況が含まれます。明確な事例であるディスカッション・グループに加えて、e-mailおよびInternet Relay Chat (IRC) クライアントも含まれることに注意してください。このパターンの利点は、市販のソフトウェアを広く使用でき、多くの場合 (私たちには該当しませんが)、カスタム・コードを作成する必要がありません。また受信者のIPアドレスがわからなくても問題ありません。受信者は送信者と同時にオンラインになっている必要がありません。この方法によって1対多または多対多の通信も可能になりますが、時間についての大きな制限があります。Point-to-Pointが同期的であるのに対し、このパターンは非同期的であり、送信者が早急なアクションを必要とする状況には適さない可能性があります。
ダイレクテッド・コラボレーション (U2Uトポロジー3)
このパターンは多くの意味で、Point-to-Pointおよびストアとリトリーブの良い面を取り入れています。ユーザー同士で直接対話できるのですが、このパターンにはすべてのユーザーがログインしなければならない中央サーバーがあり、メッセージの送信者が受信者のIPアドレスを知っている必要はありません (ただし、通常は送信者が受信者のリストをクライアントに保管しています。サーバーに接続することで、クライアントは受信者の現在のIPアドレスを判別します)。このパターンの例で広く知られているものにインスタント・メッセージがあります。このパターンの基本的な制限は、中央サーバーを提供する必要があることです。また通信の両方の当事者が同時にオンラインになっていなければなりません。
マネージド・コラボレーション (U2Uトポロジー4)
このパターンは、基本的にダイレクテッド・コラボレーションをより複雑にしたものです。このソリューションでは、ユーザーが互いにコラボレートするだけでなく、ある種のワークフロー・システムを経由します。たとえば、コール・センターでは、ユーザーとの対話で提供される情報に基づいて、そのユーザーを特定のカスタマー・サービス担当者に振り分けることがあります。
私たちの初期の計画がストアとリトリーブ・パターンにあてはまることは明確ですが、このリストを見ると2つのことがわかります。第1に、ストアとリトリーブ・パターンをいくつかの異なる方法で実装することが可能だということです。ディスカッション・グループ・タイプのシステムにずっと焦点を当てていたので、たとえばe-mailなどの方法をシステムに追加することはあまり考慮していませんでした。第2に、ユーザーが互いにコラボレートする他の方法についてアイデアを得られそうです。これはMetroSphereプロジェクトの今後のフェーズまで心に留めておきます。
理想的にはここで次のステップへ進み、プロジェクト独自の環境で使用できるランタイム・パターンやサンプル・アプリケーションについて調べるはずでした。残念なことに、現時点では、コラボレーション・パターンがアプリケーション・パターン・レベルまでしか文書化されていないため、以降は独力で進めなければなりません。ただし、それは対処できないほどのものではありません。いずれにせよ、システムのこの部分は一から構築する予定でした。そして、少なくともこの戦略の長所と短所についてアイデアを得られました。
アクセス統合パターン
アクセス統合は、実際は2つの異なる状況に適用されます。1つは、ユーザーがブラウザー、携帯電話、PDAなど異なるデバイスから情報にアクセスしなければならない場合です。もう1つは、1つのサイトからさまざまな種類の情報 (通常は異なるアプリケーションからの情報) にユーザーがアクセスできるようにする場合です。アクセス統合の目的は、ユーザーに、単一の統一された柔軟な表示を提供することです。このタスクは、次のようないくつかの異なるアプリケーション・パターンを使用して実行できます。
パーベイシブ・デバイス・アクセス
図2 に示すように、このパターンはアプリケーション自体に新しい層を追加します。パーベイシブ・デバイス・アクセス層には、アクセスする可能性のあるクライアントに関する情報と、アプリケーションによって提供されるHTMLを適切なマークアップに変換することを可能にするスタイル・シートが含まれています。
図2. パーベイシブ・デバイス・アクセス
幸運なことに、WebSphere Portalには、組み込みのトランスコーディング・サーバーがあるため、この層を自分たちで構築する必要はありません。
シングル・サインオン
このパターンで作成されるシステムでは、ユーザーは総合的なシステムにログインするだけです。基礎となるアプリケーションが認証情報を要求する場合は、新しいシングル・サインオン層がそれを提供します。このパターンには、実際には2つの種類があります。図3 は、単純にアプリケーションが認証情報を受け入れて処理を継続する簡単なバージョンを示しています。
図3. シングル・サインオン
ただし場合によっては、異なる認証を必要とするレガシー・アプリケーションであったり、高度なセキュリティが要求されたり反駁が必要ないために、アプリケーションを簡単に統合できないことがあります。この場合のアーキテクチャーは図4 のようになります。
図4. 拡張シングル・サインオン
パーソナライズド・デリバリー
パーソナライズド・デリバリーは、ユーザーに関する情報を基にして、ユーザーに表示する情報を決定します。MetroSphereでは、いくつかの種類のプロファイルおよびパーソナライゼーション機能を使用します。ユーザーにはどのトピックに関心があるかをはっきりと尋ねるつもりですが、彼らの好みを推論して適切な資料を提供するため、彼らが表示する項目とその他の人々が表示する項目の比較も行います。WebSphere Portalでは、表示するコンテンツを制御するルールを作成するだけでなく、暗黙的なパーソナライゼーションに必要なパターン認識を可能にするパーソナライゼーション・エンジンが提供されます。さらに、独自のポートレット・アプリケーション内で、いくつかのパーソナライゼーション機能を作成する予定です。
MetroSphereプロジェクトでは、実際に何らかの形でこれらのパターンのすべてが必要になります。アクセス統合はランタイム・パターン・レベルでも文書化され、さまざまな環境でのこれらのパターンの実装例を提供しています。しかし前にも述べたように、これらの機能の大部分はWebSphere Portalに組み込まれています。
学習したこと
Patterns for e-businessのサンプル・コードは入手しませんでしたが、そのプロセスから多くの情報を入手しました。第1に、私たちが達成したいものを正確に定義することができました。第2に、各アプローチの長所と短所をリストして、過去の経験者たちの知恵を得ることができました。第3に、次のステップで活用できる、今まで必ずしも検討していなかったアイデアを得ることができました。また、今後必要になるほとんどの機能がWebSphere Portalに組み込まれていることも発見しました。
コラボレーション、アクセス統合、およびポータルの3つのパターンに焦点を当てて作業を進めてきました。Patterns for e-businessのメーリング・リストに登録して、時間の経過とともにこれらのパターンおよびその他のパターンにおける開発の進捗を記録していく予定です。
次回予告
このシリーズの次回の記事では、プロジェクトのシステム管理者であるTom Syroid氏が、WebSphere Portal - Expressサーバーをセットアップし、適切なセキュリティで保護する手順について説明します。
参考文献
本文中に記載したその他のサイト :
情報集約 :
アプリケーション統合 :
著者について  | 
| |
StudioB の創始者であるNicholas Chase氏は、Lucent Technologies、Sun Microsystems、Oracle、およびTampa Bay Buccaneersなどの企業のWebサイト開発に参加してきました。彼は、高校の物理学の教師であり、低レベル放射性廃棄物施設管理者、オンラインSFマガジンの編集者、マルチメディア・エンジニア、そしてOracleのインストラクターでもあります。最近では、フロリダ州クリアウォーターにあるSite Dynamics Interactive Communicationsに技術最高責任者 (CTO) として在籍し、Web開発に関連した4冊の書籍を執筆しました。著書の1つには『XML Primer Plus』(Sams社) があります。彼は読者から意見を歓迎しています。連絡先はfeedback@metrosphere.com です。 |
記事の評価
| 
