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: [wsbpel] Issue 82 - some slides

some slides for 82

Assaf Arkin wrote:
> We see a clear need for abstract process definitions as per the original 
> spec (AP 1.1), and are concerned that the proposals to overload abstract 
> process definitions would interfere with their utility.
> 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 would imagine that such a template document would be extended 
> syntactically, that any syntactical extension will be allowed (see 
> Peter's definition). On the other hand, the semantics of abstract 
> processes (AP 1.1) is such that not all syntactic extensions are allowed 
> (see Satish's definition). 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.
> 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. Overloading is 
> not necessarily simplifying.
> I would like to propose that in allowing different profiles, we do not 
> overload existing BPEL semantics. Let abstracts be AP 1.1, let profiles 
> use their own set of semantics. For example, a profile for a template 
> could introduce the /template /attribute. The attribute will serve as a 
> marker for a BPEL processor that must understand the attribute, and can 
> use its value to understand the semantics associated with the document. 
> Further, it can be used in combination with the /abstract /attribute to 
> distinguish between templates for abstracts and templates for executables.
> Assaf
> 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. 


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