Web Application Data Access Patterns: Keith Donald

Well, after a short hiatus of getting back to "real" work, I'm going to attempt to squeeze in another Spring Experience 2007 entry. This particular session was my first of Friday morning. I've always enjoyed Keith Donald as a speaker, having first heard him at TheServerSide.com's Java In Action conference in 2005, and again during his Java University session at JavaOne 2007.

Keith began with a discussion of why we need patterns. In his opinion, patterns simply provide a way of thinking about a particular approach to a problem. One could liken them to blueprints. They typically have a name, a description of the problem being solved, a description of the solution approach, and finally a selection of implementation guidelines and considerations. Pretty nice summation.

The particular patterns that Keith planned to discuss surrounded the different data access patterns typically found in web applications.

Keith began by discussing the "Unit of Work" pattern, which he defined as a unit of interaction with a shared resource that executes independently of other units. These interactions exhibit ACID properties, and a database transaction provides a typical example. In the context of an ORM such as Hibernate, a Unit of Work tracks changes to the object graph during a transaction and then synchronizes those changes with the database when the transaction is complete. Keith followed this discussion with an implementation example from his "Reward Network" sample application.

Keith followed this discussion with two of what I'll call "subpatterns" of the Unit of Work pattern: Pessimistic and Optimistic Locking. With pessimistic locking, you prevent other units from accessing your data during a given unit of work, and then release the "lock" as soon as possible. This locking is performed to prevent a race condition, resulting in an inconsistent state in your model. Keith briefly illustrated implementation of pessimistic locking with Hibernate.

It's always interesting when someone asks a slightly off-topic question which ends up in a take home gem of information. At this point, someone asked if the implementations that Keith was showing showcased Spring's Hibernate support. To this Keith surprised me by answering (and I paraphrase), "Hibernate's native API's are much more mature and powerful now, so we recommend you use those rather than Spring's Hibernate API wrapper. Why add another dependency?" He then proceeded to recommend Rossen Stoyanchev's Saturday morning session on "Working with Hibernate in a Spring 2.5 Environment" (blog entry to come later!). One of the better quotes of the conference came during this aside as well:

Whenever you can eliminate a dependency, you should.
- Keith Donald

Well, back to the presentation. Keith then moved into a discussion of Optimistic Locking. Here, within a business transaction that executes across a series of system transactions, you use optimistic locking to prevent corruption of shared data. An examples is where several users can edit account information concurrently, but the frequency of concurrent access is fairly low. Data integrity is still at risk, so you use optimistic locking to handle those infrequent cases. Keith them demonstrated the use of Hibernate versioning to implement optimistic locking.

Keith next moved into a discussion of the controversial "Open Session in View" pattern. This is a specialized technical pattern where by the Hibernate session is kept open for the duration of a given web request. It is generally used as a "quick fix" to prevent lazy loading exceptions in the view tier. This is generally considered a bad thing, as you end up with a great deal of "N+1 Select" situations while rendering the view, resulting in way too much SQL executed against the database. Typically, the need to use this pattern reveals a flaw in the design of your model or queries. For example, since you generally know how far in the object graph you'll need to go for a specific view, you should load those relationships eagerly for that use case. You may also consider whether or not a given object association is appropriate to begin with.

The final major pattern that Keith discussed was the "Conversational Persistence Context" pattern that is present in the upcoming Spring Web Flow 2.0 release. It is essentially a more flexible variation of the Open Session in View pattern, where by you can have an open session spanning multiple requests during a long-running user interaction context, or "conversation." To be perfectly honest, I still don't quite "get" this pattern beyond that, probably because I don't know much about Web Flow or it's cousins (e.g. Seam, Web Beans JSR-299).

Keith closed with a very brief description of Master Detail, where you show an overview of objects in a collection and then allow drilling down into object details, and Paging, where you allow users to easily browse through a list of items of interest. I raised a point of contention with Keith at this point. His example implementation showed delegation of the paging concern to the DAO layer, rather than implementing that concern in the View layer. When I asked him where he thought it belonged, he thought it was obvious that it belonged in the DAO layer. I then let on that we had this debate in our team and decided the the concern belonged in the View layer. Why should I run the same query multiple times just to page through the data? Why not load the entire data set and then let the View tier decide how to page through it? Keith gracefully acknowledged my point.

