J2EE in a nutshell

J2EE specifies Enterprise Java Beans for handling data, where the data and the client accessing it may or may not be on the same system. Entity beans are used to encapsulate the data in the database—instead of accessing the database directly, you create an entity bean to do it for you. That way the client can use the entity bean and not need to know about SQL.

However, the person writing the entity bean doesn’t really want to have to know about SQL either. That database stuff makes writing an entity bean a pain, so container-managed persistence was introduced. This allows you to let the EJB container (part of your J2EE server) handle the messy database stuff for you, and you don’t have to know any SQL at all.

Of course, SQL allows you to do a lot of useful things, such as querying databases in complex ways. It turned out that doing those things by fiddling around with container-managed entity beans was a real pain in the ass. So in EJB 2.0, Sun added EJB QL, the Enterprise JavaBean Query Language. It’s just like SQL, only slightly different, and not as powerful.

Of course, performance was getting pretty crappy by this point, so to improve things, EJB QL can be compiled into SQL.

So to summarize, here’s the old ugly way of doing things:

  • Client program connects to database server.
  • Client program sends SQL query to database server.
  • Client program gets back data from database server.

Now here’s the new, improved way of doing things:

  • Client program connects to J2EE server.
    • J2EE server instantiates entity bean.
    • Entity bean opens connection to database.
  • Client program sends EJB QL query to J2EE server.
    • Entity bean compiles EJB QL into SQL.
    • Entity bean sends SQL query to database.
    • Entity bean gets back data from database.
    • Entity bean passes back data to J2EE server.
  • Client program gets back data from J2EE server.

Obviously this is a big improvement. What’s more, because of the use of EJB, all of the J2EE entity bean stuff can be placed on a separate machine from the client and the database server. In fact, for performance reasons you’d be well advised to do so.

So, before: client system, database server. After: same client system, huge $20,000 server running $50,000 of J2EE application server software, same database server. Now your client software can send queries that look just like SQL, and get back results exactly as if they came from a database server—but instead, they’re coming from a box with that wonderful Java technology.

Learning J2EE, continued

I’ve just successfully written an EJB, deployed it, and called it from a servlet and some JSP.

Right now, it looks like the EJB specification has the highest complexity-to-benefit ratio I’ve ever encountered in a programming API. Sure, I’m a beginner to J2EE, but I’m an experienced software developer, and over the years I’ve developed an intuitive ability to recognize a pile of steaming crap when I see one.