Enterprise JavaBeans™ in Context

Date: Apr 18, 2003

Sample Chapter is provided courtesy of Pearson.

Return to the article

This introductory chapter describes the goals and requirements of EJB technology and what you—the developer—can expect to gain by using it. It explains how EJBs t into other distributed programming paradigms (like CORBA), and into the wider 'J2EE' model of application development. The chapter includes an outline of the other services that a J2EE-compliant application server is expected to provide and which EJBs can use (e.g., Java-Mail, JMS). There is a brief discussion of the development philosophy that underlies the EJB Specication, including the roles of the developer, assembler, and deployer, and how the EJB model—appropriately used—can enhance code reuse and improve reliability.

1.1 Enterprise JavaBeans: what are they, and what do they do?

Let's start by examining the answer to this question as provided by the most authoritative source, the EJB Specification itself:

"The Enterprise JavaBeans architecture is a component architecture for the development and deployment of component-based distributed business applications. Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure. These applications may be written once, and then deployed on any server platform that supports the Enterprise JavaBeans specification."

This definition makes a number of important assertions, which are worth considering in more detail.

"...a component architecture..." The distinction between 'component-based' and 'object-oriented' development is not a strict one, and you will see EJBs referred to as 'distributed components' and 'distributed objects.' I take the term 'component' in EJB technology to mean a piece of software that is self-contained, has well-defined functionality, and fits into some kind of application framework. It is this latter point that probably makes the term 'component' more applicable than 'object' in EJB technology.

The application framework is exemplified by the EJB container, a concept about which we will have much more to say later. EJBs depend for their very existence on their container; it regulates all aspects of their lives, including their communication with other EJBs [EJB2.0 6.2]. This is not the restriction that it first appears, because the use of the container has profound advantages, as we shall see.

EJBs can be viewed as simple objects: They expose methods, and these methods can be called. Like ordinary objects, the methods take arguments and can return values. Unlike ordinary objects, EJBs can be distributed across different hosts, and the architecture takes care of the communication. When a client makes a method call on an EJB, it is in fact making that call on the container, which acts as a proxy, as we shall see.

"...distributed business applications..." What is a 'business application' ? This is a very broad term, but we can identify certain characteristics that most business applications will exhibit. First, there is a reliance on data, often in volume, and with strict measures to protect the integrity of that data. Most business applications make use of relational databases. Second, many business applications have large numbers of users, often geographically distant from the application host. Third, business applications often integrate systems of different types, from different vendors. Some of these systems will be 'legacy' systems—that is, based on obsolete software and protocols, but needing to be retained. EJBs can make use of messaging services, connectors, and other techniques for access to legacy systems. The EJB infrastructure has interoperability as one of its core requirements [EJB2.0 19.2]. Applications are 'distributed' when components can be hosted on different servers. The ability to distribute components has important implications for fault tolerance and load sharing, as we shall see.

It is worth pointing out at this point that, under EJB 2.0, not all EJBs have to be capable of distribution. The developer is at liberty to author EJBs such that they are only accessible to calls from other EJBs in the same JVM. This makes access more efficient at the expense of limiting load balancing and fault tolerance. We will have much more to say about this issue later.

"...scalable..." An application is scalable if the system that hosts it can be expanded or upgraded to support a higher client load, without significant modification to the software. Scalable does not necessarily mean 'high performance,' despite a common belief that this is the case. EJB applications support scalability because they lend themselves to distribution; they support high performance because they allow the sharing of resources and minimize overheads, as we shall see.

" transactional..." Where business applications are datacentric, the integrity of the data is of paramount importance. This means that access to the databases, and often to other resources, will be transactional—that is, consist of operations that must succeed or fail as a group. We will have much more to say about this issue in Chapter 9, as transaction management is a key feature of the EJB infrastructure, particularly in a distributed environment [EJB2.0 19.6].

" multi-user secure..." Business applications will need to be able to identify their users, and allow access to the data only to defined users. Information about which users are allowed which operations is often not part of the application, but stored in some sort of user database (e.g., an LDAP directory server). Security is an integrated part of the EJB framework, as described in Chapter 16.

"...written once, and deployed on any server..." With care, EJB applications can be made quite portable (but see below). The use of the Java language ensures portability not merely at the source-code level, but at the binary level. This makes it appealing for vendors to author EJB components that are general-purpose and can be integrated into other applications. A requirement to distribute source code would discourage this. Provided that the EJB author is careful to follow the Specification, the interaction between the EJB and its container should not depend on the container vendor. The EJB architecture is designed to support the use and integration of components from different vendors, by such means as using a standard (XML-based) configuration scheme for components.

