Enterprise Expertise Location システムを構築する: 第 2 回、Expertise Locator のソリューション・アーキテクチャー

この記事で話題としているのは、IBM 社内に実装された、その名も興味深い Expertise Locator という Expertise Location システムのソリューション・アーキテクチャーです。この第 2 回では、Expertise Locator システムのユース・ケース・モデル、ソリューション・アーキテクチャー、データ・モデル、そしてアーキテクチャー上の意思決定について取り上げます。

Galina Grunin, IT Architect, IBM

Galina GruninGalina Grunin は 2001年に IBM に入社しました。認定 IT アーキテクトである彼女は、現在ビジネス・アジリティー・アプリケーションに取り組んでいます。



Murali Vridhachalam, IT Architect, IBM

Murali VridhachalamMurali Vridhachalam は Open グループ認定優秀アーキテクトです。IT 業界での 17 年にわたる経験を持つ彼は、IBM Academy of Technology のメンバーとなっています。彼が、Enterprise Expertise Location のリファレンス・アーキテクチャーを発表しました。



Erich Walls, IT Architect, IBM

Erich WallsErich Walls は 1997年に IBM に入社し、10 年間、IT アーキテクトとして働いてきました。現在は、IBM および OpenGroup の両方から認定を受けた CIO 組織のシニア IT アーキテクトです。彼は、ナレッジ管理および販売サポートを専門分野としています。



2011年 12月 16日

はじめに

Enterprise Expertise Location システムは、可能な限り柔軟であると同時に、特定の技術や標準に偏らないシステムでなければなりません。このシステムは、他のエンタープライズ・アプリケーションがその固有のソリューション内で Expertise Locator (EL) を利用できるようにする必要があるためです。この記事では、企業規模の Expertise Location システムを構築する上で必要となるユース・ケース、ソリューション・アーキテクチャー、技術、データ・モデル、そしてアーキテクチャー上の重要な意思決定について説明します。

ユース・ケース・モデル

以下のユース・ケース・モデルの図には、Expertise Locator の主なユース・ケースを示してあります。この図に示されているように、Expertise Locator には、次の 6 つのアクターがあります。

  • エンド・ユーザー (EndUser) -- システムを操作して、専門家を特定したり、ナレッジ・ベースを検索したり、システムに質問を送信したりするユーザーです。
  • SME -- 他の人々を支援するためにシステム内に登録されたサブジェクト・マター・エキスパート (SME: Subject Matter Expert) で、特定の専門的トピックに対してビジネスによって指名される場合と自己推薦の場合もあります。また、企業内の「ソーシャル・メディア」から潜在的な SME が特定されることもあります。ソーシャル・メディアには、出版物、ウィキ、ブログ、特許、会議でのプレゼンテーションなどが含まれます。したがって、例えばクラウド・コンピューティングに関するさまざまなブログを投稿していて、クラウド・コンピューティングに関連する特許を申請している人物が、クラウド・コンピューティングにおけるエキスパートとして特定されることがあります。
  • 管理者 (Administrator) -- 専門分野の分類法を管理するユーザーです。通常、管理者となるのは、分類法が有効であることと、他の人々を支援する専門家が登録されていることに強い関心を持つ利害関係者です。
  • QA 管理者 (QA Manager)、質問振り分け者 (Question Router)、コラボレーション・ブローカー (Collaboration Broker) – それぞれ質問の管理、振り分け、インスタント・メッセージによるコラボレーション・サービスへの問い合わせを行うシステム・アクターです。

ユース・ケース・モデル

ユース・ケース・モデル

ソリューション・アーキテクチャー

Expertise Locator の主要なアーキテクチャー・モデルには、サービス・コンポーネント・アーキテクチャー (SCA: Service Component Architecture) が選ばれました。Expertise Locator の重要な要件の 1 つは、可能な限り柔軟であると同時に、特定の技術や標準にできるだけ依存しないことです。これによって、企業の他のアプリケーションがその固有のソリューションに Expertise Locator ソリューションを統合して利用することが可能になるためです。SOA における標準として誕生した SCA は、サービス実装とサービス・アセンブリーとを切り離す手段となります。サービス実装とサービス・アセンブリーが分離されていれば、開発者はビジネス・ロジックに専念する傍ら、さまざまな技術のためにバインディングを提供することができます。以下のアーキテクチャー・モデルに、ソリューション・アーキテクチャーとそのコンポーネントを示します。

アーキテクチャー・モデル

アーキテクチャー・モデル

Expertise Locator を構成する主要なコンポーネントの 1 つは、分類管理コンポーネントです。このコンポーネントに定義された用語を説明すると、まず、「専門分野 (Expertise Area)」があります。これは、職業単位または事業単位での分類で、例えば業界コンサルティング、ソフトウェア製品、販売チームなどの専門分野があります。「分類 (Taxonomy)」は、高いレベルの専門性の分類を表す用語です。それぞれの分類は「専門性 (Expertise)」と表現される情報のトピックに分かれています。専門性をさらに専門に特化した情報からなるサブトピックに細分化して、専門性の階層分類での「子」を作成することも可能です。

専門性管理コンポーネントは、SME を分類管理コンポーネントに定義された専門性に対応付けるマッピング・サービスを提供します。SME は、定義された専門性分類には含まれない専門性のタグを自由に指定することもできます。さらに SME は、企業内での SME のソーシャル・メディアでの活動に基づいてタグを取得するための API 呼び出しを利用することで、自動的に専門性のタグを設定することができます。

もう 1 つの Expertise Locator のコンポーネントは、Expertise Locator システムに登録された SME を見つけるための専門性の検索サービスおよび分類の閲覧サービスを提供します。API が呼び出されるのは、ユーザーと SME とのソーシャル・プロキシミティ (ソーシャルな手段によるユーザー同士の近接度) やソーシャル・パス (ソーシャルな手段によるユーザー同士の関係を示す経路) を判断する場合、そしてシステムに登録されてはいないけれども、そのソーシャル・メディアでの活動 (例: 出版物、特許、割り当てられたタグなど) に基づいて専門家であると推定される「潜在的専門家」を見つける場合です。

実装技術 (製品) としては、以下に挙げるものが選ばれました。

  • アプリケーション・サーバー (WebSphere Application Server)
  • RDBS/検索 -- ソリューションの実装には DB2/DB2 NetSearch Extender が使われていますが、検索機能または RDBS を備えた RDMS と情報検索ソフトウェア・ライブラリー (Apache Lucene など) の組み合わせに置き換えることもできます。
  • インスタント・メッセージング (Lotus SameTime)
  • サービス・コンポーネント・アーキテクチャー (Apache Tuscany)
  • Ajax ツールキット (Dojo)
  • アプリケーション・フレームワーク (Spring)

以下の図に、該当するアーキテクチャーの部分を示します。

アーキテクチャーの一部

アーキテクチャーの一部

データ・モデル

Enterprise Expertise Locator のデータ・モデルを構成するのは、ユーザー・プロファイル、専門家プロファイル、専門性分類の構造、スキルの辞書、以前に問い合わせられた質問、そしてインスタント・メッセージの交換を表すエンティティーです。さらに、このデータ・モデルには、さまざまなレベルの専門性分類を管理するための各種のマッピング・テーブル (専門家と、そのスキルまたは専門性を対応付けるテーブルなど) とアクセス制御リストも含まれています。以下のデータ・モデル図に、Expertise Locator のデータ・モデルの概要を示します。

データ・モデル

データ・モデル図

アーキテクチャー上の意思決定

さまざまなバインディングを介して企業内のリモート・サイトから柔軟にアクセスできる Expertise Locator サービスを実装するには、どのような技術を採用すればよいのでしょうか?例えば、販売力を強化するためのモバイル・アプリケーションの場合、特定のソフトウェア製品の専門家を表示することになるでしょう。その専門家に関するデータは Expertise Locator によって提供されるものの、Expertise Locator とモバイル・アプリケーションとの間の通信プロトコルまたはバインディングは、Expertise Locator を実装する時点ではまだわかりません。これらのアーキテクチャー上の意思決定は、実装を開始する以前に行われていることに注意してください。

複数の呼び出しプロトコルのサポート

問題の定義:

