Enterprise JavaBeans, Fourth Edition

Chapter 1. Introduction

This book is about Enterprise JavaBeans 2.1, the latest version of the Enterprise JavaBeans specification. It also covers Enterprise JavaBeans 2.0, which is still in widespread use. Just as the Java platform has revolutionized the way we think about software development, the Enterprise JavaBeans (EJB) specification has revolutionized the way we think about developing mission-critical enterprise software. It combines server-side components with distributed object technologies, asynchronous messaging, and web services to greatly simplify the task of application development. It automatically takes into account many of the requirements of business systems, including security, resource pooling, persistence, concurrency, and transactional integrity.

This book shows you how to use Enterprise JavaBeans to develop scalable, portable business systems. But before we can start talking about EJB itself, we’ll need a brief introduction to the technologies addressed by EJB, such as component models, distributed objects, asynchronous messaging, and web services. It’s particularly important to have a basic understanding of component transaction monitors, the technology that lies beneath EJB. In Chapter 2 and Chapter 3, we’ll look at EJB itself and see how enterprise beans are put together. The rest of the book is devoted to developing enterprise beans for an imaginary business and discussing advanced issues.

It is assumed that you’re already familiar with Java; if you’re not, Learning Java, by Patrick Niemeyer and Josh Peck (O’Reilly), is an excellent introduction. This book also assumes that you’re conversant in the JDBC API, or at least in SQL. If you’re not familiar with JDBC, see Database Programming with JDBC and Java by George Reese (O’Reilly).

One of Java’s most important features is platform independence. Since it was first released, Java has been marketed as “write once, run anywhere.” While the hype has gotten a little heavy-handed at times, code written with Sun’s Java programming language is remarkably platform-independent. Enterprise JavaBeans isn’t just platform-independent—it’s also implementation-independent. If you’ve worked with JDBC, you know a little about what this means. Not only can the JDBC API run on a Windows machine or on a Unix machine, it can also access relational databases of many different vendors (DB2, Oracle, MySQL, SQLServer, etc.) by using different JDBC drivers. You don’t have to code to a particular database implementation—just change JDBC drivers, and you change databases.^[1] It’s the same with EJB. Ideally, an EJB component—an enterprise bean—can run in any application server that implements the EJB specification.^[2] This means that you can develop and deploy your EJB business system in one server, such as BEA’s WebLogic, and later move it to a different EJB server, such as Pramati, Sybase EAServer, IBM’s WebSphere, or an open source project such as Apache Geronimo, OpenEJB, JOnAS, or JBoss. Implementation independence means that your business components are not dependent on the brand of server, which gives you many more options before, during, and after development and deployment.

Server-Side Components

Object-oriented languages such as Java, C++, and C# are used to write software that is flexible, extensible, and reusable—the three axioms of object-oriented development. In business systems, object-oriented languages are used to improve development of GUIs, to simplify access to data, and to encapsulate the business logic. The encapsulation of business logic into business objects is a fairly recent focus in the information-technology industry. Business is fluid, which means that a business’s products, processes, and objectives evolve over time. If the software that models the business can be encapsulated into business objects, it becomes flexible, extensible, and reusable, and therefore evolves as the business evolves.

A server-side component model may define an architecture for developing distributed business objects that combines the accessibility of distributed object systems with the fluidity of objectified business logic. Server-side component models are used on the middle-tier application servers, which manage the components at runtime and make them available to remote clients. They provide a baseline of functionality that makes it easy to develop distributed business objects and assemble them into business solutions.

Server-side components can also be used to model other aspects of a business system, such as presentation and routing. The Java servlet, for example, is a server-side component that is used to generate HTML and XML data for the presentation layer of a three-tier architecture. EJB 2.1 message-driven beans, which are discussed later in this book, are server-side components that can be used to consume and process asynchronous messages.

Server-side components, like other components, can be bought and sold as independent pieces of executable software. They conform to a standard component model and can be executed without direct modification in a server that supports that component model. Server-side component models often support attribute-based programming, which allows the runtime behavior of the component to be modified when it is deployed, without having to change the programming code in the component. Depending on the component model, the server administrator can declare a server-side component’s transactional, security, and even persistence behavior by setting these attributes to specific values.

As an organization’s services, products, and operating procedures evolve, server-side components can be reassembled, modified, and extended so that the business system reflects those changes. Imagine a business system as a collection of server-side components that model concepts such as customers, products, reservations, and warehouses. Each component is like a Lego(™) block that can be combined with other components to build a business solution. Products can be stored in the warehouse or delivered to a customer; a customer can make a reservation or purchase a product. You can assemble components, take them apart, use them in different combinations, and change their definitions. A business system based on server-side components is fluid because it is objectified, and it is accessible because the components can be distributed.

Enterprise JavaBeans Defined

Sun Microsystems’ definition of the Enterprise JavaBeans architecture is:

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.^[3]

That’s a mouthful, but it’s not atypical of how Sun defines many of its Java technologies—have you ever read the definition of the Java language itself? It’s about twice as long. This book offers a shorter definition of EJB:

Enterprise JavaBeans is a standard server-side component model for distributed business applications.

This means the EJB offers a standard model for building server-side components that represent both business objects (customers, items in inventory, and the like) and business processes (purchasing, stocking, and so on). Once you have built a set of components that fit the requirements of your business, you can combine them to create business applications. On top of that, as “distributed” components, they don’t all have to reside on the same server. Components can reside wherever it’s most convenient: a Customer component can “live” near the Customer database, a Part component can live near the inventory database, and a Purchase business-process component can live near the user interface. You can do whatever’s necessary for minimizing latency, sharing the processing load, or maximizing reliability.

---

^[1] In some cases, differences in database vendor’s support for SQL may require customization of SQL statements used in development.

^[2] Provided that the bean components and EJB servers comply with the specification, and no proprietary functionality is used in development.

^[3] Sun Microsystems’ Enterprise JavaBeans Specification, v2.1, Copyright 2002 by Sun Microsystems, Inc.