問題タブ [servicebus]

本日、PDCで発表されました。当初は、サービスバス、ワークフローサービス、およびアクセス制御サービスで構成されていました。彼らは何ですか？なぜ私はそれらを使うのでしょうか？

メッセージベースのシステムを使用する動機は何ですか？

NServiceBusやMassTransitなどのサービスバスについて多くのことを見ていて、基礎となる方法論の利点は何であるか疑問に思っています。

依存関係のない展開を可能にする製品 (理想的にはオープン ソースですが、必須ではありません) はありますか? 私が見つけたすべてのサービス バスまたはキュー ライブラリは、いずれかのキュー アプリ (msmq など) またはデータベースに依存しています。アプリケーションへの参照を追加してビルドし、できるだけ少ない構成でデプロイできる、非常に軽量なソリューションが必要です。

理想的な世界では、キュー/サービス バスが IIS で実行され、Web およびリッチ クライアントが IIS と通信できるようになります。

このようなツールは、ローカルの開発マシンで大規模な分散システムのプロトタイプを迅速に作成するのに理想的です。

さまざまな通知のためにサーバーにメッセージを送信する必要があるクライアント アプリケーションがあります。クライアントが時々接続して実行できるようにするために、メッセージ キュー アプローチを使用します。キュー処理は、メッセージをキューから取り出し、別のキューに配置して最終的に処理する Web サービスを呼び出します。この質問はクライアント環境に関するものです。サーバー環境はすでに決まっています。

MSMQ を適切にインストール/構成し、セキュリティで保護するためにすべてのクライアント PC を制御できないため、MSMQ を使用したくありません。また、MSMQ キューの内容を調査するためのツールの品質のために、サポートがより困難になるためです。 . SQL Server 2005 Express はすべてのマシンにあり、アプリケーションのデータを格納するために使用されます。

私は現在、2つのオプションにそれを持っています:

1. メッセージをシリアル化した後にテーブルに格納し、ThreadPool.QueueUserWorkItem各メッセージ タイプに対して構成されたハンドラーによってメッセージを処理するために使用する、かなり基本的な永続的なメッセージ キューを記述します。すべてが含まれているSystem.Transactions.TransactionScopeため、正常に処理された場合にのみ永続キューから削除されます。
2. ローカル データベースを使用する Service Broker トランスポートを使用して、クライアントで NServiceBus (これはチームとして使用したサービス バスであるため、MassTransit などはオプションではありません) を使用します。

