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: 

  
"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. 

  

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

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

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: 

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

  
If
the message is sent through a request-response operation,
"sca:DeadLetterMessageError"
fault SHOULD be replied 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, this error situation MAY be notified to the
message sender,
according
to the protocol used. 

If the message endpoint address of a business
process leverages or participates a (transport or above transport
level) protocol that has a timeout or expiration duration value
specified, and if no IMA can be matched with the inbound message within
the timeout / expiration duration, then:

  
If the message is sent through a
request-response operation, "sca:DeadLetterMessageError"
fault MAY be replied 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, this error situation
MAY be notified to the message sender,
according
to the protocol used. 

    

For example, if a
message is sent through a request-response operation and HTTP is used as a
transport protocol with the timeout duration set as 60 seconds, and if
SCA/BPEL infrastructure can determine ino IMA can be matched within 60
seconds, a SCA+BPEL infrastructure might reply "sca:DeadLetterMessageError"
fault as the response to pre-empt the transport level timeout error. 

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

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