エンタープライズ・サービス・バスの再精査

技術進歩に応じた概念および用語の更新

この記事では、サービス指向アーキテクチャー (SOA) におけるエンタープライズ・サービス・バス (ESB) の役割をアーキテクチャーの観点から明確にし、SOA での統合および ESB に関連する用語に磨きをかけます。

Greg Flurry, Distinguished Engineer, IBM Software Group, Business Process Optimization

Author photoGreg Flurry は、IBM Business Process and Service Optimization グループの Distinguished Engineer です。その任務には、顧客との連携によるサービス指向ソリューションの構築、そして IBM サービス指向製品ポートフォリオの拡張が含まれます。


developerWorks
        プロフェッショナル著者レベル

Kim J. Clark, Consulting IT Specialist, IBM Software Services for WebSphere

Photo of Kim J. ClarkKim Clark は、IBM Software Services for WebSphere (ISSW) に勤務する英国出身の IT スペシャリストです。顧客にアドバイスを提供する傍ら、SOA 設計に関する著作活動および紹介を行っています。彼は 1993年から IT 業界でオブジェクト指向プログラミング、エンタープライズ・アプリケーション統合 (EAI)、および SOA に関わり、SOA Foundation Suite 製品を利用した初期のプロジェクトの多くを開発しました。彼は英国ロンドン大学で物理学の学位を取得しました。


developerWorks 貢献著者レベル

2012年 6月 28日

はじめに

IBM developerWorks の連載記事「Exploring the Enterprise Service Bus」が発表された 2007年当時、サービス指向アーキテクチャーとこれに関連する概念および用語は、まだ完全には成熟していませんでした。例えば、その連載の第1回では、「サービス」という用語を曖昧な意味で使用するという (今でもよくある) 罠に陥り、ESB を「統合層」として位置付け、ESB には「ビジネス・ロジック」を組み込めないことを示唆していました。

その頃と比べると、事態は変わっています。この記事では、極めて明確で論理的に一貫性のある一連の概念および用語を定義し、サービスに関する曖昧さを解消する同時に、SOA における統合と ESBの関係、および ESB とビジネス・ロジックの関係を明確にします (そして正します)。また、サービス指向アーキテクチャーを実装しなければならない現実についても取り上げ、最重要要素である関心の分離に焦点を置いて、SOA の実装方法を案内します。


SOA における「サービス」

SOA はサービスを活用して、ビジネス・ソリューションの作成を単純化し、形式化し、さらにアジリティーをもたらします。図 1 に、リクエスター(Requester)プロバイダー(Provider)と相互作用することで、あるビジネス関連のタスクを達成する、SOA の理想型を示します。

図 1. SOA の概念図: 直接的なサービス相互作用
SOA の概念図: 直接的なサービス相互作用

図 1 で「サービス」に該当する部分はどこでしょうか?

以下のステートメントについて考えてみてください。

  • 「私たちはビジネスの運営に必要なサービスの 1 つとして、注文処理サービスを特定しました」。
  • 「サービスとは、反復可能なビジネス・タスクのことです」。

これらのコメントは、「サービス」は物理的なものではなく、抽象的、論理的、または概念的なものであり、基本的には、ビジネス・タスク、または相互作用によって生じるビジネス上の成果であることを示唆しています。The Open Group SOA Work Group による「サービス」の正式な定義は、この解釈と一致しており、「特定の成果をもたらす反復可能なアクティビティーの論理表現」としています。この「サービス」は、公開したり相互作用したりすることはできませんが、このようなアクションは一般に「サービス」と関連します。この定義に従えば、図 1では「サービス」そのものが示されているのではなく、その存在が暗示されているのみであると結論付けられるはずです。さらに踏み込めば、「サービス」はプロバイダーが実行するものであると結論付けられるかもしれません。

次に、以下のステートメントについて考えてみてください。

  • 「私たちは、注文処理サービスをレジストリーで公開する予定です」。
  • 「レジストリーは、新しいソリューションの設計時にサービスを検索するために使用されます」。

このようなステートメントは、「サービス」がより具体的な、何かの仕様でのようなものであると示唆しています。しかし、ここでの「サービス」はまだリクエスターが相互作用できるものではありません。この定義に従えば、図 1 には「サービス」はまったく表されていないと捉えることができ、プロバイダーとのあらゆる相互作用は、「サービス」によって規定されると結論付けることが可能です。

最後に、以下のステートメントについて考えてみてください。

  • 「このユース・ケースでは、私たちは注文処理サービスを呼び出します」。
  • 「私の SOA には、あらゆるアプリケーションが呼び出せる、再利用可能なサービスがあります」。

上記のステートメントは、「サービス」が物理的なもので、リクエスターが相互作用できることを示唆しています。この定義に従うと、図 1 は、プロバイダーが「サービス」であると解釈されます。

このように、「サービス」という用語には以下に示すように、全く異なる解釈が少なくとも 3 通り存在します。

  • より形式的な文脈では、「サービス」はビジネス・タスクの抽象的または論理的表現を指します。
  • より非形式的な文脈では、「サービス」はビジネス・タスクの具体的な説明または仕様の表現を指すこともありますが、多くの場合ビジネス・タスクの物理的実装または実体を指します。
  • 実際には文脈によって、「サービス」はサービス・ライフサイクル上のフェーズに応じて、これらのすべての解釈を表す場合があります。

以上の説明から、文脈および条件を示さないで「サービス」という用語を使用すると、混乱を招き、さらには生産性を阻害するおそれさえあることがわかります。文脈から意味を推測できる場合もありますが、常にそうであるとは限りません。

この記事の残りの部分では、正確性を期すために、曖昧になりがちな「サービス」という用語を使用する代わりに、以下に示す具体的で明確な用語を使用します。

  • ガバナンス対象サービス: SOA によって利用可能になるビジネス・タスクを意味しますが、ビジネス・タスク、仕様、実装、またはそれらの組み合わせなのかどうかについては、特に明確にはしません。例えば、「顧客のアカウント管理用の、ガバナンス対象サービス群を提供している」、というように使用します。
  • サービス仕様: サービスの相互作用に関係する、形式化された一連の特性です。これには、相互作用によって達成されるビジネス・タスク、相互作用の方法に関する技術的側面、および相互作用に関連付けられたさまざまなサービス品質が含まれます。サービス仕様は、具体的かつ物理的な「サービス」を表す形式化された表現です。企業の再利用可能なサービスを定義する (論理的)、またはレジストリーにサービスを公開する (物理的) という文脈では、仕様という用語が正確です。
  • 実体サービス:サービス仕様の物理的実装を意味します。実体サービスは物理エンティティーであるため、呼び出すことができます。実体サービスは、非形式的ではあるものの、最も一般的な「サービス」を意味します。サービスと相互作用したりサービスを呼び出したりする文脈では、実体という用語が正確です。この記事では、実体サービスに必要となる可能性のある事項の全体像を明らかにします。これには、メディエーション、統合、エンタープライズ・サービス・バス、そしてもちろんプロバイダーなどの用語の説明が含まれます。

