Issue 662: specify at least two levels or types of Choreography description

Dear Colleagues,
 
Following on from the teleconference on 13 April 2004, I would like to
emphasise that I consider this issue still open, and not closed by the
discussion at the recent face to face.
 
I do recognise the need to make forward progress - I have been critical of
our slowness in the past and believe it is one of the factors in our loss of
numbers over time.  I would like to pay tribute to Nick and David and others
for producing the draft specification and materially moving us on.
 
However, I think it is even more important that we make sound decisions and
are prepared to re-visit ones that may be unsound.
 
Thus, I would urge the group to re-consider the decision made by those
present at the F2F for the following reasons, which can be summarised as the
decision is unnecessary and does not help our cause.
 
Firstly the decision does not follow from the discussion.
Decision:   Bound to WSDL 
Discussion:  premature to even establish this hierarchy/factoring ....
there is a spectrum of "abstractness" (nothing bound --> fully bound) 
{Selective quoting deliberate}
 
Secondly the decision does not meet the fairly obvious requirement that we
should to enable a description of a basic message flow to be as simply as
possible without requiring extraneous syntax.
 
In raising this issue I put it like this (and this *requirement* should be
clearly stated in the requirements document - if not please raise 662 as an
issue against the Requirements document in addition to against the
specification).
One level could be called abstract or business process oriented or some

such.  It would support focus on the definition of the business exchanges.

It would specify the allowed sequencing of messages and the nature of each

message.  It would not have to provide a precise specification (/schema) for

each message nor how each message was to be transported.  This it would

allow agreement of the basic business 'protocol' but would be insufficient

to enable interoperability on its own.



Another level or type of Choreography description would provide a precise

specification and schema for each message and how each message was to be

transported.  It would thus be a basis for interoperation or at least

provide the interoperability specification of the upper layers of the

protocol stack.
Points for consideration:
 
1)  The fact that this issue was raised on the 13 April 04 teleconference
(and not by myself) and gave rise to a long discussion with at least 4
people speaking against the asserted resolution means that there is not
consensus on the current solution amongst all those still active in the
group.
 
2)  When attempting to describe just the message sequencing of a
choreography (what one might describe as a 'pure' choreography insisting on
having WSDL descriptions as well brings nothing but extra complexity.  Or to
put it the other way around: what do WSDL descriptions add that is required
in this case?
 
3)  Imagine a choreography where one participant (A) exchanges messages with
another (B) that exchanges messages with another (C) that exchanges messages
with another (D) {i.e. four systems in a line).  To describe this
choreography using abstract BPEL would take a minimum of 2 abstract process
plus the statement that there are only four participants (without that
statement you need four abstract processes, otherwise you do not know that
there is not something else connected to A or D).  I am fairly sure that
abstract BPEL does not demand WSDL descriptions.
Surely our aim and differentiator from BPEL is that we need only one
WS-Choreography XML document to describe this situation - at this level of
detail.  If we insist on having WSDL then you need 7 XML documents (1
WS-Choreography document and 6 WSDL documents) - and we loose!
 
Proposal:
That we allow several different versions of the same choreography (with
differing amounts of detail) to be valid against the schema and against the
text of the specification.
 
At one end of the spectrum, the the simplest would be a single XML document
that just described the allowed sequencing of messages of a stated nature
(may just be stated in a comment or documentation element).  There would be
no requirement to provide WSDL descriptions or schemas for the messages.
 
Another common point on this spectrum might be where there is the
Choreography description plus the WSDL descriptions including the message
schemas - as required by WSDL 2.0 - but no binding information.
 
The other end on the spectrum would be to provide all the detail possible -
Choreography description plus the WSDL descriptions plus bindings.  The
justification for this level of detail is that it is only this level of
description that gets you anywhere near to interoperability.
 
Notice to that it is my hope that you can start at the simple end and
develop a description incrementally and have syntax and 'good practice'
support as you do so.  It should be possible to couple in WSDL descriptions
naturally at the appropriate point in the development cycle.  Different
points on the spectrum can be used for different purposes and so it is
advantageous to have them as valid and checkable.  The simplest descriptions
will be used in the initial design and to gain agreement to that design.
That level and more detailed levels will be usable by developers (for
instance) and the most detailed level will be useful for system
administrators / system configuration.
 
Sorry for the lengthy message, but I hope it makes the point.
 
Best Regards     Tony
A M Fletcher
Home: 35, Wimborne Avenue, IPSWICH  IP3  8QW
Tel: +44 (0) 1473 729537   Mobile: +44 (0) 7801 948219
 amfletcher@iee.org     (also tony.fletcher@talk21.com  &
tony_fletcher@btopenworld.com)