W3C home > Mailing lists > Public > public-ws-chor@w3.org > December 2003

Comments on the model

From: Gary Brown <gary@enigmatec.net>
Date: Wed, 17 Dec 2003 15:27:17 -0000
Message-ID: <012f01c3c4b2$417f7240$ee00a8c0@LATTITUDEGary>
To: "David Burdett" <david.burdett@commerceone.com>, "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>
Cc: <public-ws-chor@w3.org>

Hi Dave and Nick

I think that one of the requirements that has not been satisfied by the
current model is the ability to handle legacy web service - although having
reviewed the recent list of requirements sent around by Steve (based on the
use cases), this appears to have been left out (possibly because it is non

What I would like to see is the 'abstract' choreographies focusing on the
passive monitoring of interactions between multiple participants, and
therefore not imposing any requirements on any of those participants - and
thus coping with legacy web services. This also means that it should have no
'state/variables' that it is required to manage (locally or as part of the

Then the 'portable' choreography could aim to support the more active
monitoring of a choreography, but only where all participants support the
choreography interface. Not sure why the 'concrete' choreography is
required, unless the choreography mechanism now will assume the role of
connecting participants?

I am still unclear of the real benefit of having an 'active' choreography
mechanism that is required to manage its own state - is there a clear
business/use case that warrants this, over and about the passive monitoring?

The problem I see is that the logic within the choreography, related to
decisions, would end up having to replicate the same logic/state that is
within the participant, in order to determine which route the participant
will take - but what if the decision made by the participant is based on
private data (e.g. from a customer database) that is never exposed in any
message? Or does a participant implementing this choreography mechanism need
to expose this state information, so it is just shared by the choreography

Then there are the problems of keeping this logic in the participant and the
choreography in step.

If the choreography simply represents the alternate flows that could be
taken, and the actual flow is deduced by the observed message exchange, this
simplifies the monitoring, aswell as the maintanence of the choreography.

Apologies if any of these issues have been dealt with previously in the
mailing list, but unfortunately I have not had much time to keep tabs since
the last F2F.


This email is confidential and may be protected by legal privilege. If you are not the intended recipient,  please do not copy or disclose its content but  delete the email and contact the sender immediately. Whilst we run antivirus software on all internet emails we are not liable for any loss or damage. The recipient is advised to run their own antivirus software.
Received on Wednesday, 17 December 2003 10:27:25 UTC

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