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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[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