リクエスト-返信とパブリッシュ/サブスクライブ
2つの大きなシステム間の統合に取り組んでいます。 システムAは従業員データのデータベースであり、システムBは顧客との毎日の連絡に使用される外部システムです（つまり、会議、場所データ、作業指示、作業）ステータスなど）。途中にESBを配備します。
システムAのインスタンスが3つ、システムBのインスタンスが1つあります。これは法的制限によるものであり、すべてのシステムAデータを同じデータベースに置くことはできません。
システムBでは、毎日20〜30のアクティブな連絡先があり、システムAからのデータの一部が継続的に使用されます。
システムBの会議、場所、および作業ステータスを1日中更新する必要があります。また、これらのシステムを統合するための2つのソリューションが提案されています。
ソリューションA：パブリッシュ/サブスクライブ-システムAが更新メッセージを送信し（これはHL7 ADT標準に基づいています）、システムBのインスタンスがそれらのデータを取得します。これはブロードキャストとして行われ、1日あたり1000〜10000メッセージが生成されます。システムAからすべての従業員に関する情報を送信し、システムAのすべての従業員にメッセージを生成します（1,2,3）。 「アクティブ」であり、システムBの更新に興味深いシステムAの従業員のサブセットしかありません。ただし、データは他のシステムによっても更新されるため、すべての従業員にメッセージが流れます。
解決策B：システムBは、要求/応答ソリューションを通じて更新された情報を要求します。空の呼び出しを生成しますが、特定の日にシステムBで「アクティブ」な従業員のみを要求します。
ソリューションについてのコメント？長所短所？これらの2つの中で最もインフラストラクチャの「重い」ソリューションは何ですか？
私にsomポインタを与えることができる誰かがそこにいることを願っています:)
ソリューションBは、システムBで必要になるたびにシステムAにデータを要求した場合にのみ機能します。それ以外の場合、情報が最新であることを保証できません。これは思ったほど悪くはなく、実際にはすべてのSOAアーキテクチャの基礎となっています。
プッシュする（ソリューションA）かプルする（ソリューションB）かは、システムAの更新とシステムBのクエリ数の比率によって決まります。
システムAに多くの更新があるのに対し、システムBにはいくつかのクエリがある場合、「プル」が当然の選択です。
システムAの更新が比較的少なく、システムBのクエリが多い場合は、「プッシュ」が適しています。
たくさんの更新とたくさんのクエリがある場合、どちらの選択も同様に良い（または悪い！）です。
システムBをリアルタイムで使用しているため、技術的に実装できるアーキテクチャを選択する必要があります。これにより、システムBで最新のデータが得られ、使用するリソースも最小限になります。
ソリューションAとBの実装の詳細を確認し、リソース（メモリ、CPU）の消費により良い電流データを与えるものを確認する必要があります。理想的には、システムAのレコードごとにパブリッシュサービスがあり、システムAの個々のレコードが変更されたときにシステムBに通知しますが、これは提案されたソリューションではありません。
更新がAからBにのみ流れる場合、BはAからのデータをキャッシュするだけで済みます。Bは必要なときにのみAからデータを読み取る必要があり、Aが要求されることなくデータを送信（パブリッシュ）する必要はありません。次に、古くなったキャッシュをどうするかを管理する必要があります（Aは前回Bが更新されてから更新されています）。しかし、Aが更新されたときにBだけがデータを必要とする場合はどうなりますか？ Bは、Bの最後のチェック以降に更新があるかどうかを定期的にAに尋ね、更新されたエンティティのみを取得できます。
R.フィールディングは、ここでpub/subがスケーラブルでない理由についてコメントしました： http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons ここで、からの私の答え。