30

最近、SOAについて多くのことを読んでいますが、ほとんどのコンテンツはSOAP関連であり、C＃/Javaシステムに属する「官僚的な」ものがたくさんあります。正直なところ、そのような官僚主義、特にSOAPはお尻の痛みだと思います。それで、私は興味があります、SOAはRESTで設計できますか？

現在、Rubyアプリケーションでは、すべてのコントローラーをRESTfulにしています。私のWebインターフェース（フォームなど）は、RESTWebサービスであるコアに対してGET/ POST / PUT/DELETE要求を行います。コアを使用する他のすべてのシステムは、コアに対してRESTfulリクエストを行います。これはSOAですか？

4

3 に答える 3

32

大まかに言えば、答えは「はい」ですが、完全ではありません。

SOAでは、システムについて次の観点から考える必要があります。

  • サービス（明確に定義されたビジネス機能）
  • コンポーネント（個別のコードおよび/またはデータ構造）
  • プロセス（サービスオーケストレーション。通常はBPELを使用）

新しい高レベルのサービスまたはビジネスプロセスを構成できることは、優れたSOAの基本的な機能です。XML、SOAPベースのWebサービス、および関連する標準は、SOAの実現に最適です。

また、SOAにはいくつかの受け入れられた原則があります-http://en.wikipedia.org/wiki/Service-oriented_architecture#Principles

  • 標準化されたサービス契約–サービスは、1つ以上のサービス記述文書によって集合的に定義されている通信契約に準拠しています。
  • サービスの緩い結合–サービスは、依存関係を最小限に抑え、相互の認識を維持することだけを要求する関係を維持します。
  • サービスの抽象化–サービス契約の説明を超えて、サービスはロジックを外界から隠します。
  • サービスの再利用性–ロジックは、再利用を促進することを目的としてサービスに分割されます。
  • サービスの自律性–サービスはカプセル化するロジックを制御できます。
  • サービスの粒度–サービス運用におけるビジネス機能の最適な範囲と適切な粒度レベルを提供するための設計上の考慮事項。
  • サービスのステートレス性-サービスは、必要に応じて状態情報の管理を延期することにより、リソース消費を最小限に抑えます
  • サービスの発見可能性–サービスは、効果的に発見および解釈できる通信メタデータで補完されます。
  • サービスの構成可能性–構成のサイズや複雑さに関係なく、サービスは効果的な構成の参加者です。

SOAベースのアーキテクチャには、サービス定義が必要です。RESTful Webサービスには明確なサービス定義（wsdlと同様）がないため、RESTベースのシステムが上記の原則のほとんどを満たすことは困難です。

RESTを使用して同じことを実現するには、RESTful Webサービス+オーケストレーション（MuleESBやCamelなどの軽量ESBを使用する可能性があります）が必要です。

このリソースも参照してください-SOAからRESTへ

以下のコメントの説明としてこの部分を追加します-

プロセスを構成するには、オーケストレーションが必要です。それがSOAの主な利点を提供するものです。

次のような操作を行う注文処理アプリケーションがあるとします。

  • addItem
  • addTax
  • 計算合計
  • placeOrder

最初に、これらの操作を順番に使用するプロセスを（BPELを使用して）作成しました。この構成されたサービスを使用するクライアントがあります。数か月後、免税の新しいクライアントが来て、新しいサービスを作成する代わりに、addTax操作をスキップして新しいプロセスを作成することができます。したがって、既存のサービスを再利用するだけで、ビジネス機能のより迅速な実現を実現できます。実際には、そのようなサービスは複数あります。

したがって、BPELまたは同様の（ESBまたはルーティング）テクノロジーはSOAに不可欠です。ビジネスでの使用がなければ、SOAは実際にはSOAではありません。

私の個人ブログにクロス投稿-http://blog.padmarag.com

私が出会ったこの新しいリソースもチェックしてください-RESTベースのSOA

于 2012-05-08T08:27:53.963 に答える
7

SOA用語でのサービスは、特定のビジネス上の問題を解決するコンポーネントです。SOAP / WCFは、SOAのインターフェース/配信部分とより関連性があります。RESTアプローチも使用できます。サービスコントラクト、ポリシー、バージョン管理、およびその他の「標準」SOA機能もRESTfulサービスで実装できます。

RESTfulの主な問題は、CRUDを対象としているため、複雑なロジックの実装には最適ではないということです。ただし、ビジネスロジックが完全にCRUDである（またはCRUDに収束する）場合は、問題ないはずです。

ところで、MicrosoftはRESTでSOAPをエミュレートするために特別にWCFデータサービスに操作を追加したようです。

于 2012-05-08T07:36:33.437 に答える
3

SOAで最も重要なことは、ソフトな要素です。たとえば、他の人にサービスを使用させたり、その逆を行ったりするために、使いやすいプロキシを構築できるwsdlリンクを用意することがほぼ不可欠です。サービスは構成可能である必要があります..しかし、これを行うためにオーケストレーション、BPEL、または豪華なバスは必要ありません。SOAを開始するときにそれらをお勧めしません。（実際、これらを使用したことで、これらがなくてもより良い結果が得られると思いますが、イベントが必要です）

WCFのような製品では、wsdlを公開するサービスを作成できますが、SOAPの他に、REST / JSONまたはさらに優れたバイナリTCPエンドポイントを使用することもできます。これは、単純化のためにSOAPを使用し、バイナリに切り替えるために理想的です（必要に応じて、水から出してください）。

SOAPがWCFを使用して高性能SOAシステムを構築して8年になる限り、SOAPがそこにあることに気づいたことはありません。それは私が主にC＃で作業し、優れたSOAPスタックを持っているためです。他のほとんどの言語はそうではありません。

于 2013-07-09T10:19:15.647 に答える