タグ付けされた質問 「service-bus」

私は、WCFベースのSOAの一部をサービスバスモデル（おそらくnServiceBus）に移行し、いくつかの基本的なpub-subを使用してCommand-Query Separationを達成するプロジェクトを検討しています。 SOAやサービスバスモデルは初めてではありませんが、最近まで「分離」という概念は、すぐに使えるデータベースミラーリングとレプリケーションに限定されていたことを認めています。それでも、最終的に一貫性のあるシステムのすべての利点を提供する一方で、多くの明らかな欠点（特に、適切なトランザクションサポートの欠如）を回避するように見えるため、私はこのアイデアに魅了されます。 基本的にESBアーキテクチャ（少なくともMicrosoftの世界では）の第一人者であるUdi Dahanの主題について多くのことを読みましたが、彼が言うことの1つは本当に私を困惑させます。 より多くのフィールドを持つより大きなエンティティを取得すると、それらの同じエンティティを操作するアクターも多くなり、特定の時点で何かが何らかの属性に触れる可能性が高くなり、同時実行の競合の数が増加します。 [...] CQRSの中核となる要素は、ユーザーインターフェースの設計を再考して、ユーザーの意図を捉えることができるようにすることです。これにより、ユーザーを優先させることは、ユーザーが移動したことや得たことを示すこととは異なる作業単位であるようになります既婚。上で見たように、データの変更にExcelのようなUIを使用しても意図はキャプチャされません。 - ウディダハン、CQRSを明確化 引用で説明されている観点から、その論理について議論することは困難です。しかし、SOAに関しては穀物に反するようです。SOA（および実際のサービス全般）は、粗雑なメッセージを処理して、ネットワークチャターを最小限に抑えるようになっています -他の多くの利点があります。 優れたメッセージキューイングを備え、RPCの手荷物のない高度に分散されたシステムを使用している場合、ネットワークチャターは問題になりませんが、問題を完全に却下することは賢明ではないようです。Udiは、すべての属性の変更（つまり、フィールドの更新）を独自のコマンドにする必要があるとほとんど言っているようです。これは、従来のウェブサービス。 高度にパラメーター化された適切なクエリ、テーブル値パラメーター、またはステージングテーブルへの一括挿入を行うと、SQL Serverの1つのバッチ更新に数秒の時間がかかる場合があります。これらの更新を一度に1つずつ処理するのは遅く、遅く、遅く、OLTPデータベースハードウェアはスケールアップ/スケールアウトに最もコストがかかります。 これらの競合する懸念を調整する方法はありますか？私はそれについて間違った方法で考えていますか？この問題には、CQS / ESBの世界でよく知られた解決策がありますか？ そうでない場合、コマンドの粒度の「適切なレベル」をどのように決定するのでしょうか。出発点として使用できる「データベース」のような3NFのような「標準」があり、慎重なプロファイリングが潜在的に重要なパフォーマンスの利点を示唆する場合にのみ逸脱しますか？ または、これはおそらく、さまざまな専門家によっていくつかの強い意見が表明されているにもかかわらず、実際には単なる意見の問題であるものの1つですか？

17 architecture  enterprise-architecture  service-bus 

バス通信におけるコマンドとイベントの違いは、私には少し曖昧に思えます。コマンドは1回だけ実行する必要があることを知っていますが、イベントは複数回処理できますが、コマンドまたはイベントをいつ使用するかはわかりません。 例を見てみましょう： 新しいユーザーがWebアプリケーションに登録するときに、彼にアカウントを作成し、確認メールを送信する必要があります。 アカウントを作成する -これはCreateUserCommand、バスにを送信して、専用のコンポーネントに処理させるための適切な場所のようです。 または、これは非同期バス通信で実装するべきではありませんか？ユーザーがすぐにアプリケーションにログインできるようにしたいと考えています。バスでは、コマンドがいつ実行されるかは保証されません。 メールの送信 -コンポーネントがアカウントを作成した後、2つの可能性を確認できます バスに別のコマンドを送信します SendConfirmationEmailCommand イベントを公開する UserAccountCreatedEvent そして、電子メール送信コンポーネントがそれを取得し、それを仕事にします。 一方では、確認メールを1回だけ送信したい（コマンドを使用する）一方で、新しく登録したユーザーに関係するコンポーネントが複数存在する可能性があると考えています。ロガーまたはSMS送信者。 どのように実装しますか？

14 event-programming  cqrs  service-bus 

複数のアプリケーションがサービスバスを介して通信する方法を明確に示す方法を探しています。私がこれまでに思いついた最高のものはシーケンス図ですが、私は本当にそれが好きではありません。シーケンス図は必然的にある種のシーケンスに関連しますが、それは私が本当に望んでいることではありません。さらに、すべてのサービスがサービスバスと通信し、シーケンス図が各サービスを別々の列に配置するため、サービスの数が増えると、矢印が重なってしまいます。 例えば、与えられた4つのサービスFOO、BAR、BAZ、とQUX： FOOタイプpublishおよびregenのメッセージを公開します。 BARタイプrequeueのメッセージをパブリッシュします。 BAZタイプがpublish、regen、およびrequeueのメッセージをサブスクライブし、タイプがtransmitのメッセージをパブリッシュします。 QUXタイプが送信のメッセージをサブスクライブします。 どのサービスでも、いつでもどのメッセージタイプでも公開できます（暗黙のシーケンスはありません）。 この情報を明確かつ明確に表すには、どのような図を使用する必要がありますか？ これが私がこれまでに思いついた最高のものです：

9 diagrams  pubsub  service-bus