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

[Assaf Arkin <arkin@intalio.com>]

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.

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. But since we already decided to preclude it, 
the use case becomes irrelevant.

Assaf

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>
>
>
>

begin:vcard
fn:Assaf Arkin
n:Arkin;Assaf
org:Intalio
adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065
email;internet:arkin@intalio.com
title:Chief Architect
tel;work:(650) 596-1800
x-mozilla-html:TRUE
url:http://www.intalio.com
version:2.1
end:vcard

S/MIME Cryptographic Signature