RE: [wsbpel] Issue - 82 - Proposal for Vote

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Looks good.

Peter

> -----Original Message-----
> From: rkhalaf [mailto:rkhalaf@watson.ibm.com] 
> Sent: 11 October 2004 21:06
> To: Furniss, Peter
> Cc: wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue - 82 - Proposal for Vote
> 
> 
> Hi Peter,
> 
> Perhaps this should go under part E:
> 
> E. Abstract processes say nothing about *how* concrete, 
> executable realizations of them should be implemented (ie: 
> language, platform, etc) (analogy to WSDL). Nor do they imply 
> a one-to-one relationship with any such realizations. For 
> example, several abstract processes may provide different 
> views on the same executable artifact, each projecting only 
> the activities concerning a subset of the partnerLinks.
> 
> What do you think?
> 
> Furniss, Peter wrote:
> > This looks very good. I wonder if it would be worth explicitly 
> > including near the end something on the lines of:
> > 
> > "A concrete realisation may correspond to more than one abstract 
> > process definition. Such the abstract definitions might differ in 
> > which partnerLinks are included and which
> > elements are omitted or represented as opaque."
> > 
> > I think that is generally agreed, but understanding that an 
> abstract 
> > definition my just be a view of real process is important.
> > 
> > Peter
> > 
> > 
> >>-----Original Message-----
> >>From: rkhalaf [mailto:rkhalaf@watson.ibm.com]
> >>Sent: 08 October 2004 15:38
> >>To: wsbpel@lists.oasis-open.org
> >>Subject: [wsbpel] Issue - 82 - Proposal for Vote
> >>
> >>
> >>In this proposal, we clarify abstract processes as 
> requested by Issue
> >>82. The spec should reflect these clarifications to abstract 
> >>processes 
> >>throughout its text.
> >>
> >>--------
> >>
> >>A BPEL abstract process defines the publicly visible behavior of the
> >>services it offers (all "myRole" in its partnerLinks), of course 
> >>including its interactions along its partnerLinks with other 
> >>services. 
> >>Abstract processes serve a descriptive role. They can be viewed as 
> >>partially specified processes that are typically not intended to be 
> >>executed. They are partially specified in that they are capable of 
> >>abstracting away operational details. An abstract BPEL 
> >>process must be 
> >>declared abstract by setting the abstractProcess attribute 
> to "yes". 
> >>Operational details may be abstracted away either through the 
> >>omission 
> >>of specific BPEL elements or attributes listed in the 
> >>specification, or 
> >>through the use of opaque tokens. Aside from these factors, 
> they are 
> >>well-formed process following the structure and restrictions in the 
> >>specification regarding the process definition and the 
> >>constructs used.
> >>
> >>Semantics of Abstract Processes:
> >>
> >>A.	 Although it might contain complete information that 
> >>would render it
> >>executable if the abstractProcess="yes" attribute were 
> >>changed to "no" 
> >>for executable BPEL, its abstract status states that any concrete 
> >>realizations of it may perform additional processing steps 
> >>that are not 
> >>relevant to the audience to which it has been given.
> >>
> >>B.	Abstract processes permit the use of nearly all of the 
> >>constructs of
> >>executable processes.  Thus there is no fundamental 
> expressive power 
> >>distinction between abstract and executable processes.
> >>
> >>C.	An abstract process may omit certain details that are 
> >>mandatory for
> >>BPEL executable processes. However, the semantics of the 
> >>constructs used 
> >>in such a process is exactly the same as their semantics in the 
> >>executable context. An abstract process must comply with the 
> >>syntax and 
> >>semantics of the specification.  The syntactic elements that can be 
> >>omitted in abstract processes where this would not be permitted in 
> >>executable processes are currently:
> >>-	Those listed in the "extensions for executable 
> >>processes" section of 
> >>the specification.
> >>-	inputVariable/outputVariable/variable on invoke, 
> >>receive, onMessage, 
> >>and reply.
> >>-	An initiating receive activity (pending resolution of issue 99).
> >>
> >>D.	Abstract processes may include special syntactic 
> >>extensions ("opaque"
> >>entities of various kinds) that should be replaced with concrete 
> >>entities  in any executable artifact that complies with an abstract 
> >>process using such opaque entities. Which opaque entities are 
> >>permitted 
> >>is the scope of issue 107.
> >>
> >>E. Abstract processes say nothing about *how* concrete, executable
> >>realizations of them should be implemented (ie: language, 
> >>platform, etc) 
> >>. (analogy to WSDL).
> >>
> >>F. Multiple abstract processes together may be created to define a
> >>global view of a multi-party business protocol. However, the way in 
> >>which they may be wired together (connecting partnerLinks a la WSFL 
> >>global models) is out of scope of BPEL itself.
> >>
> >>
> >>To unsubscribe from this mailing list (and be removed from
> >>the roster of the OASIS TC), go to 
> >>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> >>ave_workgroup.php.
> >>
> >>
> > 
> > 
> > 
> > Choreology Anti virus scan completed
> 
> 
> 


Choreology Anti virus scan completed