Head First EJB

No more vendor lock-in!

Enterprise beans are portable—not just to different JVM’s, but to different EJB servers.

One of the reasons we all love Java is its portability across multiple platforms. The whole write-once-run-anywhere (WORA) thing.

EJB takes portability to a new level, instead of write-once-run-anywhere, it’s write-once-deploy-anywhere (WODA). Just as WORA frees you from being forced to work on a single OS, WODA frees you from being at the mercy of your application server vendor. And then of course there’s YODA, but we digress.

In the old days, each application server vendor had its own proprietary API. You learn it, work with it, and finally get your enterprise apps up and running. And then guess what? You need a new feature. And then guess what? Your vendor says, “We’re considering that for Q3... of next year”. Now what? Like a drug dealer, they’ve hooked you, and now it’s just too painful to consider giving them up. Give them up for what? Another vendor and another proprietary API and more lock-in.

One of the crucial benefits of EJB is WODA. And now the vendors have to compete not just to sell you in the first place, but to keep you. Because as everybody knows, you can just pack up your beans and go elsewhere.

There are no Dumb Questions

Q:	Q: What’s the difference between EJB and J2EE?
A:	A: Both J2EE and EJB are specifications for a server. But EJB is actually a subset of J2EE. In other words, a J2EE server must include an EJB container. We’ve used the word server on these first pages, but technically, the thing that enterprise javabeans run in is called an EJB container. So, every J2EE server must include an EJB container (along with a Web container that can run servlets and JSPs). This exam is about the EJB portion of J2EE, whereas the SCWCD exam (Sun Certified Web Component Developer) is about the Web portion of J2EE. Later in this chapter, we’ll get more into the details of how J2EE and EJB fit together. For the rest of this book, we use the terms EJB server, container, and server interchangeably. If the difference between the terms matters, we’ll make it clear.
Q:	Q: Can I use EJB components without an EJB-compliant app server?
A:	A: Nope. EJB components can’t live outside of an EJB container. They don’t have a main method, and even if you add one to your bean class, the bean wouldn’t be very useful on its own. Most of the methods in an enterprise bean are called by the container itself and have no meaning outside the server. Remember, the whole point of an EJB server is to give you all the big services (security, transactions, etc.), and without the server, you’d lose everything but your basic business logic. And if that business logic relies on the container (for example, calling methods on interfaces provided by the container), then even the business logic would fail.
Q:	Q: Can I design and write my code in such a way that most of the business logic is in a plain old Java class, and just have the bean call methods on that class? That way I could still reuse the business logic...
A:	A: Yes, you can do that, and in fact a lot of designers write separate non-bean, reusable classes and then have the beans invoke methods on those classes. If your bean calls a method on a non-bean Java class, that method is still under the control of the container, so as far as the container is concerned, that non-bean method is just part of the bean’s functionality.
Q:	Q: What’s the difference between regular javabeans and enterprise javabeans?
A:	A: Congratulations! You’re the 3 millionth person to have asked that question. The term “javabean” means a reusable component. Regular old non-enterprise beans (and beans is just a shorter form of javabeans), are reusable components that follow a naming convention that can be used by development tools. By far, the most common type of javabean is any GUI component (like a Swing button or text field). Nearly all Java IDEs are javabean-compliant, so that if you’re working in a visual layout tool you can click on a button and up pops a property sheet where you can set the color, size, font, etc. The tool knows which properties the bean has because the bean follows conventions for getters and setters. But regular javabeans aren’t just for GUI components—other Java technologies, including Jini and Servlets, can use javabean features. Enterprise javabeans are also reusable components, but that’s where the similarity ends. The ‘bean’ part of a regular javabean is used mostly at development-time, as a way to ease or speed up hooking one bean’s events to another bean’s methods, or setting property values (which often mean the same thing as instance variable values). A regular bean runs in a JVM, just like any other normal Java class. But the “bean” part of an enterprise bean kicks in at runtime, and an enterprise bean must be run under the control of an EJB container. For the rest of the book, when we say bean, we mean enterprise bean.