これらの用語が広く正確に使用されるようになると、SOA に関する意思疎通の曖昧さが減るはずですが、通常の会話でこれらの用語がすぐに使用されるようになるとは期待できません。本来は、「注文処理の実体サービスを呼び出す」、「注文処理のサービス仕様を公開する」などと言ったほうがより正確である一方、正確さよりも会話を単純にすることのほうが、多くの場合優先されるでしょう。

この記事では、混乱を減らすために術語に磨きをかけるつもりです。したがって曖昧にならないように、できる限り上記の用語を使用するようにします。この他にも、二重の意味で使用されている一般的な用語には、サービス操作、サービス公開、サービス・ガバナンス、およびサービス・モデルがあります。本来ならば明確なこれらの用語の意味は、前後のテキストによって明らかになるでしょう。


サービスとサービス操作の違い

「サービス」という用語の使い方に関して、一般的に曖昧になっているもう 1 つの点は、サービスが関連する一連の操作を指すのか、それとも単一の操作を指すのかということです。

正式なアーキテクチャー上の定義では、複数の操作を意味するためにサービスという用語を使用することは可能ですが、それを要件にはしていません。部分的なサービス仕様を定義するための共通メカニズム (WSDL (Web Services Definition Language) など) によって、この考え方は支持されています。

例えば、「顧客」というビジネス・エンティティーを追加、削除、検索、および更新するためのビジネス・タスクが必要だとします。その場合、4 つの操作を持つ単一のサービス仕様で定義された 1 つのガバナンス対象サービスを作成することもできれば、それぞれに 1 つの操作を持つ 4 つのサービス仕様で定義された 4 つのガバナンス対象サービスを作成することもできます。

しかし、通常の会話では、「サービス」という言葉がサービス仕様を指すか、実体サービスを指すかに関わらず、サービス操作の簡潔な表現として使用されることが極めて一般的です。このことも、混乱を招く原因となります。Open Group SOA Work Group では、「サービス」を「特定の成果をもたらす反復可能なアクティビティーの論理表現」と定義していることを思い出してください。この定義自体も、この用語の曖昧な使用例の 1 つです。何かが 1 つのアクティビティーを行う場合、その何かは、実際にはサービス操作を意味します。

サービスとサービス操作の違いは、サービス仕様で規定されている特性を議論する際に重要となります。なぜなら、サービス全体に共有の特性 (例えば通信手段など) もあれば、単一のサービスに固有の特性 (例えば応答時間など) もあるからです。

幸運にも、ここで紹介する概念、見解、および提案の多くは、どちらにせよサービスとサービス操作の違いに影響されることはありませんが、議論に影響する場合には、「サービス操作」という正確な用語を使用します。正確さが重要な場合には、皆さんも同様の使い方をするようお勧めします。


SOA におけるサービス・ガバナンス

SOA 内での「サービス」は、ガバナンス対象サービスであると考えてください。そうすれば、サービスはサービス仕様によって定義され、組織のガバナンス・ポリシーに従っているものであると認識できます。これにより、たまたま比較的使用しやすい形で公開されているだけの機能 (例えば、HTTP/SOAP ベースの API を提供するアプリケーション) と、実際にビジネス関連のガバナンス対象サービスとして見なせるものとの違いを、より明確に区別できるようになります。

この文脈における「ガバナンス対象」が何を意味するかについて、詳しく検討しましょう。

SOA と、それ以前のエンタープライズ・アーキテクチャー向けの手法との大きな違いとは何でしょうか。SOA は、ビジネスに沿ったコア機能を再利用可能なサービスとして公開することを目的とします。このような目的を持つ SOA は、以下の 2 つの非常に重要な側面に分けられます。

  • サービスのビジネスとの整合性管理は、どのビジネス機能を再利用可能にするかに注目します。つまり、ガバナンス対象サービスに要求されているのは、ビジネスの目標達成を支援することです。ガバナンスにおいては、コア・ビジネス機能を前もって識別する必要がありますが、ビジネスが静的でないのと同じく、SOA も静的ではありません。ビジネスの成長と変化に伴い、SOA は徐々に成熟し、進化していきます。したがって、ガバナンスによって、引き続きガバナンス対象サービス (全体としてのサービス・モデル) をビジネスに連携させる必要があります。サービス・モデルの定義および進化のガバナンスに責任を持つのは ESB ではなく、SOA 全体ですが、ESB はこのようなガバナンスの執行に役立ちます。このことが、2 つ目の側面につながります。
  • サービスの公開管理では、これらのビジネス機能を再利用可能にする方法に焦点を置きます。ガバナンス対象サービスを再利用可能 (あるいは、共有可能と言ったほうが正確かもしれません) にするためには、その公開方法は、いくつかの重要な基準を満たす必要があります。これらの基準もまた、SOA おけるガバナンスの対象となります。正しく公開するためには、プロトコル、トランスポート、および適切なサービス品質の目標、ならびにセキュリティー、モニター、ロギング、および監査に関する組織のニーズ、バージョン管理戦略、および適正なオーナーシップが関わってきます。ガバナンスのこれらの側面のすべてが、ガバナンス対象サービスの公開方法に関連するものであり、ESB が実施すべき対象です。上記の側面はいずれもセマンティックに関する特性ではないことに注意してください。つまり、公開されたビジネス機能の意味には何の影響も与えません。アーキテクチャー上、これらの側面は、セマンティックな内容から切り離すことが理に適っているのです。この分離をどのように維持するかについては、後で説明します。

サービス・ガバナンスを達成する方法について考えてみてください。サービス相互作用に関連する重要な特性を記述する方法としては、形式サービス仕様が重要な役割を果たします。実際のところ、論理的なサービス仕様を体系化して物理的な仕様に変換し、組織のビジネス目標への準拠を確実にする自動ガバナンス・プロセスをサポートすることができます (通常はサービス・レジストリーおよびリポジトリーにより)。

「サービス」を企業にとって価値あるものにするには、明らかに、上記の方法でガバナンスを適用する必要があります。サービスにガバナンスが適用されなければ、それらのサービスはサービス・モデルの一部ではなく、SOA の実装の一部に過ぎず、限定的な特定の用途のために作成されたものとして考えなければなりません。したがって、SOA は「ガバナンス対象サービス」で構成されます。このガバナンス対象サービスという用語を使用すれば、従来のインターフェースとの違いを自覚しやすくなります。

最後に 2 点、サービス・ガバナンスに関して付け加えておきます。

  • 一部の組織では、異なるガバナンスのドメイン (例えば、部門別ガバナンス、社内ガバナンス、社外ガバナンスなど) が存在し、ドメインごとにガバナンスの手法が異なることを認識する必要があります。これが意味することは、あるドメインにおけるガバナンス対象サービスであっても、それが他のドメインのガバナンス・ポリシーに準拠しているとは限らず、別のドメインで使用するにはさらに作業が必要となる場合があるということです。幅広い話題を扱っているこの記事では、これ以上の詳細は説明しませんが、SOA が進化してガバナンス対象の環境間での相互作用が頻繁になるにつれ、ガバナンスのドメインの違いは必ず一般的になってくるはずです。
  • サービス・ガバナンスは、企業全体の IT ガバナンスの一部に過ぎません。主にサービスの識別、公開、および管理に関連するサービス・ガバナンスを、コーディング標準や実装技術などの課題を取り扱う別の形の IT ガバナンスと混同しないでください。コーディング標準や実装技術は、幅広い IT ガバナンスにおいては非常に重要な部分となりますが、サービス・ガバナンスとは特に関係ありません。

