[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Next Meeting of the "Informal" Abstract BPEL Clarification Working Group
My thoughts on abstract processes are
attached. Food for discussion at tomorrow’s call. From: Alex Yiu [mailto:alex.yiu@oracle.com]
Abstract BPEL
Clarification Working Group Members:
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 Blue 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
|
Usage of BPEL Abstract Processes Strawman.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]