mule - request-reply scope versus request-reponse exchange pattern -

i trying understand use case request-reply scope when preferred on request-response exchange pattern ?, if underlying transport jms, guessing using exchange pattern or scope same things internally , functionally flow perspective.

there few hassles crop using request-reply scope around maintaining correlation id , replyto properties details here , here , same challenges exist if 1 use request-response exchange pattern ? (i guess yes, can confirm please)

basically when use request-reply on request-response exchange pattern

updating question further probe behavior of request-reply scope.

to experiment use of request-reply scope in first use case mentioned in accepted answer.

use case 1

the endpoint not support request-reponse , still want simulate synchronicity

i created flow below, have tested without message property transformer (same behavior)

the actual behviour request waits ever, after file written, reply never comes outbound vm

my flow code below

<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 different flow" doc:name="set payload"/>     </flow> 

essentially should go request-response in of cases except in cases where:

• the endpoint not support request-reponse , still want simulate synchronicity
• you want send request 1 kind of transport , expect reponse on differnt one, i.e: send jms expect response in amqp
• you want send request 1 connector , expect reponse on differnt one, i.e: send jms connector expect response jms connector b