There is work currently going on to build a mapping from a standard visual
notation (BPMN) to BPEL4WS. This work is going on within BPMI, who are also
participating within the WSBPEL TC. I would propose that this sub-committee work
with BPMI to leverage and improve the work being done there. I am heading up
that work and would be happy to provide any information about it next
week.
-----Original Message-----
From: Jim Webber
[mailto:jim.webber@arjuna.com]
Sent: Fri 5/23/2003 2:47 AM
To: 'Burdett, David'; 'WS BPEL (E-mail)'
Cc:
doron@collaxa.com; edwink@collaxa.com
Subject: RE: [wsbpel] A Topic
for the F2F?
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
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