問題タブ [messaging]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
2864 参照

c# - C# クライアントからクライアントへのメッセージング

最初に達成したいことを正確に説明しようとします。

2 人のユーザーが Windows フォーム アプリケーションを使用しているとします。ユーザー A が特定のフォームを開くと、フォームの基になるデータ レコードにロックが適用され、その時点でそのユーザーだけが変更できるようになります。

ユーザー B は、(グリッド内の) すべてのレコードのリストを持っています。これには、特にユーザー A が既に開いているレコードへの参照が含まれています。ユーザー A がレコードを開くと、ユーザー B のレコードのリストが更新され、行の横にあるロック アイコンをクリックして、レコードが使用中であることを示します。

これはメッセージングで行うことの些細な例ですが、ユーザー A がユーザー B が知る必要のあることを行っていることは理解できます。

Jabber-net for C# と OpenFire Jabber Server を使用してシステムを実装しました。基本的に、メッセージが送信されると、データベースのメッセージ テーブルに新しい行が挿入されます。メッセージ テーブルは、SqlDependancy オブジェクトを使用してサービス クライアントによって監視されるため、新しいメッセージの準備が整うと、サービスは関連するメッセージを作成し、Jabber および OpenFire サーバーを介して目的のクライアントに送信します。

これは問題なく動作しますが、OpenFire のすぐに使える機能はインスタント メッセージングをサポートするためのものであり、明らかに私が達成しようとしているものではありません。私が抱えている問題は、ユーザーが 2 つのアプリケーション コンテキスト (テストとライブ) にログインしている場合、user@server/resource の JID 構造がリソースを認識しないため、OpenFire はどちらにメッセージを送信するかを認識できないことです。

基本的に、私が現在 OpenFire と Jabber-net を使用している方法は、まったく正しくありません。

私が達成したいことを達成するために使用できるパターンはありますか。つまり、メッセージを送信しているクライアントを指定しながら、何かをするようにクライアントにメッセージを送信します。XMPP は、解析する独自のメッセージ タイプを構築できるため、答えのように思えました。

私のアプリケーションは、Windows フォーム、.NET 3.5 C# アプリケーションです。

0 投票する
4 に答える
1915 参照

java - Java Web アプリケーション用の埋め込み可能なメッセージング コンポーネント

顧客の要求を満たすためには、ユーザー同士で情報を交換できるようにする必要があります。「メッセージング システム」には高度なバックエンド要件がなく、メッセージとメッセージ タイプを格納するいくつかのテーブルで簡単に実装できます。

問題は、フロントエンドの要件が非常に高く、使いやすさが非常に重要であると私が信じていることです。また、このコミュニケーションの部分は、長期的にはシステムの重要な部分になると期待しています。

Java Web アプリケーションに直接統合して、アプリケーションの設計に適合させることができるものはありますか? 必要なのは次のインターフェースです

サービス層から:

  • ユーザーにメッセージを送信 (ヘッダー、件名)
  • メッセージに返信する
  • ユーザーの受信トレイの新しいメッセージに関する通知 (可能な場合: 現在のページ)
  • 既存のユーザー管理へのインターフェース

できれば、コンポーネントには、次の機能を備えたフロントエンドが既にある必要があります。

  • メッセージ管理 (選択、削除、返信、削除/復元など)
  • フォルダー: 受信トレイ、送信済み、ゴミ箱
  • タグ付け: メッセージ カテゴリ
  • パネル/div に最後のx件のメッセージを表示する
  • アプリケーションのように見えるスタイリング

かなり安定したものがあれば、このようなものをアプリケーションに実装する前にコンポーネントを使用することをお勧めします。アプリケーションは Wicket で実行されますが、メッセージング コンポーネントについてはこのフレームワークに縛られていません。

ありがとう、カリエム


ポータル サーバーでは、探しているコンポーネントと同様の機能を持つポートレットを柔軟に追加できます。たとえば、 Liferayメールメッセージ ボードのポートレットを提供します。

akfがコメントで指摘しているように、Jabberはメッセージングの強固な基盤を提供します。Web アプリケーションに統合できるものを探しています。Jabber を中心に多くの UI を構築する必要がある場合、それが要件に適しているとは本当に考えられません。

