[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [bt-spec] FW: Issue 89
Hi Jim, As this is a constructive request from yourself (HP) I am happy to elaborate elaborate. Considering that the BTP contains a huge amount of TP Gurus this should make sense .. I hope ;-) The issue : ----------- It is very attractive to gain "peer" level inter operability with the BTP TM, by "peer" level inter operability I mean the ability of a non-BTP TM to collect the state ( on demand ) and therefore continue execution within a traditional TP infrastructure. A natural by-product of this approach is that it provides much greater levels of HA. Where this comes from : ------------------------- My experience with integrating transactional application and navigating supply chains ( i.e. vendors apps et al ) is that one has to "patch" together transactional state across TPMs. This is a well known problem that many SIs face, due to limitations with TP monitors this is usually addressed by asynchronous messaging. Ironically this is exactly why TP monitors can not be used across the web today ; I architected Oracle's Message Broker for this very reason. Summary : ----------- This is not rocket science .. this is common sense. Bindings allow "client-server" inter operability only. Let me be clear that bindings are needed but I feel they do not address the aforementioned problem .. *IF* the BTP committee want a truly *OPEN* transaction infrastructure then this proposal addresses the problem. Again I propose this approach as an "optional" part of the BTP spec - for large scale complex transactional infrastructures. The BTP TM should only render its current state in XML on DEMAND and not for every single operation. If there are any constructive alternatives please let me know as I will be very happy to apply these to the real-world problems that the industry faces. Geoff. "WEBBER,JIM (HP-UnitedKingdom,ex1)" wrote: > Hi everyone, > > I've just read Geoff's document and Mark's comments. Now I am perfectly > willing to accept that I might be being naïve here, but could someone please > clarify for me what precisely the benefits of sharing state in a common > format are? I can well enough see the drawbacks for myself, but I am rather > finding the benefits difficult to quantify. > > I don't have an objection to J2EE (or any other platform for that matter) > interop with BTP, but does sharing of state (as opposed to say defining > standard bindings at the message level) really achieve that objective in a > straightfoward way? > > Again, this isn't a rebuttal to the Oracle/Choreology suggestion, more of a > plea for help in understanding its value. > > Ta. > > Jim > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
Attachment:
Geoffrey.Brown.vcf
Description: Card for Geoffrey Brown
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC