企業から見たSOAガバナンス

「… SOAガバナンスの最大の特徴は、企業の協調的な性質を評価することと、共通の目標の推進をよりどころにすることです」- SOA Reference Architecture [1]

SOAガバナンスはSOAで近ごろ最も話題となっていて、最もデリケートなトピックの1つです。約2年前、多数の企業がともかくSOAに取り組み、そしていわゆる「更地状態」からスタートすることができました。SOAガバナンスが適所に用意されているかについて、配慮が行き届かなかったのはなぜでしょうか。釈明は色々あるかもしれませんが、私はこの状況からSW開発者の行動原則、「試してみてうまくいかなかったら、その後で取扱説明書を読めばいいのだ」を思い出します。

SOAは既存資産を統合し、再利用するためのIT新技術である、と組織は当時納得させられていたのです。統合と再利用により、ビジネス上のニーズにもっと速く、もっと簡単に（魔法のように）対処できなければなりませんでした。組織の中には何百ものWebサービスを構築したばかりに、あまりにも多くの統合ポイントを管理するうちに桁外れの困難に遭遇し、遂に前進も後退もできなくなったところもありました。他の組織は、約束されたはずのROIと製品化までの時間を達成できませんでした（考えてもみてください。トラックのエンジンを交換してもいないのに、車輪の数を増やすだけで、速く動けると思いますか？）。成功して前進したのは極めて少数でした。なぜこのような事態になったのでしょうか。

こうした問題の主な原因のひとつに、サービス指向設計や実装、利用がまったくガバナンスされていなかったこと、もしくは伝統的なSW開発としてガバナンスされたこと、つまりサービス指向化の詳細に対する理解がないままガバナンスされたことが挙げられると思います。この論文は企業の見地からSOAガバナンスの詳細を観察し、SOAのガバナンスポリシーの例をまじえながら、ガバナンスの詳細を説明するものです。

SOA標準におけるSOAとは？

まず、共通の認識を定め、これから話す事柄を定義しておく必要があります。W3CやIBM、WikipediaなどでSOAの定義はおそらくたくさん見つかるでしょう。ここで使うのはそうした定義ではなく、OASISが初のSOA専用標準の中で2006年末に発表したSOA Reference Model 〔RM〕（参照モデル）[2]です。この標準ではビジネスを中心に据えたアーキテクチャのパラダイムとしてSOAを位置づけました。すなわち、SOAにおいて最優先されるのはビジネスであり、ビジネスの後に初めて、主なサービス指向環境としての技術について論じるのです。

SOA RM:
サービス指向アーキテクチャの焦点はタスクやビジネス機能 ? つまり、何かの処理を完了させること -- です。

この論文ではOASISのSOA RM標準およびSOA Reference Architecture、Public Review of SOA-RA V1.0(リンク)の草案1（SOA RA PRD 1）［1］を利用します。両文書とも、ビジネスを中心に据えたSOAの性質とビジネスの変化に対する柔軟な適応性を強調しています。

SOA RM:
…SOAにおいてサービスは、ニーズと能力を引き合わせるメカニズムです。

もちろん、OASISのSOAはサービスに関係しています。しかし、SOAにおけるサービスは実装の真偽が不明な抽象概念として定義され、この概念の手助けによって顧客は、自らのニーズを満たす実世界効果（RWE=Real World Effect）を手に入れるのです。SOAのサービスは顧客にRWEを提供するため、独立して存在するリソースと結びついた能力を活用します。

SOA RM:
実行コンテキストの定義：…技術的・ビジネス的な要素の一揃えであり、ニーズがあるものと能力を有するものの間に経路を形成します。

SOAサービスは「実行コンテキスト」で動作し、このコンテキストはビジネスコンテキストと技術的コンテキストで構成されています。ビジネスコンテキストには、ビジネスモデルやルール、規定が含まれ、RWEにはビジネスコンテキストにおいて特定の解釈が与えられます。技術的コンテキストは技術的環境のことであり、サービスの技術的なパーツが実行されます。