0 投票する
1 に答える
1268 参照

python - Mule vs ActiveMQ for Python

いくつかのサーバー、ネットワーク サービス、アプリケーション サーバー (Apache、Tomcat) を管理し、それらを管理する (開始、停止、ソフトウェアのインストール) 必要があります。

C++は複雑で、タスクの生産性が低いように見えるため、Pythonを使用したいと思います。どのミドルウェアを使用すればよいかわかりません。Java で書かれていますが、ActiveMQ と Mule は良い選択のようです。私は ActiveMQ についてよく理解していますが、ESB についてはほとんど知りません。

何かアドバイス?Pythonのオプションはありますか?

豆の木があるのを見ましたが、単純すぎて柔軟性がありません。調整のためのメッセージ システムと、tar.gz ファイルをサーバー (ソフトウェア パッケージ) に送信する方法が必要です。

Python ネイティブのメッセージング ソリューションがありました。

0 投票する
2 に答える
2910 参照

.net - メッセージ処理のパイプライン パターン

キューに置かれている一連のサービス (非 WCF) があります。メッセージが到着すると、典型的なサービスはいくつかの計算を行い、0 個以上の結果メッセージを出力キューに吐き出します。各サービスには、その主な機能に加えて、認証 / 監査 / ロギング / ステータス追跡などのいくつかのハウスキーピング ロジックがあり、正確な手順とシーケンスはサービスによって多少異なります。ここで、パイプラインの概念が登場します。

最終的なデザインに満足できず、シンプルにする方法を探しています。CCR ポートをモデル化する必要がありますか? ASP.NET パイプライン? AOP? 他に何か?

私の現在の設計は次のとおりですIMessageHandler<TMessage>。IoC を使用して 6 つの独自の方法でチェーンされたインターフェイスと約 15 の実装があります。インターフェイスは単一のメソッドHandle(TMessage msg)を定義するため、各実装はメッセージをデイジー チェーンの次のハンドラに渡す前と後の両方で何らかのロジックを実行できます。

これの問題は、各実装が正確に何をするのか、なぜこの特定のサービスのためにこの特定の方法で連鎖されたのかを思い出すのが難しいことです。一方、各側面を独自のクラスに配置すると、懸念事項をより適切に分離できるため、単体テストが容易になります。

アイデア?私が見ることができる良いパイプラインパターンはありますか? 参照として使用できる優れたパイプラインの実装はありますか? それともJFHCIにするべきですか?

0 投票する
1 に答える
984 参照

java - MuleAggregator-ストリーミングアグリゲーション

Mule 2.0フレームワークで使用されるコレクションアグリゲーターは、次のように機能します。

  • インバウンドルーターはメッセージのコレクションを受け取り、それをいくつかの小さなメッセージに分割します-それぞれの小さなメッセージには、親メッセージに対応する相関IDがスタンプされます

  • これらのメッセージはさまざまなサービスを流れます

  • 最後に、これらのメッセージは、親メッセージの相関IDと予想されるメッセージの数に基づいてメッセージを収集するインバウンドアグリゲーターに到着します。予期されたすべてのメッセージが受信されると、集計関数が呼び出され、結果が返されます。

これで、グループ内のメッセージの数が適度に少ない場合にこれが正常に機能します。ただし、グループ内のメッセージの数が最大100kになると、後のメッセージが到着するのを待っているメッセージのグループを保持するために、多くのメモリが拘束されます。複数のグループが同時に集約されている場合、これはさらに悪化します。

この問題を回避する方法は、ストリーミングアグリゲーターを実装することです。私のユースケースでは、基本的にキーに基づいてさまざまなメッセージを要約しています。これは、グループ内のすべてのメッセージを同時に表示しなくても実行できます。結果をエンドポイントに転送する前に、すべてのメッセージが受信されたことを知りたいだけです。

これは問題の合理的な解決策のように聞こえますか?

これはすでにMuleのどこかに実装されていますか?

これを行うためのより良い方法はありますか?

0 投票する
5 に答える
2522 参照

c# - デザインヘルプ–ポリモーフィックイベント処理

