Mike E,
Your suggestion/amendment is perfectly fine with me. The additional
words in parentheses in my previous email also made me worry a bit.
Here is the consolidated amended normative part of the text.
------------------------------------
[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, can
not be matched with a corresponding inbound message activity (i.e.
receive, onMessage or onEvent), then:
·
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.
------------------------------------
Since we are dropping those wording in parentheses, I think
there is now even a stronger need to add the non-normative part of the
proposed text to the spec to give readers the proper context on how
messages might be matched with an IMA in a BPEL process. (Particularly
to address Dieter's concern expressed in another email of his).
So far, I have not heard any suggested amendment of the non-normative
text. I guess I can assume people are OK with most of its content?
Thanks!
Regards,
Alex Yiu
Mike Edwards wrote:
OFC01488DA.719259D0-ON8025738B.002F8631-8025738B.00301B1F@uk.ibm.com"
type="cite">
Alex,
I agree with your point about
"never",
but I don't like your additional words in parentheses at all. The
extra qualifiication just complicates things needlessly
- let us leave it to the SCA &
BPEL
infrastructure to work out whether matching can be done. I changed
"will" to "can" as well, to get rid of this flavour
of
"future-ness" in the wording
which is not appropriate, since this statement is about a state and
what
to do when this state is detected.
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, can not be matched with a corresponding
inbound message activity (i.e. receive, onMessage or onEvent), then:"
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
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: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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with
number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
|