請求回覆範圍與請求響應交換模式

我想了解request-reply scope的用例何時會優於request-response exchange pattern？特別是如果底層傳輸是JMS，我使用交換模式或範圍將從流程的角度在內部和功能上完成相同的事情。請求回覆範圍與請求響應交換模式

在維護關聯ID和replyTo屬性詳細信息here和here時，有一些使用請求 - 回覆範圍的麻煩，如果使用請求 - 響應交換模式，是否會存在相同的挑戰？（我猜是的，有人可以請確認）

基本上當過度的請求 - 響應交換模式

更新我的問題，以進一步探討的請求 - 應答範圍的行爲，請使用請求 - 應答。

在接受的答案中提到的第一個用例中試驗請求 - 應答範圍的使用。

使用案例1

端點本身不支持請求作出反應並仍然您要模擬同步

我創建類似下面的流程，我都沒有消息，測試了這個物業變壓器太（相同的行爲）

Request-reply use case

實際behviour是請求等待過，該文件被成功寫入即使後，得到的答覆永遠不會接觸到出站VM

我流的代碼如下

<flow name="request-replyflowtest"> 
     <http:listener config-ref="Orders_HTTP_Listener_Configuration" path="/rr" doc:name="request-reply-test"/> 
     <set-payload value="Hello world" doc:name="Set Payload"/> 
     <message-properties-transformer overwrite="true" doc:name="Message Properties" > 
      <add-message-property key="MULE_REPLYTO" value="vm://back"/> 
      <add-message-property key="MULE_CORRELATION_ID" value="#[java.util.UUID.randomUUID().toString()]"/> 
     </message-properties-transformer> 
     <request-reply doc:name="Request-Reply"> 
      <file:outbound-endpoint path="C:\Users\sudarshan.sreenivasan\Desktop" outputPattern="hello.txt" responseTimeout="10000" doc:name="File"/> 
      <vm:inbound-endpoint exchange-pattern="one-way" path="back" doc:name="VM"/> 
     </request-reply> 
     <logger message="response not written out" level="INFO" doc:name="Logger"/> 
     <set-payload value="This is from a different flow" doc:name="Set Payload"/> 
    </flow>

來源

2015-05-08 Sudarshan

基本上你應該去請求 - 響應在大多數情況下，除了在案件：

端點本身不支持請求作出反應並仍然要模擬同步
要發送一個reques t發送給一種傳輸方式，期望發送不同的響應，即：發送給jms期望響應在amqp
你想發送一個請求到一個連接器，並期望不同的響應，例如：發送到jms連接器期待響應jms連接器b

來源

2015-05-08 14:42:45

謝謝，聽起來合乎邏輯，你能舉個例子來說明「端點本身不支持請求響應，但你仍然想模擬同步性」嗎？ – Sudarshan

MQTT可能是一個例子。某些TCP協議甚至是FILE。 –

可能的燈泡時刻 - 如果我們在請求響應範圍內的請求階段使用File outbound，那麼在整個文件寫入完成之前它不會調用響應階段？也會騾子照顧維護消息中的關聯ID？ – Sudarshan

請求回覆範圍與請求響應交換模式

回答

相關問題