Re: WS-Addr issues

David Orchard wrote:

>+1.  
>
>Arguing against action is like arguing against HTTP operations.  Having
>one spot for Action will give all WS-A applications a much simpler
>processing model and enable a doc/literal world.
>  
>
How about that one spot being the name of the child element of the 
soap:body.  

Tom Rutt
Fujitsu

>Separately, can we pick better subject lines and focus the conversation
>a bit?  I think this thread is on mandatory Action.  I expect we are
>going to debate every single component's mandatory/optional nature and
>separating them would help a lot.
>
>Dave
>
>  
>
>>-----Original Message-----
>>From: public-ws-addressing-request@w3.org
>>    
>>
>[mailto:public-ws-addressing-
>  
>
>>request@w3.org] On Behalf Of Francisco Curbera
>>Sent: Thursday, November 04, 2004 6:26 AM
>>To: Mark Little
>>Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
>>Subject: Re: WS-Addr issues
>>
>>
>>
>>
>>
>>
>>The idea that the intent of the message is *always* embedded in the
>>    
>>
>body
>  
>
>>of
>>the message smells like SOAP-RPC in sheep clothes to me. I am not
>>    
>>
>saying
>  
>
>>that will never be the case, but you need to allow for the case in
>>    
>>
>which
>  
>
>>the same document type is used in different interactions - for
>>    
>>
>example, a
>  
>
>>customerInfo document could be sent as input to both an "update" and a
>>"create" operations.This "document centric" model is actually very
>>frequent
>>(it is no uncommon in CICS applications for example). To support this
>>model
>>you need either an Action header or something functionally equivalent.
>>
>>Paco
>>
>>
>>
>>
>>
>>                      "Mark Little"
>>                      <mark.little@arjuna.com>        To:
>>    
>>
>"Sanjiva
>  
>
>>Weerawarana" <sanjiva@watson.ibm.com>, <public-ws-addressing@w3.org>
>>                      Sent by:                        cc:
>>                      public-ws-addressing-req        Subject:  Re:
>>    
>>
>WS-
>  
>
>>Addr issues
>>                      uest@w3.org
>>
>>
>>                      11/04/2004 05:05 AM
>>
>>
>>
>>
>>
>>Hi Sanjiva. Although not an answer to your question, I think it's
>>    
>>
>worth
>  
>
>>bringing up generally: personally I think wsa:Action should be dropped
>>    
>>
>or
>  
>
>>made optional. Why have an "op code" (which is essentially what it is)
>>embedded in an address? I can see that there are optimizations that
>>    
>>
>could
>  
>
>>be made to dispatching directly on the Action rather than having to
>>    
>>
>parse
>  
>
>>the body, but surely that's an implementation specific issue? I'd be
>>interested in knowing how many users of WS-Addressing actually use
>>    
>>
>this
>  
>
>>versus those that ignore it.
>>
>>Mark.
>>
>>----
>>Mark Little,
>>Chief Architect,
>>Arjuna Technologies Ltd.
>>
>>www.arjuna.com
>>----- Original Message -----
>>From: Sanjiva Weerawarana
>>To: public-ws-addressing@w3.org
>>Sent: Wednesday, November 03, 2004 7:42 PM
>>Subject: Re: WS-Addr issues
>>
>>Hi Steve,
>>
>>What's your view of dispatching with wsa:Action? Since those are
>>    
>>
>required
>  
>
>>to be unique that gives enough info to find the operation to dispatch
>>to within a service. The service itself is of course identified from
>>the <To> somehow.
>>
>>Sanjiva.
>> ----- Original Message -----
>> From: Vinoski, Stephen
>> To: Doug Davis
>> Cc: public-ws-addressing@w3.org
>> Sent: Thursday, November 04, 2004 12:58 AM
>> Subject: RE: WS-Addr issues
>>
>> +1 to having a pointer to the WSDL itself in the EPR. We have found
>>    
>>
>in
>  
>
>> working with our customers that having access to the service
>>    
>>
>definition
>  
>
>>is
>> critical for applications that rely on pure dynamic dispatching.
>>
>> --steve
>>       -----Original Message-----
>>       From: Doug Davis [mailto:dug@us.ibm.com]
>>       Sent: Wednesday, November 03, 2004 11:02 AM
>>       To: public-ws-addressing@w3.org
>>       Subject: WS-Addr issues
>>
>>
>>       I might have missed a formal request for "issues" from the
>>    
>>
>public
>  
>
>>       but since it appears there is now an issues list I thought I'd
>>    
>>
>make
>  
>
>>       some suggestions on possible issues for the WG's consideration:
>>
>>       issue: EPRs have WSDL bits - e.g. PortType, ServiceName.  But
>>    
>>
>no
>  
>
>>       pointer to the actual WSDL itself - why not?  W/o the WSDL do
>>    
>>
>these
>  
>
>>       values mean anything?  And if we assume the consumer of the EPR
>>    
>>
>has
>  
>
>>       the WSDL why can't we assume they know the PortType and
>>ServiceName?
>>       Perhaps an example of how this would be used would clarify it
>>    
>>
>for
>  
>
>>       me.
>>
>>       issue: If a response message is expected then a wsa:ReplyTo
>>    
>>
>MUST be
>  
>
>>       included.  Does the absence of a wsa:ReplyTo imply a one-way
>>       message?  The spec seems to come very close to saying that.
>>    
>>
>And
>  
>
>>       does the presence of wsa:ReplyTo imply a two-way message?  My
>>       preference would be to have a clear statement so that upon
>>       inspection of the message itself a processor can know if its a
>>       one-way or two-way w/o having to go back to the wsdl.
>>
>>       issue: wsa:FaultTo:  "This property may be absent if the sender
>>       cannot receive fault messages (e.g. is a one-way application
>>       message)."  But it also says that in the absence of wsa:FaultTo
>>    
>>
>the
>  
>
>>       wsa:ReplyTo/From may be used.  So, how does a client really say
>>that
>>       it doesn't want ANY fault messages at all but still be allowed
>>    
>>
>to
>  
>
>>       specify a wsa:From?
>>
>>       thanks
>>       -Doug
>>
>>    
>>
>
>
>  
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Friday, 5 November 2004 06:24:42 UTC