business-transaction message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [business-transaction] Regarding issue #89
- From: Sazi Temel <sazi.temel@bea.com>
- To: business-transaction@lists.oasis-open.org
- Date: Wed, 24 Apr 2002 00:00:25 -0400
Folks,
Regarding issue #89. I am all for exploring this issue, but do not
understand its urgency to include into spec at this time. I have been
reading the e-mails and doc on this issue lately and inclined to go
against including it into the spec for this version, but continue to
explore it as its scope is wider than BTP.
In addition..
a) Agreed with the idea that we should vote
for any issue without having a reasonably good understanding of whether
it makes sense to include into or exclude from the spec. So a vote should
be for a solution, not for a place holder.
c) Externalizing the state so that other systems/protocols can at some
level interoparete with BTP definitely requires more thought on what to
do. I am not concerned on how to at this stage, I think it will require
some changes in the protocol which I think will make the protocol
more complex..
d) It seems to me that the issue is not directly related to the protocol,
but more on the systems (externalizing the state of the system) that make
use of the protocol; Its scope is wider than BTP, involves other
transactional systems/protocols and this needs to be coordinated with
other interested parties as well as parties involved in BTP
effort.
e) I disagree with the idea that this will not have any impact on
protocol as it stands now. How would one externalize the state without
involving the BTP actors? We cannot just say it will not have
impact on BTP. Surely some actors/roles will involve in externalizing
the state and its consistency, perhaps even the participants will
involve... If you can do it without involving the BTP actors and without
changing any aspects of the protocol, then it is clear that the
externalizing state is out of scope of BTP work - there is nothing to do
other than agreeing on a form that we think that a BTP system will
externalize its state. Even if so, I do not see its urgency at this
version of the spec. If there is no impact, and no changes needed,
perhaps I am also missing something here...
f) From my experience with several customer projects using business
transactions, and what I hear from others in the field, is the need for a
simple protocol (in use, in implementing, and in deploying). I know this
(simplification) sounds like a broken record! Including a lot of optional
features makes the protocol, at least look like, a complex one... I do
not see that this (a coordination migration protocol) is a high item in
many enterprise that I know showed some interest in business transaction
protocol, list of features that they expect from the protocol.
e) I don't have a problem with Bill Pope remaining chair on this vote. I
wouldn't bring this, but since Bill mentioned in his e-mail earlier. I
don's see any reason for you (Bill) not to remain chair for this vote.
--Sazi
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC