レベル: 中級 Germán Goldszmidt, Ph.D., Distinguished Engineer, IBM
Carl Osipov (osipov@us.ibm.com), Software Architect, IBM
2007年 04月 10日 このシリーズでは、SOA (Service-Oriented Architecture) 複合ビジネス・サービスにおける POV (points of variability: 可変ポイント) を作成する方法について学びます。この記事では、変化に対応するための複合ビジネス・サービスを設計、開発するためのさまざまな方法についての概要と、POV の実現を支援する IBM® WebSphere® ソフトウェアの機能と能力について説明します。ここで取り上げる話題は、ビジネス・ルールとセレクター、Enterprise Service Bus を使ったメディエーション、サービス・レジストリーとサービス・リポジトリーを使ったダイナミック・ルーティング、そしてコンテンツや、コントラクト、コンテキストなどによるルーティングを使った動的ワークフロー・アセンブリーなどです。また、POV を公開するための方法と、WebSphere のより高度な機能をソリューションに追加することによる利点についても学びます。
はじめに
このシリーズでは、CBS (composite business service: 複合ビジネス・サービス) を開発する際に利用できる、POV を作成する方法の詳細について説明します。今後の記事ではワークフローという一般的な概念を使いますが、この概念は BPEL (Business Process Execution Language) のような具体的な言語を使って、CBS でのロジックの実装として実現することができます。ここでは、ワークフローの構造 (ワークフロー・シーケンスでのステップや分岐、結合など) ではなく、ワークフローがサービスの呼び出しを行うポイント (ステップ) に可変性を導入することに焦点を絞ります。
この記事では、POV を実装するための幅広い方法を紹介し、それらの技術的な側面を詳細に説明します。この記事でサービス呼び出しという場合は、ワークフローの中で下記が行われるステップを指します。
- 送信先のサービス・エンドポイントとメッセージを交換する
- ワークフローに制御を戻す
このように定義すると、ワークフローとサービス・エンドポイントとの間の対話動作のスタイルは、リクエストとレスポンス、片方向リクエスト、などとなります。
ワークフローでの POV
このセクションでは、ワークフローに POV を導入するための 2 つの方法を説明します (図 1)。左側の方法 1 (Option 1) では、呼び出すエンドポイントの選択をベースにしています。Invoke というラベルの付いた呼び出しステップは、ワークフローにおける任意のサービス呼び出しステップを表しています。
破線の矢印は、サービス呼び出し (Invoke) ステップがサービス・エンドポイントを選択する際に取り得る選択肢 (E1、E2、E3) を示しています。あるいは、サービス呼び出しステップはどのエンドポイントも選ばないことも可能で、その場合サービス呼び出しステップはオプションになります。
図 1. ワークフローに POV を導入するための方法
例えば、クレジット・スコア (訳注: 消費者個人に与えられる信用評価点のこと。米国で個人の信用度を評価する際に近年特に用いられている。) を取得する BPEL プロセスを考えてみてください。このプロセスは、いくつかの信用調査会社の中から 1 社を選ぶように作成することができます (各会社はエンドポイントとして表現されます)。
 | |
