Hi DK,
Thanks for chiming in this discussion.
Among cases of "zero/one/multiple matching process instance(s)":
For multiple message process instances, I guess that it is covered by bpel:conflictReceive fault already. I believe a conflictReceive fault will happen EITHER at the time of IMA (inbound message activity, e.g. <receive>) got executed/enabled OR at the time arrival of a message that matches multiple IMAs. (The latter case was actually suggested by you in a later stage of spec discussion, if my memory is correct.)
I guess only the "zero" case is unspecified in BPEL 2.0 spec, which I term it as "dead letter message" case or undelivered message case.
I am not against talking about the possibility of "dead letter message" case in SCA-BPEL. Just our hands may be still somewhat tied here. My concerns (summarized here again) are:
- The proposed behavior to deal with "dead letter message" should
be identical whether SCA conversation is used or not. Because, we can
have "dead letter message" situation even without SCA conversation.
- We need to define a way to detect this "dead letter message"
situation. Considering the racing condition between message and a
(future) matched IMA, timeout-based mechanism is the only generic way
to detect the "dead letter" (that I can think of so far).
- Without referring to a specific conversation mechansim (e.g. WS-Addr, WS-Coordination, WS-BusinessActivity), it may be difficult to define an across-the-board mechanism:
- to notify the sender of the dead letter
- or to allow the sender to specific the timeout condition that a
message is considered a dead letter (if we choose to use timeout based
detection method)
- And, we don't want to fault the BPEL process itself
indiscriminately. Because, the correlation in the BPEL process instance
may be right and the sender may be the one that makes mistake in the
message. It should be up to the BPEL process designer to decide this.
Thanks!
Regards,
Alex Yiu
Dieter Koenig1 wrote:
OF2263AD53.35070588-ONC1257363.00511C26-C1257363.0051FD2B@de.ibm.com" type="cite">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: pic26675.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
