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

["Trickovic, Ivana" <ivana.trickovic@sap.com>]

+1

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Freitag, 18. Juni 2004 15:58
> To: Rossomando, Philip; 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
> 
> 
> 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 <opaque> 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:
> >
> > <<<It must be possible to have an abstract BPEL process that
> > 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
> >
> >
> 
>