[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 107 - Proposal to Vote
Hi Martin, I'm drafting something for 82 and will post in a bit. As we discussed in the last call, there is no reason why these discussions can't go along in parallel and I do agree that they probably shouldn't go on in strict reverse order :) -rania Martin Chapman wrote: > 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. > > > > 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]