Title: Message
If
there is an activity that is already adressing this problem then I, for one,
would not want to invent another. If we decide that this type of capability is
useful then we should look into the BPMI work in more
detail.
David
-----Original Message-----
From: Stephen White
[mailto:]
Sent: Friday, May 23, 2003 8:41
AM
To: Jim Webber; Burdett, David; WS BPEL (E-mail)
Cc:
;
Subject: RE: [wsbpel] A Topic
for the F2F?
Jim, David,
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.
-Steve
-----Original Message-----
From: Jim Webber
[mailto:]
Sent: Fri 5/23/2003 2:47 AM
To: 'Burdett, David'; 'WS BPEL (E-mail)'
Cc:
;
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
-----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
