問題タブ [messaging]

Enterprise Integration Patternsが出版されて以来、人々はその本で導入された表記法を使用して、非同期の異種メッセージング システムを文書化しています。

しかし、私たちのショップは、UML のみを処理する独自のドキュメント ツールを中心に多かれ少なかれ標準化されています。標準 UML ダイアグラムの 1 つは、トランスフォーマー、ルーターなどを含む非同期メッセージング システムを文書化するのに適していますか? はいの場合、どちらですか？そうでない場合、この目的のために UML を微調整することに反対する強力な議論は何でしょうか?

AMQP (qpid を使用) を使用して、Python と Java のサービスが相互に通信できるようにすることを検討しています。基本的なテキスト メッセージングは​​単純に見えますが、私が調査した他のすべてのメッセージング テクノロジと同様に、それで終わりのようです。インスタント メッセージング アプリケーションを構築することを除いて、文字列を送信することは特に役立つことではないと思っていたでしょう。

私の本能は、両方の言語で優れたライブラリサポートを備えた XML (デ) シリアライゼーションまたは類似のもの (JSON、YAML、プロトコルバッファーなど) を使用することです。これはベスト プラクティスですか? もしそうなら、どの (逆) シリアル化プロトコルをお勧めしますか? それとも、私はどこかでポイントを逃しており、小さなテキストを送信するだけで十分なはずですか?

メッセージキューからメッセージを取得し、データベース内のテーブルを更新するコードを作成する必要がある場合、どのようにすればよい方法でメッセージを構造化できますか。どのように構成しますか？メッセージはXMLデータであり、テーブルの行ごとに1つのノードです。テーブルの行は、更新、削除、または挿入される可能性があります。

アプリケーションで1つの論理PGMベースのマルチキャストアドレスを使用する必要がありますが、そのようなアプリケーションを複数の異なる地理的位置(つまり、米国/ヨーロッパ/オーストラリアを考えてください)で「シームレスに」実行できるようにする必要があります。

アプリケーションはかなりのスループット (1 日に数百万のビジネス メッセージ) であり、多くの小さいながらも非常に頻繁にメッセージを送信するため、遅延が要求されます。古典的な Atom pub は、レイテンシの外部制限により、ここでは機能しません。

これらのデータセンターを接続するためのいくつかのオプションを考え出しましたが、最適なものが見つかりません。私が検討したオプションは次のとおりです。1) VPN を介してマルチキャスト メッセージを転送します (VPN はそのような大きな負荷を処理できますか)。2) すべてのマルチキャスト メッセージを「ラッパー メッセージ」に変換し、AMQP 経由で転送します。3) TCP 経由でマルチキャスト メッセージを他の 2 つの場所にトンネリングする専用の社内ゲートを作成します。4) その他の解決策

開発者から追加のコードを書き込む必要がないため、オプション 1 をお勧めします。しかし、信頼できる接続ではないのではないかと心配しています。

そのような接続に適用する規則はありますか?

地理的構成に関する最適なネットワーク構成は、上記の制約に対するものです。

背景
現在の Web アプリケーション内でのメッセージングの効率性を調査し、XML の代替手段の使用を検討しています。これは大学のプロジェクトであり、その結果は公開されます。コミュニティの参加が増えるほど、返される結果の価値が大きくなります。

次のことを行うために、できるだけ多くの実際の XML の使用例が必要です。

• ホスト A がホスト B
  と通信するときに、XML がどのように使用されるかを完全に理解する。現実はかなり違うかもしれません。
   
• 架空のデータではなく、実際のデータに対してテストを実行する 実際のデータセット
  に対してテクノロジー X と比較して XML がどのように機能するかは、任意のデータ セットに対してXML がテクノロジー X とどのように比較されるかと同じくらい重要です。
   
• 
   要素のみ、要素といくつかの属性、または最小限の要素と大量の属性の使用など、XML の使用パターンを特定して測定します。

質問

Web アプリケーションの世界で XMLをどのように使用しますか?

ホスト B が XML 構造のデータを HTTP 経由でホスト A に返すと、何が返ってくるでしょうか? これは、AJAX 環境でデータを返すサーバー、または 1 つ以上の他のサーバーからのデータを照合する 1 つのサーバーの場合があります。

理想的な答えは次のとおりです。

• HTTP 応答内の XML の実例
• 該当する場合、上記をリクエストするための URL
• 必要に応じて、データが何を表しているかについての説明
• 明白でない場合、そのようなメッセージが交換されている理由の説明 (たとえば、ユーザー要求を満たすため、ホスト X がホスト Y にヘルス ステータス レポートを返すため)

