SOA リファレンス・アーキテクチャー標準に対する IBM のアドバンテージ

IBM の SOA 標準

この記事では、お客様がビジネスならびに IT の柔軟性を向上させるのを支援するために、IBM ではどのように SOA リファレンス・アーキテクチャー (SOA Reference Architecture (SOA RA)) を開発して使用しているのかを説明します。SOA リファレンス・アーキテクチャーは、組織がそれぞれに固有の SOA ビジネスの目標に具体的に従って、高度なビジネス・アジリティーと IT の柔軟性をサービス統合という手段で実現できるようにするために使用されています。IBM では、組織が独自のクラウド・ソリューションを定義できるように、SOA リファレンス・アーキテクチャーをクラウド・リファレンス・アーキテクチャーとも組み合わせて使用しています。

Heather Kreger, Destinguished Engineer, CTO International Standards, IBM

Heather Kreger は、IBM Software Group で SOA 標準の国際標準化最高技術責任者兼主任アーキテクトを務めています。標準化に 15 年間取り組んできた彼女は、これまで ISO/IEC、W3C、OASIS、DMTF、および The Open Group で SOA、クラウド、Web サービス、管理、および Java を対象とした標準の開発を主導してきました。数々の記事を執筆するとともに、仕様の作成にも携わっています。著書には『Java and JMX, Building Manageable Systems』があります。また、『Navigating the SOA Open Standards Landscape Around Architecture』では編集を手がけました。



Vince Brunssen, Senior Software Engineer, IBM

Vince Brunssen は、IBM の標準化組織に勤めるシニア・ソフトウェア・エンジニアです。現在、OASIS で S-RAMP (SOA Repository Artifact Model and Protocol) の標準化への取り組みを主導しています。彼は、The Open Group の SOA 標準化の取り組みにも貢献しています。



Robert Sawyer, SOA Marketing Lead, IBM

Robert Sawyer は、SOA ソリューションを専門とする IBM WebSphere の製品マーケティング・マネージャーです。この任務に就く前は、イベント処理の分野に深く関与しており、IBM のビジネス・イベント処理 (BEP) カテゴリー・レベルのメッセージングおよび取引戦略の定義に協力していました。過去の任務としては、数々の IBM グループや ECM、電子メディア管理システム (EMMS)、IBM SCORE (Solution for Compliance in a Regulated Environment) などの製品、そしてヘルスケアおよびライフサイエンス業界のソリューションで、ソフトウェア・エンジニアリングを担当した経験もあります。



Ali Arsanjani, Ph.D., IBM Distinguished Engineer, CTO SOA Emerging Technologies, IBM

Dr. Ali Arsanjani は、IBM Global Services に所属する SOA Emerging Technologies の CTO です。彼がリーダーを務めるチームは、SOA で世界規模のコンピテンシーを発展させ、IBM のツール、IBM 以外のツール、そして SOA オファリング (そのほとんどにおいて彼自身も開発に参加) を使用して一層卓越した SOA ソリューションを実現することを任務とし、新しい技術と SOA オファリングで SOA 分野における IBM の構想と戦略を立て、その戦略を実践する責任を担っています。現場で直接指揮を執る彼は、世界各国の IBM の主要なお客様の間で引っ張りだこのアーキテクトです。Dr. Arsanjani は IBM の技術と最新の SOA オファリングを使用してクライアントに SOA を提供するため、IBM Software Group や IBM Research、そして IBM Global Business Services のその他の部門と協力しています。IBM Global Services 所属の SOA and Web Services Center of Excellence では、チーフ・アーキテクトとしてチームに加わり、SOA および Web サービスをモデル化、分析、設計、実装するためのベスト・プラクティスの収集および開発を専門としています。彼は IBM 内部でグローバルに展開されている SOA and Web Services Community of Practice (6000 人を超えるメンバーで構成) のリーダーであり、SOA や SOA 関連のアセット、オファリングおよびツールを対象とした SOMA (Service-Oriented Modeling and Architecture) 方法論の中心的作成者として、これまで Rational ソフトウェアの機能拡張およびプラグインを使用した SOA ツールに重点的に取り組んできました。SOMA-ME (SOMA Modeling Environment) と呼ばれるこのツールは、IBM の SOA 方法論と SOA ソリューション開発用アセットをサポートするものです。SOMA-ME については、2008年 8月版の IBM Systems Journal に記載されています。Dr. Arsanjani は世界中のさまざまな国、さまざまな業界で SOA コンピテンシーの開発に携わっています。彼は SOA 分野での IBM ツールとアセットの開発をサポートするチームを育成すると同時に、IBM の最大規模のクライアントに日々関わっています。また、GBS のグローバル戦略の実践だけでなく、IBM のオファリングをサポートするツールの評価と開発にも取り組んでいます。彼は、The Open Group などの標準団体で IBM の代表を務め、The Open Group では SOA リファレンス・アーキテクチャーと SOA 成熟度モデルの両標準で共同リーダーとしての役割を担っています。IBM 内では、新しい技術とツールの調査、そしてサービスと、サービスの実現を成功させるために必要なソフトウェアを、世界中の 6000 人以上の実務者たちの間で拡張可能かつ繰り返し可能な方法で組み合わせるというコンサルティング・オファリングの調査でリーダーを務めています。



Rob High, IBM Fellow, VP - BPO Foundation, IBM

Rob Highは、SOA Foundationのチーフ・アーキテクトであり、IBM Academy of Technology の IBM Fellow、Vice President、およびメンバーです。彼は、SOA およびビジネス・プロセス最適化によって可能になるビジネスと IT の同調の原則によるオープン業界アーキテクチャー定義を確実にするという任務、そして IBM のソフトウェアとサービス・ポートフォリオをアーキテクチャーの基礎として効率的な SOA ベースのソリューションを実現するという任務を担っています。この任務は、SOA の有効化に関係する WebSphere、Rational、Tivoli、Lotus、および Information Management 製品を含めた IBM ソフトウェア・ポートフォリオ全体に及びます。



2012年 3月 08日

はじめに

SOA (Service Oriented Architecture) は、エンド・ツー・エンドのビジネス・ソリューションを可能にする柔軟で再利用可能なアセットの作成を容易にするためのアーキテクチャーです。世界中のさまざまな業界の企業が各種のプロジェクトで SOA の原則と SOA 関連の手法を採用するようになるのに伴い、リファレンス・アーキテクチャーの必要性が明確になってきました。SOA による価値提案を実現するためには、SOA リファレンス・アーキテクチャーを使用することが成功の鍵となります。

The Open Group が新たに公開した SOA リファレンス・アーキテクチャー標準は、クラウド・ソリューションのアーキテクチャーを含め、サービス指向ソリューションのアーキテクチャーの設計および実装を決定する上でのガイドラインとオプションを規定しています。SOA リファレンス・アーキテクチャー標準の目的は、アーキテクチャーを作成して評価するための青写真を提供することです。さらにこの標準では、SOA の基本要素をソリューションやエンタープライズ・アーキテクチャーに統合するための洞察を行い、そのためのパターンやビルディング・ブロックを明らかにしています。

SOA の価値

