A recent java.net article, JOTM Transactions In Spring And Hibernate, Binildas Christudas and Sowmya Hubert explore distributed transactions with the help of the Java Open Transaction Manager (JOTM) and the Spring framework.

They claim that while most J2EE application servers provide full support for the sort of complex distributed service interaction depicted in the article, developers should eschew a full-blown app server in favor of a light-weight approach that uses Spring along with other light-weight tools. According to the article, a key benefit of that approach is that the solution will not be tied to any specific application server:

Component relationships are externalized in configuration files, and the Spring runtime instantiates the required objects and sets relationships. Similarly, the transaction attributes are configured on a per-instance level or on a per-method basis. If you combine these two capabilities, you gain a lot of advantages in the component world. The important part is that the components configured in this way are not tied to any specific application server or runtime mechanisms.

While that may be so, the article illustrates that, in lieu of a full-blown app server, a developer has to piece together various tools to achieve correct transaction semantics for the application. For example, to use transactional semantics outside an app server, a component will need to enlist an implementation of the Java Transaction API (JTA), and to coordinate distributed transactions that adhere to the two-phase commit protocol, you also need a distributed transaction manager that, ideally, understands the industry-standard X/Open interface.

JTA provides the application-level interface to coordinate a transaction across multiple resources. If this has to happen, the various Resource Managers have to interoperate, and this is achieved by all Resource Managers adhering to the X/Open XA Resource Manager interface. ...Here you need multiple connectors to coordinate in the same transaction, and you need a JTA-compliant Transaction Manager. It is here you are going to use JOTM. Such Transaction Managers are also called Transaction Processing (TP) Monitors... Java Open Transaction Manager (JOTM) is a JTA-compliant Transaction Manager.

And, for persistence, you need to weave Hibernate, or another O/R mapping or persistence tool, into the Spring-based solution.

As the article itself demonstrates, configuring and coordinating the work of all the components that go into this solution is a fairly complex task. Although the Spring-based solution may provide a "light-weight" approach, an off-the-shelf application server can possibly provide a turn-key, ready-to-use environment that hides much of the configuration complexity from a developer via tools.

While there has been a backlash against top-heavy application servers in recent years, with the proliferation of so many frameworks and tools—many of which try to solve similar problems—do you believe that the pendulum will swing the other way? Instead of having to self-assemble a solution from a half dozen framework components, in what situations would you favor using just one turn-key, out-of-the-box tool to solve a complex problem?