- From: Gary Brown <gary@enigmatec.net>
- Date: Wed, 17 Dec 2003 15:27:17 -0000
- 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 functional). 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 interaction). 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 mechanism? 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. Regards Gary. 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