サービス指向のモデリングおよびアーキテクチャー

ここでは、サービス指向モデリング/アーキテクチャーの特長や、サービス指向アーキテクチャー(SOA)を構築するための分析と設計に必要な主要アクティビティーについて説明します。また、ここでは各種サービスとそれらのフローおよび構成の識別、仕様決定、実現に必要なテクニックに対応することの重要性と、SOA必須サービスの品質を実現および保証するのに必要なエンタープライズ規模のコンポーネントを中心に説明します。

Ali Arsanjani, Ph.D. (arsanjan@us.ibm.com), Chief Architect, IBM 

Ali Arsanjaniは、IBMグローバルサービスのSOAおよびWebサービスセンターのチーフ設計者であり、シニアテクニカルスタッフメンバーです。IT業界、特に大規模システム向けの分散型ソフトウェアアーキテクチャーの設計と開発においては、21年の経験があります。彼のリサーチ分野と出版物には、ソフトウェア設計パターン、ソフトウェアアーキテクチャー、コンポーネントベースおよびサービス指向のアーキテクチャー、文法指向のオブジェクト設計などがあります。現在は、動的に再構成可能なソフトウェアシステムの構築を専門としています。著者へのお問い合わせは、arsanjan@us.ibm.comまでお寄せください。



2004年 11月 09日

はじめに

サービス指向アーキテクチャー(SOA)と、WebサービスとしてのSOAの実装によって提供される機会については、さまざまな風説や誇大宣伝が存在しています(中には事実に基づくものもあれば、それほど根拠のないものもあります)。アナリストが予測し、専門家が公言し、大学教授が講義するように、企業も自社製品をSOA製品として販売するよう急いでいますが、SOAが製品ではない点が見逃されていることも少なくありません。SOAは、一連の設計原理、パターン、テクニックを使ってビジネスに合わせて調整されたITサービス群によって、ビジネスとITの間のギャップを埋めるためのものです。

ZDNetでは最近、「Gartnerは2008年までに企業の60%以上がミッションクリティカルなアプリケーションやプロセスを作成する際の「ガイド的な原理」としてSOAを利用するようになるだろうと予測している」と発表しました。

SOAの開発と実装には大きな需要があります。SOAが単に、Webサービスなどによる実現を支援する製品や規格に関するものでないとすれば、SOAを実現するにはさらにどのような要素が必要なのでしょうか? サービス指向モデリングには、従来のオブジェクト指向分析/設計(OOAD)にはない、新たなアクティビティーやアーティファクトが必要です。「Elements of Service-oriented Analysis and Design」では、OOADよりも必要とされる基本的な理由と、ビジネスプロセス管理またはエンタープライズアーキテクチャー(EA)とOOADでは、分析と設計の実行手段としては不十分である旨を説明しています。また、IBM Redbook「Patterns: Service-Oriented Architecture and Web Services」では、このサービス指向モデリングアプローチの主なアクティビティーについても解説しています。

ただし、他にも考慮すべき重要事項があります。第1に、現在のOOADメソッドはSOAの3つの主要要素(サービス、フロー、サービスを実現するコンポーネント)に対応していないことです。また、サービスとそのフローおよび構成の識別、仕様決定、実現に必要なテクニックとプロセスのほか、必須サービスの品質を実現および保証するために必要なエンタープライズ規模のコンポーネントにも明示的に対応できなければなりません。

第2に、SOAの2つの主な役割であるサービスプロバイダーとサービスコンシューマーという異なる要件を尊重するためには、パラダイムシフトが必要となります。第3に、ある企業またはビジネスライン向けに構築すべきと思われるアプリケーションは、サプライチェーン内で使われ、新しいアプリケーションの構成、組み合わせ、カプセル化を計るビジネスパートナーに提示する必要があります。これはサービスエコシステムやサービスバリューネットの考え方です。