大多数の企業で目にするように、ビジネスコンテキストと技術的コンテキストは、（残念ながら）別々に存在し、別々に進化します。こうした分離の原因はビジネスとIT間の因習的な関係であり、そこにはSOAに対する重大な脅威が隠れています。例を挙げましょう。英国内に存在する建造物の階数を数える単純なサービスがあると想定してください。ビジネス、すなわち「ニーズを持っているもの」が、技術的なサービスの実装、すなわち「能力を持っているもの」を米国内で適用しようと決め、同じRWEを期待します。このサービスを使って米国で得た結果が、英国における結果と異なると判明すれば、ビジネス的に不満が生じることは想像に難くないでしょう。原因は些細なことです -- サービスが異なるビジネスコンテキストで実行されたのです。米国では建物に「ground floor」がなく（訳注：英国では1階を「ground floor」と呼びます。米国では1階を「first floor」と呼びますが、英国で2階を指す言葉になります）、また、12階の次は13を飛ばして14階になるのです。

ここ数年間、SOAにはマーケティングの陳腐な決まり文句がつきものとなりました。「SOAのゴールはIT資産間のより良い統合です」や、「SOAとはサービスの再利用のことです」、果ては「WebサービスでラッピングしたレガシーアプリケーションがSOAサービスになるのです」などです。私はただ、「本当に？」と尋ねたいです[3]。こうした決まり文句はすべて、技術的な解釈を過度に単純化したものですが、SOAでビジネスをモデル化するには、ビジネスアーキテクチャ、技術的アーキテクチャ、ソリューションを介さなければならないのです。BurtonグループのAnne Thomas Manesが次のように述べています。「SOAは統合アーキテクチャではなく、システムアーキテクチャの一様式です。能力をリファクタリングしてサービスにすることであり、アプリケーションサイロを統合することではありません」。私はThomas Manesの言葉につけ加えて、伝説になるほど有名なサービスの再利用さえ、SOAマーケティングの最良の候補ではない、とさえ言えます。なぜなら、Webサービスの取るに足らない再利用により、企業がマーケットリーダーになる可能性も、悪夢に見舞われる可能性もあるからです。サービスの再利用をSOAガバナンスがどのように定義・統制するかに、すべてがかかっているのです[4]。サービス再利用について話をするようになってすでに2、3年になりますが、サービスガバナンスについて話し始めたのはつい最近のことです。SOA導入を困難にしている原因がここにあります。

SOAガバナンス

標準ベースのガバナンスの基本

SOA RA PRD 1ではSOA範囲内における企業の社会構造の役割について認識しています。はっきり言うと、サービス相互作用の参加者（サービス消費者と提供者）の行動は、「ニーズがある」人間や「ニーズがある」組織の構成単位と、「能力を有する」ものに対してだけ、ビジネス上、技術上の意味を持つのです。結果として、社会構造に変化があれば、同一の行動でも以前とは違う意味を持つかもしれません。さらに言えば、異なる社会構造において消費者がサービスの行動に同じ意味を期待するなら、そうした期待に沿うためには、異なる社会構造においてはサービスが異なる動作をとり、異なる結果（あるいはRWE）をもたらさなければならない可能性が高いのです。

SOA RA PRD 1:
…参加者がとる行動は…通常、社会的なコンテキストの中で実行され、この社会的コンテキストが行動の意味自体を定義するのです。

SOA RA PRD 1:
社会構造：特定の社会的コンテキストを具体化したもの

社会構造の概念は、組織においてビジネスとITを分ける境界線を越えます。これにより、ビジネスとITをひとまとめにカバーする、企業規模のガバナンスモデルとしてのSOAガバナンスの基礎が築かれます。このアプローチは非常に自然です。なぜなら、SOAにおける主な技術的目標は、ビジネス利益のためにRWEを達成することだからです。換言すれば、SOAとSOAガバナンスの「頭部」にあたるのがビジネスであり、「手足」にあたるのが技術なのです。

SOA RA PRD 1:
…サービスの相互作用に取り組もうと計画する組織は、SOAベースの効果的なサービスの作成や利用を促進する上で、組織内外の境界を越えた全域で標準化を確約できるだけのガバナンスポリシーと手順を導入することが肝要です。

企業規模のサービス指向化概念により、SOA RMで言われているように、異なる所有権領域に属するビジネス機能や技術的機能が分散するようになります。これは特別トピックとして、後ほど検討することにします。さて、所有権領域の構造と企業そのものの構造がSOAガバナンスのヒエラルキーに影響する、とたった今概説しました。したがって、次のようなSOAガバナンス構造が認められます。:

• 企業ガバナンスの一環としての企業SOAガバナンス
• 企業SOAガバナンスには以下が含まれます。:
  • ビジネスSOAガバナンス
  • IT SOAガバナンス
    • IT開発SOAガバナンス

SOAガバナンスはポリシーと規定に基づいた意思決定に関係しています。ポリシーと管理の実行に関与しているのは経営陣です。SOAにはそのガバナンスを通じて、企業内における管理上の所有権領域を横断するという独特の能力が備わっていますが、これは経営陣の関与のお陰であり、技術に根ざした他のいかなるアーキテクチャも、所有権領域の横断はできませんでした。企業においてSOAガバナンスが影響を与える分野を図1に示しました。

SOA RA PRD 1:
SOA が人間関係の重要な側面を調停するとすれば、コミュニティによる実施を必要とする約束事が参加者によって結ばれ、そしてSOA自体がコミュニティそのものの要件を反映しなくてはならない、ということになります。これは両方とも、サービス指向アーキテクチャによるガバナンスの側面です。ガバナンスに関連するモデル〔M.P. ? SOA RA〕における重要要素には、社会構造の構成、社会構造のポリシー、社会構造における権限、関連する実施のメカニズムがあります。

そうは言っても、SOAガバナンスが企業ガバナンスやビジネスガバナンス、ITガバナンスに取って代わることはありません。SOA以外にも世界が存在することを忘れてはなりません。

SOAガバナンスと所有権

ガバナンス構造においては、所有権領域が最重要級の役割を演じます。所有権が単一の領域では通常、ガバナンスは階層的になっており、その中には企業、営業科目（LOB=line of business）、事業単位（BU=business unit）、技術、IT、アーキテクチャの各ガバナンスが含まれます。所有権が複数存在する領域環境では、単一の領域のようにはガバナンスできず、容認済みのガバナンス権限に基づく必要があります。たとえば資金運用会社で、小口金融LOBがファンド取引ビジネスサービスを開発したとします。小口金融LOBはサービスの所有者であり、サービス提供者でもあるかもしれません。同企業の機関LOBは、このサービスの所有者と契約関係を結び、小口金融LOBのガバナンス権限を認めるだけで、機関のクライアントWebサイトにおいて同サービスを再利用できるようになります。

所有権領域によって課される制約は、IT内では非常によく知られた存在です。リソース可用性に対するこうした制約が原因となり、ITで開発の取り組みが重複したり、ITプロダクトのリリースのバランスが崩れたり、企業アーキテクチャや技術ロードマップの安定化で問題が発生したり、複数のP2P統合における混乱が起こったりするのです。ビジネスとITの両経営陣にプラスの影響を与えられるのは、ビジネスとITをひとまとめにしての縦方向のガバナンスのみであり、このガバナンス方法ではポリシーを設定し、そのポリシーに業務上のコンテキストを提供するルールも定義します。たとえば、ビジネスをガバナンスする組織体は、ビジネスクライアント全員が各自、関連ビジネスデータに対して資格を持っていなければならないと定めるポリシーを設定することもできるでしょう。ITをガバナンスする組織体は、PKI技術に基づいたユーザー認証サービスが資格の第一歩でなければならない、というルールを明言できるでしょう。PKIを発行する組織体として、IT管理者に認定を受けている者、また、実際の認証を行う方法について、今度はIT管理者が明示することができます。

図1. SOAガバナンスの影響分野

ルールや規定を定めても、遵守が評価されなければ、効果的なガバナンスが保証されるわけではありません。こうした評価に基づいて、ルールや規定を実施できるのです。評価指標は、サービスの動作がポリシーと契約にどれほど則っているかを明らかにする上で測定可能な状態や数量となります。ルールや規定は収集した評価指標に基づいていなければならず、そうでなければ、経営陣が遵守を査定する方法がなくなってしまいます。皆がはっきりと評価結果を理解できるようにするためには、評価指標をサービス相互作用の参加者と、ガバナンス担当の組織体に公開すべきです。

異なる所有権領域への効果的な対応は、それが一企業内であっても、ガバナンスにおいてはトップクラスの難題に入ります。SOAガバナンスはこの点に関して、サービス開発とサービス維持管理においてサービス指向的な方法を必要とし、この方法は伝統的なアプリケーションガバナンスとは異なります。ビジネス／技術グループ、個人、消費者、開発者は、各サービスの所有権縮小と同時に発生する、非常にたくさんの結びつきや依存性を検討するように、サービス指向ポリシーによって求められます。これが、市場ニーズに即したSOAの柔軟性と順応性に支払われる代償です。

