These all seem like reasonable arguments.
As was stated at the meeting today,
I feel we need to at least mention
modeling because, it makes sense to use
Abstract BPEL for modeling and others in
our TC have expressed an interest
In doing just that. We need not focus on
this use case but we must call it out
As a recognized usage for this tool.
Phil
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: Sally St. Amand
[mailto:sallystamand@yahoo.com]
Sent: Friday, June 18, 2004 10:56
AM
To: Satish Thatte
Cc:
wsbpel-abstract@lists.oasis-open.org
Subject: RE: [wsbpel-abstract]
Modification of Sally's document from Tony
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
>
>