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

5

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!

Share.

About Author

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director for Fusion Middleware. Consultant, trainer and instructor on diverse areas including Oracle Database (SQL & PLSQL), Service Oriented Architecture, BPM, ADF, Java in various shapes and forms and many other things. Author of the Oracle Press book: Oracle SOA Suite 11g Handbook. Frequent presenter on conferences such as JavaOne, Oracle OpenWorld, ODTUG Kaleidoscope, Devoxx and OBUG. Presenter for Oracle University Celebrity specials.

5 Comments

  1. Nice to see a discussion coming up. It was about a year ago when I started playing with ADF and spring. At that time I asked myself the same question. Never really got to an answer. Today it becomes more complicated since adf now has JHeadstart and Spring has, well a lot. I happen to have a little experience in projects with both frameworks as well. I think using the right tools and having some experience, spring can be very productive as well. Creating something new with JHeadstart turns out to be a little complicated when creating something different than the usual CRUD application. But JHeadstart has evolved since then as jspring has. I am very curious about exprience of other developers with both frameworks. Looking forward to your dicussion that is coming up :-)

  2. Nice to see a discussion coming up. It was about a year ago when I started playing with ADF and spring. At that time I asked myself the same question. Never really got to an answer. Today it becomes more complicated since adf now has JHeadstart and Spring has, well a lot. I happen to have a little experience in projects with both frameworks as well. I think using the right tools and having some experience, spring can be very productive as well. Creating something new with JHeadstart turns out to be a little complicated when creating something different than the usual CRUD application. But JHeadstart has evolved since then as jspring has. I am very curious about exprience of other developers with both frameworks. Looking forward to your dicussion that is coming up :-)

  3. Hi Andrej,

    It is all good stuff I think. However, what is your idea about the fact that ADF Binding Framework so clearly favors ADF BC over POJO? Have you got any idea whether it would be viable to extend the POJO BindingAdapters to achieve similar support as currently exists for ADF BC? Is having a POJO-only Service Layer (no ViewRowImpl, no ApplicationModule etc.) valuable? And is it valuable enough to give up the ADF BC benefits currently in ADF (and in the IDE)?

    Or should I look at other opportunities for mixing ADF and Spring? It is definitely worth brainstorming about!

  4. Hi Lucas,

    I’m currently writing a small app to learn about spring, hibernate 3, jsf and jdk1.5. So far i really like spring, and hibernate 5 with annotations is also pretty nice.

    I feel that adf (bindings) and spring are trying to achieve the same goal, accessing data and services in a consistant way from the ui. Adf is doing this by adding an extra layer of functionality between the business services and the views, springs is doing this by making everything available as pojo’s. The result is that adf scares you at first by all the extra methods and classes, and spring makes everything look easy, because everything is a pojo.

    Ofcourse, adf adds a lot of extra functionality, and most of the complexity is hidden by the tools and wizards in jdeveloper.

    In my opinion adf was made by oracle to make programming easy for tools (it allows oracle to provide drag and drop data controls, etc.) and spring was made to make programming easy for developers.

  5. But what actually is a POJO, a JavaBean and a domain object? Althought they have different, but overlapping, ‘definitions’, people tend to be not very precise in using the terms and mix them. Spring is all about beans, but in its description it clearly refers to POJO’s. How OO are javabeans and is a MyOwnViewRowImpl less OO then a Javabean or a jdbc.Rowset. But OO is not only about POJO’s, but, among others, also about inheritance and abstraction (with interfaces). This is extensively used in the Spring Framework and, as I recall, also in ADF BC. So it will always be a trade-off between pure OO and a less OO but more pragmatic approach.
    I share yourt concerns about implementation code in services objects (and often also on other places especially on integration ‘points’). Spring is in my experience the first framework that seems to be able (as far as I (as a spring novice) can see) to make implementation agnostic code and is (almost) non-intrusive. It is really an advantage and offers great flexibility but often a factory (or another pattern) that provide different implementations (maybe based on a property) does the job as well and also result in much less xml files. But in both cases, it is essential to code against interfaces.