When did Peter ask for "at least one opaque marker"? I must have missed
it ..
Satish
-----Original Message-----
From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Monday, October 11, 2004 4:38 PM
To: ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 82 - Proposal for Vote
We're back to my objection of describing abstract processes in terms of
conformance. You may not have intended to go there Yaron, and I
apologize in advance if this is the case.
My understanding of the current set of proposals, is that the query
string would not affect conformance proofs at all, and therefore DOES
NOT BELONG in abstract processes. What you described would therefore be
termed an incompletely specified process, and one which does not meet
the definition of abstract process.
My preference, which I have (perhaps ineptly) stated in various ways,
coincides more with Peter's proposition that an abstract process is one
with at least one "opaque" marker, for whatever value of opaque marker
we decide upon. Note that this has nothing to do with observable
conformance, just with degree of specificity.
I would also argue that an abstract process is defined by intent, and
not by syntax, e.g. an abstract process is one that is marked
abstract=true.
I hesitate to go through my complete (but inept) arguments again, but
since it's been a while...
It makes more sense to me that there will be multiple conflicting
definitions of abstract process: the observable conformance flavor, the
proper superset which you describe, others. If we are going to preserve
a notion of an abstract process that has any meaning to a large number
of the audience of our specification, one way to do it would be to mark
the process with a string (perhaps a URI) that selects some
syntax/semantics/intentions of abstractness. I worry that standardizing
that portion of "abstractness" that aids only in defining observable
conformance will increase the size and complexity of the BPEL spec
without giving benefit to a large portion of the community. Therefore
I, for one, can not support the current proposals. I would prefer the
absence of abstract processes to the current situation.
One counter-argument is that while the use-case you provide is
ill-specified, the observable conformance use case can be nailed down
precisely. Using this as an argument for actually doing so, however,
and ignoring everything else, is specious.
Yaron Y. Goland wrote:
I like the general direction the text is going in but there is one
particular issue that still worries me - why are abstract processes
not a proper superset in functionality of executable processes?
Imagine a company is using an abstract process as a template. Part of
the template is fully defined to provide a complete description of a
particular operation but the rest of the process is defined with less
detail. For the detailed section it is necessary to use a query string
on a from to indicate exactly which part of a source variable should
be assigned to a destination.
Currently the previous use case is impossible in BPEL because query
strings on from-specs are reserved for executable processes. Therefore
abstract processes do not have the same expressive power as executable
processes.
For issue 82 to be resolved it is necessary for abstract processes to
be well enough defined that it becomes obvious why limitations such as
the query string restriction are necessary to meet the goals of
abstract processes. Yet no such description is provided below. Could
you please clarify this issue?
Thanks,
Yaron
rkhalaf wrote:
In this proposal, we clarify abstract processes as requested by Issue
82. The spec should reflect these clarifications to abstract
processes throughout its text.
--------
A BPEL abstract process defines the publicly visible behavior of the
services it offers (all "myRole" in its partnerLinks), of course
including its interactions along its partnerLinks with other
services.
Abstract processes serve a descriptive role. They can be viewed as
partially specified processes that are typically not intended to be
executed. They are partially specified in that they are capable of
abstracting away operational details. An abstract BPEL process must
be declared abstract by setting the abstractProcess attribute to
"yes".
Operational details may be abstracted away either through the
omission of specific BPEL elements or attributes listed in the
specification, or through the use of opaque tokens. Aside from these
factors, they are well-formed process following the structure and
restrictions in the specification regarding the process definition
and the constructs used.
Semantics of Abstract Processes:
A. Although it might contain complete information that would
render it
executable if the abstractProcess="yes" attribute were changed to
"no"
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.
B. Abstract processes permit the use of nearly all of the
constructs of
executable processes. Thus there is no fundamental expressive power
distinction between abstract and executable processes.
C. An abstract process may omit certain details that are
mandatory for
BPEL executable processes. However, the semantics of the constructs
used in such a process is exactly the same as their semantics in the
executable context. An abstract process must comply with the syntax
and semantics of the specification. The syntactic elements that can
be omitted in abstract processes where this would not be permitted in
executable processes are currently:
- Those listed in the "extensions for executable processes"
section of
the specification.
- inputVariable/outputVariable/variable on invoke, receive,
onMessage,
and reply.
- An initiating receive activity (pending resolution of issue
99).
D. Abstract processes may include special syntactic extensions
("opaque"
entities of various kinds) that should be replaced with concrete
entities in any executable artifact that complies with an abstract
process using such opaque entities. Which opaque entities are
permitted is the scope of issue 107.
E. Abstract processes say nothing about *how* concrete, executable
realizations of them should be implemented (ie: language, platform,
etc) . (analogy to WSDL).
F. Multiple abstract processes together may be created to define a
global view of a multi-party business protocol. However, the way in
which they may be wired together (connecting partnerLinks a la WSFL
global models) is out of scope of BPEL itself.
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.
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.