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:
waqar.sadiq@eds.com
fax:
+01-972-605-4071
_______________________________________________
-----Original Message-----
From: Burdett, David
[mailto:david.burdett@commerceone.com]
Sent: Friday, May 23, 2003 12:00 PM
To: 'Stephen White'; Jim Webber;
Burdett, David; WS BPEL (E-mail)
Cc: doron@collaxa.com;
edwink@collaxa.com
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.
-----Original Message-----
From: Stephen White
[mailto:swhite@SeeBeyond.com]
Sent: Friday, May 23, 2003 8:41 AM
To: Jim Webber; Burdett, David; WS
BPEL (E-mail)
Cc: doron@collaxa.com;
edwink@collaxa.com
Subject: RE: [wsbpel] A Topic for
the F2F?
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?
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?
-----Original Message-----
From: Burdett, David
[mailto:david.burdett@commerceone.com]
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 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.
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.
|