OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issue 82.3 - Clarification to the base, and change to template profile


Hi everyone,
 
While going through the missing section on 82.3, there was confusion regarding the use of default values. The confusion was because the text in the base about default values and omission is spread out over several sections. Alex, Danny and I worked on adding a clarification in the base to succinctly spell out what  happens to constructs with defaults in an Executable Completion, and to highlight the effect of that on the ability to add new links.  The clarification is also referred to now by the newly edited text for the lost section of 82.3.

This requires a fix in the template profile: the template profile today allows one to set the value of 'validate' if it is omitted in the AP. With the clarification, it can be changed if it is explicitly opaque, and there is a note about tools.

I'm not sure what the right way to address this is (open an issue for both ? for one ? )

We can discuss that in the call tomorrow. In the meantime, here is the text that we have crafted to provide a solution to both things.

Here are the pdf and word versions, with track changes on:

http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/18967/EC-clarification_EDITED.pdf

http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/18968/EC-clarification_EDITED.doc

** AFTER** THE EC definition (unchanged), we add the two paragraphs starting 'A clarification ..'.

New Clarification in Base

An Executable Completion of an Abstract Process is defined as an Executable Process that

1.      is derived only by:

a)      Changing the namespace to that of Executable WS-BPEL and removing the profile URI.

b)      Using some combination of the following syntactic transformations:

                                             i.            Opaque Token Replacement: Replacing every opaque token (including those omitted using the omission-shortcut) with a corresponding Executable token. For example, replacing an opaque activity with an <empty>.

                                           ii.            Addition of WS-BPEL constructs: Adding new WS-BPEL XML elements anywhere in the process.

2.      is a valid Executable WS-BPEL process that satisfies all static validation rules mandated by this specification including both schema-based and non-schema-based rules.

A clarification is provided here regarding the completion rules and their application to constructs with default values in the Abstract Process, such as “createInstance” at <receive>, “validate” at <assign> and <joinCondition> within <targets>. The completion rules above do not allow changing non-opaque constructs when creating an executable completion (whether through omission-shortcut or explicitly).  As stated in section "13.1.3. Hiding Syntactic Elements", a construct, which is not explicitly present in the abstract process and has a default value, is not allowed to be made opaque through omission-shortcut. Its value will be that of the default in all executable completions (e.g.: “no” for an omitted  “suppressJoinFailure” attribute). Therefore, specifying its value in an executable completion is not covered by “Addition of WS-BPEL constructs.” In order to allow Execution Completion to specify the value of such constructs, explicit opaque tokens should be used in the Abstract Process.  Completions can then specify the values specified using “Opaque Token Replacement”.

This is especially relevant to the addition of links. New links cannot be added as targets to existing activities with at least one link if such an addition changes an existing, non-opaque join condition (including the default join condition).  The default join condition is included in this consideration because adding a new link to an activity using the default join condition effectively changes the condition to include the new link’s status. Examples where new links can be added include adding them to: 1) an activity with no existing incoming links, 2) an activity with incoming link(s) and an opaque join condition, or 3)  an activity with incoming link(s) and an explicitly specified, non-opaque join condition (whose value cannot be changed in any executable completion).

New Changes in Template Profile:

1) Drop the bullet about <assign> under "13.4.4. Adding Constructs without explicit opacity". And add a clarification after all the bullets:

A tool, which generates Abstract Processes of Template Profile based on user inputs, is expected to use explicit opaque tokens to denote the constructs with default values (e.g. validate attribute at <assign>) in the generated WS-BPEL Abstract Processes, when users of the tool do not specify any values for those constructs.  In the WS-BPEL Abstract Process itself, omitting such a construct is, as usual, equivalent to specifying it using the default value.

 



 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]