設計の質問–多形イベント処理

現在、現在のプロジェクトでイベントハンドルの数を減らしようとしています。USB経由でデータを送信する複数のシステムがあります。現在、メッセージを読み取り、最初のヘッダーの詳細を解析して、メッセージの送信元のシステムを判別するルーチンがあります。ヘッダーが少し異なるため、作成したEventArgsは同じではありません。次に、すべての「オブザーバー」に変更を通知します。だから私が今持っているのは次のとおりです。

Form1コード

そして、解析アルゴリズムでは、メッセージに基づいて次のようなものがあります。

私が本当にやりたいのはこれです:

そして、あいまいさの理由から、これを行うことはできません。だから私の質問は、この問題へのより良いアプローチは何でしょうか?

0 投票する
4 に答える
20815 参照

events - RESTful Web サービスを使用して非同期通知システムを作成するにはどうすればよいですか?

RESTful Web サービス経由で利用できるようにする Java アプリケーションがあります。クライアントがイベントの通知に登録できるメカニズムを作成したいと考えています。問題は、クライアント プログラムが Java プログラムであるという保証がないため、これに JMS を使用できないことです (つまり、すべてのクライアントが Java アプリである場合、クライアントが JMS トピックにサブスクライブできるようにすることができます)。そこで通知メッセージをリッスンします)。

ユースケースはおおよそ次のとおりです。

  1. クライアントは、特定のオブジェクトが更新されるたびに通知メッセージを取得することに関心があることを示す、RESTful Web サービス呼び出しを介してサーバー アプリケーションに自身を登録します。
  2. 対象のオブジェクトが更新されると、サーバー アプリケーションは、このイベントの通知を希望するすべてのクライアントに通知を送信する必要があります。

上で述べたように、すべてのクライアントが Java アプリである場合にこれを行う方法はわかっています。つまり、クライアントが通知メッセージをリッスンできるトピックを設定します。ただし、多くのクライアントが JMS トピックの通知メッセージをリッスンできない可能性が高いため、このアプローチは使用できません。

この問題が通常どのように解決されるかについて、誰かが私に教えてもらえますか? RESTful API を使用してどのようなメカニズムを提供できますか?

0 投票する
3 に答える
8157 参照

messaging - スプリットブレイン、投票、クォーラムの回避

n 個のプロセス (n > 2) があるとします。そのうちの 1 つをアクティブにするという合意が必要です。そのため、どちらがアクティブかを決定するために、互いに投票する必要があります。

すべてのプロセスはいつでも失敗する可能性があります。可能であれば 1 つのプロセスをアクティブにしたいのですが...

同時に 2 つをアクティブにしてはいけません(つまり、スプリットブレインを回避したい)

それらの間で利用可能な唯一の通信メカニズムは、pub-sub メッセージングです (ポイント ツー ポイントではありません)。

1 つ以上のデータベースが使用可能ですが、1 つのデータベースが単一障害点になることはありません。すなわち。すべてのプロセスが動作可能であり、1 つのデータベースが失われたために動作が妨げられるとしたら、非常に望ましくありません。

デザイン?どのようなメッセージを公開する必要がありますか?

0 投票する
2 に答える
2031 参照

jms - メッセージ キュー: メッセージはネットワーク障害で失われますか?

WebsphereMQ や ActiveMQ (JMS 経由で使用) などのメッセージング システムでのメッセージ配信の信頼性について疑問に思っています。私の知る限り、受信者が利用できず、後で配信される場合、メッセージをバッファリングできます。

今、送信者が一時的にネットワークに到達できない場合はどうなるのだろうと思っています。後でメッセージを送信する何らかの種類のローカル バッファリングはありますか? これは、メッセージブローカーが実行されている場所に依存すると思います。すべてのマシンにローカル ブローカーがありますか? それとも中央のブローカーだけですか?

私の質問を特定するには: 一時的なネットワーク障害に直面しても、メッセージが最終的に受信されるようにする必要がある場合、メッセージング システムは正しい選択ですか? この信頼性を達成するために必要な特定のセットアップはありますか?

関連するドキュメントへのポインタをいただければ幸いです。