Abstract BPEL Clarification
Working Group Members:
Our next teleconference will be on Friday
5/21/2004 from 11:00
AM to 12:00
AM EDT.
Our ultimate objective remains to address the
"left something out" point raised by Satish in our previous meeting.
What are the "some things?" and what's left after these are left out.
What is Abstract BPEL to be used for? We need to arrive at a consensus of opinion.
The key here is to get all idea on the table. I want to personally thank all
those who attended our last meeting and if you know others who may be
interested, please feel free to invite them. The contact number is
1-877-302-3764 and the pass code is 4233998. I am looking forward to our next
meeting. Please try to come prepared.
I apologize in advance if I did not include some of you on the direct
mailing list. If you would kindly send me email to this effect, I will happily
correct the omission in the future. (Ivana, sorry but I could not find your
email address L).
Action Items:
All: Try to write what you
personally consider an Abstract BPEL Use Case.
Here if you don’t write one, get behind someone who has/will so that
Your views are expressed.
All: Come up with a list of “Must Haves” relative to Abstract BPEL. This
Action is especially important for those of you who don’t write a Use
Case.
All: Understand the point being brought out by Issues 82, 109 and 107.
Satish: Make explicit the two use cases related to abstract BPEL. The first
Relates to providing templates for those wishing to provide
implementations of standardized services. The second relates to
To define the externally visible contract for a protocol. See letter
at bottom of this email message. (Note: Nick was supposed to help
Satish).
Nick: When use cases and requirements are available figure out what is
The definition of Abstract BPEL. (Actually, this is an action item for the
Group to ultimately address.)
Alex: To resend what he created relative to Abstract and Executable BPEL
XSDs.
Phil: Contact Yaron and ask to see if he can come up with an Abstract
BPEL Use Case that incorporates opaque as both an element and an
Attribute.
Phil: Remind John to provide us with the Abstract BPEL Use Case he promised
Us for May 14 meeting.
Phil: Get out the minutes of this meeting.
Diane: Get us a place (sub-list) on our TC Web site where we can post our work products.
Left over from Last Meeting:
All: Review spec on abstract BPEL Section 15 (extensions for Business Protocols).
Although not present, it would be nice if Yaron would come up with a Use Case incorporating
Opaque as an Element and
as an attribute.
Phil Rossomando
Research Director, Technology & Architecture
Unisys Corporation
Unisys Way, B-330
Blue Bell, PA 19424 USA
Philip.rossomando@unisys.com
215-986-3998
FAX 413-0215-2043
The following was taken from an email exchange between Yaron and Yuzo dated Thu 4/15/2004 3:17 PM
I actually see abstract processes being used in two different contexts.
#1 - To define the externally visible contract for a protocol. That is,
system A wishes to work with system B. System B publishes an abstract
process. System A writes its code to work with System B's abstract
process and so is able to interoperate with System B's executable process.
#2 - To provide templates for those wishing to provide implementations
of standardized services. For example, the International Association of
Widget makers provides a standard for a widget request service. As part
of that standard they provide an abstract process definition that
specifies how someone implementing the widget request service is to
behave. So when a widget maker decides to implement the widget request
service they will validate their executable code against the abstract
process definition. In other words, they must make sure that their
executable process does the same thing the abstract process definition
specifies. This is the inverse of the previous example.
To your point about being able to put in an assign but not a receive, I
would offer the following as a counter example. Imagine that a widget
maker implementing the widget request service adds in a receive to their
implementation of the widget request service that waits for up-to-date
information from the widget factories as to the current number of
available widgets. This receive not be specified in the abstract process
definition since it is not relevant to that definition how the widget
request service knows how many widgets are available. So in this case it
is completely reasonable for the executable process to add in a receive
that was never specified in the abstract process definition.
Finally, as to your assertion that opaque is not necessary it is very
difficult to respond to an assertion. In my original e-mail below I
provide two examples where the use of either nothing or empty causes
ambiguities and then show how opaque resolves those ambiguities. If you
could illustrate that the ambiguities I describe don't actually exist
then it would seem likely that you would have made the case that opaque
is unnecessary.
Thanks,
Yaron