axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <asan...@wso2.com>
Subject Re: [Axis2][1.1 Nightly] Why a JMS destination should be dedicated to only a single service (and vice-versa)?
Date Mon, 06 Nov 2006 11:38:38 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ascii" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Ali<br>
<br>
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!<br>
<br>
thanks<br>
asankha<br>
<br>
Ali Sadik Kumlali wrote:
<blockquote
 cite="mid20061104154550.66690.qmail@web38901.mail.mud.yahoo.com"
 type="cite">
  <pre wrap="">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] <a class="moz-txt-link-freetext"
 href="http://issues.apache.org/jira/browse/AXIS2-1585?page=all">http://issues.apache.org/jira/browse/AXIS2-1585?page=all</a>

----- Original Message ----
From: Asankha C. Perera <a class="moz-txt-link-rfc2396E"
 href="mailto:asankha@wso2.com">&lt;asankha@wso2.com&gt;</a>
To: <a class="moz-txt-link-abbreviated"
 href="mailto:axis-dev@ws.apache.org">axis-dev@ws.apache.org</a>
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.
  </pre>
  <blockquote type="cite">
    <pre wrap="">- A single destination can be used for messages of different services
- Multiple destinations can be used for messages of the same service
  
    </pre>
  </blockquote>
  <pre wrap=""><!---->asankha


Ali Sadik Kumlali wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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): <a
 class="moz-txt-link-freetext"
 href="http://ws.mycompany.com/schemas/account_1_0">http://ws.mycompany.com/schemas/account_1_0</a>
  - 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: <a class="moz-txt-link-freetext"
 href="http://127.0.0.1:8080/axis2/services/EchoXMLService/echoOMElement">http://127.0.0.1:8080/axis2/services/EchoXMLService/echoOMElement</a>
- SMTP: <a class="moz-txt-link-abbreviated"
 href="mailto:mail:foo@127.0.0.1/axis2/services/EchoXMLService/echoOMElement">mail:foo@127.0.0.1/axis2/services/EchoXMLService/echoOMElement</a>
- TCP: tcp://127.0.0.1:8080/axis2/services/EchoXMLService/echoOMElement
- JMS: jms:/destinationName?transport.jms.ConnectionFactoryJNDIName=conFactName&amp;...

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: <a class="moz-txt-link-abbreviated"
 href="mailto:axis-dev-unsubscribe@ws.apache.org">axis-dev-unsubscribe@ws.apache.org</a>
For additional commands, e-mail: <a class="moz-txt-link-abbreviated"
 href="mailto:axis-dev-help@ws.apache.org">axis-dev-help@ws.apache.org</a>



  
    </pre>
  </blockquote>
  <pre wrap=""><!---->
---------------------------------------------------------------------
To unsubscribe, e-mail: <a class="moz-txt-link-abbreviated"
 href="mailto:axis-dev-unsubscribe@ws.apache.org">axis-dev-unsubscribe@ws.apache.org</a>
For additional commands, e-mail: <a class="moz-txt-link-abbreviated"
 href="mailto:axis-dev-help@ws.apache.org">axis-dev-help@ws.apache.org</a>







---------------------------------------------------------------------
To unsubscribe, e-mail: <a class="moz-txt-link-abbreviated"
 href="mailto:axis-dev-unsubscribe@ws.apache.org">axis-dev-unsubscribe@ws.apache.org</a>
For additional commands, e-mail: <a class="moz-txt-link-abbreviated"
 href="mailto:axis-dev-help@ws.apache.org">axis-dev-help@ws.apache.org</a>



  </pre>
</blockquote>
</body>
</html>

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message