web-dev-qa-db-ja.com

SOAはRESTで設計できますか？

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

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

architecturesoa
28
vinnylinux

高レベルでは、答えは「はい」ですが、完全ではありません。

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

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

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

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

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

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

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

このリソースもご覧ください- From SOA to REST

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

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

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

  • addItem
  • addTax
  • calculateTotal
  • placeOrder

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

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

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

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

24
Padmarag

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

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

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

6
mikalai

SOA=について最も重要なことは、他の人にあなたのサービスを利用させたり、その逆を利用したりするために、使いやすいプロキシを構築できるwsdlリンクを用意することです。 。サービスは構成可能である必要があります..ただし、これを行うためにOrchestration、BPEL、またはファンシーバスは必要ありません。SOAを使用する場合は推奨しません（実際にこれらを使用した場合は、より良い結果が得られると思いますそれらが、あなたはイベントが必要です）

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

SOAPは、8年間の高パフォーマンスの構築に行くSOAシステムは、私が気付いたことがないSOAPそこにあるのは、私が主にC＃で作業していて、SOAPスタックがあるからです。他のほとんどの言語ではできません。

2
user1496062