[
https://issues.apache.org/jira/browse/ODE-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthick Sankarachary updated ODE-345:
--------------------------------------
Attachment: (was: jms.txt)
> 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
> Assignee: Matthieu Riou
> Fix For: 1.3
>
> Attachments: jms.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> 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.
