WS-AT and SOA

Just a cross post.

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.

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.

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.

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.

Trying to put JBossTS into perspective: the core

There have been a few comments on the forums recently asking how the various components within the JBossTS suite relate to one another. So I thought I'd try to put everything into context here so we can at least refer back to it if these questions come up again in the future. However, there's potentially a lot to say, so I'll split it across a few entries.

Note that these entry won't go into transaction basics: this is purely about the product and it's architecture.

You'll find a lot of this information in the various collatoral documents and presentations we've got. Plus, the documentation that ships with the product is very extensive and does cover this to one degree or another. So don't think this entry is a substitute to doing your homework.

Where to start? Well if you're interested in seeing the overall architecture we have a good description, but I think it's best to start at the beginning: ArjunaCore. As it's name suggests, this is the core of JBossTS: everything that needs transactional capabilities builds on this in one way or another. Using ArjunaCore you can get full transactional semantics for your applications in a local environment. You also get:

• Multi-threaded: transactions can have many threads operating within them concurrently.


• Nested transactions: transactions may be nested within one another. This allows for improved fault-tolerance the failure of a nested transaction does not automatically undo the work of the parent transaction) and modularity (nesting is transparent to applications, such that an object that requires transaction support can be constructed without a requirement that it must be invoked within a transaction: if it is then it's own transactions will simply be nested within the invokers and if it is not then the transactions will be top-level).


• Highly configurable: one of the key components to the performance of any transaction system is its log: the transaction log is used at many times during the lifetime of a transaction and the information it stores must be durable. Thus, disk I/O is a typical bottleneck to any transaction system. However, the usage patterns for transactions can also affect the log such that different log implementations perform better for different applications. Therefore, rather than provide a single log implementation, ArjunaCore allows different implementations to be plugged in at runtime to best suite the application requirements.


• Relaxation of properties across the ACID matrix: all of the ACID properties can be relaxed in a controlled manner. So, for example, the atomic nature of a traditional transaction can be modified to support OASIS BTP cohesive transactions. Furthermore, this means that the same transaction coordinator can be used to support many different transaction models. ArjunaCore provides the necessary support for BTP, but can also be used to support the various WS-CAF (or WS-T) transaction models.


• Optimised and performant: ArjunaCore has been developed in one form or another for over 15 years. In that time, it has been tuned and optimised to improve its performance.


• Adaptable failure recovery: arbitrary transactional resources can be enlisted with ArjunaCore transactions and recovery mechanisms can be provided that will be automatically driven by the failure recovery sub-system.


• No dependency on XA participants: it defines a neutral two-phase aware interface for transactional participants that does not mandate XA semantics.

Note, it is important to realize that ArjunaCore does not require any other software in order to run. It is a complete 100% pure Java implementation of a transaction system and does not require an ORB or application server in order to provide any of its functionality.

As a result of its flexibility, our core engine has been used within mobile transactions (it has a very small footprint and still runs on an HP Jornada 720), JMS implementations, JTS, JTA and Web Services transactions (supporting more than just ACID transactions).

Hopefully that's enough on ArjunaCore. Next entry I'll move "up" to our local JTA implementation.

TIBCO BusinessWorks and JBossTS

I can't remember why I let this slip by last year, but it's still worth mentioning: TIBCO BusinessWorks uses a version of JBoss Transactions for its transactional capability. It's a long story, going back to my Arjuna days, but we worked closely with those guys for a long time before finally signing them to use ArjunaTS, the old name for JBossTS. The rest, as they say, is history.