All in all, this was a great session, if for no other reason than it reminded me of some best practices in this area and let me in on the little secret about using native Hibernate API's rather than Spring's Hibernate template. Nice job, Keith.

Goodbye Spring Experience 2007!

Well it had to end eventually. As you can see, I'm hopelessly behind on my blog entries, having only made it through my first day of sessions. I've still got several more I intend to cover (I probably won't do the last two as I started blanking out - I think my brain was pretty much melted by this afternoon). Look for those entries in the coming days. Many thanks go out to No Fluff Just Stuff and SpringSource for putting on an awesome conference!

There were several things I really liked about this conference that I believe set it apart from most of the conferences that I have attended.

  1. The technical content was top-notch - Spring topics from the developers themselves. There were also quite a few architecture/design sessions that were also superb.
  2. The session length, at 90 minutes, provided ample time to cover each topic pretty well in-depth. The session scope cooperated with this, as most of the speakers didn't try to do too broad of subjects for the time allotted.
  3. It was a smaller conference, at a little over 500 developers. This meant you weren't trying to weave through crowds to get in queues for packed out sessions like at JavaOne. Much less stressful.
  4. The atmosphere was just plain fun. Everyone was laid back. I mean, how many conferences give you a bobblehead doll on the first night! I now issue a call out to Sun that we must have a James Gosling bobblehead doll issued to every attendee at JavaOne 2008!
  5. The food was top notch - every meal was provided, buffet-style (no boxes!!!). I ate way too much.
  6. The location was great. You can't beat a front-on view of the Atlantic Ocean from the conference center balcony during session breaks.
  7. SWAG! Let's see what all I collected: a computer bag, a binder with all of the slides, two t-shirts, a hat, sunglasses, a beach towel, a Frisbee, a NFJS Anthology, a bobblehead doll, a Spring Source toolkit (two screwdrivers and a measuring tape - you'd have to see it)...what's more, Jay Zimmerman distributed the left-over swag after the conference closed. I picked up two more computer bags full of swag and two conference binders to give away at the January and February Memphis JUG meetings!
Once again, thanks for a great conference. It was easily the best all-around that I've attended.

The State of the Art in Dependency Injection: Rod Johnson

This was a truly fascinating talk. If you ever wanted to learn the entire history and landscape of dependency injection (DI), this was your opportunity. I really didn't realize how deep of a topic DI really is.

According to Rod, DI had its beginnings in 2002, in the Interface 21 Framework that was born from his seminal work, Expert One-on-One J2EE Design and Development. In the beginning, DI was done solely through setter injection (SI), with external metadata (usually in XML). 2003 gave us Spring 0.9, which had the same DI model, but added FactoryBeans for indirection and proxy-based AOP (enabling among other things, declarative transaction management). With Spring, DI was always just one enabler of a complete enterprise solution. Contrast that with PicoContainer, also arriving on the scene in 2003, which was an ultra-lightweight DI-only container. PicoContainer brought us several innovations, including constructor injection, automatic resolution by type, and an attempt to dispense with external configuration.

Rod then discussed the Pros and Cons of Constructor Injection (CI). On the Pro side, we see that CI is great for immutable objects, can be used with existing code, enforces that the necessary dependencies are provided at object construction, and allows developers to dispense with methods like afterPropertiesSet(). On the Con side, there are no default arguments in Java, which forces us to ALWAYS provide all of the necessary dependencies, constructor overriding can be somewhat messy, and constructor argument names are not usually available through reflection, which forces us to depend on argument order for dependency resolution.

Spring 1.0, which arrived in late 2003, incorporated some of PicoContainer's innovation: CI, "Autowiring" by type and by name, as well as the ability to mix CI and SI. Here Rod reflected on Spring's pragmatic philosophy, whereby they are more than willing to incorporate the good ideas that others had first.

Spring 1.1 brought us method injection, a unique Spring feature, which solved the problem of long-lived managed objects which depend on short-lived objects. It also brought us Factory Methods. You now had the ability to create objects through invoking static factory methods or instance methods on other beans.

