[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [bt-spec] FW: Issue 89
> 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. So you want to export a BTP TM state and import it to, say, CICS? > A natural by-product of this approach is that it provides much greater levels of > HA. If this is why you would want to do this then we should look at HA techniques in general. If it's for "interoperability" then that's something else entirely. > > 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. What do you mean by "transactional state"? Do you mean tracking down where the context flows to? What the format of the context is? Do you have a worked use case on this? > > 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. Sorry, but we still don't get it. This definitely makes BTP more "open", but that's a bit like saying that in order to make operating systems open lets remove all security restrictions and give everyone root access: it's possible but why would we want to do that? BTP is "open" in the traditional sense of the word (the sense that, say, the OMG would use, or the OSF would use). This keeps boiling down to us not seeing the use case for it. And that's not to say that there isn't one, just that we can't see it. So, if there is such a beast, please show it in detail so we can examine the protocol implications. Simply saying that BTP isn't "open" without it isn't sufficient I'm afraid. > Again I propose this approach as an "optional" part of the BTP spec - for large > scale complex transactional infrastructures. So why can't we leave this as deferred, discuss it in a lot more detail (I think it requires it) and then add it to the 1.1 version if we as a committe agree it's good? > The BTP TM should only render its > current state in XML on DEMAND and not for every single operation. And what about the security implications? As I said in the previous email: please answer the questions in the marked-up Word document. We can only have an informed discussion if *both* parties engage in it! > > If there are any constructive alternatives Lots if you're just after HA (see email of about 3 weeks ago that you didn't respond to either). As for alternatives for other requirements - it's difficult to say since we still don't understand why you need this. > please let me know as I will be very > happy to apply these to the real-world problems that the industry faces. > > Geoff. Mark. ---------------------------------------------- Dr. Mark Little, Distinguished Engineer, Transactions Architect, HP Arjuna Labs Email: mark_little@hp.com Phone: +44 191 2606216 Fax : +44 191 2606250 > > > "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> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC