SOAとは何ですか?サービス指向 Archi構造原則

SOA は、さまざまなネットワーク上のソフトウェア コンポーネントが相互に連携しやすくするだけです。

SOA アーキテクチャに従って構築された Web サービスは、Web サービスの独立性を高める傾向があります。Web サービス自体は相互にデータを交換でき、その作成の基本原則により、人間による操作やコードの変更は一切必要ありません。これにより、ネットワーク上の Web サービスがシームレスに相互にやり取りできるようになります。

サービス指向 Archi構造 (SOA) 原則

SOA の設計原則には次の 9 種類があります。

1. 標準化されたサービス契約

サービスはサービスの説明に準拠します。 サービスには、そのサービスの内容を説明する何らかの説明が必要です。 これにより、クライアント アプリケーションはサービスの内容を理解しやすくなります。

2. 疎結合

Less 相互依存性。これは Web サービスの主な特徴の 1 つであり、Web サービスと Web サービスを呼び出すクライアント間の依存性をできるだけ少なくする必要があることを示しています。したがって、サービスの機能がいつ変更されても、クライアント アプリケーションが壊れたり、動作が停止したりすることはありません。

3. サービスの抽象化

サービスは、カプセル化したロジックを外部から隠します。 サービスは、その機能をどのように実行するかを公開すべきではありません。 クライアント アプリケーションに、それがどのように実行するかではなく、何を実行するかを伝える必要があります。

4. サービスの再利用性

ロジックは、再利用を最大化することを目的としてサービスに分割されています。 どの開発会社でも、再利用性は大きなテーマです。なぜなら、同じコードを必要とする複数のアプリケーションにわたって同じコードを何度も構築するのに時間と労力を費やしたくないのは明らかだからです。 したがって、Web サービスのコードを作成すると、さまざまな種類のアプリケーションで動作する機能が必要になります。

5. サービスの自律性

サービスは、カプセル化するロジックを制御できる必要があります。 サービスは、サービスが提供する機能についてすべてを知っているため、サービスに含まれるコードを完全に制御する必要もあります。

6. サービスのステートレス性

理想的には、サービスはステートレスである必要があります。 これは、サービスがある状態から別の状態に情報を差し控えるべきではないことを意味します。 これは、いずれかのクライアント アプリケーションから実行する必要があります。 例としては、ショッピング サイトでの注文が考えられます。 これで、特定の商品の価格を表示する Web サービスを利用できるようになりました。 ただし、商品がショッピング カートに追加され、Web ページが支払いを行うページに移動した場合、支払いページに転送される商品の価格について Web サービスが責任を負うべきではありません。 代わりに、Web アプリケーションによって実行する必要があります。

7. サービスの発見可能性

サービスは (通常はサービス レジストリ内で) 検出できます。 これについては、Web サービスに関する情報を保持できるレジストリを実行する UDDI の概念ですでに見てきました。

8. サービスの構成可能性

サービスは大きな問題を小さな問題に分割します。 アプリケーションのすべての機能を XNUMX つのサービスに組み込むのではなく、サービスを個別のビジネス機能を持つモジュールに分割してください。

9. サービスの相互運用性

サービスでは、多様な加入者がサービスを使用できる標準を使用する必要があります。 Web サービスでは、次のような標準が XML この原則に確実に準拠するために、HTTP 経由の通信が使用されます。