サービス指向アーキテクチャー (SOA) として知られるようになった、このアーキテクチャー・スタイルでは、コンポーネントの実装が公開されて既知となるのではなく、提供されるサービスのみが公開されます。つまり、サービスのプロバイダーは、サービスの実装の詳細をコンシューマーには見えなくするということです。実質的には、サービス・コンシューマーが使用するサービスのインターフェースをサービス・プロバイダーによる実装とは疎結合にするのに加え、実装とそのバインディングとを切り離すことで、インターフェースと実装との分離はプログラミング・レベルからアーキテクチャー・レベルにまで引き上げられています。

SOA では、ビジネスと連携した一連の IT サービスによって集合的に組織のビジネス・プロセスとビジネス目標がサポートされ、これらの IT サービス (で構成される契約) に関する合意を通じて、ビジネスと IT の収束が実現されます。SOA は、再利用可能で分離された柔軟な機能を提供するのみならず、サービス品質の変動を外部化するためのメカニズムを宣言型の仕様 (WS-Policy やこれに関連する標準など) の中で規定します。この疎結合により、ソフトウェア・ソリューションでの柔軟なソフトウェア・コンポーネントの構成が可能になり、さらにこの柔軟な構成により、アプリケーション開発者はビジネス要件の変更に応じて迅速にソリューションを変更できるようになるというわけです。新しいビジネス要件を満たすための新たなソリューションは、同じ構成概念を使用して、つまり以前のアプリケーションで作成したコンポーネントを再利用することによって、迅速に提供することができます。コンポーネントは、異なる状況での個々のビジネス要件にきめ細かく対応するように設計することができます。

ビジネスにおける SOA の主要な利点

SOA には、柔軟で拡張可能なアーキテクチャー・フレームワークとして、以下の特徴があります。

  • コストの削減: これまで投資したアプリケーション機能を利用する一方で、重複する機能は統合し、時代遅れで次第にコストがかさむようになってきたアプリケーションからは機能を切り離す機会を提供します。
  • アジリティー: 一連のビジネス・サービスと IT サービスをベースに、ビジネス・プロセスとそれを使用するソリューションを迅速に再編成および再構成できるような方法でビジネス・ソリューションを構造化します。
  • 競争上の優位性の強化: 新たな市場に参入し、疎結合された一連の IT サービスを使用した新しい革新的な方法で既存のビジネス機能を活用する機会を提供します。より優れた新しいビジネス・サービスを提供することで、おそらく市場占有率およびビジネス価値が高まる結果がもたらされます。
  • 製品化までの時間: ビジネスが何をソリューションの中心に据えて進めていくかを決定できるようになり、IT がその意思決定を素早くサポートして実装できるようになるため、ビジネスと連携したソリューションを提供するまでの時間が短縮されます。
  • 統合: サイロ化されたソリューションと組織を統合して、物理的なシステムの数を減らし、複雑に絡み合ったレガシーの依存関係から整然と統合された共存システムへの「グレースフルな遷移」プログラムのもと、プラットフォームを統合することができます。
  • 連携: 組織がビジネスの目標と IT をより適切に連携できるようになることから、ビジネスは組織が戦略的計画に従って実現しようとしている機能を IT に関連付けられるようになります。これにより、持続的なアジリティーと長期間にわたる再利用という結果につながります。

リファレンス・アーキテクチャーの目的および利用法

リファレンス・アーキテクチャーの目的は、ソリューション・アーキテクトとエンタープライズ・アーキテクトに、ビジネスに応じたソリューションを設計する際のベースとなる、標準化された青写真を提供することです。図 1 に示すように、リファレンス・アーキテクチャーは、アーキテクチャーに関する意思決定や前提は明らかであるがまだ実装されていない非常に抽象的なものから、これらの意思決定と前提のほとんどが実装されている極めて具体的なものまで、さまざまな抽象化レベルで存在します。

このさまざまな抽象化レベルには、ドメイン、業界、企業、ソリューションの各リファレンス・アーキテクチャーが存在します。以下の図全体を理解するには、http://www.opengroup.org/soa/source-book/stds/index.htm に掲載されている「Navigating the SOA Open Standards Landscape Around Architecture White Paper」を参照してください。

図 1. さまざまな抽象化レベルのリファレンス・アーキテクチャー
さまざまな抽象化レベルのリファレンス・アーキテクチャー

リファレンス・アーキテクチャーは、アーキテクチャーのコンテキストを設定するために使用することができ、それによって、製品を対応付ける対象やサービスを設計する対象をベンダーと顧客が理解するための共通基盤を提供したり、ソリューションに必要なビルディング・ブロック一式を統合したりすることができます。

SOA の場合、アーキテクトはさまざまなシナリオでリファレンス・アーキテクチャーを使用します。これらのシナリオには例えば、SOA の導入を進めている組織のための後押し、SOA を構築する際のサービスを提供しているインテグレーターへの支援、コンシューマーが理解できる標準的な方法で製品を位置づけるために SOA コンポーネントを作成している SOA 製品ベンダーへの支援、新しい SOA 仕様および標準を作成している組織への支援などが含まれます。

標準化された SOA リファレンス・アーキテクチャーの価値

SOA リファレンス・アーキテクチャーが標準化されたことで、SOA ソリューションを作成するお客様は、業界に認められた、ベンダーに依存しない出発点として、このアーキテクチャーを使用できるようになりました。しかもベンダーに中立であることから、複数の企業が提携しているような状況で使用することができ、ベンダーやシステム・インテグレーターなどの変更に影響されることはありません。SOA リファレンス・アーキテクチャーは、SOA ソリューションを設計、構築、および記述する上で共通の分類法と用語を提供するため、コストと時間の節約になるとともに、結果が改善されるはずです。

SOA を導入している組織にとっては、ビジネス・プロセス、ビジネス・ツール、メッセージ交換、サービス統合、データ・アクセスを用い、レガシー・ソフトウェアおよびコンポーネントをカプセル化したソリューションを作成する際に SOA リファレンス・アーキテクチャーが役立ちます。アーキテクトが SOA のモデル化手法および配信手法を適用すると、SOA のすべての要素が特定されて SOA ソリューションの進捗状況を示すビューを提供する SOA リファレンス・アーキテクチャーに対応付けられます。さらに、特定の企業や業界のビジネスおよび IT 利害関係者には、SOA リファレンス・アーキテクチャーが非常に有用なコミュニケーション・ツールになります。

SOA リファレンス・アーキテクチャーは、ソリューションの機能と実現可能性を定義するためにも使用されます。この場合には、SOA ソリューションの設計時に検討しなければならない主要な要素のチェックリストという形がとられます。SOA リファレンス・アーキテクチャーが定義する層、およびこれらの層に含まれるアーキテクチャー・ビルディング・ブロックが、チェックリストになるというわけです。層およびアーキテクチャー・ビルディング・ブロック内にはさらに、SOA ソリューションの定義を支援する設計意思決定点および対話パターンもあります。例えば、技術的観点から見ると、アーキテクトは次のような問題に対する答えを出さなければなりません。

  • SOA ソリューションを作成するための検討事項および基準は何か?
  • 相互接続された複数のアーキテクチャーと変換機能を備えたアーキテクチャー・フレームワークとして SOA ソリューションを編成する方法は何か?
  • アセットが最大限再利用されるように SOA ソリューションを設計する方法は何か?

