[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Next Meeting of the "Informal" Abstract BPEL Clarification Working Group
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 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]