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