[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 107 - Proposal to Vote
Hi all, Issues are being mixed here. 82 is about clarifying what abstract processes are. 107 is about what's opaque. I don't see the dependency on 158 which is about editorial stuff. Yaron Y. Goland wrote: > +1 to both Martin's mail (we can't vote on 107 until we have a > definition of abstract processes) and Peter's summary of what abstract > processes are. I would point out that Peter's definition naturally leads > us to issue 158 and structuring the spec so we first define executable > processes in full and then we define abstract processes as an extension > of executable that introduces opaque functionality. > > Yaron > > Furniss, Peter wrote: > >> >> >> I seem to recollect a suggested definition of abstract v executable bpel >> that was roughly: >> >> executable bpel is a document that doesn't have opague in it. >> >> abstract bpel is a document that does have at least one opaque >> >> with an underlying assumption that although some opaque-free BPEL script >> could be executed, it >> might in fact be an abstraction of a particular deployed process (i.e. >> the >> deployment had other features that weren't detailed in the bpel script, >> but >> it did all the things that were in that script. >> >> (apologies if this is just more petrol on the fire) >> >> Peter >> >> >> > -----Original Message----- >> > From: Martin Chapman [mailto:martin.chapman@oracle.com] >> > Sent: 08 October 2004 10:07 >> > To: wsbpel@lists.oasis-open.org >> > Subject: RE: [wsbpel] Issue - 107 - Proposal to Vote >> > >> > >> > >> > Opaque have no place in executable bpel, but we have not yet >> > clarified what abstract bpel is. Therefore I cannot see how >> > we can vote on 107 until we have resolved the >> > >> > generic abstract bpel issue. >> > >> > Cheers, >> > Martin. >> > >> > >-----Original Message----- >> > >From: rkhalaf [mailto:rkhalaf@watson.ibm.com] >> > >Sent: 06 October 2004 20:30 >> > >To: ygoland@bea.com >> > >Cc: Assaf Arkin; wsbpel@lists.oasis-open.org >> > >Subject: Re: [wsbpel] Issue - 107 - Proposal to Vote >> > > >> > > >> > >Hi >> > > >> > >There are two issues under discussion here: >> > >Your issues bring up two kinds of attributes. Ones with a >> > >default value >> > >(createInstance) and one without (operation). >> > > >> > >Regarding operations being opaque (and some notes regarding >> > the extent >> > >of opacity), there was a discussion between Danny and Satish >> > from the >> > >end of September under the heading "abstract process strawman". >> > >Specifically, please see: >> > > >> > >http://www.oasis-open.org/archives/wsbpel/200409/msg00319.html >> > > >> > >In recollection Diane's comments at the F2F of the perils of >> > >repetition >> > >;) I'll spare us my own paraphrase of that mail and simply >> > >point to the >> > >last paragraph which is along the lines of what I had been >> > trying to >> > >point out at the F2F.. >> > > >> > >Regarding createInstance, I don't find the example compelling. >> > >createInstance receives signal entry-points into the process. It is >> > >intrinsically part of the definition of the activity and its >> > behavior >> > >and its place in the process model. Either it is an entry >> > >point or it is >> > >not. The place where I think the debate would be more interesting is >> > >when we discuss Ivana's issue regarding whether or not such >> > activities >> > >may be simply completely ommitted.. Note, that this is drastically >> > >different from actually having a receive with a portType/op >> > and making >> > >its createInstance attribute opaque. >> > > >> > > >> > >Regards, >> > >Rania >> > > >> > >Yaron Y. Goland wrote: >> > >> One of the outcomes of the discussion around issue 81 is that it >> > >> actually makes sense to allow for empty to occur before start >> > >> activities. But I recognize that this is not a normative >> > >statement of >> > >> the spec. >> > >> >> > >> But in any case the other issues mentioned in my letter >> > still stand. >> > >> >> > >> Assaf Arkin wrote: >> > >> >> > >>> Yaron Y. Goland wrote: >> > >>> >> > >>>> Imagine I have the following abstract process: >> > >>>> >> > >>>> process abstract="true" >> > >>>> sequence >> > >>>> opaque >> > >>>> receive >> > >>>> >> > >>>> I want it to be undefined in the abstract process >> > definition if the >> > >>>> receive is a start activity or not. After all, if opaque >> > >is replaced >> > >>>> by empty then it would be legal for receive to be a >> > start activity. >> > >>> >> > >>> >> > >>> >> > >>> A start activity cannot follow a base activity, and the empty >> > >>> activity >> > >>> is a base activity. >> > >>> >> > >>> Assaf >> > >>> >> > >>> >> > >>>> >> > >>>> The default value for createInstance is no. Therefore it is >> > >>>> impossible for me to leave the receive activity's status as a >> > >>>> potential start activity as undefined. Only if there was a >> > >>>> createInstance="opaque" would the ambiguity be possible. >> > >>>> >> > >>>> Similarly if I want to define a messaging operation but be >> > >ambiguous >> > >>>> as to what exactly message I'm sending or receive, I just want to >> > >>>> specify who I am communicating with, there is no way to do >> > >that if I >> > >>>> can't say operation="opaque". >> > >>>> >> > >>>> By not providing for opaque attributes I am required to specify >> > >>>> aspects of an abstract process that in a templating scenario I >> > >>>> wouldn't want to have to specify. >> > >>>> >> > >>>> Yaron >> > >>>> >> > >>>> >> > >>>> rkhalaf wrote: >> > >>>> >> > >>>>> >> > >>>>> >> > >>>>> This proposal affects spec section 15 (Extensions for Business >> > >>>>> Protocols). I'm not going to do spec wording. This is >> > split into >> > >>>>> four >> > >>>>> parts: base, activities, expressions, and attributes. >> > >>>>> >> > >>>>> --- >> > >>>>> >> > >>>>> Base (w/ background): >> > >>>>> >> > >>>>> In abstract processes, operational details may be >> > abstracted away >> > >>>>> either through the omission of specific BPEL elements or >> > >attributes >> > >>>>> listed in the specification, and/or through the use of opaque >> > >>>>> tokens. Its abstract status states that any concrete >> > realizations >> > >>>>> of it may perform additional processing steps that are >> > >not relevant >> > >>>>> to the audience to which it has been given. >> > >>>>> >> > >>>>> It must be stressed that opaque entities (activities, >> > >etc) are not >> > >>>>> the only points of extension allowable in creating a process >> > >>>>> derived from or related to an abstract process that >> > uses them. In >> > >>>>> particular, a related executable process MAY contain additional >> > >>>>> processing steps (activities, fault handlers, etc) and > >> >parterLinks >> > >>>>> including the extras that may be required to carry these >> > >>>>> out(correlation sets, variables). >> > >>>>> >> > >>>>> Opaque entities: >> > >>>>> >> > >>>>> Part A - Opaque activities: >> > >>>>> >> > >>>>> An activity called 'opaque' shall be introduced for the >> > exclusive >> > >>>>> use of abstract processes. An opaque activity explicitly hides a >> > >concrete BPEL >> > >>>>> activity whose behavior is not relevant to the >> > >recipient/user of the >> > >>>>> abstract process. An opaque activity is a BPEL activity >> > >and therefore >> > >>>>> has the same standard elements and attributes that all >> > >BPEL activities >> > >>>>> have (see spec section 11.1 and 11.2). >> > >>>>> >> > >>>>> Examples of using opaque activities include, but are not >> > >restricted >> > >>>>> to, creating process templates (marking the points of normative >> > >>>>> extension in a process) and edge cases where simple >> > >omission of an >> > >>>>> activity creates a syntactic problem, e.g., if the >> > >omitted activity >> > >>>>> is a join point for several links. >> > >>>>> >> > >>>>> At first glance, it seems that this could instead be done using >> > >>>>> "empty" , but the difference is that "empty" explicitly >> > >says "I do >> > >>>>> nothing here," whereas "opaque" is really saying "some >> > >magic occurs >> > >>>>> here but it's hidden on purpose". >> > >>>>> >> > >>>>> >> > >>>>> PART B - Opaque expressions (incl assignment): >> > >>>>> >> > >>>>> Opaque assignment (<from opaque="yes") is used for capturing >> > >>>>> variable creation/modification in a yet-to-be-concretized >> > >>>>> mechanism/fashion. An example of usage is to express >> > >>>>> non-determinism: the obvious case being a process that needs to >> > >>>>> show a decision point with alternative outcomes without >> > >specifying >> > >>>>> how the decision is reached. In this case the expressions that >> > >>>>> constrain each branch may need to be left unspecified, >> > but it may >> > >>>>> also be convenient to make a specific value or quantity >> > such as a >> > >>>>> price threshold unspecified, so that explicitly specified >> > >>>>> conditions relative to the threshold become >> > >non-deterministic as a >> > >>>>> result of the threshold value being unknown. >> > >>>>> >> > >>>>> In addition to <from opaque="yes"/>, this proposal asks for >> > >>>>> allowing transitionConditions to be opaque. This avoids the >> > >>>>> default "true" value. If an expression is opaque, the >> > >>>>> expressionLanguage attribute on it is meaningless since >> > >there is no >> > >>>>> expression syntax to refer to. >> > >>>>> >> > >>>>> -sample syntax: >> > >>>>> <transitionCondition opaque="yes"/> >> > >>>>> >> > >>>>> PART C - Opaque attributes: >> > >>>>> >> > >>>>> No change to the spec. >> > >>>>> >> > >>>>> (background info on why not attributes: They were originally >> > >>>>> proposed to make all hiding explicit but there was a lot of >> > >resistance to that. >> > >>>>> Then, they were proposed for attributes that have >> > >defaults in BPEL - >> > >>>>> but all the examples that were put forward created more >> > >agony than the >> > >>>>> uniformity using opaque would have brought to the table. >> > >The reason >> > >>>>> was >> > >>>>> that they are core to the semantics of the constructs >> > >they are attached >> > >>>>> to. Examples include suppressJoinFailure, isolated (scopes), >> > >>>>> createInstance, and initiate (correlation sets). Therefore, I >> > >>>>> propose no change to the spec.) >> > >>>>> >> > >>>>> >> > >>>>> --- Rania >> > >>>>> >> > >>>>> >> > >>>>> To unsubscribe from this mailing list (and be removed from the >> > >>>>> roster of the OASIS TC), go to >> > >>>>> >> > >http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/lea >> > ve_workgroup.php. >> > >>>> >> > >>>> >> > >>> >> > >>> To unsubscribe from this mailing list (and be removed from the >> > >>> roster >> > >>> of the OASIS TC), go to >> > >>> >> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le >> > ave_workgr >> > oup.php. >> > >>> >> > >>> >> > >> >> > >> >> > > >> > > To unsubscribe from this mailing list (and be removed from >> > the roster >> > > of >> > > the OASIS TC), go to >> > > >> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le >> > ave_workgr >> > oup.php. >> > > >> > >> > >> > >> > To unsubscribe from this mailing list (and be removed from >> > the roster of the OASIS TC), go to >> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le >> > ave_workgr >> > oup.php. >> > >> > >> > >> > To unsubscribe from this mailing list (and be removed from >> > the roster of the OASIS TC), go to >> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le >> > ave_workgroup.php. >> > >> > >> >> >> Choreology Anti virus scan completed >> > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]