これは、単なる「分散型オブジェクト」から多少発展したものであり、ネットワーク化の効果により生み出される価値にかかわるものです。たとえば、Amazon.comとGoogle検索サービスの組み合わせを活用し、それらをさらにeBayサービスと組み合わせて独自のハイブリッドソリューションを構築する例や、旅行代理店が飛行機の予約システムに深いレベルまでアクセスし、レンタカー業者やホテルチェーンと連携して、それらの記録を更新し、旅行ルートに関する情報を顧客の電子手帳に送信する例などが考えられます。アプリケーションが何であれ、SOAを正しく作成するには、単なる便利なツールや規格以上のものが必要となります。SOAのライフサイクル(サービス、フロー、コンポーネントを分析、設計、実現するためのテクニック)をサポートする規範的なステップも必要です。したがって、エンタープライズアプリケーション開発に興味のある人にとっては、サービス指向モデリング/アーキテクチャーにかかわる詳しいステップを理解することが重要となります。

これらのステップの詳しい説明の前に、まずは自分が何を作ろうとしているのか、つまりSOAとは何か、どのようなものなのかを理解することから始めましょう。SOAの背後にある考え方や概念を定義した後で、SOAのレイヤーと、これらの各レイヤーに関する主なアーキテクチャー決定を記録する方法について説明します。これらは、SOAを実現する一連のサービス、フロー、コンポーネントと統合および連携させようとするプロジェクト、ビジネスライン、エンタープライズ規模の取り組み、またはバリューチェーンに適したSOAの青写真を描く際に役立ちます。


サービス指向アーキテクチャー: 概念モデル

この概念は、主要パーティー間のインタラクションモデルを定義するアーキテクチャースタイルに基づいています。主要パーティーには、サービス記述を公開しサービスを実現させるサービスプロバイダー、サービス記述のURI (Uniform Resource Identifier)を直接使うかサービスレジストリでサービス記述を探し、該当するサービスをバインドして呼び出すサービスコンシューマー、サービスレジストリの提供とメンテナンスを行うサービスブローカーの3つがあります(ただし現在、パブリックレジストリは主流ではありません)。

次の図1に、これらの関係を表すメタモデルを示します。

図1. SOAアーキテクチャースタイルの概念モデル
図1. SOAアーキテクチャースタイルの概念モデル

アーキテクチャースタイルと原理

SOAを定義するアーキテクチャースタイルでは、大まかに組み合わされ、ビジネスに合わせて調整されたサービスを作成するための一連のパターンとガイドラインが記述されます。記述、実装、バインドによって問題が別れるため、このような形態のサービスを作成することで、ビジネス上の新たな脅威や機会に高い柔軟性で対応できるようになります。

SOAは、オンデマンドでリソースをリンクできるエンタープライズ規模のITアーキテクチャーです。SOAでは、(一般に、企業内または複数企業間の複数アプリケーションに跨った)バリューネット、企業、ビジネスラインの関与者がリソースを利用できるようにします。SOAはビジネスに合わせて調整された一連のITサービスからなり、これらのサービスが集まって組織のビジネスプロセスや目的を果たします。これらのサービスを複合アプリケーションとして動作させ(コレオグラフィー)、標準的なプロトコルを通して呼び出すことができます(図2を参照)。

サービスとは、具体的なサービス記述付きの(検出可能な)ソフトウェアリソースを言います。このサービス記述は、サービスコンシューマーによる検索、バインド、呼び出しに使われます。サービスプロバイダーは、このサービス記述の実装を行い、サービス要件に示される品質をサービスコンシューマーに提供します。サービスは宣言ポリシーによって統括されるのが理想的であるため、動的に再構成可能なアーキテクチャースタイルをサポートする必要があります。

図2. SOAの属性
図2. SOAの属性

