Alex,

Thanks for the background material. I also the proposed normative text, except for the reference to “a dead letter message”, without having a definition for that in our spec. I also thought that “message receiver” might be too vague. Perhaps the first sentence, which you had as:

“If the SCA and BPEL infrastructure of the message receiver is able to detect a dead letter message:”

could instead read:

“If the SCA or BPEL infrastructure is able to determine that a message that has been sent to an endpoint address of a business process will never match a corresponding inbound message activity (i.e. receive, onMessage or onEvent), then:

Michael

From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Thursday, November 01, 2007 12:34 PM
To: Najeeb Andrabi
Cc: sca-bpel@lists.oasis-open.org; ALEX.YIU@oracle.com
Subject: Re: [sca-bpel] Issue 3 - An amended proposal - Correlation Disagreement between SCA and BPEL proposal

Hi all,

Here is an amended proposal for this Issue 3.

I believe the spirit of the proposal is the same. But, wordings and details are different. This amended proposal avoids/addresses a few issues that the original proposal has:

· "bpel:correlationViolation" is for BPEL's CorrelationSet lifecycle violation - not CS mismatch. I am not sure we want to overload it. All existing "bpel:*" fault thrown are for internally consumption only. Not directly visible through BPEL partnerLink.

· There is no formal notion of "wrapping" in WS fault.

· We need to address the difference in one-way or request-response MEP.

· The flow chart has "wait until all the IMA in all existing processes have been activated". That seems to be not so feasible / well-fit.

The proposal has two parts: background (non-normative) text and normative text.

If the background text is too long for some audience, I am happy to trim and para-phrase it. I send this longer version for the benefit for the TC discussion.

About the normative text, I hope it is short yet concise.
One thing to highlight is: it may be infeasible to specify a universal dead letter detection algorithm, which has real values to users. Hence, I am using SHOULD and MAY here, instead of MUST.

------------------------------------
[background text begins here ...]
When an inbound message comes into the SCA and BPEL infrastructure, such a message is normally consumed by a matching inbound message activity (IMA)(e.g. a <receive> activity). However, due to process model error or runtime message data error, there is no matching IMA at all or a matching IMA is not enabled within the expected time limit of the (system/business level) protocol between the message sender and receiver. This kind of messages, which do not have a matching IMA, are termed as "dead message messages"

Examples of process model error are:

· matching IMAs are skipped by faults

· matching IMAs blocked by other activities within a sequence or an impossible-to-fulfill control link transition condition.

· IMAs cannot receive message due to incorrect usage of message correlation mechanism, including BPEL correlation set and SCA conversational interface

Examples of runtime message data error are similar to above, as the above error are not inside the process definition itself but caused by incorrect data values.

There might not be a universal way to determine a message is truly a "dead letter message" without any additional protocol between message senders and receivers. Consider the following example, an message is dispatched to a BPEL process instance by SCA conversational mechanism. At the moment when the message is matched with the BPEL process instance, there might be no <receive> activity enabled for the matching partnerLink and operation at all, or there is a <receive> activity enabled for the matching partnerLink and operation but with a mismatched correlation set. Some users might think this is certainly a dead letter message situation. However, a matching IMA may be enabled minutes, hours, or days later, as the matching IMA might be blocked in the process model.

On the other hand, there might be some cases that the BPEL infrastructure can determine there will never be a matching IMA enable in future. And, some advanced features in BPEL infrastructure (e.g. process instance repair or process definition repair) might make the detection of "dead letter message" cases more difficult. However, with some additional system-level protocol coordination between the message sender and receiver, it might make detection easier.
------------------------------------

------------------------------------
[normative text begins here ...]
If the SCA and BPEL infrastructure of the message receiver is able to detect a dead letter message:

· If the message is sent through a request-response operation, "sca:DeadLetterMessageError" fault SHOULD be thrown to the message sender

· If the message is sent through a one-way operation and additional system-level protocol is used between the message sender and receiver, the dead letter message error situation MAY be notified to the message sender, according to the protocol used.

------------------------------------

Looking forward to further comments and fine-tuning.

Thanks!

Regards,
Alex Yiu

Najeeb Andrabi wrote:

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.

Client

Loan Approval BPEL Process

Submit Request

SOAP/JMS

Correlation Id

Check Response SOAP/JMS with Correlation Id

Check Response Reply

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:

</operation>

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

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

Message

Can create new process instance

Create new instance of the process

Correlate with existing processes? (Wait until all the IMA (Inbound message activities) in all existing processes have been activated)

Yes

Cannot Correlate

Throw bpel:correlationViolationException

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.

sca-bpel message

Correlation Disagreement between SCA and BPEL

Background

Proposal