2

こんにちは、GregorHohpeとBobbyWoolfによるエンタープライズ統合パターンを経験しました。

http://www.eaipatterns.com/toc.html また、CamelとMuleがこれらの統合パターンに準拠していることも確認しました-

http://www.mulesoft.org/documentation/display/current/Understanding+Enterprise+Integration+Patterns+Using+Mule

http://camel.apache.org/enterprise-integration-patterns.html

MuleとCamelの両方で、SOAPやRESTなどのWebサービスを介してアプリケーションをデプロイおよびアクセスできるようになっています。SOAPはよりRPCスタイルです。これらは、CXFやJerseyなどのオープンソースユーティリティを使用した大規模な統合サポートを可能にします。実際、MuleはRMIエンドポイントもサポートしています。これにより、リモートメソッド呼び出し機能も提供されます。これは、広く受け入れられている統合形式です。ESBは他のプロトコルの追加サポートを備えたメッセージバスを中心に構築されていることを理解していますが、ESBはEIPにのみ準拠しており、EIPはESBだけではありません。

質問は、SOAP / RESTまたはそれらのトランスポートプロトコルが「統合スタイル」と見なされない理由であり、エンタープライズ統合であるため「メッセージ指向」であるのはなぜですか？

私はこれらのパターンを設計した偉大な頭脳と比較して初心者ですが、統合パターンの偏ったメッセージのような性質を理解しようとしています。スタックオーバーフローのQnA形式ではないことは認めますが、人々が意見を共有できるように、Modにしばらくの間それを存続させるように要求します。

4

1 に答える 1

1

SOAPについては、SOAPが実際に実装するものとほぼ同じであるため、統合スタイルの「リモートプロシージャコール」に分類されます（ここでは、RPCとメッセージングを混在させる可能性のあるSOAP over JMSハイブリッドについては考慮しません）。 。

RESTは、インターフェース的には、サービス駆動型ではなくリソース駆動型であるという点で、SOAPとは大きく異なります。これは同期RPC呼び出しの単なる別の形式であるため、「RPC」スタイルでグループ化することは少なくありません。

ただし、特定のメッセージパターンが実装するEIP統合スタイルの理論にはあまり力を入れません。

代わりに、手元にある特定のシナリオを見て、EIPを使用して特定の統合をモデル化します。

実際に実装されたRPCパターンまたは実際にメッセージングを実装したSOAPサービスのファイル転送の統合を見てきました（ただし、これを行うことはお勧めしません）。

具体的な例：専用のファイルアップロードサービスの使用法を考えてみましょう。このサービスは、SOAP技術を使用して構築されており、CSVファイルをサーバー上のファイル領域にアップロードし、そこから他のシステムによって取得されます。私はこのファイルベースの統合を高レベルで呼びます。

もう1つの例は、メッセージングシステムが共有データベースを使用して実装される場合があることです。それでも、それらを使用する統合スタイルは、「共有データベース」ではなくメッセージングです。

統合が高レベルでどのように機能するかを考えてから、さまざまなプロトコルを適用してうなり声を上げます。

于 2013-03-04T15:57:34.210 に答える