[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Correlation Disagreement between SCA and BPEL proposal
Correlation Disagreement between SCA and BPEL
SCA defines conversational interfaces at messaging/binding level and not at an application level. This approach can result in ambiguous behavior as the two correlation mechanisms are mutually exclusive. In context with SCA and BPEL, this ambiguity arises due to the decoupling of SCA conversation and BPEL correlation mechanisms. It implies that if the SCA is able to correlate the BPEL correlation can still fail.
To illustrate this, let use consider a long running Loan Approval SCA composite application that is implemented using BPEL component.
The client make two asynchronous web services (submit request and check response) calls using SOAP over JMS. These two web service calls take part in SCA container based conversation. The SCA container correlates based on a JMS correlation id that it generates on receipt of 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 name = “checkResponse” sca:endsConversation=”true”>
<input message = “tns:checkResponseRequest”/>
<output message = “tns:checkResponseResponse”/>
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 based on the JMS correlation id, while the BPEL container fails to correlate correctly if the order number and order date don’t match the correlation id in the correlation set.
<correlationSet name=”LoanRequest” properties=”orderNumber orderdate”/>
<Receive name="Submit Request Receive"
<correlation set="LoanRequest" initiate="yes" pattern="in"/>
<Reply name="Submit Request Reply"
<Receive name="Check Response Receive "
<Reply name=" Check Response Reply"
A sca:correlationViolation exception wrapping a bpel:correlationViolation should be thrown if SCA conversation mechanism is able to correlate while the BPEL correlation mechanism fails. BPEL 2.0 specification does not mandate throwing of bpel:correlationViolation fault on correlation mismatch. So, timeout exception should be wrapped instead.
A recommendation should be made to BPEL specification committee to fix this issue in next version of BPEL. As not notifying web services clients or BPEL processes acting as clients about correlation mismatch results in poor fault handling and unnecessary use of resources (holding sockets connections, dead process instance data etc).
Algorithm for determining correlation mismatch could be something like this:
Throwing a bpel:correlationViolation on a correlation mismatch would be applicable to both synchronous and asynchronous calls. In both cases a bpel:correlationViolation fault must be sent back to the client on the same partner link.