どんな例でも大歓迎ですが、あなたが作成、開発、または取り組んだアプリケーション/サービスからの例を希望します。5 行の XML 文書から 10,000 行のモンスターまで、どんなものでも素晴らしいでしょう。

あなたの例での XML の使用に関するあなた自身の意見も素晴らしいでしょう (たとえば、要件 X/人 Y のために XML 構造の応答を実装しましたが、...; または、XML を使用して[本当に正当な理由]であり、それが仕事に最適な選択だからです）。

更新
一般的に XML のトピックに関するすべての回答に非常に感謝していますが、私が本当に探しているのは、XML を含む HTTP 応答本文の実際の例です。

私は現在、XML の歴史、どのような一般的な代替案が存在する可能性があるか、および特定のシナリオに対する機能と適合性がどのように比較されるかについて、かなり認識しています。

現在の使用法が正しいか適切であるかに関係なく、HTTP ホスト間のデータ交換で XML が現在どのように使用されているかを理解することで、より大きな利点が得られます。XML が誤って適用された例は、XML が正しく適用された場合と同じくらい価値があります。

ActiveMQ 5.2を使用していますが、アプリケーションには500,000付近の多数のトピックが必要です。アプリケーションを実行すると、約1000のトピックのみを作成した後、ActiveMQはOutOfMemoryExceptionをスローします。

ActiveMQがこの数のトピックをサポートすることを期待するのは不合理ですか？

この使用法に最適な構成はありますか？

このスレッドは問題の詳細を示しています：http：//www.nabble.com/java.lang.OutOfMemoryError%3A-unable-to-create-new-native-thread-on-AMQ-5.0-td17005441.html

簡単に言うと、私は、通常の理由で大規模な Web アプリケーションを書き直すプロジェクトに取り組んでいます。書き換えの主な目的は、単一のサーバーで実行されているこの大きな単一のアプリケーションを、多くのサーバーで実行できる多くの小さな分離アプリケーションに分離することです。

ここに私が望むものがあります：

HTTP私は主要な輸送メカニズムになりたいです。たとえば CMS などの 1 つのアプリケーションが更新されると、HTTP 経由でブローカーに連絡し、言うと、ブローカーは言うために a を"I've changed"送り返します。200 OK"thanks I got the message"

次に、ブローカーは、CMS の変更について知りたいと思っている他のアプリケーションのリストを調べ、メッセージについて知りたいとブローカーに伝えたときにアプリケーションが残した URL にメッセージを渡します。

他のアプリケーションは200 OK、メッセージを受信すると戻ります。そうでない場合、ブローカーはメッセージを保持し、誰かが次にそのアプリケーションに接続しようとするときに備えてキューに入れます。

問題は、どこから始めればよいのか、それを実現するために何が必要なのかさえわからないことです。私は 、 、 などを見てきましたがXMPP、ActiveMQ来年RabbitMQはMule ESBこのようなものと一緒に円を描いて過ごすことができることがわかります。

私は難しい方法でレッスンを学ぶことを避けたいので、誰かが個人的な経験からアドバイスを提供できますか.

Google のプロトコル バッファは、本番環境の大規模な本番アプリケーションで使用されていますか?

使ってみての感想は？

マルチスレッド Windows アプリケーションを作成しました。ここで、スレッド:
A – ユーザーの操作を処理し、B からのデータを処理する Windows フォームです
。B – 時々データを生成し、2 つの A に渡します。

スレッド セーフ キューは、スレッド B から A にデータを渡すために使用されます。エンキューおよびデキュー機能は、Windows クリティカル セクション オブジェクトを使用して保護されます。

エンキュー関数が呼び出されたときにキューが空の場合、関数は PostMessage を使用して、キューにデータがあることを A に伝えます。この関数は、PostMessage への呼び出しが正常に実行されていることを確認し、成功していない場合は PostMessage を繰り返し呼び出します (PostMessage はまだ失敗していません)。

これは、ある特定のコンピューターが時折メッセージを失い始めるまで、かなり長い間うまくいきました。失うとは、PostMessage が B で正常に返されるが、A がメッセージを受信しないことを意味します。これにより、ソフトウェアがフリーズしたように見えます。

私はすでにいくつかの許容できる回避策を考え出しました。Windows がこれらのメッセージを失っている理由と、これが 1 台のコンピューターでのみ発生している理由を知るのは興味深いことです。

コードの関連部分を次に示します。