主として、SOAによって提供されるインターフェース、実装、(プロトコルの)バインドを分離することでITシステムの柔軟性が高まり、新しいビジネス要件(機能的要件と非機能的要件(例えばパフォーマンス、セキュリティー、拡張性など))に基づいて所定のタイミングでサービスプロバイダーを選択できるようになると、ビジネスの即応性が得られます。

フラクタル型の実現パターンでは、社内のビジネスユニット間や、ビジネスパートナーとのバリューチェーン間でサービスを再利用できます。フラクタル型の実現とは、アーキテクチャースタイルのパターンや、そのインタラクションモデルの関与者に関連付けられた役割を複合形式で応用できることを言います。これはアーキテクチャー内の1つの層に適用することも、エンタープライズアーキテクチャー全体にわたる複数の層に適用することも可能です。プロジェクトの中には、統一のとれた概念上拡張可能な方法で、ビジネスユニットとバリューチェーン内のビジネスパートナーとの間で行われる場合もあります。


コンテキスト

ここでは、サービス指向モデリングの識別、仕様決定、実現に関する上位レベルのアクティビティーについて説明するとともに、サービス指向モデリングのアーティファクトをいくつか紹介します。サービス指向モデリングは、ビジネス分析、ビジネスプロセス、ビジネス目的に合ったSOAをモデリング、分析、設計、作成するためのサービス指向分析/設計 (SOAD) プロセスです。

ここではまず、SOA自体とそのレイヤーを構築する目的について概説します。次に、SOAの作成に必要な主なアクティビティーとテクニックについて説明しながら、SOAの構築方法を説明します。

例として、あなたは現在、セルフサービスの会計システムを持つ金融ビジネスラインの一部をSOAに移行することを目的としたプロジェクトに携わっているとします。

SOAに移行するには、サービスのモデリングだけでなく、次のような要素も必要になります。

  • 採用モデルと成熟モデル。あなたの企業は、SOAとWebサービスの採用において、他と比較してどの程度の成熟レベルに達していますか? 異なる採用レベルごとに、特有のニーズが存在します。
  • 評価。社内に精通者はいますか? Webサービスを利用してみたことはありますか? 結果的にアーキテクチャーの出来具合はどうですか? 方向転換はせずに継続するべきですか? これは企業規模のSOAにまで及ぶものですか? 考慮事項はすべて検討済みですか?
  • 戦略および計画アクティビティー。どのようにSOAに移行する計画ですか? 考慮すべきステップ、ツール、手段、テクノロジー、規格、トレーニングにはどのようなものがありますか? どのようなロードマップやビジョンがありますか、またそれをどのように実現しますか? どのような計画がありますか?
  • 統括。既存のAPIや機能はサービスになりますか? ならない場合でも、サービスにするのが適当なものはどれですか? 作成されるどのサービスにも、何らかの方法でビジネスに価値をもたらす目的があります。このプロセスを邪魔しないように管理するには、どうしたらよいですか?
  • ベストプラクティスの実装。セキュリティーの実現、パフォーマンスの保証、相互運用性に関する規格の準拠、変化に合わせた設計について、試行済みの方法やテスト済みの方法はありますか?

サービス指向モデリングのアプローチには、ここで説明する識別、仕様決定、実現のほか、SOAのライフサイクル全体のサポートに必要な展開、監視、管理、統括を行うためのテクニックも含まれます。

SOAへの移行に関する前述の説明と、実現後の追加アクティビティーについては、それぞれ個別に説明する価値があります(これについては、このシリーズの今後のコラムで扱います)。ここでは、あなたが携わっているプロジェクトで、どこに重点を置くべきかを決定した(つまり、既存のシステム/サービスから新しいシステム/サービスへの移行の焦点を定義した)とします。この段階で、サービス指向モデリングを開始し、サービス指向アーキテクチャーを構築することができます。


SOAのアーキテクチャーテンプレート

SOAの抽象図では、ビジネスプロセスに合わせた複合サービスを部分的にレイヤー化したアーキテクチャーとしてSOAを表しています。図3に、このタイプのアーキテクチャー表現を示します。

