Re: [bt-spec] FW: Issue 89

[Mark Little <mark_little@hp.com>]

Alastair, yes this was posted to the OTS RTF mailing list a while back. Interesting paper, and in fact the Inria people would like to have done this using the Activity Service. However, as I said in an earlier email: state serialization is not the only issue here. Rather than a "place holder" I'd prefer to see a fully thought out solution to everyone's requirements (if there are any). We don't see people wanting to migrate coordinator state from one implementation to another. This may come, but it hasn't yet. Why add extra complexity to an implementer just because something "may" happen? The BTP specification is already a daunting tome to read. We would prefer to see things done incrementally as and when the need arises. Just because something can be done doesn't mean it has to be done.

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

From: Alastair Green

To: Mark Little

Cc: Geoffrey Brown ; WEBBER,JIM (HP-UnitedKingdom,ex1) ; Bt-Spec

Sent: Friday, April 19, 2002 2:16 PM

Subject: Re: [bt-spec] FW: Issue 89

Dear Mark and others,

You may well have come across this interesting paper from INRIA (attached), which motivates the need for transaction coordination mobility driven by the desire to create client sessions which can migrate from one terminal to another. I think this is relevant to our current discussion.

As I said above, it's interesting from an academic standpoint at the moment.

What slightly surprises me about this discussion is that it should be so controversial to provide an optional externalization format for data which is a simple (and obvious) derivation of the concept of a (sub)decider. The content is old hat. What is novel is the need for it to be available interoperably, and I think BTP could provide a service in this respect.

Great, so let's discuss this as a committee and hear everyone's take on this. We don't see the need today even with the Inria paper, but that's our opinion. However, I don't believe we have talked this through enough and I don't believe we should rush this through the 1.0 spec. Let's make sure we get it right first rather than repent at leisure.

As I understand this from Geoff's verbal motivation at the FTF after the OMG meeting, he sees this as a valuable placeholder for a potentially more involved scheme, where matters such as a transmission sub-protocol might (or might not) be addressed in the future.

As far as specifications go, I don't believe in placeholders. It's either in or it isn't, and it either solves the problem or it doesn't. If you believe that a BTP cohesion coordinator state can be imported to a CICS coordinator (the example Geoff and I used) then I'd be surprised.

I think that the elements such as domain, transport etc are particular to Oracle's target environment, and are therefore proprietary, and should therefore go in the "impl_data" field, or whatever the suggested free space is.

I for one have found this notion a) unaccustomed b) stimulating and c) somewhere between inoffensive and vital (room for vendor variation?).

OK, but we don't. Hence the reason we need to discuss this a lot more before a vote.

 

Mark.

Yours,

Alastair

Mark Little wrote:

Geoff and others, attached is a new marked up version of the document. To make it easier to read, I've put Geoffs comments within <gb></gb> and my subsequent comments within <ml></ml> tags. Mark. -----------------------------------------------------------------------
SENDER : Dr. Mark Little, Architect (Transactions), HP Arjuna Labs
PHONE  : +44 191 206 4538, FAX : +44 191 206 4203
EMAIL  : mark@arjuna.com | mark_little@hp.com