Title: Message
Jim,
The
Collaxa BPEL Console and Designer include indeed an automatic layout
manager. But having a facility to capture metadata about activities/links and
having a standard set of metadata for a visual notation would be a plus as
it would provide hints to overide the default behavior of the layout
manager.
I
think that the problem David is highlighting is a real one: the value of BPEL as
a process flow execution language is standard skill sets and portability across
BPEL server. Given that very few people will actually write the raw XML BPEL
code manually, skill sets and knowledge re-use become a tool
problem.
Part
of the challenge here is that it is still early to decide on tools and visual
modelling approaches: UML 2.0, BPNL, RAD modeling etc...At this point I think
that you do NOT want to limit the use of one set of notations only. This is why
I suggest an extensible activity metadata framework with specific set of
attributes for each notation.
I
agree on Dave as well that where to capture the metadata should be open for
discussion once we know what it looks like for a sample notation language. My
preference would be to use something like process stylesheets (similar to HTML
stylesheets) but we can talk more about this at the appropriate
time.
Edwin
From: Jim Webber
[mailto:]
Sent: Friday, May 23, 2003 2:48
AM
To: 'Burdett, David'; 'WS BPEL (E-mail)'
Cc:
;
David,
I
take a contrary view to this. My belief is that for any given project, the
source code (which in this case is a BPEL "script") is the definitive
descriptor for the entire project. Anything else, like a visual
representation, is simply a view on that source code.
Now
we may choose to invest effort in creating a standard means of transforming
that source code into something visual (or perhaps an intermediate format that
makes visualisation easier), but that should not be part of the BPEL
"scripting language." For an analogy, I have never programmed any C#
applications with additional features to support syntax highlighting, the tool
that I use works it out from the source code (which bits of text should be in
blue, which in black and so forth).
Now
my view may be naive because you might have come across some bits of BPEL for
which we simply cannot compute a visual representation, and if that is the
case then your motion is probably a strong one. However, I notice that the
Collaxa implementation of BPEL4WS has a visual audit trail facility (and I
belive also a visual wizard now?) which makes me think that it is possible to
compute a visual representation without having to add clues into the
script.
Perhaps Doron or Edwin would
share their thoughts here?
Jim
-----Original Message-----
From: Burdett, David
[mailto:]
Sent: 22 May 2003
23:45
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
