0

いくつかのアーキテクチャ設計について、SOA/ESB の専門家に助けを求めています。質問があまり明確でない場合はお詫び申し上げます。

現在、P2P 通信や大量のコード ブロックを使用しているビジネス ケースがいくつかあります。

       if(...)
               Update System 1
               Then Update System 2
               Then Update System 3
       Else If (...)
                Update System 1 in a different Way
                 Don't Update 2 at all
                 Update 3 but differently

現在、定型コードとデータベース更新コードがあちこちにあります。おもしろいことに、私たちは 1 つのクライアント向けインターフェイスから始めて、さらに追加を続け、コード全体を複製し続けることで「迅速な成果」を上げました。小さな変更が必要になったとき、それは途方もない作業になりました。

これは典型的な ESB タイプのケースであり、そのようなシナリオに対応するためにトピック - パブリッシュ - サブスクライブ モデルを採用することを考えています。参加しているすべてのクライアントがトピックにメッセージを発行できるように、必要なときにいつでもどこでもサブスクライバーをフックするだけです。すべてのデータベースまたはシステム更新コードは汎用であり、単一のクラスター化された展開になります。

ただし、すべてのシステムでデータを更新する必要があるとします。たとえば、1 人のサブスクライバーで更新が失敗した場合、他のシステムで更新をロールバックするか、少なくとも失敗した場所の監査を維持する必要があります。上記を達成するための最良のアプローチは何ですか？使用できる標準ツール/ユーティリティはありますか?

参考までに - Java テクノロジと Mule ESB を使用しており、その可能性を最大限に活用したいと考えています。前もって感謝します。もっと明確にする必要がある場合はお知らせください

4

1 に答える 1

0

トピックの使用は、サービスを結び付ける非常に強力な方法です。これは私が嵯峨と呼んでいるパターンです。コンテキストに応じて同じイベントを異なる受信者にルーティングする必要がある場合があるため、トピックの設計がイベントとコンテキストの両方を伝える必要があることを確認する必要があります (そのため、トピックは context.evetnType のように見え、サブスクライバーはすべてのタイプのイベント (*.eventType) または特定のコンテキストのみ)

この動作をサービスから外部化するもう 1 つの代替手段は、オーケストレーションを使用することです。オーケストレーションにより、事前定義されたビジネス プロセスを簡単に確認および監視できますが、セレンディピティとある程度の柔軟性が犠牲になります (対サガ)。また、ナノサービスを促進することもできます

于 2012-10-23T20:07:49.080 に答える