サービスとコンポーネントの関係で言えば、エンタープライズ規模のコンポーネント(大まかなエンタープライズコンポーネントまたはビジネスラインコンポーネント)はサービスを実現し、コンポーネント機能の提供とサービス品質を維持する責任を持ちます。ビジネスプロセスフローは、これら提示されたサービスを複合アプリケーションとして動作させること(コレオグラフィー)によってサポートできます。統合アーキテクチャーは、エンタープライズサービスバス(ESB)を使ってこれらのサービス、コンポーネント、フローのルーティング、調停、変換に対応します。展開されるサービスは、その品質を監視および管理すると共に、非機能要件に適合する必要があります。

図3. SOAのレイヤー
図3. SOAのレイヤー

これらのレイヤーごとに、設計とアーキテクチャーの決定を行う必要があります。従ってSOAについて記述しやすいよう、必要に応じて、各レイヤーにセクション分けしたドキュメントを作成してください。

次に、SOAアーキテクチャーに関するドキュメントのテンプレートを示します。

  1. 範囲 <このアーキテクチャーの対象となる企業領域>
  2. 運用システムレイヤー 
    1. パッケージ化されたアプリケーション
    2. カスタムアプリケーション
    3. アーキテクチャー決定事項
  3. エンタープライズコンポーネントレイヤー
    1. このエンタープライズコンポーネントによってサポートされる機能領域
    2. <このエンタープライズコンポーネントによってサポートされるビジネスドメイン、目的、プロセス>
    3. 統括に関する決定事項  
      1. <このクライアント組織内のエンタープライズコンポーネントとして選択される基準>
    4. アーキテクチャー決定事項
  4. サービスレイヤー 
    1. カテゴリー化されたサービスポートフォリオ
    2. アーキテクチャー決定事項
  5. ビジネスプロセスおよび構成レイヤー 
    1. コレオグラフィーとして表現されるビジネスプロセス
    2. アーキテクチャー決定事項  
      1. <コレオグラフィーに含める必要のあるプロセスと、アプリケーションに組み込まれるプロセス>
  6. アクセスまたはプレゼンテーションレイヤー
    1. <このレイヤー上のWebサービスとSOAに関する含意(ユーザーインターフェースレベルでWebサービスを呼び出すポートレットを使うなど)と、このレイヤーの機能に関する含意を記述する>
  7. 統合レイヤー 
    1. <ESBに関する考慮事項を含める>
    2. <提供されるサービスのクライアントが必要とするサービスレベル契約(SLA)とサービス品質(QoS)をどのように保証するか>
    3. セキュリティー上の問題と決定事項
    4. パフォーマンス上の問題と決定事項
    5. テクノロジーや規格による制限と決定事項
    6. サービスの監視と管理  
      1. 記述と決定事項

次に、各レイヤーの詳細と、これらの各レイヤーの構成について説明します。

レイヤー1: 運用システムレイヤー。このレイヤーは、CRMおよびERPパッケージアプリケーション、比較的古いオブジェクト指向のシステム実装、ビジネスインテリジェンスアプリケーションといった既存のカスタム構築アプリケーション(レガシーシステムとも呼ばれる)で構成されます。SOAの複合レイヤー化アーキテクチャーでは、既存のシステムを活用し、サービス指向の統合テクニックを使ってそれらを統合することができます。

レイヤー2: エンタープライズコンポーネントレイヤー。これは機能の実現と、提示されたサービスのQoS維持を扱うエンタープライズコンポーネントのレイヤーです。このような特殊コンポーネントは管理および統括対象の企業アセットであり、エンタープライズレベルまたはビジネスユニットレベルで資金調達されます。企業規模のアセットの場合は、アーキテクチャー上のベストプラクティスを適用することで、SLAへの準拠を保証する必要があります。このレイヤーでは一般に、アプリケーションサーバーなどのコンテナーベースのテクノロジーを使って、コンポーネント、作業負荷管理、高可用性、負荷分散を実現します。

