wsbpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsbpel] A Topic for the F2F?
- From: "Tony Andrews" <tandrews@microsoft.com>
- To: "Burdett, David" <david.burdett@commerceone.com>,"WS BPEL (E-mail)" <wsbpel@lists.oasis-open.org>
- Date: Thu, 22 May 2003 16:33:03 -0700
I just wanted to comment on your first assumption below.
The "business protocol" extensions in BPEL are very much about describing
behavior, as opposed to execution. A BPEL abstract process definition is a
useful description of behavior regardless of how the service is
implemented. I would even argue that "business protocol" may be an unfortunate
name for this given that we're really talking about services in a more
general sense. The two usage styles - "executable processes" and "business
protocols" can each be used independently or together as
appropriate.
Regarding your real point, I wonder if a set of standard
annotations and extensions within the BPEL document itself would be sufficient.
Separating these into different documents seems troubling to
me.
Tony
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]