With the finalization of the EJB 3.0 standard in May 2006, several new ideas became available in the world of DI: annotation-based DI, annotations for callback methods (e.g. @PostConstruct), scanning for annotations without any external configuration needed for a deployment unit, and field injection (FI). These EJB standard brought with it a new philosophy - that annotations are a superior model and that externalization should be a second-class citizen. The Pros of this standard? One big one - no configuration is necessary for simple cases. The Cons? Rod listed several: resources could only be injected from JNDI, no CI, limited control over object lifecycle, unsuitability for fine-grained object graphs, effectively usable ONLY with annotations, as the XML configuration option is so verbose, and it isn't just DI - it brings along with it enforcement of many obsolete EJB concepts (such as bean instance pooling).

Spring 2.0 arrived in late 2005 with its own share of innovations: integration with AspectJ, the ability to inject anything with an AspectJ aspect via @Configurable, namespaces to provide an XML-based DSL for external configuration, the @Required annotation, and pluggable scopes to manage the object lifecycle. About that same time, JBoss Seam introduced many strange ideas (that I didn't quite grasp from Rod's explanation): bijection, outjection, and subversion of control.

Some additional players on the field include Spring Java Config, which is a DSL for configuration in Java, Google Guice 1.0, and the JSR-299 Web Beans spec, which Rod described as "blogware" in that there is currently no available implementation.

Finally we got to Spring 2.5, released last month. Rod didn't have his slides printed or available on the web (argh!), so about this time my hand was really hurting from taking furious notes, and I simply gave up. Fortunately, most of what Rod covered was redundant from some of the other sessions, so I'll have or will blog about it later. About the only thing I really don't have good notes on is Spring Java Config, which he discussed pretty extensively. If you want to learn more about it, check out http://www.springframework.org/javaconfig.

Ajax Integration Guide for 2008: Jeremy Grelle

This talk looked really exciting going in. Jeremy is a member of the Spring Web Products team and the lead of Spring Faces, as well as a member of the JSF 2.0 Expert Group. He describes himself as the resident Ajax freak at SpringSource. Jeremy began by discussing the current Ajax landscape, highlighting what he believes are the important features a successful framework must deliver, and then identifying the frameworks he considers to be the cream of the crop. No surprises here on the list: Prototype/Scriptaculous, jQuery, YUI, Ext, and Dojo. He then gave a brief high-level overview of each framework - I really didn't learn anything new here, as I've been following these frameworks for quite awhile. He mentioned the commonality that all of these frameworks are about more than asynchronous client-server communication - they're about improving your client-side code and user experience. See Dion's May 2007 comment that Ajax "was never about the acronym - it's about building killer websites." What is good about all of these frameworks is that you can use all of them in an unobtrusive manner and progressively enhance your UI. This gives you the ability to only Ajaxify what you need and also get graceful degradation.

In the second portion of his talk, Jeremy talked about connecting to Spring. I was really hoping that the "goods" would be delivered here. He started by mentioning DWR, which I think is a really nice framework. It merited 2 slides and no demo (even though there was a slide mentioning a demo). I don't think Jeremy really cares for it or GWT, as he sort of lumped them together and didn't mention them again. I do appreciate his point that neither really allows you to harvest any existing controlling infrastructure that we may have built using Spring MVC or another framework.

Jeremy then moved into what he considers the better way to do it, which is the progressive enhancement I mentioned above. He took the existing Spring Booking MVC + Web Flow example application and ajaxified portions of it. He did this using an interesting combination of Apache Tiles, some Javascript "pseudo-AOP" he lifted from the SpringFaces project, and a bit of Dojo. It seemed to work really well, but it wasn't immediately clear how this type of technology was going to be made available to us as developers. He said something along the lines of "you don't have to be using JSF to use this Javascript, so we probably need to change the name to something else." I hope they figure out soon so I can get my hands on it. :-)

He closed by briefly discussing REST's place in the future of Spring Web. The ideal scenario, according to Jeremy, is that we will be able to request different representations of the same resource. For example, we could request HTML for full page display or partial DOM updates, and JSON for intelligent widgets like the Dojo table.

It looks like a lot of exciting things will happen in 2008. I hope I don't have to wait too long.

What's New in Spring 2.5? : Juergen Hoeller

This was my second talk of TSE 2007. I have to admit I chose it by process of elimination - none of the second session talks particularly jumped out and grabbed me like Chris Richardson's talk.

Juergen is the project lead for the Spring Framework, so he was the obvious choice to give this talk. Juergen split it up into three sections:

  1. Platforms
  2. Annotation Configuration
  3. AspectJ Support
