RE: Proposal: Uniqueness on the Wire Requirement for WSDL 2.0

+1, but I'd add that the client is only ok if the transport correlates messages for the client (as with HTTP). For asynchronous models some addressing/policy magic beyond the GED is definitely required. 

Paul


-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: 29 October 2003 02:00
To: Jeffrey Schlimmer; Anne Thomas Manes; Amelia A. Lewis
Cc: umit.yalcinalp@oracle.com; www-ws-desc@w3.org
Subject: Re: Proposal: Uniqueness on the Wire Requirement for WSDL 2.0



+1 .. I have to say that WSDL deciding whether the message QName
is the service selector or the URL or something else is not right.

I remember asking about this when we implemented IBM SOAP, before
SOAP 1.1 was released. I too was looking for a specific thing to
be tagged as the "key" to routing messages (URL, SOAPAction or
first body element NS URI) - eventually it turns out that different
implementations can choose to route off different of these and
that's completely ok. What's necesssary is that clients be able
to form a proper envelope and send it to the right address. Whether
the server calls a magician to decide which service to invoke or
whether it requires unique element QNames so that it can route or
whether it uses a SOAP header that its clients are expected to put
on (and it presumably conveyed to the world via policy or however)
is up to that.

Sanjiva.

----- Original Message -----
From: "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com>
To: "Anne Thomas Manes" <anne@manes.net>; "Amelia A. Lewis"
<alewis@tibco.com>
Cc: <umit.yalcinalp@oracle.com>; <www-ws-desc@w3.org>
Sent: Wednesday, October 29, 2003 7:50 AM
Subject: RE: Proposal: Uniqueness on the Wire Requirement for WSDL 2.0


>
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> >
> > While I agree with you, I'm certain that WS-I will define a constraint
> > that
> > wire signatures must be unique.
>
> The future may not resemble the past.

Received on Wednesday, 29 October 2003 03:48:55 UTC