13 March 2007 - 15:59Competition in transaction semantics

I was reading this post by Rod Johnson on the Interface 21 blog about Oracle Application Server and Spring when I came across this quote:
Because Spring provides a rich, portable transaction abstraction, it does the work under the covers of driving JTA and other APIs, so your code doesn’t need to know anything about the underlying infrastructure, and thus can take advantage of any proprietary APIs that give more control or greater efficiency. Spring supports both declarative and programmatic transactions, so you can layer transaction management onto POJOs that don’t know anything about it; or, if transaction management is part of your business logic, you can use a more elegant API that offers more features than JTA (*), isn’t tied to JNDI, and is much less verbose to work with.

Wow. Does this mean that Spring’s transaction semantics are starting to compete with JEE’s transaction semantics for mind-share, and ultimately, market share? In what DSL (**) should you model your transactions: the old way by declaring them in ejb-jar.xml or Spring’s way by declaring them in spring-conf.xml? Is there a danger that one of these languages will become obsolete? Is there a danger that the current transaction semantics in Spring could be forked in order to better utilize a specific app-server’s capabilities? Is there a danger that these new transaction semantics be irreconcilable with the ones in the next Spring version?

In an earlier post I likened the transparent container’s capabilities to LISP’s, particularly when it comes to defining new languages (**). Well, the transparent container may inherit one bad thing from LISP: language mush-rooming. LISP diverged into so many dialects that it became eventually impossible to use as a common platform. More and more DSLs could be created for various use cases, which will range from the very specific to the very generic. I think this is probably where the effort will lie in the future, in managing all these DSLs, in separating specificity from generic behavior in an efficient manner. The future announces itself to be pretty messy…

* It is an interesting exercise to muse on Spring’s lead in TX APIs. If the features they advertise are needed - and I think they are needed and, even more, they are tested by the market - you would expect the JTA people to include them in their spec, after all the spec would be missing good functionality which should be included. If the JEE body will not include these features it will pretty much admit to being irrelevant in this particular area and would be handing the baton to the Spring people. Or maybe the JEE body doesn’t see these features as being generic enough or not having broad appeal. Who knows…

** Spring 2.0 was released with this nifty feature: XML namespaces. This opens the door to defining your own specialized languages (let’s call it a Domain Specific Language, DSL) tailored to your needs and plugging them into Spring’s runtime.