以上の問題に対処するために、The Open Group の SOA リファレンス・アーキテクチャー標準は SOA ベースのソリューションのためのリファレンス・アーキテクチャーを提示しています。このリファレンス・アーキテクチャーは SOA を上位レベルで抽象化して複数の層に分解し、その各層では SOA ソリューションが有効にその役割を果たすために必要な一連の機能を提供します。これらの層は、それぞれが SOA に特有の価値提案に関連する特性および役割の一部を担っています。

この階層化アーキテクチャーの基礎となっているのは、層、機能、アーキテクチャー・ビルディング・ブロック (ABB)、対話パターン、オプション、アーキテクチャーに関する意思決定、そして機能、ABB、層の 3 つの間にある関係で構成されたメタモデルです。メタモデルを構成するこれらの要素は、アーキテクトがアーキテクチャーを作成および評価する際の指針となります。

SOA リファレンス・アーキテクチャーの使用に関する現状

サービスと SOA を導入するまでの過程で、組織がその固有のプロジェクトの目標と制約に対処しなければならないことはよくあります。多くの組織は、サービス統合の世界を探る手段として (既存のアプリケーションをラップする) Web サービスを試し、その結果から、サービス統合の初期フェーズ以降の進め方を判断しています。また、全社規模のビジネス変革に取り組む組織もあれば、ロードマップ、構想、戦略、そして評価およびガバナンスの基準を定義する組織もあります。このいずれの組織にとっても役立つのが、サービスおよび SOA の現在の成熟度を測るための客観的な基準を持つこと、そしてその要求されるレベルの成熟度に達するためのロードマップを作成することです。このロードマップは、成熟度に達することだけを目的にするのではなく、成熟度の各レベルに達するごとに異なるビジネス結果がもたらされるようなものとして作成しなければなりません。

IBM では、Web サービスのような特定の技術手法と、ソリューションおよびビジネス・アーキテクチャーとしての SOA を切り分けて認識し、それを先導してきました。数千ものお客様および政府との関わりを通じて、IBM は SOA ソリューションの開発、およびそのような SOA ソリューションを実現するための製品の提供において、世界的に認められた業界リーダーシップを確立しました。IBM はこれまで、こうしたお客様や政府との関わりを支える業界最高レベルの数々のアセットを開発してきました。これらの実証済みの主要なアセットの一部は、The Open Group がガバナンス、成熟度モデル、用語に関する最近の SOA 標準のベースとして使用しています。そして現在、The Open Group の SOA リファレンス・アーキテクチャーのベースにもなっています。The Open Group のガバナンスおよびサービス導入に関する標準において、IBM が開発にどのように貢献したか、そして現在どのようにサポートしているかについては、他に説明している記事があるので、この記事では The Open Group の SOA リファレンス・アーキテクチャー標準に対する IBM のサポートに焦点を絞ります。この SOA リファレンス・アーキテクチャー標準は現在 http://www.opengroup.org/projects/soa-ref-arch/ で公開されています。

SOA リファレンス・アーキテクチャーの概要

SOA リファレンス・アーキテクチャーは、一連の抽象要素で構成されています。これらの抽象要素のすべてが 1 つにまとまって、SOA の論理設計となります。したがって、SOA リファレンス・アーキテクチャーは「SOA とは何か」という質問に答えるためのアーキテクチャー・ビルディング・ブロック一式を提供し、個々のアーキテクチャー・ビルディング・ブロックで質問の詳細に答えます。アーキテクチャーを評価する際、あるいはソリューション・アーキテクチャーまたはエンタープライズ・アーキテクチャーを設計する際に、アーキテクトは対象とするアーキテクチャーの構成要素のチェックリストとして SOA リファレンス・アーキテクチャーの構成要素 (ビルディング・ブロックなど) を使用することができます。例えば、各層のアーキテクチャー・ビルディング・ブロックおよびブロック同士の関係、使用可能なオプション、そして各層で行わなければならない意思決定などです。これらの層は、SOA を構築するために必要な関心の分離を行うための出発点となります。分離された関心の各グループが、それぞれ独自の「層」内で表されます。

アーキテクトにとって、SOA リファレンス・アーキテクチャーの設計は、ソフトウェア開発ライフサイクルの中で使用するテンプレートとガイドラインが組み込まれた青写真となります。これらのテンプレートとガイドラインによって、アーキテクトがアーキテクチャー層、アーキテクチャー層に含まれる機能と ABB、そして層と ABB のオプションなどをモデル化および文書化した上で、製品を ABB と (SOA の作成に貢献する) アーキテクチャーおよび設計に関する意思決定に対応付ける、というプロセスは容易になり、最終的にこのプロセスは自動化および合理化されます。

SOA リファレンス・アーキテクチャーは、SOA を導入する組織、SOA インフラストラクチャー・コンポーネントを作成する製品ベンダー、SOA ソリューションの作成に取り組むインテグレーター、そして SOA の今後の仕様の開発に取り組む標準化団体をサポートするように意図されています。

図 2. SOA リファレンス・アーキテクチャーのソリューションの論理ビュー
SOA リファレンス・アーキテクチャーのソリューションの論理ビュー

SOA ポートフォリオの機能は、運用システム層とサービス・コンポーネント層で実現されます。インターフェースが公開されるのは、サービス層です。この 3 つの層 (運用システム層、サービス・コンポーネント層、サービス層) には、統合、サービス品質、情報、ガバナンスといった分野横断的な関心事があることに注意してください。これらの関心事は、上図の各層のそれぞれに検討事項として含まれています。これらの層のうちの 3 つの層 (運用システム層、サービス・コンポーネント層、およびサービス層) がサービスの実装とインターフェースに対処し、別の 3 つの層 (ビジネス・プロセス層、コンシューマー層、統合層) がサービスの使用をサポートします。そして、情報アーキテクチャー層、サービス品質層、統合層、ガバナンス層の 4 つが、よりサポート的な (非機能的または補足的とも呼ばれる) 性質を持つ分野横断的な関心事をサポートします。この SOA リファレンス・アーキテクチャー全体が、サービスとその対話をサポートするすべてのコンポーネントを含め、SOA を構成するすべての要素をサポートするためのフレームワークとなります。

図 2 の各層の中に示されているのは、アーキテクチャー・ビルディング・ブロック (ABB) です。ABB は、再利用可能な機能の基本要素を表し、それが含まれている層の主要な役割を果たします。層に常駐して機能をサポートする ABB には、それぞれに役割があります。また、ABB は他の層の ABB と相互接続して、層間を自然に関連付けます。ある特定の問題を解決するために層の間で常に特定の ABB 同士が相互接続されるとしたら、その相互接続がこれらの ABB のパターンと、ABB 間の有効な対話シーケンスを定義することになります。

