请求-回复范围与请求-响应交换模式

request-reply scope versus request-reponse exchange pattern

我正在尝试了解 request-reply scope when would this be preferred over request-response exchange pattern 的用例?,特别是如果底层传输是 JMS,我猜测使用交换模式或范围将在内部和功能上做完全相同的事情流动的观点。

在维护关联 ID 和 replyTo 属性详细信息方面使用请求-回复范围会出现一些麻烦 here and here,如果使用请求-响应交换模式,是否会存在相同的挑战? (我猜是的,有人可以确认一下吗)

基本上什么时候在请求-响应交换模式上使用请求-回复

更新我的问题以进一步探究请求-回复范围的行为。

在接受的答案中提到的第一个用例中试验请求-回复范围的使用。

用例 1

The endpoint itself does not support request-reponse and still you want to simulate synchronicity

我创建了如下所示的流程,我已经在没有消息 属性 转换器的情况下进行了测试(相同的行为)

实际的行为是请求永远等待,即使在文件成功写入之后,回复也永远不会进入出站 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>

基本上,在大多数情况下,您应该进行请求-响应,但以下情况除外:

  • endpoint本身不支持request-response,还想模拟同步
  • 您想向一种传输方式发送请求并期望在不同的传输方式上得到响应,即:发送到 jms 期望在 amqp 中得到响应
  • 您想向一个连接器发送请求并期望在另一个连接器上得到响应,即:向 jms 连接器发送一个期望响应的 jms 连接器 b