サービス仕様

前述したようにサービス仕様は重要なので、詳しく検討しましょう。図 2 に示しているのは、論理的なサービス仕様 (Service specification) と物理的な実体サービス (Service Realization: この例ではプロバイダー) との間での、関心の分離を強化し促進している、より全体的で成熟した (ただし、依然として理想的な) SOA におけるサービス仕様の位置付けです。

図 2. SOA およびサービス仕様
SOA およびサービス仕様

図 3 に、サービス仕様のさまざまな観点を示します。サービスと相互作用する主な理由を考えてみてください。サービスのリクエスターは、実体サービスと相互作用して、ビジネス・タスクを達成します。図 3 のセクション (a) に、ビジネス・タスク (Business Task) は一連のセマンティック特性 (Semantic characteristics) によって記述されていることが示されています。セマンティック特性には、実行するビジネス・タスクの説明 (例えば、ショッピング・カートから注文書を作成すること)、およびタスクに関連するビジネス・エンティティー (例えば、顧客、アカウント、ショッピング・カート、発注書) に関するビジネス・インターフェースの定義が含まれます。これらセマンティック特性は、実体サービスとの相互作用によって、ビジネスに関連した用語で達成されるものと考えることができます。

図 3. サービス仕様のさまざまな側面
サービス仕様のさまざまな側面

図 3 のセクション (b) には、構文特性 (Syntactic characteristics) が示されています。構文特性とは、実体サービスと実際に相互作用するために必要なメカニズム (例えば、通信プロトコル、メッセージ・フォーマット、セキュリティー) のことです。これらの特性は、相互作用を成功させるために必要な構文、またはバインディングであると考えることができます。

「サービス仕様」と他に使用されている用語

残念なことに、我々が「サービス仕様」と呼んでいる概念に、他の用語が使用されているのを見たり、聞いたりすることがよくあります。なかでも最もよく使用されている用語は、「サービス契約」です。一般的な意味で使用するには、この用語には欠点があります。契約は、複数のパーティー間での同意を意味するためです。実際のところ、仕様には実体サービス以外のパーティーは関係しません。アーキテクチャーの上では、真のサービス契約は実体サービスを 1 つのパーティーとして参照し、リクエスターパーティーに対する (おそらくサービス品質に関連する) 詳細な取り決めを定義します。

「サービス記述」という用語が使用されることもよくあります。この用語の欠点は、WSDL で使用される場合、この用語が正式にサポートするのは必要な特性の一部だけであることです。

図 3 のセクション (c) は、応答時間、スループット、可用性などの実行特性 (Operational characteristics) を示しています。これらの特性により、実体サービスが最終的には、リソース (CPU サイクル、ストレージ、メモリー、ネットワーク帯域幅など) の限られた 1 つ以上の物理コンテナーで実行されることが分かります。実行特性は、サービス品質として考えることができます。サービス品質は、プロバイダーのコンテナーが適切にサイジングされて構成されていることに依存するため、図 3 ではコンテナーとして表現されています。

関心を分離するためには、サービス仕様に含まれるすべての特性が外部化され、実体サービスによって公開されなければなりません。このようにすれば、サービス仕様に含まれる特性が実体サービスの実装とは独立するため、特性が変更されない限り、実体サービスの実装をサービスのリクエスターに影響することなく変更したり、改善したり、アップグレードしたりできます。これは、実体サービスのすべてのユーザーに、サービス仕様を適用できることも意味します。

このサービス仕様の定義を前提とすると、図 1 および図 2 に示されている直接的なサービス相互作用では、サービス・プロバイダーが実体サービスであることから、以下のことが言えます。

  • プロバイダーが提供する構文特性は、サービス仕様に定義された構文特性を満たす必要があります。
  • プロバイダーが提供する実行特性 (サービス品質) は、サービス仕様に定義された実行特性を満たす必要があります。

以上のことから、図 1 および図 2 のサービス・プロバイダーは、サービス仕様のセマンティクス (ビジネス・タスクを実行すること) を実装するだけでなく、構文特性および実行特性を実装することによって、ビジネス関連のセマンティクスも公開していることになります。

以降の説明では、ビジネス・タスクに関連する特性と、これに関連しない特性を区別するだけで十分な場合もあります。このような説明においては、構文特性および実行特性を非セマンティック特性として 1 つにまとめ、セマンティック特性と非セマンティック特性にのみ言及します。


SOA でサービスを公開するためのメディエーションの使用

図 2 の単純なシナリオでは、プロバイダーがすでに適切なガバナンス対象サービスを提供していますが、現実にはほとんどあり得ません。ここからは、プロバイダーの非セマンティック特性が、サービス仕様を含め、ガバナンス・ポリシーと一致しない場合を検討します。

図 1 および図 2 に関して説明したように、直接的なサービス相互作用では、プロバイダーがサービス仕様に記述されているすべての特性を満たす必要があります。さらに、プロバイダーは組織のサービス・ガバナンス・ポリシーにも忠実である必要があります。しかし、該当するドメイン内のガバナンスの性質によっては、これは困難または不可能な場合もあります。ほとんどのプロバイダーは、関心の分離を維持しつつ、明確なガバナンスが適用されたサービス仕様に忠実であることはできないという事実から、SOA には仲介されたサービス相互作用が必要となります (図 4 を参照)。

図 4. SOA の概念図: 仲介されたサービス相互作用
SOA の概念図: 仲介されたサービス相互作用

翻訳と変換

この記事では、単純にビジネス・エンティティーの表現をある形式から別の形式に変更するだけで、そのオブジェクトの中核的意味を変更しないことを意味する場合には、明確に翻訳という単語を使用します。したがって、翻訳は意味 (セマンティクス) ではなく、表現 (構文) を扱う必要があります。

その一例は、<surname>Flurry</surname> を <secondName>Flurry</secondName> にマップする場合、または <DOB>1960-11-03</DOB> を <DateOfBirth>3rd November 1960</DateOfBirth> にマップする場合です。日付の形式が変わっても、その意味は変わらないことに注意してください。翻訳は通常、データのソースが 1 つしかない場合に行われます。単一のソースのデータを、別の意味を持つ何かに変更するのは容易なことではありません。

優秀な言語翻訳者を例に取ると、英語とフランス語で何かを話す場合、単語や句、さらには文の構造が違っているとしても、同じ意味で話すことができます。翻訳者は純粋に、2 つの言語を仲介しているだけで、新しい意味を付け加えることはしません。確かに、新しい意味を追加することは言語翻訳者の役割ではありません。新しい意味を加えることは、良くても誤解の原因、最悪の場合には違反になります。

一方、変換という言葉は、ここでは意味 (セマンティクス) を変えることを示すために使われます。変換は一般に、複数のソースからのデータを別の形に変える (または、マージする) 場合に行われます。これにより、別の意味を持つ新しいエンティティーを作成できるようになります。

したがって、翻訳はセマンティックを処理しないサービス公開で行われ、変換は新しいエンティティーが作成されるプロバイダー作成 (後で説明) で行われるでしょう。

図 2 と図 4 との間の顕著な違いに注目してください。最初の相違点は、図 4 ではメディエーションがプロバイダーとリクエスターの仲介役となっている点です。メディエーションは、リクエスターと異なる特性を持つプロバイダーとの相互作用を可能にするために導入されますが、これらの特性はどのように異なるのでしょうか。

以前の連載記事の第 1 回で、「サービスはビジネス目標の達成に関連付けられたセマンティクスを実装する」と説明し、その一方でメディエーションは「必要な相互接続性の実現に関連付けられた構文のみを変更する」と説明しました。この説明は、前のセクションでの説明を基にして、調整され明確にされる必要があります。

この連載記事を正しく解釈すれば、メディエーションは、相互作用のセマンティック特性を変更できないことがわかります。しかし、サービス仕様の理解を基にすると、メディエーションは相互作用の非セマンティック特性を操作できると言うほうが適切です。非セマンティック特性には、サービス仕様で定義される構文特性および実行特性 (サービス品質) の両方が含まれます。メディエーションは、通過するメッセージの一連のアクションを実行して、非セマンティック特性を仲介します。メディエーションが実行するアクションには、プロトコルの切り替え、翻訳、暗号化、およびルーティングなどがあります。

図 2 と図 4 の次の相違点は、図 4 では、プロバイダー単独では既に実体サービスではなくなっていることです。これは、プロバイダーは、正しくガバナンスが適用されたサービス仕様に準拠していないことを表しています。プロバイダーが、セマンティック特性、構文特性、および実行特性の一部を提供することは確かですが、ほとんどの場合、これらの特性はサービス・モデルによって明確に定義されるものではなく、またサービス・モデルと共に管理されるものでもありません。ガバナンスが適用されない一連の特性をサービス仕様から区別するために、ここではプロバイダー記述 (Provider description) という用語を使用します。

図 2 と図 4 の最後の相違点は、図 4 では、事実上、メディエーションとプロバイダーの組み合わせが実体サービスとなっていることです。メディエーションはプロバイダーを補強するために、サービス仕様に従ってプロバイダーを公開していると言えます。つまり、サービス仕様で定義された特性を満足させるために、プロバイダーを支援するということです。したがってこの文脈では、メディエーションがサービス公開を行っています。これは、メディエーションを使用して非セマンティック特性を調整することにより、ガバナンス対象外の機能をガバナンスのドメインと一致させるという行為です。

そうすると、メディエーションは、SOA 内でサービスを公開するために使用されると考えることができます。実際には、メディエーションは、サービス仕様に従ってプロバイダーを公開するために使用されると言うほうがより正確です。そして、その最終結果が実体サービスです。

今度は、仲介されたサービス相互作用における、サービス仕様の本質について検討しましょう。関心の分離により、メディエーションは、サービス仕様に定義されたセマンティック特性に対するすべての責任をプロバイダーに委譲します。そのため、図 4 の実線矢印で示されているように、(形式的または非形式的に関わらず) プロバイダー記述のセマンティック特性は、サービス仕様のセマンティック特性の中に反映されます。

プロトコル切り替えとプロトコル変換

サービスを公開する際に、リクエスターとメディエーションの間で、ある特定の通信プロトコルを使用可能にし、メディエーションとプロバイダーの間では、別の通信プロトコルを使用可能にしなければならない場合がよくあります。一般的には、プロトコルを切り替えるという言い方が使われますが、変換という用語が使われることもあります。私たちが最も正確だと思う用語は、切り替えです。実際には、リクエスターとの相互作用ではあるプロトコルが使用され、プロバイダーとの相互作用では別のプロトコルが使用されるため、変換が行われるわけではありません。

メディエーションはリクエスターと相互作用するポイントであり、プロバイダーのあらゆる構文特性をラップしていることから、サービス仕様に定義されたすべての構文特性は、メディエーションが提供します。このことは、プロバイダー記述との関連性がまったくないことによって示唆されています。サービス仕様に含まれる実行特性は、(形式的または非形式的プロバイダー記述にある) プロバイダーの実行特性とメディエーション自体の実行特性の組み合わせから導き出されます。例えば、応答時間やスループットなどの特性は、明らかに、メディエーションおよびプロバイダーの両方の実行コンテナーによって左右されます。これを意味するのが、図中の点線矢印です。

サービスの相互作用についての考察を、今度は仲介された相互作用のために繰り返します。SOA では関心の分離が極めて重視されるので、サービスを公開する際のプロバイダーの役割とメディエーションの役割は、アーキテクチャー上、以下のように別個のものであり異なります。

  • プロバイダーが提供するセマンティック特性は、サービス仕様に定義されたセマンティック特性を満たす必要があります
  • プロバイダーが提供する構文特性は、メディエーションが仲介者としての役割を果たすため、サービス仕様に定義された構文特性を満たす必要はありません
  • プロバイダーが提供するサービス品質の実行特性は、サービス仕様に定義された実行特性を上回る品質でなければなりません。メディエーションは多くの場合、このような品質を低下させる可能性があるからです。ただし、これにはわずかな例外もあります。例えば、適切な状況下でメディエーションが代替プロバイダーにルーティングすることによって、実際にプロバイダーの可用性が改善されることがあります。しかし、この話題は記事の範疇ではありません。

メディエーションとプロバイダーをこのように区別することは、関心の分離には不可欠です。メディエーションがサービス仕様に含まれるセマンティック特性に貢献するとしたら、そのメディエーションはプロバイダーになります。これは明らかに関心の分離に反しており、例えばビジネス・タスクの実装を変更しなければならないときに、その実装がどこにあるのかを「発見」し、変更管理の観点から誰がビジネス・タスクを「所有」しているのかに関する混乱が生じるなど、さまざまな問題につながる可能性があります。

サービス公開: ガバナンス対象サービスとしてプロバイダーを公開する

この記事ではこれ以降、サービス公開という用語をたびたび使用するので、サービス公開とはプロバイダーをガバナンス対象サービスとして公開することであると理解しておくことが重要です。サービス公開が話題にのぼるときには、「サービスを公開する」という表現をよく耳にします。残念ながら、この表現はガバナンス対象サービスがすでに存在していて、そのサービスをただ単に明らかにすれば良いように誤解されるおそれがあります。「サービス公開」とは、プロバイダーをガバナンス対象サービスとして使用できるようにすることであると解釈してください。さらに明確に言うと、「既存の非ガバナンス対象プロバイダーを、サービス仕様に従ってガバナンス対象サービスとして公開すること」です。

