Hi, Michael,
Thanks for the quick feedback.
I agree with you that the "if" condition in the normative text can be
tightened up. I like your changes in general.
I am wondering whether the word "never" may be a bit too strong. I am
thinking to use the word with a weaker tone with extra qualification
description.
How about:
“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 not be matched with a
corresponding inbound message activity (i.e. receive, onMessage or
onEvent) (possibly based on a message protocol or some
infrastructure heuristic), then:"
If the extra qualification description "(possibly based on a message
protocol or some infrastructure heuristic)" opens new cans of worms, I
am comfortable to drop it.
Thanks!
Regards,
Alex Yiu
Michael Rowley wrote:
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:]
Sent: Thursday,
November 01, 2007
12:34 PM
To: Najeeb Andrabi
Cc:
;
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
