RE: [wsbpel-abstract] Modification of Sally's document from Tony

["Sally St. Amand" <sallystamand@yahoo.com>]

You cannot tell people how to use or not use a specification; actually you can but it usually has no affect. But I believe we should be precise in how we envision abstract bpel. That is there are a set of minimum requirements that define abstract bpel.

Given the charge of this TC and the amount of time spent on refining the execution language I would suggest that those minimum requirements for abstract bpel are

- the external or public view

- achieves conformance through the business process execution language

 

The specificatin can include notes recognizing additional uses.

We need to look at what is the primary goal of this TC. And there will be more evolution of bpel.

Sally

Satish Thatte <satisht@microsoft.com> wrote:

I believe abstract BPEL could be a starting point for a representation used by a modeling tool. As Nick pointed out, if you think of an abstract process as an indeterminate or partially specified process, then that can be used for partial description of the behavior of one business actor. Now the primary use case motivating this for us should be external or public views, based on what the spec already states as the goal. It is also a far simpler and more vendor neutral goal than modeling. But that does not preclude modelers from using abstract BPEL as the basis for an intermediate form for in-progress descriptions of their process models. My concern is with taking on modeling-specific requirements. Thus, for instance, we should not motivate or any other special notation based on a modeling use case. We cannot and should not prevent modelers from using abstract BPEL for any purpose if it suits them.

I believe Monica is asking for a notion of conformance in the same sense I did in my strawman paper. Here is what I wrote there:


If an abstract process claims to be the externally observable behavioral description of (some aspect of) a previously existing executable process, or vice versa, an executable process claims to faithfully implement external behavior as previously specified in an abstract process, we must be able to define the meaning of the validity of such claims. At the same time we recognize that given the expressive power of BPEL, the mechanical verification of such conformance claims is not decidable in general.


________________________________

From: Rossomando, Philip [mailto:Philip.Rossomando@unisys.com]
Sent: Tue 6/15/2004 1:47 PM
To: John Evdemon; Monica J. Martin; Tony Fletcher
Cc: wsbpel-abstract@lists.oasis-open.org
Subject: RE: [wsbpel-abstract] Modification of Sally's document from Tony



John:

While modeling may be out of scope for now,
I think we should recognize that potential
Use case. Having done so, we can say that we
Recognize it to be out of scope. Thus people
Reading the spec will not feel we forgot to even
Think of it.

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


-----Original Message-----
From: John Evdemon [mailto:jevdemon@microsoft.com]
Sent: Tuesday, June 15, 2004 3:47 PM
To: Rossomando, Philip; Monica J. Martin; Tony Fletcher
Cc: wsbpel-abstract@lists.oasis-open.org
Subject: RE: [wsbpel-abstract] Modification of Sally's document from
Tony

While a use case might assume the presence a modeling tool, we should
refrain from making any recommendations about modeling techniques or
graphical representations.



> -----Original Message-----
> From: Rossomando, Philip [mailto:Philip.Rossomando@unisys.com]
> Sent: Tuesday, June 15, 2004 12:06 PM
> To: Monica J. Martin; Tony Fletcher
> Cc: wsbpel-abstract@lists.oasis-open.org
> Subject: RE: [wsbpel-abstract] Modification of Sally's
> document from Tony
>
> Interesting observations on both your parts.
> As I mentioned in my trial balloon proposal
> For an abstract bpel use case, I envision
> The business person putting together a visual
> Model and the abstract bpel is generated by
> A tool under the covers so to speak. Think
> IBM had such a tool for Eclipse.
>
> That minimum set of core requirements for
> Abstract bpel make a lot of sense. It would
> Establish a framework and help to focus our
> Discussion. Tony what do you think?
>
> Phil Rossomando
>
> Good suggestions...
>
> 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
>
>
> -----Original Message-----
> From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
> Sent: Tuesday, June 15, 2004 2:16 PM
> To: Tony Fletcher
> Cc: wsbpel-abstract@lists.oasis-open.org
> Subject: Re: [wsbpel-abstract] Modification of Sally's document from
> Tony
>
> Tony Fletcher wrote:
>
> > Dear Colleagues,
> >
> > I have just added my thoughts for requirements on Abstract
> BPEL at the
>
> > end of Sally's document
>
> mm1: Tony, when you indicate you could go from a messaging sequence
> diagram to an abstract process, this is only related to the
> view of the
> party correct? You also indicated in your paper that the abstract
> process would allow hiding. Reference:
>
> <<> only uses
> some, or none, of the optional language features. An abstract BPEL
> process designer is able to add or omit detail as they
> please, limited
> only by the features of the language.>>>
>
> Are we to infer then that we have a minimum set of core mandatory
> language features in the abstract process? Would that assist us in
> helping to ensure conformance (not compliance) [1] and/or
> compatibility
> with the executable process?
>
> One more point, on your target audience, I am uncertain if a business
> process expert would be involved with abstract BPEL. The target
> audience, I believe begins with the architects you listed.
>
>
> [1] Loaded term with implications for software
>
>