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 - 111 - Syntax Choices for Extension Activity(Web Ballot) [background for option#1]



Hi all,

Some of you guys may wonder how [option #1] is related to sub issue 111.1. Basically, if the web ballot result picks [option #1], that means we will effectively pick the original proposal attached to the issue description (instead of the alternative one) to continue the rest of Issue 111. [See: http://lists.oasis-open.org/archives/wsbpel/200503/msg00040.html ].

Two and half months have passed. I believe there are some new factors that we need to consider regarding to the extension syntax design issue as we progress in Issue 111 (which is not a common situation, generally speaking)  Here is more background on why it worths our efforts to evaluate all feasible options with an open mind. 

[Side Note: Please also keep in mind we did change some BPEL 1.1 design in BPEL 2.0. E.g. changing a termination fault handler to terminationHandler. and, we add <sources> and <targets> wrapper as well in BPEL 2.0]

"Historial" Timeline

First of all, I would say I am the one who needs to take the blame. :-) Because, during Germany F2F, Paco suggested to park the discussion of Issue 111.1 until we have a better idea of how Issue 111 (extension activity) looks like. At that time, for a moment, I was considering to say "yes" to Paco's suggestion. However, I made a snap judgement call to continue the discussion  process of Issue 111.1 at the F2F

Now taking in more of design consideration for Extension Activity (Issue 111), it shows that my snap judgment call in terms of continuing the discussion at F2F is definitely NOT a good one. I should let the TC (including myself) have more time to consider more aspects of extension syntax issue. So, we may not need to re-touch the extension syntax issue for extension activity.

Technical analysis

For syntax part of Issue 111, we spent most of our time in arguing whether we add wrapper to <xsd:any> for existing extension elements (under "tExtensibleElements") or to <xsd:any> for those relative newer extension points (e.g. new assign operation).

At that time, it seemed to some of us that this decision choice is a relatively arbitrary one. It looks like that it would just make some cosmetic or syntactic sugar differences, one way or the other.

Reality is: there are no extra complication / consideration for new assign operation or literal-from-spec. Because, there are no BPEL standard elements or standard attributes defined on those new assign operations or literal-from-spec.

But, now we are trying to solve the syntax issue for Issue 111. We need to decide where to put those standard attributes (e.g "name" / "suppressJoinFailure") or standard elements (e.g. <sources> and <targets>).

Oblivously, we have only 3 choices as listed in the web ballot.  Here are some comparision of these different choices:

Consistent XPath/XSLT Design
The advantage of [Option #1] and [Option #3] is: it would be MUCH EASIER to write XPath or XSLT to look for those standard-attributes and stardard-elements. (This advantage is partially applied to [Option #3] only, excluding the standard-elements part). Because, we will have a consistent place to look for those standard-attribute / elements.

For example, "./bpel:flow/*/@name"
This XPath will allow me to retrieve the list of all activity names within a <bpel:flow> in case of [Option #1] and [Option #3]. However, it will not work for [Option #2], if <extensibleActivityWrapper> is used.

XPath / XSLT is important here because they are commonly used in source code analysis for BPEL developement tool and management console.

Consistent BPEL Activity Syntax
On the other hand, [Option #2] is better than [Option #3], because it yields a more consistent syntax between a BPEL standardized activity and an Extension Activity. A consistent syntax is better because:
  • If the next version of BPEL spec decides to standardize some of extension activity, people just need to change their corresponding XMLNS declaration and remove <extensibleActivityWrapper>. Then they are done with their code migration to new version of the spec. (Removal of <extensibleActivityWrapper> is even not needed for [Option #1].) 
  • Also, please note that are some subtle differences of location of xsd:any between [Option #3] and a standard-activity. That difference was first mentioned by Yaron:
    http://lists.oasis-open.org/archives/wsbpel/200503/msg00209.html
    That difference matters when people try to extend an extension activity. (Details see below) That difference is definitely undesirable.
If one looks like closely, actually BOTH advantages of  "Consistent XPath/XSLT Design" and "Consistent BPEL Activity Syntax" can be applied to [Option #1]. If we pick [Option #1], we can get best of both world!!!

That is why we decide to pursue [Option #1] by listing it as one of web-ballot options, after we obtain more pro-vs-cons analysis result as we progress in Issue 111.


Thank you so much for your understanding !!!




Regards,
Alex Yiu



Alex Yiu wrote:

Hi all,

Here is the details of the web ballot (proposed) for Extension Activity Syntax.

The web-ballot is NORMATIVE. That is, a binding vote on a partial solution for 111 which would then constrain the remaining completion of the resolution. Similar to what we did with 82 where we approved a partial solution that set a direction and filled in the details later with a vote on the additions.

In short, we shall finish the actual proposal for Issue 111 to vote based on the result of this web-ballot.


(I hope the color scheme make it easier for comparision)

Option #1
: moving the extension to wrapper to generic extension points (<extendedBy>)
-----------------------------

<sequence>
   
<extendedBy>
       
<foo:sequenceExtension1="xyz" />
   
</extendedBy>
    ...
   
<invoke name="myInvoke"
                 
foo:activityExtension2="abc"
                 
operation="op1" ...>
       
<extendedBy>
           
<foo:activityExtension3>def</foo:activityExtension3>
       
</extendedBy>
        <targets> ... </targets>
        <sources> ... </sources>

   
</invoke>
   
<bar:myInvoke name="myExtendedInvoke"
                 
foo:activityExtension2="abc"
                 
operation="op1" ...>
       
<extendedBy>
           
<foo:activityExtension3>def</foo:activityExtension3>
       
</extendedBy>
        <targets> ... </targets>
        <sources> ... </sources>

   
</bar:myInvoke>
</sequence>

-----------------------------
Related to: http://lists.oasis-open.org/archives/wsbpel/200503/msg00040.html

Option #2:
Using <extensibleActivityWrapper> and having all standard attribute and elements and generic extension points (both attr and elem) local to the extended activity element itself (i.e. <bar:myInvoke>).
-----------------------------

<sequence>
   
<foo:sequenceExtension1="xyz" />
    ...
   
<invoke name="myInvoke"
                     
foo:activityExtension2="abc"
                      operation="op1" ...>
           
<foo:activityExtension3>def</foo:activityExtension3>
            <targets> ... </targets>
            <sources> ... </sources>

   
</invoke>
   
<extensibleActivityWrapper>
       
<bar:myInvoke name="myExtendedInvoke"
                     
foo:activityExtension2="abc"
                      operation="op1" ...>
           
<foo:activityExtension3>def</foo:activityExtension3>
            <targets> ... </targets>
            <sources> ... </sources>

       
</bar:myInvoke>
   
</extensibleActivityWrapper>
</sequence>

-----------------------------


Option #3
: Using <extensibleActivityWrapper> and having all standard attribute and elements and generic extension attr on the wrapper, but having  generic extension element local to the extended activity element itself (i.e. <bar:myInvoke>)
-----------------------------

<sequence>
   
<foo:sequenceExtension1="xyz" />
    ...
   
<invoke name="myInvoke"
                 
foo:activityExtension2="abc"
                  operation="op1" ...>
       
<foo:activityExtension3>def</foo:activityExtension3>
        <targets> ... </targets>
        <sources> ... </sources>

   
</invoke>
   
<extensibleActivityWrapper name="myExtendedInvoke"
                              
foo:activityExtension2="abc">
        <targets> ... </targets>
        <sources> ... </sources>

       
<bar:myInvoke operation="op1" ...>
          
<foo:activityExtension3>def</foo:activityExtension3>
       
</bar:myInvoke>
   
</extensibleActivityWrapper>
</sequence>

-----------------------------

Option #4
: Other:
Please state your alternative opinion. E.g.: you can simply state your position, if you don't support extension activity in general in BPEL.



Thanks so much!!!



Regards,
Alex Yiu





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