You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Chamil Thanthrimudalige <ch...@opensource.lk> on 2005/03/17 09:54:52 UTC
[Axis2] REQUEST_URI in mail transport
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.
Re: [Axis2] OP name *must* be taken from SOAP message???
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Anne, all:
Axis is NOT by default a BP-compliant engine. I'm all for having a
switch to indicate BP compliance, but the world is way bigger than the
limitations imposed by BP (for instance, we're going to support RPC
encoding too).
Using unique <Body> child elements as dispatch is certainly one way to
do it. But Axis has been designed from the get-go to allow flexibility
for these sorts of things - as long as SOMEONE along the processing
chain sets the service/operation by the time the Dispatch phase is
complete, it doesn't matter that it happened in any particular way. We
should certainly provide good defaults for this sort of thing, but the
point is that a given deployer should be able to make sure her
particular system works the way she needs by deploying handlers in
particular ways, and we shouldn't limit her choices (of which using
action is a perfectly acceptable one, for instance).
Thanks,
--Glen
Anne Thomas Manes wrote:
> Per the WS-I BP, in SOAP 1.1, the child element of the SOAP body must
> supply a unique signature (for both RPC and Document styles) and it
> should always be used to determine what's being requested. SOAP Action
> is merely a processing hint, and it should not be used to determine
> processing action:
>
> R1127 A RECEIVER MUST NOT rely on the value of the SOAPAction HTTP
> header to correctly process the message.
>
> and
>
> 4.7.6 Operation Signatures
>
> Definition: operation signature
>
> The profile defines the "operation signature" to be the fully
> qualified name of the child element of SOAP body of the SOAP input
> message described by an operation in a WSDL binding.
>
> In the case of rpc-literal binding, the operation name is used as a
> wrapper for the part accessors. In the document-literal case, since a
> wrapper with the operation name is not present, the message signatures
> must be correctly designed so that they meet this requirement.
>
> An endpoint that supports multiple operations must unambiguously
> identify the operation being invoked based on the input message that
> it receives. This is only possible if all the operations specified in
> the wsdl:binding associated with an endpoint have a unique operation
> signature.
>
> R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in
> operation signatures that are different from one another.
>
>
>
> On Thu, 17 Mar 2005 17:57:18 +0600, Chathura Herath
> <ch...@opensource.lk> wrote:
>
>>Are you sure, I'm not so sure about that. I am referring to the fact that op
>>name must be taken from SOAP message. Anyway if it's a must the WSDL2.0 WG
>>guys missed something. ;-) Have to check on it.
>>
>>Thanks
>>
>>Chathura
>>
>>
>>>-----Original Message-----
>>>From: Srinath Perera [mailto:hemapani@gmail.com]
>>>Sent: Thursday, March 17, 2005 5:29 PM
>>>To: axis-dev@ws.apache.org
>>>Subject: Re: [Axis2] REQUEST_URI in mail transport
>>>
>>>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
>>><ch...@opensource.lk> 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: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
>>>>><ch...@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
>>>>>
>>>>><he...@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
>>>>>>>><ch...@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
>>>>>>
>>>>>>
>>>>
>>
>
Re: [Axis2] OP name *must* be taken from SOAP message???
Posted by Anne Thomas Manes <at...@gmail.com>.
Per the WS-I BP, in SOAP 1.1, the child element of the SOAP body must
supply a unique signature (for both RPC and Document styles) and it
should always be used to determine what's being requested. SOAP Action
is merely a processing hint, and it should not be used to determine
processing action:
R1127 A RECEIVER MUST NOT rely on the value of the SOAPAction HTTP
header to correctly process the message.
and
4.7.6 Operation Signatures
Definition: operation signature
The profile defines the "operation signature" to be the fully
qualified name of the child element of SOAP body of the SOAP input
message described by an operation in a WSDL binding.
In the case of rpc-literal binding, the operation name is used as a
wrapper for the part accessors. In the document-literal case, since a
wrapper with the operation name is not present, the message signatures
must be correctly designed so that they meet this requirement.
An endpoint that supports multiple operations must unambiguously
identify the operation being invoked based on the input message that
it receives. This is only possible if all the operations specified in
the wsdl:binding associated with an endpoint have a unique operation
signature.
R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in
operation signatures that are different from one another.
On Thu, 17 Mar 2005 17:57:18 +0600, Chathura Herath
<ch...@opensource.lk> wrote:
> Are you sure, I'm not so sure about that. I am referring to the fact that op
> name must be taken from SOAP message. Anyway if it's a must the WSDL2.0 WG
> guys missed something. ;-) Have to check on it.
>
> Thanks
>
> Chathura
>
> > -----Original Message-----
> > From: Srinath Perera [mailto:hemapani@gmail.com]
> > Sent: Thursday, March 17, 2005 5:29 PM
> > To: axis-dev@ws.apache.org
> > Subject: Re: [Axis2] REQUEST_URI in mail transport
> >
> > 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
> > <ch...@opensource.lk> 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: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
> > > > <ch...@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
> > > > <he...@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
> > > > > > > <ch...@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
> > > > >
> > > > >
> > >
> > >
>
>
RE: [Axis2] OP name *must* be taken from SOAP message???
Posted by Chathura Herath <ch...@opensource.lk>.
Are you sure, I'm not so sure about that. I am referring to the fact that op
name must be taken from SOAP message. Anyway if it's a must the WSDL2.0 WG
guys missed something. ;-) Have to check on it.
Thanks
Chathura
> -----Original Message-----
> From: Srinath Perera [mailto:hemapani@gmail.com]
> Sent: Thursday, March 17, 2005 5:29 PM
> To: axis-dev@ws.apache.org
> Subject: Re: [Axis2] REQUEST_URI in mail transport
>
> 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
> <ch...@opensource.lk> 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: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
> > > <ch...@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
> > > <he...@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
> > > > > > <ch...@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
> > > >
> > > >
> >
> >
Re: [Axis2] REQUEST_URI in mail transport
Posted by Srinath Perera <he...@gmail.com>.
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
<ch...@opensource.lk> 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: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
> > <ch...@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
> > <he...@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
> > > > > <ch...@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
> > >
> > >
>
>
RE: [Axis2] REQUEST_URI in mail transport
Posted by Chathura Herath <ch...@opensource.lk>.
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
> <ch...@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
> <he...@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
> > > > <ch...@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
> >
> >
Re: [Axis2] REQUEST_URI in mail transport
Posted by Srinath Perera <he...@gmail.com>.
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
<ch...@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 <he...@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
> > > <ch...@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
>
>
Re: [Axis2] REQUEST_URI in mail transport
Posted by Chamil Thanthrimudalige <ch...@opensource.lk>.
hi,
If more than one email address is used then how will the server side
code [Listening Thread] operate?
In that case when the Listener starts up the email addresses and details
[i.e. user names, passwords, server, etc.] should have to be retrieved
from the services [?!]. And then it has to pole multiple email
addresses. I guess on the mailet scenario this will not be a problem,
but if some one wants to use a generic mail server to setup a service
then that will be a problem in my opinion [at least :) ].
Best Regards,
Chamil Thanthrimudalige.
Ajith Ranabahu wrote:
>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 <he...@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
>><ch...@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.
>>>
>>>
>>>
>
>
>
>
RE: [Axis2] REQUEST_URI in mail transport
Posted by Chathura Herath <ch...@opensource.lk>.
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 <he...@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
> > <ch...@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
Re: [Axis2] REQUEST_URI in mail transport
Posted by Ajith Ranabahu <aj...@gmail.com>.
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 <he...@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
> <ch...@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
Re: [Axis2] REQUEST_URI in mail transport
Posted by Srinath Perera <he...@gmail.com>.
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
<ch...@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.
>
Re: [Axis2] REQUEST_URI in mail transport
Posted by Srinath Perera <he...@gmail.com>.
Ajith, Eran .. actual Q is far more complex than just the SOAP actions
and it is been a real pain to write a code to support all these case.
see my above mail
Thanks
Srinath
On Thu, 17 Mar 2005 15:42:44 +0600, Ajith Ranabahu
<aj...@gmail.com> wrote:
> Ahum,
> I don't think using the SOAPAction for identifying the service is a
> good idea. You can use the SOAPAction to identify the operation but
> not the service. it's better if the service identification comes from
> end point reference (The http URL or in the case of the mail, the mail
> address)
> IMHO we have to stick to one convention in doing this. Anybody has any
> idea how other implementers utilize the SOAPAction ? Perhaps Microsoft
> ?
>
> On Thu, 17 Mar 2005 15:29:49 +0600, Eran Chinthaka
> <ch...@opensource.lk> wrote:
> >
> > Hi Chamil,
> >
> > >
> > > 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?
> >
> > IMO, Service identification must be done through the SOAPAction found in the
> > mime header, at the transport level. This is the same done even in Axis 1.x.
> >
> > mimeMessage.getHeader("SOAPAction") will give you that. Get the SOAPAction
> > from that and use that to set the SOAPAction in
> > MessageInformationHeaderCollection of the message context.
> >
> > Regards,
> > Eran Chinthaka
> >
> > >
> > > 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
>
Re: [Axis2] REQUEST_URI in mail transport
Posted by Ajith Ranabahu <aj...@gmail.com>.
Ahum,
I don't think using the SOAPAction for identifying the service is a
good idea. You can use the SOAPAction to identify the operation but
not the service. it's better if the service identification comes from
end point reference (The http URL or in the case of the mail, the mail
address)
IMHO we have to stick to one convention in doing this. Anybody has any
idea how other implementers utilize the SOAPAction ? Perhaps Microsoft
?
On Thu, 17 Mar 2005 15:29:49 +0600, Eran Chinthaka
<ch...@opensource.lk> wrote:
>
> Hi Chamil,
>
> >
> > 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?
>
> IMO, Service identification must be done through the SOAPAction found in the
> mime header, at the transport level. This is the same done even in Axis 1.x.
>
> mimeMessage.getHeader("SOAPAction") will give you that. Get the SOAPAction
> from that and use that to set the SOAPAction in
> MessageInformationHeaderCollection of the message context.
>
> Regards,
> Eran Chinthaka
>
> >
> > 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
RE: [Axis2] REQUEST_URI in mail transport
Posted by Chathura Herath <ch...@opensource.lk>.
I don't think we have any disagreement on "WHAT" value. It's a URI. The URI
of the EPR.
Chathura
> -----Original Message-----
> From: Chamil Thanthrimudalige [mailto:chamil@opensource.lk]
> Sent: Thursday, March 17, 2005 4:35 PM
> To: axis-dev@ws.apache.org
> Subject: Re: [Axis2] REQUEST_URI in mail transport
>
> The problem is not transferring SOME "VALUE" once it is decided, but
> agreeing on what "VALUE" to use. I mean a URI or a mail address [which
> is a bit problematic as I mentioned earlier.] or some thing else. Please
> note that I am only speaking with respect to the mail transport since
> the URI option seems to be working ok in the HTTP case.
>
> Best Regards,
> Chamil Thanthrimudalige.
>
> Chathura Herath wrote:
>
> >Well a simpler solution would be to use the Subject to transfer the
> >SOAPAction :-)
> >
> >Chathura
> >
> >
> >
> >>-----Original Message-----
> >>From: Eran Chinthaka [mailto:chinthaka@opensource.lk]
> >>Sent: Thursday, March 17, 2005 3:30 PM
> >>To: axis-dev@ws.apache.org
> >>Subject: RE: [Axis2] REQUEST_URI in mail transport
> >>
> >>
> >>Hi Chamil,
> >>
> >>
> >>
> >>>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?
> >>>
> >>>
> >>IMO, Service identification must be done through the SOAPAction found in
> >>the
> >>mime header, at the transport level. This is the same done even in Axis
> >>1.x.
> >>
> >>mimeMessage.getHeader("SOAPAction") will give you that. Get the
> SOAPAction
> >>from that and use that to set the SOAPAction in
> >>MessageInformationHeaderCollection of the message context.
> >>
> >>
> >>Regards,
> >>Eran Chinthaka
> >>
> >>
> >>
> >>>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.
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
>
Re: [Axis2] REQUEST_URI in mail transport
Posted by Chamil Thanthrimudalige <ch...@opensource.lk>.
The problem is not transferring SOME "VALUE" once it is decided, but
agreeing on what "VALUE" to use. I mean a URI or a mail address [which
is a bit problematic as I mentioned earlier.] or some thing else. Please
note that I am only speaking with respect to the mail transport since
the URI option seems to be working ok in the HTTP case.
Best Regards,
Chamil Thanthrimudalige.
Chathura Herath wrote:
>Well a simpler solution would be to use the Subject to transfer the
>SOAPAction :-)
>
>Chathura
>
>
>
>>-----Original Message-----
>>From: Eran Chinthaka [mailto:chinthaka@opensource.lk]
>>Sent: Thursday, March 17, 2005 3:30 PM
>>To: axis-dev@ws.apache.org
>>Subject: RE: [Axis2] REQUEST_URI in mail transport
>>
>>
>>Hi Chamil,
>>
>>
>>
>>>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?
>>>
>>>
>>IMO, Service identification must be done through the SOAPAction found in
>>the
>>mime header, at the transport level. This is the same done even in Axis
>>1.x.
>>
>>mimeMessage.getHeader("SOAPAction") will give you that. Get the SOAPAction
>>from that and use that to set the SOAPAction in
>>MessageInformationHeaderCollection of the message context.
>>
>>
>>Regards,
>>Eran Chinthaka
>>
>>
>>
>>>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.
>>>
>>>
>>
>>
>>
>
>
>
>
>
>
>
RE: [Axis2] REQUEST_URI in mail transport
Posted by Chathura Herath <ch...@opensource.lk>.
Well a simpler solution would be to use the Subject to transfer the
SOAPAction :-)
Chathura
> -----Original Message-----
> From: Eran Chinthaka [mailto:chinthaka@opensource.lk]
> Sent: Thursday, March 17, 2005 3:30 PM
> To: axis-dev@ws.apache.org
> Subject: RE: [Axis2] REQUEST_URI in mail transport
>
>
> Hi Chamil,
>
> >
> > 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?
>
> IMO, Service identification must be done through the SOAPAction found in
> the
> mime header, at the transport level. This is the same done even in Axis
> 1.x.
>
> mimeMessage.getHeader("SOAPAction") will give you that. Get the SOAPAction
> from that and use that to set the SOAPAction in
> MessageInformationHeaderCollection of the message context.
>
>
> Regards,
> Eran Chinthaka
>
> >
> > 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.
>
>
>
RE: [Axis2] REQUEST_URI in mail transport
Posted by Eran Chinthaka <ch...@opensource.lk>.
Hi Chamil,
>
> 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?
IMO, Service identification must be done through the SOAPAction found in the
mime header, at the transport level. This is the same done even in Axis 1.x.
mimeMessage.getHeader("SOAPAction") will give you that. Get the SOAPAction
from that and use that to set the SOAPAction in
MessageInformationHeaderCollection of the message context.
Regards,
Eran Chinthaka
>
> 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.