Matt Ingenthron's Stream of Consciousness

Wednesday June 09, 2004

What's old is new again...

First of all, a big thanks to Marc Fleury and Gavin King for coming to our LA JUG meeting last night. I'm sure they tune into my blog all the time. :)

Hopefully the slides will be posted soon off of the LA JUG website. To quickly summarize though, Gavin is the founder of the Hibernate project. He's also participating quite a bit in JSR-220 which will probably be EJB 3.0.

The reason for the title of this entry is that years and years ago, I remember looking at a draft of the JSP 0.92 specification. Way back then the idea whomever wrote that spec had was to use Java Beans (not EJBs) for the component model. Then the developer would progammatically control transactionality and such within the code they develop. Then things like the EJB spec including CMP (or the idea for it anyway) and things changes significantly going into JSP 1.2.

Marc's theme was to treat all of these components that reside behind the JSP/Servlet tier as POJOs (Plain Old Java Objects). Then through the use of annotations/metadata in Java 1.5, ascribe different aspects (think AOP) to these POJOs you've described. For instance, if you need something to be an entity, you can 'inject' an entityManager into a POJO using the @inject annotation. What this does is takes the developer out of the daily routine of coding to the current EJB specifications with all of it's home/remote interfaces and different facades for encapsulating how things are done. Instead it's replaced with a simple to read, easy to understand way for developers to declare what they want to happen. There are some other neat things like removing the need to write DTOs (Data Transfer Objects-- a TLA [three letter acronym] that describes all of those mountains of code that we write for moving data back and forth between Servlet/JSPs and the EJB containers). EJB 3.0 should also be picking up some of Hibernate's other great features, like very much simplifying O/R mappings and addressing common challenges in implementing such code. It also should give EJBs some more OO concepts that were lost with the component approach, like polymorphism.

Now that I reread that, I've kind of summarized in the reverse order of the presentations last night (Gavin went first and really described the moving from EJB 1 to EJB2 to EJB3, very coherently describing the problem), but it seems to help to take Marc's description of the problem and then translate that back into what EJB 3.0 will do.

Marc picked up where Gavin had left off, translating what EJB 3.0 will do into the POJO theme and describing how the EG is focused on simplifying J2EE development for the next release. He then made mention of how JBoss's 4.0 architecture implements this kind of thing.

Finally, he closed with a discussion of JBoss the company, and their thoughts around open source software. It was definitely food for thought-- I'm sure it's well described on their website.

Both Marc and Gavin are great guys and the LA JUG guys had an opportunity to share a beer or two with the JBoss folk at the local eclectic watering hole. Both are good guys-- if you're in the Silicon Valley region, I think they're on tonight at the SV JUG. I'd imagine they'll be at JavaOne too, so you can likely catch them there. It was clear to me that they're focused on how the applications work and how developers interact with these systems when building apps. Gavin in particular would at times get quite cerebreal; for example on how transactions are somewhat broken, in that there isn't a concept of an 'application transaction'.

It'll be interesting to see how this all works out. The only reason I want to reserve judgement is that to me, EJB 2.0 gave developers a framework to code to that would make transaction management and scaling things with lots of multithreaded access someone elses problem. EJB 3.0 seems to put this back in the hands of the developer with annotations. That, of course, means the developer needs to think about where the transaction is occuring and where to begin and end things. I don't know that this is a bad thing, but history with other languages has shown us that making the developer responsible for certain aspects of programming just tends to introduce errors. Still, EJB 3.0 looks to be much more accessable, and it doesn't matter how well/not well EJB 2.1 did things if it was limited to those who spent a significant amount of time understanding how it worked and coding to it's particularities in moving things about between containers.

In the end, Marc said, and I'd agree, that while the future looks bright, EJB 2.1 is where it's at today and you can still get plenty accomplished with that. 6 months from now we should all get to play with this stuff a bit more, and hopefully we'll find not too many more changes are needed to make it useful :).