Over the past few years there's been a backlash against application servers (both commercial and open source), with some people saying they're too heavy-weight. I'm not going to get into that argument here, but what does surprise me is the number of open source transaction managers that are trying to differentiate themselves on this very fact, as if it was something new and wonderful. Well guys I hate to break it to you but we, IBM, BEA and a few others have been doing that for years. In the open source arena, JBossTS was the first to run outside of an application server simply because it began life before there was such a thing! We've continued that over the intervening years, but maybe I just need to make it more explicit: JBossTS does not require any application server within which to run. I'm pretty sure I mentioned this before, but it's also highly embeddable, which we have proved time and again (yes, footprint size is very small, but the architecture is designed so that it doesn't require anything from the underlying environment).
Then there are some transaction service implementations (typically open source, but not exclusively) that seem to need to try to differentiate themselves by pouring scorn on transaction standards like OTS/JTS or WS-T: guys, if you have problems with these things then get involved in the process, but don't cry foul because the rest of the industry (and users) have got together to develop them. Oh, and yes while it's true that JBossTS has been at the forefront of these (and other) standards since the start, the architecture is not built on any of them since, once again, with the exception of XA they all came after JBossTS (aka Arjuna) started life.
Now maybe we don't go around "blowing our own trumpet" enough, but I think that's got a lot to do with our background: in academia there's a heavy peer review process that permeates throughout everything you do and unsubstantiated statements quickly become something you avoid like the plague. We've had 20+ years to document what we've done in this way, so everything has been verified and screened for accuracy. Maybe we assume too much that people will check that backlog of information, particularly in this day and age with so many good internet search engines. However, maybe we need to change that and start revisiting our previous publications and discussions more to refresh people's memories.
So if you're a user looking for some or all of the following: power, configurability, performance, openness, pedigree, flexibility, excellent documentation, standards (where necessary), extensibility, embeddability, stand-alone or application server deployment options, continuous vision, knowledge base, 24x7 support, etc. etc., then there really is only one option: JBossTS. TIBCO, webMethods and many others over the past 20+ years have made the JBossTS choice and found it to be the right one.
This is the blog site for the Narayana team. Expect postings on our transaction projects, but also on general transaction issues.
Saturday, November 17, 2007
Thursday, August 30, 2007
Tuesday, July 17, 2007
XTS update
It's nice to see that there are other commercial and OSS vendors looking to provide new implementations of WS-TX. However, it is worth stressing the points I made earlier: not only was XTS the world's first Web Services transactions implementation, but it is the only open source implementation that has been tested for interoperability with IBM, Microsoft and others. So if interoperability with heterogeneous implementations is important to you, come talk to us.
Friday, July 13, 2007
Trying to put JBossTS into perspective: XTS
Up to this point we've covered the core engine component, the local JTA, and then the JTS and remote JTA implementations. That leaves XTS: the Web Services transactions component.
There has been a Web Services transactions component in JBossTS since it's HP days, when it was called HP Web Services Transactions (HP-WST). Once again it was the world's first Web Services transactions product. At that time it was based on the OASIS Business Transactions Protocol (BTP), which didn't get the support of major vendors. Over the intervening years we tracked, authored and influenced BTP, WS-CAF, WS-T and then WS-TX. Each time, we used XTS as the platform for testing these protocols.
Just like the local JTA and JTS implementations, XTS leverages the core engine. It has no dependency on CORBA. It has no dependency on JTA. As well as webMethods, others have used XTS successfully in the past too. Because all of the various Web Services transactions specifications/standards have included support for extended (non-ACID) transactions, XTS is able to exploit yet more of the power of the underlying core engine: the ability to relax all of the ACID properties in a controlled manner. So unlike other vendors, we have the same core engine providing the support for all of the transaction models!
Then of course there's end-to-end transactions (E2EX as we were calling it in HP). We've been talking about transaction bridging for many years and working on one prototype or implementation after another. But the recent work that Jonathan et al have been doing has really pulled everything together into a more coherent approach, at least as far as JEE is concerned.
I could say more about the architecture of all of our components. I could also wax lyrically about recovery or extended transactions. But most of what I'd say is covered by the various hyperlinks I've embedded throughout these entries. So please follow them and read up. If you've got any questions or comments, put them against the relevant entry or post in our forums. But overall, enjoy using JBossTS as much as we've enjoyed developing it over the past 20 years.
There has been a Web Services transactions component in JBossTS since it's HP days, when it was called HP Web Services Transactions (HP-WST). Once again it was the world's first Web Services transactions product. At that time it was based on the OASIS Business Transactions Protocol (BTP), which didn't get the support of major vendors. Over the intervening years we tracked, authored and influenced BTP, WS-CAF, WS-T and then WS-TX. Each time, we used XTS as the platform for testing these protocols.
Just like the local JTA and JTS implementations, XTS leverages the core engine. It has no dependency on CORBA. It has no dependency on JTA. As well as webMethods, others have used XTS successfully in the past too. Because all of the various Web Services transactions specifications/standards have included support for extended (non-ACID) transactions, XTS is able to exploit yet more of the power of the underlying core engine: the ability to relax all of the ACID properties in a controlled manner. So unlike other vendors, we have the same core engine providing the support for all of the transaction models!
Then of course there's end-to-end transactions (E2EX as we were calling it in HP). We've been talking about transaction bridging for many years and working on one prototype or implementation after another. But the recent work that Jonathan et al have been doing has really pulled everything together into a more coherent approach, at least as far as JEE is concerned.
I could say more about the architecture of all of our components. I could also wax lyrically about recovery or extended transactions. But most of what I'd say is covered by the various hyperlinks I've embedded throughout these entries. So please follow them and read up. If you've got any questions or comments, put them against the relevant entry or post in our forums. But overall, enjoy using JBossTS as much as we've enjoyed developing it over the past 20 years.
Trying to put JBossTS into perspective: JTS
Well if you're still with me you're either really interested in transactions and JBossTS, or lost.
So far I've covered the core transaction engine and the local JTA components of JBossTS and shown how they are related. In this entry I'll go over the JTS implementation as well as the remote JTA.
JBossTS began life in C++. In the early 1990's when the CORBA OTS was being developed within the OMG, we were involved and came up with the world's first complete OTS implementation (supporting all of the optional components). We did some pretty cool things with end-to-end transactions back then too (but more on that in a separate entry). When Java came along and we created the world's first 100% pure Java transaction service (predating JTA and JTS), we decided to do our own Java language mapping of the OTS, JTSArjuna.
JTSArjuna, which became Total-e-Transactions, HP Transaction Service, ArjunaTS and now JBossTS, is a full implementation of the OTS (now JTS). It builds on the core transaction engine and, because OTS is distributed in nature, obtains all of the distribution support from a variety of CORBA ORBs. Quite early on in its evolution we developed an ORB Portability Layer, to isolate ourselves from the differences in ORB implementations. So over the years, in C++ and Java, we've probably ported TS to most of the ORBs that have ever seen the light of day.
Anyway, the JTS component leverages the core, but doesn't touch the local JTA: it doesn't need to. As I said earlier, when we first did out JTA support it was built on top of the JTS. So we had distributed JTA from the start: local JTA was an after thought. The relationship between the remote JTA and the local JTA is the core engine.
Being a JTS implementation, it supports distributed transactions and hence distributed failure recovery. We have both top-down (coordinator driven) and bottom-up (participant driven) recovery. As I said above, we also support all of the optional capabilities within the OTS (e.g., nested transactions and interoposition), with XA interoperability and an XA TX look-alike veneer API. Plus we provide quite a few enhancements to allow the power of the underlying core engine to come out. For example, neither the OTS/JTS nor JTA support ordering of participants with the log. So when you call commit (or rollback) there is no guarantee on the order in which participants will be driven. The core engine allows you to order participants and therefore so does the JTS.
That's about all I have to say about the JTS component. There's a lot more in the shipped documentation that also goes into the details around the OTS. If you want to have distributed JTA, then this is your only route (at the moment). You don't have to use JTS via the JTA of course: you could go straight to the JTS. Plus, you can continue to mix-and-match your participants and transactions from the core with the JTS if you need to.
So far I've covered the core transaction engine and the local JTA components of JBossTS and shown how they are related. In this entry I'll go over the JTS implementation as well as the remote JTA.
JBossTS began life in C++. In the early 1990's when the CORBA OTS was being developed within the OMG, we were involved and came up with the world's first complete OTS implementation (supporting all of the optional components). We did some pretty cool things with end-to-end transactions back then too (but more on that in a separate entry). When Java came along and we created the world's first 100% pure Java transaction service (predating JTA and JTS), we decided to do our own Java language mapping of the OTS, JTSArjuna.
JTSArjuna, which became Total-e-Transactions, HP Transaction Service, ArjunaTS and now JBossTS, is a full implementation of the OTS (now JTS). It builds on the core transaction engine and, because OTS is distributed in nature, obtains all of the distribution support from a variety of CORBA ORBs. Quite early on in its evolution we developed an ORB Portability Layer, to isolate ourselves from the differences in ORB implementations. So over the years, in C++ and Java, we've probably ported TS to most of the ORBs that have ever seen the light of day.
Anyway, the JTS component leverages the core, but doesn't touch the local JTA: it doesn't need to. As I said earlier, when we first did out JTA support it was built on top of the JTS. So we had distributed JTA from the start: local JTA was an after thought. The relationship between the remote JTA and the local JTA is the core engine.
Being a JTS implementation, it supports distributed transactions and hence distributed failure recovery. We have both top-down (coordinator driven) and bottom-up (participant driven) recovery. As I said above, we also support all of the optional capabilities within the OTS (e.g., nested transactions and interoposition), with XA interoperability and an XA TX look-alike veneer API. Plus we provide quite a few enhancements to allow the power of the underlying core engine to come out. For example, neither the OTS/JTS nor JTA support ordering of participants with the log. So when you call commit (or rollback) there is no guarantee on the order in which participants will be driven. The core engine allows you to order participants and therefore so does the JTS.
That's about all I have to say about the JTS component. There's a lot more in the shipped documentation that also goes into the details around the OTS. If you want to have distributed JTA, then this is your only route (at the moment). You don't have to use JTS via the JTA of course: you could go straight to the JTS. Plus, you can continue to mix-and-match your participants and transactions from the core with the JTS if you need to.
Trying to put JBossTS into perspective: local JTA
I covered the core component of JBossTS earlier, so now it's the time of local JTA. Although we have two JTA implementations now, early on in the evolution of JBossTS there was only one and that was built on our JTS/OTS implementation. However, with the development of ArjunaCore and the fact that some of HP's customers didn't want to worry about configuring/maintaining an ORB, we looked at creating a purely local JTA implementation.
ArjunaCore has its own set of APIs that are not based on XA or any other standard. In fact, many of them pre-date the current standards in these areas. But as we saw in the earlier entry, there's a lot of flexibility in the core engine: if anything, it essentially presents a superset of capabilities of the various transaction specifications. So producing a purely local JTA implementation based on it was relatively straightforward. JTA is a narrowing of those capabilities, because it is closely tied to XA: the participants can only be XA participants and even with the UserTransaction/TransactionManager split there's not a lot of scope for doing "interesting" things like nested transactions or nested top-level transactions.
Both of our JTA implementations do support nested transactions. But the fact that XA doesn't support nesting makes it harder than it should be. In order to have support for nested (or sub) transactions, you need the cooperation of a nested transaction-aware coordinator and nested transaction-aware participants. Our coordinator is nested transaction-aware, because ArjunaCore has always supported sub-transactions. However, XA participants don't. But luckily for those people who want to try out this capability, you can mix-and-match your APIs with JBossTS. So you can create a JTA transaction and then dive into the core API if necessary to register a nested transaction-aware participant. Plus, ArjunaCore comes with a suite of such participants, so you don't have to write them to start with.
So there you have it. The local JTA (which ships by default in JBossAS 4.2) is a layer on top of ArjunaCore. It provides full non-distributed JTA capabilities including automatic failure recovery. Plus, if you're willing to try, it's still possible to get at the power of the underlying engine.
ArjunaCore has its own set of APIs that are not based on XA or any other standard. In fact, many of them pre-date the current standards in these areas. But as we saw in the earlier entry, there's a lot of flexibility in the core engine: if anything, it essentially presents a superset of capabilities of the various transaction specifications. So producing a purely local JTA implementation based on it was relatively straightforward. JTA is a narrowing of those capabilities, because it is closely tied to XA: the participants can only be XA participants and even with the UserTransaction/TransactionManager split there's not a lot of scope for doing "interesting" things like nested transactions or nested top-level transactions.
Both of our JTA implementations do support nested transactions. But the fact that XA doesn't support nesting makes it harder than it should be. In order to have support for nested (or sub) transactions, you need the cooperation of a nested transaction-aware coordinator and nested transaction-aware participants. Our coordinator is nested transaction-aware, because ArjunaCore has always supported sub-transactions. However, XA participants don't. But luckily for those people who want to try out this capability, you can mix-and-match your APIs with JBossTS. So you can create a JTA transaction and then dive into the core API if necessary to register a nested transaction-aware participant. Plus, ArjunaCore comes with a suite of such participants, so you don't have to write them to start with.
So there you have it. The local JTA (which ships by default in JBossAS 4.2) is a layer on top of ArjunaCore. It provides full non-distributed JTA capabilities including automatic failure recovery. Plus, if you're willing to try, it's still possible to get at the power of the underlying engine.
Subscribe to:
Posts (Atom)