Expand your server-side toolkit with EJB
Find out how EJB can make your server-side hum
Since its official debut at the April 1998 JavaOne conference in San Francisco, Enterprise JavaBeans has been one of the most widely talked about and anticipated technologies yet to emerge from Silicon Valley. Much discussion over the past year has focused on what EJB really is, and how this new distributed technology will affect the marketplace. This month's IT Architect examines EJB and helps you determine if this technology is right your company. (3,100 words)
This month we'll focus on a technology many IT architects are talking about, Enterprise JavaBeans (EJB). Creating a clean design for the application infrastructure often seems an elusive goal. Quick development times associated with the first phase of an application often drive architects to cut corners in favor of a more slap-it-together approach, which inevitably results in the need to rearchitect the solution as the user base grows, either for performance reasons or to reduce long modification times. Every devtool vendor, whether they build application servers or middleware, claims to provide a "new way" of attaining the goal of a good application infrastructure design, which is particularly difficult to achieve when the goal is to construct a platform-independent transactional application. Proponents of EJB believe it to be just the technology to meet this challenge. The EJB specification has now been implemented in several products on the market, and having recently completed an EJB-based application, the authors of this month's column are able to share their thoughts about the technology and their knowledge of how the technology works.
ne of the hottest technologies today is Enterprise JavaBeans (EJB), and it has taken distributed computing by storm. As the lead distributed technologist for your company, it's your job to determine if and how to incorporate new technologies like EJB into your organization. Can EJB help solve such common problems as security, distribution, and transaction management? Can it make your group more productive? And above all, how will it combine with your existing technologies? These are important questions, and in this article we hope to provide you with the answers (and maybe a little more!).
This article seeks to help you, the IT architect, gain a solid understanding of the lower-level EJB technologies like distribution, transactions, and security. Where appropriate, we will be drawing on lessons we've learned during the course of our recent implementation of the technology.
We have a lot of ground to cover, so let's get started.
Before we set out on the architectural path, let's take a quick look at what exactly EJB is. In a nutshell, it's a set of distributed, transactional, secure software components. At a more abstract level, a single Enterprise JavaBean is nothing more than a software component that adheres to guidelines in the EJB specification. The spec describes the relationship between a software component (the bean itself) and its runtime environment (the container).
But that's not all. In addition to outlining a component framework, the EJB specification also describes how various vendors will work together cohesively to deliver complete software solutions. It is the combination of a component framework and the structure of the EJB community that makes this specification so unique.
While it's true that other vendors have tried to provide component-based, scalable, transactional, and modular solutions, EJB may be the first to deliver on this promise. We believe this is because EJB combines the known advantages of Java (platform independence and an easy-to-use programming model) with a well-defined component model. This combination will reduce constraints on developers and allow them to make more portable and reusable components.
The ultimate goal of the EJB specification is to create a platform-independent environment for component-based software development that allows developers to choose components from a suite of beans in a library and plug them into a larger application in any environment, and to do so in a manner that may not have been foreseen by the original bean provider. To accomplish this heady goal, the EJB specification has defined a set of distinct roles to be filled by various vendors in the software development life cycle:
By defining these roles, the specification has allowed developers to focus on their area of specialization. For example, business domain experts who don't typically have a detailed understanding of system-level programming, don't have to spend time under the hood, so to speak, learning about transactions, concurrency, and security. Instead, the server provider is tasked with understanding and implementing this level of functionality.
As the IT architect, you must be familiar with all roles in the specification and understand how they fit into your organization's IT strategy.
The following figure shows a typical three-tier architecture, consisting of the presentation layer (front end), functional layer (middle tier), and storage layer (back end). The diagram includes elements that generally aren't considered part of an architecture (toolkits, for example), but we feel that these items, while not part of the architecture proper, are critical to the success of an EJB-based application.
Architectural elements of an EJB-based solution
The EJB specification inherently supports the architecture shown above. The component framework is described without making assumptions about any of the other layers, except for some of the technologies used for communication between the layers. In this manner, the specification is generic enough to work with any front- and back-end products, yet firm enough to be of practical use.
In the following sections, we'll look more closely at each of the elements shown in the figure above.
Creating a distributed enterprise bean is relatively easy. Developers don't have to learn new languages like IDL (Interface Definition Language) to define the remote interfaces of their components. Rather, the beans rely on standard Java language elements, such as interfaces and classes, to define remote methods. Support for remote client access is provided through two standard Java APIs: Java Remote Method Invocation (RMI) and Java Naming and Directory Interface (JNDI). RMI enables developers to create distributed applications, in which the methods of remote Java objects can be invoked from other Java virtual machines, possibly on different hosts. A Java program can make a call on a remote object once it obtains a reference to it, either by looking up the remote object using the JNDI naming service or by receiving the reference as an argument or a return value.
JNDI is a Java extension that provides Java applications with a unified interface to multiple naming and directory services. As part of the Java Enterprise API set, JNDI enables seamless connectivity to heterogeneous enterprise naming and directory services. The JNDI service is layered on top of RMI. It uses RMI to communicate with the server on which it performs the lookup.
Even though the specification mandates the use of RMI for remote method invocation, it can be used with all industry-standard distributed object protocols. For example, IIOP is supported through a Java-to-IDL mapping.
One major benefit of an enterprise bean is that it is able to work together with other components, either other Enterprise JavaBeans or possibly DCOM/CORBA components, as part of a larger unit of work. Your components need to be able to be grouped together into a logical transaction. To realize this requirement, EJB uses the Java Transaction Service (JTS) API for all transaction monitoring.
JTS is a Java implementation of the Object Management Group's (OMG) Object Transaction Service (OTS) specification. In theory, this enables enterprise beans to work together with other objects adhering to this standard, such as CORBA components. JTS provides methods for starting, committing, and rolling back transactions, as well as the means to retrieve the current transaction context. Using the transaction context, it is possible for developers to create an enterprise bean that can participate in the same transaction as non-EJB components.
As we will see often in the EJB specification, this is an area where the developer is shielded from much of the underlying complexity. The EJB container can handle almost all of the required transaction management without the developer's intervention. At a minimum, the developer will specify what a bean's transactional requirements are and the container will take care of starting, committing, or rolling back transactions as required.
One of the great features of EJB is that a solid understanding of the underlying technology, while not required, enables developers to create more flexible solutions. In this case, if a developer wants to do his own transaction management, he can access JTS directly for a finer level of control.
In our experience, allowing the EJB container to handle the transaction management proves to be advantageous. It unburdens the developer from managing complex transactions and makes it easy to combine several beans into one transaction, even if this wasn't originally intended by the bean provider.
A special kind of Enterprise JavaBean (the entity bean) represents data that is persistent; that is, that can survive beyond the lifetime of the EJB container. In addition to business logic, these entity beans also represent data stored in a database, although this isn't required by the specification. Other data stores (such as a flat-file or object database) can also be used.
The specification mandates two types of persistence: container-managed and bean-managed. When using container-managed persistence, it is the responsibility of the EJB container to generate code to transfer data from the entity bean instance to the data store. The code will be generated at deployment time, making it easy to move beans from one environment to another.
EJB also allows bean providers to write their own database access code. Beans that take advantage of this ability use bean-managed persistence. The developer is responsible for writing code to access the data store itself (by using straight SQL, for example). Note that this doesn't imply that the developer should also do transaction management. Even though a bean uses bean-managed persistence, it can still let the container take care of transactions.
This is another area where you can choose to rely on the container to do most of the low-level services. We used container-managed persistence as much as possible, because it doesn't tie the bean to a particular database representation. We found that, as the database schema changes during a project, being able to simply redeploy a bean and have the container generate code to handle the new table structure minimizes the impact of database changes to the entity beans.
Another advantage of this approach is that it simplifies the entity bean's code. The entity bean contains only business logic, while lower-level classes contain the persistent mapping. This decoupling of the application business logic from the persistent storage mechanism allows the software component to be more portable, as it can easily be adapted to a new storage device.
That said, we've found that the persistence code generated by the container doesn't completely meet our needs in all cases. The container generates code designed to work with the majority of databases and drivers. It doesn't always take into account quirks specific to a certain environment. For example, the code generated to store our beans into a DB2 database expected a return value that wasn't provided by our JDBC driver. To solve this and other problems, we introduced an extra step in the building process in which we preprocessed the generated code to provide functionality unique to our environment.
An important note to make here is that the EJB specification currently does not mandate entity bean support. This means that an EJB application server could choose not to implement entity beans and still be in compliance with the specification. Even though such servers can be useful, they don't allow developers to take advantage of the full power of Enterprise JavaBeans.
As the architect, you're responsible for ensuring that the systems you design can support the complex security requirements your user community presents to you without weakening the productivity of your development team. Enterprise JavaBeans simplifies this task considerably. Security properties are defined at deployment time. The bean deployer is responsible for specifying access control entries in each bean's deployment descriptor. These access control entries give principals (users or groups) access to either individual methods or to an entire bean. The control lists that are generated can change over time to support changes in your business needs without requiring recompilation of the enterprise beans.
The ability to change components' security at deployment time without altering the source code has proven to be a tremendous value in our efforts. Our project was riddled with changing security requirements, and because we were able to make these modifications without touching the source code, they didn't significantly impact our schedule.
One of EJB's biggest benefits is that it makes business components more reusable. In the ideal scenario, we build a generic bean (say, Organization) in one environment and then reuse it by simply deploying it in a new environment. All the necessary changes, such as the mapping of attributes to database columns, can ideally be made to the deployment descriptor, requiring no changes to the source code.
Unfortunately, reusing a business component often requires more than just changes to the database mapping. In most cases, the new environment will also require the bean to enforce different business rules, necessitating modification of the source code.
In order to maximize the reusability of our EJB business components, we used the deployment descriptor to store certain types of business rules. The deployment descriptor can be customized to contain name-value pairs defined by the developer. Because this data is available to the bean class at runtime, it can vary its behavior dynamically, depending on the business rules specified.
By using the deployment descriptor in this way, we were able to create beans that could add or remove business rules at deployment time without any code changes. This approach greatly increased the potential for bean reuse because the bean can be redeployed in an environment that is different in both database structure and business requirements.
Early on in the prototyping and development process, you'll come to the realization that not very many tools are currently available to help with the development of Enterprise JavaBeans. Remember, EJB is fairly new technology, and vendors haven't had time to develop and market a robust toolkit. Because developing enterprise beans requires quite a bit of manual work, it would be to your benefit to develop some tools yourself.
One helpful tool you should definitely develop is a bean builder, which you can use to automate much of the work required during the creation of new beans. During the course of our development, we found that once the business interfaces are defined and the development patterns are in place, creating new enterprise beans is largely an act in replication.
You can also enhance your development efforts by creating a class that manages the home interfaces of your beans and acts like a factory to your beans. This home manager will allow you to overcome one of the shortcomings of the EJB specification -- the lack of inheritance in the home interfaces, which makes it difficult to work with, create, and delete your beans in a generic manner. The home manager would allow you to request a new bean or delete an existing bean abstractly given its home interface.
Interoperability with existing technologies
Enterprise JavaBeans is designed to fit in with your existing technologies. EJB is based on a set of APIs, which are themselves built upon industry standards.
For the IT architect supporting a heterogeneous enterprise architecture, EJB provides a smooth way to phase out older, single-computer-based systems. You can write beans that are wrappers for existing legacy applications, thus acting as a stepping stone to a more network-centric, Java-based software architecture.
Sun's Java Software Division was on the ball when it came to handling existing technologies. Interoperability was designed into the EJB component model. For example, the EJB specification provides a standard and supported mapping between an EJB and a CORBA component; the network protocol IIOP used by CORBA is compatible with RMI, which allows Enterprise JavaBeans to access CORBA servers, and CORBA clients to access Enterprise JavaBeans. Bidirectional communication between Enterprise JavaBeans and DCOM/COM components is also possible. For instance, the BEA WebLogic application server ships with a preprocessor that will generate COM bindings for any enterprise bean.
As previously mentioned, the EJB model uses JTS for its transaction services. This means that an enterprise bean can participate in a transaction with a CORBA-compliant component. EJB vendors can differentiate their products by providing additional interoperability features. For example, InformationBuilder's Parlay allows enterprise beans to access CICS applications.
Interoperability with different databases isn't specifically mentioned in the EJB spec. In fact, the specifics of data storage are abstracted out. This is another area in which different vendors can distinguish themselves. Currently, some vendors offer access to relational databases using JDBC while others integrate with object-oriented databases.
It's unrealistic to expect that an application server will work with all of your existing technologies out of the box. Currently, vendors are offering best-of-breed application servers that are integrated tightly with a few specific technologies. For example, the Oracle8i application server inherently works well with the Oracle database. BEA WebLogic will integrate well with its TP monitor, BEA Tuxedo. As the IT architect, you must know your environment and choose the application server that interoperates best with your key technologies.
When to use Enterprise JavaBeans
By now you must be wondering if EJB is appropriate for your organization. The key to making a good decision about whether to use EJB is to understand your environment. Java and Enterprise JavaBeans are designed to play in an intergalactically distributed world. EJB brings a sorely missing element to Java-based, distributed computing: it offers a more modularized, standard way to make your applications distributed. Prior to EJB, we would have had to choose between any number of component models, various network protocols, and several transaction monitors. EJB is designed to unify these numerous technologies into one industry-supported model.
Why would you choose an EJB-based solution? What are the factors to consider before making this decision? Without claiming to be complete, the following is a list of the pros and cons experience has taught us are important to consider as you make your final decision:
Enterprise JavaBeans is a welcome addition to our Java programming toolbox. It provides a standard component model that will allow the enterprise application developer to build and share reusable business objects. One of its greatest strengths is that it hides much of the complexity associated with building secure, distributed components, but allows advanced developers the ability to get under the hood. This model worked well within the structure of our team: senior developers were responsible for understanding and implementing low-level services, while junior members were able to easily replicate established patterns.
Along with these strengths, EJB also has its weaknesses, one of which is its inherent Java-based nature. While this may appeal to a lot of people, there are, no doubt, some who would like to keep their options open. CORBA, for instance, allows components to be developed in any language for which bindings are available.
Another weakness is that EJB is very much the new kid on the block, technologically speaking, whereas CORBA and COM/DCOM have been around for some time. That said, the EJB specification does have the advantage of building and improving upon the aforementioned technologies.
We can say confidently that using EJB for the development of our application paid off with dividends. We were able to develop a robust, distributed system in months, a task that would have taken much longer using more conventional technologies.
About the author
|Mike Porter and Martin Van Vliet, technologists with Cambridge Technology Partners, have been working on several leading-edge projects, focusing their efforts most recently on Enterprise JavaBeans.|
If you have technical problems with this magazine, contact email@example.com