Why Is EJB So Hard?

Gather round young folk. The grumpy "old" programmer is going to explain why EJBs are so "hard" when compared to things like Ruby on Rails. If you don't give a rip about EJBs, you still might find this interesting.

Ok, so I'm not exactly old (but I'm fairly sure I'm grumpy). Well, I don't feel old. But more often than not when on a job, I'm starting not to just be the most senior programmer experience wise but also one of the most senior age wise. Which freaks me out--I'm not even 35 yet! But be that as it may, I have actually seen quite a bit in the world of programming--especially when it comes to "distributed programming".

It's funny that I have to put that in quotes, but I think it might be necessary since no one speaks about "distributed programming" anymore. It's an uncommon term even though many modern solutions are essentially distributed programming (for instance, SOAP is basically distributed programming grown up and stunted all at the same time ).

Ok, enough musing, back to EJB. Why is EJB so hard? Well, whether you think it is hard or not, many do. Just google "death of EJB" to get a few. I used to think these people just didn't get EJB or the benefits of n-tier programming. Ok, it's complicated, but nothing powerful and flexible is ever simple. Quit being wussies!

But there I was writing EJBs for a client on an older J2EE platform and it took almost 2 days to get it working with the rest of the system. To be clear, my EJB worked just fine, but it was the integration that was killing us. Handing it off to others and getting their configs setup correctly was an absolutely pain. I just couldn't believe how much freaking trouble it was given us. And this was an easy EJB. It was so straight-forward we probably could have skipped the SB if we wanted to manage the transactions ourselves.

And that in a nutshell, is what people hate about EJB. That and the packaging (although I have a snazzy little build system that makes my EJBs fairly easy and cross-platform). After doing a lot of JSP or struts based projects, people start to wonder why EJB is so freaking hard and why even bother?

I think it's important to understand EJB's roots before we condemn it outright. Many of the easier solutions people use today came as a result of EJB or learning from EJB. So here's the quick, abbreviated timeline:

1. First there was RPC. Remote procedure calls allowed you to knit together several systems and expose functionality from one system to another.


2. RPC was pretty snazzy, and OO was just starting to get all sexy. People wanted to marry RPC with OO. This eventually led to CORBA.


3. CORBA was all that (and a bag of chips). Lots of people got into it. Lots of people started realizing that just because you could marry OO to RPC, it doesn't mean you should. Through a lot of practice (read: expensive trial and error), people basically started making remote objects that just had business functions as the methods. That is, they grouped a bunch of RPC calls in to one namespace and called it an object ;-)


4. Java found its killer app: not "write once, run anywhere" client applications, but server-side software. So there people are, cranking out server apps and some CORBA implementors thought, "Hot dog, Java would make a great ORB platform!" And sure enough, they were right.


5. Sun suddenly is very happy about server side software. They look at CORBA and think, "Too complicated!" So they make RMI (remote method invocation). Ironically, RMI isn't really all that much easier. You got to skip the IDL creation, but the rest was only marginally simpler.


6. So people are cranking out server software with servlets, RMI, or CORBA. And then someone says, "Gosh, you know what makes all this stuff hard to do? Transactions and life-cycle management!" And thus, EJB was born.


7. Compared to RMI or CORBA, the life-cycle and transaction management of EJB is a breeze. And again, compared to RMI or CORBA, deployment isn't all that hard either.


8. People go nuts. They embrace EJB full bore. Entity beans are the bomb. Session beans are innovative. But in the end, their just CORBA with a very nice framework. With a lot of practice (read: expensive trial and error), people learn that stateful transactions are freaking hard, EJB or no EJB. Everyone starts moving away from Entity Beans and Stateful Session Beans.


9. People make some truly awful apps via Servlets and JSPs, mixing control code and presentation code. Despite MVC being decades old and most of Java being built on the design, no one seemed to have learned from it. Struts is born and people are very happy.


10. With struts, MVC design is very easy to implement, and EJB isn't needed so much. Struts matures and people start to find they don't need the heavy duty aspects of EJB most of the time. The apps are industrial scale, but they are easy to make and easy to deploy.


