Rod Johnson is on the Servlet 2.4 expert group and is the author of the book "Expert One-on-One J2EE Design and Development". Rod is an enterprise java architect and has been working with Java and J2EE since their release.

Can tell us a bit about yourself and what you're involved with?

In the first instance, I'm an application developer. I've never actually worked for a vendor; I've always worked through end users or in consulting assignments. So I guess my primary motivation is making life easier for the developer and I'm essentially seeing myself on the developer's side.

I've been involved in J2EE since the beginning - in fact, before it was branded as J2EE. More recently I've been on the Servlet 2.4 expert group and I've written a book called 'Expert One-on-One J2EE Design and Development', which was published in 2002 by Wrox Press. I'm also involved in an open source project called The Spring Framework which grew out of the source code examples in my book.

Why did you choose to write your book on J2EE design?

I guess I've always enjoyed writing and communication. It's always ended up being a fairly important part of whatever of the job I've been doing. This was actually my fourth book. I've contributed to several others. I guess I was primarily motivated by the fact that I saw a lot of people making the same mistakes and I really thought that there was a need for a sort of common sense book that told people how to avoid those common mistakes.

When should developers choose to use distributed architectures?

When they can't avoid it. I think that a lot of J2EE developers are far too eager to distribute their objects. I think it's something that they really should do reluctantly. There are quite a few costs with distributing objects which aren't immediately obvious. The first adverse cost is performance. And although that's relatively obvious people often neglect that.

The second really big cost is what it does to the ability to practice object-oriented design. For example, you get into the whole scenario of needing value objects to communicate between processes and value objects are not very object-oriented.

I really enjoyed reading Martin Fowler's 'Patterns of Enterprise Application Architecture'. He formulates Fowler's first law of distributed objects: "Don't distribute your objects." And I think J2EE developers would be very wise to heed that advice.

Why are value objects evil?

Value objects are evil because they are not objects. Value objects, by definition, don't have behavior, and anything that doesn't have behavior is not an object. When there's a real need for value objects, such as in inter-process communication, you have to accept that trade off. I think it's a mistake to welcome value objects into the internals of your application, because once you have to marshall your application's domain objects into value objects, your essentially taking away the behavior; there's a true impedance mismatch there that developers don't always recognize. And you also face non-trivial problems such as how deeply you're going to navigate your relationships.

When should you use EJB?

I think we're learning that we've probably been much too eager to use EJB in the past. I think that EJB is probably going to eventually be seen as a transitional technology towards AOP-based middleware. The first indication for me that I should use EJB is, where I want containment managed transactions, where I want the EJB threading model, and if I'm writing a message-based application, I'd be inclined to use message driven beans. However, I think it's important to note that there are good alternatives to using EJB in many of those cases.

EJB solves some problems very well but it also has a very significant downside. For example, EJBs are quite difficult to test. So I think we're becoming more mature in our use of EJB. We're realizing that EJBs are usually best seen as coarse grain components, that EJB does have a value proposition but unless you've got multiple indications for using EJB, such as you need declarative transaction management, you need the thread management, you maybe need role based security, unless you got those multiple indications, you probably shouldn't incur the cost of EJB just for one facet of what EJB does.

What are the data access pitfalls that you have seen?

I think one of the biggest problems is naive object relational mapping. I think that the great majority of J2EE developers are actually facing problems of object relational mapping. It's true that entity beans and JDO are both designed to work with any persistent data store, but the fact is that we do generally work with relational databases and we have to accept the good and bad that flows from that.

So the biggest problem is that there is a naive mapping between Java objects and individual tables and also a distrust and dislike of relational databases. I think Java developers can be quite arrogant with respect to people with relational database skills. For example, they're very often unwilling to accept that an organization may have an investment in stored procedures, and they really want to impose their own view of how the relational model should work.

I think what works best is if you have a natural object model on one side and you have an idiomatic relational database schema on the other. And you try to a sufficiently sophisticated mapping between those two things that neither suffers.

