2015-05-08 2 views
3

Я пытаюсь понять прецедент для request-reply scope, когда это было бы предпочтительнее, чем request-response exchange pattern?, Особенно если базовый транспорт JMS, я предполагаю, используя шаблон обмена или объем будет делать то же самое внутреннее и функциональное с точки зрения потока.модель запроса-ответа по сравнению с шаблоном обмена ответами-ответами

Есть несколько проблем, возникающих при использовании области запроса-ответа при сохранении идентификатора корреляции и ответа на свойства свойств here и here, будут ли возникать те же проблемы, если вы используете шаблон обмена запрос-ответ? (Я думаю, да, кто-то может подтвердить пожалуйста)

В основном, когда использовать запрос-ответ по запросу-ответ шаблона обмена

Обновления моего вопроса для дальнейшего зонда в поведение запроса ответ области.

Экспериментально использовать область запроса-запроса в первом варианте использования, упомянутом в принятом ответе.

Use Case 1

Конечной сама не поддерживает запрос-réponse и до сих пор вы хотите имитировать синхронности

Я создал поток, как показано ниже, я испытал это без сообщения свойство трансформатора тоже (такое же поведение)

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> 

ответ

4

По сути вы должны пойти на запрос-ответ в большинстве случаев, за исключением тех случаев, когда:

  • сама конечная точка не поддерживает запрос-réponse и все же вы хотите, чтобы имитировать синхронности
  • вы хотите послать reques t к одному виду транспорта и ожидать отклика на другой, т. е. отправить в jms ожидать ответа в amqp
  • Вы хотите отправить запрос на один разъем и ожидать отклика на другой, то есть: отправить в jms-коннектор a ожидать ответ jms-коннектор b
+0

Спасибо, звучит логично, можете ли вы привести пример для «Конечная точка сама по себе не поддерживает запрос-ответ, и все же вы хотите имитировать синхронность»? – Sudarshan

+1

MQTT может быть примером. Некоторые протоколы TCP даже FILE. –

+0

Возможный момент лампы накаливания. Если мы используем исходящий файл на этапе запроса в области запроса-ответа, он не будет вызывать фазу ответа до завершения всей записи файла? также будет ли mule заботиться о поддержании идентификатора корреляции в сообщениях? – Sudarshan

Смежные вопросы