In summary, EJBs are Java3 software components that run in a framework that supports distribution, load sharing, fault tolerance, security, and transaction management. To their clients they 'look like' ordinary Java objects, and can be used similarly.

In a more pragmatic sense, EJBs are components built from Java program classes and interfaces. In particular, each EJB has at least one class, which provides the application functionality, and, where direct interaction by clients is allowed, two or four interfaces, which specify which methods are to be exposed to clients. These Java elements are packaged into a standard Java JAR file along with a deployment descriptor, an XML file that provides configuration information to the server. Each JAR file can contain one or more EJBs. In practice, we tend to use graphical tools for building the JAR and XML files.

1.2 EJBs in the enterprise

EJBs, for all their power and flexibility, are most useful in conjunction with other components of an enterprise application. The J2EE model of enterprise application development—which is described in more detail below—sees EJBs as implementing the bulk of the application's business logic and data management. In this model (Figure 1.1), EJBs occupy an architectural 'tier' between the enterprise data sources (relational databases, directory servers) and the presentation elements (clients using Java, servlets, etc). Centralizing the application's business logic in EJBs allows a variety of different clients (including clients via CORBA protocols) to make use of that logic and decouples the application from the specific representation of its data in the enterprise data sources.

The rest of this section describes in more detail some of the J2EE3 and non-J2EE technologies with which EJBs are likely to interact. These interactions are summarized in Figure 1.2. Some of these technologies are sufficiently important that they have their own chapters in this book.

1.2.1 J2EE technologies

Java 2 enterprise edition (J2EE) is not a technology in its own right; it is an umbrella specification that dictates how a number of other Java technologies are to intraoperate. Not all of these are relevant to EJB developers, but those that are (particularly JNDI3 and JDBC3) are described in detail in this book. Others (JSP and servlets, for example) will be described briefly. For completeness, this section describes in outline all the technologies that are part of the J2EE group. It also describes some important non-Java technologies.

JavaIDL

JavaIDL is a Java implementation of the CORBA interface description language (IDL). IDL is a language for specifying the methods of an object and their properties that is independent of the programming language. JavaIDL is a set of classes, which maps IDL data onto Java stubs that support the IIOP protocol.¹On the whole, EJB developers don't need to be too concerned with JavaIDL, except where EJBs need to make explicit calls on CORBA ORBs. In most cases, the intricacies of JavaIDL are encapsulated—where necessary—in code generated by the EJB server vendor's tools.

JAF

JavaBeans activation framework (JAF) is a specification for mapping content handlers to arbitrary data types (typically MIME types). JAF gets only a brief (one-line) mention in the J2EE Specification; it is included because the JavaMail API has a dependency on it. EJB development is not likely to involve direct use of JAF.

Figure 1.1. A simplified view of the J2EE application model; EJBs are central to this model, implementing the business logic and data management.

Figure 1.2. EJBs in relation to other enterprise application technologies.

JCA

The J2EE Connector Architecture (JCA) is a relatively new addition to the J2EE standards. It defines a specification by which application servers can allow the components they host to get access to external resources, particularly legacy systems. The term 'connector' is used to describe any piece of software that allows this. At present, the major commercial EJB products all have their own proprietary ways of implementing connectors and often provide a range of connectors for popular data management systems, like IBM's CICS or SAP R/3. The problem is that not only are the connectors themselves proprietary and nonportable, the EJB code that makes use of them will only work with that vendor's connectors.

The JCA is an attempt to standardize the provision of connectors. A JCA-compliant product is portable across application servers and provides a uniform method of access for EJBs; thus the EJB code is also portable.

Providing a connector architecture is not straightforward. The systems that are connected may well have transactional semantics and need to be integrated with the transaction management system of the EJB container. In addition, it may be necessary to propagate the security context of the EJBs' caller into the connector. The JCA takes care of these issues and others.

At the time of writing, few commercial products are available that support JCA. The J2EE Reference Implementation, however, provides an implementation of it that can be used to experiment with the technology. JCA is described in more detail in Chapter 18.

JDBC

JDBC is a specification and API for providing Java program classes with access to relational databases in a vendor-neutral manner. We will have much more to say about this later (mainly in Chapter 8, but it is discussed extensively in other chapters as well).

JNDI