上記の定義に従えば、サービス公開に使用されるメディエーションに関しては、アーキテクチャーの観点から以下の原則があると言えます。

  • セマンティクスの透過性: メディエーションは、セマンティックな機能を一切追加しません。メディエーションは、サービス仕様の特性の残りの特性を満足させることによってプロバイダーを公開します。
  • 能動的ではなく受動的: メディエーションがプロバイダーと相互作用するのは、リクエスターがそのメディエーションでの相互作用を開始した場合のみです。
  • 1 対 1 の関係: サービス仕様に含まれるすべてのセマンティック特性はプロバイダーが提供するため、サービス操作の要求ごとに、そのサービス操作のセマンティック特性を満足させるために呼び出されるプロバイダーは論理的には 1 つに限られます。
  • ステートレス: メディエーションは、例えば応答がリクエスターに返された後など、要求が満たされた後は、その要求に関する状態を保持しません。

サービス公開に対するメディエーションの役割とプロバイダーの役割との間の、時として微妙な違いを識別するには、上記の原則が極めて重要となります。


SOA における ESB

図 4 に ESB が示されていないこと、さらにこの図に関する説明で ESB がまったく言及されていないことに注目してください。なぜでしょうか。ESB に関する連載記事の第 1 回では、ESB を SOA におけるアーキテクチャー・パターンと特定しました。これは真実ですが、正確とは言えません。この記事では、ESB はメディエーション・フロー (メディエーション) をサポートするとも示唆しました。これは真実であり、正確でもあります。ESB がサービスを公開するという意見は現在では一般的ですが (前述の記事を書いた当時は、そうではありませんでした)、より正確に言うと、サービス仕様に従ってプロバイダーを公開するのは、個々のメディエーションです。

これが意味するのは、純粋にアーキテクチャーの観点からだけ考えると、前のセクションにリストアップした原則をサポートしているメディエーションを介してサービスを公開することが、SOA における重要なアーキテクチャー・パターンであるということです。したがって、ESB アーキテクチャー・パターンは、サービスを公開している個々のメディエーションの集合に対するサポートであると表現したほうが正確です。以前の記事では、「メディエーション」という用語は常にサービス公開を指すために用いました。しかし、統合に関する幅広い話題で取り上げられるような機能 (例えば、翻訳や切り替え) の使用を指すために、メディエーションという用語が頻繁に使用されています。これは多くの場合、サービス公開の役割について混乱したり、サービス公開やその他の役割のためにメディエーションをサポートする製品を使用したりした結果もたらされたものです。この混乱については、次のセクションで詳しく検討します。

上記の説明から、図 5 に示すように、ESB はサービス公開の役割を果たすメディエーションのアーキテクチャー上のコンテナーであると考えることができます。この図には、1 つ以上の実行コンテナー (プロバイダーを、組織のガバナンス対象サービスとして公開するために使用されるメディエーションをホストする実行コンテナー) に、ESB 自体が収容され、メディエーションを容易に作成、構成、管理できるようになっている仕組みも示されています。これらのコンテナーは多くの場合、製品という形を取ります。

図 5. SOA のトポロジー
SOA のトポロジー

サービス・バスとエンタープライズ・サービス・バスの違い

図 5 では、実際には ESB という用語を使用せず、その代わりにサービス・バスという用語を、このアーキテクチャー・パターンで使用していることに注意してください。これも、SOA の現実を反映した述語の進化です。最近では、プロバイダーを特定のドメイン (例えば、部門別、アプリケーション別、または業種別ドメイン) 内のガバナンス対象サービスとして公開することが非常に一般的となっているため、すべてのガバナンス対象サービスが「エンタープライズ」レベルで公開されると考えるのは、一般には正しくありません。このような状況では、ドメインはドメイン・サービス・バスを使用してガバナンス対象サービスを公開します。公開されたガバナンス対象サービスのほとんどは、その特定のドメイン内でのみ使用されますが、エンタープライズ全体で使用されるものもあります。「エンタープライズ」サービス・バスは論理の上でのみ存在し、サービス・フェデレーション (連載記事の第 4 回を参照) が、企業全体でガバナンス対象サービスを共有できるようにサポートします。

そうは言っても、ESB は定着した用語なので、将来的には一般的に使用されるようになる日が来るはずです。しかし、すべての「ESB」が企業全体にまたがるわけではないことも認識しておいてください。この点が認識されないと、「エンタープライズ ESB」などの用語が一般的に使用される可能性は小さくなります。

サービス・レジストリーおよびリポジトリー

実行コンテナーについて検討していますが、ではサービス仕様はどこに収容されるのでしょうか。サービス仕様はガバナンス対象のエンティティーを意味するため、理想的には、サービス・レジストリーおよびリポジトリーに収容されるべきです。サービス・レジストリーおよびリポジトリーは、サービス・モデル、結果として作成されたサービス仕様、および関連するメタデータを含む、明確なガバナンスが適用されたサービス・ライフサイクル管理をサポートします。そして何らかの形で、サービス・レジストリーおよびリポジトリーは、サービス仕様のコンテナーとなります (図 5 を参照)。理解しておかなければならない重要な点は、サービス・バスの存在が、サービス・モデルを定義したり、サービス仕様、またはサービス・レジストリーおよびリポジトリーの存在を義務付けたりすることはない点です。ガバナンスが、その動機を提供します。


SOA の文脈における統合

このセクションでは、SOA の文脈における統合層の本質について検討し、統合層をメディエーションの役割およびサービス・バスに関連付けます。以前の連載記事では、ESB を「統合層」として位置付けました。混乱を減らし、この記事で規定した概念および用語と整合性を持たせるため、この位置付けを明確にする必要があります。

「統合層」および「統合」はどちらも非常に曖昧な用語であり、これらの用語の定義をどのように解釈するかは文脈しだいです。ほぼすべての文脈で (SOA でも)、統合の定義はエンタープライズ・アプリケーション統合 (EAI) に由来します。それは、「あるアプリケーションが別のアプリケーションと相互作用できるようにするために必要なあらゆること」という定義です。EAI では、統合が明確に扱うのは、アプリケーション間の非セマンティックに関する不整合ですが、EAI で統合がアプリケーション間のセマンティックに関する不整合を扱うこともよくあります。

セマンティックに関する不整合は、アプリケーションの呼び出しに期待されるタスクまたは結果が、別のアプリケーションとの相互作用のどれとも一致しない場合に発生します。重要な点は、必要となるサービス操作の意味を実現する相互作用が 1 つもないことです。疑いの余地のない一例は、bookTripItineray() 操作には takePayment()、reserveAccomodation()、bookFlight()、updateItineraryStatus() などの実行が必要となるのに、「旅行」の予約に必要となるセマンティクスを実行する個々のバックエンド操作がない場合です。そのため、どこかで何かしらが、これらの異なる相互作用の意味を理解して、操作を結び付ける必要があります。したがって EAI では、「統合」がセマンティック・アクションと非セマンティック・アクションの両方を含み、「統合層」がこの両方を実行できるようになっています。

