Enterprise Java and Rational Rose -- Part I - Enterprise JavaBeans
(Page 4 of 6 )
What Are Enterprise JavaBeans?
The primary purpose of Enterprise JavaBeans (EJBs) is to simplify the development of business logic. EJBs, which are non-visible, server-side beans, fulfill this purpose by specifying a general, server-side framework for building distributed and secure components, which support transactions out of the box.
So, you may ask, who provides all this distribution and security infrastructure? The answer is vendors such as IBM and BEA. When vendors indicate their compliance with the J2EE EJB specification, they are signaling that they conform to the specifications.
EJBs fall into two very distinct categories:
- Session beans. Think of these as beans that implement workflows or processes (for example: making a hotel reservation, transferring funds from one account to another, etc). These are by nature transient activities. Once the task is complete, the bean has no reason to exist.
- Entity beans. These are object-oriented representations of persistent data residing in relational databases (for example: a representation of hotels in Seattle, a business's customers, your bank accounts).
Each EJB has a remote interface as well as a home interface, as shown in Figure 5. EJBObject and EJBHome implement these interfaces, respectively. The client never actually interacts with the bean directly; instead it calls methods on some objects that you, as the bean creator, had nothing to do with.
The primary purpose of the home interface is to provide a "factory" interface for the EJBs. Clients use the home interface to address questions such as how to locate an EJB, how to create an EJB, or how to delete an EJB. For example, a client creates an EJB by using the home interface's create methods. Remember that these are methods that the developer of the EJB provided. The create() methods, of course, are not implemented by the EJB. Instead, they simply correspond to "ejbCreate" methods in the EJB itself, which get called in response to a create method call.
The remote interface covers everything else. It is implemented by the EJBObject, which, in essence, wraps the EJB and knows all about networking, transactions, security, and so on. EJBObject, through the remote interface, exposes the business methods implemented by the bean and delegates them when the business methods are invoked. The EJBObject provides other services, such as a way to test whether two EJBObjects are identical, identify the corresponding home object for the EJBObject, etc.
What is the upside of such a complex architecture? Well, for one thing, it means that no matter where the bean is located, the client doesn't need to do anything differently. So you can easily change things without breaking the application.
Second, it enables the container to intercept the requests so that it can provide all those services that you get from your runtime environment. Do you want only a certain group of people to access a specific business method? No problem. If the deployer specifies security attributes at deployment time, then, when the method is invoked, the container can intercept it to make sure only the authorized people are trying to access it. The same is true for transactions, persistence, etc.
Session Beans
As we mentioned earlier, a session bean exists to carry out a specific task on your behalf. Think of it as an extension of a client program that executes on the server side.
Now imagine that you are doing some bank transactions and using a session bean. Would it make sense for the bean also to perform tasks on behalf of another client who may be online at the same time? Obviously not, because your account information, etc., is specific to you. So session beans are typically private and cannot be shared. In essence, there is an ongoing interaction strictly between you and the session bean, and it maintains what is called "conversational state."
Typically, there is no persistence associated with your session, meaning that if your session ends abruptly, it is usually not possible to recover and continue on.
The EJB specification allows you to differentiate between the session beans as either stateless or stateful.
- Stateless session beans typically carry out "atomic" operations. That is, the bean is asked to do something, and once the bean has fulfilled that request, the conversation between the client and the bean is over. A good example is a bean that implements a credit card authorization. You enter a number, the bean obtains the authorization, and it's done. Another party could then request another credit card authorization, and a new session could be started using the same bean. In other words, the container does not save any value for the bean attributes during the session.
- Stateful session beans are useful for more complex activities. These beans remember things from one method call to another, so you could call a bean repeatedly and continue your "conversation" or session. For example, if you were to go shopping on the Net and use a shopping cart to keep track of your purchases, a stateful session bean could represent that.
Entity Beans
The other type of EJB is called an entity bean. Entity beans were actually introduced in the first EJB spec, but the container providers were not required to support entity beans. That changed with the EJB 1.1 spec, and support for entity beans is now required for J2EE compliant application servers.
Entity beans provide an object-oriented view of the persistent data in a database. Things such as customer, employee, and account, as well as things such as banks, tickets, and reservations, all map nicely to entity beans, allowing you to work with objects rather than database records.
There are many advantages to using entity beans. For one, you can simply call methods (e.g., mybean.setdestination()) instead of dealing with obscure SQL queries. In addition, objectification allows you to reuse the entity bean concept throughout your system consistently.
Since an entity bean refers to database records, it needs to be uniquely identified. That's why you have a primary key for each entity bean. For example, for an employee entity bean, the primary key may be the employee ID.
From a user perspective, all the details of database access, synchronization, and so on, are all taken care of, and things become much simpler. For instance, the container ensures that the same method is not called concurrently, unless explicitly specified by the bean provider.
Since entity beans deal with databases, there has to be coordination between the two to keep things in sync. This process of coordination is referred to as "persistence."
Two types of persistence schemes are available for entity beans.The simpler one is called Container Managed Persistence (CMP). This is attractive because, as a bean developer, you simply tell the container to take care of things. You can have it take care of business logic, specify how entity bean attributes map to fields in the database, and then sit back and relax while the deployment utility actually generates all the SQL calls at deployment time.
The nice thing is that, by using CMP, your entity bean doesn't have to embed direct database queries. So it remains independent of the database, and hence easily portable.
But say you want more control over how the persistence is handled (e.g., you want to do it more efficiently than the auto-generated code). In that case, you can specify Bean Managed Persistence (BMP) and write all the database access logic as part of your bean.
Of course, the disadvantage of bean-managed persistence is that you now have to understand the database structure, know SQL, and do a lot more coding, too!
Next: Working with EJBs >>
More Development Cycles Articles
More By The Rational Edge
