Title: Message
If the
promise of BPEL is to be fulfilled it is to be expected that process
descriptions will grow to be quite complicated, on par with what can currently
be seen in traditional workflow implementations. I would imagine that one
point of differentiation among vendors of BPEL technology would be in the area
of presentation and constructions of such process descriptions. Perhaps it would
be wise to include a completely opaque vendor extension area in the process
descriptor for whatever visual annotation the vendor requires, rather than
developing specific visual annotations.
Maciej Szefler
Vice President - Product Development
FiveSight Technologies Inc.
213 N.
Morgan Street
Suite 1A
Chicago, Illinois 60607
phone: 312-432-0556 ext 226
email:
-----Original Message-----
From:
Sadiq, Waqar [mailto:]
Sent: Friday, May 23, 2003
11:56 AM
To: ; 'Jim Webber'; 'Burdett, David'; 'WS
BPEL (E-mail)'
Cc:
Subject: RE: [wsbpel] A
Topic for the F2F?
I think that David's
suggestion of "Visual binding" is very valid and is also inline with how WSDL
has an abstract portion and then bindings. I agree that the creation of
maintenance of BPEL would be most likely through design tool. Since during execution of a business
process, BPEL is more likely executed by a single BPEL execution engine, its
core value is preventing product dependency so that you can take BPEL created
and executed from one product suit into another. That makes the ability of being able
to render it into various editors important. So while I think the actual rendering
of the graphical information into a notation such as UML should be upto the capabilities of the designer tool, BPEL script
should carry the necessary graphical information, via some mechanism such as
visual binding extensions, so that the rendering tools can use
it.
Thjis is not the same as
the C# example cited earlier. The
main difference is that most C# programs are not generated but written. So the syntax highlighting, which is
useful for an IDE tool, is not that necessary. However, most BPEL scripts will not be
written by hand but rather auto-generated by editing tools and studios that
will translate a process model designed in a particular modeling notation into
the standard BEP script.
_______________________________________________
Waqar
Sadiq
EDS
EIT ESAI - Enterprise Consultant
MS:
H3-4C-22
5400
Legacy Drive
Plano,
Texas 75024
phone:
+01-972-797-8408 (8-837)
e-mail:
fax:
+01-972-605-4071
_______________________________________________
-----Original
Message-----
From:
Edwin
Khodabakchian [mailto:]
Sent: Friday, May 23, 2003 11:30
AM
To: 'Jim Webber';
'Burdett, David'; 'WS BPEL (E-mail)'
Cc:
Subject: RE: [wsbpel] A Topic for the
F2F?
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