Expertise Location のデータには、企業内の複数のソース (またはサイト) からアクセスし、さらに更新することもできなければなりません。しかし、サイトによって、Expertise Locator サービスにアクセスしてデータの取得または更新を行うために実装する技術や言語はそれぞれに異なるはずです。例えば、Dojo を実装し、JSON-RPC を介して Expertise Locator サービスを利用するリモート・サイトもあれば、SOAP ベースの Web サービスを介して Expertise Locator サービスを利用するサイトや、HTTP を介して同サービスを利用するサイト、さらには JMS、RSS、ATOM などを介して利用するサイトなども考えられます。

動機:

標準の採用: 開発を迅速に行うために、より新しい技術を利用します。インフラストラクチャーの変更に対する適応性: プレゼンテーション技術がサービスを利用できるようにサービスを実装します。つまり、プレゼンテーション層とサービス実装の間にあるのは、疎結合です。

サービス・コンポーネント・アーキテクチャー (SCA: Services Component Architecture) は SOA に登場した標準で、そこに意図されているのは、開発者がビジネス・ロジックの開発だけに専念できるようにして、SCA がコンポーネントを呼び出すための単一のプログラミング・モデルを提供することです。さらに、SCA では 1 つのコンポーネントが複数の構成可能なバインティングを使用することもできます。

選択肢:

  1. Fabric3 -- 高リスクです。サービスのプロビジョニングおよび管理を自動化することに重点を置く SCA 標準のオープンソース実装ですが、現在はまだベータ版の段階にあります。
  2. Apache Tuscany – 低リスクです。Websphere Application Server 6.x 以降でサポートされています。Apache Tuscany は SCA に準拠したオープンソースの製品で、SOA ソリューションの開発タスクを簡易化するために、SCA 標準に基づく包括的な SOA の開発管理インフラストラクチャーを提供します。そのため、サービス開発者はビジネス・ロジックだけが含まれる再利用可能なサービスを作成することが可能になります。プロトコルはビジネス・ロジックから除外されていて、さまざまな種類のプラガブルなバインディングを使用して処理されます。このようなブラガブルなバインディングによってプロトコルが処理され、サービス (トランザクション、セキュリティー) 品質は宣言型で対処されることから、アプリケーションはインフラストラクチャーの変更を記録しなくても、その変更に容易に対応することができます。SCA は軽量のランタイムを提供しますが、Tuscany のランタイムはこの SCA 仕様の定義に従って、Java、BPEL、Java EE、Spring の統合をサポートします。さらに、Apache Tuscany 開発チームでは、RESTful な API の実装を容易にする JAX-RS バインディングのサポートを実装しています。 Apache Tuscany の図

    Apache Tuscany の図

    注: ソフトウェア・コンポーネントが、それぞれの実装で使用されている技術に関わらず互いの存在を検出して呼び出せるようにするために一般的に使用されているのは、ESB (Enterprise Service Bus) です。ESB は通常、複合アプリケーションをまとめて 1 つのアプリケーションとして記述することはしません。ESB はコンポーネントの間に位置し、あるコンポーネントから別のコンポーネントへのメッセージ転送を管理します。それとは対照的に、Tuscany および SCA では複合アプリケーション全体を記述することができます。その一方で、Tuscany では、ESB のサービス間メッセージのルーティングおよび変換機能を利用するために ESB を統合するのも簡単です。SCA コンポーネント間でのさまざまなサービス通信パターンを利用するには、Tuscany が優れたサポートを提供します。通信するコンポーネントの局所性を表すパターンには以下のものがあります。

    ローカル: 互いに通信する双方のコンポーネントが同じ JVM 内で実行されているパターンです。この場合、Tuscany はメモリー内通信を使用します。

    リモート: 互いに通信するコンポーネントがそれぞれ別の JVM 内で実行されているパターンです。これらの JVM も、それぞれ別の物理マシンで実行されている場合があります。コンポーネントが互いに通信するには、JSON-RPC や Web サービスなどのリモート・バインディングを使用することができます。局所性によらず、メッセージ交換スタイルの観点からは、以下の通信パターンが挙げられます。

    リクエスト・レスポンス: 呼び出し側コンポーネントは、各リクエストの送信直後にレスポンスを受け取ることを期待します。

    片方向: 呼び出し側コンポーネントは、リクエストの送信後にレスポンスを待機しません。

    対話型: 呼び出し側コンポーネントは、呼び出し側と呼び出し先のコンポーネントが共通して保持するコンテキストを使用して、互いに関連する一連のリクエストを送信します。

    コールバック: 呼び出し先コンポーネントが、将来のある時点で呼び出し側コンポーネントに対して呼び出しを行います。

  3. Websphere Process Server (WPS) – ベンダー固有の実装です。WPS は比較的重たいですが、Expertise Locator システムでの複雑なワークフローに関する要件はありません。