各層の中には、ABB に加え、ABB がサポートする機能も含まれます。The Open Group が TOGAF 9 で定義している「機能」とは、「組織、個人、またはシステムに備わった能力」です。ABB はこの定義を拡張し、組織、個人、またはシステムがそれぞれに機能を定義して提供できるようにするための技術リソースを提供します。つまり、それぞれの ABB が、1 つまたは複数のコンポーネントや製品によって実現可能な 1 つまたは複数の機能のサポートを提供するということです。ABB の役割には、例えばサービス定義、メディエーション、ルーティングなどが挙げられます。

各層の概要

SOA リファレンス・アーキテクチャーに定義されている層は以下のとおりです。

  • 運用システム層 ― 運用および IT システム層には、設計時、デプロイ時、および実行時に SOA ソリューションをサポートするために組織に必要な新規インフラストラクチャーと既存のインフラストラクチャーの両方が取り込まれます。

    この層は、実際のランタイム・インフラストラクチャーとそのインフラストラクチャー上で実行される SOA の残りの層が交わるポイントを表します。さらに、コンテキストをクラウド・コンピューティングに広げると、この層は IaaS (Infrastructure as a Service) 構成と SOA の残りの層の統合ポイントでもあります。この層の重要な要件については、これらの要件を満たすために提供される機能を説明しているセクションに概説されています。
  • サービス・コンポーネント層 ― サービス・コンポーネント層には、ソフトウェア・コンポーネントが収容されます。これらのソフトウェア・コンポーネントのそれぞれが、サービスを実装または「実現」したり、サービスを操作したりします。この層には、サービス・コンポーネントが 1 つ以上のサービスを実現できるようにする機能コンポーネントと技術コンポーネントも含まれます。サービス・コンポーネントは、それぞれが表すサービスの定義を、その機能とサービス相互作用の管理および品質の両方に反映します。これらのサービス・コンポーネントは、サービス契約を運用および IT システム層のサービス実装にバインドします。サービス・コンポーネントは、サービス仕様をサポートするコンテナー内でホストされます。

    サービス・コンポーネント層は、カプセル化という手段、そして疎結合を可能にすることによって、IT に柔軟性をもたらします。コンシューマーはサービスがその公開された記述 (サービス・コンプライアンス) に従って忠実に実現されることを想定し、プロバイダーはサービス・コンプライアンスが確実に実現されるようにする、という形で関心の分離は行われます。サービスを実現する方法の詳細は、コンシューマーにとって重要ではありません。したがって、プロバイダー組織はサービス・コンシューマーに影響を及ぼすことなく、同じサービス・コンプライアンスに従って、あるコンポーネントを別のコンポーネントに置き換えることができます。
  • サービス層 ― サービス層を構成するのは、SOA 内に定義されたすべての論理サービスです。この層には、設計時に使用/作成されるサービス、ビジネス機能、IT 表明に関する記述と、実行時に使用されるサービス契約およびサービス記述が含まれます。

    サービス層は、SOA でサポートされるビジネス機能を提供する水平層の 1 つであり、SOA のサービス機能を記述します。
  • ビジネス・プロセス層 ― ビジネス・プロセス層は、疎結合サービスをビジネス目標に合わせて順序付けられたプロセスとして集約するためのプロセス表現、構成方法、およびビルティング・ブロックが含まれる層です。サービスとビジネス・プロセスとの間のやりとりを可能にするためには、データ・フローと制御フローが使用されます。このやりとりは、企業内で行われることも、複数の企業間にわたって行われることもあります。

    SOA リファレンス・アーキテクチャーのビジネス・プロセス層は、統合層、サービス品質層、情報アーキテクチャー層、およびサービス層と連携してビジネス・レベルの要件と IT レベルのソリューション・コンポーネントを関連付ける際に、中心的な調整役としての役割を果たします。
  • コンシューマー層 ― コンシューマー層は、個人、プログラム、ブラウザー、オートメーションのどれであるかに関係なく、コンシューマーが SOA と対話する場所です。この層により、SOA ソリューションは、クライアントにもチャネルにも依存しない一連の機能をサポートすることが可能になります。これらの機能は 1 つ以上のチャネル (クライアント・プラットフォームおよびデバイス) を使用して個々に使用およびレンダリングされます。したがって、内外のコンシューマー (人間および他のアプリケーション/システム) およびサービス (例えば B2B のシナリオなど) のすべてにとって、コンシューマー層は SOA と対話する上でのエントリー・ポイントとなります。

    コンシューマー層は、市場の変化に応じてビジネス・プロセスおよび複合アプリケーションのフロント・エンドを素早く作成する機能を提供します。そして、さまざまなアプリケーションとプラットフォームでサポートされるビジネス・プロセスに対し、チャネルに依存せずにアクセスできるようにします。コンシューマーと SOA の残りの部分とがこのように分離されることにより、組織にはアジリティー、再利用の促進、そして品質と一貫性の改善がもたらされます。
  • 統合層 ― 統合層は、メディエーション機能を有効にして提供するという横断的な関心層であり、サービス・リクエストをリクエスト側から適切なサービス・プロバイダーへと転送するための変換、ルーティング、プロトコル変換が含まれています。この層は、ルーティング、プロトコルのサポートと変換、メッセージング/対話スタイル、異機種環境のサポート、アダプター、サービス対話、サービス有効化、サービス仮想化、サービス・メッセージング、サービス処理および変換を含め、SOA を有効にするために必要な機能をサポートします。疎結合システムの下でソリューションの一貫性を維持するのも、統合層の役割です。

    この層では、主にサービス・コンポーネント層、サービス層、およびプロセス層 (つまり、「機能」層) の統合が行われます。例えば、プロセスを実行する際にサービスのバインディング (遅延バインディング、または別の方法でのバインディング) が行われるのは、この統合層です。これにより、複数の顧客対応チャネルで一貫したサービスを公開することが可能になります。
  • サービス品質層 ― サービス品質層は、非機能要件 (NFR) に関連する SOA の関心事をサポートする横断的な関心層であり、あらゆるソリューションで NFR 関連の関心事に対処する中心となります。この層は、監視、信頼性、可用性、管理容易性、トランザクション性、保全性、スケーラビリティー、セキュリティー、安全性、ライフサイクルなどに関する要件を SOA が満たすことを確実にする手段を提供します。サービス品質層のスコープは、従来の ITIL による FCAPS (Fault, Configuration, Accounting, Performance, Security) や RAS (Reliability, Availability, Serviceability) と同じです。サービスと SOA ソリューションを管理するには、現在ビジネスに適用されているのと同じ種類の管理および監視が重要になります。また、場合によっては多くの SOA ソリューションに伴うサービス指向の性質やドメイン境界をまたがる問題に対処するために拡張しなければならないこともあります。
  • 情報アーキテクチャー層 ― 情報アーキテクチャー層は横断的な関心層であり、組織の情報という側面において、ビジネスのニーズとプロセスを実現するための IT サービス、アプリケーション、システムなどから提供される情報を、ビジネス語彙 (用語集と用語) に従った情報の統一表現として明示する役割を担います。

    この層には情報アーキテクチャー、ビジネス・アナリティクス、ビジネス・インテリジェンス、メタデータなどに関する検討事項が含まれており、データマートやデータウェアハウスからビジネス・アナリティクスとビジネス・インテリジェンスを作成するためのベースとして使用することもできる情報アーキテクチャーについて、関連する重要な検討事項が確実に見落とされることがないようになっています。検討事項には、この層に保管されたメタ・データ・コンテンツも含まれます。さらにこの層は、情報サービス機能にも対応しており、仮想化された情報データ層機能を可能にします。これにより、SOA はデータの一貫性、そしてデータ品質の一貫性をサポートできるようになります。
  • ガバナンス層 ― ガバナンス層は、組織内のサービスと SOA ソリューションが、目標、戦略、そして組織に適用される法規制に応じて定義された規定のポリシー、ガイドライン、標準に準拠していること、そして SOA ソリューションが目的とするビジネス価値を提供していることを確実にするという横断的な関心層です。SOA ガバナンスのアクティビティーは、企業、IT、およびエンタープライズ・アーキテクチャーのガバナンス原則および標準に準拠しなければなりません。ガバナンス層は、組織が目標とする SOA 成熟度レベルに応じて、それに適応するように変更されてその成熟度レベルをサポートします。

