SOAのためのメッセージタイプアーキテクチャ

原文(投稿日：2009/2/9)へのリンク

SOAガバナンスの組織の主要な目的の一つは、再利用可能なサービスを促進するためのプロセスとポリシーを定義することです。そのようなSOAガバナンスの組織は、検証、資金調達、設計、デプロイ、運用、バージョン管理から終了まで、サービスのライフサイクル全体に関与しています。

しばしば見受けられるSOAガバナンスの主要な側面の１つに、データガバナンスがSOAガバナンスをどのように補完するのかということがあげられます。それらが共に大きく異なる目的を持っていたとしても、それらは共に、通常「エンタープライズデータモデル(EDM)」と呼ばれるメタデータのセットを共有します。EDMは、情報システム全体の論理的なデータモデルです(言うなれば、オントロジーです)。その構造は、通常抽象的で、レコードシステムの物理的な構造にゆるく結びついています。しかし、与えられたレコードシステムに格納されているすべてのデータ要素は、あるEDMの要素から追跡可能でなければなりません。EDMは、同期化されたり複製されたデータを、あるシステムから別のシステムへ転換するためのマップを構成するのにしばしば利用されます。　

EDM に加えて、データガバナンスは、サービス設計、オペレーション、バージョン管理、利用に影響を及ぼすプロセスを持っています。これらのプロセスには、データ特性、メタデータ管理、参照データ変更、ビジネスルール変更、外部データ要求、データモデル変更... を含みます。

本稿では、私たちはデータとSOAガバナンスのプロセスの間に必要な協調についてはフォーカスしません。私たちは、効果的な協調の前に必要な第一歩についてフォーカスします。それは、エンタープライズデータモデルの共通利用です。

90 年代中頃にXMLが考案されて以来ずっと、人々はXMLドキュメントの構造を記述する一番の方法、特に、再利用可能なXMLの断片を作る方法について議論していました。3つの陣営が異なる形で浮かび上がり、時には意見が分かれ、そして必要とされました。それは、Web陣営、ドキュメント陣営、データ陣営の３つです。DTD(リンク)では十分でないことが明らかになると、W3CはすぐにXMLスキーマ(リンク)の仕様を公開しました(現在では、それから１０年近く経っています)。来るマイナーバージョン(XML Schema 1.1(リンク))の変更に対して、より少ない変更が期待されています。いくつかの批判(複雑さ、不十分な点、...)や、代替となる技術(Relax NG(リンク))や補完的なもの(Schematron(リンク)) の開発にも関わらず、XMLスキーマは、XMLメッセージの型を記述する標準として利用されていますし、今後もそうなるでしょう。しかし、XMLスキーマの定義だけを使用してEDMをモデル化するための効果的な方法を本当に見つけている人はいません。これは、２つの規律、データとSOAガバナンスの分離に起因しています。

本稿で、私たちはメッセージタイプがEDMメタデータから生成されなければならないということについて議論します。私たちは、XML、ERD、UMLといった従来のモデルの利用は、この目的でEDMを利用可能にするのには適していないということも議論します。私たちは、２つの補足的なDSL(ドメイン特化言語(リンク)) を定義することを提案します。それは、EDMのためのものと、EDMの要素が参照しているメッセージタイプのためのものです。これらのDSLは、EDMとメッセージタイプ定義から得られたものからテキストの表記を生成するのに利用されます。また、これらのDSLはグラフィカルな表記を生成するためにも適しています。

エンタープライズデータモデルのドメイン特化言語

UMLとERDは、具体的なM２メタモデル(リンク) (OO と ER それぞれ(リンク))に深く根ざし、共に強い血統をもっています。両方のモデルは、XMLドキュメントの階層的な性質とそれの関連したスキーマ言語として、実質、互換性のないものです。あなたが、サラミスライス、ロシア人形、ベネチアンプラインド(リンク)、あるいは、それらの任意の組み合わせのどのパターンを使うのかは、重要ではありません。XMLスキーマは、この機能を効果的に実行することができません。それは、モデリング言語ではないのです。それは、ドキュメントの妥当性確認をするためのXMLドキュメント構造の定義です。加えて、全てのフレームワークがこれらの複雑なXMLから構造を取りこんでクラスを生成することができるわけではないので、これらのパターンを乱用した構造を取り込んだ複雑なXMLスキーマは、インターオペラビリティを壊します。

