5

簡単に言うと、私は、通常の理由で大規模な 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このようなものと一緒に円を描いて過ごすことができることがわかります。

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

4

6 に答える 6

7

まず第一に、ESB について心配する必要はありません。あなたが説明した状況は、単純なメッセージ指向のミドルウェアの範囲内にあります。メディエーション、コンテンツベースのルーティング、プロトコル変換などを行う場合にのみ、ESB が「必要」です。メッセージを適切な場所にルーティングするだけでなく、ミドルウェアがメッセージに何かを行うもの。

相互に通信する必要があるさまざまな宛先アプリケーションのセットがある場合 (あなたのように聞こえますが)、言語にとらわれないプロトコル (XMPP、STOMP、HTTP など) を介したメッセージングが優れたソリューションであることは間違いありません。これは基本的に、メッセージを好みの JMS に変換するために Java デーモンを大量に作成して実行する必要がないことを意味します。

STOMP はメッセージ ブローカー、特にオープン ソースのメッセージ ブローカーによってますますサポートされており、多数の異なるクライアント ライブラリがあります。これはメッセージング用に特別に設計された軽量のプロトコルであるため、HTTP よりもはるかに豊富な機能セットをすぐに利用できます。

私にとって、XMPP はサーバー側で十分にサポートされていないため、少し弱いオプションですが、ブローカーに IM を送信できるのは楽しいことです :)

HTTP に設定されている場合、OpenMQは非常に優れており、私は個人的にUniversal Message Serviceを使用しました。これは基本的に、JMS 宛先の webapp ラッパーです。STOMP が提供するのと同様の一連の動詞を使用して、REST 対応のインターフェイスを提供します。

于 2008-12-28T19:24:43.833 に答える
7

私は 2003 年頃から、さまざまなソフトウェア システムで JMS メッセージングを扱ってきました。クライアントが事実上 JMS トピック サブスクライバである Web アプリケーションを持っています。メッセージをトピックにパブリッシュするだけで、メッセージはサーバープッシュされ、サブスクライブしているすべての Web クライアントに配信されます。

Web クライアントは Flex ベースです。当社の中間層スタックは次のもので構成されています。

  • Java 6
  • トムキャット6
  • ブレイズDS
  • 春フレームワーク
  • ActiveMQ (JMS メッセージ ブローカー)

BlazeDS には、JMS へのブリッジとして構成する機能があります。これは、Flex クライアントのリモート呼び出しに応答する Tomcat サーブレットですが、構成されている JMS トピックに新しいメッセージが表示されたときにクライアントにメッセージをプッシュすることもできます。

BlazeDS は、サーバー側のメッセージ プッシュを行うための Comet パターンを実装します。

非同期 HTTP および Comet アーキテクチャ 非同期のノンブロッキング HTTP プログラミングの概要

Farata Systems は、コメット パターンを実装するための Jetty continuation アプローチで動作するように BlazeDS を修正したことを発表しました。これにより、単一の物理サーバーに対して何千もの Comet 接続にスケーリングできます。

Farata Systems が Adob​​e BlazeDS でパフォーマンスのブレークスルーを達成

基本的に私たちは Tomcat と Spring を組み合わせて使用​​することにかなり慣れているので、Adobe が BlazeDS 自体に Servlet 3.0 のサポートを実装するのを待っています。

非常にスケーラブルな Comet パターンを実行する手法の鍵は、Java NIO HTTP リスナーをスレッド プール (Java 5 Concurrency ライブラリの Executor クラスなど) と組み合わせて利用することです。Servlet 3.0 は、このような HTTP リスナーと結び付けることができるサーブレットの非同期イベント駆動型モデルです。数千 (10,000 から 20,000 のような数) の同時 Comet 接続を単一の物理サーバーに対して維持できます。

私たちの場合、Adobe Flex テクノロジーを使用して Web クライアントをイベント駆動型メッセージング サブスクライバーに変えていますが、一般的な AJAX Web アプリでも同じことができます。AJAX サークルでは、サーバー側のメッセージ プッシュを行う手法は、多くの場合、リバース AJAXと呼ばれます。コメットは、Ajax (両方とも家庭用掃除機) に対応するものと同様に、言葉遊びであることに気付いたかもしれません。ただし、私たちにとって良いことは、部品を配線するだけですぐに使用できることです。一般的な AJAX Web コーダーは、より多くのプログラミング作業を行う必要があります。(ただし、一般的な Web アプリでも BlazeDS を使用することはできますが、BlazeDS で可能な AMF マーシャリングを使用することはできません。)

最後に、Adobe と SpringSource は協力して、Spring フレームワークと連携した BlazeDS のよりスムーズですぐに使える統合を確立しています。

アドビ、SpringSource と協力して Flash と SpringSource プラットフォーム間の統合を強化

于 2008-12-24T07:23:07.007 に答える
0

あなたは本当に確実な配信でパブリッシュとサブスクライブについて話しているのです。ほとんどのMOMソフトウェアは、ユースケースを簡単にサポートするはずです。

于 2011-04-14T19:49:13.980 に答える
0

すでに述べたように、現在のケースで ESB を使用することは、ハエをハンマーで粉砕するのが好きなように思えます。

ESB ソフトウェア自体には時間がかかり、メンテナンスが必要になります。オープン ソース ソリューションを使用する場合は、ライセンス ソリューション (IBM、ORACLE など) を使用するよりも時間がかかる可能性があります。

もちろん、ESB がその役割を果たします。ソリューションを開発するのは非常に簡単ですが、ESB をセットアップすることは、ソリューション自体を行うよりもはるかに困難です。

問題が説明されているケースに限定されている場合は、OpenMQ (または同様のもの) で単純なアーキテクチャを構築し、JMS を介して使用することを強くお勧めします。

于 2016-07-15T20:08:33.133 に答える