[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
Alex, Answers in your e-mail below… Steve Capell Red
Wahoo Pty Ltd +61 410 437854 From: Alex Yiu [mailto:alex.yiu@oracle.com]
Remember that my answers to your questions come from the
perspective of a business partner that needs to “comply” with a predefined
public process (and by that I mean process model, information model, and
deployment technology). This use case is not addressing the business that
wants to create some arbitrary new web service.
Yes – I think the designer of a private process should
ideally not have to worry about: ·
The deployment technology of the public
process (eg ebXML or WS) – that is abstracted by the message service
interface ·
The details of the QOS attributes of the
public process (eg whether a receipt acknowledgement is needed, whether it
should be signed, what the timeout period is, etc…) – that is
abstracted by the business service interface. The private process designer should just have to think about
the semantic/syntax transformations and internal services that are needed to
meet the BUSINESS (but not the technology) requirements of the public process.
Hmm, I’m not so sure about this. It is a
question of who “owns” the public process vs the private process –
and hence who is responsible for lifecycle management etc. ·
Assume that the “public process”
is a model plus a collection of deployment schema that are created by a working
group established under the auspices of a standards body like ANSI, Standards
Australia or EAN International. The model and the schema strictly
describe the public process and say nothing about how a particular party will
comply. ·
A private process is an executable BPEL
plus supporting schema like XSLT, X-Forms, etc that are created either by a particular
business party (typically one that owns a home grown legacy back-office system)
or by a vendor on behalf of a larger community (that are all users of the same
back office). The job of the private process package is to provide
compliance to the public process for the community that can re-use the same
private process (ie they all have Quickbooks as their FMS). In this scenario, the public process collection of schema
objects and the private process collection of schema objects are created and
maintained by different groups and will have totally separate packaging and
lifecycle management.
True. I should be able to change private processes
without changing public process behaviour.
Yes – with the exception of the lifecycle management
and ownership story..
The reason we are looking at BPEL this way is because we are
focused on B2B processes. Particularly those that are characterized by
having a very large number of small players that all need to comply with the
same public process standards. An example is Superannuation (401k in the
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]