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


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bpel message

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

Subject: Re: [sca-bpel] NEW ISSUE: Title: Correlation disagreement between SCA andBPEL

Hi Alex, I agree with your interpretation of WS-BPEL 2.0. IMO, for both
correlation means, we need to consider the cases of zero/one/multiple
matching process instance(s), the case where the two sets are not
identical, and the case where a resolved process instance does not expect
the message (note however that it may do so at a later point in time). Many
cases (like the obvious case of an undelivered message) are out of scope of
WS-BPEL 2.0, but we might want to describe the expected behavior in

Kind Regards

             Alex Yiu                                                      
             com>                                                       To 
                                       Najeeb Andrabi <nandrabi@tibco.com> 
             27.09.2007 04:40                                           cc 
                                       Danny van der Rijn                  
                                       Re: [sca-bpel] NEW ISSUE: Title:    
                                       Correlation disagreement between    
                                       SCA and BPEL                        

Hi, Najeeb,
(explicitly cc'ing Danny as well)

I think your email explanation fits my guess on what you are worrying
about. Here is my understanding on how WS-BPEL 2.0 spec (not SCA-BPEL spec)
deals with this situation.
      First let me re-elaborate the situation with my own wordings to make
      sure we are on the same page:
            SCA infrastructure dispatchs a message to a BPEL process by
            some sort of machine-generated ID (similar to GUID)
            However, there is a mismatch between the correlation set used
            and the message content (say OrderNumber is somehow screwed up)
      In this case, the message will NOT be passed to the BPEL process
      instance through BPEL infrastructure. (I think that is what WS-BPEL
      2.0 spec says.)
      This is a situation where a message is successfully received
      successfully by the BPEL infrastructure from the lower layer
      communication infrastructure BUT there is no matching inbound message
      activity (e.g. receive). Let me call this "dead letter message
      The very same situation can occur even without any SCA conversation
      mechanism. That is,  just a plain old correlation mistake somewhere
      in the message or process. The difference is the SCA conversation ID
      serves an extra ID (think correlation redundancy) that allows the
      detection of the correlation problem earlier.
      Unfortuatnately, WS-BPEL 2.0 spec does not specific semantics to deal
      with "dead letter message situation".  (My first attempt to deal this
      situation was actually in BPEL F2F Apr 2004.) And, SCA conversation
      mechanism is one of the "engine-managed correlation" examples (using
      BPEL TC discussion term, used in issue list but not in the spec). I
      think if we want to deal with this "dead letter" situation. We should
      have a solution generic to all BPEL's "dead letter" scenario, even
      without using SCA conversation mechanism. Hence, I am wondering
      whether SCA-* spec (including SCA-BPEL) is the right place to handle
      this situation.
      Last time, when I read about SCA conversation mechanism in SCA
      Assembly spec, it is somewhat binding independent. (It may involve
      WS-Addr, WS-Coordination, WS-BusinessActivity or SCA vendor specific
      mechanism). It may be difficult to define how to notify the client in
      an async fashion about the correlation mismatch situation, if we
      cannot specify some binding/protocol details. Say, if the caller and
      callee are both using WS-BusinessActivity, this correlation mismatch
      will not want to shift the coordination context to the "faulted"
      NOTE: bpel:correlationViolation is NEVER used to send back a fault to
      the client of the BPEL process. It is used ONLY in correlation set
      initiation lifecycle error so far in WS-BPEL 2.0.

Thanks for reading this long email. :-)

Alex Yiu

Najeeb Andrabi wrote:

      Hi Alex,
                  Sorry could not get back to you earlier. I have done a
      quick write up of the correlation disagreement issue.

      Correlation Disagreement between SCA and BPEL

      SCA defines conversational interfaces at binding level and not at an
      application level. This approach can result in ambiguous behavior as
      the two correlation mechanisms are mutually exclusive. To illustrate
      this, let use consider a long running Loan Approval SCA composite
      application that is implemented using BPEL component

      (Embedded image moved to file: pic26113.gif)

      The client make two asynchronous web services (submit request and
      check response) calls using SOAP over HTTP.  These two web service
      calls take part in SCA container based conversation. The SCA
      container correlates based on a correlation id that it generates as a
      response for the submit request web service call.

      . The interface used by the Loan Approval process is defined below:

                  <portType name =”LoanService”
                       <operation name = “submitRequest”>
                                         <input message =
                                         <output message = “tns:
                        <operation name = “checkResponse”
                                         <input message =
                                         <output message =

        This works fine if the correlation is not defined at the BPEL
      process level.

           Now, if the BPEL process correlates as well based on LoanRequest
      correlation set that uses orderNumber and orderDate properties; there
      is a possibility for ambiguous behavior as the SCA container could
      correlate correctly while the BPEL container fails to correlate
      correctly and sends a correlation violation exception back to the

      <correlationSet name=”LoanRequest” properties=”orderNumber

                <Receive name="Submit Request Receive"
                    <correlation set="LoanRequest" initiate="yes"
                <Reply name="Submit Request Reply"
                <Receive name="Check Response Receive "
                       <correlation set="LoanRequest"/>
                <Reply name=" Check Response Reply"

      From: Alex Yiu [mailto:alex.yiu@oracle.com]
      Sent: Wednesday, September 26, 2007 11:30 AM
      To: Najeeb Andrabi
      Cc: sca-bpel@lists.oasis-open.org; ALEX.YIU@oracle.com
      Subject: Re: [sca-bpel] NEW ISSUE: Title: Correlation disagreement
      between SCA and BPEL

      Hi Najeeb,

      Could you elaborate your concern with a more concrete example?
      Particularly to elaborate what you mean by "BPEL correlation fails"?


      Alex Yiu

      Najeeb Andrabi wrote:
      TARGET: SCA C+I WS-BPEL spec, General

      DESCRIPTION: SCA conversation mechanism primarily deals with
      correlations at the transport/messaging level not at an
      application/component level. Currently, there is no mechanism to
      handle a case where SCA runtime correlates correctly but BPEL
      correlation fails.

      PROPOSAL: none


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