W3C home > Mailing lists > Public > www-ws-arch@w3.org > December 2002

BTP without RM scenario

From: Ricky Ho <riho@cisco.com>
Date: Mon, 30 Dec 2002 09:30:45 -0800
Message-Id: <4.3.2.7.2.20021230090754.026ab198@franklin.cisco.com>
To: "Mark Potts" <mark.potts@talkingblocks.com>, "Patil, Sanjaykumar" <sanjay.patil@iona.com>
Cc: "Www-Ws-Arch" <www-ws-arch@w3.org>

Under "BTP without RM" situation, lets assume the following happen.

1) Client initiate a BTP atom transaction
2) Client send a messageA to invoke operationA of Server
3) Client send a messageB to invoke operationB of Server (this message is 
lost !)
4) Client commit the transaction

Let me skip the early part of underlying BTP interaction (e.g. obtain 
transaction id, enroll participant ... etc.) and jump to step (4) ...

4.1) Client send a "commit" to the co-ordinator (while thinking he is 
asking for completion of operationA and B)
4.2) Co-ordinator send a "prepare" to Server
4.3) Server respond a "perpared" to Co-ordinator (while thinking he is 
being asked for completion of operationA ONLY)
4.4) Co-ordinator continue to commit the transaction successfully

BTP provides a 2-phase interaction protocol, but BTP doesn't address 
"Prepare for What ??", or "Commit what ??"  BTP assumes the "application 
state" has been exchanged reliably between the client and server.  And 
without RM, such guarantee is NOT POSSIBLE or have to be done at the 
application level.

This seems to be more than just a protocol efficiency issue.

Rgds, Ricky
Received on Monday, 30 December 2002 12:31:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:11 GMT