標準化されたサービス契約は、サービス指向設計パラダイムに適用されるソフトウェア設計原則[1]であり、サービスインベントリ[3] （エンタープライズまたはドメイン）内のサービス契約[2]が同じ設計標準セットに準拠することを保証します。[4]これにより、サービスインベントリ全体で標準化されたサービス契約が容易になります。[5]
目的
サービス指向アーキテクチャ（SOA）が約束するアジリティは、通常、そこに含まれるサービスの再利用性のレベルによって測定されます。しかし、この再利用性は、サービスコントラクトがサービスの機能をどのように定義するかに直接関係しています。再利用性を持つ可能性のある機能コンテキスト[6]上に構築されたサービスであっても、この再利用性を正しく伝えていないコントラクトを持つサービスは、その再利用性を十分に発揮できません。
サービス指向ソリューションにおいて、サービスコントラクトは基本的なアーティファクトです。これは、サービスが互いに、あるいは他のコンシューマプログラムとやり取りする唯一の媒体だからです。そのため、サービスの再利用性と再構成性を最大限に高めるためには、サービスコントラクトを標準化することが強く求められます。これを実現するためには、標準化されたサービスコントラクト設計原則を適用する必要があります。この原則を適用することで、サービスインベントリ内に設定された設計標準[7]に基づいた標準化されたサービスコントラクトが実現します。
このデザインパターンの目標の一つは、2つのサービスが相互に作用する際にデータ変換の必要性を減らすことです。これは、サービスがWebサービスとして実装されている場合、サービスコントラクトが標準化されたデータモデル（例えばXMLスキーマ）を使用することで実現できます。これはまた、サービスの相互運用性を高めることにも役立ちます。このデザインパターンのもう一つの重要な目標は、サービス機能の表現に標準化された方法を用いることで、設計時にその目的と能力を容易に理解できるようにすることです。[8]
応用
技術サービス契約[9]は通常、WSDL文書、XMLスキーマ、およびポリシー文書で構成されます。したがって、この原則は、以下に説明するように、サービス契約の3つの領域に適用する必要があります。
機能表現の標準化
サービスの操作は、標準化された命名規則を用いて定義する必要があります。これは、構成要素となる入力メッセージと出力メッセージの名前、そしてそれらに対応する型名にも適用されます。これにより、サービスコントラクトの正確な解釈が向上し、サービスの再利用性と相互運用性が向上します。サービスコントラクトがその機能を明確に表現することで、サービスの重複の可能性も低減されます。
データモデルの標準化
同じ種類のデータ（例えば、注文書）に基づいてメッセージを交換する2つのサービスが、異なるスキーマに従ってデータをモデル化している場合、データモデルの変換が必要になります。これは明らかにオーバーヘッドを増加させ、サービスの相互運用性と再利用性を阻害します。この変換を回避するために、標準化されたサービス契約の原則では標準化されたデータモデルが必須であり、これにより、標準化されたサービス機能を定義するために企業全体で再利用できる標準化されたデータ表現アーキテクチャの構築がさらに容易になります。スキーマの集中化は、データモデル標準化[10]設計パターンの目的を直接的にサポートし、集中管理されたスキーマの作成をさらにサポートします。
ポリシーの標準化
サービスポリシーは、サービスの利用規約を表します。したがって、サービスを再利用可能にするには、その動作要件を業界標準の語彙に基づく標準化されたポリシー表現を用いて一貫して表現する必要があります。このような標準化により、ポリシーをサービス契約から個別のポリシー文書に分離することがさらに促進され、集中的なガバナンスが促進されます。場合によっては、2つのポリシーが構文的には異なっていても、同じ意味を持つことがあります。そのため、設計標準によって許容されるポリシー構造が規定される必要があります。
考慮事項
この設計原則の適用は、サービスインベントリレベルの設計標準に依存します。これには、時間と労力という点で追加のリソースが必要です。第二に、この設計原則を効果的に適用するには、実際の契約をサービスロジックおよび実装から物理的に分離し、業界標準に基づくようにする必要があります。これは、分離契約[11]設計パターンを適用することで実現できます。また、「契約優先」アプローチに従い、基盤となるロジックが標準化されたデータモデルのみを使用するようにする必要があります。さらに、集中型データモデルの要件は、サービス間で冗長なデータが送信されることにつながる可能性があります。これは、サービスに必要な実際のデータが、サービスに課せられた標準化されたスキーマで定義されたデータのサブセットのみである可能性があるためです。
参考文献
- ^ “Design Principle”. 2010年4月29日時点のオリジナルよりアーカイブ。2010年3月7日閲覧。
- ^ 「サービス契約」。2012年5月1日時点のオリジナルよりアーカイブ。2010年3月9日閲覧。
- ^ “Service Inventory”. 2010年3月13日時点のオリジナルよりアーカイブ。2010年3月9日閲覧。
- ^ Cellary, Wojciech; Strykowski, Sergiusz. 「クラウドコンピューティングとサービス指向アーキテクチャに基づく電子政府」.第3回電子政府理論と実践国際会議議事録. ICEGOV '09. pp. 5– 10. doi :10.1145/1693042.1693045. ISBN 978-1-60558-663-2。
- ^ Michael Poulin. サービス指向の原則の進化: サービス コントラクト、パート 2 Archived 2011-09-29 at the Wayback Machine . アクセス日: 2010 年 4 月 12 日。
- ^ サービスの境界、つまりサービスが提供する機能の種類
- ^ Tost 他「Web サービス コントラクト テクノロジの使用に関するガイドライン」、Wayback Machineに 2012 年 10 月 3 日にアーカイブ。アクセス日: 2010 年 4 月 12 日。
- ^ kou-Kai Lin. 小規模移行のためのサービス指向移行に関する予備的研究. 2011年8月15日アーカイブ.アクセス日: 2010年4月10日.
- ^ サービスは通常 Web サービスとして実装されるため、この記事では Web サービスのコンテキスト内でのこの設計原則の適用に焦点を当てます。
- ^ 「スキーマ集中化パターン」。2010年2月11日時点のオリジナルよりアーカイブ。2010年2月18日閲覧。
- ^ 「Decoupled Contract Pattern」。2010年2月13日時点のオリジナルよりアーカイブ。2010年2月18日閲覧。
- Mauro 他「サービス指向デバイス統合 - SOA 設計パターンの分析」pp. 1–10、2010 年 43 回ハワイ国際システム科学会議、2010 年。アクセス日: 2010 年 4 月 8 日。
- エルル、トーマス（2008年）『SOAサービス設計の原則』プレンティス・ホール、ISBN 978-0-13-234482-1。
- Paul-Alexandru Istoan.ソフトウェア製品ラインとサービス指向アーキテクチャ: これらは接続できますか?アクセス日: 2010 年 4 月 10 日。
- Youssef Achbany.適応型でオープンなサービス システムを開発するためのマルチエージェント フレームワーク。アクセス日: 2010 年 4 月 10 日。
- Kjell-Sverre Jerijærvi.SOA 契約成熟度モデル。アクセス日: 2010 年 4 月 12 日。
外部リンク
- SOAの概念
- SOA用語集
