[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 abstractprocess issues
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]