RMI and JavaBeans bring a standard distributed object framework and a component model, respectively, to the general Java environment. The Enterprise JavaBeans architecture builds on these foundations to provide a standard distributed component model for the enterprise Java environment. So, you may ask, how are EJB components different from "regular" RMI and CORBA distributed objects or nondistributed JavaBeans components? Well, in a nutshell (so to speak), an EJB includes the capabilities of both and adds an entire set of enterprise services. An EJB component has the remote capabilities of an RMI or CORBA object, in the sense that it can be exported as a remote object using RMI or RMI/IIOP. An EJB component is also a JavaBeans component since it has properties that can be introspected and it uses JavaBeans conventions for defining accessor methods for its properties. The EJB architecture provides a framework in which a developer can easily take advantage of transaction processing, security, persistence, and resource-pooling facilities provided by an EJB container. These facilities don't come for free, of course. You need to understand how they work and what rules your EJB object needs to follow in order to take advantage of these services. Enterprise JavaBeans are useful in any situation in which regular distributed objects are useful. They excel, however, in situations that take advantage of the component nature of EJB objects and the other services that EJB objects can provide with relative ease, such as transaction processing and persistence. A good example is an online banking application. A user sitting at home wants to connect to all of her financial accounts, no matter where and with whom they may live, and see them tied together into one convenient interface. The EJB component architecture allows the various financial institutions to export user accounts as different implementations of a common Account interface, just as we would do with other distributed object APIs. But since the Account objects are also EJBs, we can use the EJB server's transaction management capabilities to implement the Accounts as transactional components, which allows the client to perform a number of account operations within a single transaction and then either commit them all or roll them back. This can be a critical feature in financial applications, especially if you need to ensure that a supporting transfer can be executed before a withdrawal request is submitted. The transactional support in EJB ensures that if an error occurs during the transfer and an exception is raised, the entire transaction can be rolled back and the client-side application can inform you of the reason. And of course, an application such as this may also take advantage of any of the other EJB-related component services. The EJB component model insulates applications and beans (for the most part) from the details of the component services included in the specification. A benefit of this separation is the ability to deploy the same enterprise bean under different conditions, as needed by specific applications. The parameters used to control a bean's transactional nature, persistence, resource pooling, and security management are specified in separate deployment descriptors , and not embedded in the bean implementation or the client application code. So, when a bean is deployed in a distributed application, the properties of the deployment environment (client load levels and database configuration, for example) can be accounted for and reflected in the settings of the bean's deployment options. The EJB API is a standard extension to Java, available in the javax.ejb package and its subpackages. You must install this extension API explicitly to write code against the EJB interfaces. You can find the latest version of the API at http://java.sun.com/products/ejb. You should also note that EJB is just a specification for how distributed components should work within the Java environment. In order to actually create and use EJB objects, you need to install an EJB-enabled server. J2EE-compliant application servers provide this service and are bundled with the standard EJB API classes and interfaces. Finally, it's important to note that this chapter provides only a basic introduction to Enterprise JavaBeans, which is an extensive specification with many features. For more complete coverage, see Enterprise JavaBeans by Richard Monson-Haefel (O'Reilly). |