axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chathura Herath" <chath...@opensource.lk>
Subject RE: [Axis2] REQUEST_URI in mail transport
Date Fri, 18 Mar 2005 03:31:09 GMT
Hi Shawn,

You raised the very true point. All in all what I feel about this discussion
is that we have different methods of getting at the same info (operation
discovery) and we should make precedence rules over those. My idea is that
the WSA stuff takes precedence over all, and as you said WAS stuff is not
mandatory so I guess the SOAPAction gets precedence in absence of the WAS
stuff.
We ll have to agree what to do when SOAPAction is not present.

Surely the decisions should be made thinking of Interoperability.

Thanks
Chathura


> -----Original Message-----
> From: Shawn Dahlen [mailto:shawn@dahlen.name]
> Sent: Thursday, March 17, 2005 10:45 PM
> To: axis-dev@ws.apache.org
> Subject: Re: [Axis2] REQUEST_URI in mail transport
> 
> I guess I was approaching this issue by assuming that WSA was mandatory,
> as in all incoming requests would have the appropiate headers.  To me it
> is a fundamental piece to achieving the protocol neutral async messaging
> model.
> 
> As for routing rules, It is my understanding that it was outside the scope
> of WSA.  It would be up to the engine to determine what code was executed
> based on the standardized addressing headers.
> 
> I will take a look at MS approach in Indigo to see if WSA is fundamental.
> 
> Perhaps I am assuming to much.  But for async replies, conventions for
> each transport will be needed if the WSA info is not available.  To me
> that sounds like an interop nightmare.
> 
> Shawn
> 
> ------Original Message------
> From: Aleksander Slominski
> To: axis-dev@ws.apache.org
> ReplyTo: axis-dev@ws.apache.org
> Sent: Mar 17, 2005 10:51 AM
> Subject: Re: [Axis2] REQUEST_URI in mail transport
> 
> 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?
> >
> >
> hi,
> 
> 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)
> ...
> 
> thanks,
> 
> alek
> 
> >-----Original Message-----
> >From: Ajith Ranabahu <ajith.ranabahu@gmail.com>
> >Date: Thu, 17 Mar 2005 15:54:30
> >To:axis-dev@ws.apache.org, Srinath Perera <hemapani@gmail.com>
> >Subject: Re: [Axis2] REQUEST_URI in mail transport
> >
> >Hi,
> >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 <hemapani@gmail.com>
> 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
> >>*/services/$A
> >>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
> >>operation
> >>
> >>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.
> >>
> >>thoughts
> >>Srinath
> >>
> >>On Thu, 17 Mar 2005 14:54:52 +0600, Chamil Thanthrimudalige
> >><chamil@opensource.lk> 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
> >>>James.]
> >>>
> >>>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
> 
> 




Mime
View raw message