サービス指向設計の原則

サービス指向設計原則は、サービス指向アーキテクチャ（SOA）内でサービスのソリューションロジックを開発するための提案された原則です。^{[1] [2] [3]}

特定の設計パラダイムに基づくソフトウェア開発の成功は保証されません。サービス指向設計パラダイムに基づいて開発されたソフトウェアは、さらに大きなリスクを伴います。これは、サービス指向アーキテクチャが通常、複数のビジネス領域にまたがり、かなりの初期分析を必要とするためです。したがって、具体的なガイドラインなしに開発された SOA は失敗する可能性が非常に高くなります。^[4]サービス指向への移行が、約束されたメリットを実現する前向きな変化であることを保証するために、一連のルールを採用することが役立ちます。^[5]

サービス指向設計の原則は、トーマス・エルの「SOAサービス設計の原則」に従って、以下のように大まかに分類できます。^{[6] [7] [8]}

• 標準化されたサービス契約
• サービスの疎結合
• サービスの抽象化
• サービスの再利用性
• サービスの自律性
• サービスのステートレス性
• サービスの発見可能性
• サービスの構成可能性

これらの設計原則を適用することで、技術に依存しないサービスが生まれ、長期的には相互運用性が確保されます。^[9]これらの設計原則は、サービスを識別するためのガイドラインとして機能します。^[2]

これらの原則を適用することで、サービス指向の採用に結びついた根本的な目標を達成するのに役立ちます。これらの目標は本質的に戦略的なものであり、つまり長期的であり、組織の当面のニーズ^[10]を超えたものです。これらの戦略的目標は、次の7つの目標と利点に要約できます。^{[11] [12]}

• 本質的な相互運用性の向上
• 連邦化の強化
• ベンダーの多様化オプションの増加
• ビジネスとテクノロジーの連携強化
• ROIの向上
• 組織の俊敏性の向上
• IT負担の軽減

上記の目標と利点はそれぞれ、労力と時間を削減しながら、絶えず変化する市場の状況に迅速に対応できる アジャイル組織^{[13]の開発に直接役立ちます。}

サービス指向設計原則は、明確な設計特性を促進することで、サービス指向ソリューション^[14] を従来のオブジェクト指向ソリューションと区別するのに役立ちます。サービス指向ソリューションにこれらの特性が存在すると、前述の目標と利点を実現する可能性が大幅に高まります。Erlは、次の4つのサービス指向特性を特定しました。^[15]

• ベンダー中立
• ビジネス主導
• エンタープライズ中心
• 構成中心

ベンダー中立のサービス指向ソリューションは、絶えず変化するビジネス要件に応じて、基盤となるテクノロジー アーキテクチャを進化させるのに役立ちます。特定のベンダーに依存しないことで、ソリューション全体を最初から再設計する必要なく、老朽化し​​たインフラストラクチャをより効率的なテクノロジーに置き換えることができます。また、これは、特定のビジネス自動化要件が特定のテクノロジーによって満たされる異種テクノロジー環境の作成にも役立ちます。

SOA では、ソリューション ロジックの開発はビジネスのニーズに基づいて行われ、ビジネスの長期的な要件に重点を置いた方法で設計されます。その結果、テクノロジ アーキテクチャはビジネスのニーズとより一致するようになります。

従来のサイロベースのアプリケーション開発とは異なり、SOA では、企業全体または少なくともそのかなりの部分における要件が考慮されます。その結果、開発されたサービスは、企業のさまざまなセグメント間で相互運用可能かつ再利用可能になります。

サービス指向ソリューションでは、既存のサービスを利用して、短時間で新しい要件や変化する要件に対応できます。サービスは、再構成可能、つまり異なるソリューションの一部になるように設計されています。

サービス指向の設計原則は、サービス指向の分析および設計プロセス中に適用されます。これらの各原則を適用できる範囲は常に相対的であり、組織の全体的な目標と目的、および時間的制約に照らして検討する必要があります。留意すべき重要な要素の 1 つは、サービス指向の採用に関連するサービス指向の設計目標の実現を保証するのは、これらの設計原則の適用だけではなく、一貫した適用^[6]であるということです。これは、サービスがエンタープライズ リソースであるためです。つまり、特定の標準に準拠し、複数のソリューション内で再利用できるという確信が持てるためです。したがって、このようなリソースであり続けるためには、これらの原則が一貫して適用されたプロセスから生み出される必要があります。一貫性のない適用は、互いに互換性のないサービスをもたらし、基本的なサービス指向設計特性が失われることになります。

• サービス指向アーキテクチャ

• Mauro 他「サービス指向デバイス統合 - SOA 設計パターンの分析」[オンライン]、pp. 1–10、2010 43rd Hawaii International Conference on System Sciences、2010。アクセス日: 2010 年 4 月 8 日。
• Dennis Wisnosky.米国国防総省の原則とパターン[オンライン]。アクセス日: 2010 年 4 月 10 日。
• Ash Parikh.サービス指向が新たなマントラです![オンライン].アクセス日: 2010 年 4 月 10 日。
• Ertan Deniz.XML および XML Web サービス[オンライン].アクセス日: 2010 年 4 月 10 日。
• Nafise Fareghzadeh. SOA 開発へのサービス識別アプローチ[オンライン]。アクセス日: 2010 年 4 月 10 日。
• William Murray.SOA がビジネス戦略と組織設計に与える影響[オンライン].アクセス日: 2010 年 4 月 10 日。
• Diaconita 他「公共機関における 2 つの統合スタイル」[オンライン]。アクセス日: 2010 年 4 月 11 日。
• Fabian Meier.サービス指向アーキテクチャ成熟度モデル:SOA 導入ガイド?[オンライン].アクセス日: 2010 年 4 月 11 日。
• Moosavi 他著「サービス指向設計の方法」[オンライン]。アクセス日: 2010 年 4 月 11 日。
• Kjell-Sverre Jerijærvi.SOA 契約満期モデル[オンライン]。アクセス日: 2010 年 4 月 12 日。
• IBM Red Books.Power Systems と SOA Synergy[オンライン]。アクセス日: 2010 年 4 月 21 日。