OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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


Title: Guys:

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]
Sent: Friday, 21 May 2004 3:14 PM
To: Steve Capell; Alex Yiu; Rossomando, Philip
Cc: John Evdemon; Diane Jordan; Frank Leymann; ygoland@bea.com; nickolas.kavantzas@oracle.com; Ugo Corda; Monica J. Martin; Tony Fletcher; Ben Bloch; sundari.revanur@oracle.com; ashwini.surpur@oracle.com; Martin Chapman; Jeff Mischkinsky; wsbpel@lists.oasis-open.org; Malhotra, Sumeet S; Ismael Ghalimi; Dillman, Frederick
Subject: RE: [wsbpel] Next Meeting of the "Informal" Abstract BPEL Clarification Working Group

 

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]
Sent: Thu 5/20/2004 9:53 PM
To: Satish Thatte; 'Alex Yiu'; 'Rossomando, Philip'
Cc: John Evdemon; 'Diane Jordan'; 'Frank Leymann'; ygoland@bea.com; nickolas.kavantzas@oracle.com; 'Ugo Corda'; 'Monica J. Martin'; 'Tony Fletcher'; 'Ben Bloch'; sundari.revanur@oracle.com; ashwini.surpur@oracle.com; 'Martin Chapman'; 'Jeff Mischkinsky'; wsbpel@lists.oasis-open.org; 'Malhotra, Sumeet S'; 'Ismael Ghalimi'; 'Dillman, Frederick'
Subject: RE: [wsbpel] Next Meeting of the "Informal" Abstract BPEL Clarification Working Group

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]
Sent: Friday, 21 May 2004 9:10 AM
To: Alex Yiu; Rossomando, Philip
Cc: John Evdemon; Diane Jordan; Frank Leymann; ygoland@bea.com; nickolas.kavantzas@oracle.com; Ugo Corda; Monica J. Martin; Tony Fletcher; Ben Bloch; sundari.revanur@oracle.com; ashwini.surpur@oracle.com; Martin Chapman; Jeff Mischkinsky; wsbpel@lists.oasis-open.org; Malhotra, Sumeet S; Ismael Ghalimi; Dillman, Frederick
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]
Sent: Thursday, May 20, 2004 1:36 PM
To: Rossomando, Philip
Cc: Satish Thatte; John Evdemon; Diane Jordan; Frank Leymann; ygoland@bea.com; nickolas.kavantzas@oracle.com; Ugo Corda; Monica J. Martin; Tony Fletcher; Ben Bloch; sundari.revanur@oracle.com; ashwini.surpur@oracle.com; Martin Chapman; Jeff Mischkinsky; wsbpel@lists.oasis-open.org; Malhotra, Sumeet S; Ismael Ghalimi; Dillman, Frederick; Alex Yiu
Subject: Re: [wsbpel] Next Meeting of the "Informal" Abstract BPEL Clarification Working Group

 


Hi Phil and others,

My action item this week is to resend a snapshot of email what a group of TC people discussed about Issue 24 few months ago. I attached the ".eml" file here in this email for your reference.

A recap of what we did so far in Feb:
- identify the preliminary list of syntactic differences between abstract and exec BPEL: some of them are already a part of the spec; some are not in the spec yet (e.g. if query for assign is optional in abstract, how about expression?) ; those differences do not cover Issue 91, 97, 99 and 107.
- we also annotate the XSD with special syntax comment to make it easier for us to refer from the preliminary list of syntactic differences to the corresponding part of XSD.

(If someone has problem openning this eml file, please let me know. I tried both Outlook and Mozilla, they both work fine)

Thanks!


Regards,
Alex Yiu



Rossomando, Philip wrote:

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

 

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]