Title: Message
+1
From: Sadiq, Waqar
[mailto:]
Sent: Friday, May 23, 2003 10:08
AM
To: Burdett, David; 'Stephen White'; Jim Webber; WS BPEL
(E-mail)
Cc: ;
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
