RE: Abstract messages [Was: Multi-Party Binding Scenario]

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