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: Re: [wsbpel] Issue - 92.6 - proposal draft


See inline. Thanks, Alex.

> Yiu: Monica,
> Thanks for your feedback. I have a relatively open mind here.
> There are two parts of my proposal. The first part is a MUST 
> requirement. The second part is a SHOULD recommendation.
>
> Do you have a use case whether bounding the semantics to its syntactic 
> scope is too restrictive? Is there any particular parts of my "MUST" 
> wording should be turned into "SHOULD"?

mm2: The comment was more so prefaced, Alex, on if the additional 
SHOULDs 'should' be included. I understand there may be other 
requirements you may have in mind to satisfy here. Are they technical 
considerations? Ron and I suggest we gain more experience before adding 
more details.

> Another point which may be helpful for clarification:
> ----------------------------
> <scope>
>    ...
>    <partnerLink name="pl1" foo:bar="..." ... />
>    <partnerLink name="pl2" ...  />
>    ...
>    <invoke partnerLink="pl1" ... />
>    <invoke partnerLink="pl2" ... />
>    ...
> </scope>
> ----------------------------
>
> The restriction is to mean the "foo:bar" extension is applicable to 
> "pl1" only, not "pl2".
> And, of course the extension effect of "foo:bar" will be carried along 
> with partnerLink "pl1", including the the usage in the <invoke> activity.
>
> If the above example explain the MUST restriction better, I could 
> change that.
>
>
> Actually, the wording of "cannot modify" is a bit too restrictive, 
> except for tool-based extension (e.g. IDE BPEL diagram layout). Most 
> of BPEL runtime extensions do apply twists to existing BPEL standard 
> semantics. For example, if engine-managed message correlation exists 
> as a form of extension to partnerLink or message-related activities.
>
> There is another 92.3 subissue to track that down.

mm2: This may evidence that we need more experience before specifying 
additional MUST or SHOULD. See comments above.

> Thanks! 

mm2: You are welcome.

>> mm1: From Ron Ten-Hove and I:
>> Alex, I understand you working hard to bound extensible elements, but 
>> the SHOULD guidelines at the end really are implementer hints. Are 
>> these necessary? Should we consider bounding the semantics of an 
>> extension to its syntactic scope? We already safeguard the semantics 
>> of BPEL, stating that extensions cannot modify them. Thank you.
>>
>>> Yiu: Hi all,
>>> Here is the proposal draft (as promised in the last conf call) for 
>>> Issue 92.6.
>>> If not controversial, I shall move it as the formal proposal soon.
>>> ------------------------------------------------------------------------ 
>>>
>>>       Proposal Draft for Issue 92.6: need for an explicit syntax token
>>>       to apply extension semantics from a NS URI
>>>
>>> Last modified: May 01, 2005 - 6 pm PDT
>>>
>>> Applied the following the text to the paragraph describing 
>>> <extension> syntax:
>>> --------------------------------------------
>>> An extension declaration through <extension> syntax does not 
>>> automatically imply the application of any extension semantics 
>>> defined in the corresponding namespace to the process definition. It 
>>> merely declares the properties of the namespace of extension, such 
>>> as, using "mustUnderstand" attribute to denote whether a WS-BPEL 
>>> processor can safely ignore related extensions.
>>>
>>> In order to apply an extension semantics to a WS-BPEL process 
>>> definition, one MUST use and include the corresponding syntax token 
>>> (either in an element form or an attribute form) explicitly in the 
>>> WS-BPEL source code and attach the token to a WS-BPEL extensible 
>>> construct.
>>>
>>> The extension semantics can ONLY affect BPEL constructs within the 
>>> syntax sub-tree of the element where the explicit syntax token 
>>> attached to. In other words, extension syntax token MUST NOT "leak" 
>>> its semantics outside the subtree. As WS-BPEL source code itself is 
>>> an XML document, the definition of syntax sub-tree is trivial and 
>>> can be borrowed from self-or-descendant concept from XML world. Here 
>>> are two examples to illustrate the above concept further:
>>>
>>> <process>
>>>     ...
>>>     <scope>
>>>         <sequence>
>>>            <invoke operation="operation1"
>>>                      foo:invokeProperty="someNature" ... />
>>>            <invoke operation="operation2" ... />
>>>            <invoke operation="operation3"
>>>                      foo:invokeProperty="someNature2" ... />         
>>> </sequence>
>>>     </scope>
>>> </process>
>>>
>>> The "foo:invokeProperty" extension attribute are applied to <invoke> 
>>> activities for "operation1" and "operation3". The <invoke> activity 
>>> for "operation2" MUST NOT be affected.
>>>
>>>
>>> <process>
>>>     ...
>>>     <scope>
>>>         <foo:invokeProperty>someNature</foo:invokeProperty>
>>>         <sequence>
>>>            <invoke operation="operation1" ... />
>>>            <invoke operation="operation2" ... />
>>>            <invoke operation="operation3" ... />         </sequence>
>>>     </scope>
>>> </process>
>>>
>>> On the other hand, the "foo:invokeProperty" extension element can be 
>>> potentially applied to all <invoke> activities within the <scope> 
>>> activity where the extension element are attached to.
>>>
>>> Apart from the above "MUST" restrictions, here are some extra 
>>> "SHOULD" guidelines for the design of extension syntax and semantics:
>>>
>>>     * Each extension syntax token SHOULD carry only semantics that
>>>       fits into a relatively modular and elegant boundary. An counter
>>>       example of bad design would be: one single extension syntax that
>>>       carries dozens of overloaded extension semantics ranging from
>>>       transaction to security, from message delivery QoS to XML data
>>>       manipulation shortcuts. One should break down the above variety
>>>       of extension semantics into different extension syntax token.
>>>     * Each extension syntax token SHOULD have a set of well-defined
>>>       attachment points, instead of making an extension syntax
>>>       applicable to every BPEL extensible constructs. Using the
>>>       "invokeProperty" example above, the set of attachment points are
>>>       <invoke> and <scope> constructs. Designers of extension are
>>>       encouraged to keep the set of attachment points small within
>>>       reasons and to try to avoid using grander level constructs (e.g.
>>>       <process> and <scope>) as attachment points  unless the
>>>       semantics of extension require.
>>>
>>>
>>> --------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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 
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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]