+1000 from me.
thanks,
dims
On 6/14/06, Asankha C. Perera <[EMAIL PROTECTED]> wrote:
While trying to support JMS proxy services for Synapse, I came across a few
issues with the current JMS support in Axis2
The current Axis2 support for JMS requires you to define the destination
(queue or topic) at the transport receiver level.
e.g.
<transportReceiver name="jms"
class="org.apache.axis2.transport.jms.SimpleJMSListener">
<parameter name="transport.jms.Destination"
locked="false">dynamicQueues/InvesbotJMSProxy</parameter>
<parameter name="java.naming.factory.initial"
locked="false">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
<parameter name="java.naming.provider.url"
locked="false">tcp://localhost:61616</parameter>
</transportReceiver>
This seems to have two limitations, as you could only define the transport
receiver for JMS (with the name "jms") only once, and there you need to
specify the (single) JMS destination. Hence being able to listen for JMS
messages on more than one destination is confusing and probably not properly
supported?
If I deploy the above configuration and two services to use the JMS
transport, for both of them I get the same EPR as follows, which is a defect
jms:/dynamicQueues/InvesbotJMSProxy?transport.jms.Destination=dynamicQueues/InvesbotJMSProxy
&java.naming.provider.url=tcp://localhost:61616&java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
Once a message arrives at the above destination, it does not get dispatched
to either service, and currently results in a service not found fault.
Proposal
I think that the transportReceiver for JMS should just define just the JMS
connection properties (without specifying a destination). It would be good
to be able to support more than one such connection, so that we could
connect to multiple JMS servers in future.
e.g.
<transportReceiver name="jms" name="connector1"
class="org.apache.axis2.transport.jms.JMSConnector">
[<parameter name="transport.jms.DestinationPrefix"
locked="false">some/queuePrefix</parameter>]
<parameter name="java.naming.factory.initial"
locked="false">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
<parameter name="java.naming.provider.url"
locked="false">tcp://localhost:61616</parameter>
</transportReceiver>
Then a service should get the EPR as
jms://[${transport.jms.DestinationPrefix}]/<serviceName>?
&java.naming.provider.url=tcp://localhost:61616&java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
A service.xml should be able to specify an optional property
JMS_DESTINATION_TYPE as either a QUEUE or TOPIC and optionally the name of
the destination through which it wishes to receive messages via a
JMS_DESTINATION_NAME property.
If these are specified, it should override the use of the service name in
the destination and the EPR would be of the form
jms://${JMS_DESTINATION_NAME}?&java.naming.provider.url=tcp://localhost:61616
&java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
If the destination type was not specified, we should default to a Queue
(probably?).
The dispatcher should then use the JMS destination to determine the service
to dispatch to.
I would be performing some changes to accommodate the above, and also
support JMS Map, Byte and Text messages in Axis2 - of which I will keep the
list posted on the specifics soon.
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas : http://wso2.com/blogs/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
