[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
Background
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>
<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 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”/> <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>
Proposal
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]