[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 82 - Proposal for Vote
Since most of these defintions are not really normative, isnt this is mostly material for a primer? Martin. >-----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/lea ve_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]