- From: Francisco Curbera <curbera@us.ibm.com>
- Date: Fri, 5 Nov 2004 07:40:56 -0500
- To: tom@coastin.com
- Cc: Mark Little <mark.little@arjuna.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
That is one particular design model. The doc/lit approach types WSDL
messages with element definitions, the assumption being that it is the
document itself what gets reused; in your approach you need to redefine a
new XSD element for each operation - I would say that you need to define
the operation twice, first as a new XSD element then as a WSDL operation
proper. That is fine, but is certainly not the only (or best) approach to
do doc/lit.
Paco
Tom Rutt
<tom@coastin.com> To: Francisco Curbera/Watson/IBM@IBMUS
cc: Mark Little <mark.little@arjuna.com>, public-ws-addressing@w3.org,
11/05/2004 12:30 public-ws-addressing-request@w3.org
AM Subject: Re: WS-Addr issues
Please respond to
tom
This scenario sounds like it is not using WSDL.
With doc literal one could have the same type of the document in the
body (as message part for wsdl operation) for two
different intended operations, but the two cases can each use
a different global element name to distinguish two different operations
using that type as the input message part.
Tom Rutt
Fujitsu
WSDL: operation names appear in the child of the soap body.
It seems broken to me to have to rely on something outside the soap body
to dispatch the operation.
Tom Rutt
Fujitsu
Francisco Curbera wrote:
>
>
>
>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 12:41:30 UTC