To break down part one as quickly as possible, Spring supports virtually EVERYTHING. You get JDK 1.4 all the way to Java 6, including all of the new API's in Java 6. It fully supports Java EE 5 while remaining backward compatible all the way to J2EE 1.3. You can now deploy a Spring ApplicationContext as a RAR file, and you also get full JCA 1.5 support (if you want to know what that means, don't ask me :-)). Quite notable was the fact that they have worked with IBM to support WebSphere's proprietary transaction manager. Also interesting was Spring's continuing strong support for OSGi as an alternative enterprise runtime.

The annotation configuration part of the talk was quite fascinating. I'm something of an annotations junkie - I have to be careful about that. At any rate, it was so good that I was interested enough to attend Juergen and Mark Fisher's later talk that was completely dedicated to the subject. I'll leave the details for my entry on that talk.

The final portion, on AspectJ support, was equally fascinating. The first new feature was the ability to advise specific beans by name rather than by type using AspectJ. This was made even sweeter by the fact that you can use pattern matching in your definition. Very exciting was the ability to do AspectJ load-time weaving, meaning you can use the power of AspectJ at runtime without involving the AspectJ compiler. Unfortunately, this isn't available across all appservers. I didn't get a chance to ask and comfirm, but it seems that JBoss (our primary appserver) does not support this. GlassFish, Weblogic, OC4J, and Tomcat were all mentioned as being able to handle it.

The most interesting part of this talk for me was the ability to annotate a class as @Configurable, and then do dependency injection on it even thought it isn't managed by Spring. You could do this in Spring 2.0, but you had to use the AspectJ compiler. Now, with load-time weaving, you can do this at runtime! I really could have used this recently when I wanted to inject a single dependency into a class that was really overkill to manage as a Spring bean. Since I'm using Spring 2.5 in this project, I can go back and try this feature. Exciting!

Pair Programming with the Official Rod Johnson Bobblehead

As you can see, Rod really likes my Spring MVC configuration. :-)

Improving Application Design with a Rich Domain Model: Chris Richardson

This was my very first session of the conference. I've really been looking forward to it. I became pretty excited about object-oriented programming when I first really learned it in my computer simulation course at Ole Miss. In that course we built discrete event simulation programs using collaborating Java threads. Each thread implemented an object from the domain model representing a particular simulation problem. Once I got into the "working world," I found that the architecture described by Rod Johnson as the "J2EE stove pipe" had made my OO skills essentially unusable in the projects on which I was required to work on a day-to-day basis. My recent experiences developing in a more POJO-based style, particularly with JPA/Hibernate, have allowed me to get closer to my preferred OO-style, but the business logic still lived in the service-tier. My domain model was still essentially "anemic" to borrow from Martin Fowler.

When I read the description for this session I was elated! Finally I could see that someone was building real enterprise applications using object-oriented techniques! I've never quite been able to articulate what I felt was wrong with the way we're building applications in my group. I was fortunate enough to have breakfast with Chris Richardson prior to the session, and he said that addressing my inability to articulate those problems was one of the goals of his talk. Awesome! On to the session...

Chris began with a tour through his object-based programming experience, beginning in LISP, followed by C++ and then Java. Around 1999 he got into EJB programming, and described his experience as "Applications were still built from objects, but those objects were very different..." Basically the EJB paradigm caused us to abandon object-oriented programming in favor of procedural programming. Why? Well, for all of the pros surrounding EJB, it made writing object-oriented code difficult, and in some cases, impossible. The EJB/procedural style works very well for simple business logic, but it doesn't scale well as business logic becomes more complex. The result is a few monolithic transactional classes containing hundreds to thousands of lines of code embedded in very long methods. Hence, the legacy of EJB (and I quote):

  • Java is an object-oriented language, AND...
  • Object-oriented design is a better way to tackle complexity, YET...
  • Many complex enterprise Java applications are written in a procedural style
Chris then moved on to discuss the rich domain model pattern, which is really nothing new at all. It's just good OO design. Most of your classes (or entities) correspond to real world concepts, and the business logic is spread amongst them. Classes are true objects: they contain state and behavior. The goal is to push as much business logic as possible down into the domain objects, which is exactly where it belongs. What do you get? Better maintainability, better testability, better reusability, and a better shared understanding of your domain. Not only that, but your code is quantifiably simpler! Who doesn't want that? The main drawback to this is that you have to have good OO design skills to make it happen - which is exactly what the EJB programming model has made scarce.

