これが私がスタックオーバーフローを愛する理由です。私はこれについて聞いたことがありません!!!
「自動応答」は、ラバの動作によって引き起こされる可能性があります。
mule が message 内のreply_toプロパティを検出すると、そのエンドポイントへの自動応答を起動します。これは、jms の要求と応答の機能のためですが、http コネクタに影響している可能性があります。
このソース:
メッセージ送信時の自動応答
---------------*----------------------------
調査の結果、 ws-addressing の適切な動作は次のとおりであることがわかりました。
client -- SOAP request ( on port A ) --> server
client <-- HTTP 202 ( "Hello, i will send the response soon" HTTP body ) --- server
client <-- SOAP response ("Response is ready!!" on port B ) --- server
ソース: jax-ws 2.2.8 および ws-addressing
これを可能にするには、次のものが必要です。
1.- サーバー エンドポイント : mule/cxf
2.- サービスのクライアント : soapui
3.- コールバック エンドポイント :非同期応答を受信する (これはラバにあると思います)
これを理解しましたが、それに関する公式ドキュメントは悲しいです:
MULE 3.7 WS-Addressing の有効化
非同期応答を作成して実行するには、CallBack Enpoint が必要だと思います。ラバには何も見つかりませんでした:(。
ここにJava実装のリンクがいくつかありますが、ミュールはありません:
WS-Addressing による非同期 Web サービス
JAX-WS および WS-Addressing を使用して単一ポートの非同期サービスを呼び出す
---------------*----------------------------
別の解決策は次のとおりです。
1.- アドレス指定なしの mule/cxf の Web サービス。
2.- 内部操作方法 :
public Response operation ( Request requestPayload ) {
MuleClient client = new MuleClient(muleContext);
client.dispatch("jms://my.queue", requestPayload , null);// this is async
return new Response("Hello, i will send the response soon.");
}
参照 : Mule クライアントの使用
3.- リッスンする jms インバウンド エンドポイントを作成します: jms://my.queue
<flow>
<jms:inbound-endpoint queue="my.queue" >
<do something>
<launch a response to client>
</flow>
これは次のようになります。
a.- クライアントへのメール
b.- クライアントによって公開されたサービスを利用する
c.- SMS 通知
d.-何でも
このアプローチはより柔軟で、将来のクレイジーな要件をサポートできます。
mule cxf サービスまたは jms についてサポートが必要な場合は、お知らせください。
http://jrichardsz.github.io/