サービスのタイプ

サービスがあらゆるサービス指向アーキテクチャーにおける中心的な概念であるのは当然ですが、サービスには多種多様なカテゴリーが考えられることを認識しておくことが重要です。SOA リファレンス・アーキテクチャーでは、サービスの標準カテゴリー化スキームを定義しています。このスキームでは、すべてのサービスを網羅して、共通の認識を持てるようにするために、サービスはその実行内容、すなわち機能または目的によってカテゴリー化されます (ただし、カテゴリーは重複しないわけではありません)。もちろん、これ以外のカテゴリー化スキームも可能であり、役に立ちます。

サービス指向アーキテクチャーでサービスおよびサービス・ポートフォリオを開発する場合、サービスをグループに分けるのは一般的な作業です。サービスのカテゴリーおよびグループは、ビジネスと IT の両方にとって、アーキテクチャーとそのアーキテクチャーをサポートするサービス・ポートフォリオの見解および理解に影響を及ぼします。

以下の図に、標準的な企業に見られるサービスの機能を基準としたカテゴリー化スキームを示します。

図 3. サービスのタイプ
サービスのタイプ

図 3 では、サービスがカテゴリーに分けられています。「サービス統合サービス (Service Integration Services)」に結び付けられているサービス (対話サービス (Interaction Services)、プロセス・サービス (Process Services)、情報サービス (Information Services) など) は、ドメイン固有のサービスと見なされます。これらのサービスはソリューションに固有であり、そのドメインまたは開発対象のソリューションに特有の実装が必要となります。ドメイン固有のサービスは購入することもできますが、その場合には通常、大々的なカスタマイズあるいは拡張を行わなければなりません。

残りのサービス・カテゴリーは、ドメインに依存しないサービスと見なされます。これらのドメイン非依存カテゴリーには、開発サービス、管理サービスなどがあります。このカテゴリーのサービスは、さまざまなドメインやソリューションでそのまま使用することができます。一般に、ドメインに依存しないサービスは、ソリューションに含まれるドメインに固有のサービスを計画、開発、サポート、および管理するために使用されます。多くの場合、ドメインに依存しないサービスは購入するとしても大幅にカスタマイズすることなく使用することができます。

対話サービス、プロセス・サービス、および情報サービスの各カテゴリーは、モデル・ビュー・コントローラー・パターンをサポートすることに注意してください。従来のアーキテクチャー・ビューでモデル、ビュー、コントローラーの側面を分離することによってもたらされる価値は、SOA の場合にも同じく当てはまります。

以下に、サービスの各カテゴリーについて説明します。

  • メディエーション・サービス ― サービス・コンシューマーをサービス・プロバイダーにバインドします。透過的にロケーションを解決して、ネットワーク全体でリクエストの最適なルーティングを実現します。通常、メディエーションは接続性に加え、ロギングや変換などの有用なアクティビティーを行うことによって付加価値をもたらします。
  • 対話サービス ― ビジネス設計のプレゼンテーション・ロジックを提供し、アプリケーションとエンド・ユーザーとの対話をサポートします。
  • プロセス・サービス ― ビジネス・プロセス・フローをはじめ、さまざまな形態の構成ロジックが含まれます。
  • 情報サービス ― ビジネス設計のデータ・ロジックを提供します。情報サービスの実装は、ビジネスの永続データへのアクセス、ビジネスのデータ合成をサポートするとともに、組織全体でのデータ・フローを管理するための独自のサブアーキテクチャーを提供します。
  • アクセス・サービス ― レガシー・アプリケーションおよび機能をサービス指向アーキテクチャー・ソリューションに統合します。
  • セキュリティー・サービス ― SOA の脆弱な側面を脅威から保護します。セキュリティー・サービスの役割は、サービス・コンシューマーとサービス・プロバイダーの間の対話を保護するとともに、アーキテクチャーに貢献するすべての要素を保護することです。
  • パートナー・サービス ― ビジネス設計で直接表現されるパートナー相互運用性のセマンティクスを取り込みます。
  • ライフサイクル・サービス ― 戦略からインフラストラクチャーに至るまでの開発および管理において、SOA ソリューションおよび SOA ソリューションを構成するすべての要素のライフサイクルの管理をサポートします。
  • アセットおよびレジストリー・サービス ― アーキテクチャーの一部となっているアセットへのアクセスを提供します。これにはサービス記述、ソフトウェア・サービス、ポリシー、ドキュメントなど、ビジネスの運用に不可欠なアセットや成果物が含まれます。
  • インフラストラクチャー・サービス ― リソースの効率的な使用、運用環境の保全性の確保、サービス・レベルの目標に合わせたワークロード・バランシング、作業の分離による干渉の回避、保守の実行、機密性の高いビジネス・プロセスとデータへのセキュア・アクセス、そして全体的なシステム管理のすべてを単純化します。
  • 管理サービス ― サービス・フロー、システムの正常性、リソースの使用状況、故障とボトルネックの特定、サービス目標の達成状況、管理ポリシーの実施状況、および障害からの復旧状況などを監視するために使用する一連の管理ツールと測定基準を提供します。
  • 開発サービス ― SOA ソリューションを組み立てるために必要なアーキテクチャー・ツール、モデリング・ツール、開発ツール、ビジュアル構成ツール、アセンブリー・ツール、手順、デバッグ支援、インスツルメンテーション・ツール、およびディスカバリー・エージェントをすべてサポートします。
  • 戦略および計画サービス ― ビジネス結果を改善するための構想、青写真、遷移計画の作成をサポートするとともに、ビジネス戦略を処理してビジネスと IT の両方を網羅した実装ロードマップを作成するためのサービスをサポートします。
  • ビジネス・アプリケーション・サービス ― コア・ビジネス・ロジックを実装します。このロジックで、ビジネス・モデル内に具体的に実装が作成されます。
  • ビジネス・サービス ― ビジネス機能を取り込むサービスです。これらのサービスは、外部コンシューマーに対して粒度の大きなサービスとして提示されます。