実際、これら3つのデータタイプは、ハイパーグラフデータモデル(リンク)と呼ばれる仲介のデータモデルによってのみ、確実に変換することができます。

もちろん、それはUMLやERモデルからXMLドキュメントを作成することが可能で、逆もまた同様で、一連の明確な(そして、アドホックな)ルールをベースとしています(特に、関連を扱うための方法を指定するもの)。しかし、これらのルールベースのマッピングが現実的なメッセージタイプを生み出すことはありません。その理由は、非常に単純です。:

a)  データは、実際は関係のあるものです。それは、人類が書くこと、会計、契約を考案した8000年前から真実でした(リンク)。すべての情報システムが紙ベースであった100年前も真実でした。そして、人がデータを操作する間は、それはおそらく真実のままでしょう。エンタープライズデータモデルでは、ほぼすべてのエンティティは、他のすべてのエンティティと関連があります。しかし、UMLやERDでは、他のエンティティからそのエンティティを作るクラスの境界を明確に決めていません。

b) メッセージタイプの要素は、大抵、EDMのエンティティに対応する属性の一部を含んでいます。人は粒度の細かい再利用可能なデータ要素のセットを作ろうとしますが、その戦略はもろいものであるという実績があり、EDMに不必要な複雑さを取り込みます。

私たちは、EDMの必要性にあったセマンティクスでメタモデルを作ることを提案します。:

a)  関連(集約やコンポジション)が同じメッセージタイプ(あるいは、データベースのテーブル、このメタモデルでの別のアプリの帳票)に属す結果となることがほとんどであるようなスコープを定義するエンティティ。このタイプの関係の例は、「顧客-住所」の関係です。

b)  エンティティ間の関係を記述するエンティティの関連。例は、「顧客-口座」となります。

このメタモデルは、「エンティティ」、「バリューオブジェクト」、「集約」を含むドメイン設計開発(参考記事・英語) (DDD)のコンセプトできちんと整理されています。 

私たちが健康保険の領域を例にとるならば、MemberとGroup(あるいは、Coverage)が別のスコープを定義しているので、私たちはMember-Addressの関連がMemberのスコープに属していることが分かります。

図1. 異なる関連のタイプを例示している単純なUML図

私たちのEDLのDSL文法は、(図2)の通りです。私たちは、テキストのDSLを作るためのOpenArchitectureWare(リンク)プラグインと、Eclipseモデリングフレームワークを使用しました。最近では、Markus Voelter氏が「テキストDSL」に関する紹介をしています(参考記事・英語)。 

私たちのDSLは、エンティティとデータタイプを定義することができます。エンティティは「基底」としての資格を与えることが可能です。それは、別のエンティティの(集約かコンポジションのどちらかを使用している)関係のスコープ内でのみ参照されることが可能です。これは、DDDの中のバリューオブジェクトに相当します。もちろん、基底エンティティは異なるエンティティから参照することができます。

DSLは、エンティティ間の「関連」を指定します。これらの関連は、そのプロパティを指定しなければならないときに、エンティティのタイプを拡張することができます。

図2. エンタープライズデータモデルDSL(XTextの文法で定義)

このXtextの文法から、OpenArchitectureWareは、いくつかのEclipseプラグインを作っています。それは、この文法で規定されたシンタックスを使用しているモデルを編集し、コンフィギュレーションやデプロイのアーティファクトの中にそれらを変換することができます。

ある人は、このメタモデルがUMLプロファイルを使用して簡単に表現することができ、それらはおそらく正しいと主張するでしょう。しかし、UMLのメタモデルそれ自身の複雑さにより、UMLのクラス図(視覚的に表わされたエンタープライズデータモデル)からデプロイ生成物の変換をおこなうことを困難にしています。加えて、UMLプロファイルそれ自身は、それがエンティティ定義の中のクラスの範囲を表現するための特定の方法を提供していないので、かなり限定された価値を持っています。あなたは、その目的のために特別な表記を使用しなければならないでしょう。

さらに、全体的に、メタデータの版と管理の主要な形式としてグラフィカルな表現から離れる傾向があります。と同時に、XML表現から離れる傾向もあります。 Markus Voelter氏は自身のプレゼンの中で、人々がテキストのDSLを使用しない主な理由が、パーサーや、構文に敏感なエディタ(インテリセンスを含む)を作るための簡単な方法がなかったというだけの理由にあると主張しています。XTextにより、その文法や誰もが期待するリッチなエディタのエクスペリエンス(図3)を作成することが非常に簡単になります。

