Find out why JavaBeans and Enterprise JavaBeans are important for AS/400 shops. The EJB architecture, components, and roles are explained in this introduction to a critical software development standard. Learn why EJB is the key to your future in developing platform-independent software components.

What is Enterprise JavaBeans (EJB) technology, and why is the software development community so interested in something with such an unusual name? EJB technology is a practical method for enterprise software reusability in Java. EJB is a standard component model that works across computing platforms from differing vendors, providing compatibility at the byte code level. Although EJB works at any level, it is primarily targeted at the middle-tier servers. EJB makes it easier to write application logic and applications by handling the low-level infrastructure tasks—such things as threading, state management, resource pooling, and the like.

EJB lets the business application developer concentrate on the business application and not on the plumbing. EJB is important to IBM and to AS/400e because it promises to become the most widely used binary-level component standard for business applications. EJB is also important to AS/400e because AS/400e is a server for business applications. As a mission-critical business computing server, AS/400e must have excellent support for EJB.

JavaBeans

Because EJB technology builds on the Java component model, also known as JavaBeans, I think that it is necessary to first review what JavaBeans themselves are. A JavaBean is a reusable, platform-neutral, software component that can be visually manipulated in a software development tool. That definition, straight from the Java specification, is deceptively short, simple, and to-the-point. Like a Japanese rock garden, however, there’s a lot going on there that is not immediately apparent. First, a JavaBean is reusable. To be reusable, the bean must be created (programmed) in a standard way and, in fact, JavaBeans use a well-defined set of standards that are defined in the JavaBeans specification.

To be platform-neutral, a component must not have any dependencies on the operating system, on the hardware, or on anything else associated with the specific platform. JavaBeans meet that requirement. They are written in 100% Pure Java and are therefore portable from one platform to another as long as that platform has a Java Virtual Machine (JVM) running on it.

Next, a JavaBean must be a software component. According to my trusty dictionary (English dictionary, not computer dictionary), the word component simply means a “constituent element.” In software, the word component implies that the constituent element can be manipulated as a complete “black box” component. It’s not necessary to understand the innards of a component to use it. In fact, most component users never see the inside of the component. Certainly, automotive mechanics don’t cut open a spark plug and measure the electrical characteristics of the conductor and insulator before using it in a car. That “black box” approach to working with external characteristics, specifications, and interfaces is very important to the idea of software components in general and to JavaBeans as software component models in particular.

Finally, software development tools must be able to visually manipulate JavaBeans. This implies that an individual software development tool must know the external characteristics of all JavaBeans, which, in fact, it does. Software development tools that are bean-capable understand and can manipulate the methods, properties, and events that JavaBeans use. These three aspects of JavaBeans provide sufficient inspection and manipulation capabilities for the development tool to understand and use the component (bean) as part of a larger system. I will briefly define methods, properties, and events here, but interested readers should consult a more complete Java reference work for more information. A method is an action that can be requested of a bean. In other words, a method is something a bean can do. A property is data or information that a bean can provide or store. An event is a response and communication mechanism for beans. Beans can respond to events and can initiate events in other beans.

Software reuse is the modern-day equivalent of the Industrial Revolution when standardized parts (first used by Eli Whitney in 1798 to produce firearms) made mass production possible. The implications for productivity of software reuse are as great as they were for industrial mass production. The training, skill, and effort required to fit components (industrial or software) together are different than that required to design, test, and produce the components. It’s not just less training, skill, and effort; it’s altogether different. Producing a high-quality component is analysis intensive, requires extensive design skill, and should require extensive testing. Using the component as part of a larger system requires knowledge of the larger system but shouldn’t require in-depth knowledge of the component. For example, how productive would automotive mechanics be if they had to evaluate the metallurgy of every single mechanical component that they bolted onto a car?

This reuse capability lets business application programmers concentrate on the business aspects of programming, not on the “metallurgy” of the components that they are using. That’s a big deal, in terms of both the quality of the software and the productivity of business application programmers.

Enterprise JavaBeans

Enterprise JavaBeans are enterprise Java components. EJB components can be used and reused in an organization as component parts of larger enterprise software systems. As component models, JavaBeans fall short when it comes to distributed systems architectures. While it is possible to run a bean remotely, the JavaBeans specification offers no standards for such common behaviors as find, start, and stop. Nor does it provide standards for management. Enter Enterprise JavaBeans. The EJB specification provides component standards at a distributed level. These components implement specific interfaces and honor specific behavioral contracts (in other words, they behave as expected) to allow

