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 6 - Rough draft of proposal for vote

Hi Danny,

It was not a matter of complexity, rather there was an important concern
about adoption; we made a careful attempt to limit the amount of new or
"advanced" features that were uncommon in workflow practice. "Immediate
evaluation" was one of those, but we also decided to mention it explicitly
in the spec because we consider it a very powerful extension which the
language should support at some point. Compared with some of the function
BPEL has since introduced since then "immediate evaluation" looks like
small change.


                      Danny van der                                    
                      Rijn                     To:       Axel Martens/Watson/IBM@IBMUS
                      <dannyv@tibco.com        cc:       "'wsbpel@lists.oasis-open.org'" <wsbpel@lists.oasis-open.org>
                      >                        Subject:  Re: [wsbpel] Issue 6 - Rough draft of proposal for vote
                      09/01/2004 04:18                                 

while i like the simplicity, i am concerned that in WSFL 1.0, the
"immediate" value was not allowed:

"V1.0 remark: deferred is the only valid value for the when attribute in
Version 1.0."

can you comment on the reasons that it was not included in 1.0?  i imagine
that there were complexities introduced that were not desirable for a 1.0
spec.  i wonder if those concerns are also relevant for BPEL.
Axel Martens wrote:

      Dear all:

      I'd like to participate in your discussion with a proposal that
      comes with minimal changes to the current BPEL specification but
      is able to handle the mentioned use cases, and even more.

      First, I'd like to introduce myself. I am a post-doc researcher at
      IBM Watson, working in the group of Paco Curbera. In my PhD thesis
      I have dealt with Web service based business processes and Petri
      nets. Hence, I know the discussion on the mismatch between BPEL
      and the workflow pattern  la van der Aalst quite well.

      I completely agree on searching for a general solution to the
      request of issue 6 rather than fixing distinguished cases. The
      problem (or restriction) of BPEL is that you can't enable or
      disable an activity easily w.r.t. to the complex context, like you
      can do modeling with Petri nets or related methods. The deferred
      evaluation of the join condition (all incoming links has to be
      signaled first) is one of the mayor reasons for it. Hence, our
      group proposes to allow an immediate evaluation of the join
      condition, too. This feature was already covered by IBM's Flow
      Definition Language (FDL) and Web Service Flow Language (WSFL).

      The next paragraph explains the proposed change to syntax and
      semantics. Afterwards I show three examples to demonstrate the
      expressive power of this changes.

      Syntax & semantics:

      The changes to syntax are minimal. Each activity gets a new
      standard attribute "joinEvaluation" - of course, this attribute
      has only influence on activities that are target of at least two
      links. The attribute can have the values "deferred" (the default
      value) and "immediate".

      As a kind of syntactical sugar, each flow or the whole process
      might redefine the default value for all its child activities
      through the additional attribute "defaultJoinEvaluation". But, we
      do not insist on this change.

      In case, the attribute was set to "deferred", the join behavior
      stays untouched. If the attribute was set to "immediate", the join
      condition is evaluated each time one of the incoming links has
      changed its value. Some examples:

        "true" and "yet undefined" yields "yet undefined"
        "false" and "yet undefined" yields "false"
        "true" or "yet undefined" yields "true"
        "false" or "yet undefined" yields "yet undefined"

      This evaluation may yield "yet undefined", than nothing happens.
      If the join condition could be evaluated to "true" or "false", the
      activity is executed or skipped, and further changes to the link
      values are ignored.

      Because links are not allowed to cross the borders of a while loop
      and each time a while loop is entered, its internal link value
      should be cleared, there can't be any confusion.


      This changes together with the already existing concepts of scope
      and fault handling allow an strait forward mapping of the missing


      First, we take a look on a selection of one result out of three,
      where the not chosen alternatives are allowed to finish normally.
      The following figure shows the example of contacting three
      airlines and booking the first available (for reasons of clarity,
      the bpel-code is not fully specified).

      (Embedded image moved to file: pic03178.gif)
      Because of the immediate evaluation of the join condition, the
      activity "InvokeBooking" is started directly after the termination
      of one preceding activity. Whereas the flow is exited only if all
      its child activities are terminated. In case, the customer should
      be informed as soon as possible, the reply activity should be
      moved into the flow in sequence to "InvokeBooking".


      The second example shows two new aspects. First, the join requires
      at least two of the three referees to have finished the review.
      This is done by a modified join condition. Second, after two
      results are available, still running activities of the flow are
      explicitly terminated. This is modeled by help of a scope around
      the flow with an empty fault handler that catches the
      "forcedTemination" fault.

      These mechanisms already exit. Hence, no further changes to the
      language itself are necessary. Of course, a user should be
      supported, e.g. by generating such structures automatically on
      demand, but this is a task of tooling rather than language design.

      More complex relations

      Finally, the join condition can specify precisely which
      combination of link values is needed to proceed, instead of just
      the number. The last figure shows an example employing this
      feature: For booking a trip, it is necessary to find an available
      hotel and at least on kind of transportation.

      This example mixes all concepts. In case, no hotel or no
      transportation is available, an information for the customer is
      generated ("assign") and the flow is terminated ("throw").
      Otherwise, the trip is booked ("InvokeBooking") and still running
      activities are allowed to terminate on their own before the
      customer is informed.


      A minimal change to BPEL's syntax and an easy to implement change
      to its operational semantics enrich the expressive power
      enormously, such that more useful modeling pattern could be mapped
      into this language. To increase the convenience of usage, tools
      may provide predefined macros or generate necessary structures
      automatically on demand.

      Regards, Axel.
      Axel Martens

      Post Doc Researcher
      Component Systems Group
      IBM TJ Watson Research Center
      Hawthorne, NY (USA)
      Phone: (914) 784-7480
      E-mail: amarten@us.ibm.com

 "Trickovic, Ivana"                                                    
 09/01/2004 10:32               <alex.yiu@oracle.com>                  
 AM                                                                     cc
                                RE: [wsbpel] Issue 6 - Rough draft of  
                                proposal for vote                      


      Regarding the proposed semantics: Would you elaborate how the fault
      (bpws:earlyCompletionFault) will be signaled to other incomplete flow
      activities? Those activities are enclosed within the flow activity.
      If I understand the fault handling model correctly there is no
      possibility to communicate faults to nested activities/scopes except
      canceling the enclosing activity (in this case, the flow activity).



      -----Original Message-----
      From: Alex Yiu [mailto:alex.yiu@oracle.com]
      Sent: Mittwoch, 1. September 2004 04:28
      To: Satish Thatte
      Cc: edwink@collaxa.com; wsbpel@lists.oasis-open.org; Alex Yiu
      Subject: Re: [wsbpel] Issue 6 - Rough draft of proposal for vote

      Hi, Yaron and others,

      I agree with the concern of Edwin and Satish. We should define a
      general mechansim to express early completion condition. Then, define
      the "orJoin" attribute or other syntax as a macro/special syntax
      short cut.

      If you guys don't mind, I can supplement some alternative ideas to
      this issue. I am in the thinking-out-loud mode again. That means, I
      need to verify whether this idea makes sense to other people at
      Oracle.  [ But, as Ron said, this thinking-out-loud mode has worked
      quite well for me in the past. ;-) ]

      We should allow a <completeCondition> subelement attached to
      parallel-flow-starter activity (e.g. <flow> or future potential
      parallel <forEach>).

      Syntax of completeCondition:
      It has two forms:
      (1) <completeCondition>a_boolean_expr</completeCondition>
      (2) <completeCondition minFlow="a_number" />
                 ...  or ...

      The first form is the most generic form of completion condition.
      The second form provides a convienent shorthand to achieves the N out
      of M semantics.

      The suggested orJoin="yes" is equivalent to:
         <completeCondition minFlow="1" />

      Semantics of completeCondition:
      The complete condition will be evaluated at the completion of each
      flow. If the condition is true, a standard fault
      bpws:earlyCompletionFault will be signaled to other incomplete flow
      activities. Each incomplete flow activity can potentially be
      compensated if each flow is a scope activity. (Potentially, we can
      add static analysis to enforce that when a completionCondition is
      used in <flow>, <scope> must be used as activities within the flow.)

      The completeCondition itself is executed in the same scope context of
      the <flow> activity.  [ And, the completeCondition should be executed
      serially, to avoid racing condition among flows (?)]

      I hope this rough draft of ideas serves as a good base of discussion
      for this issue.


      Alex Yiu

      Satish Thatte wrote:
      I echo Edwin's second question.  Yaron, your proposal clearly doesn't
      address the intent of 6.  It seems too narrow to just address this
      corner case of completion of one among many (corner case from my

      From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
      Sent: Friday, August 27, 2004 5:38 PM
      To: wsbpel@lists.oasis-open.org
      Subject: RE: [wsbpel] Issue 6 - Rough draft of proposal for vote

      Hi Yaron,

      2 questions:

      1) are we sure that termination is the desired behavior for the non
      completed activity?

      2) what happens if the join rule is: "the first search result which
      is non empty or includes at least 3 entries with more than 85%
      accuracy"? The point here is that a lot of join patterns might have
      logic in them. I know that in the past we talked about having
      something like <break> for flow. (This is something that a lot of our
      customers are asking us and might address the same us case is a more
      flexible way specially if the <break> can be configure to tell the
      engine to compensate or terminate).




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