That was not my understanding.
We had agreement that mandatory extensions was intended to be the primary usage case for the <opaque> activity/expression proposal, as I wrote below. We need to discuss whether that is something which we should support based on the range of usage scenarios in which it is relevant. I argued below that the usage scenarios are narrow.
Do you agree with my characterization of the usage scenarios?
Satish
-----Original Message-----
From: Martin Chapman [mailto:]
Sent: Tuesday, July 20, 2004 12:46 PM
To: Satish Thatte;
Subject: RE: [wsbpel-abstract] Potential requirements and use case
Satish,
I thought on Friday we had tentative agreement that opaque should be
part of (abstract)
BPEL to identify mandatory extension points, but its use is optional.
Martin.
>-----Original Message-----
>From: Satish Thatte [mailto:]
>Sent: 16 July 2004 17:48
>To:
>Subject: RE: [wsbpel-abstract] Potential requirements and use case
>
>
>I think we are agreeing on a few things
>
>1. abstract BPEL allows partial specification of executable processes.
>
>2. we need a precise definition of conformance between a
>partial process and any executable process that claims to be
>its completion
>
>3. We do not want to preclude any use case for abstract
>processes, including
>
>a. A notation for specifying the externally visible behavior
>of a web service or a collection of web services where the
>notation may be used with various degrees of austerity as
>appropriate for the needs of the specifier,
>
>b. A notation for exchange of process requirements across
>autonomous entities where the abstract and the executable
>process are NOT "owned" by the same entity, and
>
>c. A notation for partial specification in a modeling context
>where the abstract and the executable process ARE "owned" by
>the same entity.
>
>4. <opaque> activities and expressions are primarily intended
>as a proposal for allowing the designer of an abstract process
>to express his/her intentions regarding mandatory points of
>extension. The purpose of <opaque> is NOT to specify all
>allowable points of extension, prohibiting all other potential
>points of extension in the completion of an abstract process.
>Secondarily, <opaque> activities and expressions serve as a
>convenience for technical specification and validation using a
>single schema.
>
>I would argue that the technical convenience argument for
><opaque> is a weak one because the syntactically mandated
>completion points can be easily found by tools and forcing an
>abstract process designer to explicitly design them in helps
>tools and BPEL specification writers at the expense of the
>users of abstract BPEL, i.e., those who read and write
>instances of abstract BPEL. This is especially the case for
>use case (a) above where brevity and readability are likely to
>be very important.
>
>I believe the primary intention of the <opaque> proposal as a
>mechanism for expressing the intention for mandatory extension
>applies primarily to use case (c) and as such I would argue
>that it belongs more in the realm of a tools oriented
>extension rather than an essential aspect of abstract BPEL.
>
>Satish
>
>
>________________________________________
>From: Satish Thatte
>Sent: Thursday, July 15, 2004 10:20 PM
>To:
>Subject: RE: [wsbpel-abstract] Potential requirements and use case
>
>I would add that in real scenarios external views are often
>linked with modeling requirements. A large company may
>specify a "required external view" in the form of an abstract
>process for its partners' processes without dictating how such
>a process is completed by the partners. The partners may need
>to take their required external view and use it as input into
>a modeling environment for completion and implementation in
>their own environments. However, it is extremely unlilely
>that the large company will dictate exactly how the process is
>to be completed by specifying the exact places where it must
>be extended. Each partner may of course complete and
>implement the process differently, so long as all maintain the
>externally visible contract specified by the abstract process.
>
>We would therefore be better off specifying the base techical
>notion of abstract processes as partial processes and we
>should avoid attempts to narrow the space of use cases artificially.
>
>Satish
>
>________________________________________
>From: Satish Thatte [mailto:]
>Sent: Thu 7/15/2004 9:41 PM
>To: Ashwini Surpur;
>Subject: RE: [wsbpel-abstract] Potential requirements and use
>case Aren't you confusing a use case with a set of
>"requirements" marked with "MUST"?
>
>I am not opposed to the use of abstract BPEL for supporting
>modeling tools, if it suits.
>
>I am opposed to structuring abstract BPEL in such a way that
>it is ONLY or PRIMARILY focused on supporting modeling tools.
>
>There are several reasons for this.
>
>1. This is inconsistent with the current spec which expresses
>the intentions of the original authors rather clearly, as well
>as the charter. All of these emphasize the public view aspect
>of abstract BPEL and it is not at all clear that the use of
>OPAQUE is suitable for that.
>
>2. The *technical* motivation for this push away from the
>original intentions is not clear -- it would be helpful to
>have that explained.
>
>3. At a technical level, we recognize that abstract processes
>are partially specified executable processes. One can provide
>an external view as a partially specified process by
>eliminating all unnecessary detail. One can also use the very
>same partial specification as the basis for representing
>intermediate states in a modeling exercise.
>
>In both cases you need a notion of faithful completion. I do
>not buy that faithful completion is a purely syntactic matter
>of specifying OPAQUE syntactic elements. This may be adequate
>for some narrow use cases but is clearly suboptimal for the
>technology as a whole.
>
>It is not, and has never been our charter to specifically
>address the requirements of (visual or other) tools for
>process modeling. I simply see no reason to bring that in as
>the canonical use case.
>
>It is time we moved beyond this. Let us use the call tomorrow
>to do so.
>
>Satish
>
>
>
>________________________________
>
>From: Ashwini Surpur [mailto:]
>Sent: Thu 7/15/2004 4:49 PM
>To:
>Subject: [wsbpel-abstract] Potential requirements and use case
>
>
>
>Hi,
>
>Here is a use case and some requirements that we feel should
>be satisfied. If needed, we can discuss this at tomorrow's conf call.
>
>Thanks,
>Ashwini
>
>
>
>
