[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 107 - Proposal to Vote
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]