Enterprise JavaBeans (EJB) has generated a great deal of excitement since the March 1998 announcement of the Enterprise JavaBeans Specification Version 1.0. Companies such as Oracle, Borland, Tandem, Symantec, Sybase, and Visigenic, among many others, have announced and/or delivered products that adhere to the EJB specification. This month, we’ll take a high-level look at what exactly Enterprise JavaBeans is. We’ll go over how EJB differs from the original JavaBeans component model, and discuss why EJB has generated such an enormous amount of interest.
But first, an advisory: we won’t be looking at source code or how-to topics this month. This article isn’t a tutorial; rather it’s an architectural overview. EJB covers a lot of territory, and without first understanding the basic concepts involved, code snippets and programming tricks are meaningless. If there’s interest on the part of JavaWorld‘s readers, future articles may cover the specifics of using the Enterprise JavaBeans API to create your own Enterprise JavaBeans.
In order to understand why EJB is so attractive to developers, we need some historical background. First, we’ll look at the history of client/server systems, and at the current state of affairs. Then, we’ll discuss the various parts of an EJB system: EJB components — which live on an EJB container running inside an EJB server — and EJB objects, which the client uses as a kind of "remote control" of EJB components. We’ll go over the two types of EJBs: session and entity objects. You’ll also read about home and remote interfaces, which create EJB instances and provide access to the EJB’s business methods, respectively. By the end of the article, you’ll have an idea of how extensible servers can be built using Enterprise JavaBeans. But first, a look back in time