11. Learning from the J2EE body of work, Ruby on Rails is born. RoR gets people very, very excited. The main reason people are so excited is that RoR is so freaking easy to use for 90% of most small or routine applications. You can use the defaults and it just works!

I hope you see what I am getting at. EJB only seems hard or stupid if you don't bear in mind that RoR got to learn from its many mistakes. I'm not saying EJB isn't hard, I'm just saying you have to understand where it was coming from. EJB was a vast improvement in productivity over rolling CORBA apps from scratch.

But EJB is still too hard. And here's why: it seeks to solve all the problems. It doesn't just solve the simple problems, the hard problems, or the industrial-sized problems--it seeks to solve them all. And the easiest way to do that is to solve the industrial-sized problems and leave your framework open so that others could innovate and make it simpler to use for the easier problems.

No one ever did. That's why EJB is so hard: Sun never tried to make it easy. They always assumed a vendor would make it easy or a tool would make it simpler. And to be fair to Sun, there were a lot of vendors making sure Sun didn't try to eat their lunch. But it never really happened. You could point to XDoclet, but you would be falling into the trap EJB fell into: making one piece or another of X easier, but never thinking there might be some flaws in the assumptions that make X so hard. XDoclet makes deployment descriptors and home classes easier to generate, but it doesn't really make EJBs as easy as they could (or should) be.

And here we are, and no one is making EJB easier. One could argue that Spring makes EJB easier by just not being EJB. But that's not what I mean. There should be a way to use a simple POJO as a Session Bean just by declaring it in an XML file. Again, I know Spring kind of does that, but I'm actually talking about still using EJBs.

What is needed to fix EJB is not just a solution to the industrial-sized solutions, but also a solution for the simple problems. And the way to do that is a framework on top of the framework. You would need a two-piece framework: one for the server side and one for the client side. The server toolkit takes a simple POJO and deploys it as a stateless session bean, all business methods get a default transaction mechanism of "requires new". The client toolkit takes a simple POJO and returns a proxy that refers to the EJB--all without having to know about names, JNDI, or initial contexts.

I'm sure you might think, "Cripes, that would be a lot of work!" But would it really be any more work than creating a Java version of RoR? Would it be any more work than what was required to create Spring? I doubt it.

You might ask, "Well, Mr. Smarty Pants, why don't you make it?" Good question. Maybe I will (in all my spare time). Sigh. Spare time--if only ;-)

iPhone: who wouldn't want one?

Ok, let me join the rest of the internet and blogosphere in saying: "I want an Apple iPhone ... NOW." When Steve Jobs announced it would be available in June, I felt my heart sink a little. Oh well. I guess this means I can just focus on getting my work done until June rolls around.

They have photos over at MacRumors. Very, very cool stuff. I know it is Steve's job to hype his company and his products, but his statement about the iPhone being revolutionary might really not be hype. This device is everything Microsoft has been trying to do with Windows Mobile and everything Palm and Blackberry have been doing--but done right. I had thought when the patent came out for touch screen it might be Apple planning a tablet--but using that technology for the iPhone was a stroke of genius. If it works half as well as the demos, it is going to be an incredible product.

I wonder if it will have a Java stack on it? Will it run J2ME? It's running some version of Mac OS X (look out Linux--if they license this, Linux devices could be in for a run for their money), but it's a question of how much of the core OS is on there and how many toolkits have been provided. To be honest, running J2ME would be a joke--why bother with that much horsepower and a screen like that? I'm hoping they just include a full JRE and call it done. Not sure if that is even feasible, but one could hope ;-)

I currently have a project that uses J2ME. It's fun in a very frustrating way. For instance, J2ME has forms, which do auto layout based on the screen or device type. They have nice little flags you can pass in to tell how to structure the rows (that is, it will try to cram stuff on the same row until the width is reached or a flag is set). So I set the flags. But on one device, it says those flags don't exist. On another, they work fine. But they are flags right from the MIDP API documentation! Argh. So I had to just dynamically append "\n" to my string values to force the row breaks in a way that works on any J2ME phone. J2ME is full of that kind of stuff.

