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

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

Satish,

You are correct that one shouldn't bake in any specific methodology into
a langauge.
That is exactly why we propose not to!

Martin.

>-----Original Message-----
>From: Satish Thatte [mailto:satisht@microsoft.com] 
>Sent: 16 July 2004 06:20
>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
>
>
>
>
>
>
>