この先のセクションとこのシリーズの今後の記事では、POV を実装するための、より高度な方法を説明します。 |
|
ベースラインを設定するために、BPEL と SCA (Service Component Architecture) に基づく単純な実装について考えてみましょう。図 2 は、このタイプの実装の一部を示しています。左側には、選択 (Choice) ステップを持つ BPEL プロセスがあり、その後にサービス呼び出しステップの個々のインスタンスが続きます (個々のインスタンスは別々のサービス・エンドポイントに対応します)。実際のエンドポイントは BPEL で定義されておらず、右側の図に示す SCA 結線図で表現されています。この結線図は、この実装での BPEL プロセス (SampleChoice 要素として表現されています) とエンドポイントの関係が、静的な性質を持っていることを明らかにしています。
図 2. SCA を使った POV のベースラインの実装
次に、図 1 の右側に示した POV の方法を考えてみましょう。この方法は、何らかの選択に基づいて (その選択はデフォルト設定と同じかもしれません) 特定のエンドポイントが選択されていることを前提としています。エンドポイントへのエイリアス付与というのは、ワークフローの中でエンドポイントが事前定義された後、あるいは実行時にワークフローによってエンドポイントが選択された後に、エンドポイントを変更することを言います。この方法の柔軟なところは、ワークフローで選択されたエンドポイントと実際に呼び出されるエンドポイントとを別にすることができる点です。
例えばクレジット・スコアの場合、信用調査会社のサービス・エンドポイントにエイリアスを付与することによって、さまざまな方法でサービス・リクエストを処理することができます。エイリアスを付与したエンドポイントと通常のエンドポイントの違いは、単に別の URI を使うなどの技術的な違いの可能性もあります。あるいは、エンドポイントが異なると、異なるビジネス結果がもたらされる可能性もあります (例えば、リクエスト処理のトランザクション料金が高く設定されている、別のビジネス・パートナーが提供するサービス・エンドポイントを使う、など)。
SCA は、図 1 の方法 2 (Option 2) の POV を利用するための基本的な機能を持っています。また WebSphere Enterprise Service Bus (ESB) と WebSphere Process Server (Process Server) は、方法 1 (Option 1) の POV を実現するために、Web ベースの管理クライアントを使って SCA のインポート・コンポーネントにアクセスすることができます。
図 3 は ESB/Process Server の管理コンソールを示しています。この管理コンソールでは、図 2 の ChoiceOne インポート・コンポーネントに対する Web サービス・バインディングで指定された、具体的な URI を編集することができます。
図 3. WebSphere の管理コンソールを使って実行時にエンドポイントへのエイリアス付与を行う
POV を実装する際の選択肢
「ワークフローでの POV」では、ワークフローに POV を導入することを決定した場合の、導入方法について現実的な検討を行いました。このセクションでは、POV の実装方法と、その方法を実装する際に起こりうる技術的な問題とを関連付けます。こうした技術的な問題を探ることによって、CBS の構築に適用できる WebSphere の具体的な機能の特徴を明らかにすることができます。
サービス・エンドポイントを選択する際の動的性
方法 1 の POV を使う際に考慮すべき重要な事項は、その実装によって一連のサービス・エンドポイントの選択肢を変更できるか、という点です。これはつまり、新しいサービス・エンドポイント E4 を追加しようとする際、あるいは E1 を削除しようとする際に、元からある一連のエンドポイントの選択肢 (E1、E2、E3) をいつ変更できるか、という質問です。下記はそのいつ変更できるかの選択肢です。
-
開発時
- エンドポイントの選択肢の変更は実質的に静的であり、ワークフローの変更が必要なだけではなく、ワークフローの再デプロイメントも必要です。図 2 の左側に示す BPEL は、このタイプの実装の一例です。
-
実行時
- アプリケーションの実行中に、そして純粋に構成によって、一連の選択肢を変更することができます (アプリケーションを変更するか、あるいは再デプロイする必要があります)。
-
呼び出し時
- 実行時の場合と同じですが、サービス・エンドポイントを呼び出すという決定がワークフローの中で行われた後でないと、選択肢を変更することができない、という追加の制約があります。実際には、あるタイプのサービス・エンドポイントがワークフローの中で選択された後、選択されたタイプに合うように一連のエンドポイントの選択肢をフィルタリングします。
サービス・エンドポイントの選択基準の評価
図 1 では、評価をワークフローのスコープ内で行うのかスコープ外で行うのかに関して、いかなる動作をも規定していません。前者の場合は、ワークフローが選択基準を定義するか、あるいは選択基準を使用する必要があります。後者の場合は、ワークフローは選択基準とは無関係です (図 4)。
図 4. 選択基準を評価する方法
ビジネス・ルールなどの機能を使って選択基準の定義からワークフローを部分的に切り離すこともできますが、次のような理由から、選択基準は完全にワークフローとは切り離されていた方が望ましいです。
- 汎用のワークフローは、アクティビティーの各ステップが (対応するサービス呼び出しステップに基づいて) オプションとなるように選択基準をカスタマイズすることで、処理要件に適合するように設計され、実行時にも処理要件に応じて変化することが可能になります。実装の観点から見ると、この選択基準は一連の空のエンドポイント選択肢に対して評価を行うことになり、従ってサービス呼び出しステップを行いません。この方法は、選択基準としてワークフロー・リクエストの重要性を考慮することによって、リクエストのインスタンスごとのワークフローにオプションのステップを提供することもできます。
例えばローンの申し込みのワークフローの場合、申込者のクレジット・スコアが高い場合には、申し込みの承認を手動で行うステップをオプションとする選択基準を設計することができます。
- 決定ポイントを、必要に応じて新しい状況を処理できるように拡張することができます。ローン申し込みのプロセスでは、さまざまなサービス・エンドポイントを使うことで、上顧客と通常顧客を処理することができます。選択基準をワークフローから分離することで、ワークフローに影響を与えずに選択基準を変更することができます。
例えば、上顧客の一部を構成する最上顧客のために、新しい階層を導入することができます。
図 5 は、上で説明した、選択基準をカプセル化することによる利点を示しています。NULL エンドポイントは、(オプション・ステップとして) 対応するサービス・エンドポイントを持たない呼び出しを表します。ここでは、ワークフローを変更せずに、さらにクレジット・セグメントを追加することもできます (例えば 750 以下のクレジット・スコアにマッピングされる E3 サービス・エンドポイントを追加するなど）。
図 5. ワークフローから切り離された選択基準
サービス・エンドポイントにエイリアスを付与するための動的性の選択肢
図 3 は、ESB/Process Server の管理コンソールを使ってエンドポイントを変更する様子を示しています。管理コンソールを使う方法は、WebSphere を使ってエンドポイントにエイリアスを付与する方法を実装するための 1 つの選択肢です。エンドポイントへのエイリアス付与を利用するソリューションの場合、さまざまな実装方法の持つ、次のような特徴を考慮する必要があります。
-
ユーザー駆動型
- 実行時におけるエンドポイントの変更を、人間が行います。ベースラインの SCA 実装は、この方法の一例です。ユーザー駆動による動的性は、サービス・エンドポイントへのエイリアス付与の機能要件を満足できますが、エンドポイントが非常に頻繁に変化するため人間による変更が現実的ではない場合には、ソリューションとしては十分ではありません。
-
スクリプト型
- ユーザー駆動による方法を、自動化によって改善します。例えば、エンドポイントにエイリアスを付与するためのベースライン SCA 実装は、WebSphere のスクリプト・インターフェース (Jacl あるいは Jython スクリプト) を使って自動化することができます。
-
プログラム型
- 基礎となる呼び出し API を使って、実行時に (例えばサービスを呼び出す直前に) サービス・エンドポイントを変更します。例えばエイリアスの付与を、SCA の API を使ってサービス呼び出しを行う Java™ スニペットの一部として実行することができます (リスト 1)。エイリアスを付与されたエンドポイントは、太字で強調されたエンドポイント変数に入れて渡されます。
リスト 1. プログラム型のエンドポイントへのエイリアス付与
com.ibm.websphere.sca.addressing.EndpointReference eRef =
com.ibm.websphere.sca.addressing.EndpointReferenceFactory.
INSTANCE.createEndpointReference();--------------------------------------------------(1)
eRef.setAddress(Endpoint); ------------------------------------------------------------(2)
com.ibm.websphere.sca.Service echoService =
(com.ibm.websphere.sca.Service)com.ibm.websphere.sca.ServiceManager.INSTANCE.
getService("echoService", eRef);-----------------------------------------------------(3)
commonj.sdo.DataObject response = (commonj.sdo.DataObject)echoService.
invoke("echo",ServiceInput);---------------------------------------------------------(4)
|
プロトコルに依存しない、サービス・エンドポイントへのエイリアス付与
メッセージの配信を行うさまざまなプロトコルを処理するために、さまざまなサービス・エンドポイントが使われます。サービス・エンドポイントにエイリアスを付与することによって、メッセージの配信を実装する方法も変わる可能性があります。例えば図 6 の状況を考えてください。選択されたエンドポイント (E1) には E2 というエイリアスが付与されていますが、E1 はメッセージおよびメッセージを配信するプロトコルとして SOAP/HTTP を使っており、E2 は SOAP/JMS (Java Message Service) を使っています。エンドポイントへのエイリアスの付与の実装方法で、プロトコルに依存せずにエイリアスを付与する方法を検討する場合 (次のセクションで説明します)、下記の基準に従います。
- 開発時あるいはデプロイメント時に指定されたものとは異なるメッセージ・プロトコルや配信プロトコルに対して、実行時にエイリアスを付与することを許す。
例えばローンの申し込みフローとして、SOAP/HTTP を使ってクレジット・スコアを提供するエンドポイントから SOAP/JMS エンドポイントへの変更が必要な場合を考えてください。
- 設計や開発の際に指定されたプロトコルを処理する。
例えばローンの申し込みのワークフローを設計する場合、そのワークフローで SOAP/HTTP エンドポイントと SOAP/JMS エンドポイントが使われると想定されるのであれば、実装でそうしたプロトコルが確実に処理できることを検証する必要があります。
- 実装に拡張性を持たせ、実装をカスタマイズすることで設計時や開発時に指定されたものとは異なるメッセージや配信プロトコルを処理できるようにする。
例えば、SOAP/HTTP プロトコルと SOAP/JMS プロトコルとの間でエイリアスの付与を行える実装であれば、その他のプロトコル (例えば SOAP/SMTP あるいは XML/HTTP など) にもエイリアスの付与を行える必要があります。
図 6. プロトコルに依存しない、エンドポイントへのエイリアス付与
メッセージ交換パターンに依存しない、サービス・エンドポイントへのエイリアス付与 (MEPISEA: message exchange pattern independent service endpoint aliasing)
ワークフローとサービス・エンドポイントとの間でメッセージ交換を行うための方法は、数多くあります。最も一般的な方法の 1 つは、同期したリクエスト/レスポンス・メッセージの交換です (図 7)。ワークフローはサービス・エンドポイントにリクエスト・メッセージを送信し、構成可能な期間内にエンドポイントからレスポンスが返ることを想定します。SOAP/HTTP を使った従来のリクエスト/レスポンスは、このメッセージ交換パターンの一例です。この方法は一般的に使われますが、サービス・エンドポイントによる処理時間が長いためワークフローの処理がレスポンスの受信前にブロックされてしまう場合には、当然ながら最適ではありません。
図 7. メッセージ交換パターンに依存しない、エンドポイントへのエイリアス付与
ワークフローの処理にサービス・エンドポイントのレスポンスが不要な場合には、(片方向リクエストなど) 別のメッセージ交換パターンが適切かもしれません。非同期リクエスト/レスポンス・モデルは、レスポンス・メッセージを (例えば BPEL の相関セットを使って) 元のリクエストに関連付けるワークフローに向いています。実装が MEPISEA をサポートするためには、プロトコルに依存しない実装の場合に似た、次のような基準を満足する必要があります。
- 開発時あるいはデプロイメント時に指定されたものとは異なるメッセージ交換パターンに対して、実行時にエイリアスを付与することを許す。
例えばローンの申し込みのワークフローとして、申込者のクレジット・スコアをリクエストしてから 60 秒以内にクレジット・スコアを受信するフローを考えてみてください。このワークフローは、24 時間以内にリクエストにサービスする、異なる信用調査会社を使えるように構成する必要があります。この構成上の変更を実装の面から見ると、要するに、リクエスト/レスポンスの処理を同期型から非同期型に切り替えることを意味します。
- 設計時や開発時に指定されたメッセージ交換パターンを処理する。
考えられるメッセージ交換パターンの数は有限なため、ある特定の実装において、そうしたパターン群を想定することが可能です (そうした例を「参考文献」にあげてあります)。
- 新しいメッセージ交換パターンに対応して拡張できるようにする。
考えられるメッセージ交換パターンを設計フェーズで想定することはできますが (上記 2 番目の基準を見てください)、現実的な制約によって、考えられるすべてのパターンをサポートする実装はできないかもしれません。MEPISEA による POV の実装の柔軟性を評価する際には、新しいメッセージ交換パターンに対応して拡張できるかどうかも検討する必要があります。
POV の実装を選択する
このセクションでは、SCA コンポーネントの基本的な機能と、ワークフローに POV を導入する両方法についての高度な実装方法との比較を行います。図 8 の左側は 6 つの実装を示しています。この図には、他の方法との違いを明確にし、その実装に付加価値を付ける特徴的な機能の概要が示されています。(これらの方法を実装するための詳細な技術的説明については、このシリーズの今後の記事を参照してください。)
図 8. さまざまな POV 実装によって実現される機能
ベースライン SCA 実装 (Baseline SCA implementation)
この方法については、この記事の前の方で説明しました (図 2 と図 3)。
ビジネス・ルール ( Business rules)
ルール・グループとルールは、WebSphere Integration Developer (Integration Developer) で SCA コンポーネントを実装するための 1 つの方法です。ビジネス・ルールによってワークフローの中でサービス・エンドポイントを選択することができ、またビジネス・ルールは開発時や実行時に編集することができます。
開発時に Integration Developer を使うことで、ビジネス・ルールに組み込まれている基準に基づいて、エンドポイント選択の初期実装を定義することができます。この選択基準は、ビジネス・ルール固有の言語 (SDO (Service Data Object) を照会する機能を持つ Java 式のサブセット) を使って表現することができます。あるいは、ビジネス・ルールを含むワークフローがその選択基準と等価な選択表現を Java スニペットの中に持ち、単純にその結果をビジネス・ルールに渡すこともできます。
エンドポイントの選択に関係するビジネス・ルールの実装には、次の 2 つのタイプがあります。
- 選択基準を評価するための if-then ビジネス・ルール
- エンドポイント呼び出しを含み、選択基準の評価結果に従って実行されるアクション・ルール
実行時には、アプリケーションは Process Server の Business Rule Manager を使ってビジネス・ルールを変更することができます。もし選択基準が純粋にビジネス・ルール表現言語で指定されていれば、その基準を完全に書き直すことができます。従って当然ながら、実行時には、この基準はビジネス・ルールに渡される入力パラメーターの制限範囲内でしか変更できません。この制約は、ワークフローの状態すべてをビジネス・ルールに渡せば想定することができ、また緩和することができます。選択基準が Java スニペットを使ってキャプチャーされる場合には、ルール・マネージャー・アプリケーションを使って選択基準を変更することはできません。
ビジネス・ルールを使う、方法 1 の POV 実装 (図 1) は、開発中に指定されるエンドポイントの集合の中からしか選択できないように制限されています。この制限は、各ルールをルール・グループのコンテキストで定義する必要があること、またアクション・ルールはルール・グループの中で事前定義されたパートナー・リンクを使う呼び出ししか定義できないことによるものです。
ビジネス・ルールに基づく方法 2 の POV 実装は、パートナー・リンクへのバインディングに依存することによっても制限されます。パートナー・リンクは SCA の結線に対して解決されるため、ビジネス・ルールへのエイリアスの付与はデフォルトの SCA 実装と同じです。
セレクター (Selectors)
セレクターは、特別な目的の SCA コンポーネントであり、Process Server の一部です。セレクターの一部は、Integration Developer によってサポートされており (後のセクションで説明します)、セレクターを使うことによって、ワークフローを 1 つ以上の SCA インポート・コンポーネントに間接的に結線することができます。ワークフローがセレクターをとおしてリクエストを送信すると、セレクターはそのリクエストを、リクエストごとに評価される選択基準に基づいてエンドポイントにルーティングします。
この記事の執筆時点で、セレクターの完全な機能はツールやラインタイムのユーザー・インターフェースには公開されていません。Integration Developer 6.0.2 は、そのままの状態で、選択基準の変数として日付を使うセレクターのみをサポートしています。セレクターを、(Java を使って指定される) もっと複雑な基準を使うように拡張するためには、SelectionAlgorithm インターフェースを実装するカスタム・コードを作成する必要があります。
実行時には管理コンソールを使ってセレクターを変更できますが、それができるのは Integration Developer がサポートするセレクターの場合のみです。この方法は、SelectionAlgorithm インターフェースを実装するカスタム・セレクターに対しては使えません。コンソールにはセレクターのテーブルを編集する画面があり、あるセレクターが行う Web サービス操作に対応する具体的なサービス・エンドポイントを、その画面から指定することができます。先ほど説明した方法とは異なり、セレクター・テーブルを使うことで、プロトコルに依存しないエイリアスの付与を行うことができます。セレクター・テーブルの各エントリーは SCA コンポーネントに対して解決されるため、各エントリーは HTTP によるインポート・コンポーネントか、あるいは JMS バインディングです。またセレクターによって、エンドポイントの選択に関する実行時の動的性も実現することができます。いったん SCA モジュールが Process Server にデプロイされると、そのモジュールのバインディング・コンポーネントを、セレクター・テーブルのエントリーとして追加することができます。
POV を実装するための候補として、セレクターは適切です。しかしセレクターを実稼働にデプロイしようとする際には、そのリスクを評価することが重要であり、またメディエーション・モジュールやサービス・レジストリー、動的アセンブリーなどに関する POV 実装の機能を十分に理解することも重要です。
セレクター・ベースの実装では、Process Server の管理コンソールにアクセスできる必要があります。しかしそれは、セキュリティー上の理由から、セレクターの選択を編集する役割のアクセス権限と、Process Server の管理者の役割とを分離する必要がある環境では、適切ではないかもしれません。このセキュリティー・リスクは、システム管理者がアクセスできないビジネス・ロジックの中にセレクターを使ってPOV を実装する場合には、特に深刻です。多くの場合、実稼働環境では、ビジネス・ユーザーは Process Server の管理者の機能 (アプリケーションの停止、削除、システム構成の変更など) を持つべきではありません。
セレクターに大きく依存する POV 実装を行うと、開発組織にとっては回帰リスクも発生します。アプリケーションの新しいバージョンをデプロイする際には、そのアップグレードを行う前に、実行時のセレクター・テーブルを、それまでのバージョンのアプリケーションを使ったものから更新する必要があります。もしセレクター・テーブルが頻繁に変更されるとすると、既存のアプリケーションにダウンタイムが発生してしまうかもしれません。
またセレクター・テーブルは Process Server の管理コンソールで変更されるため、サービス・エンドポイントの呼び出し時に動的性がありません。Process Server は、スクリプトを使って (セレクション・テーブルの変更を含めて) 管理コンソールの機能にアクセスできるようになっています。しかし、このスクリプト・インターフェースを使ったエンドポイント呼び出しはパフォーマンスを低下させるため、この方法はほとんどのアプリケーションでは現実的ではありません。
メディエーション・モジュール (Mediation)
ESB/Process Server の用語では、メディエーション・モジュール (MM: mediation module) は一種の SCA コンポーネントです。MM は、(通常はアプリケーション固有のビジネス・オブジェクト (ASBO: application specific business object) と汎用のビジネス・オブジェクトとの間での) メッセージ変換を行うために設計されています。しかし MM は、コンテンツのメディエーションを行うためだけのものではありません。つまり各モジュールの実装 (メディエーション・フローと呼ばれます) は、(特定のステップにコントロール・フローをルーティングする関連のロジックと共に) 別のサービス呼び出しステップを含むことができます。
| |
メディエーション・モジュール (MM) は、さまざまなプロトコル (例えば SOAP/HTTP から SOAP/JMS まで) で、またさまざまなメッセージ交換パターンでエイリアスを付与することができます。今後の記事では、WebSphere Enterprise Service Bus に関して、さらに詳しく説明します。 |
|
MM にはルーティング・ロジックにアクセスして修正するためのランタイム・ユーザー・インターフェースや管理ユーザー・インターフェースはありませんが、サービス・エンドポイントのエイリアス付与に関しては、究極的には MM の方がセレクターよりも柔軟です。
MM は柔軟性やツール・サポートの面で、セレクターよりも一段階優れています。WebSphere Integration Developer は、複雑なプロトコル開発やエンドポイントの独立性の実装に関する開発を支援する、一連のメディエーション・プリミティブを提供しています。例えば、ロギングやイベント通知、リクエスト・ルーティングのためのプリミティブがあります。WebSphere 製品シリーズの観点から見ると、MM は WebSphere Enterprise Service Bus が完全にサポートしている唯一の SCA コンポーネント・タイプです。他の WebSphere Process Server 製品群は、MM と他の SCA コンポーネントをサポートしています。
サービス・レジストリーを持つメディエーション (Mediation with service registry)
ここまでは、POV を実装する方法を説明する中で、サービス・エンドポイントの選択肢を管理する問題を無視してきました。セレクターやビジネス・ルール、メディエーション・モジュールなどに基づく実装には、サービス・エンドポイントに関する情報を保存し、照会し、操作するための標準的な方法がありません。
WSRR (WebSphere Service Registry and Repository) を WebSphere Enterprise Service Bus あるいは WebSphere Process Server と組み合わせて使うことによって、実行時のサービス・エンドポイントの選択に関する動的性を実現することができます。WSRR は、サービス・エンドポイントを管理するための Java API と Web サービス API を、内部レジストリーの中に公開しています。また WSRR は、サービス・エンドポイントを記述するための分類メタデータを追跡することもできます。例えば、下記と共にエンドポイントを WSRR に保存することができます。
- エンドポイントの WSDL インターフェースを記述する関連メタデータ
- 異なるプロトコル・パターンあるいはメッセージ交換パターンを持つ、別のサービス・エンドポイント
- ビジネス情報 (例えばサービス・エンドポイントをホスティングする会社の名前など)
実装の面から考えると、WSRR を照会する SCA メディエーション・モジュールを作成することによって、サービスの呼び出しを実行する前にサービス・エンドポイントを取得することができます。またそれと並行して、BPEL ワークフローあるいは他の WSRR クライアントによって、一連のサービス・エンドポイントを変更することもできます (例えば WSRR を照会するメディエーション・モジュールの動作を変更するなど)。またガバナンス機能によって、そうした変更が行われる際に WSRR クライアントが影響を受けないようにすることができます。
動的アセンブリー (Dynamic assembly)
WBSF (WebSphere Business Services Fabric) は、ワークフローを動的にアセンブリーできる機能を持っています。動的アセンブリーに基づく実装は、他の方法とは異なり、サービス・エンドポイントに対する選択基準に関して、ワークフロー以外のスコープ評価に依存します。ビジネス・アナリストは、Java プログラミングのスキルがなくても、単純な式言語を使って Composition Studio (WBSF のツール部分) の中で選択基準を実装することができます。
WBSF を使う POV 実装は、CBS の開発者にとって最も柔軟な方法です。しかし WBSF を使おうとする際には、WBSF に特有の追加の開発要件を理解することが重要です。
| |
今後の記事では、WSBF を使ってワークフローを実現する方法の詳細について説明します。 |
|
例えば、既存の BPEL ワークフローを、WBSF を利用できるように変更するには、ワークフローを変更し、また動的アセンブリー・エンジンのために追加されるデータとロジックの構造の実装を変更する必要があります。
まとめ
この記事では、POV を公開するための分類された選択肢について、また、そうしたソリューションにさらに高度な機能を追加する利点について学びました。そして、WebSphere 製品の機能によって POV を実現する方法を、ビジネス・ルールやセレクター、ESB を使ったメディエーション、WebSphere Service Registry and Repository を使った動的ルーティング、WebSphere Business Services Fabric を使った動的ワークフロー・アセンブリーなどを含めて学びました。
このシリーズの次回の記事では、WebSphere Business Services Fabric を利用することによって、サービス・リクエストの内容やポリシー、サービス定義、セマンティクスなどに基づいてサービスの動作を適合させる方法について説明します。また、BPEL プロセスのサービス呼び出しを、オントロジーによる拡張と WBSF の Dynamic Service Assembler を使うことによって、いくつかの関連エンドポイントの 1 つに、実行時にバインドする方法を学びます。またクレジット・カードのシナリオを使いながら、実装のためのステップを調べ、私達が直面した問題を探ります。さらに、他の SCA コンポーネント (例えばビジネス・ルールやセレクター、メディエーション・モジールなど) ではなく WebSphere Business Services Fabric を使うことによる利点についても学びます。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | 
| | Germán Goldszmidt 博士は、IBM Software GroupのSenior Technical Staff Memberであり、オンデマンド・ソリューションの配信やカスタム化、デプロイのための統合プラットフォームのアーキテクチャーに焦点を当てた作業を行っています。以前はIBM T.J. Watson Research Centerの研究者として、オートノミック・コンピューティングeUtilityの最初のプロトタイプであるOcéanoや、WebSphere製品の負荷平準化コンポーネントであるNetwork Dispatcherなど、幾つかの技術開発や実装を主導してきました。 |
| 
| | Carl Osipov は、IBM Software Group の Strategy and Technology 組織に所属する経験豊富なソフトウェア・アーキテクトです。彼の専門は、分散コンピューティングや音声アプリケーション開発、計算型自然言語理解などです。彼は SOA や会話型ダイアログ管理に関して、業界関係者や学術界に対して執筆と講演を行ってきました。現在は複合ビジネス・サービスのための再利用技術の設計に取り組んでいます。 |
記事の評価
| 
