24

Web サービスに対する JMS の大きな利点、またはその逆の利点は何ですか?

(Web サービスは肥大化していますか? JMS は全体的にインターフェイスを提供するのに適していますか?)

4

9 に答える 9

29

エリクソンからの修正後に編集：

JMS では、JMS プロバイダー、メッセージを処理するための MessageListener インターフェースを実装する Java クラス、および JMS キューへの接続方法を認識しているクライアントが必要です。JMS は非同期処理を意味します。クライアントはメッセージを送信し、必ずしも応答を待ちません。JMS は、ポイント ツー ポイント キュー方式またはパブリッシュ/サブスクライブで使用できます。

「サービス」は流動的な用語です。私は、サービスをネットワーク上に存在し、「X を送ってくれれば、このタスクを実行して Y を返します」という契約を宣伝するコンポーネントと考えています。

分散コンポーネントは長い間使用されてきました。それぞれが異なるプロトコル (COM、Corba、RMI など) を使用して通信し、さまざまな方法でコントラクトを公開していました。

Web サービスは、分散サービスにおける最新のトレンドです。プロトコルとして HTTP を使用し、TCP/IP 経由で接続して HTTP 要求を行うことができるクライアントと相互運用できます。

SOAP、RPC-XML、REST、または「コントラクト ファースト」スタイルを使用できますが、HTTP をプロトコルとして使用する分散コンポーネントの基本的な考え方はそのままです。

これらすべてを受け入れる場合、Web サービスは通常、同期呼び出しです。肥大化する必要はありませんが、不適切なコンポーネントを任意のスタイルまたは言語で記述できます。

最初にリクエストとレスポンスを設計することで、分散コンポーネントの設計を開始できます。それらを考慮して、必要なクライアントの種類と、通信が同期か非同期かに基づいて、JMS または Web サービスを選択します。

于 2009-05-12T22:57:31.200 に答える
6

JMS を含むメッセージ ベースのシステムは、相手側から「時系列的に切り離す」機能を提供します。メッセージは、相手側が使用可能でなくても送信できます。

他のすべての一般的な A2A アプローチでは、パートナーがすぐに応答できる必要があり、処理を分散する能力がほとんどなく、ピーク負荷を処理できる必要があります。

于 2009-05-12T23:14:40.907 に答える
4

最大の違いは、JMS が RPC 指向ではなくメッセージ指向であることです。すぐに使用できるほとんどの JMS プロバイダーは、再試行を実行し、重複を防止し、トランザクションをサポートする高レベルのプロトコルをサポートしています。

これらの機能が不要なアプリケーションは数多くあります。しかし、それらが必要な場合に、RPC メカニズムの上に自分で構築することは、複雑で費用がかかり、エラーが発生しやすくなります。

于 2009-05-12T23:10:14.143 に答える
3

Web サービスは、サービス指向アーキテクチャ (SOA) の実装です。SOA には、疎結合されたプロバイダー、ブローカー、およびリクエスターの 3 つの関係者があります。プロバイダは、特定の実装を表すビジネス サービスを提供しますが、これはリクエスタには直接見えません。リクエスターは、プロバイダーから送受信する必要がある情報構造と、そのサービスにアクセスするために使用するプロトコルをブローカーから学習します。リクエスタは、プロバイダがビジネス サービスを実装する方法を知りません。

Web サービスは、すべてのビジネス リクエストの共通パイプとしてではなく、リクエスタとプロバイダの間で必要なビジネス インターフェイスとして定義されます。以下を含む、Web サービスを特徴付ける変数がいくつかあります。

  • それらは密結合することができ、それらの展開は呼び出しフレームワークの使用に基づくことができます。
  • これらは、同期要求/応答モードまたは非同期モードで実行できます。
  • これらは、J2EE または非 J2EE プロバイダによって公開できます。
  • トランザクションとセキュリティのサポートを提供する場合と提供しない場合があります。

JMSは非同期メッセージベースのインターフェースです。また、JMS を使用して、異種システム間で分散されたビジネス ロジックにアクセスすることもできます。メッセージベースのインターフェイスを使用すると、次の機能が有効になります。

ポイント ツー ポイントおよびパブリッシュ/サブスクライブ メカニズム。メッセージベースのフレームワークは、明示的に要求しなくても、他のアプリケーションに情報をプッシュできます。同じ情報を多くのサブスクライバーに並行して配信できます。

リズムの独立。JMS フレームワークは非同期モードで機能しますが、同期要求/応答モードをシミュレートする機能も提供します。これにより、ソース システムとターゲット システムが相互に待機することなく同時に動作できます。

