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: [Fwd: [wsbpel] Issue - 82.3 - AP 1.1 definition to be refactoredas a profile.]


Hi all,

I have modified the suggested change that is about issue 99 below to 
address the ambiguity Monica had raised about the original wording.

After discussing this with her off-line, we realized that the discussion 
about that was heading into 99  territory and the right thing to do is 
to relegate to that. That had been my initial intent, but my wording was 
kinda crap ;)

Please take the below as the revised text for consumption ;)

Regards,
Rania

-------- Original Message --------
Subject: 	[sbpel] Issue - 82.3 - AP 1.1 definition to be refactored as a 
profile.
Date: 	Mon, 27 Jun 2005 14:05:05 -0400
From: 	Rania Khalaf <rkhalaf@watson.ibm.com>
To: 	wsbpel@lists.oasis-open.org
References: 	<42BC4975.1090107@watson.ibm.com> 
<42BC4F4A.4080907@tibco.com> <42BC51BC.5020005@watson.ibm.com> 
<42BC5FBE.8060400@oracle.com> <42C02C11.3010500@watson.ibm.com>



Hi everyone,

Here is a summary of the main points of the AP1.1 profile.
I would like to do two rounds of this:

One to agree on the  'meat' (points below), and another of the spec 
wording/motivation/etc..
Like what we did for main 82.

The main idea here was to make the AP1.1 into a profile, and adding a 
completions section that is based on the idea of keeping the messages 
exchange order the same.

Regards,
Rania
--------------------------------------------------
AP1.1 refactoring, start.
-------------------------------

(add motivation)

(consider what old text to bring in from spec and how to modify it to
introduce various aspects, especially regarding clarifications about
initialization of correlation sets and variable omission).

ProfileURI:

- http://schemas.xmlsoap.org/ws/2004/03/business-process/abstract/ap11


Base Language subset
_____________________

.. This profile restricts the base in the following manner: 

(From AP1.1 original):

* The only expression that can be opaque is <from opaque='yes'>

* The only attributes that can be opaque are the attributes
 "variable", "inputVariable" and "outputVariable", on
 receive/invoke/reply/onMessage/onEvent (Note: bug fix based on Issue
 97: fixing the consistency for elements onMessage and onEvent).

* It is not clear whether BPEL function 'getVariableData' is allowed
 (what's the new form of this with $ etc): Text disallows it, but
 example uses it. Need to vote on this. Preference is to disallow
 it. However, 'get VariablePropery' is still allowed.

* Activity <exit > is not allowed. 

* Uses omission-shortcut for the opaque tokens above.

(Suggested Changes):

* In this profile, allow leaving out the createInstance receive (This is 
a part of the consideration of Issue 99 which may also affect Issue 82).

* Allowing opaque activity, as a bug fix for the two reasons
 below. Note that its use elsewhere is superfluous since completions
 in this profile allow adding new BPEL activities anywhere:

    -Allows for hiding an activity that is the source or target of
    -links.  Allows for using omission-shortcut in places like fault
    handlers etc (This had led to Issue 91).

* Allowing all expressions to be opaque except joinCondition. Please
 note that the joinCondition is based on the transition conditions on
 the incoming links. If the joinCondition is missing its default
 value is the disjunction of the status of the incoming links.


Base Completions subset
_________________________

Places where new activities may be added are not explicitly defined in
processes in this profile. The permitted executable completions of
abstract processes in this profile include both 'Opaque Token
Replacement' and 'Addition of BPEL Constructs', but subsetting those
such that:

o Each process that is a valid executable completion of a process in
this profile MUST NOT:

   * add to
   * omit any of
   * or change the order (control dependency) of

any of the interactions along the partnerlinks already defined in the
abstract process, even if replacing opaque activities (including those
omitted with omission-shortcut, such as activity of a fault
handler). Note that this still allows for adding new interactions with
new partnerLinks (ie: partnerLinks added in the executable completion
but not present in the abstract process).

o It is not allowed to add copies in assigns whose 'to' is any of the
EPRs of the partnerLinks defined in the abstract process, because that
is equivalent to removing subsequent interactions with that partner.
Remember that 'opaque token replacement' also replaces opaque tokens
omitted through the omission-shortcut.

( Note: The phrase 'even if .. ' sentence is pending whether opaque
activities get allowed. )





---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 




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