- From: Ricky Ho <riho@cisco.com>
- Date: Mon, 30 Dec 2002 09:30:45 -0800
- 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 UTC