W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2004

WS-CDL questions

From: Jean-Jacques Dubray <jeanjadu@Attachmate.com>
Date: Sun, 11 Apr 2004 23:19:45 -0700
Message-ID: <D15269CBED76D51185280008C73323FA02CE069A@exch-bel6.attachmate.com>
To: "Steve Ross-Talbot" <steve@enigmatec.net>
Cc: "WS-Choreography List" <public-ws-chor@w3.org>

Interactions are bound to WSDL operations, as I understand the current
draft. This implies a few things and some questions:

WS-CDL must be associated to some abstract WSDL service definitions
(port types but not ports)? Concrete WSDL defined by each participant
must built on this abstract WSDL?

Why specify a message type in the interaction? Why not in the associated
WSDL? Could they be different? How do you guaranty that they cannot be
different if specified in two different places?

As I understand it, the only operations that will be referenced are
One-Way and Request/Response, no Notifcation and Sollicite-Response will
be needed/allowed? I understand why you do that, but this is a big
departure from WSDL itself?

A comment with respect to state alignment and work unit. It looks like
the granularity at which isAligned() can be used is too big and that
could defeat the purpose of work units along with state alignment which
are otherwise very useful concepts. BPSS offers alignment at the message
level (it is not because you received a message that this message is
understood as valid and can be processed by the receiver). If no
protocol is available to notify the sender of potential standard errors
for each message, then these error notifications must be implemented in
the choreography itself. This is not a satisfying solution, because you
end up acking the ack. As I learned it, it is only through the use of
widely agreed upon and structurally constant signals that you can really
guarantee state alignment otherwise, I am under the impression that it
will remain a wish rather than a fact. 

Received on Monday, 12 April 2004 02:24:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:24 UTC