包括的なスコープと詳細を提供する SOA リファレンス・アーキテクチャーにより、アーキテクトはサービスおよびソリューションのビルディング・ブロックについて考える際に、何も見落としがないことを確信することができます。広範な実際のプロジェクトの経験に基づき、IBM は他に類を見ないほどの万全の態勢で、SOA とこの SOA リファレンス・アーキテクチャー標準をサポートするために必要な幅広い経験および製品を提供します。

IBM による SOA リファレンス・アーキテクチャー標準のサポート状況

サービス製品

IBM は、十分にテストされた包括的なサービス・オファリング一式を用意しているだけでなく、お客様の SOA 導入を支援してきた経験から、SOA の市場リーダーとしての地位を確立しています。

SOA への移行はすでに開始しているけれども、その進め方を評価したいという場合があります。例えば、パフォーマンスに問題があるため、設計、インフラストラクチャー、あるいは実装を評価したいという場合や、SOA ソリューションをサイジングしたり、ピーク負荷時でもソリューションが確実に機能するようにしたりするための支援が必要という場合です。IBM のサービスは計画を評価して改善案を提示することによって、さらに大きなビジネス価値をもたらします。SOA 診断 (SOA Diagnostic) では全体的な SOA 戦略、ガバナンス (セキュリティーを含む)、インフラストラクチャーの整備状況、および進行中の SOA 開発プロジェクトを調べます。さらに IBM はキャパシティーとパフォーマンスの評価にも注目し、SOA がすべてのビジネス要件および IT 要件を満たすことができることを確認します。

The Open Group の SOA リファレンス・アーキテクチャー標準がベースとしているのは、IBM の SOA ソリューション・スタックおよび SOMA (Service Oriented Modeling and Architecture) です。前者は、前述のサービスに含まれる主要なアセットであり、後者はそれぞれのソリューションに適したサービスを特定するための、世界的に有名な IBM の手法です。

現在、IBM はこの広範な経験を生かし、お客様の組織のクラウド・ソリューションに SOA を適用しています。詳しくは、http://www-935.ibm.com/services/us/index.wss/offerfamily/gbs/a1028751 を参照してください。

ソフトウェア製品

IBM はお客様に適した SOA ソリューションの実装を可能にする、業界で最も広範囲な製品ラインナップを取り揃えています。IBM 製品を使用することで、お客様のソリューションのロードマップのすべてのステップにおいて、SOA の適切なツールおよびインフラストラクチャーをアーキテクチャーのすべての層で提供することができます。しかも、ライフサイクルのすべてのステージ (計画、開発、展開、管理) で可能です。IBM では、SOA 実装の側面を説明するためのアーキテクチャー・リファレンス・モデルとして、以下のダイアグラムを使用しています。

IBM の製品とサービスは、SOA リファレンス・アーキテクチャーが標準化している共通のサービス・タイプに対応付けることもできます。

図 4. IBM ソフトウェア製品の対応付け、パート 1
IBM ソフトウェア製品の対応付け
図 5. IBM ソフトウェア製品の対応付け、パート 2
IBM ソフトウェア製品の対応付け

SOA ソリューションのモデル/アセンブル/展開/管理というライフサイクルの各フェーズをサポートする IBM ブランドには以下に挙げるものがあります。

  • Rational: SOA ソリューションおよびビジネス・プロセスをモデル化するためのツールによって、モデル・フェーズおよびアセンブル・フェーズをサポートします。また、開発サービスをサポートする製品も提供しています。
  • WebSphere: サービス実装、サービス・クライアント、そしてビジネス・プロセスのランタイムを提供することによって展開フェーズをサポートします。また、SOA ソリューションを展開するために必要な運用サービスをサポートする製品も提供しています。
  • Tivoli: サービス、ソリューション、インフラストラクチャーの監視および運用管理を行えるようにすることで、管理フェーズをサポートします。また、管理サービスをサポートする製品も提供しています。
  • Lotus: ビジネス・プロセスにコミュニケーションおよびコラボレーションを統合するためのツールを提供し、対話サービスをサポートします。上記に示した IBM SOA リファレンス・アーキテクチャーには、SOA の各側面で使用できる多種多様な IBM 製品が記載されています。
  • Information Management: 情報サプライ・チェーン全体にわたる情報管理サービスを提供することによって展開フェーズをサポートします。