As a part of this J2ME project, I also got to write my own POST code from scratch. It was scary how much I had forgotten about mime encoding and POST requests thanks to all the excellent toolkits that are available in every language these days. But it isn't there in J2ME--so I had to go digging on the internet and find some code examples to write my own. Again, frustrating but also strangely fun. It's kind of like making a fire while camping: it can be very frustrating, but when you are heated by the work of your own hands, you get a nice feeling of accomplishment. Perhaps there are easier ways, but it feels good to be able to fend for yourself, to create what you need from scratch.

Hopefully iPhone has a JRE and not J2ME. While it's fun to crank out J2ME, I would love to have Java5 syntax for iPhone apps. If not, I can limp along in J2ME until I teach myself Objective C ;-)

10 PRINT "HELLO WORLD!"

Well, I finally got around to "blogging". Everyone and their brother seems to be blogging these days, but I just haven't ever found something I wanted to blog about. But then I thought, "Hey, I've been programming for 25 years now. I might have something to say about it after all this time."

Yeah, 25 years. Well, not all of it was professional ;-) Unless you count writing your own Star Trek shoot-em-up game on the Apple IIe as "professional experience". I've been writing software professionally (I guess that's when you get paid to do it) for 12 years now. However you look at it, it's been a good few years of coding.

I love writing software. It's hard to put into terms that don't sound corny or weird. But the best way to explain it I have found is that I would write software even if I didn't get paid for it. There were a few years there where I had other jobs, and I always found myself thinking about programming or coding up little scripts. Why wouldn't I? It's fun!

But I have to confess that doing it professionally can sometimes take the fun out of it. I guess that is why work is called work--sometimes it isn't tremendous amounts of fun to pound away at a problem when you would rather be hanging out with friends or fishing (ah, fishing ... that's another topic). But even at it's worst, I still love writing software for a living. You still get to solve problems, write clever little tidbits of code, and sometimes even build something pretty impressive. And hey, putting food on the table while doing something you love is pretty great--better than what most people have to do for a living!

A couple of years ago, I was browsing in an antique shop. I'm not an antiquer--nor am I really a shopper. This is code for "I was tagging along with my wife while she browsed/shopped/meandered through an antique shop". I was just doing my husbandly duty: trying not to appear too bored or to whine about wanting to move on (whether that whine is verbal or non-verbal). Anyways, I see this stack of old magazines and I find this old men's magazine called True. Never heard of it (turns out it wasn't in print long), but it was kind of funny to read a men's magazine from 1968. It had the typical reviews of cars, and reviews of stereo equipment. Even a (now) hilarious article about dating.

But I found the following advertisment in there. It so caught my eye that I surprised my wife and actually bought something. When we got home, I immediately hooked up the scanner and scanned in the full page; this is only the "book" part of it--the text of the ad is classic:

"If you're dissatisfied with your present job, why don't you become a programmer? So great is the demand for programmers, you'll have your choice of openings, with a growing future ahead."

Wow! Who wouldn't want to become a programmer?!? I mean, with such demand and a choice of positions? And look at that photo! Just look at it! Who wouldn't want to work with those clean-cut, upstanding young Americans? That guy on the right really looks like he knows what he is doing. That sharp-dressing young woman clearly thinks so--that, or she's pointing out he has his english-to-metrics conversions all wrong. The guy on the left looks to me like he just likes to be in the computer room, watching the tape reels spin (and hey, youngsters, if you haven't seen those things in action, you don't know what you are missing!). But what do I know? He probably invented some cool banking algorithm for all I know.

All joking aside, this ad just warms my heart. Maybe it is because, despite being cynical now, I would have read a similar ad when I was in High School and thought, "Oh yeah! I'm going to be a programmer and it is going to be soooo cool!" And in fact, it was, and is, cool. I'm one lucky guy, and I get to work in a great field. And I'll be writing software for a long time to come, even if it is only for my own amusement.