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

[Charlton Barreto <charlton_b@mac.com>]

At this time, the point is moot as far as I'm concerned. However, I 
still have a few comments....

On 15/12/2004, at 07:10, Assaf Arkin wrote:

> The BPEL 1.1 specification defines a language, which it extends to 
> define executables and abstracts. People in this group indicated they 
> want more sets of restrictions layerd on top of the specification. 
> Let's call them profiles. I would expect us to add more profiles to 
> the two that already exists. Instead, we're going to have two 
> profiles, and create sub-profiles from one of those profiles.

Nice recap of how we more or less ended up with the profiles concept; 
I'm still not entirely convinced whether, given the implied 'semantics' 
of profiles, this concept reflexively applies to absBPEL, given Peter's 
initial proposal. However, given the direction taken on issue 82 with 
Peter's revised proposal, IMO this is moot.

> We can branch into a more detailed discussion about a template 
> profile, look at specific use cases, etc. We can reach the conclusion 
> that it's a good thing, or a bad thing.

Given the direction taken on issue 82 with Peter's revised proposal, I 
feel a discussion on templates/template profiles is in order (at some 
point). I'll continue to delve into this and look forward to others in 
the group adding to the discussion.

> Charlton Barreto wrote:
>
>> 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>
>>
>>
>>
>
> <arkin.vcf>