0

メッセージベースで動作するクライアント/サーバーアプリケーションを作成中です。別の実装を書くのではなく、できるだけ再利用したいと思います。他の人が何を使っているのか知りたいです。

ライブラリが提供する機能:

  • クライアント側とサーバー側の機能
  • メッセージベースで動作するはずです
  • マルチスレッドをサポート
  • ロードバランサー/ファイアウォールの背後で動作する必要があります

HTTPCoreでいくつかのテストを行いましたが、結論としては、クライアントとサーバーの両方を実装する必要があり、トランスポート層のみがカバーされるということです。RMI は、ネットワーク関連の要件のため、オプションではありません。

どんなアイデアでも大歓迎です。

詳細

私の考えは、クライアント通信 (ユーザー/パスワードの検証を含む) を処理し、着信要求を JMS キューに書き込むクライアント/サーバー ラッパーを実装することです。

#1  User --> Wrapper (Check for user/password) --> JMS --> "Server"
#2  User polls Wrapper which polls JMS

個別のプロセスがリクエストを処理し、ラッパーを介してクライアントに応答できます。JMS を使用したい理由は次のとおりです。

  • それは永続性を非常にうまく処理します
  • 負荷分散 - コンシューマーとしてサーバーを追加することで、ピークを簡単に処理できます
  • JMSTimeToLive も便利です

残念ながら、JMS を単独で使用する方法はわかりません。クライアントは自分のメッセージにしかアクセスできず、JMS 側で別のユーザーを設定することもできないためです。

4

7 に答える 7

3

HTTP は、それを実装するクライアント コードとサーバー コードの点でおそらく最もよくサポートされていますが、要件によっては完全に不適切な場合もあります。実際に適切なアドバイスを行う前に、いくつかの要件 (または少なくともアプリケーションがどのようなものかについての漠然とした考え)を実際に確認する必要があります。

于 2009-01-16T16:31:13.493 に答える
2

RMIは私たちにとってうまく機能します。そのコンピューターに直接接続できない限り、クライアントにコールバックできないなどの制限があります（クライアントがファイアウォールの背後にある場合は機能しません）。通信をSSLで簡単にラップしたり、SSLでラップできるHTTP経由でトンネリングしたりすることもできます。

これを使用することになった場合は、クライアントに配布されるクラスのシリアルバージョンを常に設定することを忘れないでください。作成時に1Lに設定できます。または、クライアントにすでにクラスがある場合は、serialver.exeを使用して既存のクラスのシリアルを検出します。そうしないと、パブリックメソッドを変更または追加するとすぐに、または既存のクライアントとの変数の互換性が失われます。

static final long serialVersionUID = 1L

編集：サーバーに着信する各RMI要求は、独自のスレッドを取得します。これを自分で処理する必要はありません。

編集：私はいくつかの詳細が質問の後半に追加されたと思います。RMIをHTTP経由でトンネリングしてから、ロードバランサーを使用できます。

私は最近ヘシアンと遊び始めました、そしてそれは多くの約束を示しています。HTTPをネイティブに使用するため、RMI over HTTPよりも単純であり、バイナリプロトコルであるため、すべてのXMLベースのプロトコルよりも高速です。ヘシアンを動かすのはとても簡単です。最近、Jettyをアプリに埋め込み、Hessianサーブレットを構成し、APIインターフェースを実装することでこれを行いました。Hessianの優れている点は、その単純さです...JMSやRMIoverHTTPのようなものはありません。他の言語のヘシアン用のライブラリもあります。

于 2009-01-16T16:42:26.250 に答える
1

与えられた情報に基づいて提案を行うことは困難ですが、クライアントごとに動的に作成された PTP 宛先など、TemporaryQueues の使用が問題に適合する可能性がありますか?

ここに合理的な概要があります。

于 2009-01-16T16:59:03.017 に答える
1

RMIまたはCORBAを試しましたか? それらの両方を使用すると、ロジックを配布してセッションを作成できます

于 2009-01-16T17:03:35.800 に答える
1

Java 用のクライアント/サーバー通信パッケージは、最適に実装されているとは言えませんが、最もサポートされているのは、Sun の RMI (Remote Method Invocation) です。これは、標準の Java クラス ライブラリに含まれており、最速のオプションではない場合でも、仕事を完了できます。そしてもちろん、それは Sun によってサポートされています。数年前にターンベースのゲーム フレームワークを実装しましたが、非常に安定していました。

于 2009-01-16T16:33:33.413 に答える
1

Spring を使用....次に、プロトコルを選択します。

于 2009-01-16T18:13:48.873 に答える
0

クライアント層で Adob​​e Flex/AIR を使用し、中間層スタックで Java6/Tomcat6/BlazeDS/Spring-Framework2.5/iBATIS2.3.4/ActiveMQ-JMS5.2 を使用しているため、Adobe の AMF で標準化しています ( Oracle 10g バックエンド)。

Flex のクライアント側開発を標準化しているため、AMF と BlazeDS (Adobe と SpringSource が統合に協力したおかげで、Spring との結合が改善されました) は、サーバー側と対話するために採用できる最も効率的で便利な手段です。

また、データ センターで JMS メッセージングを大幅に構築しています。BlazeDS により、Flex クライアントを JMS トピック サブスクライバーとしてブリッジすることができます。それは非常に強力で効果的です。

当社の Flex .swf および Java .class コードは、デプロイ用に同じ .jar ファイルにバンドルされています。こうすることで、クライアント サービス呼び出し (またはメッセージング操作) を処理する対応する中間層の Java コードと対話するために、正しいバージョンのクライアント コードがデプロイされます。これは常に、クライアント/サーバー コンピューティングの悩みの種でした。それぞれの層の正しいバージョンが相互に接続されていることを確認します。私たちは、パッケージ化と展開に対する独自のアプローチにより、長年の問題を効果的に解決しました。

すべてのクライアント サーバー インタラクションは、HTTP/HTTPS ポート 80 および 443 を介して機能します。サーバー側のメッセージング プッシュでさえ、ActiveMQ JMS メッセージ ブローカーにブリッジされた BlazeDS を使用して行います。

于 2009-01-16T16:36:32.720 に答える