Java Naming and Directory Interface (JNDI) was originally intended to fulfil the same role with respect to directory servers that JDBC does for database servers. That is, it is a specification and API that allows Java code to query and update a directory server. JNDI is still widely used for this, especially with LDAP directory servers (see page 178), but it has an additional role in the J2EE architecture. Here the JNDI API is used to retrieve classes that provide access to resources. These resources may be EJBs, database connections, simple data elements, mail servers, and many others. While information about the resource may be stored in a directory server, it may equally not be. The use of JNDI for this purpose is to avoid introducing a new API just for looking up resources. JNDI is extremely important to EJB development, and the whole of Chapter 7 is devoted to it.

JSP

Java Server Pages3 (JSP) are HTML or XML documents with embedded programmatic content. They are increasingly used for providing a Web-based user interface to EJB and database applications. In practice, JSPs are translated into servlets (see below), and have more-or-less the same properties and capabilities. JSP is an alternative technology to Microsoft's Active Server Pages (ASP) and to other server-side Web scripting technologies like PHP.

JTA

Java Transaction API (JTA) is a set of related APIs for Java components to communicate with the various components of a transactional system. In particular, there are APIs for use by application components, transaction managers, and resource managers. An EJB product is required to support the JTA APIs [EJB2.0 17.1.3] to the extent required to allow EJBs to demarcate transaction boundaries. The product can support the other APIs as well, and it would certainly improve inter-operability to do so, but at the time of writing, many commercial products do not provide such support. The implication is that if an EJB product is to take part in a distributed database transaction, it must use database drivers provided by the vendor of the EJB product, not the database. This issue, along with others relating to the use of JTA, is discussed in detail on page 287.

JTS

Many developers misunderstand the role of the Java Transaction Service (JTS), and its relationship to JTA. In fact, JTS is not part of the J2EE Specification (at least in Version 1.3), and EJB products are not required to support it [EJB2.0 17.1.3]. So what is it, and why is it important? The CORBA Object Transaction Service (OTS) Specification defines how transaction context can be propagated between distributed objects. This allows objects on different hosts to take part in the same distributed transaction. This is also a goal of EJB technology: If one EJB calls a method on another and the caller is part of a database transaction, then it should be possible for database work done by the called method to be encapsulated into the same transaction as the caller.

JTS specifies the interface between JTA (the transaction management methods that applications will use) and the low-level CORBA OTS. A JTS-compliant EJB product should allow EJBs to intraoperate seamlessly with CORBA components, at least in so far as transaction management is concerned. Although JTS is a specification, Sun Microsystems provides a full implementation of that specification; when developers talk of 'using JTS,' they often mean 'using Sun's implementation of JTS.' As CORBA integration becomes increasingly important in EJB technology, JTS may become more widespread. At present, most commercial products use proprietary techniques for propagating transaction context between EJBs.

JMS

Java Messaging Service (JMS) is a Java interface to asynchronous messaging products like IBM's MQ Series. JMS is becoming very important, as it provides an elegant way for EJB products to integrate with legacy systems. Version 1.3 of the J2EE Specification and Version 2.0 of the EJB Specification both add increased support requirements for JMS, and a compliant application server must provide not only an interface to a messaging service, but the actual infrastructure of a messaging service as well. The JMS architecture and its integration with EJBs, is discussed in detail in Chapter 10.

JavaMail

JavaMail is a specification for Java components to send and receive email messages in a vendor-neutral way. Although it is a specification and not an implementation, in practice most developers who are using it are actually using Sun's implementation, which provides support for SMTP, IMAP, and POP3 mail protocols. EJBs can use JavaMail to send email messages, as described on page 584.

Servlets

Servlets are Java program classes that extend the functionality of a Web server. When a Web browser makes a request that corresponds to a servlet, the Web server calls the class's service() method. This method must generate content (usually HTML or XML) to be conveyed back to the browser. Servlets and JSPs are widely used to provide a Web interface to an EJB application; this technique is discussed in detail in Chapter 17.

1.2.2 Related technologies

CORBA

Common Object Request Broker Architecture (CORBA) is a set of standards for allowing objects to interact in a distributed environment. In a sense, this is what EJB technology aims to do, and it is often thought that EJB and CORBA are competing technologies. There is indeed an overlap between what EJB servers do and what object request brokers do. The EJB developers have neatly sidestepped this issue by integrating some of the CORBA specifications into EJB. In particular, the IIOP protocol, which CORBA uses for communicating method-call information over a network, must now be supported by compliant EJB products. There is, of course, more to CORBA than remote method calls; Sun's developers have been very busy integrating other CORBA services into the Java environment. This is particularly evident in the development of JTS. The details of CORBA are beyond the scope of this book, although we will discuss those aspects that overlap with EJB technology (page 37).

