axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: [Axis2] REQUEST_URI in mail transport
Date Thu, 17 Mar 2005 15:51:59 GMT
Shawn Dahlen wrote:

>It seems to me that the WS Addressing spec is meant to solve these issues.  The To field
allows for approriate routing to a given endpoint (the service) and the Action field provides
dispatching to an operation (although the endpoint may have just a generic receive method
and do manual dispatching).
>This has been my thought when I wrote about a low level messaging model.
>Does everyone believe that WS Addressing should be fundamental to the core engine?

i think WSA is integral part of engine already?

i agree that if possible WSA:Action/To should be used to do routing (are 
there definitive rules how to do it?)

as of original question about mail transport receiving messages: i think 
that To: in mail should be used in similiar manner to HTTP GET/POST URI 
to do dispatch as well.

in other words i see no problem with using Mail:To as REQUEST_URI (and 
mybe combine it with Mail:Subject) that is set before engine.receive(MC) ...



>-----Original Message-----
>From: Ajith Ranabahu <>
>Date: Thu, 17 Mar 2005 15:54:30 
>, Srinath Perera <>
>Subject: Re: [Axis2] REQUEST_URI in mail transport
>Yes I agree that this is a broader issue than just the SOAPAction. The
>algorithm you suggest seems to be fair enough for service resolution.
>However I suppose we should look more into what others are doing
>(afterall its not only axis  that is there in the world :)) and decide
>the alternate branches of our service/operation resolution algorithm
>depending on that.
>On Thu, 17 Mar 2005 15:42:04 +0600, Srinath Perera <> wrote:
>>Let me extend the Q bit .. as it is not only the SMTP that bring the Q
>>At the web services we need to identify  two things
>>1) Service Name
>>2) Operation name
>>to obtain the information we have the following
>>1) To address, (if the address not presents the request URI for HTTP
>>and the mail address for the SMTP case )
>>2) SOAP actions
>>3) if rpc-* or doc-literal-wrapped from the SOAP message
>>we want to handle this for (at least) SMTP & HTTP
>>each of these can have a separator to have two information. I purpose
>>the following algorithm to
>>1 try to get the service name from the To address.. that is basically
>>find string $A in the To address that Marches the patters
>>2.1 if 1 is success,
>>       if (style == rpc || wrapped){
>>             find the operation from the Envelope
>>       }
>>       if(style == doc){
>>             pick the operation name from the SOAPAction
>>       }
>>2.2. if 1failed, try to pick up the service from the SOAP action. Then
>>the style must be rpc or doc literal wrapped as no way to find
>>Does the algorithm is fair enough?
>>few issues are
>>1) do we need escape characters in the to addess or the SOAPAction to
>>let one entry have two information?
>>2) Are going to use the things like NSURI of the firat element to
>>locate service/operation
>>3) do we need configuration support to change the order of the things
>>taking the precedence.
>>On Thu, 17 Mar 2005 14:54:52 +0600, Chamil Thanthrimudalige
>><> wrote:
>>>hi all,
>>>Well let me start by telling how I have setup the mail transport code
>>>for the time being. [Currently working on a maillet that can work with
>>>There is a poling thread that listens to a specified mail address and
>>>when a mail comes to that address it will be fetched; broken down;  MC
>>>made and this MC will be used to call the engine.receive(MC) method.
>>>My problem is that since it is required to set a REQUEST_URI (which will
>>>be used to find out the service that should be called) before calling
>>>engine.receive(MC), what can I use to set this?
>>>Using the email address might cause a problem because then for different
>>>services the mail listener will have to listen to many email address.
>>>Before the current change I set the service using a value stored on the
>>>mail header.
>>>Best Regards,
>>>Chamil Thanthrimudalige.

The best way to predict the future is to invent it - Alan Kay

View raw message