効果的なSOAガバナンスにおいては、ポリシーと規定のバランスがとれていなければなりません。所有権領域を横断するには、何段階かに分けた勧告のような形でポリシーを表現することにより、このバランスを達成できるかもしれません。たとえば、必須、高推奨、推奨、制限、禁止、などです。バランスをとる手順には、プロセスと、プロセスを実行する適切な規律が必要です。これには、ポリシー遵守の例外に対する妥当性確認も含まれます。このようなバランスをとるための主な必要条件は、現在そして未来のビジネスニーズを検討することであり、こうしたニーズはガバナンス下にあるサービスとSOAエコシステム全体の柔軟性を介して処理されます。

ITのSOAガバナンスにおける問題

企業でSOAの原則を利用する主なメリットの一つとして、リソースを迅速に補充、再配置する能力が挙げられ、この能力を使ってビジネスで、そしてひいてはITにおいても、予期せぬ事態や新展開に対応します。また、リソースを利用する方法にはかなりの柔軟性が必要であり、サービス能力には高い信頼性が必要です。

図2. ビジネスアプリケーションとサービスの構成

図2は、前述の必要条件を満たし、ITに実装される可能性のあるビジネスサービスの概念を示しています。この概念が他と根本的に違っている点は、モデル駆動型アーキテクチャをコンポーネント・ベースの設計と組合せて、垂直限定構造（VDS=vertical dedicated structure）としていることです。このようなVDSには、ビジネスの1タスクをエンドツーエンドで処理する機能が結合してセットとなり、積み重なっていきます。

VDSが表しているのはビジネスサービスやビジネス機能、ビジネス機構であり、もしかすると、ビジネスプロセスとして実装された、より複雑な集合体でVDSが利用される可能性もあります。各VDSで階層化した組織は、リソースの迅速な再構成と再利用をサポートし、さらに、レイヤーの中には、ビジネスアプリケーションの統合に向けて、外部のコンポーネントやサービス（例：Service Interface〔サービスインターフェース〕やProcess Connector〔プロセスコネクター〕）から直接アクセスされるものもあるかもしれません。このアプローチを使ったビジネスアプリケーションは、Business Process Connector Layer（ビジネスプロセス・コネクターレイヤー）を介して組織化した、1つから数個のビジネスサービスで構成されていますが、このサービスにはプログラミングが全く必要ないか、最小限で済みます（製品化に要する時間が最短になります）。このようなビジネスサービス・モデルのさらに詳しい検討は別の論文のトピックになりますが、その中にはSOAガバナンスのテーマがいくつかあります。たとえば、レイヤー間で関心事を分離するポリシーや、内外のインターフェース・アクセシビリティ、Technical Service Layer（テクニカルサービスレイヤー）とResource Layer（リソースレイヤー）間でのエンティティ共有などです。

したがって、SOAガバナンスはサービス構造とサービス利用の主要4側面に適用します。:

• サービス構造 – 要素の最小セットであり、要素の結びつきと業務モデルの中でサービスを形成します（開発、統合、デプロイメントの各ポリシー）
• SOAインフラ – サービスの使用を可能にし、サポートするユーティリティの機能を提供する「配管」です（デプロイメント、ランタイムの各ポリシー）
• サービスインベントリ – パブリックインターフェースを介して、手動もしくは自動で、インフラ内におけるサービスへのアクセスを許可する、サービスに関する要件（管理ポリシー）
• 参加者の相互作用 – サービス相互作用の全参加者による遵守が期待される、一貫した見込み（到達可能性、ランタイムの各ポリシー）

SOA RA PRD 1:

…サービス機能性…は、サービスとの相互作用で何が期待できるかを説明したものです。

サービス機能性とは、サービス機能とその機能を呼び出すことの実世界効果を明確に表現したものです。機能とはおそらく、何らかの領域で望ましい実世界効果を生み出す、ビジネス活動のことを示します。

サービス機能性は、結果として生じる可能性のある効果の根拠となる技術的な仮定によって、制限される可能性もあります。技術的な仮定はおそらく、サービスのアクセスを受ける、根本的な能力と結びつきがあります。