The CORBA and IIOP specifications are defined and maintained by the Object Management Group (OMG), a large consortium of vendors and other interested parties. The size of the OMG means that its standards have very broad support, but it can take a long time to adapt to changes in technology. One vendor that is notably absent from the OMG is Microsoft, which has its own proprietary techniques for distributed computing, such as DCOM (see below). The relationship between EJB and CORBA is set out in detail in [EJB2.0 19.5].

DCOM, COM+, .NET

Microsoft's Distributed Component Object Model (DCOM) and its successor COM+ are proprietary distributed object technologies from Microsoft. They are central components of Microsoft's integrated enterprise application framework called '.NET,' which includes a distributed transaction infrastructure, messaging services, Web components (based on ASP), and a database server.

While there are undoubtedly advantages to building a system from a set of products by a single vendor (there should be minimal problems with interoperability, for example), there are disturbing disadvantages as well. The most obvious of these is the difficulty of integrating products from other vendors. Another problem is Microsoft's continued unwillingness to produce versions of their products that run on Unix platforms; the majority of enterprise applications are deployed on Unix-based systems, even if something else is used for development.

Although Sun has not escaped criticism for its attempts to maintain control of the Java and J2EE standards, these standards are fully publicized and anyone can sell products that support them. The problem with Microsoft's offering is that the same company controls both the products and the specifications. Being in a position to do this puts a vendor at a huge advantage. Consider, for example, the task of producing integrated development environments (IDEs) to support the production of enterprise systems. It should be fairly clear that producing such tools is much simpler if everything the tools will work on is a product from the same vendor. If it proves to be impossible to achieve what is desired by users of the tools, no problem: We can change the underlying technology. This is simply not an option with a standards-based platform. Spare a thought for those brave souls who develop integrated development tools for J2EE: The tools must be able to generate and maintain code that complies with about 20 different open standards, all of which are developing rapidly under the pressure of about 100 major vendors. This is why it remains true that integrated tool support for J2EE is underdeveloped.

Use of Microsoft's distributed component technology does not preclude integration with EJBs. Part of Sun's J2EE support is a set of products that enable non-Java software to be clients of EJBs. These products, known collectively as client access services (CAS), currently support Microsoft COM and ActiveX clients (see developer.java.sun/developer/earlyAccess/j2eecas). Essentially these products use IIOP bridging technology, in which COM interactions are translated into IIOP interactions.

XML

Extensible markup language (XML) is probably the most widely hyped, least understood of all the current enterprise technologies. In fact, XML is extremely simple; the cleverness is in the use which is made of it.

XML is a general-purpose language for describing data. Superficially an XML document resembles HTML, in that sections are demarcated using tags. What goes in and between these tags is entirely at the discretion of the developer, provided that basic syntactic integrity is maintained. This allows the format to be adapted to suit a large number of applications. In addition, the structure and content of the tags can be described formally in a document type definition (DTD), which allows the receiver of an XML document to ensure that the document is structured in a way that can be interpreted.²

XML owes its success to a number of factors:

• It enjoys wide industry support. Among other things, this means that XML parsers and document assemblers are widely available.

• It is a completely open standard.

• The basic structure of an XML document can be checked against its DTD. This is particularly important in business-to-business applications, where the sender and receiver of a document may be very different kinds of business and may not work closely together.

Organizations involved in business-to-business (B2B) e-commerce are particularly excited about XML. To see why, consider that at present the majority of B2B transactions are carried out using proprietary EDI (electronic data interchange) services. These services are run by a small number of specialist providers, and are funded by subscription. In addition, many transactions are not carried on the Internet, but on private EDI networks, also maintained by specialist providers. The use of these services can be extremely expensive. In addition, the data formats used in EDI are often proprietary, and subscribers can easily by locked into a particular provider. With this background, it's easy to see why XML, which is open, flexible, and can readily be carried on a public network (with suitable encryption), is taking the B2B world by storm.

Although XML as a standard is well-supported, this does not necessarily mean that two XML-enabled applications can exchange data; this is one of the most widespread misconceptions about XML. To exchange data, the applications must at a minimum agree on a common DTD. As the use of XML has increased, large numbers of 'standard DTDs' have been defined by various industries. There are, for example, standard DTDs for data as diverse as livestock trades, curricula vitae, and interactive teaching materials. Having agreed on the DTDs, the collaborating organizations must agree on a protocol by which the XML documents will be encoded and transmitted.

