Java Reference
In-Depth Information
D
ISTRIBUTED
C
OMPUTING
Enterprise JavaBeans bring the benefits of Java-built components to distributed,
transaction-oriented systems. An EJB can be instantiated (that is, created) on a re-
mote system and then respond to message requests from an application on a local
system. Furthermore, EJBs can contain and manage transaction definitions. EJBs
automatically participate in a transactional model as defined by your application.
(In a transactional model, either all the work in a transaction is guaranteed to be in-
tact, or committed to a database, or none of it is.)
Unfortunately, EJBs and ordinary JavaBeans share the same name. This has un-
doubtedly been the source of endless confusion among inexperienced developers,
recruiters, and nontechnical managers. The fact is that EJBs and ordinary JavaBeans
have very little to do with each other. Their only real thread of commonality is that
both EJBs and ordinary JavaBeans are attempts to move software development in a
more componentized direction.
JavaBeans are Java components defined in a way that makes them easy to use.
In most functional respects, the JavaBeans specification is similar to the ActiveX
specification, except what is specific to Java. JavaBeans are simply regular Java
classes that employ a certain convention for getting and setting their internal val-
ues or properties. When a JavaBean implements the JavaBean API, the class is able
to interact with other Java classes in a simple, standard fashion. For example, the
GUI design tools that are a part of many integrated development environments ex-
pect you to code JavaBeans.
In contrast, EJBs are business logic components. They are designed to provide
back-end business logic, particularly for thin client applications. They operate
through interfaces and are largely ignorant of what is happening between the
human and client application. Best of all, EJBs don't have to manage the complex
system plumbing that is normally associated with remote component management
and transaction integrity control. All these system-level issues (e.g., component in-
vocation, life-cycle management, security, and transaction semantics) are handled
by the EJB infrastructure. A major design objective of the EJB spec is to allow de-
velopers to focus on writing code that solves the business problem(s) at hand rather
than the technical issues surrounding the management of remote distributed com-
ponent services.
The EJB specification is primarily an effort to standardize remote component-
management techniques available to Java components. It also attempts to simplify
and improve existing techniques, such as Common Object Request Broker Archi-
tecture (CORBA) and Distributed Component Object Model (DCOM). EJB is very
Java-centric; it fits naturally into the Java language.