SOA においても、この類の統合が必要でしょうか。もちろん必要です。前述したように、既存のプロバイダーが、サービス仕様で必要とされるセマンティック特性を提供するものの、非セマンティック特性には適合しない場合があります。このような非セマンティックの不整合に対処して、ガバナンス対象サービスを公開するために、メディエーションが導入されました。SOA でも EAI と同様に、サービス仕様で必要とされるセマンティック特性であっても、既存のプロバイダーが常に提供できるとは限りません。実際には、SOA の成熟度サイクルの初期段階では、組織は、既存のプロバイダー・アセットからサービス・モデルを組み立てる際に、「統合」の定義および実装に時間のほとんどを費やします。したがって実際のところ、SOA でも EAI と同じように統合は重要です。

SOA ではどのように統合を実現するのでしょうか。現実には EAI での方法とほとんど同じですが、強調すべき大きな違いがいくつかあります。EAI では、個々のアプリケーションが他のアプリケーションと 1 対 1 で相互作用できるようにすることを目的にする一方、SOA では、すべてのアプリケーションが使用するサービス・モデルを組織全体で共有し、再利用できるようにすることが目的です。SOA では、成熟した EAI と同じく、関心の分離が鍵となります。したがって、SOA での「統合層」は、セマンティック・アクションおよび非セマンティック・アクションの両方を実行するとしても、アーキテクチャー上はこの 2 つを分離する必要があります。

サービスを公開するために使用するメディエーションは、相互作用の非セマンティック特性のみを操作できることを既に明確にしました。したがって、サービス・バスが SOA の統合層に提供できるのは、非セマンティックの「サブ層」だけです。既存のプロバイダーがサービス仕様のセマンティック特性の要求を満たせない場合には、統合層の他の部分がセマンティクスを操作する必要があります。このことから、サービス・バスが統合層全体ではないことは明らかです。少なくとも、ほとんどの人によって定義されている統合層で、このことが当てはまります。その一方、サービス・バスは統合に含まれる非セマンティック・サービスの公開を行うことから、サービス・バスは統合層の一部であり、サービス公開のメディエーションは統合の 1 つの形であることも確かです。完全を期すために指摘しておくと、稀な場合ですが、既存のプロバイダーがサービス・モデルのセマンティクスと完全に一致し、サービス・バスを限定的な統合層と見なせる場合もあります。

図 6 を用いて詳しく説明すると、図の一番上に示された実体サービスは、図 4 で説明したものとまったく同じです。サービスを公開するために使用されるメディエーションは、サービス・バスの一部として、サービス仕様と、そのサービス仕様によって暗示されるセマンティクスと一致する既存のプロバイダーとの間の非セマンティックの不整合に対処します。したがって、サービス・バスが提供するサービス公開層は、より機能的な統合層によってカプセル化されていることになります。

図 6. 統合層、メディエーション、および作成
統合層、メディエーション、および作成

今度は図 6 の一番下に示された実体サービスを見てください。この例では、サービス仕様によって暗示されるセマンティクスと一致する既存のプロバイダーは存在しません。通常この事態は、ビジネス・タスクの粒度が、プロバイダーによる相互作用が提供するどの粒度よりも大きい場合に発生します。セマンティクスと一致するように粒度を大きくしたビジネス・タスクを作成するには、大抵の場合、(ビジネス・エンティティーおよび複合エラー処理の作成を含む) 仲介「ロジック」を使用した一連の相互作用が必要です。このロジックは、サービス公開に使用するメディエーションから想像できる機能とはまったく異なる一連の機能からなります。

このセマンティック操作を行うには、アーキテクチャー上、分離された層が必要です。一般的には、この追加層が、粒度の細かいビジネス・タスクから粒度の粗いビジネス・タスクを作成します。一部の文脈では、これはサービス作成と呼ばれ、以前は存在しなかったビジネス・タスクを作成する行為と言えます。つまり新しいセマンティック特性を実装するということです。さらに正確に説明すると、この追加層はプロバイダー作成を実施します。つまり新しいセマンティクスは、既存のプロバイダーが存在せず、新しいプロバイダーがサービス仕様に含まれる非セマンティック特性を提供する必要もない (あるいは提供できない) ことを意味するはずだからです。

図 6 には、サービス公開層、プロバイダー作成層、既存のプロバイダー、サービス仕様、および実体サービスと、包括的な統合層との関係が示されています。この図で強調されているのは、(サービス公開のための) メディエーションおよびプロバイダー作成は、いずれも実体サービスに貢献するものの、この 2 つは関心の分離のため、アーキテクチャー上は分離されていることです。重要な点として、アーキテクチャー上は、サービス・バスはサービス公開層だけを提供することに注意してください。

ここで、サービス公開とプロバイダー作成の違いを明らかにする 2 つのシナリオを簡単に検討しましょう。

図 7 に示す最初のシナリオでは、サービス操作のサービス仕様によって規定されているとおりのこと (ビジネス・タスク、ビジネスおよび技術インターフェース、プロトコル/フォーマットなど) を行う既存のプロバイダーを仮定しています。ただし、このプロバイダーに対する要求は HTTPS で保護するという必要性は除外しています。

図 7. 統合層でのサービス公開
統合層でのサービス公開

サービス仕様への非セマンティックな貢献の好例は、暗号化の追加です。プロバイダーはビジネス・タスク、およびこの例では非セマンティック特性の (すべてではなく) 大部分を実装します。プロバイダーを変更せずに HTTPS の使用を可能にするのは、メディエーションです。このシナリオでは、明らかにメディエーションはセマンティクスには何も追加しません。前述のように、サービス公開のためのメディエーションは、サービス・バス内にのみ存在します。

図 8 に示す 2 番目のシナリオでは、サービス操作のサービス仕様に含まれるセマンティック特性を、リモートからであっても提供する既存のプロバイダーは 1 つもありません。この場合、複数のプロバイダーと相互作用し、通常は追加の仲介ロジックによって仕様のセマンティック特性を満たすことが必要となってきます。サービスを公開するためではなく、既存のプロバイダーとの相互作用をサポートするためだけにメディエーション機能が利用されることも珍しくありません。ここでは事実上、粒度の細かいビジネス・タスクの集合を、サービス操作のサービス仕様と合致する単一の粒度の粗いビジネス・タスクに変換しています。

具体的な例としては、顧客アカウントを検索する手段として、あるシステムからアカウント情報を取得し、別のシステムから顧客情報を取得する場合が挙げられます。いずれのプロバイダーも完全なセマンティック特性を持っていないため、この 2 つの異なるエンティティーを意味のある形でマージするためのセマンティック・アクティビティーが必要であることは明らかです。これは、サービス公開の範囲を超えており、プロバイダー作成の範疇に入ります。非セマンティック・サービス公開を行うメディエーションが、この構成とは独立して実装されることは、関心の分離によって確実になります。

図 8. 統合層でのプロバイダー作成およびメディエーション
統合層でのプロバイダー作成およびメディエーション

要するに、アーキテクチャーから見ると SOA の統合層には純粋な非セマンティック・サービス公開サブ層が含まれます。このサービス公開は、プロバイダー作成サブ層に含まれるサービス・バス・パターン、およびより充実したセマンティック機能によって実現されます。前者のサブ層は常に存在し、後者のサブ層はほとんど常に存在します。したがって通常は、サービス・バス (ESB としても知られます) だけでは、SOA の統合層としては十分ではありません。


