[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel-abstract] Potential requirements and use case
Just want to say few brief points: (a) One use case of opaque attribute (not activity in this particular case): Say, we have an activity which has an attribute which is optional and has a default value. If we omit that attribute in abstract BPEL, does it mean the default value? or it means users need to specify that value? Basically, having opaque attribute and opaque activity will minimize both syntactic and semantics differences between abstract and executable BPEL. Easier for end-users to understand. Easier for implementation vendor (both tools and runtime) to understand and follow. (b) If the balanced version of abstract BPEL semantics does NOT require using <opaque> to mark ALL extension points in abstract BPEL, then <opaque> may not be as burdensome or "troublesome" as Satish originally suspected. Users may just need to use <opaque> explicitly in a minority number of cases. (c) To evaluate whether veriations of semantics of abstract BPEL fits our needs, I would suggest to pick / create 3 or more usecases. Then, we try to model them with variations of abstract BPEL semantics and see how the outcome look like. Thanks! Regards, Alex Yiu Satish Thatte wrote: >I see. I have very serious reservations about the use of <opaque> activities. I think they would be misleading to use in most scenarios. I explained my thoughts in the original posting. > >Having said that, I thought the idea of <opaque> was that anything without <opaque> was as ready for execution as anyone could tell. What additional checks would one do? > >________________________________ > >From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] >Sent: Fri 7/23/2004 9:00 AM >To: Satish Thatte >Cc: Monica J. Martin; wsbpel-abstract@lists.oasis-open.org >Subject: Re: [wsbpel-abstract] Potential requirements and use case > > >Satish Thatte wrote: > > > Monica, > > Regarding your suggestion to maintain an explicit abstract/executable > distinction, probably using the current process-level attribute, I agree > with you. > > I don't quite understand what you mean by "statically verifiable set of > conditions to specify when a process model is ready to execute". I > would hope that abstractProcess="no" and the schema for executable > processes plus simple static checks that we already have in the text > which we should gather in a list (issue 84) should be sufficient. Did > you have something else in mind? > > >This comes from a different line of thought that we were kicking around internally. The idea was that abstract processes are simply executable processes that are missing some details needed for execution, or that contain placeholders for concrete activities (opaque activities). A set of statically verifiable conditions could be specified to allow this condition to be checked mechanically. The conditions would include things like "no opaque activity nodes" and "all expressions filled in." This is what Monica alluded to. > >The thought was that this model would allow abstract processes to be more flexible -- the amount of detail in the process could run along a continuum, from minimal to virtually complete, rather than the current model that defines one point along that continuum. > >We thought this approach had some merit. It avoids the "two schema" headache, and is flexible enough to accomodate a wide range of use cases. It does add complexity to any tools that would exploit the static definition of abstract process that we have today. > >Cheers, >-Ron > > > Satish > > -----Original Message----- > From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] > Sent: Thursday, July 22, 2004 3:35 PM > To: Satish Thatte > Cc: wsbpel-abstract@lists.oasis-open.org; Ron Ten-Hove > Subject: Re: [wsbpel-abstract] Potential requirements and use case > > Satish: We'd provide some additional suggestions: > > * If an abstract process contains opaque elements or activities, > they must be elaborated. > o Make explicit the semantics surrounding opaque if accepted. > [1] > * Ensure we can specify a process is abstract or executable > irrespective of whether opaque is used. [2] > * Suggest we define a statically verifiable set of conditions to > specify when a process model is ready to execute. > * Ban extensions from affecting 'ready to execute.' [3] This is > inline with current specification that bans extensions affecting > BPEL semantics. > > [1] In order to provide a guide for developers and allow other > computational or conformance capabilities to be used on top of the > abstract process. > [2] The condition may occur that opaque activities may have not been > explicitly added yet, but you wish to ensure that someone doesn't try to > > execute an incomplete process. We currently have > abstractProcess="yes|no"? under Process. Is this sufficient? > > Thanks. > > > > Thatte: 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 > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]