[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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/leave_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/leave_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/leave_workgr oup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]