axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <g...@thoughtcraft.com>
Subject Re: [Axis2] OP name *must* be taken from SOAP message???
Date Sat, 19 Mar 2005 15:25:55 GMT
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
> <chathura@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
>>><chathura@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
>>>>><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