30 August 2006 - 14:45The emergence of the managed environment

You wouldn’t have guessed that this post is about EJBs, right? I wrote a rather critical post about EJBs, but I’d like to take a second look at them.
I was looking at EJBs from a historical point of view and I realized that the EJBs are probably the first managed environment. Their intention was noble: to free the developer of any operational concerns and focus exclusively on the business logic. The developer was not supposed to worry about securing an application, about propagating credentials in a cluster, the environment was supposed to do this. The developer was not supposed to code for concurrency, the environment was going to do this. The developer was not supposed to deal with resource management, the environment would have done this for it. The developer was not supposed to code TX behaviour, but rather declare it and let the environment enforce it and propagate it in a cluster. The developer was not supposed to connect to a DB manually, but rather delegate this to the environment. The aim was really high, the functionality that this managed environment was supposed to implement was not trivial. On top of this, the spec defined this managed environment to be a distributed managed environment. Very high goals…
The result was disappointing: in order to embed your component in this managed environment you had to code to a series of interfaces and design policies which had to become second nature to a developer, in other words the environment was very intrusive. Embedding your component in the environment also came with a very large overhead: for some beans no less than 6-7 files were required in order to be able to turn an ordinary class into an EJB. Working with entity beans was particularly hard on anyone who had to use collections in the early days of EJBs: I remember scanning the log of the application and waiting forever for the app server to load 20 entities. This managed environment also came with some perverse side effects, the most known of which was the vendor lock-in: transporting an application from one app server to another was an undertaking that very few organizations had the resources to carry out.

Now, if we look at it from a “historical” point of view, the above doesn’t seem so bad for a first try. One cool thing about EJBs that resonates well with me is the fact that EJBs promoted the use of interfaces. One very good use of this would have been the abstraction of a business process behind interfaces, unfortunately this didn’t take off, most of the implementations were going the other way around, from concrete class to interface, XDoclet-style.
The “mistakes” that this operational environment made would be that it was advertised as “enterprise” and that it was too inclusive. Trying to address every issue important in enterprise computing on your first shot is prone to failure. The fact that this was done in a “democratic” fashion with each industry vendor pitching in his customers’ needs didn’t make defining the spec easier.

Some people look at EJBs as an abject failure. I look at it as the first step on the road to something new, a first step loaded with mistakes as all first steps are. Currently everything is running in a container, in a managed environment if you wish, which you get to define and tinker with if you wish. The lessons learned by working with EJBs provided valuable when the current successful containers were designed. It’s an evolution if anything else.