RE: [wsbpel-abstract] Potential requirements and use case

["Martin Chapman" <martin.chapman@oracle.com>]

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:satisht@microsoft.com] 
>Sent: 16 July 2004 17:48
>To: wsbpel-abstract@lists.oasis-open.org
>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: wsbpel-abstract@lists.oasis-open.org
>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:satisht@microsoft.com]
>Sent: Thu 7/15/2004 9:41 PM
>To: Ashwini Surpur; wsbpel-abstract@lists.oasis-open.org
>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:Ashwini.Surpur@oracle.com]
>Sent: Thu 7/15/2004 4:49 PM
>To: wsbpel-abstract@lists.oasis-open.org
>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
>
>
>
>