Do we need entity beans?

Short answer: No. Longer answer: Read Chapter 7 of my book, and the answer is still no. Entity beans, I think, were misguided. They have held the cause of object relational mapping back severely, because when entity beans were first introduced into the EJB 1.1 spec as a required part of EJB, there was already sophisticated object relational mapping, such as, TopLink and Apple's WebObjects which were far more capable than what EJB delivered at that time. I think entity beans have been playing catch up ever since, but they still haven't really gotten to the level of a sophisticated mapping solution.

One of my prime problems with entity beans is they don't give you transparent persistence. They don't give you anything that remotely approaches transparent persistence and I think that's a nasty problem. I actually want to persist domain objects. I don't want to persist objects that are essentially dumb value holders. I want to persist rich objects which have behavior in them. And to do that I need to be able to test that behavior. And testing entity beans is extremely difficult.

Also, I don't see any good reason for tying persistence to the EJB container. If my persistent objects are in my domain model, I want to be able to use those domain objects in a variety of contexts. The J2EE server is one of those contexts, and I might want to use my domain objects in a J2EE server but outside the EJB container.

So I think that entity beans are the weakest link of the EJB spec. I think the EJB spec should focus on the problems that it solves well and leave persistence mappings to specialist solutions.

How do you decide where to store state?

In web applications, I'm inclined to say store state in an HTTPSession object. I think the implementations for that are very robust and I think the implementations allow you significant optimizations by having relatively fine grained attributes. I generally don't advocate the use of stateful session beans. I think they definitely have a place, but I think they make fairly unusual requirements. For example you might use stateful session beans if you've got multiple client types, and you need a central place to store your session state.

In general, if I was writing a richer client, like a stand alone Swing or SWT client, I'd be inclined to store the state on that client and pass state up to stateless session beans as necessary.

How do you handle writing portable J2EE applications?

I think there's several strategies that you can use; one of the most useful is the reference implementation verifier tool. Another useful technique is to ensure that anything that you know upfront is going to be non-portable, you put behind an interface. I think that's a very sound, object oriented design practice and that works really well in the J2EE context.

So, certainly, if you need to use a particular feature of your application server, very often you can do that, but you can hide it behind an interface. Where the reference implementation verifier tool helps you is it means that you don't end up with portability problems through carelessness. For example, you don't want to accidentally make your EJB bean implementation methods final. The reference implementation verifier is very good at picking up those kinds of problems.

Two other things that I would say is EJB is more of a portability problem than the web container. In my experience, servlet applications are very, very portable, EJB applications are much less portable. Finally, I would steer clear of any really unique features of your particular application server. For example, the JBoss 4.0 AOP features, sounds pretty cool, but at least at the moment you are going to get totally tied in to that server if you use those features. So I would tend to favor using, say, a portable AOP framework that isn't tied to a particular server rather than using that particular capability of the server. Likewise, I would prefer to use a portable JDO implementation, than to rely heavily, on say, WebLogic's enhancement to CMP entity beans.

When is it appropriate to use messaging?

In general, I'm not eager to use messaging. I guess in the applications I've worked with, whether or not to use messaging has not really been dictated by business requirements. For example a lot of web applications that I've worked on have had virtually entirely synchronous requirements. In a lot of financial applications, you find messaging absolutely used everywhere. If I have a choice, I'm inclined to go with the synchronous call. The reasons for that is, it makes the system easy to debug, it also can incur less overhead because , of course, message oriented middleware needs to do quite a bit of work behind the scenes. So, in general, I tend to be a bit skeptical about claims, that using messenging throughout your system will improve performance. I think there's no harm in fast rules. I think this is the kind of issue that you really need to resolve on a case by case basis, by doing a vertical slice and looking at benchmarks and maybe experimenting with how easy you could debug that application.

What is the open source project that started from your book?

