|
----- Original Message -----
Sent: Monday, April 22, 2002 11:38
PM
Subject: Re: [bt-spec] FW: Issue 89
Comments intermixed <gb>
Mark Little wrote:
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:
<gb> Your along the right lines ..
It is more a case of "passing" control rather than "shadowing" which learns
heavily towards HA.
<ml>At this point the issue is only
talking about state serialisation and deserialisation. If you want to open it up
further then please do so. However, unless you do, I still think that this
example solves the current problem.</ml>
Key point : Complex supply chains "hinder"
visability of transactions boundaries - one traverses complex supply chains
by "passing" transaction contol from one TM to another.
<ml>Again, this wrapper technology
would do this since the intelligence about which TM is the controller can be as
complex or as simple as you want. For example, given the location of the sender,
the wrapper could determine that a physically close TM is the master for this
invocation and shadow to the other(s).</ml>
It is possible to have more than 2 TMs,
however in reality I could not think why one would want more than 4 TM's (
this is based on the most complex supply chain interop problem I know / face
</gb>
<ml>Possibly because availability is
not proportional to the number of replicas you have.</ml>
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.
<gb> I do like the ENROL
idea, however this comes across as a Load Balancing solution ( I may
misunderstand your position here ) </gb>
<ml>You could use it as such, since
the intelligence is hidden. However, what I'm trying to show here is that more
than one TM gets the messages transparently and can act on them in such a way
that one of them (call it the master) does all of the work (e.g., sends back an
ENROLLED message) while the other (call it/them the backup(s)) simply change
their state accordingly. If the master goes down, then the backup can come into
play and take over, and this is seamless to participants and other users. As
indicated above, the actual role of master and backup can be selected based on
lots of different criteria (c.f. coordinator-cohort where each client/invocation
could potentially have a different master/backup combination). So we end up with
peer-to-peer shadowing as you wanted.</ml>
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.)
<gb> Your help is appreciated
</gb>
Mark. ----------------------------------------------
Dr. Mark Little, Distinguished
Engineer,
Transactions
Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax : +44 191
2606250
|