Re: [business-transaction] Regarding issue #89

[Mark Little <mark_little@hp.com>]

Title: Message

 

----- Original Message -----

From: Peter Furniss

To: WEBBER,JIM (HP-UnitedKingdom,ex1) ; business-transaction@lists.oasis-open.org

Sent: Wednesday, April 24, 2002 2:35 PM

Subject: RE: [business-transaction] Regarding issue #89

I think this issue comes in at two levels - a scope/procedure/timing issue,  and a technical/content/detail one. However, they aren't entirely separable.

 

The technical content of what is proposed can be described in the diagram attached. The existing actors are already well defined. All that is proposed is that we define an xml representation of the state of a transaction node, in their five flavours. How that serialisation is invoked, or how the xml format is reincarnated to be active or how the serialised state is passed around or stored or how multiple nodes are presented or transferred are not proposed at this stage.  It could be that those are never defined in a btp spec, but some other specification details with the requesting, transfer and reincarnation of entities whose state can be represented as xml - in which case that document would reference this schema as how to represent btp actors that were involved. Or future btp work might cover this (for a different use case), which might mean there were new roles - but even they would be kind of sideways to the existing ones.

 

In fact, re-reading Sazi's paragraph, it answers its own question: " there is nothing to do other than agreeing on a form that we think that a BTP system will externalize its state". That is precisely what we are talking about.

 

There are some detailed questions about the content of the xml document itself - where implementation or application specific information is included; whether the serialisation declares its position in the tree explicitly (e.g. with a role type element) or if it is implicit in whether superior and inferior relationships exist. But the semantic content is well understood - and has been for a very long time, since it's essentially the same for any 2pc transaction node (at least for presume-abort).

 

Whether we end up with exactly the best xml definition for this isn't certain, but then the same applies to all the rest of the protocol. I think we generally expect that 1.0 won't be the final word. Including a serialisation format now means that stands a chance of getting tested along with everything else.

So you are advocating that we add things into the specification that we know are incomplete simply for users to test? We certainly wouldn't be the first specification body to do that, but that doesn't mean we have to! We have spent a long time on most (all?) of the minutae within the specification to at least see that it fits into the whole picture we've been trying to aim at. Now you appear to be saying we can add things just to see how they work in practice (or more accurately how they hold up) or as place holders for things that may or may not occur later. If that is the case then I would suggest we extend the deadline for the 1.0 and let all committee members go back to their respective implementers and ask them what features they'd like hooks for in the spec.

 

Mark.

 

----------------------------------------------
Dr. Mark Little (mark_little@hp.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2606216
Fax   +44 191 2606250