
	Corporate Info \| News \| Solutions \| Products \| Partners \| Services \| Events \| Download \| How To Buy
	e-docs \| Site Map \| Search \| Contact \| Glossary \| WebLogic Server Documentation

Overview of WebLogic Enterprise JavaBeans

Enterprise JavaBeans (EJB) is a component architecture for building distributed, object-oriented business applications in Java. This whitepaper describes the basic features of WebLogic's implementation of the JavaSoft EJB specification, and discusses the benefits of using WebLogic EJB. More detailed technical information is available in BEA WebLogic Server Enterprise Java Beans.

Contents: What are Enterprise JavaBeans?; How do EJB and RMI differ?; What are the major benefits of EJB?; How does WebLogic support EJB?; How do EJB and "ordinary" JavaBeans differ?; Summary

What are Enterprise JavaBeans?

The JavaSoft Enterprise JavaBeans (EJB) specification defines a component architecture for building distributed, object-oriented business applications in Java. The EJB architecture addresses the development, deployment, and runtime aspects of an enterprise application's life cycle.

An Enterprise JavaBean encapsulates business logic in a component framework that manages the details of security, transaction, and state management. Low-level details such as multi-threading, resource pooling, clustering, distributed naming, automatic persistence, remote invocation, transaction boundary management, and distributed transaction management are handled by the EJB "container." This allows the EJB developer to focus on the business problem to be solved.

An Enterprise JavaBean is, in essence, a transactional and secure RMI (or CORBA) object, some of whose runtime properties are specified at deployment time using special classes called "deployment descriptors."

With the EJB model, you can buy or develop business components (such as invoices, bank accounts and shipping routes) and, during deployment into a certain project, specify how the component should be used -- which users have access to which methods, whether the framework should automatically start a transaction or whether it should inherit the caller's transaction, and so on.

In this scenario, an EJB contains the business logic (methods) and the customization needed for a particular application (deployment descriptor), and the EJB will run within any standard implementation of the EJB framework.

The spirit of "write once, run anywhere" carries through into EJB: a vendor's EJB framework can run any third-party Enterprise JavaBeans to make up an application. Nuances of the security mechanisms and specific distributed transaction monitors are entirely abstracted out of the application code (unless the bean author chooses to make such calls explicitly).

Types of beans

An EJ bean can be one of two types:

"Entity" bean (used for an object-oriented, persistent approach)
An Entity bean contains persistent data and a specific bean represents a set of fields in a datastore.
"Session" bean (service-oriented approach)
A Session bean merely provides a service, and does not itself represent any persistent data. It can be thought of as a "business logic" bean. Any persistent data is in objects passed as a parameter. Any instance of a session bean can provide the service; they are interchangeable. The bean is responsible for ensuring appropriate transactional guarantees on its methods.

For example, one method of accessing bank accounts could be through an AccountBean: an entity bean, it represents a specific bank account, and has a specific state (account) associated with it.

Another method of accessing the accounts could be through a TellerBean: a session bean, it is stateless, and its interface expects the caller to spell out exactly which account to operate on. Once a transaction is over, the TellerBean can be reused to work on a different bank account, since the caller will not care which teller it is using.

With an AccountBean, you would say account.deposit(300); with a TellerBean, you would say teller.deposit(account, 300).

How do EJB and RMI differ?

EJB and RMI have similar calling conventions -- to the client, they look identical.
RMI does not require transactions and security, though it does not preclude a framework from supplying these features. EJB explicitly requires both features.
the EJB framework provides object services, only one of which is remote access; it includes transactions and security, and in the case of WebLogic, a host of other services.

What are the major benefits of EJB?

These are the stated goals of EJB:

Enterprise JavaBeans will be the standard component architecture for building distributed object-oriented business applications in Java. EJBs will make it possible to build distributed applications by combining components developed using tools from different vendors.
EJBs will make it easier to write applications: Application developers will not have to deal with low-level details of transaction and state management, multi-threading, and resource pooling. However, an expert-level programmer will be allowed to gain direct access to the low-level APIs.
EJBs applications will follow the "write-once, run anywhere" philosophy of Java. An enterprise bean can be developed once and then deployed on multiple platforms without recompilation or source code modification.
The EJB architecture will
- Address the development, deployment, and runtime aspects of an enterprise application's life cycle
- Define the contracts that enable tools from multiple vendors to develop and deploy components that can interoperate at runtime
- Be compatible with existing server platforms; vendors will be able to extend their existing products to support EJBs
- Compatible with other Java APIs
- Provide interoperability between enterprise beans and non-Java applications.
- Be compatible with CORBA

How does WebLogic support EJB?

Major advantages of the WebLogic EJB implementation include:

WebLogic EJB is designed to be highly scalable. This is a critical issue with EJB since the point of EJB is transaction processing -- an application model typically requiring a high degree of scalability.
WebLogic EJB supports the features required by the Enterprise JavaBeans 1.1 specification. Moreover, additional features and performance tuning capabilities have been implemented as well, and are described in The WebLogic Server EJB Container.
WebLogic EJB works seamlessly with other WebLogic facilities, such as Events, JNDI, remote streams, and multitier JDBC.
WebLogic EJB includes an easy way to specify deployment descriptors. Using the DeployerTool utility, deployers specify deployment properties in a graphical user interface. The required XML deployment files are updated automatically in the associated EJB .jar file.

How do EJB and "ordinary" JavaBeans differ?

It's important to understand that Enterprise JavaBeans are different from the "ordinary" JavaBeans that are used in many integrated development environments (IDEs).

There is an unfortunate use of the term "JavaBeans" that causes much confusion. JavaSoft originally introduced JavaBeans to refer to Java classes that were designed according a set of conventions. These conventions enabled the components to be examined dynamically by a development tool and used in the construction of applications. These components, or JavaBeans, can be specialized for particular uses in applications. A convention for generating and receiving events is part of the convention, allowing beans to be "connected together" by a development tool.

The most common examples are graphical in nature. For example, a GUI pushbutton widget can be developed as a bean. Any compliant development tool can examine the button bean and determine its properties (e.g., size, shape, label, color, etc.) and can connect to the bean's methods (e.g., program the bean to respond to the user clicking on the button). A specialization of the button might be a specific instance of it on a specific panel with a label of "Exit."

Enterprise JavaBeans are also components, but their similarity to JavaBeans ends there. EJB does not implement the same conventions as JavaBeans: EJB has its own distinct interfaces and conventions. The purpose of EJB is to provide a server-side encapsulation of application logic for security and transactional purposes. It does not have the development tool semantics of JavaBeans.

An example of an EJB might be a business entity such as an invoice. Access to the invoice is controlled by an access control list associated with the bean, and updates to the invoice or any of its line items must done as an atomic transaction. The EJB framework removes the need to deal with ACLs or transaction boundaries from the bean. If multiple EJBs participate in a single transaction, the EJB framework manages the distributed transaction.

WebLogic implements both kinds of beans: Enterprise JavaBeans and WebLogic Beans (i.e., JavaBeans). Each has its place in the application architecture, and each is well supported by the WebLogic framework.

The Enterprise JavaBean specification (java.ejb package) shares little with the "ordinary"JavaBeans specification, save for the fact that both specifications have the term "bean" in them, and that both strive to build components (beans).

Summary

This paper has described how WebLogic EJB, while offering the developer the flexibility and universality of the JavaSoft standard, provides the power and performance necessary for a production environment. Because WebLogic's EJB implementation depends upon and takes advantage of the sophisticated infrastructure of WebLogic, WebLogic EJB is fast and scalable, with many additional features that support real-world use of EJB for building complex, distributed systems that depend on security, transactions and state management.

For more technical information, read BEA WebLogic Server Enterprise JavaBeans.

Other related documents: WebLogic Server EJB Design and Development; Deploying EJBs with DeployerTool; Example EJBs