レイヤー3: サービスレイヤー。ビジネスが資金調達や提示を行うことを選択するサービスは、このレイヤーに常駐します。これらのサービスを検出したり、静的にバインドしてから呼び出したり、複合サービスとして動作させたり(コレオグラフィー)することができます。また、このサービス提示レイヤーでは、エンタープライズ規模のコンポーネント、ビジネスユニット固有のコンポーネント、さらに場合によってはプロジェクト固有のコンポーネントも組み込むためのメカニズムにも対応し、それらのインターフェースのサブセットをサービス記述の形式で具体化します。したがって、エンタープライズコンポーネントは、インターフェースによって提供される機能を使って、実行時にサービスを実現します。このレイヤーでは、インターフェースはサービス記述としてエクスポートされ、利用できるように提示されます。サービス記述は個別に存在することも、複合サービスとして存在することも可能です。

レベル4: ビジネスプロセスの構成またはコレオグラフィーレイヤー。レイヤー3で提示されるサービスの構成やコレオグラフィーは、このレイヤーで定義されます。サービスは、オーケストレーションやコレオグラフィーによってフローにバンドルされ、全体が1つのアプリケーションとして動作します。これらのアプリケーションは、具体的なユースケースやビジネスプロセスをサポートします。アプリケーションフローの設計には、IBM(R) WebSphere(R) Business Integration ModelerやWebSphere Application Developer Integration Editionなどのビジュアル形式のフロー構成ツールを使用できます。

レイヤー5: アクセスまたはプレゼンテーションレイヤー。このレイヤーは、SOAに関する説明の範囲外となるのが普通ですが、徐々に関連性が高くなってきています。ここで筆者が取り上げた理由は、Web Services for Remote Portlets Version 2.0やその他のテクノロジーなど、アプリケーションインターフェースまたはプレゼンテーションレベルでWebサービスを活用しようとする規格が収束しつつあるためです。このレイヤーは、今後のソリューションのために考慮すべき将来的なレイヤーと言えます。また、SOAではコンポーネントからユーザーインターフェースが切り離される点と、最終的には、アクセスチャネルから単体のサービスや複数サービスの構成まで、エンドツーエンドのソリューションを提供する必要がある点にも注意してください。

レベル6: 統合(ESB)。このレイヤーでは、インテリジェントルーティング、プロトコル調停、その他の変換メカニズムなど、しばしばESBと呼ばれる信頼性の高い機能セットを採用することで、サービス統合を有効にします(「参考文献」を参照)。WSDL(Web Services Description Language)では、サービスの提供場所を示すバインディングを指定します。一方ESBは、場所に依存しない統合メカニズムを提供します。

レベル7: QoS。このレイヤーは、セキュリティー、パフォーマンス、可用性などのQoSの監視、管理、維持に必要な機能を提供します。これはバックグラウンドプロセスであり、検知/応答メカニズムおよびツールを使ってSOAアプリケーションの健全性をモニターします。監視対象には、WS-Managementや、SOAのサービス品質を実現するその他の関連プロトコルや規格の重要な実装もすべて含まれます。


サービス指向モデリング/アーキテクチャーのアプローチ方法

このセクションでは、トップダウンのビジネス主導型アプローチと、これまでの投資を活かしたボトムアップアプローチを組み合わせる方法について説明します。

サービス指向モデリングアプローチは、SOAの基礎を定義するためのモデリング、分析、設計テクニック、アクティビティーを提供します。このアプローチは、各SOAレイヤーの要素を定義し、各レベルの重要なアーキテクチャー決定を行うことによって支援します。これは、トップダウンのビジネス主導型のサービス識別と、従来のアセットやシステムを活用してサービス識別を実行する一連のタスクを組み合わせて利用します。