図3. EDM DSL(図2)をベースにしたEDMの例(図1より)

メッセージタイプのドメイン特化言語

エンタープライズデータモデルをメッセージタイプと関連づけるというアイデアは、新しいものではありません。たとえば、Mike Rosen氏他の書籍「Applied SOA(参考記事・英語)」では、次のように主張しています。(第3章):

情報は、組織のデータリソースを表しています。データは、多くの異なる記憶領域、アプリケーション、フォーマットで格納されます。データのさまざまなレベルは、さまざまなレベルのSOAの構成に使用されます。その意味情報のモデルは、ビジネスプロセスやサービスのためのデータを定義します。ドキュメント形式のビジネスプロセスに渡された情報は、意味情報のモデルをベースにしています。そのドキュメントは、プロセスとサービスの間の意味のあるメッセージ形式を提供します。SOAは、本来の操作可能なフォーマットからビジネスに必要とされる意味のあるデータへと変換するためのメカニズムを明らかにします。

問題は、私たちがどのようにしてこの関係を効果的に確立するか？(図4)ということです

図4. 私たちは、どのようにしてメッセージタイプの定義をエンタープライズデータモデルと関連づけるのか？

Michael Rosen氏他は、効果的なメッセージタイプを設計するために、EDM(それらは用語に意味のある情報モデルを使用します)に深く依存することを勧めています(「Applied SOA(参考記事・英語)」の6章、249ページ参照)。著者たちは、バックエンドのシステムや特定のプロジェクトの境界というより、そのインターフェースの範囲がエンタープライズデータモデルを念頭に置いて設計されるものとして、その核となる利点の一つが新しいコンシューマと既存のサービスプロバイダの互換性を強化することだと主張しています。しかし、著者らは、この問題を実行するための自動化された方法はもとより、この問題に取り組むためのモデルを提供していません。

当然ながら、初めの一歩は、先の段落で周知のとおりEDMのメタモデルを定義することです。

図5では、私たちのメッセージタイプのアーキテクチャについて説明しています。EDMのDSLとメッセージタイプのDSLを作成した後、私たちはメッセージタイプのスキーマとWSDLファイルを生成する状態になっています。結果として生じるスキーマは独立しています。そして、対応するWSDLファイルによってのみ参照されます。再利用がメッセージタイプ定義の中のEDMへの参照から来ているので、全ての種類のタイプや要素の再利用を達成するための複雑な取り込みの構造を作成する必要はありません。

図5. メッセージタイプアーキテクチャ

メッセージタイプDSLは、図6のようになります。このDSLの中心的な考え方は、EDMのDSL内のエンティティによって定められたスコープと相まった「Projection(射影)」要素です。そのエンティティのスコープは、大部分がメッセージタイプ、データベースのテーブル、クラス定義に関係のあるデータフィールドを定義するのに向いています。そのスコープ内の要素は「再利用」可能です。たとえば、ある基本的なエンティティである「アドレス」は、 EDMの中の別のエンティティで現れるかもしれません。これらのエンティティは、エンティティの射影から明確に「除外」された場合を除いて、メッセージタイプの定義の中で自動的に再利用されます。しかし、projectionの定義は、メッセージタイプの定義から全ての属性や基本的なエンティティを除外します。一方、ベースとなるエンティティと関連のあるエンティティのいくつかの属性や基本的なエンティティは、与えられたメッセージの一部であることがしばしば望まれます。サンプルの図1では、通常、groupIDが会員情報を表しているメッセージの一部です。このケースでは、projectionが基底のエンティティのスコープの外の要素を「含んで」いるかもしれません。そのモデルは、要素の内包もサポートしています。それは、projectionの構成によって、必ずしもベースとなるエンティティに直接関連するエンティティに属する必要はありません。

このアプローチは、メッセージタイプやXMLスキーマのレベルで、1対1や1対多の「関連」を管理しなければならない部分をとても楽にしてくれます。関連するエンティティの要素と属性は、メッセージタイプへ単純に「射影」されるからです。私たちが図4を例にとるならば、私たちのDSLはオーダーコレクションの要素が顧客の子要素であるといったXMLスキーマを生成するのに向いています。それぞれのオーダーは、出荷情報も含んでいるかもしれません。複雑な XMLスキーマをインポートした関連やXMLスキーマ内の参照をモデル化しなければならないので、一般的に、XMLスキーマでは失敗します。

