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

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [business-transaction] Regarding issue #89



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