[
https://issues.apache.org/jira/browse/ODE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthick Sankarachary resolved ODE-431.
---------------------------------------
Resolution: Fixed
The patch was applied at revision 718818.
> Enable JMS-Based Round Tripping
> -------------------------------
>
> Key: ODE-431
> URL: https://issues.apache.org/jira/browse/ODE-431
> Project: ODE
> Issue Type: Improvement
> Environment: platform-independent
> Reporter: Karthick Sankarachary
> Assignee: Karthick Sankarachary
> Attachments: jms-based-round-tripping.txt
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> When a process interacts with an external service over JMS, chances are that
> it will use one-way messages. This is due to the fact that, in the
> asynchronous world of JMS, the request-response MEP is typically implemented
> using two one-way WSDL operations. Let's consider the case where a process
> sends a JMS request to the external service, which in turn sends a JMS
> response back. In order for this to work, a couple of things have to happen:
> a) The JMS Correlation ID header in the request message must carry the
> implicit correlation token that uniquely identifies the process instance (see
> http://ode.apache.org/stateful-exchange-protocol.html).
> b) The JMS ReplyTo header in the request message must carry the name of the
> JMS destination where the response must be sent, which by default should be
> set to the myRole EPR corresponding to the <invoke> activity.
> The engine uses the correlation token in the response message to determine
> which process instance receives it. Needless to say, this assumes that the
> external service propagates the JMS correlation ID from the request to the
> response message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