多対多の関係(たとえば、オーダーと製品)は、EntityAreaの定義の中のdependencies要素で扱われます。その場合、XMLスキーマのジェネレーターは、メッセージ要素間の関連に関する適切な表現を保障するためのキーやキー参照要素を利用しなければなりません。しかし、この情報は、 XMLスキーマの時代からEDM定義によってもたらされるものなので、メッセージタイプのDSLの中でこれらの要素を管理する必要はありません。

そのメッセージタイプは、唯一のprojectionsを含んでいるかもしれません。つまり、エンティティへの参照、基本的なエンティティ、EDMの関連や属性です。EDMの一部でない要素を追加する準備はありません。本来ならばエンタープライズデータモデルに表わされて、レコードシステムとしてすべてのデータ要素が格納されなければならないので、これは設計時の判断となります。

図6. メッセージタイプDSL

メッセージタイプそれ自身は、以下で構成されます。:

• Verb (動詞。GET, NOTIFY, PATCH, CONFIRM, CANCEL, PREPARE, SUBMIT, SHOW, ANYがあります。図6のUniform InterfaceとVerbの定義を参照)
• Noun (名詞。基底となるエンティティ)
• メッセージ処理が冪等かどうか
• 3つの異なるタイプからなるペイロード

最初の3つの要素は、たとえばOpen Applications Group(OAG)によって定義されたものなど、メッセージのビジネスエンベロープを構成するのに使用されます。XMLスキーマが生成されると、エンベロープのすべての要素は、すべてのメッセージタイプの中に織り込まれます。これらの要素には、メッセージ識別子、送信情報、日付...が含まれます。

verb(動詞)は、 Open Applications GroupのverbとHTTP verbのサブセットです。CRUDのようなインタラクションでは、サービスコンシューマとサービスプロバイダの間で強い結合を作る傾向があるので、設計時点では、CRUDインターフェース定義を支援する傾向のあるPOST(OAGISの場合はPROCESS)、PUT、DELETEのverbを使用しないことを選択しました。

メッセージのペイロードは、3つの異なるタイプがあります(この場合も、Open Applications Groupの設計ガイドラインに従います):

a)  Query Area (Query-by-Example、-QBEとして表わされます。この場合のverbは、GETです)

b)  Event Area (もととなるエンティティの状態の発生を表します。NOTIFY verbによってイベントメッセージを発行します)

c)  Entity Area (その他すべてのverbの引数を表します)

図7. メッセージタイプ定義

PATCH verbは、Entity Areaで併用され、リクエスト－(変更)－更新パターンと結びつきます。このパターンは、.Netの世界のDateSetやJavaの世界の SDO(Service Data Object)で実装されています。このパターンは、基底のエンティティ(と関連する要素)の内容を変更することが目的である、ある種のヒューマンアクティビティを実装しなければならないBPMアプリケーションで非常に有用です。また一方で、アクション(それは基底のエンティティの状態変化のトリガーとなります)が呼び出されると、POSTのような一般的なものではなく、対応するverbを使用するように通知されます。提案されたメタモデルが変更内容をすぐに処理するわけではないということに注目することは重要です。しかし、ある人は変更概要のスキーマが適切なアルゴリズムによるエンティティ定義によって生成されたと考えるかもしれません。

PREPARE とSUBMITのverbは、統一インターフェースの中でエンタープライズを通して標準化する価値のあるもので、一般的に利用される動詞の例です。それは、購買オーダーといった特定のエンティティが「用意」されているインスタンスの一般的なものです。つまり、「送信」の準備ができるまでに生成・更新され、そのライフサイクルを開始します。そのような送信(あるいは、その事象に対する何らかのアクション)のためのレスポンスのverbは、「confirm」です。

CANCELのverbは、ビジネスエンティティのライフサイクルを終了することを指示する標準的なアクションのverbとして使用されます。

SHOWのverbは、レスポンスに使用されます。たとえば、GETリクエストのレスポンスに使用されます。

CONFIRM　verbは、アクションリクエストのレスポンスに使用されます。たとえば、SUBMITやCANCELリクエストに応答します。