私はサービス バスの経験がほとんどないため (サービス バスの用語はまだよくわかりません)、必要な方法で要件を満たすはるかに単純なものを作成する場合と比較して、学習曲線が心配です (展開は大きな考慮）。

誰か考えがありますか？

私は、サーバーで処理するために、クライアントでかなりタイトなループで数千のメッセージを生成する可能性のあるアプリケーションに取り組んでいます。イベントのチェーンは次のようなものです。

1. クライアントはアイテムを処理し、ローカル キューに入れます。
2. ローカル キュー処理がメッセージを取得し、Web サービスを呼び出します。
3. Web サービスは、サーバー上のサービス バスにメッセージを作成します。
4. Service Bus はデータベースへのメッセージを処理します。

Web サービスには多くのクライアントが存在するため、すべての通信が非同期であるという考え方です。MSMQ がこれを直接実行できることは知っていますが、セキュリティなどを設定するためのその種の管理機能がクライアントに常にあるとは限りません。

私の質問は、各段階でのメッセージの粒度についてです。最も単純な方法は、クライアントで処理される各アイテムが 1 つのクライアント メッセージ/Web サービス呼び出し/サービス バス メッセージを生成することを意味します。それは問題ありませんが、可能であれば Web サービスの呼び出しをバッチ処理する方がよいことはわかっています。ただし、大粒度の Web サービス DTO とデータベースでの実行時間の短いトランザクションとの間にはトレードオフがあります。この特定のシナリオでは、すべてのアイテムが処理されるか、まったく処理されない「ビジネス トランザクション」は必要ありません。メッセージ サイズと Web サービス呼び出しの数とデータベース トランザクションの最適なバランスを実現することを目指しています。

何かアドバイス？

nServiceBus、Rhino Service Bus、MassTransit について、あなたが持っている、または知っているリソースについてぜひ教えてください。

• ビデオ？
• ブログ投稿？
• 本？
• デモプロジェクトなど

ホワイト ペーパーでは、REST を使用してトークンを要求し、トークンを使用して発行するリクエストにアタッチし、サービス バスでサービスを呼び出すことができると述べていますが、トークンを取得できません。

以下は、REST 呼び出しを行うために使用するコードです。結果を取得できますが、これは html エラー ページでした..トークンを取得できませんでした...そして、ソリューション名とパスワードが正しいと確信しています。クラウド内の私のサービスは RESTful サービスです。サービス エンドポイントをブラウザに配置すると、ソリューション名とパスワードを入力するように求められます。以下のコードで使用されているものと同じものを入力すると、問題なく動作します。 .

以下のコードが白人の言ったことを理解できない理由を誰か教えてもらえますか??

================ 以下はホワイトペーパーからの言葉 =============

https://accesscontrol.windows.net/isssuetoken.aspx?u= {ソリューション名}&p={パスワード}

応答には、.NET Access Control Service 内に保持されているトークンへの参照 Cookie (プレーン テキスト形式) が含まれています。クライアントは、「X-MS-Identity-Token」という名前のカスタム HTTP ヘッダーで送信 HTTP 要求に Cookie 値を追加することにより、Cookie を使用してリレー サービスにアクセスできます。この手法を使用する場合、Microsoft は HTTPS を使用してネットワーク上の Cookie 値を保護することを強くお勧めします。.NET Access Control Service の詳細、および (.NET Service Bus だけでなく) 独自のサービスと組み合わせて使用​​する方法について具体的に学習するには、付属のホワイト ペーパー「A Developer's Guide to the .NET」を参照してください。アクセス制御サービス。

タイトルがすべてを表していると思います.... .NET 2.0 システムで分散パブ/サブ モデルを実装しようとしています。NServiceBus、RhinoBus、MassTransit に出会いました。残念ながら、これらは MSMQ ベースです。私は、別のメッセージングの代替手段を使用する pub/sub の代替手段を見つけ出す任務を負っています...

MSMQ の代替手段を探す唯一の理由は、メッセージ サイズの制限を克服することです。メッセージごとの制限により、企業向けアプリのメッセージが切り捨てられる可能性があるため...

どんなガイダンスも大歓迎です

私はメッセージバスをさらに理解しようとしていますが、頭に浮かぶ質問の1つは、「メッセージはどのようにしてバスに届くのか」ということです。さて、メッセージを受信して​​バスに乗せるサービス（WCFなど）があると思います。それで、私が持っているもう1つの質問は、このサービスがボトルネックになる可能性が高いということではないでしょうか。このサービスは、負荷分散などによって簡単に拡張できるように設計すると思いますか？それとも別の方法がありますか？

また（申し訳ありませんが、元々は1つの質問のみであると想定されていました）、メッセージの送信先を定義するルーティングテーブルはどこに保持されますか。データベースで？繰り返しますが、これは潜在的なボトルネックではないでしょうか？

これを非製品（BizTalkなど）またはフレームワーク（NServiceBus、大量輸送機関など）の観点から見ようとしています。まるでこのようなことを一から書くかのように。私はあなたが得ているものと潜在的な問題について頭を悩ませたいと思います。BizTalkを使用すると、ルーティングテーブル用のメッセージボックスが表示されます。これは、過去に悪名高いボトルネックでした。また、2009年のESBの部分で「ランプ上」の概念を持っていることもわかります。しかし、私が言ったように、私は製品を超えて、人々がそれをどのように見るかを設計する必要があると考えたいと思います。

洞察に感謝します。