An EJB is a server-side component that executes specific business logic. EJBs run on a server and are invoked by local or remote clients. A standardized contract exists between an application server and its EJB components that enables a component to run within any application server. The application server provides clearly-defined services while the components adhere to a standard interface. EJBs are not GUI components; rather, they sit behind the GUIs and perform all the business logic, e.g. database CRUD operations. GUIs such as rich clients, web-based clients, and web services are the clients that can make connections to EJBs.The original JavaBeans specification is based on the java.beans package which is a standard package in the JDK. Components built in the JavaBeans specification are intraprocess components that stay in one address space and are typically used for Graphical User Interface (GUI) visual widgets such as buttons, tables, HTML viewers, etc. On the other hand, the EJB specification is based on the javax.ejb package, which is a standard extension package. EJB is one of several specifications grouped into Sun Microsystem’s Java 2 Enterprise Edition (J2EE) specification. Components built in the EJB specification are interprocess components that stay in multiple address spaces as distributed objects. These components are used as transactional business objects that are accessed as remote objects.
So we have:
- EJB is a framework for writing distributed programs.
- EJB involves a standardized agreement that enables a component to run within any application server (increasing code reuse).
- The agreement is accomplished by implementing a set of Java interfaces from the EJB API.
- EJBs are not GUI components.
EJB is a heavyweight framework. Deciding to implement EJB on your next project should only be done after weighting their pros and cons versus more lightweight solutions, such as Hibernate, JDO, or straight SQL. If you need a distributed solution, consider adding RMI-IIOP or CORBA options to the mix. Following are some things to consider when making the decision of whether or not to use EJB:
Advantages of EJB:
- Many vendor application servers conform to the J2EE specification allowing one to select a best-of-breed solution.
- To handle fluctuations in resource demand server-side resources can easily be scaled by adding or removing servers.
- Application servers provide access to complex services, namely transaction and security management, resource pooling, JNDI (Java Naming and Directory Interface), component lifecycle management, etc.
Disadvanatges of EJB:
- EJB has a large and complicated specification.
- EJBs take longer to develop. Also, when things go wrong they can be more difficult to debug. Occasionally the bug may not be in your code but in the application server itself.
- No sooner have you deployed your EJB application than you see a new specification coming down the pipe with newer features, rendering your application obsolete. This situation, however, is unavoidable with cutting-edge technologies.
Some rules of thumb for when not to use EJB include:
- Do not choose EJB when there is no need for scalability, transaction management, or security.
- Do not choose EJB if you anticipate low numbers of read-only users.
- Do not choose EJB if your team lacks EJB experience or cannot quickly obtain that experience. The EJB learning curve is steep and overcoming it can easily derail an otherwise viable project.
The EJB Ecosystem
To have an EJB deployment up and running, one needs more than an application server and components. There are six more parties that are involved:
- The Bean provider: The bean provider supplies the business components to the enterprise applications. These business components are not complete applications but can be combined to form complete enterprise applications. These bean providers could be an ISV selling components or an internal component provider.
- The Application Assembler: The application assembler is responsible for integrating the components. This party writes applications to combine components so as to develop the target application that can be deployed under various environments.
- The EJB Deployer: After the application developer builds the application, the application must be deployed on the server. This involves configuring the security parameter settings, performance tuning, etc. An application assembler is not familiar with these issues. This is where the EJB deployer comes into play.
- The System Administrator: The system administrator is responsible for the upkeep and monitoring of the deployed system and may make use of monitoring and management tools to closely observe the deployed system.
- The Container and Server providers: The container provider supplies the EJB container (an application server). This is the runtime environment where the beans live. The container supplies the middleware services to the beans and manages them. Some of the various containers are: BEA’s WebLogic, iPlanet’s iPlanet Application Server, IBM’s WebSphere, Oracle’s Oracle 9i Application Server and Oracle 10g Application Server, and the JBoss open source Application Server. The server provider is the same as the container provider.
- The Tool Vendors: There are various IDEs available to assist the developer in rapidly building and debugging components, for example Eclipse, NetBeans, and JBuilder. For the modeling of components one can use Rational Rose. There are many other tools, some used for testing (JUnit) and others used for building (Ant, XDoclet).
Different Beans for Different Tasks
There are three different types of beans in EJB: session, entity, and message-driven. Each has a specific purpose:
- Session Beans: Represent an action or process that must be executed synchronously, such as making a reservation or validating a credit card.
- Message-Driven Beans: Also represent an action or process. But, message-driven beans are executed asynchronously.
- Entity Beans: Represent data; each entity bean represents a unique record in the database.
Types of Beans
Session Beans are actions that can be executed by client code, such as making a reservation or charging a credit card. When a client wants to perform any of these actions, a session bean should be used. The session bean decides what data to modify. Typically, the session bean uses an entity bean to access or modify data, although it can use any technology that makes sense, for example, JDO, JDBC, or direct file access. Session beans represent business processes to be performed. They implement business logic, business rules, algorithms, and work flows. Session beans are relatively short-lived components. Their lifetime is equivalent to a client session. For example, if the client code invokes a session bean to perform credit card validation, the EJB container creates an instance of that session bean. After performing the business logic, if the client disconnects or terminates the session, the application server may destroy the session bean. The length of the client’s session generally determines how long a session bean is in use. The EJB container may destroy a session bean if its client times out. Typically, session beans neither survive application server crashes nor machine crashes. Session beans are not persistent, i.e. they are not saved to permanent storage such as a database. A session bean can perform database operations, but session beans themselves are not persistent.
Based on the possible types of conversations between a client and a bean, there are two types of session beans:
- Stateful Session Beans are beans that serve business processes that span multiple method requests or transactions. A stateful session bean retains its state across multiple method invocations made by the same client. If the stateful session bean’s state is changed during a method invocation, then that state will be available to the same client on the following invocation. For example, consider a customer using a debit card at an ATM machine. The ATM could perform operations like checking an account balance, transferring funds, or making a withdrawal. These operations could be performed, one by one, by the same customer. So the bean needs to keep track of the state for each of these operations.
- Stateless Session Beans are beans that serve business requests that span only a single method invocation. They are stateless because after each method call the container may choose to destroy a stateless session bean or recreate it, clearing all information pertaining to past transactions. The bean object may not be destroyed and instead may be shared by different clients who want to use the same session. For example, a stateless session bean could be a credit card verification component. This bean takes the credit card number, expiration date, holder’s name, and dollar amount as input and returns whether the credit card holder’s credit is valid or not. Once the bean’s task is over it is available to serve a different client and it retains no past knowledge of previous clients.
Entity beans deal with data. They typically represent nouns, such as a frequent flier account, customer, or payment. Plain old Java objects come into existence when they are created in a program. When the program terminates, the object is lost. But an entity bean stays around until it is deleted. A program can create an entity bean and then the program can be stopped and restarted–but the entity bean will continue to exist. After being restarted, the program can again find the entity bean it was working with and continue using it.
Plain old Java objects are used only by one program. An entity bean, on the other hand, can be used by any program on the network. Client programs just need to find the entity bean via JNDI in order to use it. Entity beans must have a unique primary key that is used to find the specific entity bean they want to manipulate. For example, an “employee” entity bean may use the employee’s social security number as its primary key. Methods of an entity bean run on a “server” machine. When a client program calls an entity bean’s method, the client program’s thread stops executing and control passes over to the server. When the method returns from the server, the local thread resumes execution.
Message-Driven Beans are enterprise beans that allow applications to process messages asynchronously. They act as a JMS message listener, which is similar to an event listener, except that it receives messages instead of events. The messages may be sent by any J2EE component–an application client, another enterprise bean, a Web component–or by a JMS application or system that does not use J2EE technology. The most visible difference between message-driven beans and session or entity beans is that clients do not access message-driven beans through interfaces. Unlike a session or entity bean, a message-driven bean has only a bean class.
In several respects, a message-driven bean resembles a stateless session bean:
- A message-driven bean’s instances retain no data or conversational state for a specific client.
- All instances of a message-driven bean are equivalent, allowing the EJB container to assign a message to any message-driven bean instance. The container can pool these instances to allow streams of messages to be processed concurrently.
- A single message-driven bean can process messages from multiple clients.
The instance variables of a message-driven bean can contain some state across the handling of client messages–for example, a JMS API connection, an open database connection, or an object reference to an enterprise bean. Session beans and entity beans allow you to send JMS messages and to receive them synchronously, but not asynchronously. To avoid tying up server resources, you may prefer to not use blocking synchronous receives in a server-side component. To receive messages asynchronously, instead, use a message-driven bean.