So what does all this have to do with EJBs? The answer at present, sadly, is 'not much.' The EJB Specification only stipulates the use of XML for deployment descriptors (files that specify configuration data to the server). There's nothing to stop the developer coding EJBs that use XML for data interchange, but there is no built-in support for this. In particular, there is widespread interest in using XML to carry objects in EJB method calls (techniques for doing this are discussed on page 42) but EJB products aren't required to provide any support; it's up to the developer to implement it.

1.3 Why use EJBs?

It is possible to write applications that support distribution, transaction management, and security without using EJBs. There are many such applications in use already. So what advantages do EJBs have to offer over other techniques?

• The EJB developer works within the EJB framework to take advantage of its built-in support for features like transaction management and security; once understood, little developer effort is required to make effective use of these features. With suitable servers, EJB applications can even make use of features as sophisticated as distributed transaction management with no coding whatsoever.

• EJB 2.0 introduces a very powerful persistence management scheme, which supports not only persistent data, but persistent relationships between objects. It takes a while to get used to, but once mastered, this revolutionizes the development of persistent application objects. Again, very little coding is required to implement such objects.

• The EJB framework presents the EJB with a managed operating environment. For example, the framework ensures that an EJB instance is never executing in more than one concurrent thread,³so the developer does not have to be concerned about the effects of concurrency on data integrity. The container is also responsible for memory and resource management, so EJB developers don't have to be concerned with these issues.

• EJBs can make use of the full range of Java APIs and class libraries. It is relatively straightforward to code an EJB that parses XML, sends email, and communicates with directory and database servers via standard APIs like JDBC and JNDI.

• EJBs isolate database implementation from the application's business logic. If we use entity EJBs, for example, as models of the underlying data, then theuse of that data is decoupled from its internal representation. This leads to increased ease of maintenance and portability of code. We can also use EJBs as interfaces to legacy systems, with similar advantages.

• EJBs are very accessible to Web components such as servlets and JSPs. There are a number of products available that support these components in the same application framework (typically called application servers). This makes it straightforward to provide EJB applications with a Web-based user interface and, perhaps, provide Internet access to the application.

1.4 The EJB philosophy

The EJB Specification is based on a small number of fundamental principles, an appreciation of which will help the developer to understand why the Specification has the form that it does.

EJB applications are loosely coupled This is discussed at [EJB2.0 5.4]. The EJB Specification was designed from the outset to support the integration of components from different vendors. For example, EJBs refer to other components and services to which they have access by arbitrary names. These names can be mapped onto real names without modifying program code. This allows EJBs to be authored without detailed knowledge of the environment in which they will be used or of the other components with which they will interact.

In traditional software engineering, this principle is called 'loose coupling.' A loosely coupled system is easier to test and maintain, and its components are easier to reuse.

The Specification distinguishes carefully between the role of the 'component provider' and the 'application assembler,' even though in practice these may be the same person or people. As we shall see, an 'application assembler' is someone who builds an application from separate EJBs, perhaps from different sources. The assembler's roles include resolving naming conflicts between the different components and ensuring that transactions are propagated between components correctly. These factors are largely controlled declaratively—in XML files—not in Java code, allowing applications to be assembled without code changes.

EJB behaviour is specified by interfaces The clients of EJBs do not, in principle, need access to the EJB implementation code itself, either at compile time or runtime. An EJB's interaction with its clients is specified entirely in terms of Java interfaces. These interfaces expose the methods that clients can call, and thereby set out a 'contract' between the client and the EJB.

Developers who work with systems that do not enforce this strict separation between 'interface' and 'implementation' sometimes find the use of interfaces a burden in EJB development; nevertheless, it increases portability and modularity, and makes it easier to support integration with non-Java components (in which interfaces may be specified using IDL, for example).

EJB applications do not manage resources As far as possible, EJBs get access to external resources (databases, legacy systems) through their container.

It is the container's job to manage these resources and make the access as efficient as possible. In most cases, the container will implement resource-sharing and pooling schemes to support this. The programmer does not have to worry about resource allocation and deallocation. The EJB container itself cannot be configured or managed through API calls. It is the administrator's responsibility to configure resource sharing policies, not the developer's.

The container supports the application developer This is particularly important where persistence management and transaction coordination is required. When Version 1.1 of the EJB Specification was current, developers were loathe to use container-managed persistence (CMP). In Version 2.0, the CMP strategy has been radically revised. It is now possible to define container-managed relationships between objects as well as container-managed persistent data. These features are straightfoward to use when fully understood and significantly ease the development process. However, for these advantages to be fully realized, the developer must 'buy in' wholeheatedly and develop in the spirit of the EJB model.