意思決定:

Apache Tuscany を採択しました。その理由は、IBM Tuscany 開発コミュニティーによる多大なサポートがあり、Apache Tuscany を採用することで、迅速な開発によるスケジュールの遵守、標準の採用、複数バインディングのサポートが可能となるからです。上記の Apache Tuscany の図には、複数の外部ソースが Enterprise Expertise Locator サービスと通信できること、そしてこれらのサービスが ESB や外部ソースと統合できることが示されています。

プレゼンテーション層の技術

問題の定義:

要件を基に考えると、エンド・ユーザーは専門性を検索する場合や、自身を専門家として登録する場合、あるいは潜在的専門家を検索する場合に、Web ベースのユーザー・インターフェースを使用することになります。さらに、コミュニティーを作成する場合や、グループ・ベースの専門性を検索する場合、さらにはレポートを表示する場合にもユーザー・インターフェースを使用する必要があります。このような Web ベースのユーザー・インターフェースを開発するために使用する技術一式を決定しなければなりません。

動機:

  • 企業戦略に関する提言の採用
  • より大規模な企業コミュニティーのアセット・コントリビューションの利用
  • ユーザー・エクスペリエンスの改善

選択肢:

  1. Dojo (Ajax ツールキット) -- Dojo は本番品質の多数のウィジェットを提供します。Dojo は完全に JavaScript だけで作成されているため、(例えば Firebug を使用して) デバッグするのも、既存のウィジェットの拡張機能を開発するのも簡単です。
  2. GWT (Google Web Toolkit) – Dojo とは異なり、GWT には、すぐに使用できるウィジェットがそれほど多く用意されていません。エンタープライズ開発者はかなりの時間をかけて基本ウィジェットを開発するか、あるいはサード・パーティー・ベンダーに頼らなければなりません。
  3. jQuery – jQquery は、Dojo ほどには構造化されていません。これは、アプリケーション・プレゼンテーション層全体の開発というより、別個のウィジェットの開発に適しています。

意思決定:

Web プレゼンテーション層の実装には、Dojo を使用することにしました。

アプリケーション・フレームワーク

問題の定義:

Enterprise Expertise Location システムのサーバー・サイドの開発に適したフレームワークと技術を決定する必要があります。

動機:

J2EE アプリケーションを構築するには、Tuscany と容易に統合できる業界標準の軽量のソリューションを使用します。しかもそのソリューションは、容易にテストができて、疎結合を実現できるものでなくてはなりません。

選択肢:

  1. Spring Framework/ Spring JDBC -- 低リスクです。広範に使用されている最新のオープンソース・フレームワークです。Expertise Locator データベースに意図された目的は、主にデータの取得です。Spring JDBC は ORM のオーバーヘッドを加えることなく、完全なパーシスタンス機能を提供します。また、Spring は一貫性のある例外階層となり、この階層ではデータベース・ベンダー固有のチェック例外をより一貫性のあるランタイム例外に変換し、アプリケーションの指定された層でのみ例外を捕捉できるようにします。
  2. Hibernate (JPA) -- 低リスクです。Expertise Location データベースの主な目的はデータの取得であることから、Hibernate のような ORM 製品を使用しても、そのオーバーヘッドを補うだけの十分なメリットはありません。

意思決定:

Spring/Spring JDBC を選択しました。

まとめ

連載の第 1 回では、Expertise Location システムに SOA パターンを適用する方法を説明するとともに、SOA パターンからリファレンス・アーキテクチャーをどのように導き出したかを説明しました。この第 2 回で、柔軟で、特定の技術や標準に依存しない Enterprise Location システムを構築するために必要なソリューション・アーキテクチャー、データ・モデル、実装技術について理解していただけたはずです。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=780448
ArticleTitle=Enterprise Expertise Location システムを構築する: 第 2 回、Expertise Locator のソリューション・アーキテクチャー
publish-date=12162011