Re: [wsbpel] Issue 82 - Proposal to resolve 82 and other abstract process issues

[Charlton Barreto <charlton_b@mac.com>]

This is true in a sense, but my concern is that we as such are forced  
to deal with absBPEL having more variation - and thus more complexity -  
than is needed.

Overloading in this case definitely simplifies the scenario -  
overloading abstracts to support both cases would not necessarily lead  
to unwanted restrictions

On 14/12/2004, at 08:11, Assaf Arkin wrote:

> I can imagine that during the lifecycle of a process definition, one  
> would want to exchange "incomplete" process definitions that do not  
> fully conform to BPEL semantics (executable or abstract). At the  
> moment the only technical requirement we have is satisfied by what XML  
> defined as "well-formed XML". But assume that we reach a point where  
> we want more specific restrictions and semantics, beyond  
> "readable/writeable XML document using BPEL elements". For example,  
> creating a "template" document type with specific semantics that could  
> eventually be developed into an executable or abstract.

I see this as feasible via use of templates at a high-level w.r.t.  
abstract. From Peter's proposal, I do not see where this would impeded.

> We are concerned that overloading abstracts to support both cases  
> would lead to confusion, unwanted restrictions on future extensions,  
> and difficulty in understanding AP 1.1.

How would this be the case? I agree that it requires deeper  
understanding w.r.t. absBPEL, but overloading places fewer restrictions  
on future extensions than would adding profiles/dialects.

> Further, it will be impossible to define a template for an abstract,  
> if such a template is called an abstract, as is the resulting  
> abstract, as is any template used to generate a process definition.

If a template is written to either overloaded definition, this would be  
the case. However, is this necessary? What would be the use case for  
such a template? I'm not convinced that such a template is needed. With  
respect to absBPEL, I see the use case as only warranting a looser  
template definition. I feel this fits in nicely with the abstract level  
that Peter's proposal aims to maintain.

-Charlton.