ビジネス・ロジックと統合ロジックとの違い

次に、「統合ロジック」および「ビジネス・ロジック」という用語について検討します。以前の連載記事の 1 つでは、この記事で説明した統合層およびサービス・バスの文脈でこれらの用語を使用しています。このセクションでは、どちらの用語も曖昧であり、サービス・バスまたは統合層の本質を説明するには役に立たないことを明らかにします。それと同時に、これらの代わりに使用できる、より意味があり、役に立つ用語を提案します。

以前の連載記事では、「ビジネス・ロジックは、ビジネス目標の達成に関連付けられたセマンティクスを扱う」と述べ、その一方で、「統合ロジックは、必要な相互接続を実現するために関連付けられた構文のみを変更する」と述べています。前のセクションでの統合層およびサービス・バスの説明を基にすると、矛盾があることに気付きます。その 1 例は、ビジネス・ロジックは統合ロジックの 1 つの形であるということです。問題は、用語があまりにも単純化されていて、正確さを欠いているところにあります。本来は、ビジネス・ロジック統合ロジックを比較するのではなく、影響オーナーシップ (所有権) によって分類されたロジックを比較すべきです。

ロジックの影響は、以下のようにサービス仕様の特性に関係します。

  • セマンティックな影響は、セマンティック特性のみに対する貢献を意味します。
  • 非セマンティックな影響とは、非セマンティック特性のみに対する貢献を意味します。

ロジックのオーナーシップは、そのロジックを定義および変更する役割またはグループに関係します。統合層では、重要なオーナーシップの役割が、以下に示す 2 つ存在します。

  • 役割としてのビジネスでは、セマンティックな目標か、非セマンティックな目標かに関わらず、すべてのビジネス目標 (「理由」) を定義します。ビジネスは、ビジネス目標を達成するためのいかなるロジックであっても、それがセマンティックな影響を持つか、非セマンティックな影響を持つかに関わらず、定義し変更することができます。
  • 役割としてのITでは、ビジネス目標の達成を支援するインフラストラクチャー (「方法」) を実装します。IT は、ビジネス目標を達成するためのロジックの内、非セマンティックな影響を持つものだけを、定義し変更することができます。

図 9 に、3 つの適正なロジック・カテゴリーを示します。これらのロジックは、ビジネスが所有するセマンティック・ロジック、ビジネスが所有する非セマンティック・ロジック、および IT が所有する非セマンティック・ロジックということになります。IT が所有するセマンティック・ロジックは、当然のことながら無効です。セマンティクスは、ビジネス・タスクの意味に関するものだからです。

図 9. 統合層でのロジック
統合層でのロジック

言うまでもなく、ビジネスが所有するセマンティック・ロジックは、プロバイダー作成サブ層に存在します。このサブ層の目的はまさに、新しいセマンティクスを導入することだからです。

同じく明らかなことですが、IT が所有する非セマンティック・ロジックは、メディエーション/サービス公開サブ層に存在します。このロジックには、プロバイダーの健全性など操作上の考慮事項に基ずいて、ルーティングにも影響する、IT が所有する「ポリシー」または「ルール」が含まれます。私たちの意見では、IT が所有する非セマンティック・ロジックは、プロバイダー作成サブ層にも存在します。なぜかと言うと、例えば、新しいプロバイダーが、既存のプロバイダーと異なるメッセージ・フォーマットを使用して相互作用しなければならない場合を考えてください。その場合、メッセージを変換して相互作用を可能にするために必要となる非セマンティック・ロジックは、IT が所有しなければなりません。これにより、関心の分離が維持されます。

それほど明らかではないタイプのロジックは、ビジネスが所有する非セマンティック・ロジックです。これは、プロバイダー作成サブ層、およびサービス公開層に存在します。このようなロジックは、基本的なセマンティクスを変更するのではなく、例えば基本的なセマンティクスに関係するパラメーター値のみを変更します。サービス公開層での一例は、プロバイダー間のルーティングです。つまり、ルーティングの決定が、上客からの要求に対してより品質の高いサービスを提供するために、ビジネスが所有する「ポリシー」または「ルール」に基づいて行われる場合です。これらはビジネスが所有するポリシーですが、要求のセマンティックな意味を満たすことは一切行いません。

これで、SOA の統合層に含まれるロジックについて、より正確に言及できるようになったはずです。サービス公開層に存在するメディエーションに収容できるのは、非セマンティックなロジックのみです。そのロジックを所有するのは、一般には IT ですが、ビジネスが所有することもできます。つまり、メディエーション (したがって、サービス・バス) にビジネス・ロジックを収容できるのは、それが非セマンティック・ロジックである場合に限られると言えます。プロバイダー作成層には、ビジネスが所有するセマンティック・ロジック、および両方のタイプの非セマンティック・ロジックを収容できます。

ロジックの異なるタイプを区別するのは、ロジックをタイプ別に独立して実装することが重要だからです。ロジックの更新は、その役割ごとに異なる変更サイクルで、大抵は異なるツールを使用して、さらには異なるガバナンスで行う必要があります。これは、関心の分離を実質的に維持するためです。タイプの違いは、IT が所有するロジックと、ビジネスが所有するロジックの間ではかなり明白ですが、ここで紹介しているのは、ビジネスが所有する 2 つのタイプのロジックについても明確に分離すべきだということです。これらのロジックは、それぞれに異なるビジネス所有者が所有し、変更する可能性が高いためです。


アーキテクチャーと実装との違い

このセクションでは、以前の連載記事全体を通して説明した、アーキテクチャー、アーキテクチャー層、アーキテクチャーの役割、およびアーキテクチャーの原則 (関心の分離など) について取り上げます。しかし、アーキテクチャーが単独でビジネス価値をもたらすことはできません。アーキテクチャーは適切な技術または製品を使用して実装される必要があります。次に、特に統合層に重点を置いて、SOA の設計および実装という用語の語用論についても検討します

SOA では、関心の分離が不可欠です。そのため、明確な関心の分離を達成するために必要なアーキテクチャー層を定義する必要があります。これが、統合層自体が存在する理由であり、さらに統合層の中にメディエーション/サービス公開層およびプロバイダー作成サブ層が含まれる理由です。SOA の実装が失敗するよくある原因は、関心の分離を促進する階層化アーキテクチャーを定義できなかったために、柔軟性がなく管理しにくい実装につながったためです。例えば、一部の企業では統合層とサービス・バスの違いを評価していないため、サービス公開とプロバイダー作成を混合し、事実上ビジネスの責任と IT の責任が不適切に混在する結果となっています。

しかし、理想的な階層化アーキテクチャーは、妥協を許さず実装しなければならないと言っているわけではありません。実際、ほぼ必ずと言っていいほど、パフォーマンスやコスト、技術の制約などを理由に妥協せざるを得なくなります。例えば、パフォーマンスを改善するために、物理的な階層化ではなく、簡潔な論理的階層化を使用する場合もあります。問題は、妥協するかどうかではなく、アーキテクチャーの意図を維持しつつ、関心の分離を最大化するためにできる最小限の妥協は何か、またどこで行うかについてです。

