Days of EJB are numbered -EJB's Memoirs-

March 2009

In the darker middle ages of distributed computing I came as a revolutionary solution. People were struggling with CORBA; CORBA was/is one of those amazing technologies from the nineties and brought distributed Object technology to the masses. It brought it to projects that would otherwise never have been able to use distributed computing due to the complexity. It made distributed computing feasible for everyone that needed scalability and or availability.

CORBA had so much to offer. Besides its core ORB it had a bunch of different service targeting different services and quality aspects. I can’t remember exactly how many services there were, just under 30? Do you know, please tell me: COS naming, -transactions, -security, -trader, etc. But it wasn't all that easy in use. It was API based, meaning developers had to call these services (e.g., in order to demarcate transaction you had to use the COS Transaction via the Transaction API)

Then CORBA almost reached 3. By that time, it introduced Object By Value (OBV). This was the era which allowed my birth. Who am I? I provided a “framework”. I was an API turned inside out. No longer did code have to call APIs, no I called theirs (business logic) instead!. Making it possible for every (Java) developer to program highly advanced distributed architecture without needing the knowledge of concepts such as IDL, GIOP/IIOP, IORs, Naming, Security, Transactions, distributed object life-cycle management. I however sadly ended the careers of many CORBA consultants (author included), because it became a child’s-game to program distributed solutions. I took the “plumbing” out of the “project” and into a “product” (i.e., the application server); from “programming” to “configuring” (at first using serialized Java Objects, later using XML and finally using annotations). Project teams could focus on their responsibility: automate the business process; program business logic and no longer use precocious project time on all the necessary plumbing code.

That was my objective: make distributed computing even more easy. You will have to excuse my ex-husband, “Entity Beans”. I don’t know what people were thinking!! That was never a good marriage. We did not belong together. He was only taking care of persistence (in a horrible way), whereas i was born for distributed computing . What on earth was i thinking marrying him. We tried to patch things up by introducing local interfaces, which only confused the world even more (RIP Entity Bean)

But wait! Due to local interface my solution for distributed architectures was able to be accessed locally. (read that again!) This confused the IT world even more. My original rational became blurred. At the same time a new IT developer generation came along, a generation that never knew the challenges of a distributed environment. They found me difficult and over-complicated. Especially because many people thought that when choosing J2EE/Java EE, that EJB was the required or the best option to implement the business tier (due to some blue-bible).

Everybody thought I had to be used, even together with my Entity Beans!. This led to many developers having a hard time understanding me. But they never experienced the problems i was solving. In fact they did not need a distributed architecture in the first place. This led on its turn to bad performance and other quality problems. People forgot what my intent was: recall i solved problems known in a distributed world, not in the general application world.

They started hating me, also because of the habits of my ex-husband. many people did not know my intentions. When I overheard IT projects were spending valuable project time trying to answer the fundamentally wrong question of: “to ejb or not to ejb?”. That question should always be answered with “yes”. Because the question should have been: “do we need a distributed architecture”. If that was answered with “yes”, then of course you should use me.

Luckily some people starting helping showing my position better: courses/whitepapers by us and other training companies, consultants and a book by Rod Johnson (“J2EE Development without EJB“). People starting to respect me again; people in need of distributed component architecture reached out for me again and those who did not, left me in peace. I was happy and at the same time rather sad. People came to me for who i am, but not so many people needed me. So i picked up some bad habits, i became market share-hungry again. This time even more than before. I was not only losing territory to “.Net”, my original antagonist, but i had now also my best friend Spring to worry about.

Once again I started forgetting who i was and tried to change my position from a distributed component framework to a general application framework, very much like my girlfriend “Spring”. I envied her so much. I also tried dependency injection, went back to trying to be local and so on. But i should have known better. I should be proud for what i am: a solution for distributed component architecture. I also would like to say sorry to my new boyfriend JPA (Java Persistence API). I am dragging you into something bad. Listen JPA: “I am really asking you to leave me and have a life on your own!” You target general applications, not merely distributed applications. I am sorry for the damaged I might have caused you already, go go GO!

So I’m back at who I am. However, I see more dark clouds. Many of the systematic qualities I address (for example scalability and availability) can now be solved by Visualization. (Virtual) computers can scale on themselves (I suddenly recall what my bright godfather used to tell me when I was young: “the network is the computer”). I know I am still needed for vertical scaling; a (JVM) process cannot cope well with a lot of memory and many CPUs, so for inter-process communication I am still a solution. But my days are numbered….

I thank you all; it was a pleasure serving you…. (originally published in 2009)