4

今日、JMS APIを使用してアプリケーションを構築し（MDBをメッセージリスナーとして使用し、GlassFishやWeblogic 10などでホストします）、明日はトラフィックが途方に暮れるとしましょう。コードを変更せずに、このアプリケーションをWebsphereMQなどの製品に移植できますか。 ... coz理論的には、MQは専用のJMSプロバイダーのようなものです...

4

4 に答える 4

4

はいといいえ。（すべての最良の質問に対する答えは常に「状況によって異なります」です。）

アプリケーションがJMS仕様に準拠している場合は、JMS準拠のプロバイダーで変更せずに実行する必要があります。それは良いニュースです。

悪いニュースは、プロバイダーがJMSをどのように実装したかが本当に重要であるということです。たとえば、JMS 1.1仕様のセクション6.5には、トピックについて次のように記載されています。

多くのPub/Subプロバイダーは、トピックを階層にグループ化し、階層の一部をサブスクライブするためのさまざまなオプションを提供します。JMSは、トピックオブジェクトが表すものに制限を課しません。トピック階層のリーフである場合もあれば、階層の大部分である場合もあります（一般的なクラスの情報をサブスクライブするため）。

トピックの編成とそれらへのサブスクリプションの粒度は、Pub/Subアプリケーションのアーキテクチャーの重要な部分です。JMSは、これを行う方法に関するポリシーを指定していません。アプリケーションがプロバイダー固有のトピックグループ化メカニズムを利用する場合は、これを文書化する必要があります。アプリケーションが別のプロバイダーを使用してインストールされている場合、同等のトピックアーキテクチャを構築し、同等のトピックオブジェクトを作成するのは管理者の仕事です。

これが意味するのは、仕様の特定の部分がJMSトランスポートプロバイダーの解釈に開かれているということです。アプリケーションを移植するときにこれらの違いをどのようにマッピングするかを決定するのは、アプリケーションの所有者次第です。

この質問のもう1つの側面は、仕様が2つのトランスポートプロバイダーによって厳密に守られている場合でも、APIの背後にある動作が異なる可能性があることです。この例は、接続管理です。一部のプロバイダーはクライアントへの接続を透過的に失敗させ、他のプロバイダーは失敗後に接続シーケンスを再駆動するようにクライアントに要求します。どちらのアプローチも100％JMS互換である可能性がありますが、どちらも異なるアプリケーションロジックを必要とします。

したがって、答えは、JMS APIに準拠することで、完全な移植性に非常に近くなり、必要な移植の量は、トランスポートプロバイダーが仕様の一部を解釈する方法や、仕様であいまいな実装された機能の違いによって異なります。 。

于 2011-04-13T03:21:54.350 に答える
1

開発者にとって、JMSベースのアプリケーションでベンダー独自の機能を使用したくなる（または必要になる場合がある）と感じるのは非常に簡単です。JMSの使用に費やした短期間で、開発者がプロ​​プライエタリAPIの使用に頼る4つの理由に気づきました。

Destinationまず、ネーミングサービスからオブジェクトを取得することConnectionFactoryは、特にアプリケーションを作成する前にJMS管理コマンドの学習に時間を費やす必要がないJMSを初めて使用する開発者にとっては不便です。Destinationベンダー独自の関数を使用してConnectionFactoryオブジェクトを直接作成する方が便利な場合があります。

第2に、JMS製品は、JMS仕様で定義されている以上のサービス品質を提供するのが一般的です。これらのサービス品質が、たとえば、、またはに関連している場合Session、Producerベンダーがこれらのタイプに対してConsumer独自のset<Name>()操作を提供するのは自然なことです。簡単に言えば、すべての独自のサービス品質を管理対象オブジェクトにカプセル化できるわけではありません。

第3に、JMS関連の操作が失敗すると、（のサブタイプ）がスローされますJMSException。アプリケーションの開発者は、例外の性質に応じて、キャッチされた例外をいくつかの方法のいずれかで処理したい場合があります。ただし、JMS仕様では、によって提供される3つの情報のうち2つJMSExceptionはJMSベンダー独自のものであると規定されています。このため、開発者は、例外の処理方法を決定する際に、例外に含まれるベンダー独自の情報に依存する必要がある場合があります。

最後に、JMSは、メッセージが（1）ヘッダーフィールド、（2）任意のプロパティ（つまり、名前=値ペア）、および（3）本文の3つの部分で構成されることを指定します。（2）の使用目的は、コンシューマーアプリケーションでの柔軟なメッセージ選択をサポートすることです。たとえば、ロンドンで実行されているプロデューサーアプリケーションは、メッセージを送信する前に、メッセージのプロパティにlocation=Londonを追加する場合があります。コンシューマーアプリケーションは、メッセージセレクター"(location = 'London')"を使用して、そのプロパティ値を持つメッセージのみを受信するようにすることができます。いいですね。悪い点は、JMS仕様がで始まるプロパティ名を予約することですJMS_<vendor>JMSベンダーが使用するためのものであり、一部のベンダーはそのようなプロパティを使用して、メッセージごとに独自のサービス品質を指定します。独自のメッセージごとのサービス品質を利用したい開発者は、メッセージを送信する前に独自のプロパティを設定するように、プロプライエタリアプリケーションのコードを変更する必要があります。

トピック階層に関するT.Robの警告は、注意が必要なもう1つの問題です。

于 2011-04-21T15:26:39.193 に答える
0

WebSphere MQは非常に成熟した安定したプラットフォームであり、私が知る限り、JMS標準に完全に準拠しています。多くの組織が、トランスポートとしてJMSoverMQを使用しています。私は、JMSとネイティブMQメカニズムの両方を使用してMQレイヤーと通信するいくつかの作業を行ってきましたが、IBMJMSの実装に関する苦情はありません。ただし、JMSプロバイダーを変更した人とは一緒に仕事をしたことはありません...

IBMは、javax.jmsパッケージのみを参照する多数のJavaライブラリーを提供しています。コードにベンダー固有の拡張機能を含めていない限り、MQライブラリーをスロットに入れてMQをJMSにすることができるはずです。プロバイダー。（JMSサブスクリプションの設定などを行うには、MQツールを使用して管理を行う必要がある場合があります。ただし、MQのJMSアスペクトは使用しておらず、コアライブラリのみを使用しています。）

MQ JMSライブラリーの詳細については、このIBMページを確認してください。

例としてWebSphereMQのみを使用した場合は、はい、候補ベンダーが仕様に準拠しているかどうかを確認する必要があるかもしれませんが、JMSはしばらく前からあり、すべての大手企業が適切なJMSプロバイダーになると思います。 。

于 2011-04-13T05:25:05.580 に答える
0

JMSは（JDBCなどと比較して）比較的単純なAPIであるため、最初にいくつかの基本的な対策を講じれば、実装間で非常に移植性が高くなります。

WebSphereMQからより良いパフォーマンスを得る限り、それが当てはまるかどうかはわかりません。ポイントツーポイントを使用している場合は、おそらく。ただし、Pub / Subを実行している場合は、ほとんどありません。競合他社によって明らかに公開されているこのベンチマーク を参照してください。ただし、サードパーティのベンチマークを使用しており、実際には一部のオープンソースの参加者には非常に寛大です。

于 2011-04-18T19:30:31.297 に答える