[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bpel] Issue 3 - An amended proposal (take 2) - CorrelationDisagreement between SCA and BPEL proposal
Hi all, Here is an amended proposal (take 2) for this Issue 3. Let me repeat a few points here:
My proposal is to add both parts into the spec text: The background text will be added as a non-normative appendix titled: "Background about Dead Letter Messages in BPEL: (Non-normative)" ------------------------------------ [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:
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 or BPEL infrastructure is able to determine that a message, that has been sent to an endpoint address of a business process, will never be matched with a corresponding inbound message activity (IMA) (i.e. receive, onMessage or onEvent), then:
------------------------------------ Besides using the "never" wording suggested by Michael Rowley, there are some minor fine tuning of wordings in the first half of the normative text. The second half of the normative text is newly added. The logic and style are very similar to the first half. It is explicitly targeting the "protocol time out" situation that Danny mentioned in the last email. If people do NOT want the spec to deal with "protocol time out" situation explicitly, I am OK to remove it. Thanks! Regards, Alex Yiu |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]