IBM 製品は、SOA リファレンス・アーキテクチャーを構成する層とサービスの両方に対してサポートを提供します。

  • 戦略および計画サービスは、Global Business Service の CBM (Component Business Modeling) サービスによって提供されます。CBM は、ビジネスを系統的に検討し、適切なビジネス・コンポーネントとサービスのセットを特定するのに役立ちます。ニーズに応じた適切なサービスを特定するには、SOMA (Service Oriented Modeling and Architecture) のサービスとツールを利用することができます。このサービス特定プロセスを促進するのが、SOMA 用の RUP (Rational Unified Process) が提供するベスト・プラクティス・オファリングです。このオファリングは、レガシー・システムを刷新する場合には特に効果的です。さらに、IBM Rational ではエンタープライズ・アーキテクト向けツールとして Rational Systems Architect および Rational Focal Point を販売しています。この 2 つの製品は、市場主導型の製品およびポートフォリオ管理のための意思決定支援システムです。Rational RequisitePro が、サービス開発ライフサイクルにおける目標とステップに応じてビジネス要件を追跡します。
  • ビジネス・サービスおよびビジネス・イベントは、ビジネス・アナリストが文書化、コンプライアンス、シミュレーション、最適化を目的にビジネス設計を取り込む際に役立ちます。WebSphere Business Monitor では、ダッシュボードを作成してビジネスのパフォーマンスを視覚化できるため、ビジネス設計がビジネス目標をどれだけ満たしているかを把握することができます。さらに、最適化の案を推奨してくれたりもします。Cognos Business Intelligence には、SOA に関するビジネス・レポート作成機能、分析機能、ダッシュボードが用意されています。WebSphere Operational Decision Management は、イベントによって主導されるビジネス状況に関する洞察と認識をもたらすことにより、BPM および SOA インフラストラクチャーを強化します。
  • 開発サービスは、Rational の Rational Software Architect が提供します。この製品は、Windows、Linux、i System、z System でビジネス・サービスを開発するための環境となります。さらに、Rational Team Concert によって、これらの環境でのコラボレーティブな開発が可能になります。Rational ClearCase および ClearQuest は開発プロセスを自動化して実施することで、ソフトウェア開発ライフサイクルの洞察力、予測可能性、管理、および制御を強化します。そして、この製品を補完する IBM Integration Designer が、ビジネス・プロセス・フロー、状態マシン、ビジネス・ルールの作成を支援します。
  • アセット・サービスやレジストリー・サービスを提供する Rational Asset Manager は、SOA ソリューションのアセットを含め、あらゆるタイプの開発アセットの作成、変更、管理、検索、再利用などに使用することができます。WebSphere Service Registry and Repository は、サービスの登録および検索用のツールによって、サービスとの遅延バインディングをサポートします。
  • サービス統合サービスは、本質的にはエンタープライズ・サービス・バス (ESB) 機能であり、WebSphere Enterprise Service Bus によってサポートされます。この製品は、エンタープライズ分散ネットワーク全体でサービスを透過的に相互接続するための基礎構造となります。WebSphere Enterprise Service Bus を拡張し、XML 以外のデータ型のメッセージの変換とメッセージ・ベースの統合に対応できるようにするのが、WebSphere Message Broker です。WebSphere Message Queue は、さまざまなプラットフォーム間でのスケーラブルで信頼性の高い情報交換を可能にします。WebSphere DataPower SOA アプライアンスは、SOA アプリケーションを増強し、処理スピードを向上させます。特に、IBM WebSphere DataPower Integration Appliance XI52WebSphere DataPower XML Accelerator XA35 Appliance はそれぞれ、Web サービス処理の負荷、XML 処理の負荷を取り除きます。
  • ビジネス・アプリケーション・サービスは、WebSphere Application Server でホストされます。この製品は、基本的な SOA ビジネス・サービスのための可用性に優れたホスト環境であり、WebSphere PortalIBM BPM (Business Process Management)、および WebSphere ESB のプラットフォームとなります。ここでは SOA、SCA、SIP、Web 2.0、および JPA の標準ベースのプログラミング・モデルがサポートされます。WebSphere Application Server を規模の面で増強するのが、WebSphere XD (eXtended Deployment) です。また、WebSphere Network Deployment は一般的なハイエンドのコンピューティング要件に対応するようにプログラミング・モデルを拡張します。WebSphere eXtended Deployment Compute Grid は、複数のトランザクションおよびバッチ・パラダイムの間でビジネス・ロジックを共有できるようにします。WebSphere eXtreme Scale は、柔軟なスケーラビリティーと次世代の SOA およびクラウド環境に不可欠な分散キャッシングを実現します。ビジネス・アプリケーションを実現するための高性能のデータ管理システムには、アプリケーション・サーバー兼トランザクション・サーバーである CICS、そして階層型トランザクション・データベース管理システムの IMS があります。CICSIMS はいずれも、SOA 開発に対応するようになっています。
  • プロセス・サービスは、IBM Business Process Management によって完全にサポートされます。IBM Business Process Management は、ビジネス・プロセス処理 (プロセス・フローとビジネス状態マシンの両方) のための主要なホスト環境です。WebSphere Operational and Decision Management は、ビジネス・ポリシーおよびビジネス・プロセスを制御し、管理するためのビジネス・ルール管理システムを実現します。またビジネスが、実行可能なイベント・パターンのディスカバリーを基にビジネス・イベントの影響を検出し、評価し、対応するには、WebSphere Business Events を使用することができます。
  • 対話サービスをサポートする WebSphere Portal は、SOA アプリケーションのユーザー対話ロジックのホスト環境であり、インターフェースを 1 つのユーザー・ページに集約することができます。統合通信プラットフォームである Lotus Sametime は、ビジネス・プロセスでのサービスの呼び出しと人の関与を可能にします。そして IBM Mashup Center により、動的な状況依存型アプリケーションを使ってユーザーをビジネス・サービスに接続できるようになります。
  • 情報サービスは、データウェアハウスおよび情報統合製品によって提供されます。InfoSphere Master Data Management は顧客、製品、アカウントの各ドメイン内にあるビジネスに不可欠なマスター・データを一元管理する一方、IBM Information Server は散在する異種混合の複合的な情報を統合するためのデータ・プラットフォームです。Cognos Business Integrator により、あらゆるデータを、あらゆる組み合わせで全期間に渡って探索し、対話することが可能になります。
  • パートナー・サービスは、Sterling B2B Integration および WebSphere DataPower Appliance によってサポートされます。WebSphere DataPower Appliance は、取引先およびトラザクション管理用に 1 つに統合されたプラットフォームでプロセスとデータを統合することにより、取引先との B2B 統合を可能にします。
  • アクセス・サービスは、多種多様なレガシー情報システムへのアダプターを提供する WebSphere Adapters によってサポートされます。
  • インフラストラクチャー・サービスは、WebSphere Virtual Enterprise がサポートします。この製品では、アプリケーションの仮想化により、コストの削減と、柔軟性、アジリティー、可用性、信頼性の向上が実現されます。IBM や他のベンダーのミドルウェアおよびハードウェアの使用を管理するのは仮想化ソフトウェアです。IBM は、AIX または Linux を稼働する最先端の Power Systems や、スケーラビリティーと管理容易性を組み込んだ BladeCenter 統合プラットフォームをはじめ、ビジネス向けのシステム、サーバー、ストレージの信頼できるプロバイダーとなっています。IBM の擁する System z シリーズの類まれな処理能力および高可用性は周知のとおりです。
  • 管理サービスには、セキュリティーとランタイム管理の両方が含まれます。セキュリティーを提供するのは、Tivoli Identity Manager、Tivoli Federated Identity Manager、Tivoli Security Policy Manager です。Tivoli Access Manager は、ユーザーの管理、ユーザー情報のフェデレーション、そして特権管理を一元化します。Tivoli Compliance Insight Manager は、セキュリティー・コンプライアンスを目的にユーザーの挙動を自動的に監視します。そして WebSphere DataPower XML Security Gateway XS40 および XG45 が、Tivoli の統合された ID、セキュリティー、ディレクトリー・サービスを SOA ネットワーク処理に統合します。監視、プロビジョニング、自動化をサポートするのは、統合製品セット (ITCAM for SOA を含む) として SOA リファレンス・アーキテクチャーのすべての層での IT サービス管理を可能にする Tivoli Composite Application Manager (ITCAM)、運用管理のワークフローの管理と自動化や、情報システムでのイベントに応じたワークフローの開始などをサポートする Tivoli Intelligent Orchestrator (TIO)、そしてハードウェアとソフトウェアのプロビジョニング用デプロイメント環境を自動化するためのワークフローによってこの TIO を拡張する Tivoli Provisioning Manager です。Tivoli Change and Configuration Management DataBase (CCMDB) が ITIL によって記述されている変更および構成の管理プロセスを自動化してサポートする基盤となり、Tivoli Application Dependency Discovery (TADDM) が自動ディスカバリーおよび構成追跡機能を提供してアプリケーション・マップを作成することによって、アプリケーションの複雑な部分をリアルタイムで視覚化することができます。そして、Tivoli Usage and Accounting Manager が共有計算リソースの使用状況およびコストを評価します。Tivoli Business Service Manager (TBSM) はリアルタイムのサービス可用性を視覚化し、さまざまな情報をダッシュボードで提供するとともに、重要なビジネス・サービスおよび関連するサービス・レベル・アグリーメント (SLA) の正常性を視覚化します。IBM Systems Director は、マルチシステム環境全体で物理システムと仮想システムのプラットフォーム管理を行い、仮想化を単純なものにします。ライフサイクル・サービスは、Rational Method Composer によってサポートされます。この柔軟なソフトウェア開発プロセス・プラットフォームに用意されたベスト・プラクティス・ライブラリーを利用すれば、カスタマイズされていながらも一貫性のあるプロセス・ガイダンスをプロジェクト・チームに提供することができます。Rational Requirements Composer は、コラボレーティブな環境でビジネス目標および要件の詳細をグラフィカルな方法および文字ベースの方法で表示します。Rational Build Forge は、ビルドとリリースのプロセスを自動化し、作業に要する時間を短縮します。

