Re: Different Levels of Reliable Messaging

Ricky:

This is a subject which OASIS and UN/CEFACT addressed within a service
level agreement called a CPA.  When two trading partners decide to
engage in a business collaboration, they make the Collaboration Protocol
Agreement (CPA) which stipulates the complete gamut of possibilities
that could ever be encountered.  This makes the reliable messaging
component of the stack a lot easier to understand and operate.  In
effect,  when a CPA is used to configure a business collaboration,  you
set values in the CPA to reflect what actions will be taken and how many
times you keep trying until a time out occurs.  There is also an
agreement, if a Business Process Specification Schema is used, to what
state both parties will roll back to if something does fail.

If the conditions in your phase 1 (below) happened,  the
messaging/service layer of the sender would send an event up the stack
saying "I sent this message several times but did not get an ACK back". 
The upper layers would parse the event, then check the CPA to see what
should happen.  In a particular instance, it may say "try to send the
message 3 more times, upon which if no ACK is received,  both parties
have agreed that this constitues a failure of the business collaboration
and agree to roll back to a previous state."  There are values one can
set for timeouts, retries, time to perform etc.

Getting back to the thought of using the ebXML messaging for web
services,  this would automatically give the web services access to this
service level agreement since every message that is sent or received
must assert or contain an assertation that it exists as part of a
specific CPA instance.  Within that CPA instance, it is also possible to
have several "threads" running so there is also a "ConversationID"
attribute.

WSDL could use this mechanism (the CPA) today since the authors of the
CPA spec were careful enough to beleive that the CPA may be used in
conjunction with WSDL.  Dale Moberg of Cyclone Commerce is somewhat of
an expert on this subject and has given it a lot of thought.  He may be
the guy to solicit comments from on this.

IMHO - Reliable messaging is only useful when there is a way to map the
events associated with events and exceptions back to the requirements of
businesses.

Hope any of this was useful/interesting..

Duane Nickull

References:

CPA - http://www.oasis-open.org/committees/ebxml-cppa/
BPSS - http://www.unece.org/cefact/ebxml/Documents/ebBPSS1.05.pdf.zip

An expanded illustration of how this all fits together is in the
UN/CEFACT Architecture document - 
current revision v 0.83 - via the TMG File Sharing 
Site (http://homepage.mac.com/knaujok/TMG_Files/) under the 
"General->For Review Folder". The file name is "eBA-TS_V0pt83.zip".


Ricky Ho wrote:
> 
> There are 2 phases
> 
> Phase - 1) The sender send its first message, keep resending until an
> ACK is received, or when the timeout is reached and the sender give up
> resend
> 
> By the end of this phase, the sender can only draw the following
> conclusion
> 1a) The message is "delivered" -- when an ACK is received
> 1b) The message is "in-doubt" -- when no ACK is received
> 
> Note: I don't think the sender can draw conclusion that the message is
> undelivered within this phase.
> 
> Phase - 2) The sender already given up the resend.  Now the sender
> want to find out the delivery status.  Sender keep sending a query
> until it answer "YES" or "NO"
> 
> By the end of this phase, the sender can only draw the following
> conclusion
> 2a) The message is "delivered" -- when an "YES" is received
> 2b) The message is "undelivered" -- when an "NO" is received
> 2c) The message is "in-doubt" -- when no response of the query is
> received
> 
> I still fail to see how the time expiry play a role here to make
> drawing the conclusion easier.
> ...<SNIP>

Received on Tuesday, 17 December 2002 13:57:37 UTC