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 and BPEL


 

Hi Alex,

  • "throws sca:correlationViolation fault" ... throw a fault to where? ... caller? (if caller, how?) or the BPEL process itself? Please consider the bullets in the email that I sent a moment ago (around 12:54 pm PT).

        In case of synchronized call just send the fault back on the transport thread. In case of async operation we can send the fault back using the SCA level conversation id.

 

Thanks,

Najeeb

 

 


From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Thursday, September 27, 2007 1:06 PM
To: Najeeb Andrabi
Cc: sca-bpel@lists.oasis-open.org; Danny van der Rijn; ALEX.YIU@oracle.com
Subject: Re: [sca-bpel] NEW ISSUE: Title: Correlation disagreement between SCA and BPEL

 


Hi Najeeb,

  • "if the BPEL correlation fails" ... please consider the racing condition between the arrival of a message which mismatches a current receive and enabling a future matched <receive> - detection/definition of BPEL correlation failure is not as easy as one may think
  • "throws sca:correlationViolation fault" ... throw a fault to where? ... caller? (if caller, how?) or the BPEL process itself? Please consider the bullets in the email that I sent a moment ago (around 12:54 pm PT).


Thanks!

Regards,
Alex Yiu


Najeeb Andrabi wrote:

 

  Hi Alex,

              I think that fixing the dead letter message situation would only be a partial solution to this issue. It would imply that SCA level conversation went fine but the component level conversation failed. In my view one solution to this problem would be for SCA to combine these two correlation mechanisms. So if the BPEL correlation fails the SCA runtime still throws sca:correlationViolation fault wrapping the bpel:correlationViolation fault.

 

Thanks,

Najeeb

 


From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Wednesday, September 26, 2007 7:40 PM
To: Najeeb Andrabi
Cc: sca-bpel@lists.oasis-open.org; Danny van der Rijn; ALEX.YIU@oracle.com
Subject: 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 situation".
  • 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" state.
  • 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. :-)



Regards,
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.

Thanks,

 Najeeb

 

 

 

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

 

 

 

 

 

 Client

 

 

 

 

Loan Approval BPEL Process

Submit Request

SOAP/HTTP

Correlation Id

Check Response& nbsp;  Request  SOAP/HTTP with Correlation Id

 

Check Response Response

           

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” sca:requires=”conversational”>

                 <operation name = “submitRequest”>

                                   <input message = “tns:submitRequestRequest”/>

                                   <output message = “tns: submitRequestResponse”/>

                  </operation>

                  <operation name = “checkResponse” sca:endsConversation=”true”>

                                   <input message = “tns:checkResponseRequest”/>

                                   <output message = “tns:checkResponseResponse”/>

                  </operation>

            </portType>

 

 

  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 client.

 
<correlationSet name=”LoanRequest” properties=”orderNumber orderdate”/>

 

<process>

         <sequence>

        <sequence>
          <Receive name="Submit Request Receive" 
                 partnerLink="submitRequestPL" 
                  operation="submitRequest" 
                 portType="LoanService" 
                  variable="submitRequestVariable" createInstance="yes">
            <correlations>
              <correlation set="LoanRequest" initiate="yes" pattern="in"/>
            </correlations>
          </Receive> 
          <Reply name="Submit Request Reply" 
                 partnerLink="submitRequestPL" 
                  operation="submitRequest" 
                 portType="LoanService" 
                  variable="submitResponseVariable"/>
        </sequence>
        <sequence>
          <Receive name="Check Response Receive " 
                 partnerLink="checkResponsePL" 
                  operation="checkResponse" 
                 portType="LoanService" 
                  variable="checkResponseRequestVariable" 
                  createInstance="no">
              <correlations>
                 <correlation set="LoanRequest"/>
              </correlations>
          <Reply name=" Check Response Reply" 
                 partnerLink="checkResponsePL" 
                  operation="checkResponse" 
                 portType="LoanService" 
                  variable="checkResponseResponseVariable"/>
        </sequence>
    </sequence>
</process>

 

 


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"?

Thanks!

Regards,
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]