Tony
Thanks
for the comments, I agree, that "Business Process Execution Language" is a bit
of a misnomer and perhaps it should be simply called a "Process Execution
Language" ... but let's not go there ...
As far
as including the Visual Binding extensions in BPEL natively is concerned I think
we can actually separate the work into two parts:
1.
Identify WHAT additional information needs to be held to identify the graphical
information, and
2.
Design HOW to represent that information. At this point we can choose to include
it within the BPEL language or have a separate language. We can also decide
whether it goes in the same spec e.g. in an Appendix or in a separate
spec.
The
point is that we do not have to decide immediately HOW to specify
it.
David
-----Original Message-----
From: Tony Andrews
[mailto:]
Sent: Thursday, May 22, 2003 4:33
PM
To: Burdett, David; WS BPEL (E-mail)
Subject: RE:
[wsbpel] A Topic for the F2F?
I just wanted to comment on your first assumption below.
The "business protocol" extensions in BPEL are very much about describing
behavior, as opposed to execution. A BPEL abstract process definition is a
useful description of behavior regardless of how the service is
implemented. I would even argue that "business protocol" may be an unfortunate
name for this given that we're really talking about services in a
more general sense. The two usage styles - "executable processes" and
"business protocols" can each be used independently or together as
appropriate.
Regarding your real point, I wonder if a set of standard
annotations and extensions within the BPEL document itself would be
sufficient. Separating these into different documents seems troubling to
me.
Tony
From: Burdett, David
[mailto:]
Sent: Thursday, May 22, 2003
3:45 PM
To: WS BPEL (E-mail)
Subject: [wsbpel] A Topic for
the F2F?
Here's a topic I
would like to suggest for discussion at the F2F.
THE
PROBLEM
The problem arises
because of three assumptions that I believe are
valid:
1. BPEL is an
"execution only" language, i.e. it is desgined to be something that can be
input into software and run, e.g. using some "BPEL Run Time"
software
2. BPEL will often
be defined and maintained with the aid of some GUI based "BPEL Design Time"
software that allows the process to be visualised.
3. The BPEL Design Time software will contain additional
positional and graphical information about the visual representation of the
BPEL design that not contained in the BPEL XML
definitions.
The problem is
that this means that exporting a BPEL definition from one BPEL Design Time for
input into another will result in a BPEL definition that will not be easily
editable as all the graphical information would be lost.
In the extreme,
for a complex design, it could mean that designer of business processes using
BPEL is effectively locked into the BPEL Design Time software provider that
they initially choose. This I don't think is a good idea.
THE SOLUTION
?
To solve this
problem I would like to suggest the setting up of a sub-committe of the TC
that has responsibilty for developing a "BPEL Visual Binding" specification
which would contain the relevant visual information from the BPEL Design Time.
The idea would be that the Visual Binding specification is
a separate document to the main BPEL
specification. Also BPEL Design Time Implementations could export
either:
1. The BPEL XML
Definition alone, or
2. The BPEL
XML Definition PLUS the BPEL Visual Binding
The former could
be used for input to a BPEL Run Time and the latter could be input into some
other BPEL Design Time.
By creating a
separate, but related, specification, it should be possible to carry out the
work on the BPEL Visual Binding specifcation in parallel, without hindering
any work on the main BPEL specification.
Regards
David
Director, Product Management, Web
Services
Commerce One
4440
Rosewood Drive, Pleasanton, CA 94588, USA
Tel/VMail: +1 (925) 520 4422;
Cell: +1 (925) 216 7704
mailto:; Web: http://www.commerceone.com