SOA が構築するクラウドの基盤

The Open Group によって標準化された SOA リファレンス・アーキテクチャーは、クラウド・アーキテクチャーに適用されます。この SOA リファレンス・アーキテクチャーを基本アーキテクチャーとする IBM Cloud Computing Reference Architecture は、The Open Group に提出されました (IBM CCRA)。このセクションでは、クラウド・アーキテクチャーではどこに新たな検討事項があるのかを説明し、これらの検討事項が SOA リファレンス・アーキテクチャーによってどのようにサポートされるのかを明らかにします。

機能に関する関心事としては、運用システム、サービス・コンポーネント、サービス、ビジネス・プロセス、そしてコンシューマー・インターフェースなどがあります。これらはすべてクラウドの中に存在するため、クラウドに関係してきます。

図 6. クラウドの基本アーキテクチャー
クラウドの基本アーキテクチャー

クラウドのアーキテクチャーでは、特に以下の層に注意が必要です。

  • 運用層: インフラストラクチャーは運用システム層の一部ですが、クラウド・アーキテクチャーでは特にインフラストラクチャーに焦点が当てられます。それは、クラウドは広範なネットワーク・アクセス、リソース・プール、迅速な変更、仮想化、スケーラビリティーを可能にするために、インフラストラクチャーに新しい要件を課すためです。
  • サービス層: クラウド・サービスの一般的なタイプである *aaS は、サービス層に位置します。これらのクラウド・サービス・タイプは他のサービスと同じく、運用システム層のアセットを使用し、場合によってはこれらのアセットを公開します。クラウド・サービスで公開されるアセットのタイプは、多くの場合、サービス・タイプが焦点とするものです。つまり、運用システム内のハードウェア・インフラストラクチャーは IaaS として、ミドルウェアは PaaS として、そしてビジネス・プロセスは BPaaS (Business Process as a Service) として公開されます。
  • ビジネス・プロセス層: ビジネス・プロセス層は、SOA ソリューションの場合とほとんど同じようにクラウド・ソリューションに関与します。ビジネス・プロセスはサービスとして提供される (BPaaS) ことも、サービスのコンシューマーとなることもあります。さらに、クラウド・プロバイダー組織内のビジネス・プロセスは、提供するまでの時間を大幅に短縮するという目標、変更にかかる時間を大幅に短縮するという目標、そしてコストに関する目標などを達成できるように、斬新な方法で再構築して効率化する必要があります。
  • コンシューマー層: コンシューマー層は、サービスおよびサービス・プロバイダーから、より厳格かつ慎重に分離されます。これは、クラウド・サービスやクラウド・プロバイダーのプールおよび置き換えを可能にするためです。

SOA リファレンス・アーキテクチャーにおける横断的な関心事には、統合、サービス品質、情報、そしてガバナンスがあります。これらの関心事は、SOA での場合と同じく、すべてのクラウド・アーキテクチャーおよびソリューションにとって重要な関心事です。横断的な関心事であるということは、機能層のそれぞれが、層の境界を越えて別の層の機能と対話する可能性があることを意味します。

クラウド・アーキテクチャーでは、特に以下の点が重要になってきます。

  • サービス品質 (QoS) 層: クラウドの場合、サービス品質という横断的な関心事には、管理とセキュリティーに関する重要な要件が追加されます。それは、オンデマンド・セルフサービス要件と測定されるサービス要件だけでなく、レジリエンシー、セキュリティー、パフォーマンス、自動管理、運用およびビジネス・サポートに関する顧客からの非常に重要な要求を満たすためです。管理サポートは、SOA リファレンス・アーキテクチャーの QoS 層で Common Cloud Management Platform として表すことが可能です。この層には、運用サポート・サービス (OSS) およびビジネス・サポート・サービス (BSS) が組み込まれます。同じ基盤をベースに多くのクラウド・サービスを提供することによってスケール・メリットを活かすには、これらのサポートが不可欠です。
  • ガバナンス層: クラウド・ソリューションのガバナンスには、組織境界を超えたガバナンスをサポートするために必要な独特の要件パターンがあります。多くの場合、プロバイダーとコンシューマーは、クラウド・ソリューションとサービスが適切に提供された上で、ビジネス要件と調整され続けるようにガバナンスの反復プロセスを実行する方法について、交渉する必要があります。

クラウド・エコシステムに関しては、クラウド・アーキテクチャーに共通して見られる大まかな役割として、クラウド・サービスのコンシューマー、プロバイダー、そして作成者があります。

重要なのは、クラウドを SOA のコンテキストで検討すること、そしてクラウド・ソリューションを、それを支えるより大きな SOA ソリューションのコンテキストで検討することです。

統合と情報に関する横断的な関心事も重要であることに変わりなく、クラウド・ソリューション・アーキテクチャーを開発する際に考慮する必要があります。ただし、クラウドが、これらの横断的な層に新たな原則や関心事をもたらすことはありません。

SOA の関心事ではなく、クラウドの関心事に焦点を当てやすくするために、図 7 に示すように、クラウドの関心事を固有のダイアグラムにあらわすことができます。

図 7. IBM のクラウド・コンピューティング・リファレンス・アーキテクチャー
IBM のクラウド・コンピューティング・リファレンス・アーキテクチャー

上記の CCRA に示されている以外にも、SOA リファレンス・アーキテクチャーから引き継いだ概念とアーキテクチャー要素が存在します。

まとめ: SOA ソリューションを構築するのに IBM が適任である理由

最近の Gartner の記事 (「Application and Integration Platforms Key Initiative Overview」(2011年 7月 22日)) では、クライアントに「SOA をアーキテクチャーの前提条件とする」ようにアドバイスしています。

IBM はこの 7 年以上、SOA 市場のシェアのトップを占めていると認識されています。Wintergreen が最近公開した SOA ソフトウェア市場のシェアおよび予測に関する記事では、IBM がこの市場の 78% を占め、IBM に次ぐ競合企業でも、その市場占有率はわずか 4 % であると述べています。

IBM は以下の点で優位に立っています。

  • 8000 以上の顧客からなる最大の顧客ベースと、ibm.com で紹介されている 100 件を超える成功事例
  • 7400 以上のビジネス・パートナーを含む、最強のエコシステム
  • 業界最高レベルの専門知識と SOA ビジネス・カタログに記載された 13,000 を超えるアセットでの投資、そして極めて奥の深い広範なソリューション・ポートフォリオおよびサービス
  • Forrester SOA Wave および Gartner SOA Magic Quadrant の評価で連続して選ばれているリーダーとしての位置付け

重要な点は、IBM の SOA 戦略は、相互運用性と標準化を目的に、オープン・スタンダードをベースとしていることです。SOA リファレンス・アーキテクチャー、SOA オントロジー、OSIMM、そして SOA ガバナンス・フレームワークの標準化に関して、The Open Group において IBM が発揮しているリーダーシップは、SOA アーキテクト向けの各標準に IBM が深く関与している証拠です。

参考文献

学ぶために

製品や技術を入手するために

  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

コメント

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=799825
ArticleTitle=SOA リファレンス・アーキテクチャー標準に対する IBM のアドバンテージ
publish-date=03082012