EJB applications are tiered Although it is sometimes necessary to divert from this goal for reasons of efficiency, EJB applications are easiest to manage if a strict tiered architecture is followed. The fact that there were two types of EJB in Version 1.1 of the EJB Specification made it quite natural to adopt a two-tiered model: the client-facing tier based on session EJBs, with entity EJBs deployed between the session tier and the back-end data sources. Don't worry if the terms 'session EJB' and 'entity EJB' are not clear at the moment: We will have much more to say about these, and the tiered model in general, in Section 15.1.1.

The session tier is the API to the application Ideally, the entire business logic of the application should be encapsulated within its EJBs and exposed via the outermost tier. In most applications, this tier will consist of session EJBs, message-driven EJBs, or both. Thus, the session tier can be seen as the 'API to the application.' This interpretation favours the view that the application consists of services that are exposed through the outermost tier of EJBs. Clients that wish to get access to the services can do so, supplying input and rendering output as they see fit. If this logic is followed to its conclusion, then it becomes a very straightforward matter to provide a range of di3erent types of client for the same application. It also tends to decouple some of the internal business logic from the needs of the client, particularly that related to access to the back-end services.

Not all Web-based applications will benefit from being developed using EJBs. However, there is a tendency for developers of Web applications to have business logic in servlets, even when they are using EJBs. This reduces the effectiveness of the tier model and couples the servlet tier to the data model, leading to reduced ease of maintenance.

The entity tier is the API to the data sources If the session tier is the 'API to the application,' then the entity EJB tier is an 'API to the database.' What this means is that the entity tier hides the back-end datasources behind an object-oriented (or at least component-oriented) facade. This tier therefore exposes back-end functionality via the methods of its EJBs. There should therefore be little or no business logic in this tier. If this is taken to its logical conclusion, the application's business logic in the session tier is completely decoupled from the data representation. Again, this increases ease of maintenance.

There are sometimes good reasons for not following this architectural blueprint strictly, usually related to performance. Of course, imposing a new layer of abstraction in a system always leads to some performance penalty, however small. In earlier versions of the EJB Specification, and products that implemented it, it was probably fair to say that the performance penalties were more severe than they should have been. For example, using entity EJBs strictly to iterate a large database table could be breathtakingly slow. Recent changes to the Specification allow the purity of the tiered architecture to be upheld with relatively little degradation in performance, if the developer is careful.

1.5 EJB roles

An interesting feature of the EJB Specification is that its requirements are largely divided into different 'roles.' When reading the Specification, it is therefore quite clear to whom the various requirements correspond.

Component provider The component provider [EJB2.0 25.1] is a software developer who authors EJBs. These EJBs may be destined for a particular application, or they may be general-purpose or part of a software library. The EJB author may not know the names of the EJBs with which it is to interact although, of course, their method specifications must be known. Similarly, the EJB author may not know the names of external resources like databases.

The Specification indicates how the component provider uses the XML deployment descriptor to indicate that these EJBs and resources are required, and the names by which it has referenced them.

Application assembler The application assembler [EJB2.0 25.2] is someone who builds an application out of component EJBs. The same person or people may be operating in this role as are fulfilling the component provider role, but the Specification is quite clear that the two are distinct jobs. The application assembler resolves references between EJBs, unifies the references to external resources, and packages the components into a single file ready for deployment.

It is slightly confusing for the newcomer to EJB development that most of the graphical tools used for building EJB applications don't distinguish between what they are doing in the provider role versus in the assembler role. It often appears that the developer is supplying redundant information or information that is duplicated; this is because the deployment descriptor being built does support the notion of a separate provider and assembler, even if they are in practice the same person.

Deployer The deployer [EJB2.0 25.3] takes a file from the application assembler that contains the EJBs and other components required for the application and installs it on the server, making appropriate customizations for the site.

These customizations include replacing database references with real database information, mapping the security roles in the application onto real users and groups in the organization, and supplying values for other configuration parameters.

Server vendor The server vendor supplies EJB server products. An EJB developer should not assume that the sections in the EJB Specification that deal with the responsibilities of the server vendor are not of interest. On the contrary: The server sets the operating environment of the EJB, and this section of the EJB Specification gives the developer an insight into what environment the EJB can expect.

Administrator An administrator [EJB2.0 25.4] is a person responsible for the maintenance and performance tuning of an application.

