Post EJB
I balked at Enterprise Java for a long while. It didn't pass my crap filter a few years back so I decided to wait to see when the real server-side Java solution was going to come (doh!). It never did. So then I had to scramble and catch up. That's what I've been doing over the past year. I've come to understand and accept some of things in J2EE that I previously had thought were crap, but there's still a sense in my mind of doing too much work on the plumbing of a server side application instead of focusing on the principal business logic.
Carlos has some great thoughts on the subject in a response to a great post by James.
Are we seeing some kind of convergence here? Graham Glass is talking about some other alternative to EJB. The Avalon folks are pursuing a new Enterprise Object Model. JBeans and ACE are producing code generators to target n-tier deployments. Rickard Oberg is building his Dynamic AOP. Ara talks about XRAI and a metadata bus. Aslak talks about integrating UML2EJB, MiddleGen and XDoclet.
What I see common in all the above endeavors is the need to keep the core logic separate from the implementation. Although, this principle seems entirely obvious, EJB in its current incarnation goes completely against it. The conflicting motiviations for EJB (Transaction Monitor ideas, compliance with CORBA standards, Business Objects or Beans programming model) have created a Frankenstein. A Technology where a business' core object model is hopelessly lost inside a jungle of design patterns.
Post-EJB is an attempt to separate the core model from the implementation. The core model needs to be preserved at all times. This leads to better traceability and a more agile implementation. Imagine building your core object model without the complexities associated with EJB, test and execute it just like a plain java object. Build and deploy inside a Enterprise class container that gives you all the quality of service (QOS) features. That's what the Enterprise world needs and that's what we're not getting using EJB
Wow... how much do I agree with this? When I first was developing with EJBs I was agog at how much crap I had to write concerning RMI, XML descriptors, etc. etc. Why? I should just be able to write a bean, publish it to the cloud and have it be pooled, accessible, etc. without having to mess with the details. I'm amazed at how much work - and how much room for error there is in the current process. EJBs are way too much work!
Actually, I'm even more amazed at many of the Web Services implementations in Java are also extremely low-level. No one seems to be learning the lesson. Lots of plumbing involved in order to publish your objects as services. I saw a demo yesterday of the latest JBuilder, which included Axis integration. "It's very easy" the presenter said to provide web services. And 30 or 40 clicks and windows later he had done it. The comparision to VB.Net is laughable and sad. The tools Just Aren't There for J2EE yet, for both EJBs and Web Services... which is just nuts. It's not totally the tool makers fault - the specs are just too ridiculous.
I don't want magic, but in my mind it should be super simple to write a highly-accessible server side object. I implement an interface or extend a class, write my logic, pop it on the server and then, It Just Works. That's how servlets work and that's why servlets rock. I also love JSP - which is just a faster way to write servlets. And Weblogic's new JWS also looks good. But all the crud you have to deal with while using EJBs is nuts.
As a developer I need to talk to my customer, understand the business needs and code that in Java. That's my job. It needs to be accessible 24 hours a day to thousands of simultaneous clients. That's the freakin' server's job. I don't want to know the details.
Along these lines, by the way, I really like James' recent post about Stateful Session Beans. I forwarded it to a coworker and we both were laughing about how little was left in EJBs. But that's about what Carlos is saying. Stateless Session Beans - if I didn't have to write the RMI crap and interfaces - are more or less what we're looking for. And this is my main point. There's a lot more to J2EE than just EJBs (and Sun is the first to say this). Stateless session beans, Message Beans, Servlets, JSP, JNDI, Web Services - this stuff is cool and useful. There's just some other crap in the spec that isn't.
So here's my thoughts (after a hell of a long intro). We need to promote FIXES to the J2EE solution, not propose "next generation" servers because they will never get a foothold. Right now I'm getting paid because I know J2EE and I'm interviewing at another company for that knowledge also. Knowing "Bob's New Cool Java Server" won't get me paid anytime soon. The reality is that J2EE has a lot of momentum behind it - starting from scratch will be impossible and fruitless.
The first step to fixing J2EE is a best practices doc. Someone with a hell of a lot more experience than me would have to write it. But basically it would just say "focus on these techs" rather than on vendor-promoted techs. This is already happening to a degree, but we need to get Sun to sign on to it wholesale. Also, Sun itself needs to concentrate on SOLUTIONS not just technology. For example, how many freakin' ways are there to talk to a DB? CMS 2.0 is better than it was, but still isn't a great solution. Do something better, Sun! This stuff is basic. It should be the first and best solution.
By the way, and how I LOATHE to say this, but ATG Dynamo has all this already. It's a HORRIBLE server that's a bitch to work with, but the basic technology is exactly this. You write a bean and pop it onto the server. It's then available, pooled and managed. But then Dynamo does a bunch of funky stuff and you end up managing 4,000 unmanageable properties files that link all these objects together in various ways. It's a nightmare, but the core technology is exactly what Carlos and James are describing.
-Russ