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

[rkhalaf <rkhalaf@watson.ibm.com>]

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