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

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

Hi Danny,

I get your arguments, but I'm not clear on what you have in mind. I know 
"why" but I'm not exactly clear on "what"..

Do i understand correctly that the thing you are arguing for is strict 
supersetting of syntax + opaque markers (for several reasons below)?

Or are you just pointing out that we should watch for not constraining 
our decisions only to the observable conformance use case ?

clarification would help.. sorry to make you repeat yourself yet again..

thanks,
Rania

Danny van der Rijn wrote:
> We're back to my objection of describing abstract processes in terms of 
> conformance.  You may not have intended to go there Yaron, and I 
> apologize in advance if this is the case.
> My understanding of the current set of proposals, is that the query 
> string would not affect conformance proofs at all, and therefore DOES 
> NOT BELONG in abstract processes.  What you described would therefore be 
> termed an incompletely specified process, and one which does not meet 
> the definition of abstract process.
> 
> My preference, which I have (perhaps ineptly) stated in various ways, 
> coincides more with Peter's proposition that an abstract process is one 
> with at least one "opaque" marker, for whatever value of opaque marker 
> we decide upon.  Note that this has nothing to do with observable 
> conformance, just with degree of specificity.
> I would also argue that an abstract process is defined by intent, and 
> not by syntax, e.g. an abstract process is one that is marked 
> abstract=true.
> 
> I hesitate to go through my complete (but inept) arguments again, but 
> since it's been a while...
> 
> It makes more sense to me that there will be multiple conflicting 
> definitions of abstract process:  the observable conformance flavor, the 
> proper superset which you describe, others.  If we are going to preserve 
> a notion of an abstract process that has any meaning to a large number 
> of the audience of our specification, one way to do it would be to mark 
> the process with a string (perhaps a URI) that selects some 
> syntax/semantics/intentions of abstractness.  I worry that standardizing 
> that portion of "abstractness" that aids only in defining observable 
> conformance will increase the size and complexity of the BPEL spec 
> without giving benefit to a large portion of the community.  Therefore 
> I, for one, can not support the current proposals.  I would prefer the 
> absence of abstract processes to the current situation.
> 
> One counter-argument is that while the use-case you provide is 
> ill-specified, the observable conformance use case can be nailed down 
> precisely.  Using this as an argument for actually doing so, however, 
> and ignoring everything else, is specious.
> 
> Yaron Y. Goland wrote:
> 
>> I like the general direction the text is going in but there is one 
>> particular issue that still worries me - why are abstract processes 
>> not a proper superset in functionality of executable processes?
>>
>> Imagine a company is using an abstract process as a template. Part of 
>> the template is fully defined to provide a complete description of a 
>> particular operation but the rest of the process is defined with less 
>> detail. For the detailed section it is necessary to use a query string 
>> on a from to indicate exactly which part of a source variable should 
>> be assigned to a destination.
>>
>> Currently the previous use case is impossible in BPEL because query 
>> strings on from-specs are reserved for executable processes. Therefore 
>> abstract processes do not have the same expressive power as executable 
>> processes.
>>
>> For issue 82 to be resolved it is necessary for abstract processes to 
>> be well enough defined that it becomes obvious why limitations such as 
>> the query string restriction are necessary to meet the goals of 
>> abstract processes. Yet no such description is provided below. Could 
>> you please clarify this issue?
>>
>>     Thanks,
>>
>>         Yaron
>>
>> rkhalaf wrote:
>>
>>>
>>>
>>> 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/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. 
>>
>>
>>
> 
> 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. 
>