Saturday, December 5, 2009

EJB’s: Time to let them go?

If you are a JEE developer, you may already be familiar with the benefits of using EJB’s (Enterprise Java Beans) instead of POJO’s (Plain Old Java Objects) in your applications. The list includes, but is not limited to:
  • Transaction management.
  • Scalability – you can distribute your application across multiple machines.
  • Lifecycle management.
  • Security management.
  • Dependency Injection.

EJB’s have been with us for a long time and have certainly evolve in the right direction. From the cumbersome EJB 2.x specification with all those interfaces, a very verbose XML definition and an over-designed Entity Beans, to a more convenient EJB 3.0 spec which uses annotations and better persistence management with the introduction of JPA (Java Persistence API).  The new EJB 3.1 spec even gets simpler with no need of the Local interface and the possibility to run inside a Servlet Container.

On the other hand, we have initiatives like Spring and JBoss Seam that try to bring the benefits of the EJB’s to POJO’s. They have been very successful in this task and are being widely adopted. In fact, the reason EJB’s are getting much more simpler lies in the success of these frameworks. The idea behind them is very easy to understand: use annotations inside your POJO’s when you want the benefits of EJB’s and we will use AOP (Aspect Oriented Programming) to deliver that functionality.

They even go further and bind each object to a scope. So, for example, you may want an object to last through the duration of a request or through the whole session of the user. I will not get into the details of this powerful feature but you can read more in this post where I explain how this works in JBoss Seam.

As you can see, there are two approaches to achieve the same goal. The top-down approach is used by the JCP (Java Community Process) expert group to make EJB’s simpler and the bottom-up approach used by frameworks like Spring and JBoss Seam to empower simple POJO’s with enterprise services.

We still need the standards!

Standards are good. They allow us as developers to focus on what we have to learn, facilitates the technology selection process, promotes vendor independence and are easily accepted by the executive team in companies, among other benefits.

There have been some efforts to standardize some of the bottom-up approaches. The JSR-299 (Context and Dependency Injection) is one of these efforts leaded by the Seam group which has been approved by the JCP. With JSR-299 you could have POJO’s that behave like EJB’s with dependency injection support and scope demarcation (contexts). So the question is: do we still need EJB’s?

Well, the answer is we do. Unfortunately, the JCP group wants to keep the EJB specification and the JSR-299 group had to make the concept of component (called bean in the JSR-299) more abstract to support EJB’s. I think is confusing and not good for the Java community. While other languages are moving to the KISS (keep it simple, stupid!) principle, we are making things more confusing to developers. With JSR-299, you will be able to work with or without EJB’s. The only benefit of using EJB’s will be the clustered services and JMS but that is something that could have been added to the JSR-299 component model.

Conclusion

I don’t think it’s healthy to continue changing the EJB specification to adapt it to a new simpler model. The JCP group should really let them go, create a unified component model based on POJO’s and add it to the JSR-299. We really need to keep it that simple ;)

K6QA68WYDWM2

16 comments:

Ryan de Laplante said...

You might find this article helpful:

http://www.theserverside.com/tt/articles/article.tss?l=DependencyInjectioninJavaEE6

CDI provides us with powerful DI, but does not address more enterprisy things that EJB already provides such as asynchronous method calls, timers, instance pooling, passivation and activation, thread safety, container managed transactions, container managed security, etc. I don't think it would be politically or technically correct for CDI to re-implement all this functionality when EJB already provides it. I'm glad EJB 3.1 has been made even cleaner/easier to use, and runs in the web container. Use CDI for pure DI, and when you need enterprise features then add a @Stateless, @Stateful or @Singleton annotation to turn the POJO into an EJB, and take advantage of the additional functionality. EJB and CDI are fully integrated with eachother providing a seamless experience, so who cares that they are two separate JSR specifications?

Most of the functionality provided by Seam is now in CDI and JSF2. Seam 3 and future releases will no longer provide the plumbing, and will focus on portable extensions that work in all CDI implementations. For example, Seam Security.

Now that Java EE 6 has been approved including CDI and EJB 3.1, I think the real question is if it is time to let Spring go.

Germán Escobar said...

Unfortunately, this is what they've been selling to us: "CDI is just DI and then use EJB's". However, CDI was first called WebBeans and it was a unified component model based in POJO's. There was no need of using @Stateless, @Stateful or @Singleton. You just annotated your classes with @RequestScoped, @SessionScoped, etc, to specify the scope, and with @Transactional or @Synchronized when you needed transactional or concurrency support, among other annotations.

To mantain the EJB spec, they've created a new specification called JSR-316 (Managed Beans). So, now we have the JSR-318 (EJB 3.1), JSR-316 (Managed Beans) and JSR-299 (CDI), without mentioning JSR-330 (Dependency Injection). Do you really think this is the way to go?

I don't now if it is politically incorrect, but from a developer's perspective, I think there should be only one unified component model with DI and scope demarcation that could benefit from EJB's features through annotations.

Ryan de Laplante said...

I read a book on Seam a few years ago, but didn't end up using it because at the time it did not have Seam managed transactions (at least that is how I remember it), and I didn't like having to use an ejb-jar and EAR just to get transactions. I didn't realize they've since added Seam managed transactions. EJB 3.0 and prior was missing a lot, and I didn't like the packaging requirements. EJB 3.1 added all of the important missing features that I was aware of (other than what CDI offers), and runs in the web container. I think EJB 3.1 is light weight, and I don't have a problem using them.

Reza's article did pose the question "Is the EJB component model needed?". I have to admit that I was thinking the same thing. There are many things that could be separated from the EJB spec and made available to managed beans in general such as transactions, security, and web service endpoints. The rest of the stuff left in EJB would be fitting of the name "Enterprise Java Bean", such as instance pooling, concurrency, MDB, timers, etc. Maybe we'll see that kind of separation in Java EE 7.