Tool provider A tool provider authors EJB packaging and deployment tools.

1.6 EJB products

To construct EJB applications, you will need an EJB server, or something that includes an EJB server. This section discusses the features you can expect an EJB server to have—in addition to support for the EJB Specification, of course—and lists some products that are currently available.

1.6.1 Features of EJB products

The EJB architecture was developed to support large, critical (high reliability), distributed applications. It is the responsibility of the EJB server vendor to provide a product that allows this goal to be met. The EJB Specification has little to say about the ways in which it will do this. In practice, containers normally use some or all of the following strategies.

Load sharing

In many large systems, a single server—however powerful—will not be able to support the total load of the application. In any case, one large system is less effective than two smaller ones at handling failures. In practice, therefore, all commercial EJB products are able to distribute load between servers.

As a client's first access to an EJB service is via a name-service lookup, coarse-grained load sharing can be implemented at the point in which the EJB's factory object is looked up (more about factory objects later). Each successive request for the same EJB factory can be directed to a different server, with the EJB itself distributed on all the servers. This process can be governed by the name lookup service (on the server), or by the client. In the latter case, typically the work will be done in a proxy on the client, so that the developer does not have to code the client differently.

Such a strategy is straightforward to implement and can work reasonably well where the number of clients is large and the load imposed by each client relatively small. With a small number of demanding clients, load can easily get out of balance, as there is no opportunity for rebalancing once the factory object has been located.

Alternatively, we can balance at the method call level, if EJBs are pooled or the instance variables of unpooled EJBs can be synchronized across servers. This allows more rapid adaptation to changes in load, but is complex to implement.

In practice, load sharing is much more complicated than it first appears. The reason is that some EJB components—notably stateful session EJBs—have state that is meaningful to a client. This means that requests from the client cannot be distributed arbitrarily. Instead, they must either be bound to the server on which that client's state is stored, or we must provide a method for synchronizing the state across servers. This issue will be discussed in more detail later, when we look at failover strategies.

Needless to say, the method of load balancing will depend on the server vendor but, if you follow the rules set out in the EJB Specification and the guidance given in this book, this should not present a problem.

Resource pooling

The most common form of resource pooling is database connection pooling, which is supported by all commercial EJB products. This topic is discussed in detail in Chapter 8. The purpose of resource pooling is to allow large numbers of Java objects to have access to a small number of instances of a shared resource. In the case of database connections, these are computationally expensive to open and resource-hungry to maintain. A connection pooling scheme allows the mapping of a large number of 'virtual' connections onto a much smaller number of real connections to the database. The J2EE scheme defines a method for access to shared resources that abstracts away from the underlying resource management system. This means that, to a large extent, the Java code required to interact with the resource is the same as it would be without the application server. However, resource pooling schemes work best if the code does not hinder their operation, so an understanding of their operation is advantageous.

Failover and redundancy

In critical applications, we need to be sure that if a single server fails, the application itself can continue to operate, albeit at reduced performance. Any load sharing system will allow a degree of fault tolerance; it is the ability to handle a failure with no loss of service that distinguishes such a scheme from true 'failover.' In order to achieve a failover with no loss of service, clients must continue to be able to interact with the EJB application without interruption. This is straightforward for EJBs that have no client state, but where state is involved there is more to it. We have already seen that we could avoid the problem of state in load sharing simply by binding incoming client requests to the server that is carrying the client's state. For failover, this simply won't do: We must find a way to synchronize the state.

The problem is that, unlike servlets (page 549), EJBs do not keep their state in nice, neat packets. The state of an EJB is in its instance variables, and the instance variables of its instance variables, and so on. Synchronizing these efficiently is a far from straightforward job. Happily, it's a job for the server vendor, not for the application developer.

A number of EJB products are now able to offer failover support for stateful session beans. Typically, the EJB instance that is most up-to-date has to be serialized, and the serialized version recreated on each participating server. For maximum reliability, this needs to happen after every method call that changes an instance variable. Clearly, this could be very ine3cient if used carelessly.

1.6.2 Integration

Many enterprise-scale EJB products also offer impressive support for other distributed component technologies, notably CORBA. In addition, an EJB product is likely to be a part of a larger application server that includes some or all of the following:

• support for other J2EE components, such as servlets and JSPs;

• a distributed transaction manager;

• a relational database;

• a directory server;

• a messaging service.

