W3C home > Mailing lists > Public > public-ws-chor-comments@w3.org > April 2004

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

From: Ugo Corda <UCorda@SeeBeyond.com>
Date: Fri, 16 Apr 2004 12:28:08 -0700
Message-ID: <EDDE2977F3D216428E903370E3EBDDC9032B8ABC@MAIL01.stc.com>
To: "Tony Fletcher" <tony_fletcher@btopenworld.com>, <public-ws-chor-comments@w3.org>, <public-ws-chor@w3.org>
Tony,
 
> I am fairly sure that abstract BPEL does not demand WSDL descriptions.
 
Actually it does. Most of the BPEL spec applies both to executable and
abstract processes. The differences for the case of abstract processes
are detailed in sec. 15 and only relate to the way variables and
assignments are defined.
 
Ugo

	-----Original Message-----
	From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of Tony Fletcher
	Sent: Friday, April 16, 2004 4:54 AM
	To: public-ws-chor-comments@w3.org; public-ws-chor@w3.org
	Subject: 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)
	 
	
	 
Received on Friday, 16 April 2004 15:28:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:09 GMT