サービス機能性の要素を表現するのは、自然言語の文章や、機能に関する既存の分類法への参照、充実した説明とコンテキストを提供する、より正式なナレッジキャプチャへの参照かもしれません。

サービス開発のSOAガバナンスはこの論文の範囲外ですが、次のセクションでは前述の側面について、より詳細に論じます。

サービス構造の要素の中には消費者専用のものもありますが、サービス構造は外界に対して透過的で、見えるようになっていなければなりません。具体的に言うと、目に見えるサービス構造要素は以下のとおりです。:

• サービス機能性
• サービスインターフェース
• サービス到達可能性
• サービスコミュニケーション／呼び出しポリシー（参照のみの場合もあり）
• 消費者にとって重要であり、サービスRWEやサービス動作上の特性、関連評価指標に影響を与える、サービス実行ポリシー

サービス機能性はSOA RA PRD 1で定義されているように、SOAサービスの主要要素の1つです。サービスが消費者の必要条件（ニーズ）を満たすかどうかをサービス消費者が決定するために、機能性を使います。こうした要素には他に、動作特性と関連評価指標があります。

すべての目に見えるサービス構造要素は公共利用を目的に、サービス記述（Service Description）文書内で説明されます。SOAガバナンスは、サービス記述の中身のみならず、そのライフサイクルを規定するポリシーや、告知・保管する場所、利用規則を定義します。

サービス提供者は利用可能なサービスを告知するためにサービス記述を使い、サービス消費者はサービスを捜し出すために使います。サービスの検索は手動の場合も自動の場合もあり、サービスによって異なります。Semantic SOAの相互運用[5]により、サービス記述書内のサービス機能とRWEの表現について、サービス消費者とサービス供給者間で相互理解が促進されると期待されています。

図3はサービス記述文書を図解しています。この図から、以下がお分かりになるでしょう。

• サービス到達可能性はサービスアクセスの物理的ポイントを定義します
• サービスインターフェースは、サービスが提供する論理的インターフェースをグループ化します
• サービス機能はRWEをもたらします
• ポリシーはサービス実行コンテキスト（EC=execution context）を定義します

このモデルについてのコメントを以下にまとめます。

• サービス記述は機能一式（つまり機能性）を識別可能です
• サービス記述は、複数のサービスインターフェースを識別可能です
• サービス動作は指定のEC内で約束されています。指定のEC以外でサービスが再利用される場合は、サービスを再テストし、同じRWEをもたらすことを確認しなければなりません
• サービス契約はサービス記述に由来します

図3. サービス記述文書の構成要素

サービス機能がサービスインターフェースのオペレーションに反映される可能性はありますが、必須ではありません。たとえば、一つのサービス（サービス記述）が、各サービス呼び出し向けに監査ロギングを実施すると約束可能で、消費者はこの機能に依存するかもしれません。ロギングはサービスインターフェースで説明されていませんが、独自の監査サポートにより、消費者の労力を減らすことができます。最も単純なケースでは、1機能に1インターフェースオペレーションが相応し、そのインターフェースにはオペレーションが1つだけ入っています。SOAサービスインターフェースは一般に、到達可能性（プロトコルとエンドポイント）だけでなく、動作と情報の両モデルにおけるオペレーションセマンティクスで異なる可能性があります。多数のインターフェースを有するサービスの単純な例としては、RMIやCORBA、Webサービスインターフェースを使ってEJB上に構築したインフラ・サービスが挙げられます。

SOAインフラ

SOAガバナンスの見地からすると、SOAインフラには少なくとも3つの構成要素が必要です。サービス実行プラットフォーム（ランタイムプラットフォーム）、利用可能なサービスのサービス記述リポジトリ、サービス告知とランタイムに適用可能なサービスポリシー・リポジトリの3つです。その他にも、サービスレジストリ（UDDIなど）、ESBのような仲介サービス、サービスランタイム監視システムなどのようなもの、といったインフラ構成要素があるかもしれませんが、こうしたものは任意です。サービス記述リポジトリにはSOA RA PRD 1で言及されているサービス記述文書が含まれ、サービスレジストリとの組合せも可能です。