larger systems to find, start, stop, and manage them. In turn, the larger systems provide an environment for the component to operate and provide services to the component.

EJB is also an architecture. The EJB architecture specifies a standard component architecture; addresses the development, deployment, and runtime aspects of enterprise application software; and defines the behavioral contracts that enable tools from multiple vendors to develop and deploy components that can interoperate at runtime. EJB defines roles for component providers, software developers who use components to assemble applications, software deployers, EJB server providers, EJB container providers (a container is the above-mentioned environment), and system administrators. EJB developers, users, and interested parties will want to get a copy of the EJB specification at www.javasoft.com/beans/docs/spec.html and read it.

What’s the Big Deal?

The EJB component architecture is important because it builds on the JavaBean component concept to provide a practical enterprise mechanism for reusable binary-level components that will function on all the computing platforms in an enterprise. For example, you may buy a General Ledger debit/credit bean and then use that debit/ credit bean without modification on your IBM AS/400e, your Windows workstations, your Windows NT Server systems, and your Sun server-based systems. This capability means savings in programmer time, savings in user training, and savings in software support costs. So EJB is important because it will make for better and more cost-effective enterprise software.

EJB is also an important software market phenomenon. Because it provides a platform-independent standard, software component developers can be sure that the components that they develop are widely marketable. In turn, a larger market draws more component developers leading to a larger selection of components for component users. Everyone benefits from an open-standard, platform-independent component market. Conversely, over time, components that are limited to proprietary platforms or single platforms will lead to a smaller market and to fewer components provided to that market by component vendors.

Finally, EJB is important because it lets business programmers work at a higher level. Most programmers now spend a lot of time doing low-level programming tasks. I’ve seen estimates that place the amount of time spent on things like file I/O, manipulating relational data, manipulation of data from disk into memory structures (arrays, vectors, etc.), and other low-level tasks at over 50 percent of a typical programmer’s time. While this time spent may have once been necessary, it sure wasn’t productive. EJB lets programmers concentrate on their part of the task, and, for most business programmers, that means assembling pieces of business functionality into a functioning system. This ability to work at a higher level of abstraction will mean a large productivity boost for business programmers.

EJB and Child Behavior

EJB components are different from regular JavaBeans in some very important ways. They make some important assumptions about things like persistence, state management, transaction management, database services, and security. EJB assumes that it won’t have to handle the details of accessing any of these or other platform services. They behave much as young children do: They assume that all they have to do is ask and most of what they need will be provided. And, just as it is true for our children, as long as they are running in an EJB container, it is mostly true for Enterprise JavaBeans. This concept of a container is the key attribute of EJB that makes it possible for business programmers to concentrate on business programming.

Logical Containers

EJB separates a regular JavaBean into two parts: the business logic part and the system services part. The business logic part becomes the EJB components and the system services part becomes the EJB container. The business logic part is then portable from container to container, and the container can, in turn, run (or contain) differing, multiple

EJBs. In effect (and in technical terms), the EJB container is a portability layer of software that supports reuse of EJB components on different platforms. A container is where an EJB object “lives,” just as records live in databases and files live in file systems.

EJB containers provide services for Enterprise JavaBeans. The services provided are detailed in the EJB specification (again, see www.javasoft.com/beans/docs/spec.html). The EJB specification services provided by the container are described as contracts. A contract is a predefined expectation of behavior. For example, when a client requests the location of an Enterprise JavaBean, the EJB container must behave as expected and provide the location. In the EJB architecture, contracts exist between the container and the bean, between the container and the client, and between the container and the EJB server as shown in Figure 1.

Services that containers must provide to the client are object-identity services, method-invocation services, home-interface services, and Enterprise JavaBeans creation and destruction. In other words, the container keeps track of what beans are in it, how to invoke (or run) these beans, how to find them, and how to create instances of and destroy these beans.

Services that the container must provide to the bean are life-cycle management, context services, state management, and environmental information. In other words, the container tracks the life cycle of the beans, monitors and provides a description of the context that the beans are running in, manages state information, and provides access to environmental information.

Each bean is packaged in a .jar file (beans are stored in jars, get it?) that is known as an ejb-jar file. An ejb-jar file is the standard unit of packaging for EJB components and all EJB tools must support ejb-jar files. The ejb-jar file provides a .jar file manifest that describes the contents of the ejb-jar file. The ejb-jar file also contains Java class files for the Enterprise JavaBeans. These .jar files also contain EJB deployment descriptors. Deployment descriptors are a key attribute of Enterprise JavaBeans in that they let the bean deployer control runtime attributes and requirements such as security or transactions.

