[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
I persoanlly see nothing wrong with Peter's defintions, and seems to
suit all the use cases discussed in the past.
I also see no reason to create a tower of babel of abstract bpel
dialects.
Martin.
>-----Original Message-----
>From: rkhalaf [mailto:rkhalaf@watson.ibm.com]
>Sent: 02 December 2004 17:32
>To: Danny van der Rijn
>Cc: Furniss, Peter; wsbpel@lists.oasis-open.org
>Subject: Re: [wsbpel] Issue 82 - Proposal to resolve 82 and
>other abstract process 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/lea
ve_wor
>> kgroup.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_workgr
oup.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_workgr
oup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]