Going thru the EJB spec
This is obviously not the first time someone points out the deficiencies in the EJB spec but I just could not help it.
I have started my SCEA certification process and for the first exam I had to revisit the EJB architecture. I read EJB 2’s spec and at the end I was left in wonder. I could not believe that a corporation like SUN came out with such a spec.
The first (huge) surprise was the fact that there are interfaces that go against their contracts is a first (as far as I know) for SUN. For example, the MessageDrivenContext interface extends EJBContext and as a result it provides the MDB with access to its home. Except that an MDB has no access to a home since it is not referenced thru a home. Accessing the home thru a MessageDrivenContext would throw a system exception. I was in shock when I read this. You just have to wonder, what other methods are invalid in what interfaces? An API should provide a bullet-proof contract with no room for ‘buts’ or ‘maybes’. Well, this time SUN took a short-cut.
Another thing that surprised me was the breadth of the spec. The spec tries to address quite a few issues: transactions, security, concurrency, timer services, distributed computing, persistence and resource management. Addressing all these issues is obviously not trivial, and in this case the end-result in this case is a hodge-podge of an architecture. SUN made quite a few assumptions about the applications that will be built using EJBs and hard-wired these assumptions into the spec.For example, concurrency is addressed in the simplest manner: all calls to a session bean are serialized. You cannot isolate calls based on state that is shared between calls as you would want in order to create a better-performing architecture.
Resource management assumes that 10 years after the first JRE garbage collection is still a big problem in enterprise computing.
In the persistence area: requiring that some tasks are carried out by pooled beans and others by pooled or active beans seems more like a hack than serious design, I don’t understand why persistence issues should be inter-twined with lifecycle management.
One thing that attracts developers to the so-called light frameworks is the fact that these frameworks do not make any assumptions about the applications getting built with them. Instead, they provide a way to assemble applications and bind behavior to various parts of an applications. They let you integrate outside components more easily into your application.
I think this is a more sensible approach to enterprise computing than trying to create this solution that tries to solve all the issues important to enterprise computing.
Finally, another failure of the EJB model is the collaboration between different technology providers. The EJB model was supposed to encourage application assembly: you would get some beans from a provider, put them together with some beans from another provider and create an application. I do not know of a successful application which got assembled this way.
However, the level of integration the lightweight frameworks have with outside technologies (such as the Acegi security framework) puts them in huge contrast with the EJB architecture. It looks like the IoC containers are much better applications assemblers than an EJB container.
The EJB spec leaves behind the image of an elephant mired in the moors of enterprise computing, trying to provide a solution for every conceivable problem, ending up with no clear answer to anything.
Looking at the picture that the EJB spec presents today it is not clear how another version – even the annotation-enhanced, transparent, lightweight version 3 – will fix the systemic problems that this bloated technology poses. I am skeptical that the on-going effort for refining EJBs will ever bear the fruit it was supposed to.
