OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [Fwd: Re: [wsbpel] Issue 82 - Adding requesting clarifications(withOUT change log)]

Hi Yaron,

Yaron Y. Goland wrote:
> Then sentence "The semantics of an
> abstract process are therefore derived from those of the executable
> processes to which it would be mapped." confused me as it would imply 
> that all abstract processes MUST be mapped to an executable process. But 
> I was unaware of us ever wishing to imply that? Is the only possible use 
> of an abstract process to create an executable process? I would draw a 
> distinction with point 4 at the end of the proposal which just says that 
> it must be possible to create an executable process through some fairly 
> undefined mechanism. But that is different than implying that the end 
> goal always is an executable process.

How about :
"The semantics of an abstract process are therefore derived from the
range of executable BPEL processes that a particular abstract process

This removes the directionality while maintaining the concept.

> "One or two profile(s) will be given in the specification. " - Which is it?

Whether it will be one or two profiles was intentionally left open as
part of 82. We propose that a new issue be created to handle it.

> "[The TC will rework the 1.1 AP definition into a profile with a
> defined URI." - This sentence seems incomplete


> The proposal itself is still not in a form that is readily include-able 
> in the spec. 

see note at the end

 >The list of features of abstract processes is both
> incomplete (for example point 3 refers to opaque values without defining 
> how they work, do you intend to resolve the dependent issue first?) and 
> not in spec form.

The answer to this will come out of issue 107

> I would expect that the final proposal would be in a form that is either 
> ready to be included in the spec or reasonably close. That is the only 
> way we can make sure that all the edge cases have been properly dealt 
> with. Otherwise the editors will end up having to find those edge cases 
> themselves and then file new issues. But it is not the job of the 
> editing team to debug proposals.
> Nevertheless I am happy with the over all design and direction of the 
> proposal. My comments are therefore restricted to encouraging that the 
> proposal be completed so we can vote on it.

Looking into draft of spec to see where changes would occur, while 
making no assumptions about dependent specs other than putting 