In the mean time, Seam 3 and newer might offer portable extensions for transaction management and security for people who want to avoid EJB.

Ryan de Laplante said...

BTW I don't recall WebBeans ever having its own @Transactional or @Synchronized annotations? Sure maybe it was in Seam 2.x, but was it also in early drafts of WebBeans?

Germán Escobar said...

Yes, that is Seam 2.x. But you get the point ;) That's how it should be. What I would like to see in a Unified Component Model is a simple POJO annotated like this for example:

@SessionScoped
@Transactional
@Synchronized
@Clustered
@Roles(...)
public class ... {
...
}

No need for @Stateless, @Stateful, etc. This makes it more clear on what services we are requiring for that class; specially for new developers. It also tells the container how it should handle object pooling (based on the scope).

Germán Escobar said...

I was reading an interview in which Gavin King tries to support the separation of CDI, Managed Beans and EJB's. However, he says:

...
You can say, "Hey, on this particular class I need to add a transaction requires new or I need to make it an endpoint for asynchronous method invocations, or I want it to have a calendar-based timer." And then at that point, you can add a couple of extra annotations onto your class and you get the services of EJB. But you can easily take a class which was not written as an EJB and add those extra annotations and you are done.
...

Then he says:

...
So my expectation is, and it's the direction that people agree on, is that things like that which are currently part of specifications which define a specific programming model, a specific restricted programming model like EJB, should be generalized. So I would expect to see in Java EE 7 that example to become one of those things which becomes generalized or managed beans.
...

The full interview is here: http://java.dzone.com/videos/gavin-king-jsr299

I definitely think we need to let EJB's go and define a new generalized component model.

Ryan de Laplante said...

Yes, making the invidividual components of EJB available on their own to a managed bean via annotations is a good idea and I hope to see that in Java EE 7 too. Don't hold your breath though, because that won't be for another 3 years.

I think all of the features of EJB will always be important and needed by applications. I just think we should be able to pick and choose which pieces we want to apply to a particular managed bean without having to swallow the whole pill.

Anyway, CDI and EJB 3.1 are a giant leap forward from what we had in Java EE 5. I will be happy to use it. I'm hoping to shed my dependency on the Spring framework. My next project will be built on CDI 1.0, EJB 3.1, JPA 2.0, Bean Validation 1.0, JSF 2.0, Seam 3.0 Security, Maven, and GlassFish.

Anonymous said...

The problem is not EJBs or CDI or anything. It is the runtime that matters. And if anything requires me to run anything that includes anything closely to an application server during my development it is an absolute no-go for me.

ferg said...

"The JCP group should really let them go, create a unified component model based on POJO’s and add it to the JSR-299."

Essentially, that's what JSR-299 has done. For political reasons, the POJO "simple bean" was renamed "managed bean" and its definition was split off to a different group. But the functionality remains the same POJO model.

"Yes, making the invidividual components of EJB available on their own to a managed bean via annotations is a good idea."

We're already doing that in Resin, by the way. Our predefined aspect/component set is the same for the JSR-299 POJO model and for EJBs, and JSR-299 lets you do the same thing with its Injection model. So it's possible to do.

Unfortunately, for political reasons, the official specs only define them for EJBs, but there's nothing preventing anyone from adding them to POJOs.

Ramkumar said...

There is a nice post by Gavin on CDI & EJB here:
http://relation.to/Bloggers/CDIAndEJB

For the moment, EJBs can co-exist with the CDI and i would hazard a guess that depending on the adoption, Java EE7 would move one way or the other.

Anonymous said...

>We still need the standards!

Spring is now standard, like it or not.

Anonymous said...

> ... if anything requires me to run anything that includes anything closely to an application server during my development it is an absolute no go for me.


Is Tomcat + Spring + Hibernate + Quartz + ... any different than a Java EE application sever? They are exactly the same thing, except with a real application server you don't have to build all the integrations yourself and manage library upgrades etc. Plus with directory deploy and deploy on save in GlassFish with Eclipse and NetBeans, you can test your changes only a couple seconds after saving. With GlassFish V3 your web session is preserved. With EJB 3.1 and CDI you get spec defined ways to start/stop the container for integration tests with JUnit.

So, you have no point.

Anonymous said...

As both Reza and Gavin have pointed out in various articles, generalizing what EJB offers today through the CDI component model will be a very likely future direction.

In Java EE 6 there is some overlap now between CDI, good old JSF managed beans, and the EJB enterprise beans. They intergrate well, and all of them are 'managed' in some sense, but having 3 different models may indeed not be the most ellegant solution.

Yet, I think it's wise that in Java EE 6 it's done like this. Don't forget that CDI is very new. A lot of thinking and resources already went into EJB 3.1 before CDI was finalized. You just don't throw all of that overboard and redesign everything at the last moment around a brand new spec.

Now that CDI is there, and is going to be used in practice, let's see how EJB can build on this for EE 7.

Anonymous said...

Can we get same seamless (clustered) scalability
with web containers without EJBs ?
If the answer is yes and other ejb container services can be produced otherwise then
EJB's are gone ?

Anna said...

Great and Useful Article.

J2EE Training

Java EE course

Java EE training

J2EE training in chennai

Java J2EE Training Institutes in Chennai

Java J2EE Training in Chennai

Java EE training

Java Interview Questions

Devi.Angularjs said...

Hibernate Training Institutes in ChennaiHibernate Training Institutes in Chennai Hibernate Online Training Hibernate Online Training Hibernate Training in Chennai Hibernate Training in Chennai Java Online Training Java Online Training

Post a Comment