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

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

From: Ugo Corda <UCorda@SeeBeyond.com>
Date: Tue, 27 Apr 2004 08:55:48 -0700
Message-ID: <EDDE2977F3D216428E903370E3EBDDC9032B8AD4@MAIL01.stc.com>
To: "Tony Fletcher" <tony.fletcher@choreology.com>, <public-ws-chor@w3.org>
Tony,
 
The answer to your Why question in the case of BPEL might be as simple
as the one you find in "Goals of the BPEL4WS Specification" (see [1]),
where it says:
 
"BPEL4WS is firmly set in the Web services world as the name implies.
In particular, all external interactions occur through Web service
interfaces described using WSDL.  This has two aspects: (1) the process
interacts with Web services through interfaces described using WSDL and
(2) the process manifests itself as Web services described using WSDL". 

In any case, I am curious to see what types of answers your question on
whether BPEL abstract processes need WSDL is going to get on the BPEL
list.
 
Regards,
Ugo
 
 
[1]
http://www.oasis-open.org/committees/download.php/3249/Original%20Design
%20Goals%20for%20the%20BPEL4WS%20Specification.doc
 

	-----Original Message-----
	From: Tony Fletcher [mailto:tony.fletcher@choreology.com] 
	Sent: Tuesday, April 27, 2004 4:22 AM
	To: Ugo Corda; public-ws-chor@w3.org
	Subject: RE: Issue 662: specify at least two levels or types of
Choreography description
	
	
	Dear Ugo and others,
	 
	Sorry I have been a bit distracted with other matters, but would
like to pick this up again now.
	 
	Thank you for your observations in this mail and the previous
ones.
	 
	But the obvious question is:  Why?
	 
	In this case when we are interested in only a high level, arm
waving sort of description what is it that a WSDL description brings
that is required?
	 
	I think this question definitely applies to WS-Choreography and
possibly to BPEL as well (though generally that is aimed at a lower
level) - so I might see if it is an issue on the BPEL list.
	 
	Note again that the question in my mind is whether a set of WSDL
descriptions always needs to accompany a WS-Choreography description -
they certainly will for a detailed level choreography description, but
they seem to be too much detail (and will add many lines) when focussing
on just the basic allowed message sequences.
	 
	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)
	 
	

		-----Original Message-----
		From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
		Sent: 16 April 2004 22:02
		To: Tony Fletcher; public-ws-chor@w3.org
		Subject: RE: Issue 662: specify at least two levels or
types of Choreography description
		
		
		Tony,
		 
		Your quote of the BPEL spec talks about variable
references that can be omitted. But that is separate from using WSDL
descriptions. In particular, those <invoke/>, <receive/>, and <reply/>
activities would still need a portType reference, even in cases where
the variable reference attributes had been dropped.
		 
		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 1:36 PM
			To: public-ws-chor@w3.org
			Subject: RE: Issue 662: specify at least two
levels or types of Choreography description
			
			
			Dear Ugo and others,
			 
			Well, if that is the case then that is a problem
for BPEL that should perhaps be taken up on their list (there are a
number of open issues on abstract processes).  If the WS-Choreography
group can agree to provide a one document description of any
choreography between two or more parties that is as simple as possible
when all that is required is a 'high level' description of the
choreography, then that will be a big 'selling' point for
WS-Choreography IMHO.
			 
			[However, I would question what you say as
Section 15.1 of the BPEL spec (Nov 03) states:  In many cases, the level
of abstraction appropriate in abstract processes makes it unnecessary to
use message variables in web service interaction activities, when the
intent is to simply constrain the sequencing of such activities, and the
actual message data is not relevant. To simplify these common cases it
is permissible, in abstract processes, to omit the variable reference
attributes from the <invoke/>, <receive/>, and <reply/> activities. 
			If you can enlighten me further I would
appreciate it, but perhaps directly to me and not on this list unless
you feel the points are relevant to the WS-Choreography group   Thank
you]
			 
			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)
			 
			

				-----Original Message-----
				From: Ugo Corda
[mailto:UCorda@SeeBeyond.com] 
				Sent: 16 April 2004 20:28
				To: Tony Fletcher;
public-ws-chor-comments@w3.org; public-ws-chor@w3.org
				Subject: RE: Issue 662: specify at least
two levels or types of Choreography description
				
				
				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 Tuesday, 27 April 2004 11:56:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:04 UTC