これら2つの動詞(SHOWとCONFIRM)は、RESTには存在しません。何故なら、RESTはRPC指向であって、メッセージ指向ではないからです。 RESTでのレスポンスには、Atomコレクションの場合を除いて、特定のセマンティクスがありません。RESTでは、「技術上の」応答と「ビジネスの」応答の間に、何の区別もしません。 

このメッセージタイプのDSLは、すべてのメッセージタイプスキーマを生成するのに利用することができます。バージョン管理やビジネスエンベロープなど、ある面では対象となるスキーマのジェネレーター(図5)に織り込むことができます。ビジネスエンベロープは、情報を含んだエンベロープ内でメッセージペイロードをラップします。それは、インタラクションやインタラクションに関連する仲間やコンポーネントにとって適切です。例として、Open Applications Groupでは、そのために「BOD(Business Object Document)」を使用しています。私たちは、独自のSOAPヘッダを開発するよりも、このビジネスエンベロープパターンを使用することを強く勧めます。SOAPヘッダは、何らかのポリシーやサービスの品質(セキュリティ、信頼性、トランザクション...)を実装する必要のあるサービスコンテナによってのみ使用されるべきです。

あなたは、最後まで進めて、(バインディングやサービスのエンドポイントの無い)抽象的なWSDLの生成に利用することのできる、図8のようなサービスインターフェースのDSLを作りたいと思うかもしれません。

図8. 抽象的なWSDLの結果を生成するのにとても適しているサービスインターフェースDSL

XML スキーマがメッセージタイプの定義から生成される方法について、私たちはここで詳細を説明しません。この話題は、それ自身を説明した記事に譲ります。しかし、注意すべき重要な点として、メッセージタイプ生成のための私たちのアプローチは、いくつかの重要なことができるようになります。:

• 最初に、すべてのメッセージタイプXMLスキーマは、個々に生成することができます。これは、EDMで変更が発生したときに、私たちは (同じメッセージタイプの定義から)XMLスキーマの再生成を抜粋しておこなうことができることを意味しています。あなたは、それぞれのスキーマが生成したEDMのバージョンの足跡を追いたいかもしれません。複雑なXMLのインポートを利用する場合、そのインポートの一つの変更がすべてのメッセージタイプスキーマへと及びます。
• 第2に、私たちのアプローチは、サービスプロバイダとサービスコンシューマの間で「標準的なスキーマモデル」（CSM）を必要としません。CSMは、デフォルトで、(リクエストとレスポンスの)すべてのメッセージパスの中で2つの変換を強制しています。現代的なSOAでは、入力と出力のメッセージを変換することのできる「賢い」方法を提唱しています。メッセージが単一のバックエンドシステムによって「呼び出し」たり「呼び出され」たりするとき、それを標準的なフォーマットに変換する理由はありません。プロバイダのスキーマが何であれ、コンシューマ側でそれを変換するのは容易です。

Jack van Hoofの意見(リンク):

技術的な意味では、[標準的なスキーマモデル]は、エンドポイントでメッセージタイプ毎に一つの変換サービスだけを構成すれば良いという点でメリットがあります。サブスクライバは一つのメッセージタイプだけを気にすれば良く、複数のソースがあるかどうかを気にする必要はありません。

実際には、SOAやサービスプロバイダ/コンシューマパターンには当てはまりません。Jackの提言は、エンドポイントが実質的に記録のシステムだけである、同期/複製のシナリオで意味をなすものです。しかし、SOAの主な焦点は、新しいソリューションを構築する際に新たなレコードシステムを作ることをさけることで、まさに、同期/複製のパターンを避けることにあります。SOAは統合ではありません。しかし、統合によって技術を共有します。 SOAは、他の記録のシステムから情報を複製する必要性を確立することなく、新しいソリューションがこれらのサービスを利用することによって開発可能であるような、既存の記録のシステムをカプセル化するサービスを作ることです(図9)。 

サービス指向アーキテクチャでは、サービスインターフェースは、「その」一般的なモデルです(図9)。それは、サービスコンシューマをレコードシステムから分離します。サービスが十分に設計されていれば、すべてのコンシューマはその特定のサービスを呼び出し、そのサービスは、順番にそれに必要なバックエンドシステムを呼び出します。サービスインターフェースよりも上位の「標準的なスキーマモデル」を導入することは、私たちの余分な見解にあります。私たちは確かにこの議論に合意していて、それ故に、私たちのアプローチはEDMの定義からメッセージタイプを定義することをベースとしています。メッセージタイプの DSLは、EDMのセマンティクスからそれるために、いくらかの柔軟性を与えます。しかし、それは追加の作業を必要とします。デフォルトでは、それは、サービスインターフェース全体の首尾一貫したメッセージタイプを全体に提供するEDMのセマンティクスや構造を使用します。

