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