HI, Ok the first problem was to get the SOAP action over this particular transport. That's not a big issue, personally think we should agree to one format. The SOAP Action is another new issue and as Srinath said we should decide which one gets precedence in the event of the getting the operation.
Now regarding the operation discovery. I think the SOAPAction should get the precedence over all. The reason to do that is you don't know the style until you know the operation. In WSDL 2.0 the operation is the owner of the Style attribute(not the Interface/Porttype) In the algorithm that Srinath wrote down, there is no way to know the style before identifying the operation so it cant work. Comments?? Chathura > -----Original Message----- > From: Ajith Ranabahu [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 17, 2005 3:55 PM > To: axis-dev@ws.apache.org; Srinath Perera > 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. > > > > > > > > -- > Ajith Ranabahu
