|Satish Thatte||Jul 15, 2004 9:35 pm|
|Satish Thatte||Jul 15, 2004 10:14 pm|
|Satish Thatte||Jul 16, 2004 7:48 am|
|Martin Chapman||Jul 16, 2004 8:13 am|
|Ugo Corda||Jul 16, 2004 9:32 am|
|Satish Thatte||Jul 16, 2004 9:42 am|
|Martin Chapman||Jul 20, 2004 12:39 pm|
|Satish Thatte||Jul 20, 2004 1:45 pm|
|Monica J. Martin||Jul 22, 2004 3:34 pm|
|Satish Thatte||Jul 22, 2004 10:48 pm|
|Satish Thatte||Jul 23, 2004 10:59 pm|
|Martin Chapman||Jul 26, 2004 6:36 am|
|Alex Yiu||Jul 26, 2004 4:24 pm|
|Monica J. Martin||Aug 11, 2004 5:28 pm|
|Subject:||RE: [wsbpel-abstract] Potential requirements and use case|
|From:||Martin Chapman (mart...@oracle.com)|
|Date:||Jul 26, 2004 6:36:31 am|
then we were at different meetings:-) at least we understood differently.
Im really confused as from the below there appear to me to be contradictions:
We had agreement that mandatory extensions was intended to be the primary usage case for the <opaque> activity/expression proposal, as I wrote below.
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.
the first says mandatory and the second implies optional to me.
-----Original Message----- From: Satish Thatte [mailto:sati...@microsoft.com] Sent: 20 July 2004 21:51 To: Martin Chapman; wsbp...@lists.oasis-open.org Subject: RE: [wsbpel-abstract] Potential requirements and use case
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?
-----Original Message----- From: Martin Chapman [mailto:mart...@oracle.com] Sent: Tuesday, July 20, 2004 12:46 PM To: Satish Thatte; wsbp...@lists.oasis-open.org Subject: RE: [wsbpel-abstract] Potential requirements and use case
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.
-----Original Message----- From: Satish Thatte [mailto:sati...@microsoft.com] Sent: 16 July 2004 17:48 To: wsbp...@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.
________________________________________ From: Satish Thatte Sent: Thursday, July 15, 2004 10:20 PM To: wsbp...@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:sati...@microsoft.com] Sent: Thu 7/15/2004 9:41 PM To: Ashwini Surpur; wsbp...@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.
From: Ashwini Surpur [mailto:Ashw...@oracle.com]
Sent: Thu 7/15/2004 4:49 PM To: wsbp...@lists.oasis-open.org Subject: [wsbpel-abstract] Potential requirements and use case
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.