[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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.)
Mark.
----------------------------------------------
Dr. Mark Little, Distinguished Engineer, Transactions Architect, HP Arjuna Labs Email: mark_little@hp.com Phone: +44 191 2606216 Fax : +44 191 2606250 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC