[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
SCA-BPEL.
Kind Regards
DK
Alex Yiu
<alex.yiu@oracle.
com> To
Najeeb Andrabi <nandrabi@tibco.com>
27.09.2007 04:40 cc
sca-bpel@lists.oasis-open.org,
Danny van der Rijn
<dannyv@tibco.com>,
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
(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”
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; [email protected]
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]
