OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-bpel] Issue 3 - An amended proposal - Correlation Disagreementbetween SCA and BPEL proposal


Alex, Mike E, Mike R, Najeeb,

I assume we agree that we want to allow a BPEL implementation to store a
message if it can be consumed by a process instance at a later point in
time. Do we want to make this explicit in the normative language? (Of
course, it cannot be decided in many cases, and additional considerations
apply - e.g., it makes a lot of sense for one-way messages and it makes
less sense for request-response operations called via synchronous bindings
[<- btw, this is another scenario for issue BPEL-12]).

For those cases where we finally decide to return an
"sca:DeadLetterMessageError" fault to the sender, I have additional
questions:
 - in case of request-response operations, would this fault manifest itself
as an SCA ServiceRuntimeException?
 - in case of one-way operations, will SCA (the assembly spec?) define the
coordination protocol messages?

Kind Regards
DK



                                                                                                               
  From:       Mike Edwards <mike_edwards@uk.ibm.com>                                                           
                                                                                                               
  To:         sca-bpel@lists.oasis-open.org                                                                    
                                                                                                               
  Cc:         Najeeb Andrabi <nandrabi@tibco.com>, alex.yiu@oracle.com                                         
                                                                                                               
  Date:       06.11.2007 09:46                                                                                 
                                                                                                               
  Subject:    Re: [sca-bpel] Issue 3 - An amended proposal - Correlation Disagreement between SCA and BPEL     
              proposal                                                                                         
                                                                                                               






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

                                                                           
 Alex Yiu                                                                  
 <alex.yiu@oracle.                                                         
 com>                                                                      
                                                                        To 
                          Michael Rowley <mrowley@bea.com>                 
 05/11/2007 19:23                                                       cc 
                          Najeeb Andrabi <nandrabi@tibco.com>,             
                          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, 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










[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]