[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
Hi,
I like this proposal as a base for abstract processes and would like to
add a few more points that would make it more workable. The semantics of
the base is taken from the semantics of executable plus "opaque". As you
increase opacity, those semantics become unclear for the general case
(easy example: source/target of link w/ opaque name). From the TC we
saw that for a particular use case or application area one can converge
on what how the semantics of a construct are affected by the opacity and
what possible constraints one could add to exec bpel, but when
discussing all possible use cases this discussion goes haywire.
Instead of arguing about what can and cannot be opaque and the effects
of cutting all of abstract process 1.1 from the spec, we could use
Peter's proposal as a base for abstract BPEL. Using this base people can
create types or dialects that at a minimum state where they
allow/disallow opacity and its effects on semantics (as a delta from
exec bpel). An abstract process would use a URI to denote its
dialect/type. This approach also lets people who have use cases that
have other requirements define their own dialects/types in any forum.
Also, it lets us grandfather the abstract bpel we had in spec 1.1 (w/
minor mods to be in synch with 2.0) by including it in the spec as one
such dialect.
This would give a clean solution that can be done quickly.
Regards,
Rania
Danny van der Rijn wrote:
> agreed.
>
> 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 <http://www.choreology.com/>
>>> email: peter.furniss@choreology.com
>>> <mailto: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.
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]