Re: [bt-spec] FW: Issue 89

Geoff, removing all text from previous emails in order to make an implementation suggestion: if I have read your requirement correctly then what you want to do is basically have multiple TMs shadow each other (you have talked about 2 TMs, but I don't see why it couldn't be extended to more than that to improve availability.) If that is the case then rather than have one TM send its state to another (which I'm still dubious about for security reasons at the very least), how about the following:

As with CORBA OTS and even JTA, BTP basically hides implementations behind interfaces (OK, BTP doesn't actually get as high up the stack as an interface, but there's an implicit subtext that shows that the users of the message sets could very well be hidden behind some additional level of indirection). [And Web Services do this for us as well.] So, if that's the case, a user of a coordinator (or factory in the case of BTP) doesn't see what's behind that interface. It could be a single coordinator, or it could have some additional intelligence that farms incoming requests out to multiple (possibly different vendor) coordinators. In that way, an ENROL message (for example) is, as far as a participant is concerned, received by a coordinator, but behind the scenes it is actually distributed to, say, 2 different coordinators, one of which will act as the master and the other will act as the backup in the event of a failure. This happens transparently, doesn't require any state transfer (i.e., no modification to BTP) and works completely within the security model (or lackthereof) that BTP assumes. As a vendor, it is then up to the provider of this coordinator-farmer, to ensure that the coordinator services that are farmed out to are secure and in line with whatever security model the vendor provides to users or that users require. In addition, this is a recursive structure, since I'd assume that this coordinator-farmer could talk to its coordinators using BTP messages and they may appear to it as coordinators, but may in fact be other farms. Obviously, for performance reasons another vendor may decide to use some proprietary means of distributing the BTP requests, but that's hidden behind this farm interface and does not impact the user at all.

This would appear to give you the ability that you require. In addition, the amount of intelligence at the farm site could be down to the vendor. For example, you might not want to do this level of farming for Joe Bloggs service since he didn't pay you for it, but for XYZ Corporation you might.

There are obviously lots of ways in which this approach could be extended and if you want me to go into more detail please ask. The important point that I want to stress again, is that this approach does not require any modification to the current BTP specification. (And it's based on previous implementation experience.)

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax : +44 191 2606250

bt-spec message