SOAサービスで大いに推奨される使い易さの特徴の1つに、サービス契約があります。サービス契約はサービス記述に由来すると留意することが重要です。両者の主な相違は、サービス契約がサービス提供者と1人以上のサービス消費者との間の双方の合意を対象としているのに対し、サービス記述はサービス提供者のみによるサービスの告知という点です。サービス契約は、サービス記述構成要素のサブセットとなっています。サービス契約はさらに、特定消費者向けのサービス内容合意書（SLA=Service Level Agreement）を含むか、参照することになっています。消費者が違えば、たとえば、通信プロトコルの違いに応じて、同一サービスでも異なるSLAとすることに同意する可能性があります。

サービス契約は個々の消費者との私的な合意ですから、サービス契約がサービス記述の一部として利用可能かどうかにかかわらず、SOAガバナンスポリシーによる規制が必要です。サービス契約のこの私的な性質が原因となり、サービス契約間のインヘリタンスやクロスリファレンスが非常に複雑化するか、あるいは単に禁止される可能性があります（消費者は、別の消費者との非開示契約に依存してはなりません）。しかしながら、ポリシーのインヘリタンスやクロスリファレンスはよく見られます。

場合によっては、全消費者に対して同一のサービス契約にした方が合理的なこともあります。また、サービス使用における権限のルールを定義する特殊なポリシーに関しては、サービス記述が単一の共用サービス契約の役割を果たす可能性もあります。たとえば、セキュリティサービスは全員に無差別で適用可能かもしれませんし、個々の消費者との合意も不要です。サービス契約リポジトリも同様に、SOAインフラの推奨要素ではありますが、任意です。

サービスインベントリ

ガバナンスモデルの中には、厳重に管理された環境を扱うものもあり、その場合の主な関心事はサービスのあらゆる重複を避けることであり、もっと正確に言えば、サービス機能性の重複を回避することです。他のガバナンスモデルでは、消費者に幅広い選択を提供するサービスの市場(いちば)を提言しています。そうしたガバナンスモデルでは、市場コンセンサスからより良いサービスが出現し、「選択の余地がある」ことにより、工夫が進むことが期待されます。

一方、（ミッションクリティカルではないにしても）重要な機能性が、単一のサービスからしかアクセスできない場合は、言うまでもなく、企業にとって深刻なリスクが生じます。ITの余剰リソースについて話をする代わりに、SOAにおいては機能性の到達可能性を管理せねばならず、言い換えれば、SOAにおいては、同一の機能性に到達する複数の方法を用意しておくことが道理にかなっているのです（一方、サービス能力は同一である必要はないかもしれません）。したがって、機能性はサービスインベントリの重要な情報要素になります -- サービスＩＤやインターフェース、名称の列挙では、もはや不十分なのです。

SOAインベントリは、前述したサービス記述リポジトリを基にしてもよいでしょう。ガバナンスのインベントリ・ポリシーによって、たとえば、サービスのバージョニングモデル、新バージョン告知のためのルール、サービス引退プロセス、EOLイベントを規定できるでしょう。

SOAにおける参加者の相互作用

参加者はSOAガバナンスで定められたポリシーに従ってSOAで相互作用します。各サービス提供者には、サービス記述で明言されているローカルなポリシーが用意されているかもしれません。消費者がローカルな境界を越えてサービスに到達するためには、グローバルなガバナンス様式が必要になります。しかし、一つの企業内でさえ、所有権領域を越えてポリシーに共有可能なセマンティクスとオントロジーを用意することは、明らかなる難題なのです。

SOA RA PRD 1: …目標は、グローバルなガバナンスにはほとんど実態がわかっていないローカルなニーズに対して、グローバルなガバナンスが過度に厳格あるいは寛容な基準を定めないようにすることです。

規制された金融市場に見られるように、SOAのグローバルなガバナンスも同じ方法で可能です -- Webサービス相互運用向けには、WS-Ｉ Basic Profile [6]のような、中央集中化した最小限の標準化ポリシーひと揃いがあるかもしれません。それでもなお、管理ポリシーが場所を問わず等しく実施されるという期待は非現実的です。ですから、グローバルなSOAガバナンスの効果的な方法は、次のようなものかもしれません -- 相互作用を望む参加者には、ローカルに承認されたガバナンスポリシーに従ってもらわなければなりません。ここで強調されるのが、SOA相互作用におけるサービス契約の役割です。

