OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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 wanted to add a few comments to what Peter and Rania have said.  A
think their proposals are going in the right direction and are the right
basis for providing a notion of abstract processes that is actually
useful.  Here is how I understand the underlying logic of these

1.	We are not going to invent any new constructs with new semantics
for abstract processes.  The only constructs that have defined meaning
are the constructs of executable processes, and that meaning is defined
by the prescribed behavior of the executable process as a whole, and is
thus not directly available outside an executable process.

2.	Abstract processes exist to address situations where a complete
executable process cannot be provided.  We add a notion of "opaque" to
abstract processes not as a new semantically meaningful construct but as
a syntactic device for indicating incompleteness.  As such, "opaque"
entities have no semantics of their own.

3.	Abstract processes are *incomplete* and non-executable by
definition, whether or not they contain opaque entities.  Therefore the
semantics of the non-opaque constructs they contain cannot be understood
in isolation from the relationship of the abstract process with the
executable *completions* it permits.  The reason being that the
semantics of those constructs actually exists only in the possible
executable completions.  As an edge case, a permitted completion may
sometimes be identical to the abstract process syntactically, but this
is the exception rather than the rule.

The last point is crucial in understanding the importance of the
amendments Rania has proposed.  The biggest technical difficulty we had
in the abstract process working group was that we could not agree on a
common notion of permitted completions.  And in retrospect this is not
surprising because the correct notion depends on the use case involved.
As a corollary, it is perfectly possible that a certain abstract process
use case may require syntactic constraints on the usage of executable
constructs in defining that type of abstract process.  Let me illustrate
with a few examples.  

In point 3 above I have in a sense contradicted Peter's last point
(point [5]) on the semantics of abstract processes.  I will come back to
this point again at the end of this note to clarify how we can restore
the spirit of Peter's point.  The reason to start with a narrow
interpretation is precisely that without it as the *basis*, it is not
possible to attach semantics to the constructs used in abstract
processes at all, as I pointed out in point 3 above.  Further, I will
define the completions syntactically:  a completion is allowed to
replace opaque entities with concrete ones and it is permitted to add
entirely new activities and their required collateral (such as variables
and partnerLinks) wherever syntactically possible.  I believe a formal
version of this notion of syntactic completion should be added to
Peter's set of base definitions because it is crucial in defining the
semantics of all use cases.

Now for the examples.  Among other things, the examples illustrate how
straightforward the notion of a usage profile for abstract processes can

If an abstract process is meant to fully represent the externally
observable behavior of a complete executable process along a set of
partnerLinks, then the permitted executable completions of this abstract
process cannot allow the addition of web services interactions using the
partnerLinks mentioned in the abstract process, even as replacements for
opaque activities.  This excludes a subset of syntactic completions from
the set permitted in this use case.  Further, if we narrow the use case
to the externally observable behavior along a single partnerLink, in
effect the behavior of a party in the conversation represented by the
partnerLink, then one would syntactically restrict the abstract process
to contain exactly one globally declared partnerLink.  This excludes
certain syntactically possible abstract processes from the set of
meaningful abstract processes for this use case.

Now take the template use case.  The simplest interpretation permits all
syntactic completions.  But a stricter interpretation may permit only
the replacement of opaque entities and forbid the addition of entirely
new activities.  The latter is a case where the points of incompleteness
are completely specified by using opaque entities.

What these examples show is that the specification of constraints on
completion, and in some cases constraints on the syntactic form of
abstract processes, are essential in providing meaning to the use of
abstract processes in specific usage contexts.  The reason to provide a
notion of usage profiles is that we do not want to be narrow minded and
anoint a single use case as the canonical one.  But conversely, not
providing the means to specify which use case is intended would be very
damaging in that it would make the interpretation of the intended
meaning of an abstract process impossible.

Now to come back to Peter's point [5].  This is an important notion in
that syntactic completions are often too narrow a constraint on
practical implementation.  They are definitional but we can loosen
permitted practice *so long as there is no observable difference in
behavior*.  But note that this distinction is especially important for
the observable behavior use case rather than the template one.


-----Original Message-----
From: rkhalaf [mailto:rkhalaf@watson.ibm.com] 
Sent: Thursday, December 02, 2004 2:00 PM
To: Martin Chapman
Cc: 'Danny van der Rijn'; 'Furniss, Peter'; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue 82 - Proposal to resolve 82 and other
abstract process issues


I'd just like to illustrate what I meant when I said about the 
non-clarity of arbitrary opacity and the semantics being those of 
exec-bpel which leads into why Peter+Dialects=goodStuff. Imagine the 
following in light of this statement:

- a link source/target with an opaque name. Does this sub for the other 
end of *any* link that has a name and no "other half"? what if there are

multiple? - a fault handler with an opaque fault name? - a compensate 
with scope="opaque" - two replies and one receive and all partnerlinks 
opaque. Is this okay? I can't tell. -and many more..

On the other hand, one could say absolutely no semantics and just schema

verification. Then all hell breaks loose :) In addition to the mess 
above which would still be createable, links crossing while loops 
suddenly become okay. Links with sources and no targets are also in. 
Compensating a scope by name that doesn't exist,sequence of reply then 
receive, etc.

For anyone to use this in any way, choices have to be made - either 
explicitly and cleanly somewhere (ex: by definers of dialects that could

possibly be standardized) or by users who will try to guess their way 
around in the dark.

The arguments have been that these choices are use case dependent; 
hence, base+dialects is a natural solution of the two extremes that have

been discussed for 82 (strict and limiting (my old proposal) VS. 
flexibile and vague).

Martin Chapman wrote:
> 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
>>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 
>>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.
>>Danny van der Rijn wrote:
>>>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)
>>>>-----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  
>>>>>    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  
>>>>>    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 
>>>>>     [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
> ve_wor
>>>Choreology Anti virus scan completed
>>To unsubscribe from this mailing list (and be removed from the roster 
>>the OASIS TC), go to 
> oup.php. 
> To unsubscribe from this mailing list (and be removed from the roster
> the OASIS TC), go to
> oup.php.
> To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to

To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]