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 Thu, 17 Mar 2005 11:06:05 GMT
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:hemapani@gmail.com]
> 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
> <chathura@opensource.lk> 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:ajith.ranabahu@gmail.com]
> > > 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
> <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.
> > > > >
> > > >
> > >
> > >
> > > --
> > > Ajith Ranabahu
> >
> >




Mime
View raw message