The EJB Distributed Object Model
| Enterprise JavaBeans are not JavaBeans; they simply have a similar name because, like JavaBeans, they are components. But EJBs are not merely components they are distributed components that interoperate by means of proxies. This means that they are not called directly like JavaBeans, but indirectly, through a somewhat complicated mechanism, in order to provide location transparency. Location transparency means that a client does not need to know or explicitly determine the location of a remote object. From the point of view of the client application, the following steps are required to call an EJB method:
Behind the scenes, the client application doesn't actually call the EJB object directly; instead, it calls a local stub that serializes the parameters called marshalling the data and sends them to the EJB object on the server. The EJB object unmarshalls the data, converting it back into Java objects and primitives. This is the first layer of indirection, and it is the key to achieving location transparency. The EJB object is responsible for managing transactions, security, and resources everything but the business methods that we define in our bean implementation. Once any necessary services, such as authentication, have been performed, the EJB object ultimately calls the bean implementation to perform the business logic. This is the second layer of indirection, and it allows the EJB container to intercept and intercede in method calls in order to provide services. To enable this process to work, we (possibly with the aid of a software tool) need to write four pieces of code:
Notice that, of these, only the bean implementation is an actual class that is compiled into executable code. The other three files are essentially declarative the application server and its deployment tools use these interfaces to create the glue-code, including a number of wrapper classes, to support our bean implementation as a distributed component. Once an EJB is deployed to an application server, the application server manages the life cycle of the bean. Depending on the type of bean and other factors (such as load), the application server may instantiate the bean, populate it with data from the database, save it to disk temporarily, update the database, or destroy the bean, as different calls are made by a client application. As mentioned previously, there are three kinds of beans:
We'll next take a brief look at each of these. Session BeansSession beans are typically used to implement business methods. They are associated with actions and processes, and are sometimes described as verbs. There are two types of session beans:
Stateless Session BeansStateless session beans are used when it is not necessary for the bean to maintain information about the client between method calls. A stateless session bean might be used to build a data analysis component, for example, that accepts input data, processes it, and returns a result of some sort. Another example might be a pricing component that accepts a bill of materials as input and returns the calculated cost that takes into account factors such volume discounts; in this case, the session bean may, in fact, be a façade bean that works in conjunction with other beans to retrieve prices from a database or other systems. Stateful Session BeansStateful session beans are used when the bean must maintain information often called conversational state about the client between method calls. This is usually the case for beans that support an interactive application. A common example is the ubiquitous shopping cart used by Web applications to allow a user to browse a catalog and add or remove items to an order. Session Beans and PersistenceSession beans are not persistent objects. This means that, once the client closes the session (or the EJB container is shut down or crashes), the information that it stored is not saved. The principal difference between session beans and standard Java objects is that session beans are distributed objects. Like standard Java objects, any data they contain is lost as soon as they cease to exist. Even though session beans are not persistent objects, it doesn't mean that they cannot use persistent data. They are entirely capable of using a database to store or retrieve data. Session beans are sometimes more efficient than entity beans for accessing data from a database, especially for providing read-only access. Session beans are often used to provide a wrapper, or façade, for one or more entity beans. When multiple entity beans are used, a session bean façade can provide greater control and flexibility in setting transaction boundaries. Entity BeansThe primary characteristic of entity beans is that they represent persistent information about people, places, or things. They are sometimes called nouns. Persistent in this case means that the information in an entity bean is saved, even if the client application closes its session or the EJB container is shut down or crashes this is an assurance that the vendor of an application server must provide. This persistence could, in theory, be implemented in many ways, such as writing to operating system files, but in practice, a database is used usually a standard relational database, such as Oracle. There are two types of entity beans:
CMP BeansIn the previous chapter, we saw an example of a CMP entity bean. Each bean was mapped to a row in a database table, and the EJB container managed all database access behind the scenes. We only used the CMP bean to retrieve data in that example, but the EJB can also automatically update the database behind the scenes as we create, update, and destroy CMP beans. When we used a wizard in JDeveloper to create the CMP from a database table in the last chapter, the only option it provided was to map the bean to a single row of a table or view. Based on our selection, it created the EJB deployment descriptor, an XML file that describes this mapping. If we need more flexibility than that offered by the JDeveloper wizard, we can create or modify this file ourselves. Not only can we be more selective about mapping columns, but by using a special query language, EJB-QL, we can also define the SQL that the container will use, as well. BMP BeansIn a BMP entity bean, we write the persistence code ourselves. To do this, we need to implement a set of methods specified by the EntityBean interface, usually using JDBC, that create, delete, retrieve, and update the database table or tables corresponding to our bean. Choosing Between CMP and BMP BeansChoosing between CMP and BMP is not always easy. Here are some considerations:
Both actually have a lot going for them and present no serious disadvantages. Given that CMP is easiest to use and excellent for prototyping, the best approach may simply be to use CMP at first and move beans to BMP if it proves necessary later as you gain better understanding of the problem and greater experience with EJB. Using Session Beans Instead of Entity BeansA more important question is whether to use entity beans at all. Sometimes, a session bean with JDBC may be easier to develop and may perform better than an entity bean, because entity beans have much more overhead. On the other hand, attempting to code a complex relationship in a session bean using JDBC could become unwieldy, and entity beans may be better suited to this type of task. Answering this question will ultimately depend on your (and possibly your teammates') experience and the application requirements. Message-Driven BeansMessage-driven beans are fundamentally different from session and entity beans in that they do not use a remote execution protocol. Message beans are invoked asynchronously using a messaging service; because there is no guarantee that the message will be delivered in a timely manner, the client does not wait for a reply. The system may be set up so that the client will hear back from the message bean later via email. The issues involved in developing message-driven beans are not typically database-related and we won't consider them here any further. |
EAN: 2147483647
Pages: 71