It's called The Spring Framework. When my book was published, there were about 40 packages of infrastructure code that accompanied it. That infrastructure code was drawn from my experience, essentially consulting over the previous few years. It solved a lot of the problems that I'd seen people grappling with again and again. I've been really pleased but since the book has been out, there have been a lot of people interested in that code and now it is a thriving open source project. We have about five active contributors and, I think, ten developers in total, and they've been very significant enhancements since the original code was published.

The Spring Framework, essentially goes to places that a lot of other frameworks don't. For example, if you use Struts, you very often have some kind of home grown solution for people running business delegates to talk to EJBs. Spring gives you a really strong way to find your business objects in the web tier. That can either be in terms of delegates to EJBs, or Spring gives you a lot of support for actually implementing your business objects in the web container. The full range of Spring's capabilities is quite extensive now. It has an MVC web framework. It has a JavaBeans based configuration mechanism which means that everything about Spring applications, including Spring itself, is configured in a consistent way, usually in terms of XML files, setting JavaBeans properties. Spring also has a JDBC abstraction layer which makes JDBC exception handling, in particular, much, much easier.

Spring has integration with Hibernate and JDO and some other open source products. And Spring has an AOP framework which enables it to provide a very good substitute for EJB that's much lighter weight in many cases. Spring also provides a transaction abstraction. So, you can do programmatic transaction management without direct JDO calls.

I think one of the nice things about Spring is that it's layered. For example, if you prefer to use Struts because your developers are very familiar with Struts, you can still use Spring's configuration management, maybe AOP framework. Whatever kind of application that you're building, you could use Spring's JDBC abstraction. So it really provides a lot for developers to choose from, and if they choose a number of things, they'll find that those things are very, very, consistent.

What are your thoughts about AOP and the industry?

I think AOP is going to be very, very important. I think in the long term AOP is going to change the way we design applications. I think in the short to medium term, it's going to have a significant effect on J2EE, primarily, as a replacement for EJB. As I've said, I think that EJB is a transitional solution to AOP middleware. I think AOP generalizes a lot of the ideas that we successfully applied in EJB, and makes them both more powerful, but eliminates a lot of the downsides of EJB.

For example, declarative transaction management is one of the nicest features of EJB. But, in fact, we can implement this in a simple way using an AOP framework. So I think we'll be hearing a lot more about AOP, both in the next one or two years as it becomes a popular replacement to EJB and in the next 5 to 10 years when it really changes the way we design applications.

How have you used AOP in your projects?

Firstly, I've used AOP as a replacement for EJB. For example, Spring gives you a very lightweight framework which means that you can enjoy EJB services, such as container managed transactions without an EJB container. So container managed transactions are probably the AOP capabilities I use most often. I've also done a variety of things such as automated auditing. I've actually done this using AspectJ rather than using my own AOP framework. AspectJ, of course, is significantly more powerful, but I think there are real maintainability issues in introducing it into production systems. How I've used it is as part of the build process to insure that during unit tests, things are being called in an appropriate way, and it's certain bad usage patterns of our objects are flagged.

Your book, 'Expert one-on-one J2EE Design and Development' was published with Wrox. Do you know what happened to Wrox authors when Wrox went under?

In my case, my book was picked up, along with, I think, the 30 best selling Wrox titles by Wiley. So Wiley are obviously looking after the Wrox authors and I'm fully honoring the royalty contracts. Some of the other Wrox assets were acquired by Apress. Wiley now own the Wrox brand and are actually planning to bring out further Wrox books.

What is in your pipeline?

I think this is a really great time to be a J2EE application developer. I'm actually really enjoying it at the moment with AOP and EJB 2.1. There's really a lot of interesting things going on. So, I'm really enjoying working with the technology. I am definitely planning another book. It's still taking shape, so I can't actually tell you too much detail at the moment, but it's definitely going to relate to where I see the J2EE industry heading, and it will be about making life easier and hopefully more enjoyable for developers.