[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
Satish, Yes it makes sense. In fact I’m a bit surprised how
quickly you have understood my rather confused effort at explaining my position…. Don’t know whether to classify it as “executable”
though. It is executable in the sense that it drives a piece of software
who’s job it is to manage compliance to a public contract. However
it does not get executed on a conventional BPM that actually invokes services
in the context of a sequence… In any case, I hope the BPEL groups will consider this use
case in your work on abstract BPELs. I will be pleased for forward my
work (when I have done it) on mapping BCF process model elements to WS deployment
schema elements such as BPEL, WSDL & WS-Policy. The biggest gap I see
at present is the lack of a set of WS-Policy assertions that are focused on
defining the semantics of public collaborations. For the present I’m
just planning to borrow the BCF/BPSS semantics but put them in a WS-Policy
syntax… Thanks for your feedback. Regards, Steve Capell Red Wahoo Pty Ltd +61 410 437854 From: Satish Thatte [mailto:satisht@microsoft.com] Steve, If I
understand you correctly, you are expecting the public abstract BPEL to be used
to create a "front end executable process" that performs certain
actions such as functional acknowledgement and possibly also acts as a guard
ensuring runtime compliance with the public contract. It is perfectly
possible to contemplate creating such an executable process (almost?)
automatically from an abstract process, and I would call this use case an
interesting refinement of my Usage Scenario 2. Does
that make sense to you? Satish From: Steve Capell
[mailto:steve.capell@redwahoo.com] Satish, I like your review and particularly your positioning of
abstract BPEL as a description of the observable behaviour of one party in a
multi-party collaborative process (definition scenario 2). However but
would disagree slightly with your usage scenario 2 in which you position the
abstract BPEL as a template for implementation of an executable BPEL and you
assert that the template would be subject to some human scrutiny before it is
deployed as an executable BPEL. My background is that I have been implementing an ebXML
framework where abstract “public processes” are defined by BPSS
schema (multi-party collaboration definition) and template CPA schema
(bilateral agreements between two roles in a process). Public
process schema are generated from UN/CEFACT BCF models. Now for a
particular party to comply with the public process, an executable private
process is needed that will connect the internal processes & services to
the public domain. Our private processes utilize executable BPEL. What I am trying to do now is provide an alternative
deployment technology for the public process models. Specifically I want
to generate Abstract BPEL, WSDL, WS-Policy schema from the same BCF model -
that together will provide the same capability as the ebXML BPSS and template
CPA schema. This is basically so that we can support the same
collaborative business process models on either an ebXML or a Web Services
deployment technology. The middleware tools in which these schema are deployed
provide a strong separate of public process from private process.
Currently we have an ebXML message handler what is driven by CPAs that are
delivered from a registry based service, a “Business Service
Interface” (BSI) that is driven by the BPSS schema, and a Business
Process manager that is driven by the executable BPEL (as well as the other
obvious components of typical middleware packages). The reason I bore you with this is that I wanted to point
out that the BSI’s job is compliance with the public process and to
separate some of the implementation details of that from the private
process. For example, the public process may implement a particular
transaction pattern that required a request document, message acknowledgments,
message acceptance signals, response documents, etc - each with timeout
conditions and security / non-repudiation requirements. I want the BSI to
just deal with all that and thereby simplify my private process (executable
BPEL) that now just needs to handle the business request message and create a
business response message. So I would like the abstract BPEL
(together with a set of WS-Policy Assertions) to automatically configure my BSI
and to be separate from the executable BPEL that represents the private
process. In this case the Abstract BPEL is a self contained thing and is
not used as a stub or template from which to generate an executable BPEL.
Regards, Steve Capell Red Wahoo Pty Ltd +61 410 437854 From: Satish Thatte [mailto:satisht@microsoft.com] 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]