この方法では、大まかなサービスには上位レベルのビジネスプロセス機能が具体化されます。一方、細かなサービス(上位レベルサービスの実現を支援するサービス)は、既存のレガシー機能を調べてアダプターやラッパーの作成方法を決定するか、レガシーをコンポーネント化して必要な機能(システム内でロックされる場合もあります)を具体化することで識別されます。

最後に、目的サービスモデリングでクロスセクションアプローチを使って、識別済みの可能性のあるサービス候補の絶対数を減らします。アプローチとしては、まずはトップダウン、次に目的サービスモデリング、最後にボトムアップによる既存アセットのレガシー分析の順に実行するのが賢明です。プロジェクト全体から管理可能かつ実現的なセットまで詳しく調べることが迅速にできればできるほど、SOAの基礎をなすサービス記述と主な提示サービスに重点を置くことができ、短期間で価値を実現できるようになります。

機能的なビジネス目標と、従来のレガシーシステムの活用の組み合わせは、短期間で業績を上げ、企業全体をSOAに移行する必要のある組織にとって強力なソリューションとなります。これにより、サービス指向統合によるソフトウェアアプリケーションの統合が可能になります。

サービス指向統合はエンタープライズアプリケーション統合(EAI)の発展形であり、専用接続に代わってESB概念による標準ベースの接続が使われます。このため、場所を意識することなく、柔軟なルーティング/調停/変換機能セットを提供することができます。


サービス指向モデリング: サービスの分析と設計

ここまでは、SOAについて説明するとともに、SOAを構築するにはSOA内の各レイヤーに関する主要なアーキテクチャー決定を行う必要があることと、ビジネスに合わせた一連のサービスや、コレオグラフィーを使って、どのようにしてサービスのアプリケーション組み込みを行うかについての決定を設計に反映する必要があることについても説明してきました。

オブジェクト指向とは異なり、SOAでは、サービスコンシューマーとサービスプロバイダーの2つの観点を考慮に入れる必要があります。サービスブローカーは現在のところ主流ではありませんが、将来的には扱われる予定です。

Webサービスベースのアプローチにはよくあることですが、SOAの設計ストラテジーは「ボトムアップ」から始まるのではありません。SOAはより戦略的で、ビジネスに合わせて調整されるものであることに留意してください。WebサービスはSOAを戦術的に実装したものです。統合アーキテクチャーだけでなく、エンタープライズアーキテクチャーやアプリケーションアーキテクチャーにも影響を与える重要なアクティビティーや決定が多数存在します。これには、コンシューマーとプロバイダーという2つの主な観点からのアクティビティーが含まれます(図4を参照)。

図4. サービス指向モデリングのアクティビティー
図4. サービス指向モデリングのアクティビティー

図4は、プロバイダーとコンシューマーの役割別に、一般に実行されるアクティビティーを示しています。プロバイダーのアクティビティーはコンシューマーのアクティビティーのスーパーセットである点に注意してください(たとえば、プロバイダーはサービスの識別やカテゴリー化などにも関係します)。多くの場合、これらの役割の違いのもとになるのは、コンシューマーは必要なサービスを指定し、しばしばサービスを検索し、探しているサービスの仕様とサービスプロバイダーから提供されるサービスの仕様が一致していると確信したら、必要に応じてサービスをバインドし、呼び出すという点です。これに対しプロバイダーは、機能性とコンシューマーが求めるQoS(これが特に重要です)の両面に対応したサービスを公開する必要があります。このコンシューマーとプロバイダー間の暗黙的な契約は、SLAに関する明示的な契約に発展する可能性もあります(この場合、電子的手段によって、またはビジネスや法律上の問題として交渉が行われます)。

前述のアクティビティーのフローは、サービス指向モデリング/アーキテクチャー方式で示すことができます(図5を参照)。