In addition, many products provide vendor-specific extensions that allow EJBs to integrate with popular back-end systems like SAP R/3. The problem with vendor-specific extensions is, of course, that the EJBs that use them are not portable across servers. JCA is starting to alleviate this problem, by providing a cross-platform technique for interfacing with arbitrary data sources.

1.6.3 Platform support

If an EJB server is written entirely in Java (a few are), then it may be possible to produce a truly platform-independent product. In reality, this is unusual. Most products either include native machine code components or communicate with other services that are themselves platform-specific. In practice, vendors typically support a small number of platforms, often limited to Sun Solaris on Sparc platforms, and Microsoft Windows NT on Intel-based PCs. Only a few vendors (notably IBM) support an impressively large range of platforms. At the time of writing, support for Microsoft Windows 2000 and Linux, for example, was scant.

1.6.4 Vendors and products

There are a number of products on the market that support EJB applications, as well as a number of open source EJB servers. However, there are relatively few dedicated EJB servers commercially available. Normally, one has to buy a product that supports EJBs as part of a wider set of functionality. Commercial products that support EJBs tend to fall into two groups.

• Database engines with EJB support. Many vendors with strong reputations in the relational database field are producing EJB products that integrate with their databases. Typical examples are Oracle's 8i and 9i and, to a certain extent, IBM's WebSphere.

• Well-established application servers whose vendors have embraced the J2EE model and adapted their products to support EJB. Examples include the SunONE Application Server⁴from Sun Microsystems, and products from Pra-mati and Gemstone.

Another group, which is currently small but likely to expand, is products from vendors of development tools and IDEs (e.g., Borland's Inprise).

Knowing a product's background gives some clue to the areas in which it is likely to excel. For example, a product from a database vendor should be able to offer a high degree of optimization of database performance. A product from an IDE vendor should o3er ease of development. Of course, all products, regardless of heritage, should support the functionality required by the EJB Specification.

Table 1.1 lists some of the products available that include support for EJB 1.1 or later. This list was probably not exhaustive at the time it was written, and it certainly won't be exhaustive by the time you read it.

When considering the price of an EJB product, bear in mind that a product that supports the full range of J2EE services (servlets, JSP, etc.) is almost certainly going to be more expensive that a dedicated EJB server. If it includes a database and a distributed transaction manager as well, then it is likely to be very expensive indeed.

1.7 Summary

EJBs are Java software components that run in a framework that supports distribution, load sharing, fault tolerance, security, and transaction management. The developer works within this framework to make the use of these features relatively straightforward. EJBs can use Java APIs like JDBC and JNDI to interact with external resources and can interoperate with other distributed object architectures, such as CORBA. The EJB framework is designed to support the notion of building an application with components from different vendors. The specification distinguishes between the 'component provider' and the 'application assembler,' even though these may, in practice, be the same person or group of people.

Effective use of EJBs requires that EJB server products be widely available. At the time of writing, there are a large number of vendors with products that support EJB 1.1, and a small—but growing—number that support EJB 2.0.

Table 1.1. Some products that support EJB technology.

Vendor	Product	Contact	URL Evaluation support	Notes
Allaire Corp.	JRUN	http://www.allaire.com/products/ jrun	Free developer version	All java
IONA	iPortal	http://www.iona.com/products/ ip/ipipashome.html	Free 30-day
Evidian	JonAS	http://www.objectweb.com	Open Source
Gemstone Systems, Inc.	Gemstone/J	http://www.gemstone.com/products/ jboss/index.html	Free 30-day
Borland, Inc.	Inprise	http://www.borland.com/besappserver/ index.html	Free trial version	Supports the connector API
Persistence Software, Inc.	Power Tier	http://www.persistence.com/products/ powertier/j2ee.php	Free 30-day
Pramati Software, Inc.	Pramati AS	http://www.pramati.com	Free 30-day
Sybase, Inc.	EA Server	http://www.sybase.com/easerver	Free 60-day
BEA, Inc.	WebLogic	http://www.weblogic.com	Free 30-day	World's bestseller; EJB2.0 support
Sub/AOL	Sun ONE Application Server (formerly iPlanet application server)	http://wwws.sun.com/software/products/ appsrvr/home_appsrvr.html	Trial versions on request
(open source)	jBoss	http://www.jboss.org	Open source	Very popular open source EJB server
Oracle Corp.	Oracle 8i/9I	http://www.oracle.com	Trial versions for some platforms	Very wide platform support
IBM Corp.	WebSphere	www-4.ibm.com/software/ webservers/appserv	Free 60-day	Very wide platform support

© 2024 Pearson Education, Informit. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240