> Charlton Barreto wrote:
>
>> Satish,
>>
>> I believe the distinctions are orthogonal to one another, and that we  
>>  are looking at "wide" vs. "deep" vis-a-vis what can be accomplished   
>> completely per the level (high and abstract vs. low and detailed). By  
>>  going "wide" and approaching the issue at a high enough level, as  
>> per  Peter's proposal, we can provide a complete-enough abstract  
>> definition.  Some tweaking of the definition for everyone's comfort  
>> level may be  needed, but I feel that profiles takes us away from  
>> "wide" and abstract  and introduces much complexity, which I feel to  
>> be more than necessary.  I also feel that going too "deep" in the  
>> interpretation framework, and  not sticking to the abstract level of  
>> Peter's proposal, will  reintroduce the sort of issues that the SC  
>> wrestled with earlier this  year. I agree with your point #1 (from   
>> http://lists.oasis-open.org/archives/wsbpel/200412/msg00023.html),  
>> but  I feel that otherwise Peter's definition is generally complete  
>> to  address absBPEL at the "wide", abstract level. I'm for avoiding   
>> profiles altogether, and sticking to an abstract level for the   
>> definition - if not Peter's proposal, then Peter's proposal as a base  
>>  with some tweaking,
>>
>> -Charlton.
>>
>> On 12/12/2004, at 21:50, Satish Thatte wrote:
>>
>>> Charlton,
>>>
>>> I believe the distinction is not so much between wide and narrow as   
>>> between a completely vs incompletely defined notion of abstract   
>>> process, either singular, as you seem to prefer, or plural.  The   
>>> notion in BPEL4WS 1.1 is singular and Peter's proposal does not   
>>> actually capture it.  I showed what needs to be added to Peter's   
>>> proposal to make it correspond to AP1.1.  The only reason to  
>>> introduce  profiles is to allow new interpretations such as  
>>> templates that are  not present in the spec today.  The TC should  
>>> decide if we want  singular or plural interpretation of abstract  
>>> processes.  But we do  need an interpretation framework that is  
>>> actually specified to the  point where the semantic interpretation  
>>> is unambiguous.  For that  Peter's proposal needs some additions, as  
>>> I explained in my mail   
>>> http://lists.oasis-open.org/archives/wsbpel/200412/msg00023.html.
>>>
>>> Peter's proposal is indeed very close to what we need.  I hope we  
>>> will  have an amended proposal that fills the remaining gaps to  
>>> discuss  during the face-to-face meeting.
>>>
>>> Satish
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Charlton Barreto [mailto:charlton_b@mac.com]
>>> Sent: Friday, December 10, 2004 5:11 PM
>>> To: <wsbpel@lists.oasis-open.org> <wsbpel@lists.oasis-open.org>
>>> Cc: Peter Furniss; Danny van der Rijn
>>> Subject: Re: [wsbpel] Issue 82 - Proposal to resolve 82 and other   
>>> abstract process issues
>>>
>>> I agree with Peter's proposal as is and believe this is the better
>>> route to resolving the outstanding absBPEL issues. I feel that it is
>>> preferred to take a "wide", more abstract approach as opposed to a
>>> "deep", more detailed one, especially given the difficult on agreeing
>>> upon the details.
>>>
>>> Likewise, I feel that adding profiles/dialects to absBPEL would only
>>> add complexity, impact interoperability, and take absBPEL "deeper"  
>>> than
>>> needed or is resolvable, and agree with Martin's point on the issue.
>>> I'd prefer to stick to Peter's "wide" approach as it addresses the
>>> issues well enough at a high level.
>>>
>>> On 02/12/2004, at 02:40, Furniss, Peter wrote:
>>>
>>>> It was my original thought that nothing is a valid replacement to
>>>> opaque, though looking at the text, it doesn't read that way.
>>>>    Suggest adding, at the end of [4]:
>>>>  This includes the case where, if otherwise valid, an opaque entity
>>>> is removed without replacement in a corresponding
>>>> executable artifact)
>>>>  ([4] and [5] deliberately avoid the implication that the
>>>> concretization is necessarily executable bpel, so "syntactically"  
>>>> may
>>>> be over-specific)
>>>>  Peter
>>>>    -----Original Message-----
>>>> From: Danny van der Rijn [mailto:dannyv@tibco.com]
>>>>  Sent: 01 December 2004 17:59
>>>> To: wsbpel@lists.oasis-open.org
>>>> Subject: Re: [wsbpel] Issue 82 - Proposal to resolve 82 and other
>>>> abstract process issues
>>>>
>>>>
>>>> i would explicitly add to your proposal that it is allowed that
>>>> "opaque" be removed completely in an executable realization, so long
>>>> as such removal is syntactically valid. in other words, my current
>>>> reading is that while <opaque> -> <empty> is valid, <opaque> ->    
>>>> <!-- removed opaque --> is not.  my opinion is that it should be.  
>>>> same for attributes.
>>>>
>>>> danny
>>>>
>>>> Furniss, Peter wrote:
>>>>  Taking into account previous discussions and definitions,   
>>>> including
>>>> the Abstract BPEL
>>>> sub-group work, the  following definition of Abstract BPEL is  
>>>> proposed
>>>> as the  resolution
>>>> of issue 82, to be included in WS-BPEL v2.0.  This definition would
>>>> supercede the v1.1
>>>> definition.
>>>>   A resolution in principle of issue 107 is also proposed, in line  
>>>> with
>>>> this defintion.
>>>>  The other abstract issues can then be rapidly resolved in line with
>>>> these proposals:
>>>>   91, 97, 99 - abstract processes ARE allowed to omit/hide the  
>>>> features
>>>> mentioned. The
>>>> schema should make the  elements in question optional and, in line
>>>> with 107, allow
>>>>  explicit <opaque> as an alternative.
>>>>   109 - close with no change, mark as revisitable
>>>>   (The existing proposals for some of these issues are already in  
>>>> line
>>>> with this
>>>> proposal.)
>>>>   A corollary of [2] below is that the content of the  "extensions  
>>>> for
>>>> executable
>>>> processes" would become part of  the main body.
>>>>    Proposal for Issue 82:
>>>>  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. Whereas executable processes are  fully concretized and  
>>>> thus
>>>> can be executed, an
>>>> abstract  process lacks some of the required concrete operational  
>>>> details expressed by or
>>>> when mapping it to a fully executable  artifact. An abstract BPEL
>>>> process must be
>>>> explicitly  declared as 'abstract'.
>>>>   Abstract processes serve a descriptive role. A BPEL abstract   
>>>> process
>>>> can 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.  Alternatively, A BPEL abstract process can define a
>>>> process  "template"
>>>> embodying domain-specific best practices, encoded  in a
>>>> platform-neutral and portable way
>>>> by both enterprises  and vertical standards organizations. The  
>>>> process
>>>> "template"
>>>>  captures some essential process logic while leaving out   
>>>> operational
>>>> details that will be
>>>> concretized by the  enterprises and vertical standards organizations
>>>> when mapping  the
>>>> partial process specification to a fully executable artifact.
>>>>
>>>>  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
>>>> undefined.
>>>>   [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 either through the omission of specific BPEL elements or
>>>> attributes listed
>>>>  in the specification, or through the use of "opaque" entities  of
>>>> various types (i.e.
>>>> elements, attributes, etc.).
>>>>   However, the semantics of the constructs used in such a  process  
>>>> are
>>>> exactly the same as
>>>> their semantics in the  executable context. Addionally, an abstract
>>>> process is  required
>>>> to be syntactically valid using the executable  schema extended with
>>>> the opaque entities.
>>>>   [4]  The omitted operational details may be added anywhere,
>>>>  by or when mapping an abstract process to a fully executable  
>>>> artifact. In addition, if
>>>> the points of the omitted  operational details are specified through
>>>> the use of opaque
>>>>  entities, then these placeholders are replaced with other  concrete
>>>> entities in any
>>>> executable artifact that corresponds  to the abstract process using
>>>> such opaque entities.
>>>>   [5]  Abstract processes say nothing about *how* concretized,  
>>>> executable realizations of
>>>> them should be implemented (ie:  language, platform, etc) (analogy  
>>>> to
>>>> WSDL). Nor do they
>>>> imply  a relationship(s) with any such realizations.
>>>>    Proposal for issue 107:
>>>>   Language extensions required for abstract processes
>>>>   The language extensions consist of opaque 'placeholders'
>>>>  whose functions are explained below:
>>>>   [1]  Opaque expressions- Needed in particular for opaque   
>>>> assignment,
>>>> opaque transition
>>>> conditions, opaque query  expression. Opaque assignment is used for
>>>> capturing variable
>>>>  creation/modification in a yet-to-be-concretized mechanism/fashion.
>>>>   [2]  Opaque activities- Hide a concrete BPEL activity, such
>>>>  as a structured activity, a lifecycle activity (ie.
>>>>  receive-start) or even just an "empty". They may also be used  as a
>>>> source or a target of
>>>> control links.
>>>>   [3]  Opaque attributes- Hide a concrete BPEL attribute. For   
>>>> example
>>>> in invoke, receive
>>>> or reply activities opaque  attributes are specifying that variables
>>>> need to be filled in
>>>>  by or when mapping the partial process specification to a fully
>>>> executable artifact.
>>>>
>>>>   Peter
>>>>  ------------------------------------------
>>>> Peter Furniss
>>>> Chief Scientist, Choreology Ltd
>>>> web: http://www.choreology.com
>>>> email: peter.furniss@choreology.com
>>>> phone: +44 870 739 0066
>>>> mobile: +44 7951 536168
>>>>  Choreology Anti virus scan completed
>>>> 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.
>>>> Choreology Anti virus scan completed
>>>
>>>
>>>
>>> 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.
>>
>>
>
> <arkin.vcf>