- From: Ugo Corda <UCorda@SeeBeyond.com>
- Date: Fri, 16 Apr 2004 14:02:04 -0700
- To: "Tony Fletcher" <tony_fletcher@btopenworld.com>, <public-ws-chor@w3.org>
- Message-ID: <EDDE2977F3D216428E903370E3EBDDC9032B8ABD@MAIL01.stc.com>
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 Friday, 16 April 2004 17:02:36 UTC