|
If you were logged in you would be able to see more operations.
|
|
|
|
Time Tracking:
|
|
Original Estimate:
|
168h
|
|
|
Remaining Estimate:
|
168h
|
|
|
Time Spent:
|
Not Specified
|
|
|
|
|
File Attachments:
|
| |
Size |
|
jms.txt |
2008-08-18 11:10 PM |
Karthick Sankarachary |
28 kB |
|
|
Environment:
|
This feature is platform-independent.
|
|
Issue Links:
|
Reference
|
|
This issue relates to:
|
|
ODE-568
Undeploying a process does not remove corresponding service from ODE axis2
|
|
|
|
|
|
|
|
| Resolution Date: |
23/Jul/08 03:46 PM
|
|
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.
|
|
Description
|
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. |
Show » |
|
New Feature
Closed
