RE: WS-CDL questions

Nick:

Actually, I am not really back, just trying to understand your work
informally. 

>It would be nicer though to
>have you in the group where you could help us with CDL ;->
Hum...is that an invitation? Sounds like you have a lot of brain power
already. I don't know if I am capable of adding anything to your work.

>Anyhow, you are raising some very interesting questions and as Steve
has
>said earlier we are going to log issues (if they don't already exist)
based
>on your feedback and all other feedback we get from the public list.

Actually, I was expecting a more substantive response, I guess we did
not have an agreed upon choreography in place and it sounds like you
took an unforeseen exception path in somewhat basic unit of work. I
would hate to have this choreography park.

It would be really great if you have some time and could compensate with
an answer to these questions, as I really did not mean to raise any
issue. At least I cannot see where I raised an issue or did I?

JJ-


> 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.
>
> JJ-

Received on Saturday, 17 April 2004 09:27:19 UTC