JMSとWebサービス
Webサービスに対するJMSの大きな利点は何ですか？またはその逆は何ですか？
（Webサービスは肥大化していますか？JMSはインターフェイスを提供するのに全体的に優れていますか？）
エリクソンからの修正後に編集：
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サービスを選択します。
JMSを含むメッセージベースのシステムは、もう一方の端から「時系列的に分離」する機能を提供します。もう一方の端を使用せずにメッセージを送信できます。
他のすべての一般的なA2Aアプローチでは、パートナーがすぐに応答できる必要があり、処理を分散する能力がほとんどなく、ピーク負荷を処理できる必要があります。
最大の違いは、JMSがRPC指向ではなくメッセージ指向であるということです。すぐに使用できるほとんどのJMSプロバイダーは、再試行を実行し、重複を防ぎ、トランザクションをサポートする高レベルのプロトコルをサポートします。
これらの機能が不要なアプリケーションはたくさんあります。ただし、必要な場合は、RPCメカニズムの上に自分で構築するのは複雑で、費用がかかり、エラーが発生しやすくなります。
wrt SOAP Webサービスのプロトコル実装...これはJMSとWebサービスのどちらが優れているか.... JMSはトランスポートプロトコルを提供し、それは基礎となるメッセージングプロバイダーであり、どれだけ良いか悪いかを示します。たとえばMQのJMSプロバイダーは強力で信頼性の高いJMSプロバイダーであり、SOAPプロトコルはアプリケーションレベルのプロトコルと見なすことができ、（SOAP/HTTPの意味で）トランスポートプロトコルとして扱うこともできます。 .. SOAPはXMLベースの標準をサポートしています...アプリケーションレベルのプロトコルとして、SOAPから渡されるメッセージと見なしますトランスポートプロトコルとして、SOAPはペイロード（メッセージデータ）をトランスポートするためのコンテナと見なすことができます... SOAP/HTTPはJMSと見なすこともできます。メッセージングプロバイダー....しかし後者の形式では、HTTPはネットワーク、ソケット接続、帯域幅などに関連するエラーを含むため、信頼性の問題があります...したがって、長い話を短くして、JMSとre責任あるメッセージプロバイダーは、アプリケーションレベルのプロトコルとしてのWebサービスが異種のアプリケーションにXMLのようなSOAPプロトコルを使用して通信させる優れたトランスポートプロトコルと対話するための優れた標準になります...これが明確になることを願っています...
Webサービスは、サービス指向アーキテクチャー（SOA）の実装です。 A SOAには、プロバイダー、ブローカー、リクエスターの3つのパーティがあり、これらは疎結合です。プロバイダーは、特定の実装を表すビジネスサービスを提供しますが、リクエスターには直接表示されません。 。リクエスターは、プロバイダーとの間で送受信する必要のある情報構造と、そのサービスにアクセスするために使用するプロトコルをブローカーから学習します。リクエスターは、プロバイダーがビジネスサービスを実装する方法を知りません。
Webサービスは、すべてのビジネスリクエストに共通のパイプとしてではなく、リクエスターとプロバイダーの間に必要なビジネスインターフェイスとして定義されます。 Webサービスを特徴づけることができるいくつかの変数があります。
- それらは緊密に結合することができ、それらのデプロイメントは呼び出しフレームワークの使用に基づくことができます。
- これらは、同期要求/応答モードまたは非同期モードのいずれかで実行できます。
- これらは、J2EEまたは非J2EEプロバイダーによって公開される可能性があります。
- トランザクションとセキュリティのサポートを提供する場合と提供しない場合があります。
[〜＃〜] jms [〜＃〜]は非同期メッセージベースのインターフェースです。また、JMSを使用して、異種システムに分散されたビジネスロジックにアクセスすることもできます。メッセージベースのインターフェイスを使用すると、次の機能が有効になります。
ポイントツーポイントおよびパブリッシュ/サブスクライブメカニズム。メッセージベースのフレームワークは、明示的に要求することなく、他のアプリケーションに情報をプッシュできます。同じ情報を多くの加入者に並行して配信できます。
リズムの独立性。JMSフレームワークは非同期モードで機能しますが、同期要求/応答モードをシミュレートする機能も提供します。これにより、ソースシステムとターゲットシステムは、互いに待つことなく同時に動作できます。
保証された情報配信。 JMSフレームワークは、トランザクションモードでメッセージを管理し、メッセージの配信を保証できます（ただし、配信の適時性は保証されません）。
異種フレームワーク間の相互運用性。ソースアプリケーションとターゲットアプリケーションは、それぞれのフレームワークに関連する通信と実行の問題を処理することなく、異種環境で動作できます。
交換をより流動的にする。メッセージモードに切り替えると、よりきめ細かい情報交換が可能になります。
これをdyffymoの投稿へのコメントとして追加しますが、まだ担当者がいません。
あなたの答えからの引用：
「Webサービスは分散サービスの最新のトレンドです。WebサービスはプロトコルとしてHTTPを使用し、TCP/IP経由で接続してHTTPリクエストを行うことができる任意のクライアントと相互運用できます。
SOAPまたはRPC-XMLまたはRESTまたは「コントラクトファースト」スタイルを使用できますが、プロトコルとしてHTTPを使用する分散コンポーネントの基本的な考え方は変わりません。 「」
Webサービスとは、WS- *プロトコル、WSDL、およびSOAPのセットを意味すると思います。もしそうなら、これらのどれも「トランスポート」プロトコルとしてHTTPの使用を必要としません。 SOAプロトコルのセットは、使用される伝送プロトコルにとらわれないように設計されているため、HTTP、NamedPipes、raw TCP、さらにはJMSを使用してメッセージを送受信できます。ウェブサービス。
したがって、JMSを直接使用する場合と「Webサービス」を使用する場合は、ほとんどの場合、ツール、快適さのレベル、およびJMS固有の機能（WS- *を使用すると非表示になる）に直接アクセスする必要があるかどうかに要約されます。君は）。この時点で、かなり仕様化されたアプリケーションのみが生のJMSアクセスを必要とすると思います。
私が行ったものから、私が見つけた違いは次のとおりです。JMS-私はJMSプロバイダーに縛られています-しかし、実装タイプ（pub/sub、ポイントツーポイント）Webサービスの選択肢があります-処理/アーキテクチャが簡単です-ただし、ボックス間の直接通信の方が多いです。開発を行うために使用する多くのツールと、実装者と呼び出し元を独立させることができるクリーンなインターフェース（WSDL）。
どちらを使用しますか？問題が何であるかに依存します。
それはすべて、要件、使用するフレームワーク、およびアプリケーションの環境と動作によって異なります。あなたがそれについての概要を与えることができれば、あなたは厳格な答えを得ることができます。
これは、トラックとセダン車を比較するようなものです。どちらが優れているかを判断するには、トラックを何に使用し、どの道路で使用するかを知っておく必要があります。
JMSとWSはどちらも、分散アプリケーションを有効にします。違いは、非同期（JMS）と同期（Webサービス）です。 WebサービスはSOAPまたはRESTスタイルで実装できます。JMSは、ポイントツーポイントとパブリッシュ/サブスクライブの2つのモードでの通信をサポートするAPIです。 Apache ActiveMQ、RabitMQは、多くのJMS実装者の一部です。