Hi Asankha,
My project is not in production now. But will be :). So, JMS support is very
important. I had spent some time with asynchrony over HTTP, but then chose JMS.
When it comes to JMS, I first ecountered the implementation ported from Axis
and couldn't get into too much. The new implementation, which is written from
the ground up, seemed very promising as it looked more comprehensible. But, for
the production environment, I needed to use message driven bean as listener
instead of SimpleJMSListener. So, wrote down an MDB as JMS listener. For the
client side, on the other hand, I'm using JMSSender of Axis2 distro.
I haven't done any load and performance tests, yet. But, so far, there have
been no problem.
After my project's first phase is ready to test, I'm planning to work on the
improvements of client side implementation of the current JMS support. I've
created issues[1] related with that and beleive that we can make it better.
Should I create an improvement issue regarding with the current topic: "Why a
JMS destination should be dedicated to only a single service (and vice-versa)?"
Regards,
Ali Sadik Kumlali
[1]
AXIS2-869, AXIS2-868, AXIS2-1069
----- Original Message ----
From: Asankha C. Perera <[EMAIL PROTECTED]>
To: [email protected]
Sent: Monday, November 6, 2006 1:38:38 PM
Subject: Re: [Axis2][1.1 Nightly] Why a JMS destination should be dedicated to
only a single service (and vice-versa)?
Hi Ali
Great to hear that you got your immediate problem solved or at least have
found a work around.. I haven't been able to look at your fix it in detail yet,
but will plan to do so. Also it is good to hear that you have now been using
the JMS transport for some time .. is it in use with any production
applications? If so, I would like to hear back from you if you have encountered
any resource issues (connections/memory etc) etc.. and if you haven't.. then
thats even better!
thanks
asankha
Ali Sadik Kumlali wrote: Hi Asankha,
Thanks for your comments.
After implementing[1] findService() method of SOAPActionBasedDispatcher, I've
been able to dispatch the service by using SOAPAction, though I'm not sure
whether it is the best solution. But it works with my MDB listener and makes me
happy :)
Anyway, it would be great to be informed about future JMS improvements.
Regards,
Ali Sadik Kumlali
[1] http://issues.apache.org/jira/browse/AXIS2-1585?page=all
----- Original Message ----
From: Asankha C. Perera <[EMAIL PROTECTED]>
To: [email protected]
Sent: Saturday, November 4, 2006 11:30:28 AM
Subject: Re: [Axis2][1.1 Nightly] Why a JMS destination should be dedicated to
only a single service (and vice-versa)?
Hi Ali
I agree with your suggestion on including the service name in the EPR,
and in-fact this is would be done when we standardize our SOAP/JMS
implementation in the near future to be compatible with similar
implementations. The proposed standardization would also address your
concerns on specifying the destination in the services XML. I will let
you know more details on this as soon as it becomes available - but
immediate implementation of it is not currently planned. I need to look
at our current code to decide how we could support your requirements for
the following, but at this point, I think both would be possible with
some changes.
- A single destination can be used for messages of different services
- Multiple destinations can be used for messages of the same service
asankha
Ali Sadik Kumlali wrote:
Hi all,
Sorry for this long message :)
Nowadays, I'm trying to dispatch messages come through different destinations
to a single service. However, current JMS implemantation enforces a one-to-one
relationship between service and the destination. Thus, the following
operations is not allowed:
- A single destination can be used for messages of different services
- Multiple destinations can be used for messages of the same service
By looking at the implemantation, I've seen that is because of the difficulties
of dispatching when it comes to JMS. Destination-service relation is
established in services.xml and dispatching is done according to this relation.
That is, when a JMS message comes in, service of the destination is set to the
MC and no dispatching is done for service discovery. Later,
SOAPActionBasedDispatcher is used to get the operation.
Actually, I feel that the transport and/or dispatching related definition
should not be reside in services.xml. And, I believe, this unique behaviour of
JMS tranport is inconsistent with the implementations of other transports.
So, I've been searching a better way for dispatching JMS messages without that
restriction.
When I look at more deeply, I see that RequestURIBasedDispatcher is not capable
of dispatching JMS messages, since we don't have "to" field in MC. If, somehow,
we were able to pass JMS URL to "to" field, RequestURIBasedDispatcher would not
be sufficient to understand JMS URL.
Ok. What about SOAPActionBasedDispatcher? Can I use it for finding my service,
based on the SOAPAction? Nope. Because, it is not implemented yet. And I'm not
sure how it would be possible to discover the service from the SOAPAction.
Iterate over the deployed services and lookup the operation for each service?
If yes, what would happen if two services had the same SOAPAction? Choose the
first matching one? :)
After RequestURIBasedDispatcher and SOAPActionBasedDispatcher is passed, I
still don't have either service or operation in MC. Then I enter the Security
phase where I'm asked for service name, and of course, a NPE is thrown :)
Does it make sense to enter AddressingBasedDispatcher before entering Security
phase? Nope, because of the same thing happens in RequestURIBasedDispatcher: I
don't have "to" field in MC.
OK. Can I use SOAPMessageBodyBasedDispatcher? Nope, because;
- messageContext.getConfigurationContext().getServiceContextPath():
axis2/services
- namespace of the first element(filePart):
http://ws.mycompany.com/schemas/account_1_0
- Utils.parseRequestURLForServiceAndOperation() returns no service and
operation
Then, what would be the possible solution?
- At sender side:
- Adding service name to the JMS URL
- Adding service name to the JMS message header before sending it (the same
approach used for transferring SOAPAction)
- At receiver 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).
- Letting SOAPActionBasedDispatcher to find the operation by using soapAction
value in MC (this is already done with the current implementation).
All the transports send service name (and operation name) with the request, but
JMS. Please look at the following EPRs:
- HTTP: http://127.0.0.1:8080/axis2/services/EchoXMLService/echoOMElement
- SMTP: mail:[EMAIL PROTECTED]/axis2/services/EchoXMLService/echoOMElement
- TCP: tcp://127.0.0.1:8080/axis2/services/EchoXMLService/echoOMElement
- JMS:
jms:/destinationName?transport.jms.ConnectionFactoryJNDIName=conFactName&...
By sending service name with the JMS request, we would;
- be more consistent
- not need service-destination mapping in services.xml
- use a single destination for multiple services
- dispatch messages come from different destionations to the same service
Any thoughts?
Regards,
Ali Sadik Kumlali
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To
unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