図5. サービス指向モデリング/アーキテクチャー方式
図5. サービス指向モデリング/アーキテクチャー方式

サービス指向モデリング/アーキテクチャーのプロセスは、サービス、コンポーネント、フローの識別、仕様決定、実現という3つの一般的なステップからなります(一般に、サービスのコレオグラフィー)。

サービス識別

このプロセスは、ドメイン分解、既存アセットの分析、目的サービスモデリングについてのトップダウンテクニック、ボトムアップテクニック、ミドルアウトテクニックを組み合わせたものです。トップダウンの観点では、ビジネスユースケースの青写真がビジネスサービスの仕様となります。このトップダウンプロセスはドメイン分解とも呼ばれます。ドメイン分解では、ビジネスドメインがその機能領域とサブシステムに分解されます。これには、ビジネスドメインのフローやプロセスを複数のプロセスやサブプロセス、上位レベルのビジネスユースケースに分解する処理も含まれます。これらのユースケースは一般に、企業の境界で提示されるビジネスサービスや、企業のビジネスライン間の境界で利用されるビジネスサービスの候補として非常に適しています。

プロセスまたは既存システムの分析におけるボトムアップ部分では、既存システムが分析され、ビジネスプロセスをサポートする基本的なサービス機能を実装するための低コストソリューションの現実的な候補として選択されます。このプロセスでは、レガシーアプリケーションやパッケージアプリケーションのAPI、トランザクション、モジュールを分析し、活用します。場合によっては、既存のアセットを再度モジュール化してサービス機能をサポートするために、レガシーシステムのコンポーネント化が必要になります。

ミドルアウトの観点では、目的サービスモデリングによって、トップダウンとボトムアップのサービス識別アプローチでは取り込まれなかったその他のサービスを検証および発掘します。ここでは、主目的と副目的、主要なパフォーマンスインジケーター、メトリックスとサービスが関連付けられます。

サービスの分類またはカテゴリー化

このアクティビティーは、サービスが識別されたときに開始されます。まず最初に、サービスの複合型またはフラクタル型の性質(サービスは、より細かなコンポーネントやサービスで構成することができ、またそうするべきである)を反映して、サービスをサービス階層に分類することが重要です。分類は構成やレイヤー化の決定に役立つだけでなく、相互に依存するサービスの構築を階層に基づいて調整する役目もあります。また、サービスの急増を緩和させる効果もあります。サービスの急増とは、ほとんど統括されないまま細かいサービスの定義、設計、展開が増え続け、その結果、パフォーマンス、拡張性、管理に大きな問題が生じることを言います。さらに深刻なことに、サービスが急増すると、「規模の経済」を実現する、ビジネスに有益なサービスを提供できなくなります。

サブシステム分析

このアクティビティーでは、前述のドメイン分解で検出されたサブシステムを使って、サブシステム間の相互依存性とフローが指定されます。また、ドメイン分解で識別されたユースケースは、提示サービスとしてサブシステムのインターフェース上に置かれます。サブシステム分析では、サービスを提示し、実現するサブシステムの内部動作と設計を表すオブジェクトモデルが作成されます。この後「サブシステム」の設計構造は大まかなコンポーネントの実装構造として実現され、次のアクティビティーでサービスが実現されます。

コンポーネントの仕様決定

次の主要アクティビティーでは、サービスを実装するコンポーネントの詳細が指定されます。

  • データ
  • ルール
  • サービス
  • 構成可能プロファイル
  • バリエーション

メッセージングとイベントの仕様決定と管理に関する定義は、このステップで行われます。

サービス割り当て

サービス割り当てでは、識別済みのサブシステムにサービスが割り当てられます。これらのサブシステムは、公開された機能を実現するエンタープライズコンポーネントを持ちます。サブシステムにはエンタープライズコンポーネントと1対1の対応があると単純に思われがちですが、コンポーネントの構成は、パターンを使い、次のものを組み合わせてエンタープライズコンポーネントを構成する際に行われます。

  • メディエーター
  • ファサード
  • ルールオブジェクト
  • 構成可能プロファイル
  • ファクトリー

