if it is rpc u r suppose to get the opertion name from the SOAP
message and AFAIK it is a must.  So we are in trouble and the fact
SOAP action does not null do not mean anyhting.

still it is Oops ? 
thanks
Srinath


On Thu, 17 Mar 2005 17:06:05 +0600, Chathura Herath
<[EMAIL PROTECTED]> wrote:
> Hang on... No ooops there still.
> We can look at the SOAPAction in each case (both rpc and document).
> 
> If(null != SOAPAction){
>         Get the operation from SOAPAction(for both rpc and document)
> }
> else{
>         Assume rpc and get the operation form the SOAPBody.
> 
>         Now if the style is document.. Now definitely you have an ooops
> there   and you can't do anything(simply throw exception).
> }
> 
> Anyway what I have said was what is there in the spec(Should mention there
> is a notion of a default style in the PortType/Interface, but the problem is
> far from gone).
> 
> Comments??
> 
> Chathura
> 
> > -----Original Message-----
> > From: Srinath Perera [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, March 17, 2005 4:46 PM
> > To: axis-dev@ws.apache.org
> > Subject: Re: [Axis2] REQUEST_URI in mail transport
> >
> > if we do not know the style until operation is found and to find the
> > OPEARATION we need STYLE. (e.g. in the rpc case we found the opearion
> > from the SOAP message .. if you need opearion to found the style then
> > ooops ...., how the hell we know should we peek in to the SOAP message
> > or not )
> >
> > This is a checken and egg problem ...I strongly belive somehow we have
> > get it all wrong hope somebody enligten us on it !
> >
> > Thanks
> > Srinath
> >
> >
> > On Thu, 17 Mar 2005 16:17:17 +0600, Chathura Herath
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > 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
> > >
> > >
> 
>

Reply via email to