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