[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel-abstract] Potential requirements and use case
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. and >>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:satisht@microsoft.com] >Sent: 20 July 2004 21:51 >To: Martin Chapman; wsbpel-abstract@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? > >Satish > >-----Original Message----- >From: Martin Chapman [mailto:martin.chapman@oracle.com] >Sent: Tuesday, July 20, 2004 12:46 PM >To: Satish Thatte; wsbpel-abstract@lists.oasis-open.org >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: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 >> >> >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]