While the Enterprise JavaBeans specification is the ultimate authority on the EJB framework, it's primarily useful to vendors such as Inprise who build the EJB servers and containers the beans run in. This book will help you, the JBuilder developer, learn what you want to know about developing enterprise beans and creating applications that use them.
If you are already familiar with EJB development and want to get started creating enterprise beans with JBuilder, start with "Developing enterprise beans with JBuilder".
Gradually the benefits of dividing applications into more than the two tiers of the client-server model becomes apparent. In a multi-tier application, only the user interface stays on local machines while the logic of the application runs in the middle tier on a server. The final tier is still the stored data. When the logic of an application needs updating, changes are made to the software of the middle tier on the server, greatly simplifying the management of updates.
But creating reliable, secure, and easily managed distributed applications is notoriously difficult. For example, managing transactions over a distributed system is a major task. Fortunately using components that follow the EJB specification to build distributed systems relieves much of the burden by:
For example, if the application is an accounting system, the enterprise bean developer would need to understand accounting. The system administrator must know about monitoring a deployed and running application. Each specialist assumes a particular role.
The EJB server provider and EJB container provider (who are often the same vendor) handle many of the more difficult tasks so the developers don't have to. For example, the container an enterprise bean runs in can provide transaction and security services to the bean automatically.
Once a bean is written, it can be deployed on any EJB server that adheres to the Enterprise JavaBeans (EJB) 1.1 standard.
Bean providers (also called bean developers) create the enterprise beans and write the logic of the business methods within them. They also define the remote and home interfaces for the beans and they create the beans' deployment descriptors. Bean providers don't necessarily need to know how their beans will be assembled and deployed.
Application assemblers write the applications that use the enterprise beans. These applications usually include other components, such as GUI clients, applets, Java server pages (JSP), and servlets. These components are assembled into a distributed application. Assemblers add assembly instructions to the bean deployment descriptors. Although application assemblers must be familiar with the methods contained within the enterprise beans so they can call them, they don't need to know how those methods are implemented.
JBuilder users who are interested in Enterprise JavaBeans are usually bean providers and application assemblers. Therefore, this book is written primarily for them. JBuilder has wizards, designers, and other tools that simplify the development of enterprise beans and the applications that use them.
EJB server providers are specialists in distributed transaction management, distributed objects, and other low-level services. They provide an application framework in which to run EJB containers. EJB service providers must provide, at a minimum, a naming service and a transaction service to the beans.
EJB container providers provide the deployment tools required to deploy enterprise beans and the runtime support for the beans. A container provides management services to one or more beans. They communicate for the beans with the EJB server to access the services the bean needs.
In almost all cases, the EJB server provider and the EJB container provider are the same vendor. The Inprise Application Server provides both the server and the container.
Deployers understand the operation environment for distributed applications. They adapt the EJB application to the target operation environment by modifying the properties of the enterprise beans using the tools provided by the container provider. For example, deployers set transaction and security policies by setting appropriate properties in the deployment descriptor. They also integrate the application with existing enterprise management software.
Once an application is deployed, the system administrator monitors it as it runs, and takes appropriate actions if the application behaves abnormally. System administrators are responsible for configuring and administrating the enterprise's computing and networking infrastructure that includes the EJB server and EJB container.
Because our interest is how to develop enterprise beans, our focus is the middle tier.
The EJB server and EJB container together provide the environment for the bean to run in. The container provides management services to one or more beans. The server provides services to the bean, but the container interacts on behalf of the beans to obtain those services.
Although it is a vital part of the Enterprise JavaBeans architecture, enterprise bean developers and application assemblers don't have to think about the container. It remains a behind-the-scenes player in an EJB distributed system. Therefore, this book goes no further explaining what a container is and how it works. For more information about containers, refer to the "Enterprise JavaBeans 1.1 Specification" itself. For specific information about the Inprise EJB container, see the Inprise Application Server's Enterprise JavaBeans Programmer's Guide.
The home interface defines the methods a client uses to create, locate, and destroy instances of an enterprise bean.
The remote interface defines the business methods implemented in the bean. A client accesses these methods through the remote interface.
The enterprise bean class implements the business logic for the bean. The client accesses these methods through the bean's remote interface.
Once the bean is deployed in the EJB container, the client calls the create()
method defined in the home interface to instantiate the bean. The home interface isn't implemented in the bean itself, but by the container. Other methods declared in the home interface permit the client to locate an instance of a bean and to remove a bean instance when it is no longer needed. The EJB architecture diagram omits the home object.
When the enterprise bean is instantiated, the client can call the business methods within the bean. The client never calls a method in the bean instance directly, however. The methods available to the client are defined in the remote interface of the bean, and the remote interface is implemented by the container. When the client calls a method, the container receives the request and delegates it to the bean instance.
Session beans can maintain the client's state, which means they can retain information for the client. The classic example where a session bean might be used is a shopping cart for an individual shopping at an online store on the web. As the shopper selects items to put in the "cart," the session bean retains a list of the selected items.
Session beans can be short-lived. Usually when the client ends the session, the bean is removed by the client.
Session beans can be either stateful or stateless. Stateless beans don't maintain state for a particular client. Because they don't maintain state, stateless beans can be used to support multiple clients.
Unlike session beans, entity beans are considered to be long-lived. They maintain a persistent state, living as long as the data remains in the database, rather than as long as a particular client needs it.
The container can manage the bean's persistence, or the bean can manage it itself. If the persistence is bean-managed, the bean developer must write code that includes calls to the database.