We are happy to announce that the video/audio streaming from TSE 2007 will be available online the week of February 11th for you. You will have the opportunity to see/hear the TSE 2007 presentations you were not able to make at TSE 2007 due to all of the great sessions available per time period. We have captured the entire session length including any demos/live coding. Please look for the email from us next Monday, February 11th with the details about viewing the session content online.

I’m extremely excited about this. For two reasons:

1. I didn’t get to finish my reviews of the sessions that I attended. Now that it has been several weeks since the conference, I don’t feel like my memory of them is good enough to do a fair review. Now I can do a refresh and write!
2. There were several sessions that I wanted to attend that I couldn’t – now I get to attend…and write!

Look forward to some more reviews from The Spring Experience 2007 in the coming weeks!

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.

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.

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!

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!

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.