>     Thanks,
>         Yaron
> Rania Khalaf wrote:
>> Hi,
>> here is the text with proposed updates incorporated and no
>> highlighting of changes.
>> -----------
>> Proposal for Issue 82:
>> NOTE: Ambiguities should be limited/focus on non-substantive changes
>> to the accepted concept, i.e. editorial comment, further clarification
>> that do not change the substance of the accepted proposal from Peter
>> dated 12/15/2004.
>> Abstract BPEL definition:
>>   A BPEL abstract process is a partially specified process that is not
>> intended to be executed. Executable and abstract BPEL processes share
>> the same expressive power, while the latter allows process definitions
>> that are capable of abstracting away operational details _ either
>> through omission or explicit opacity.  Whereas executable processes
>> are fully concretized and thus can be executed, an abstract process
>> may lack some of the required concrete operational details expressed
>> by a fully executable artifact. An abstract BPEL process must be
>> explicitly declared as 'abstract'.
>> Abstract processes serve a descriptive role, with more than one
>> possible purpose. One such purpose for an abstract process could be to
>> define the publicly visible behavior of some or all of the services it
>> offers ("myRole" in its partnerLinks), which may include its
>> interactions along its partnerLinks with other services.  Another
>> purpose could be to define a process "template" embodying
>> domain-specific best practices, encoded in a platform-neutral and
>> portable way by both enterprises and vertical standards organizations.
>> For example, a process "template" could capture some essential process
>> logic while leaving out operational details that will be concretized
>> when mapping the partial process specification to a fully executable
>> artifact.
>> The different uses of abstract BPEL require different levels of
>> opacity and restrictions or relaxations on which elements of a
>> corresponding executable artifact are omitted or hidden.  To cleanly
>> enable different usages of abstract processes, an extensible approach
>> is taken using a set of basic, minimal requirements (base) for all
>> abstract processes.
>> The abstract process base definition lacks well-defined
>> semantics. Conversely, executable processes have well-defined
>> semantics and prescribed behavior. From the abstract process base
>> definition, "usage profiles" can be defined. The semantics of an
>> abstract process are therefore derived from those of the executable
>> processes to which it would be mapped.
>> To define these semantics, the range of corresponding executable
>> processes can be constrained by a usage profile, placing constraints
>> on what is opaque or omitted.  An abstract process MUST identify the
>> usage profile that defines its meaning.  The profile is identified
>> using a URI. Where profiles are defined is left unspecified.
>> The base is simply a set of minimum requirements for all abstract
>> processes. Profiles are created from the base. One or two profile(s)
>> will be given in the specification. They/it will show how one can
>> create a profile by building on the base.
>> [The TC will rework the 1.1 AP definition into a profile with a
>> defined URI.
>> It is left open whether another profile will be defined in the
>> specification that is identical to the base. If so, it will be given a
>> URI to identify it and added. It is suggested that a separate, new
>> issue XX be opened for this. The dependency (by allowed closing order)
>> of these three issues is: 82, XX, 158.
>> The placement of these profiles and other questions concerning the
>> structure of the ultimate specification and how many documents there
>> will be will be left open and dealt with as part of 158] . Issue 158
>> cannot be closed until 82 is closed.
>>        Semantics of Abstract Processes:
>>       [1] Although it might contain complete information that would
>> render it executable as specified 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. The minimum criteria for an abstract process
>> is defined in this specification while completeness is left to the
>> usage profile a particular abstract process definition belongs to.
>>       [2] Abstract processes permit the use of all of the constructs of
>> executable processes. Thus there is no fundamental expressive power
>> distinction between abstract and executable processes.
>>       [3] An abstract process may omit operational details that are
>> mandatory for BPEL executable processes through the use of "opaque"
>> entities of various types (i.e. elements, attributes, etc.) or through
>> the omission of specific BPEL elements or attributes that are allowed
>> to be implicitly opaque. This omission is treated as a syntactic
>> shortcut equivalent to the attribute or expression being in the
>> omitted location with an opaque value.
>>       The semantics and consistency constraints of executable BPEL are
>> clearly defined. The semantics of each language construct in an
>> abstract process are always derived from that of the same construct in
>> executable BPEL. (i.e. an invoke is always an invoke).
>>       The difference is strictly a consequence of the opacity used in
>> that construct (missing information) and other parts of the process
>> affected by it ( For example, opacity in a link source element may
>> affect the link target element).
>>       Additionally, an abstract process is required to be syntactically
>> valid using the BPEL schema, that accommodates extension with opacity
>> and omissions as detailed in bullet 3 above. One schema exists for
>> abstract and executable BPEL. (Check that this is consistent with
>> resolution of 24).
>>       [4] In this base definition, to avoid absurd constructs and to
>> clarify opacity, the minimial requirement is that for any abstract
>> process, there exists at least one syntactic completion that yields a
>> *valid executable process* by
>>           a) replacing each opaque token by a concrete entity or
>> removing the opaque token completely, and
>>           b) adding new BPEL XML elements anywhere in the process.
>> This is used for checking the syntactic validity of an abstract
>> process not for process semantics.
>>       [5] For this base definition, there are no requirements on how
>> concretized, executable realizations of abstract process should be
>> implemented (ie: language, platform, etc) (c.f. analogy to WSDL); nor
>> are specific relationships with such realizations specified.
>>       [6] Abstract processes are *incomplete* and non-executable by
>> definition, whether or not they contain opaque entities. Therefore the
>> semantics of the non-opaque constructs they contain cannot be
>> understood in isolation from the relationship of the abstract process
>> with the executable *completions* that are permitted by the profile
>> the abstract process references.
>>       The reason being that the semantics of those constructs actually
>> exists only in the possible executable completions. As an edge case, a
>> permitted completion may sometimes be identical to the abstract
>> process syntactically, but this is the exception rather than the rule.
>>       __
>> 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/leave_workgroup.php. 
> 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/leave_workgroup.php. 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]