ご覧になったように、サービスガバナンスは、相互作用する全参加者から集めたガバナンスポリシーで構成されています。サービスガバナンスは、集合サービス・モデルが原因の興味深い結果をもたらします。SOA RA RPD 1では、サービスの相互作用には少なくとも2人の参加者が必要で、2人以上の可能性もある、と述べています。サービス消費者1人と集合サービス1つのケースを想定しましょう。集合サービスとはすなわち、それ自体の機能性を満たすために他のサービスを利用するサービスです。つまり、サービスの参加者は数人いるかもしれません。使用中の各サービスには独自の管理ポリシーが存在する可能性もあり、そのポリシーによって、集合サービスが約束したRWEが影響を受けるかもしれません。サービス記述にある最終的なサービス結果に影響を与える可能性のある全ポリシーをどのように選択し、説明するかというルールを見極め、さらにサービス契約の品質（完全性）を保証することは、ガバナンスにとって重要な仕事となります。

SOAガバナンスのポリシー例

ITのSOAガバナンスは、サービスの開発、本番の両段階に影響を与えると、これまでにお話ししました。ガバナンスは小さく始め、まず開発段階に集中してもよいでしょう。しかし、ランタイムにおけるサービスの柔軟性やスケーラビリティを促進する、将来のSOAガバナンスポリシーの基礎を形成しなければなりません。SOAガバナンスポリシーの実用的な例を以下に挙げました。:

結論

SOA RA PRD 1:
「ひとつですべてに対応」するガバナンスは存在しないので、SOAを目標とした環境において、ガバナンスが求められる事柄の種類を理解する必要があります。コミュニティの中には、非常に厳しいポリシーや手順を最初から切望し、要求するものもあれば、ほとんど必要性を感じないコミュニティもあるでしょう。時間の経過とともにベストプラクティスが進化し、分別ある最低限で意見の一致をもたらすと思われ、必要と実証されている極端な場合を除き、ベストプラクティスの中庸に向けて厳格なガバナンスが緩むと思われます。

SOAガバナンスは不可欠な領域であり、この領域には顧客中心のビジネスと技術的なサービスのガバナンスが含まれます。SOAガバナンスの明確な標準化はありませんが、OASIS SOA RM標準はSOA RA PRD 1とともに、SOAのこの側面にかなり配慮しています。

SOA RMとSOA RA PRD 1は、SOAの社会的効果を認め、それに応じてSOAガバナンスを識別しています。この点において、SOAガバナンスは企業ガバナンスの一環と見なされ、所有権の境界を越えて、ビジネスとITの両関連分野をカバーしています。

この論文は、SOAの基本的な構造要素やSOAインフラ、サービス相互作用をガバナンス的見地から観察したものです。

SOAガバナンスは、サービス消費者には信頼を奨励し、サービス提供者には、現代のダイナミックなビジネス市場におけるビジネスニーズを満たすサービス能力を提供するよう働きかけるものでなければなりません。この達成に向け、SOAガバナンスは企業のトップから底辺まで、ビジネスから技術までをひとまとめにして、柔軟性と順応性の概念を推進します。

参考資料

1. Reference Architecture for Service-Oriented Architecture (PDF), Public Review of SOA-RA v1.0, Draft 1, OASIS

2. Reference Model for Service-Oriented Architecture (PDF), OASIS

3. M. Poulin. “Does a Web Service Make a Service for SOA?” (リンク), SOA & WebServices Journal （2006年5月）

4. M. Poulin. “Service Reuse and Entitlement”(リンク), SOA World Magazine （2008年3月）

5. Dmitri Ilkaev. “Recent Trends in Semantic SOA”(リンク), StickyMinds.com

6. Web Services Interoperability Organization (WS-I) (リンク),

著者について

Michael Poulin氏は英国、米国の複数の金融機関で企業レベルのソリューション・アーキテクトを務めています。Sun Certified Architect for Java Technology（Sun認定Javaテクノロジー・アーキテクト）であり、TOGAF PractitionerやZapThink SOAアーキテクトとしても認定されています。最近の10年間は、分散コンピューティング、SOA、アプリケーションセキュリティを専門にしています。氏の最近の出版物はSys-Con Mediaで見つかるかもしれません。

原文はこちらです：http://www.infoq.com/articles/poulin-governance
（このArticleは2008年8月20日に原文が掲載されました）