当然のことながら、アーキテクチャーを実装するためには、それぞれのアーキテクチャー層に適用する実装技術を選択しなければなりません。SOA では、特定の層をターゲットとしている製品がしばしば存在します。そのような製品は、ターゲットとする層の開発、保守、および実行時間という点では非常に優れていますが、他の層に使用するのは適切でありません。層に対する技術の選択は、ターゲットとするアーキテクチャー層だけでなく、スキルや既存の製品リスト、開発コスト (このコストにはツールが大きく影響します)、サービス品質、オーナーシップの総コスト、あるいはこれらの組み合わせを基準にして行われる場合もあります。どの層がターゲットとされているかということより、他の基準のほうが重要である場合には、その層をターゲットとしていない技術を利用してもまったく問題ありません。重要な考慮事項は、層に製品を一致させるのではなく、むしろ、定義された個々のアーキテクチャー層が最終的なソリューションでも容易に識別されるようにすることによって、関心の分離を可能な限り維持することです。

図 10 に示す非常に一般的な状況では、サービス・バス (ESB) パターンをターゲットとする製品を含む統合製品を使用しています。ESB 製品は、非セマンティック機能 (アダプテーション (Adaptation) 、翻訳 (Translation) 、ルーティングなど) に加え、これらの基本機能を順序付ける能力に焦点を置いています。当然ながら、これらの機能はサービス公開層でメディエーションを作成するために利用されます。

図 10. アーキテクチャーおよび統合製品
アーキテクチャーおよび統合製品

上記の図に示された機能は、プロバイダー作成層でも使用できます。しかし、サービス・バスのメディエーション・フロー機能は、プロバイダーの作成で使用されるような相互作用シナリオに必要な複雑な意思決定ロジック、例外処理、および状態管理を対象として設計されてはいません。その一方、他のビジネス・プロセス指向の製品 (例えば、BPEL エンジン) が焦点を置くのは、複雑な例外処理に対処し、長時間実行されるプロセスを保持して処理中の状態を表現できる複雑なフロー機能です。このような機能がプロバイダー作成層に必要となることはよくあります。前述したように、サービス公開層ではセマンティクスへの影響がない場合、アジリティー (ルールなど) の改善に貢献する高度な機能が使用される場合もあります。

参考となる例として、図 8 のプロバイダー作成シナリオで、ビジネス・プロセスをターゲットとする IBM WebSphere® Process Server が環境に含まれているとします。WebSphere Process Server に組み込まれている IBM WebSphere ESB は、メディエーションをターゲットとする製品です。この場合、ターゲットとされている開発機能とランタイム機能を利用する最適なソリューションは、WebSphere ESB のメディエーション技術を使用してメディエーションを実装することになるでしょう。WebSphere Process Server 技術は、新しいプロバイダーの作成に適した高度なツールとランタイム機能を提供するため、新しいプロバイダーを作成するためには最適な選択です。一方、新規プロバイダーの複雑さと開発チームのスキルによっては、WebSphere ESB 技術をプロバイダーの作成に使用することもできます。ここでも同じく、重要な目標となるのは、関心の分離を維持することです。

要約すると、SOA を成功させるためには、明確に関心が分離された層を設計し、これらの層を可能な限り関心の分離を維持するように実装する必要があります。層を実装するには、その層をターゲットとしている技術であるかどうかに関わらず、妥協が理解され、関心の分離に及ぼす影響を最小限にする限り、任意の技術を使用できます。ライフサイクルのモデル・フェーズおよびアセンブル・フェーズでの優れたガバナンスが、適切な関心の分離を確実する上で非常に役立ちます。


まとめ

この記事では、SOA アーキテクチャー・パターンのエンタープライズ・サービス・バスに関連する広範なトピックおよび述語を正確かつ明確にすることを試みました。実際、「エンタープライズ・サービス・バス」という用語はしばしば不適切であり、単にそれを提供する組織についての詳細な知識を持たない「サービス・バス」という用語のほうが適切であることを示しました。そうは言っても、ESB という用語が非難されることはありそうにないこともわかっています。

「サービス」という用語に関しては、文脈および条件を限定せずに使用すると混乱を招き、逆効果となることもあるため、より正確な用語として、純粋に論理的なガバナンス対象サービスという用語を強く推奨しましたが、それでもまだ多少の曖昧さが残ります。この用語は、「サービス仕様」という用語を使用して、ガバナンス対象サービスの外部化されたセマンティック特性、構文特性、および実行特性を形式的に表現し、さらに「実体サービス」という用語を使用して、サービス仕様の物理的実装を表現することによって、より正確さが増します。

「サービス・バス」という用語は現実には、セマンティクスが透過的な「サービス公開」を行う (つまり、サービス仕様に従ってプロバイダーを公開する) メディエーションの集合を指す論理的な表現 (そして物理的にはそのコンテナー) であることを説明しました。また、サービス・レジストリーおよびリポジトリーが、サービス仕様に必要なガバナンスを提供する (そして、サービス仕様のコンテナーと見なすことができる) ことを説明しました。

サービス・バスは完全な統合層ではありません。少なくとも、セマンティックなアクションおよび非セマンティックなアクションの両方を実行する EAI スタイルの統合層とは言えません。メディエーションは統合の 1 つの形であり、サービス・バスが提供する非セマンティックな「サービス公開」サブ層は、SOA での統合層の一部です。この統合層には、1 つ以上の粒度の細かいプロバイダーを用いて粒度の粗いプロバイダーを提供する「プロバイダー作成」サブ層も含まれます。

SOA の統合層に含まれる「ロジック」について、より正確に言及する方法も説明しました。ビジネス・ロジックと統合ロジックという用語は混乱を招きがちであり、ビジネスが所有するセマンティック・ロジック、ビジネスが所有する非セマンティック・ロジック、および IT が所有する非セマンティック・ロジックという用語を使用するほうがより正確であることを説明しました。さらに、サービス公開層に収容できるのは非セマンティック・ロジックのみであるが、この層にビジネスが所有する非セマンティック・ロジックを組み込むことで、ビジネス・ロジックをサービス・バス (ESB) で利用できることも説明しました。

そして最後に、SOA を成功させるためには、最初に関心の分離を保証するために必要な層を設計した上で、それぞれの層で使用する必要最小限の実装技術だけを選択して、関心の分離を維持することを示しました。さらに、あるアーキテクチャー層をターゲットとしている製品でも、関心の分離を維持できるのであれば、他の層にも使用できることを説明しました。


謝辞

この記事に貢献し、レビューを行ってくれた Andy Garratt、Guy Hochstetler、Andy Humphreys、Brian Petrini、Rachel Reinitz、Marc-Thomas Schmidt、Andre Tost に感謝します。

参考文献

コメント

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=WebSphere
ArticleID=823145
ArticleTitle=エンタープライズ・サービス・バスの再精査
publish-date=06282012