0
私はクリーンなSOAの方法では解決できないような実生活のSOA問題を抱えています。SOA/SEDA - サイクリックアーキテクチャ
私は、「物事管理者」によって消費される「更新物」メッセージの多くの分散生産者を持っています。
「物事管理者」の特徴の1つは、「物」が変更されたというトピック通知を公開することです。これにより、他の関心のあるサービスが変更に対応できるようになります。
「アップデートするもの」プロデューサの1つは、それ自体、トピックのリスナーです。それは他のシステムからの「物事の更新」だけに本当に興味があります。しかし、それはそれ自体が最初に（それゆえに既に知っている）原因となった「事柄マネージャー」からのアップデートを消費し処理していることがわかります。幸いにも、フィードバックループはその時点で壊れています。
この問題をクリーンなSOAの方法で解決するにはどうすればよいですか？私はメッセージソースに清潔な解決策を示すメタデータを追加するクラスを作成しません。メッセージの消費者は、メッセージがどこから来たのか、どこに行くのかを知る必要はありません。
ありがとうKevin - データの性質は原点に関係なく同じです。したがって、選択的な消費を可能にするデータ構造自体については何もありません。私は、あなたが提案しているのは、元のアップデートの創始者がメッセージ・ヘッダーをマークアップするためのものであろうと思っています。これは、SOAの観点から私にとって間違っているものです。 イベントの起源と物事管理者の間には、しばしば多くのプロセスがあり、それぞれがメタデータを持ち運び、自身のIDで置き換えることを知る必要があります。 – Mike
メッセージヘッダーに移動する必要があります。 「物事マネージャー」には、誰にメッセージを送信するかを知るための購読リストが必要です。このリストで呼び出す他のサービスを特定するもの。これをデータ構造に含めます。あなたがコントロールできず、変更できない契約が明確に定義されているサービスで作業している場合、問題は最初から設計しているシステムとは異なります。そして、おそらく、あなたが出版/購読のデザインパターンを使用しているという巨大な前提を作っています。 –
ああ、それはポイント・ツー・ポイントのアーキテクチャーであり、残念ながら私たちはpub/sub（トピックベース、キューベースではない）アーキテクチャーを持っています。物事管理者は、物事について誰が誰に話す必要があるかを知る必要はなく、仕事をしているだけで、物事は購読して反応します。おそらく、これはトピックベースのpub/subが大規模なSOAシステムの点で良いか悪いのかという問題になるでしょうか？ P2Pは壊れやすくなりますが、ワークフローを簡単に追跡して監視することができます。 Pub/Subはそれほど簡単ではありませんが、システムを進化させるのは簡単です。しかし、明らかに、フィードバックループを導入することも簡単です... – Mike