Allow BPEL Processes To Be Provided Over JMS
--------------------------------------------
Key: ODE-345
URL: https://issues.apache.org/jira/browse/ODE-345
Project: ODE
Issue Type: New Feature
Components: BPEL Runtime
Affects Versions: 1.3
Environment: This feature is platform-independent.
Reporter: Karthick Sankarachary
Fix For: 1.3
In general, the requirements as follows:
a) Allow two or more processes to provide the same service over (the same) JMS
Queue endpoint.
b) Allow two or more processes to provide the same port type (but different
service) over (the same) JMS Queue endpoint.
c) Allow two or more processes to provide the same service over (the same) JMS
Topic endpoint.
d) Allow two or more processes to provide the same port type (but different
service) over (the same) JMS Topic endpoint.
e) Allow a process to invoke a service (or process) over a JMS endpoint.
We work with the following assumptions:
a) Operations provided over JMS Topics must be one-way (to avoid multiple
responses per request)
b) Operations provided over JMS queues may be either one-way or two-way.
c) As per Axis2 protocol, non-durable or non-existent destination names will be
qualified with either dynamicQueues or dynamicTopics.
The limitations in the existing code base are:
a) The name that we assign to axis services is derived from the soap:location
endpoint, which is assumed to follow an HTTP scheme.
b) It is not possible to have two processes provide the same service, as that
leads to naming conflicts.
c) By default, the JMS transport is not enabled in Axis2.
The proposed (verified) solution is:
a) For testing purposes, enable the JMS transport in axis2.xml. Note that by
default, this will be not be turned on. The configuration of JMS in Axis2, and
setup of the JMS broker is left as an exercise for the user/developer.
b) Derive service names from jms endpoints, without making the assumptions made
for HTTP endpoints. Further, qualify the JMS endpoint with the bundle, diagram
and process name, so as to make it unique (this is necessary to avoid the
naming conflict). To be precise, the JMS URI template is as follows:
${deploy_serverUrl}${deploy_baseSoapServicesUrl}/${deploy_bundleNcName}/${diagram_relativeURL}/${processLocalName}/${jmsDestinationName}
c) Extract the jms destination name from the service name, and set it as the
value of the JMSConstants.DEST_PARAM of the axis service (this is required so
that the JMS Connection Factory creates the right destination for that endpoint)
d) Store the axis service in ODEServer against the unique name as was derived
above. Use that name while destroying that service as well.
e) As far as requirement (e), I believe this works out of the box.
f) As far as assumption (a), I believe this constraint should be enforced by
the modeler. Also, the modeler should enforce assumption (c) for proper
provisioning of processes over JMS.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
