標準的なプロトコルパターン

標準プロトコルは、サービス指向設計パラダイム内で適用される設計パターンであり、サービスで使用される通信プロトコルを標準化することで、サービスインベントリ内のサービスを相互運用可能にすることを試みます。 ^[1 ]これにより、サービスが異なる通信プロトコルを使用する場合に、通信プロトコルをブリッジする必要がなくなります。^[2]

根拠

異なるプロジェクトチームによって開発されたサービスは、異なる通信メカニズムに基づいている可能性があります。その結果、サービスインベントリには、それぞれ異なるプロトコルセットに準拠する異なるサービスセットが含まれる可能性があります。異なる通信プロトコルを持つサービスを再利用する場合、何らかの通信ブリッジングメカニズムが必要です。たとえば、JMSメッセージングプロトコルを使用して開発されたサービスは、 .NET Remoting を使用するサービスと互換性がないため、これら 2 種類のサービスを利用するには、通信プロトコルの不一致を埋めるミドルウェアテクノロジを導入する必要があります。余分なコストが発生するだけでなく、このようなブリッジングテクノロジを使用すると、遅延と通信のオーバーヘッドが増加します。これにより、サービスの再利用性が低下し、構成が難しくなり^{[3] 、}サービス構成可能性設計原則のガイドラインに反します。

すべてのサービスが相互運用可能で、さまざまなソリューションに構成できるサービスインベントリを設計するには、標準プロトコルパターンを適用して、サービスで使用される通信プロトコルを標準化する必要があります。すべてのサービスが同じ通信プロトコルを使用すると、ブリッジングテクノロジの必要性がなくなり、サービス間の通信がより合理化されます。^[4]

使用法

この設計パターンを適用するには、共通の通信フレームワークを提供するテクノロジアーキテクチャを選択する必要があります。これにより、インベントリ内のすべてのサービスが同じ通信プロトコルを使用して相互に通信できるようになります。これは、サービスインベントリ内のサービスがどのように使用されるかによって異なります。サービスが、常に特定の通信プロトコルを使用するサービスコンポジションの一部になるだけの場合 (効率とセキュリティ上の理由から)、そのサービスインベントリ内のすべてのサービスは、最も広く使用されているプロトコルでなくても、そのような通信プロトコルに基づいて構築できます。

Thomas Erlによる Canonical Protocol パターンは、「プロトコルブリッジングを回避するためにサービスをどのように設計できるか」という疑問に答えています。 ^[5]問題は、異なる通信テクノロジをサポートするサービスでは相互運用性が損なわれ、潜在的な消費者の数が制限され、望ましくないプロトコルブリッジング対策が必要になることです。この解決策は、サービスが対話できる唯一のまたは主要な媒体として、アーキテクチャで単一の通信テクノロジを確立することです。したがって、サービスインベントリ境界内で使用される通信プロトコル (プロトコルバージョンを含む) は、すべてのサービスに対して標準化されます (図を参照)。

最も成熟し、広く使用されている通信メカニズムの 1 つは、Web サービスフレームワークによって提供されます。通信フレームワークの選択に加えて、実際のメッセージプロトコルも標準化する必要があります。たとえば、Web サービスをHTTP経由のSOAP を使用して構築するか、単にRESTfulサービスを使用して構築するかなどです。同様に、SOAP ベースの Web サービスを標準化する場合、SOAP プロトコルの特定のバージョン (SOAP v 1.1 または SOAP v 1.2) についても合意する必要があります。

考慮事項

通信プロトコルを標準化するには、プロトコルの機能を、セキュリティ、効率、トランザクションサポートなどのサービス相互作用要件と比較する必要があります。たとえば、Web サービスの場合、サービス構成に明示的なトランザクションサポートが必要な場合は、RESTful サービスを使用するよりも、HTTP 経由の SOAP の方が適しています。

場合によっては、サービスの構築に使用されるテクノロジに応じて、異なるタイプのサービス消費者がサービスにアクセスできるようにするために、2つの異なるプロトコルセットをサポートできる場合があります（デュアルプロトコル設計パターン^[6]）。たとえば、WCFを使用すると、同じサービスがHTTPプロトコルとTCP/IPプロトコルを同時に使用するように構成できます。

通信フレームワークを選択する際には、成熟度、スケーラビリティ、ライセンスコストを考慮する必要があります。近い将来に廃止されるプロトコルを使用してサービスを構築すると、サービスの再利用性に影響し、サービスを再設計するためにかなりの時間と労力が必要になるためです。

参考文献

注記

^ サービスインベントリ 2010年3月13日アーカイブ、Wayback Machine
^ Matthew Dailey.ソフトウェアアーキテクチャ設計サービス指向アーキテクチャ (パート II) Archived 2011-07-24 at the Wayback Machine [Online].アクセス日: 2010 年 4 月 25 日。
^ サービス構成 2010年3月11日アーカイブ、Wayback Machine
^ Mauro. et al. サービス指向デバイス統合 - SOA 設計パターンの分析。[オンライン]、pp.1-10、2010 43rd Hawaii International Conference on System Sciences、2010。アクセス日: 2010 年 4 月 30 日。2010 年 3 月 28 日にWayback Machineにアーカイブされました。
^ SOA パターン - 標準プロトコル 2009 年 12 月 14 日にWayback Machineにアーカイブされました
^ デュアルプロトコル設計パターン 2009年12月14日アーカイブ、Wayback Machine

出典

Thomas Erl他 (2009)「SOA デザインパターン」Prentice Hall。ISBN 978-0-13-613516-6 。

外部リンク

SOAの概念
SOA用語集
SOA デザインパターン

[SI-1] サービスインベントリ 2010年3月13日アーカイブ、Wayback Machine

[MD-2] Matthew Dailey.ソフトウェアアーキテクチャ設計サービス指向アーキテクチャ (パート II) Archived 2011-07-24 at the Wayback Machine [Online].アクセス日: 2010 年 4 月 25 日。

[SvcComposition-3] サービス構成 2010年3月11日アーカイブ、Wayback Machine

[SODI-4] Mauro. et al. サービス指向デバイス統合 - SOA 設計パターンの分析。[オンライン]、pp.1-10、2010 43rd Hawaii International Conference on System Sciences、2010。アクセス日: 2010 年 4 月 30 日。2010 年 3 月 28 日にWayback Machineにアーカイブされました。

[SOA_Patterns.org-5] SOA パターン - 標準プロトコル 2009 年 12 月 14 日にWayback Machineにアーカイブされました

[DP-6] デュアルプロトコル設計パターン 2009年12月14日アーカイブ、Wayback Machine