Chris followed this up by discussing the building blocks of domain models, concepts he derived from Eric Evans' book Domain Driven Design. In a nutshell, they are Entities, Value Objects, Aggregates, Services, Factories, and Repositories - the reader can get the book to find out what these are. Interesting notes for me include the fact that Repositories are nearly equivalent to DAO's, especially the way I typically implement them. The concept of a Service is far different from what I'm used to. I "grew up" writing services according to the EJB Session Bean/Facade model, where essentially all of your business logic resides in service methods. Chris defined a service as a class implementing only logic that cannot be put in a single entity. They are actually quite thin!

Next came the discussion of frameworks and their role. In short, frameworks act as an enabler to rich domain models when used properly. Your domain model should be implemented purely as Plain Old Java Objects (POJO's) in that they don't implement any infrastructure interfaces or call infrastructure API's. The jury is still out on annotations - Chris argues that they still violate the POJO concept, I'm not so sure. You then wire your model together using dependency injection, handle crosscutting concerns (transaction management, security, logging, etc.) with Aspect-Oriented Programming (AOP), and use object/relational mapping (ORM) for persistence. What you often run into as obstacles are that many of these frameworks, particularly web and ORM frameworks, force you to introduce "smells" into your code for the framework to use them. Examples include requirements for public default constructors and JavaBean-style setters.

Chris closed with an awesome discussion of common code smells and the refactorings used to eliminate them. I was most interested in Feature Envy, which is where you have methods that are far too interested in data belonging to other classes. This is very common in session facades, and the healing factor is to push that logic down into the appropriate domain classes. Another interesting smell was Primitive Obsession, where code uses built-in types (such as String and Integer) instead of application classes to represent state. The refactoring in this case is to introduce Value Objects, which are immutable, validated objects representing domain concepts (e.g. a shipping address).

Chris closed with the charge to begin refactoring our procedural designs into a rich domain model on MONDAY! Oh, how I can't wait to begin. Good job Chris!

Enterprise Java and the Changing of the Guard

Greetings from The Spring Experience 2007 in Hollywood, FL. So far this has been a great conference - I'm currently waiting for my third session of the day to start. As much as I enjoy all of the hype and eye candy at JavaOne, I really get a lot more out of these smaller conferences as you're not running around stressed out trying to weave through thousands of geeks as you move from session to session (or more accurately, from session to queue!).

I wanted to post a few insights that I gained from Rod Johnson's keynote last night (the title of this entry). The basis for Rod's presentation was a Gartner report entitled "Trends in Platform Middleware: Disruption Is in Sight." To summarize, there are many converging forces in the enterprise Java space that are causing or will probably cause a great deal of disruption in the way we develop enterprise Java applications. These forces include our collective experience with application servers, the rediscovery of object-oriented or POJO-based programming, open source innovation, non-Java challengers (.NET, RoR), the rise of SOA, and Rich Internet Applications. Rod sees a big movement from the "old guard," which he described as the "J2EE Stovepipe Architecture" which was based primarily around the idea of distributed objects, to a world in which many of the highest volume Java applications don't even use a Java EE application server. An interesting point was the stagnation in job requirements for the big name application servers coupled with the BZ Research statistic that 64% of Java application developers are using Tomcat for production deployment. Yet another force for disruption is the emergence of OSGi, which allows developers to modularize applications and provides facilities for versioned components, fine-grained redeployment, and library conflict resolution - all features that Java EE currently does not and perhaps cannot address. Open source provides yet more disruption, as developers have become participants in rather than spectators of the development of Java enterprise solutions. Innovation is now primarily coming from the open source world. All of this culminated in the rather telegraphed conclusion that Rod (and also the Gartner report apparently) believes that Spring is uniquely positioned to provide the best value for ongoing Enterprise Java development in the face of the current trends. Of course, what would you expect him to say? :-)

I do tend to agree with him. The pace at which Spring is innovating and addressing the Java enterprise pain points far outpaces the pace of the JCP. It just takes too long to design specs by committee. One of the more wise things that Spring does is to learn from and in most cases accommodate the changing landscape of Java EE and integrate the best features directly into the framework. I for one am glad to be developing applications with Spring, as it makes it very easy to do the things I want to do and write quality code that isn't directly dependent on an infrastructure framework. Generally, it stays out of my way.

More to come on the sessions I've attended thus far.