2

Mule ESB 内で 3 つの (非常に) 異なるメッセージ形式を扱っているとします。それらを A、B、および C と呼びます。それらは XML (ソケット経由)、カスタム テキスト形式、および別の種類のメッセージを転送する SOAP である可能性があります。たとえば、XML (ソケットを介して転送されるものとは異なります)。それらはすべて互いに変換できます。A、B、C は同じ情報を運びますが、形式が異なります。

それらのそれぞれには、フロー内の独自のエントリ ポイント、いくつかの形式の検証などがあります。

しかし、いくつかの情報の処理/抽出、コンテンツに基づくルーティング、強化など、それらすべてで実行する必要があるいくつかの (多くの) ロジックがあります。

私は何をすべきか？つまり、統合パターンについて調査を行いましたが、この状況または類似のものについては何も見つかりませんでした。

より簡単なアプローチは、私の「メインフロー」の「デフォルト」としてフォーマットの1つ（Bを取りましょう）を取り、それに基づいてすべての共通ロジックを実装するように思えます。次に、到着するすべてのメッセージが B に変換され、2 つのポイントが同じ形式を使用している場合でも、目的の形式に再度変換されます。

例:

1) 1 つの「A」がアプリにヒットし、「B」に変換されて共通ロジックが実行され、再び「A」に変換されて配信されます。

2) 1 つの「C」がアプリにヒットし、「B」に変換されて共通ロジックが実行され、「A」に変換されて配信されます。

次に、私の質問は、Mule には、このようなことを行うためのより良い方法を提供する機能があるか、それとも上記の解決策が合理的に見えるかということです。

前もって感謝します。

4

1 に答える 1

3

オプションはいくつかありますが、いずれも Mule で実装できます。最初の2つは、あなたが提案したものに近いです。

ノーマライザー: http://eaipatterns.com/Normalizer.html

正規データ モデル: http://eaipatterns.com/CanonicalDataModel.html

回覧先: http://eaipatterns.com/RoutingTable.html

封筒: http://eaipatterns.com/EnvelopeWrapper.html

どちらを使用するかは、メッセージとその処理方法によって異なります。

たとえば、Canonical Data Model を使用すると、受信タイプごとに個別のフローを構築できます。

  • 独自の形式でオブジェクトを受け取ります。
  • そのオブジェクトを標準オブジェクトに変換します。
  • そのメッセージをメイン処理フローに渡します。

メイン フローは、そのオブジェクトの処理方法を知るだけで済みます。

元のオブジェクトを戻す必要があるエンドポイントは、変換を元に戻すことができるトランスフォーマーの背後に配置されます。

既存のオブジェクトの 1 つを選択し、メッセージ変数を使用して元の形式を記憶するか、元の型自体を記憶する新しいオブジェクトを作成できます。

于 2013-08-08T06:44:15.533 に答える