- From: Jon Dart <jdart@tibco.com>
- Date: Tue, 01 Apr 2003 10:48:08 -0800
- To: public-ws-chor@w3.org
As David Burdett suggested, we've taken some discussion of the WSDL dependency issue discussed in the "Abstract messages" thread off-line. Participants in this off-line discussion included David, myself, Assaf Arkin, William Eidson, Ricky Ho, and Patil Sanjaykumar. I'd like to summarize this discussion, which concluded with a conference call yesterday. The original issue was whether it is a requirement or not to decouple the public (aka external) view of the choreography from WSDL. The motiviation for decoupling the choreography from WSDL was to be able to support general choreography definitions that can work with a variety of message formats (representing, for example, standards that are specific to certain industries). There was some discussion of how real a use case this is, but David's input is that at least for Commerce One, it is a common case (Assaf concurs). This raises a difficulty in cases where the choreography flow depends on the message contents. In those cases, you need to be able to extract the relevant parts of the message in order to make a test. The logic behind the test could be opaque (i.e. not specified in the external definition), but if it is not opaque, then it does need to reference message contents somehow and therefore (it seems) must assume something about the schema. David's original proposed solution was to separate the input and output schemas of the messages in the choreography from the choreography definition itself, and also to have the requirement that decision points based on message contents could be abstractly specified, and later bound to a particular schema. E.g. suppose we are testing the contents of an address, but it might be in a "USAddress" element or "UKAddress" element. In that case we may want to not specify the test (e.g. XPath expression) in the choreography, but instead put it in an external binding. Bill pointed out that WSDL definitions can vary in degree of abstractness. We could say it is necesary to specify a schema for the messages, but that schema could specify very little about the message structure, could define variant structures, and could leave places where extensions can be made. This being the case, it is possible that a single schema could express a range of possible message types. Also this allows tests to be be made on those portions of the message that are specified, without requiring that the message schema be made totally specific in the choreography. Finally, the issue was discussed, whether it is ever necessary to specify message definitions in such an abstract form that they may not even be XML, i.e. do we want to eliminate not only dependence on WSDL, but also dependence on XML Schema? Or, on the contrary, can we assume that at least at the point where the choreography is evaluating the message contents, that they are XML? IMO we could at this point just say that there's a requirement to support use of the same choreography definition with varying message schemas, and let it go at that. This is after all the requirements phase. However, at a lower level of detail (and closer to implementation) we have these questions: 1. Do we need, or want, to support external binding of the message schemas to the choreography definition, so that you can distinguish between the abstract operation you are performing as written in the choregraphy, and the actual service with which you communicate? (Thanks to Assaf for helping phrase this clearly. N.b. BPEL4WS does this, through the concepts of partners, roles, and serviceLinkTypes). 2. Do we need to allow external binding of decision points (based on message content) to specific decision logic, or it is sufficient to encode decisions in the choreography, given that they can be based on a partially abstract schema? 3. (Most fundamental) Should the choreography definition explicitly assume that metadata exists in the form of WSDL and XML Schema? David has an action item to further examine WSDL and XML Schema (esp. the latter) to see if its abstraction capabilities could be made use of to allow a solution to the message-independence requirement different from the one he originally proposed (in particular: Bill's alternative). IMHO: 1. may be desirable just as a good design principle as it furthers re-use; 2. external binding is probably not necessary but we might vote to allow it as an optional feature (I don't think it should be required); 3. My preference would be to use WSDL + XML Schema, if these are sufficiently expressive to meet the use cases (David's further input needed here). --Jon
Received on Tuesday, 1 April 2003 13:48:15 UTC