Session Beans and Entity Beans

Version 1.0 of the EBJ specification defines two types of Enterprise JavaBeans. Session beans are typically short-lived (i.e., “just for this session”) objects. Entity beans are objects that survive this session and can be used again in the future. Relational database rows are an example that can be represented by entity beans. In fact, entity beans are most commonly persisted into relational database rows.

Session beans execute on behalf of a single client. They can be transaction aware and can update data in a database, but they cannot directly represent the data in the database. Entity beans, on the other hand, typically do represent data in the database directly. They are transactional, not just transaction aware, and they support shared access by multiple clients. Importantly, entity beans survive crashes of the server running the EJB container.

EJB Roles

The roles of the various participants in the Enterprise JavaBeans architecture are important to understanding and using EJB. There are six roles:

1. Enterprise JavaBeans Provider. Enterprise JavaBeans providers are typically experts in a particular software application domain (like General Ledger or Manufacturing). Providers implement a business task as an EJB component.

2. Application Assembler. Application assemblers take the Enterprise JavaBeans provided by EJB providers and assemble them into business applications. The application assemblers must be familiar with the behavior of the bean as specified in bean interfaces but does not have to understand the inner workings of the bean.

3. Deployer. A deployer strategically arranges Enterprise JavaBeans and their containers into a specific deployment environment (i.e., AS/400e, Sun, Windows NT). A

deployer uses EJB tools to map security roles and may customize business logic using deployment descriptors.

4. EJB Server Provider. EJB server providers furnish a platform on which to run EJB components. This platform (e.g., an AS/400e) will typically provide an EJB container (perhaps from an EJB container provider) and the necessary underlying services. Underlying services include transaction management, distributed objects, naming services, file systems, and other lower-level system services.

5. EJB Container Provider. EJB container providers do system-level programming focused on providing a secure, scalable, transactional container. The container must honor the contracts required by the EJB specification, but the underlying implementation of the services may vary by platform. Honoring the contracts required by the EJB specification ensures that EJB components are portable and reusable across platforms.

6. System Administrator. From the specification: “The role of a system administrator is to oversee the well-being of a running system. The system administrator typically uses runtime monitoring and management tools provided by the EJB server and container providers to accomplish this task.”

From the specification: “The role of a system administrator is to oversee the well- being of a running system. The system administrator typically uses runtime monitoring and management tools provided by the EJB server and container providers to accomplish this task.”

Where Does the AS/400 Fit In?

What’s the AS/400e story on Enterprise JavaBeans? First, AS/400e is committed to supporting Enterprise JavaBeans and doing it quickly. AS/400e, along with WebLogic, announced support for the Tengah Java Application Server in September 1998. Tengah (now BEA WebLogic—it was renamed after the BEA Systems-WebLogic merger) provided very early and very complete support for Enterprise JavaBeans on AS/400e. BEA WebLogic implements all required and all optional features of the EJB 1.0 specification. For more information, point your browser to www.weblogic.com/docs/platforms/as400/index.html.

Since then, several other application server providers with EJB support have announced that their products also run on AS/400e. Bluestone Software, a premier Java application server provider, has announced support for AS/400e (www.bluestone. com). Novera Software has announced support for AS/400e with its jBusiness application server (www.novera.com), and Information Builders, Inc. supports AS/400e with its Parlay Application Server (www.ibi.com). These excellent products from market-leading companies provide EJB support for AS/400e.

IBM’s WebSphere product family is now available on AS/400e as well. WebSphere is slated to have EJB support on AS/400e around mid-year 1999. WebSphere is IBM’s flagship offering in the Web application server market-space. WebSphere is a family of products that includes a servlet engine, performance pack, designer suite, and EJB support. For more information about WebSphere, see “WebSphere Application Server for AS/400” elsewhere in this issue.

Use of Enterprise JavaBeans is an excellent way for AS/400e shops to achieve a platform-independent binary-level component standard that enables software reuse and portability. Software reuse and portability lead to increased programmer productivity, reduced software costs, and reduced support costs for most organizations. With such a compelling business case for implementing Enterprise JavaBeans technology, you should now be wondering “What’s my EJB role going to be?”

Enterprise JavaBeans

Client

Container

EJB Server (AS/400e)

Figure 1: Enterprise JavaBeans architecture provides platform independence for server components.