[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 82 - Proposal to resolve 82 and other abstract process issues
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]