SOA結合の７つの側面

作者 Udi Dahan , 翻訳者 編集部 投稿日 2007年12月11日

セクション

エンタープライズ・アーキテクチャ

トピック

XMLスキーマ ,

Markup Languages ,

ポリシー ,

言語 ,

SOA ,

Architecture ,

プログラミング ,

エンタープライズアーキテクチャ ,

セキュリティ ,

クラウドコンピューティング

共有 |

SOAアナリストファームでシニアアナリストを努めるRon Schmelzer氏は、”完全なる疎結合はもし可能であれば驚くほど困難で高額なものである。”と述べている。最近の掲載記事(source)でSchmelzer氏はシステムは疎結合であるか、もしくはそうではないという信念を問うている。疎結合の重要性はしばらくの間周知のものであった(source)が、この記事にまつわる話題はいくつ か興味深いディスカッションへと発展した。

Schmelzer氏が解説した疎結合の７つの側面には下記のものが含まれている。

1. 実装
2. サービスコントラクト
3. サービスポリシー
4. プロセス
5. データスキーマ
6. インフラストラクチャ
7. セマンティックレイヤー

こうしろと言わんばかりにそのレポートは実装疎結合に関して述べていた。

全てのSOA実装は少なくとも実装レベルで疎結合されてなくてはいけないのだが、明らかにこれはビジネスが望んだ完全なる疎結合の一種を保障するのには十分ではないのだ。

Service ContractはService Description Framework(サイト・英語)の使用における利点を言及している。

Service Description Framework(SDF)はテクノロジニュートラルなサービスコントラクトテンプレートの一つである。これらのアプローチの中で新たなサービスコントラクトは単純に古いものを置き換えたりしない。古いコントラクトはトランジションパスがサービスコンシューマ用に提供されていない限り、廃止される予定がないのである。

この遅延結合問題もまた取り上げられていた。

（多分）この領域でのベストプラクティスは、特定のサービスコンシューマのバインディングを抽象化し、サービスコントラクトの変化が広まるのを防ぐためにランタイムレジストリとコントラクトベースのバインディングを活用する遅延バインディングアプローチの使用である。

Anil John氏(ブログ・英語)はこの点に関する疑問(サイト・英語)をあらわにした。

私達はWebサービススタック全体でのシームレスインタオペラビリティの問題を解決するまで（元々XMLからObjectへのデータバインディング問題から発生した）、動的なクライアントサイドのプロキシ実装とジェネレーションに関わるコンシューマによるサービスへのランタイムバインディングは、Vision Quest（賭け）以外の何者でもない！ランタイムレジストリとコントラクトベースのバインディングを利用する現在の環境において動作するただ一つのランタイムアプローチは、先天的なインタオペラビリティテストが可能性のあるプロデューサーとコンシューマWebサービスコード間で行われた時にのみ、異なるSOAPエンドポイント（レジストリに対するランタイムルックアップから来る）への動的バインディングに制限される。

そのレポートはサービスポリシーを下記のようにサービスコントラクトに結び付けている。

サービスの変動性を提示しようとしている会社は、サービスコントラクトへの変更に対応するのと同じやり方でポリシーへの変更に対応するべきである。遅延バインディング、サービス仲介が可能にされ、レジストリベース、そして統治されたものである。

ビジネスプロセスは同じように対応される。

メタデータ内でプロセスを定義し、これらのプロセスをサービスコントラクト（サービスのサービスプロセスコンポーズであり、サービスとして表示される再帰的なビジョン）を使用することによって、サービスコンシューマからプロセスの実装を抽象化する。

データスキーマは最初に異なる扱われ方をすると説明されている。

スキーマはサービスデータオペラビリティへのキーである。しかしながらスキーマが変更した時は何が起こるだろうか？一つのキーとなるアプローチはあなたがサービスメタデータマネジメントにアプローチするのと同じやりかたでスキーママネジメントと情報を提示することである。データスキーマはメタデータの形態として扱うこともでき、例外マネジメントの使用、トランスフォーム、サービスインターミディエート、そしてデータサービスは全てデータストラクチャの疎結合を可能にするキーなのである。

それでもまだサービスコントラクトに結び戻される。”スキーマとサービスコントラクトは同様なのである。”

またそのレポートはインフラストラクチャの観点からの疎結合を定義するのが簡単である一方、この種の柔軟性を実現するベンダーはほとんどないのである。

これは、どんな時でも会社は全てのサービスコンシューマとプロバイダを再構築する必要なしにインフラストラクチャを変更することができるという事を意味している。

最終的なソリューションが意味論レベルで解説されている。動的サービス定義：”サービスインターフェースの定義はサービスリクエスターのコンテキストに基づいて変更されなければならない。結果としてサービスは呼び出し間においてそのコントラクトを変更することができる。” このシンタックスの緩まりはRESTモデルと上手く働くように見えるが、しかしながらWSスタンダードへの統合は現在の時点でまだ知られていない。

Nicholas Gall氏(ブログ・英語)は彼の分析(source)において疎結合に関してもう一つの側面を付け加えている。

このリストは疎結合において一番重要な側面を忘れている。普遍性である。もし私とただもう一人のパートナーが世界で一番の動的再設定可能ミドルウェア アーキテクチャを構築したら、彼と私はお互い密に結合しているということになるでしょう。二人が WS-*の独自のカスタムバリエーションを夢見ることを想像してみてください。それをWS-Siloと呼びましょう。そして二人の間で、私達は片側でイ ンターフェースにいろいろな種類の粋な変更を施すことができるのです。でも他のだれとも内部動作することはできないのです。

疎結合がどのように成されるかという仕様において大筋での一致はない一方、そのゴールは世論の中にすっぽり収まる事であるように思える。それらをそれぞれ独立的に変更してシステムを変更することによってコストの削減をするということなのである。

原文はこちらです：http://www.infoq.com/news/2007/12/7-levels-loose-coupling