保証された情報配信。JMS フレームワークは、トランザクション モードでメッセージを管理し、メッセージ配信を保証できます (ただし、配信の適時性は保証されません)。

異種フレームワーク間の相互運用性。ソース アプリケーションとターゲット アプリケーションは、それぞれのフレームワークに関連する通信と実行の問題を処理する必要なく、異種環境で動作できます。

交換をより流動的にする。メッセージ モードに切り替えると、よりきめ細かい情報交換が可能になります。

ここに画像の説明を入力

ソース

于 2015-12-18T01:04:41.430 に答える
2

Web サービスの SOAP プロトコル実装について話させてください...JMS と Web サービスのどちらが優れているか....JMS はトランスポート プロトコルを提供し、それは基礎となるメッセージング プロバイダーであり、たとえば MQ は強力な JMS プロバイダーの良し悪しを示します。 SOAP プロトコルは、アプリケーション レベルのプロトコルとトランスポート プロトコル (SOAP/HTTP の意味で) の両方と見なすことができる信頼性の高い JMS プロバイダーです...SOAP の利点は、XML ベースの標準をサポートすることです...アプリケーション レベル プロトコルでは、SOAP を任意のトランスポート プロトコルを介してあるシステムから別のシステムに渡されるメッセージと見なします。トランスポート プロトコルとして、SOAP はペイロード (メッセージ データ) をトランスポートするためのコンテナーと見なすことができます...SOAP/HTTP は、 JMS メッセージング プロバイダとも見なされますが、後者の形式では、HTTP には信頼性の問題があり、ネットワーク、ソケット接続、帯域幅などに関連するエラーを伴うため...長い話を短くすると、信頼できるメッセージプロバイダーを備えたJMSは、アプリケーションレベルのプロトコルとしてのWebサービスが異なるアプリケーションを使用して通信する優れたトランスポートプロトコルと対話するための優れた標準になりますXMLのようなSOAPプロトコル...これが明確になることを願っています...

于 2010-12-05T17:35:43.567 に答える
1

これを dyffymo の投稿にコメントとして追加しますが、まだ担当者がいません。

あなたの答えから引用：

「Web サービスは、分散型サービスの最新のトレンドです。プロトコルとして HTTP を使用し、TCP/IP 経由で接続して HTTP 要求を行うことができる任意のクライアントと相互運用できます。

SOAP、RPC-XML、REST、または「コントラクト ファースト」スタイルを使用できますが、HTTP をプロトコルとして使用する分散コンポーネントの基本的な考え方はそのままです。」

Web サービスとは、WS-* プロトコル、WSDL、および SOAP のセットを意味していると思います。もしそうなら、これらのどれも「トランスポート」プロトコルとして HTTP を使用する必要はありません。SOA プロトコル セットは、使用される伝送プロトコルに依存しないように設計されているため、Web サービスとの間でメッセージを送受信する手段として、HTTP、NamedPipes、生の TCP、さらには JMS を使用できます。

したがって、JMS の直接使用と「Web サービス」の使用の場合、ほとんどの場合、ツール、快適さのレベル、および JMS 固有の機能 (WS-* を使用すると非表示になる) に直接アクセスする必要があるかどうかに帰着すると思います。あなた）。現時点では、生の JMS アクセスを必要とするのはかなり専門化されたアプリケーションだけだと思います。

于 2009-05-13T05:01:07.487 に答える
1

JMS - JMS プロバイダーに縛られている - ただし、実装タイプ (pub/sub、ポイント ツー ポイント) の選択肢がある Web サービス - 処理/設計が容易- ただし、ボックス間の直接通信に近いものです。開発を行うために使用する多くのツールと、クリーンなインターフェース (WSDL) により、実装者と呼び出し元を独立させることができます。

どちらを使用しますか？問題の内容によって異なります。

于 2009-05-12T23:04:36.713 に答える
0

JMS と WS はどちらもアプリケーションの配布を可能にします。違いは、非同期 (JMS) と同期 (Web サービス) です。Web サービスは、SOAP または REST スタイルで実装できます。JMS は、ポイント ツー ポイントとパブリッシュ サブスクライブの 2 つのモードでの通信をサポートする API です。Apache ActiveMQ、RabitMQ は、多くの JMS 実装者の一部です。

于 2016-11-10T19:20:52.353 に答える
0

それはすべて、要件、使用するフレームワーク、およびアプリケーション環境と動作によって異なります。それについて概要を説明できれば、厳密な答えを得ることができます。

これは、トラックとセダンを比較するようなものです。どちらが優れているかを判断するには、トラックを何に使用し、どの道路で使用するかを知る必要があります。

于 2013-09-17T01:20:27.587 に答える