Day 3 of the Spring Workshop – On Persistence and Transactions and ever more Test Driven Development

Rod Johnson took over from Alef again to talk about the Spring DAO module, Spring’s support for leading persistence frameworks. Spring takes over a lot of configuration details for some of the major O/R frameworks as well as a lot of the JDBC plumbing. It also allows for easy switching between or combining of different persistency technologies. Additionally, we spent quite some time on transaction management services, either implemented through JTA (when running in a J2EE container) or by Spring wrapped components from Hibernate, Toplink or JDO or the Spring implementation for JDBC.
This workshop is heavy stuff. Sometimes it feels more like a training for Spring-committers-to-be than a course for future Spring users. We get so much details on design decisions in the Spring team (and some of their internal debates as well), so much nitty gritty stuff “Hey, you know what you could also do…”. I have asked quite a number of questions, that Rod or Alef eagerly took to elaborate down some side-track. For example the discussion today about ‘keeping persistence technology out of the domain objects’ prompted me to ask about layz loading – to prevent having to instantiate entire object graphs when the application needs just a single object. This took us down the lane of various O/R frameworks and the way they go about it. Later on we went into Open Session In View pattern, that allows the View to read details/collaborators for a Domain Object that has been provided by the Model. These discussions make the workshop incredibly valuable. Although in a sense we are guinea pigs, as the workshop really is still under development and will (have to) evolve quite a bit, it gives us great opportunies for learning much more and also getting the feeling we are early adopters.

Spring supports Hibernate, JDO, TopLink, iBatis and Apache OJB as well as plain JDBC. If there is an area in Spring that is very easy to adopt, without any impact on your application and architecture, except of course for many improvement in the JDBC code in your applications, it is the Spring JDBC Templates. Johnson suggested that for the majority of database interaction (domain object instantation and persistence after modifications) should be handled using an O/R mapping framework, such as Hibernate or TopLink etc. For cornercases, where you for example need to invoke Stored Procedures, want to perform aggregation operations or set-based data manipulation, it may be useful to still use plain JDBC – through the Spring JDBC Templates and under Spring Transaction Management. Of course you have to be careful with database modifications through multiple ‘channels’: the direct JDBC call may do updates that the O/R framework is unaware of, since these passed it by completely. You have to ensure that the O/R framework flushes (posts changes) before straight JDBC calls are made; vice versa you may need to enforce Cache Refreshing after the JDBC call is made. That is your responsibility, neither O/R mapper nor Spring does it for you.

Important items in the Spring DAO module is the wrapping of all SQLExceptions – and other O/R Framework Exceptions – in technology agnostic, unchecked DataAccessExceptions. These provide access to the underlying SQLException, the stacktrace and are cast to an appropriate sub-interface, specifying the type of DataAccessException. The DataAccessException hierarchy contains interfaces for common problems that occur in all technologies (Oracle, DB2, MySQL etc.) such as Unique Constraint Violation and Lock could not be acquired. Spring maps technology specific exceptions (ORA errors or MySQL codes) to these generic DataAccessExceptions. You can customize this mapping process. It allows you to handle DataAccessExceptions in your Service Object or even WebTier in a functional, technology independent way.

Note that the Spring DAO Persistence Support is a class library, a simple Jar, that stands on its own. You can adopt Spring DAO without tying in to the rest of Spring. So it is extremely easy to use Spring DAO, if only for a single piece of JDBC code. This may well be the easiest entry point for starting to use Spring.

Spring – the open source project

Especially today I had the feeling that Spring is an open source project that I actually feel I can make contributions to. Not in the least because of the fact that both Rod and Alef are very accessible, open to criticism and eagerly inviting our contributions as well as the fact that the concepts are settling in and I feel up to speed with the whole thing. It will be nice to help along Spring! See the Spring Homepage, as well as the Spring Bug and Enhancement Request Tracking System and the Forum. There is also the Spring mailinglist at SourceForce.

Some observations

In the list of topics that seem to warrant some of my (or someone’s) time, I should also mention Maven – if only for apply Code Checks (standards enforcement) and Coordinating the Unit Tests, collecting Code Coverage statistics. See Maven Homepage at Apache. Then Alef did a passionate plea for Jira as incident management tool. As it happens, we have just started an evaluation of Jira a couple of weeks ago at AMIS, so this felt like strong support for that direction.

Rod indicated he was fairly skeptical of Annotations or rather the way they have been implemented in Java 5. He also stressed how EJB 3.0 is not the new persistence API. In fact, what used to be in EJB 2.1 and before with regard to persistence has been taken out of the EJB 3.0 specifications and is now JSR-220, to be implemented in javax.persistence which is not in EJB 3.0 and may one day even be part of J2SE. He aslo indicated that leading JDO vendors can quite easily use their implementation of the JDO 2.0 API to also implement the javax.persistence APIs. In fact, KODO JDO already has that implementation ready. So while the JDO API may fade from the J2EE stage, the JDO tools probably will not.

Never having been at JavaOne, I expected to find the same kind of atmosphere and setup as I know from the ODTUG and Oracle World conferences. Some of the comments I heard on JavaOne during this workshop about the lack of technical depth, rather short presentation with little or no demos etc. almost depressed me. Perhaps it’s better for AMIS to attend the The Server Side symposium, see here for material from the last one in march 2005. Also: The Java in Action Conference will be held October 5-7, 2005 at Disney’s Yacht Club Resort in Orlando, Florida. “Java in Action’s hands-on training and practical education have been designed to help you address real-world software engineering problems. JIA continues the uniqueness that is the hallmark of TheServerSide Java Symposium, with a hybrid training/conference unlike any event currently in the marketplace. ” See Java In Action

Spring and Oracle ADF

One of the things I have been doing in my head these last few days is trying to compare Spring and the Spring concepts (or rather the concepts that underpin Spring but may very well be applied to most J2EE Development efforts) with the Oracle ADF Technology Stack, primarily Oracle ADF Business Components, Oracle ADF Binding Framework and the way Struts is used in ADF. It is not easy to completely assess how the two might work together. First of all: Spring is not a single entity, Spring is an IoC Container, a MVC Framework, a library for facilitating working with persistence technologies, a set of services for example for Transaction Management, an AOP Framework etc.

Second, Oracle ADF Business Components is/strive to be much more than just a O/R Framework. In the Oracle ADF Binding Framework can we bind POJO based services. And we can bind ADF BC based Business Services. And some or definitely more equal than others. Where Spring clearly states that not only should Domain Objects be technology agnostic, the Service Object should not expose technology details either. In fact, the Service should be injected with DAOs and get its data from there, it should be pretty technology agnostic itself. The ADF BC Service Object typically is the Application Module, which is most certainly not implementation-details-free. Nor is the ViewRowImpl a technology agnostic Domain Object. And ADF BC interfaces clearly extend beyond the Business Service in an ADF application.

I like the Spring story a lot. So what to do? The productivity and ease of development with ADF, especially in combination with JHeadstart, is tremendous. That is a factor to take into consideration. I like a pragmatic approach. But not one that strays unnessecarily far from good OO Design Principles and modern architectural patterns.

Should we wrap the application module in a Business Service that returns only POJOs? Is that doable at all – given for example the way accessors are implemented? Is it worth giving up the special support in the ADF Binding Framework for ADF Business Components in order to achieve a technology implementation free business service? Can we have the MyOwnViewRowImpl classes implement Domain Interfaces, trying to have them look like POJOs?

Why isn’t the ADF Adapter Set for POJO not more on par with the ADF BC adapters, that would make the discussion easier. Or would it?

I will come back to this discussion!