Hi Deepal
I consider this as a new feature improvement and not a quick fix defect
for 1.3. As we have also considered the JMS support enhancements as per
the specs sent over by Glen to the Axis2 list sometime back, I think we
should handle this at the same time together. I would be happy to do
this change - but it would not be possible in the very short term.
asankha
Deepal Jayasinghe (JIRA) wrote:
[ https://issues.apache.org/jira/browse/AXIS2-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Deepal Jayasinghe reassigned AXIS2-1665:
----------------------------------------
Assignee: Asankha C. Perera (was: Sanka Samaranayake)
Hi Asankha,
Could you please have a look at this.
JMS destination should not be dedicated to only a single service
----------------------------------------------------------------
Key: AXIS2-1665
URL: https://issues.apache.org/jira/browse/AXIS2-1665
Project: Axis 2.0 (Axis2)
Issue Type: Improvement
Components: transports
Environment: Not important
Reporter: Ali Sadik Kumlali
Assignee: Asankha C. Perera
Priority: Minor
I'm creating this issue to address the improvements of JMS destination usage discussed in the axis-dev [1].
Here is the summary:
Requirements
---------------------------------------------------
- A single destination can be used for messages of different services
- Multiple destinations can be used for messages of the same service
Proposal
---------------------------------------------------
At client side:
- Including the service name in the EPR (JMS URL)
- Adding service name to the JMS message header before sending it (the same approach used for transferring SOAPAction)
At service side:
- Setting "to" field of the MC to the value of service name field retrieved from JMS message header.
- Setting "soapAction" field of the MC to the value of SOAPAction field retrieved from JMS message header (this is already done with the current implementation).
Advantages of the proposal
---------------------------------------------------
- Being more consistent with the other tranports, as all of them include service name to EPR
- No need for an association between destination and service, thus no need destination-service association in services.xml
- Being able to use a single destination for multiple services
- Being able to dispatch messages come from different destionations to the same service
[1] http://www.mail-archive.com/[email protected]/msg24261.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|