そうは言っても、サービスコンシューマが異なるタイプのサービスと相互作用することはあまりありません。もちろん、これはB2Bや大きな組織で起こりえますが、それがサービスインターフェースを誤って設計したということを単純に意味するかもしれないということで、一般的に好ましくありません。

図9. 既存のレコードシステムで新しいソリューションをサポートしているサービス。この図は、サービスインターフェースの背後にある、それぞれのレコードシステムのエンティティの足跡を表しています。

CSMは、それが同じ「標準的な」スキーマに準拠するためにすべてのエンドポイントを「強制する」ものとして、多くのSOAのバージョンの原則(参考記事)に逆らっています。そして、適切なバージョニングの戦略なしでは、組織はコンシューマごとに通常一つのサービスインターフェースを作ることになるため、私たちが見てきたそれは適切ではありません。それ故、CSMの目的を無にします。(XMLやWSDLのような)SOAの技術は、90年代の統合プラットフォームのための重要なデザインパターンであるCSMに常に対応する必要性を軽減するために、実際に設計されたものです。しかし、結局、このパターンは契約が互換性のある方法 (参考記事)で設計できれば良いのに、変更の必要のないエンドポイントに余計な変更を広めてしまいました。

CSMから生じたいくつかの重要なメリットもあります。たとえば、Jack氏は次のように主張しています(リンク)。:

標準的なメッセージフォーマットを定めることで、ビジネスイベントについて利用可能なメッセージの明確なカタログを企業に提供する機会を与えます。そして、それは価値のあるビジネス資産を表します。

Nick Malik氏は、これを「ビジネスイベントオントロジー(リンク)」と呼んでいます。

この機能は、たとえば、ビジネスアクティビティのモニタリングや複雑なイベント処理に必要不可欠なものです。私たちは、メッセージタイプ定義の中で紹介したビジネスエンベロープの考えでそれを提供します。私たちのモデルでは、イベントとアクションが明確に表現され、メッセージペイロードの外の企業レベルで合意されます。

イベント駆動アーキテクチャは、あなたがサイロを統合したいときの適切なアーキテクチャです(つまり、自律した情報システムです)。しかし、EDAの原則は、一般的にSOAに適応しません。(状態の発生として定義された)イベントとメッセージイベントは、当然、サービス指向アーキテクチャの重要な部分です。しかし、EDAだけでは、コンポジットプログラミングモデルの基盤にはなりえません。

結論

サービス指向アーキテクチャでのメッセージタイプの管理は、複雑な話題です。OOのクラスや(DSLとして使用された)注釈のセットとして表現された「データの契約」を使用するために、複雑なXMLスキーマのインポート構造を作るのとは異なるアプローチを採用しました。エンタープライズデータモデルの基幹を欠いているので、そういったアプローチで十分な結果を与えるものはないように思われます。ここで説明したアプローチは、(コードではなく)「契約」の観点からサービスインターフェースの設計を開始する必要性を強化し、重要な企業資産としてEDMに見られる再利用の戦略を確立します。

私たちのアプローチは、データガバナンスとSOAガバナンスの間の相乗効果を表に出します。新しいサービスが見つかり、資金を供給され、それが実装されると、企業の足跡を持つメッセージタイプを設計するためにエンタープライズデータモデルに依存することは必要不可欠なことです。EDMを使わなければ、サービスインターフェースは、プロジェクトとバックエンドシステム固有の足跡で設計されることになり、別のコンシューマによって再利用される機会が低減します。さらに、そのアプローチは、データガバナンスによってエンタープライズデータモデルから、必要なときにサービスのライフサイクルの中の新しいバージョンの段階を与えるSOAガバナンスのチームへと、変更を効果的に伝えることを可能にします。 

著者は、本稿を寄稿するにあたり非常に刺激的な議論をしてくれたKjell-Sverre Jerijærvi氏とBoris Lublinsky氏に感謝の意を表します。