サービス割り当てでは、サービスと、サービスを実現するコンポーネントがSOAの各レイヤーにも割り当てられます。コンポーネントとサービスをSOAのレイヤーに割り当てることは、主要アーキテクチャー決定の記述と解決に必要となる主要タスクです。これらの決定は、アプリケーションアーキテクチャーに関係するだけでなく、実行時にSOAを実現するために設計および使用される技術的な運用アーキテクチャーにも関係します。

サービスの実現

このステップでは、所定のサービスを実現するソフトウェアを選択するか、または自作する必要があることが認識されます。選択可能なその他のオプションには、Webサービスを使って機能の一部を統合、変換、サブスクリプト、アウトソーシングすることなどがあります。このステップでは、所定のサービスを実現するためにどのレガシーシステムモジュールを使用するか、また、どのサービスを「ゼロから」構築するかを決定します。ビジネス機能以外のサービスの実現に関する決定事項には、セキュリティー、管理、およびサービスの監視などがあります。

実際のプロジェクトでは、さまざまな機会を得るためにあらゆる努力が並行して行われます。このため、3つの流れを並行して実行することをお勧めします。

トップダウンのドメイン分解(プロセスのモデル化と分解、バリエーション指向の分析、ポリシーおよびビジネスルールの分析、文法や図を使ったドメイン固有動作のモデリング)は、コンポーネント化(モジュール化)とサービス提示の候補となる既存のレガシーアセットのボトムアップ分析と並行して行われます。目的サービスモデリングは、プロジェクトの背後にあるビジネス目的を把握し、このビジネス目的に合わせてサービスを調整するために行われます。


まとめ

このドキュメントでは、まずサービス指向アーキテクチャーの基礎とそのレイヤー、関連するアーキテクチャー決定のタイプについて説明しました。次に、サービス指向モデリング方式におけるアクティビティーと、サービスコンシューマーとサービスプロバイダーの観点から見たアクティビティーの重要性について説明しました(サービスブローカーについては、今後のドキュメントで扱います)。この方法は、サービス指向アーキテクチャーの3つの基本要素(サービス、フロー、サービスを実現するコンポーネント)を決定するための分析アクティビティーと設計アクティビティーに関する具体的なガイダンスとなります。さらに、SOAの各レイヤーでのアーキテクチャー決定に利用できるテンプレートについても説明しました。

サービス識別では、トップダウン分析、ボトムアップ分析、クロスセクション型の目的モデル分析の3つのアプローチを組み合わせることが重要であると述べました。その後、サービスの仕様決定と実現に関する主要アクティビティーについても説明しました。

このシリーズの次のコラムでは、この方法をアカウント管理されるバンキング(業務)領域に応用して、各ステップについて例を挙げて説明します。また、識別、仕様決定、実現のほか、SOAのライフサイクル全体をサポートするのに必要な展開、監視、管理、統括といった、サービス指向モデリングアプローチの残りのアクティビティーについても説明します。

謝辞

本ドキュメントの著作にあたっては、Luba Cherbakov氏、Kerrie Holley氏、George Galambos氏、Sugandh Mehta氏、David Janson氏、Shankar Kalyana氏、Ed Calunzinski氏、Abdul Allam氏、Peter Holm氏、Krishnan Ramachandran氏、Jenny Ang氏、Jonathan Adams氏、Sunil Dube氏、Ralph Wiest氏、Olaf Zimmerman氏、Emily Plachy氏、Kathy Yglesias-Reece氏、David Mott氏(順不同)から貴重な情報提供およびご意見をいただきました。

参考文献

コメント

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=243778
ArticleTitle=サービス指向のモデリングおよびアーキテクチャー
publish-date=11092004