Doing Business with Enterprise JavaBeans, Page 2
Distributed beansJava comes with built-in support for distributed computing via Java RMI and Java IDL (CORBA). Building on these foundations, all Enterprise JavaBeans are distributed objects that can operate in either RMI or CORBA environments. The agnosticism for distributed computing models is an extremely powerful feature of EJB. You can deploy components from any vendor in either a CORBA or an RMI environment. As a builder of an EJB, you simply don't care how your application assemblers and deployers actually intend to use the bean.
Your options on how you deploy the bean, however, are entirely dependent on the server provider you use. The server provides the distributed computing services for your runtime environment. If it relies entirely on Java RMI and JRMP (RMI's native network protocol), you will end up with an application that cannot scale due to the limitations of JRMP (lack of failover support, protocol speed, and out-of-control socket creation). A good server can work in pure-CORBA, pure-RMI, and RMI-IIOP environments.
Bean persistenceJava's platform independence is a feature you have probably heard way too much about. Just as important, though, is EJB's ability to provide a persistence-independent component model. An EJB can persist against a relational database, a file system, an object database, or any other kind of persistence store you might dream up. It does this in one of two ways.
The most common persistence mechanism in use today is something called "bean-managed persistence." As its name implies, bean-managed persistence places the burden of persistence management on the JavaBean developer. You implement the persistence methods from the EJB specification to perform persistence operations like the creation, deletion, loading, or updating of an EJB with respect to its data store.
The other kind of persistence is "container-managed persistence." Here, a bean developer is not at all concerned with persistence issues. Instead, the bean developer focuses entirely on the business logic of business components. You can configure the container at deployment time to make those objects persist against a particular data source and data model.
In an ideal world, there is absolutely no reason you would use anything other than container-managed persistence. In the real world, however, you do not want to touch container-managed persistence until the 2.0 version of the EJB specification is released. The most glaring design fault with the EJB specification is that it requires all attributes for container-managed beans be public. Public attributes are, of course, a sacred no-no of object-oriented software engineering. Unfortunately, EJB must require public attributes, because there is absolutely no way under JDK 1.1 to let a specific class get access to an object's state unless the state is all public. The JDK 1.2 specification provides a questionable tool that enables any class to get access to another class's private attributes. Using this tool, the
Another problem with container-managed persistence lies not in the specification, but in the container implementations themselves. First of all, since containers are not even required to support entity beans, much less container-managed persistence, you cannot rely on that support even to exist. Finally, practical experience is showing that most people run into implementation problems when relying on container managed persistence due to the general immaturity of the products currently available.
SecurityThe EJB container and server together wrap beans in a security blanket as specified by the deployer. Under this model, you do not have to worry about any security issues when writing an EJB. How containers manage security under the EJB 1.0 specification is largely unspecified except for a reference to a single, deprecated class from the JDK 1.1 java.security package. Security basically boils down to two issues: network security and authentication and validation. Network security is simply the EJB server's job of assuring encrypted network communication. Authentication and validation is the EJB container's job of making sure that the right people are accessing the right parts of the system.
Depending on the server you use, your network communications may or may not be secure. You need a container that uses some sort of SSL security if you intend to deploy an application where secure data is being transmitted.
Due to the lack of direction on authentication and validation, you may see a huge variation in the way different containers implement their pieces of the security puzzle. Application assemblers will potentially need to retool their applications for serious changes when EJB 2.0 comes out. You should, therefore, look for a container that provides good tools for the deployer and system administrator to manage security configuration.
EJB in an enterprise environmentWe have covered a variety of issues relating to how Enterprise JavaBeans address the issues of enterprise computing. As a 1.0 specification, it shows its immaturity in a variety of places. In spite of this, however, it is the best option available for an enterprise computing solution. Other alternatives exist that are more mature, but they invariably compromise on one or more of the key aspects of enterprise computing discussed at the start of this article. The immaturity of EJB is simply a tactical issue that should disappear as the specification grows.
About the authorGeorge Reese is lead architect for Newthink Inc. and lives in Maple Grove, Minn. He is responsible for the architecture of multi-tier distributed enterprise Java systems. He is the author of Database Programming with JDBC and Java, from O'Reilly and Associates.
Page 2 of 2