Title: Message
I think that this topic may not be as straightforward as it may seem. A
simple, generic mapping or even simpler annotations could be developed fairly
easily. The problem is that BPEL4WS is basically a programming language. And
unfortunately, or fortunately, programmers are not the ones that develop the
majority of business processes. Business people are the main authors of business
processes. At some point, these people should be the target audience of tools
that are used for developing, maintaining, managing, and monitoring business
processes. This applies to both private and abstract (choreographic) processes.
The nature of BPEL4WS, with its block structures, is not conducive to this
target audience, even though a strict BPEL editing tool could easily be made
based on a simple mapping. Mapping to a flow-chart type of notation suitable for
business people, such BPMN or even UML, creates many challenges. It is not a
one-to-one mapping, but a derivation from the notation to the execution
language. This can be discussed in more detail within the sub-committee.
-Steve
-----Original Message-----
From: Sadiq, Waqar
[mailto:]
Sent: Fri 5/23/2003 10:08 AM
To: Burdett, David; Stephen White; Jim Webber; WS BPEL (E-mail)
Cc: ;
Subject: RE:
[wsbpel] A Topic for the F2F?
This is good but we
should remember that there are other modeling notations also.
It is more desirable to have a mapping mechanism that allows mapping to
other notations as well, existing as well as in progress or
future. That is why I think it is more important to have
generic binding mechanism to capture that kind of optional
information. BPMN, by no means, is the only notation to
design process. Also several existing tools have their own
proprietary notation. This, while not desirable, is a
reality and should still allow them to display BPEL scripts created
elsewhere.
_______________________________________________
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: Burdett,
David [mailto:]
Sent: Friday, May 23, 2003 12:00
PM
To: 'Stephen White'; Jim
Webber; Burdett, David; WS BPEL (E-mail)
Cc: ;
Subject:
RE: [wsbpel] A Topic for the F2F?
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
