Remember that only the HTTP binding specifies the SOAPAction header. Not all bindings are going to have a SOAPAction that's external to the envelope.
> -----Original Message----- > From: Chathura Herath [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 17, 2005 7:31 PM > To: axis-dev@ws.apache.org > Subject: RE: [Axis2] REQUEST_URI in mail transport > > 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:[EMAIL PROTECTED] > > 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 <[EMAIL PROTECTED]> > > >Date: Thu, 17 Mar 2005 15:54:30 > > >To:axis-dev@ws.apache.org, Srinath Perera <[EMAIL PROTECTED]> > > >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 > > ><[EMAIL PROTECTED]> > > 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 > > >><[EMAIL PROTECTED]> 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 > > > > > > > > >
