[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#8] Tentative resolution of: Look at work of BT Pwith regards to 2-phase commit and its viability
If nobody objects I'll mark the issue as "Resolved" within one week. The resolution is a join of the two emails below: "Closed as not relevant due to the use of the BTP protocol being out-of scope for the WSRP/WSIA protocol and the conceptual mapping of the protocols onto each other fails due to the differences in the nature of the interactions and the number of parties involved. Also - change the WSRP spec should call it a two-step instead of a two-phase protocol. To many people, a two-phase process includes the ability to "rollback" after the 1st phase. In our specification, the 2nd step is needed to see the results of the 1st step. But, whatever the 1st step does is already a "done deal" before the 2nd step is called. In addition, it appears that you can perform many 1st steps (performInteractions) without ever performing a 2nd step (getMarkup) and visa-versa. This is different than most two-phase processes which require the 2nd phase corresponding to the 1st phase to be invoked every time you want something to "take" (commit)." Yours, Gil -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Wed, October 02, 2002 17:35 To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#8] Tentative resolution of: Look at work of BT P with regards to 2-phase commit and its viability Good point, I think your proposed change adds clarity. I'll add it to the Editorial work list. Rudnicki Joseph G CONT NSSC To: Rich Thompson/Watson/IBM@IBMUS, <RudnickiJG@NAVSE wsrp-wsia@lists.oasis-open.org A.NAVY.MIL> cc: Subject: RE: [wsrp-wsia] [I#8] Tentative resolution of: Look at 10/02/2002 10:14 work of BT P with regards to 2-phase commit and its AM viability Hello, I think that the WSRP spec should call it a two-step instead of a two-phase protocol. To many people, a two-phase process includes the ability to "rollback" after the 1st phase. In our specification, the 2nd step is needed to see the results of the 1st step. But, whatever the 1st step does is already a "done deal" before the 2nd step is called. In addition, it appears that you can perform many 1st steps (performInteractions) without ever performing a 2nd step (getMarkup) and visa-versa. This is different than most two-phase processes which require the 2nd phase corresponding to the 1st phase to be invoked every time you want something to "take" (commit). FWIW. Take care. Joe Rudnicki -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Wednesday, October 02, 2002 9:54 AM To: wsrp-wsia@lists.oasis-open.org Subject: [wsrp-wsia] [I#8] Tentative resolution of: Look at work of BTP with regards to 2-phase commit and its viability I looked at the BTP committee specification. It defines a protocol for business to business transaction. BTP defines that interactions happen in a 2-phase manner. The first of these is an exchange of messages that determine the characteristics and performance of a "Provisional Effect". The second then causes the finalization (either Confirm or Cancel) of the Effect. In essence the protocol inherently is a 2-phase commit. In thinking how this might (or might not) map onto the joint spec, be aware that BTP is a protocol for multi party collaboration to conduct a business transaction while WSRP/WSIA is a 2 party system for preparing, delivering and processing interactions with an entity's presentation. As such, requiring that all "transactions" (if mapped to performInteraction invocations) have a 2-phase commit structure seems too heavy weight. This is especially true since those invocations result from End-User interacting with the entity's presentation rather than the arbitrary invocations BTP had to deal with. Conceptually mapping BTP's first phase onto a performInteraction() causing a state change and then the second phase to getMarkup() causing this state change to be visible to the End-User almost works. The difference is that there is no capability to Cancel the state change and therefore it is not truly a preliminary change. The other potential mapping of the BTP protocol is that an entity uses it to actually perform work as a result of a performInteraction() invocation. Nothing in our protocol prohibits (or encourages) this as basically it is in the scope of how a particular entity performs work and therefore out-of-scope for our protocol. As a result of this analysis, I propose the following resolution of this issue: Proposed Resolution: Closed as not relevant due to the use of the BTP protocol being out-of scope for the WSRP/WSIA protocol and the conceptual mapping of the protocols onto each other fails due to the differences in the nature of the interactions and the number of parties involved. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC