I think that fixing the dead letter message situation would only be a
solution to this issue. It would imply that SCA level conversation went
but the component level conversation failed. In my view one solution to
problem would be for SCA to combine these two correlation mechanisms.
So if the
BPEL correlation fails the SCA runtime still throws
fault wrapping the bpel:correlationViolation fault.
(explicitly cc'ing Danny as well)
I think your email explanation fits my guess on what you are worrying
Here is my understanding on how WS-BPEL 2.0 spec (not SCA-BPEL spec)
let me re-elaborate the situation with my own wordings to make sure we
are on the same page:
infrastructure dispatchs a message to a BPEL process by some sort of
machine-generated ID (similar to GUID)
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
- 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".
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.
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.
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.
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. :-)
Najeeb Andrabi wrote:
Sorry could not get back to you earlier. I have done a quick write up
correlation disagreement issue.
Disagreement between SCA and BPEL
SCA defines conversational
interfaces at binding level
and not at an application level. This approach can result in ambiguous
as the two correlation mechanisms are mutually exclusive. To illustrate
let use consider a long running Loan Approval SCA composite application
implemented using BPEL component
Check Response& nbsp;
SOAP/HTTP with Correlation Id
client make two
asynchronous web services (submit request and check response) calls
over HTTP. These two web service calls take part in SCA container
conversation. The SCA container correlates based on a correlation id
generates as a response for the submit request web service call.
. The interface used by the
Loan Approval process is
<portType name =”LoanService”
<operation name = “submitRequest”>
<input message = “tns:submitRequestRequest”/>
<output message = “tns: submitRequestResponse”/>
<operation name = “checkResponse” sca:endsConversation=”true”>
message = “tns:checkResponseRequest”/>
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
and orderDate properties; there is a possibility for ambiguous behavior
SCA container could correlate correctly while the BPEL container fails
correlate correctly and sends a correlation violation exception back to
<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"
Could you elaborate your concern with a more concrete example?
elaborate what you mean by "BPEL correlation fails"?
Najeeb Andrabi wrote:
TARGET: SCA C+I
conversation mechanism primarily deals with correlations at the
transport/messaging level not at an application/component level.
there is no mechanism to handle a case where SCA runtime correlates
but BPEL correlation fails.