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. Key point : Complex supply chains "hinder" visability
of transactions boundaries - one traverses complex supply chains by "passing"
transaction contol from one TM to another. 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>
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>
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
|