This book is about Enterprise JavaBeans 2.0 and 1.1, which are the third and second versions of the Enterprise JavaBeans specification. Just as the Java platform has revolutionized the way we think about software development, Enterprise JavaBeans has revolutionized the way we think about developing mission-critical enterprise software. It combines server-side components with distributed object technologies and asynchronous messaging 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, component transaction monitors (CTMs), and asynchronous messaging. 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 start looking at EJB itself and see how enterprise beans are put together. The rest of this 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, Sybase, 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. It’s the same with EJB. Ideally, an EJB component, an enterprise bean, can run in any application server that implements the EJB specification.[1] This means that you can develop and deploy your EJB business system in one server, such as Orion or 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 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.
Before defining Enterprise JavaBeans more precisely, let’s set the stage by discussing a number of important concepts: distributed objects, business objects, component transaction monitors, and asynchronous messaging.
Distributed computing allows a business system to be more accessible. Distributed systems allow parts of the system to be located on separate computers, possibly in many different locations, where they make the most sense. In other words, distributed computing allows business logic and data to be reached from remote locations. Customers, business partners, and other remote parties can use a business system at any time from almost anywhere. The most recent development in distributed computing is distributed objects . Distributed object technologies such as Java RMI, CORBA, and Microsoft’s .NET allow objects running on one machine to be used by client applications on different computers.
Distributed objects evolved from a legacy form of three-tier architecture used in transaction processing (TP) monitor systems such as IBM’s CICS and BEA’s TUXEDO. These systems separate the presentation, business logic, and database into three distinct tiers (or layers). In the past, these legacy systems were usually composed of a “green screen” or dumb terminal for the presentation tier (first tier), COBOL or PL/1 applications as the middle tier (second tier), and some sort of database, such as DB2, as the backend (third tier). The introduction of distributed objects in recent years has given rise to a new form of three-tier architecture. Distributed object technologies make it possible to replace the procedural COBOL and PL/1 applications on the middle tier with business objects. A three-tier distributed-business-object architecture might have a sophisticated graphical or web-based interface on the first tier, business objects on the middle tier, and a relational or some other database on the backend. More complex architectures often have many tiers: different objects reside on different servers and interact to get the job done. Creating these n -tier architectures with Enterprise JavaBeans is relatively easy.
Object-oriented languages, such as Java, C++, and Smalltalk, 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 combine 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.0 message-driven beans, which are discussed later in this book, are server-side components that are 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.
A new breed of software called application servers has recently evolved to manage the complexities associated with developing business systems in today’s Internet world. An application server is often made up of some combination of several different technologies, including web servers, object request brokers (ORBs), message-oriented middleware ( MOM), databases, and so forth. An application server can also focus on one technology, such as distributed objects. Application servers that are based on distributed objects vary in sophistication. The simplest are ORBs, which facilitate connectivity between the client applications and the distributed objects. ORBs allow client applications to locate and use distributed objects easily. However, ORBs have frequently proven to be inadequate in high-volume transactional environments. They provide a communication backbone for distributed objects but fail to provide the kind of robust infrastructure that is needed to handle larger user populations and mission-critical work. In addition, ORBs provide a fairly crude server-side component model that places the burden of handling transactions, concurrency, persistence, and other system-level considerations on the shoulders of the application developer. These services are not automatically supported in an ORB. Application developers must explicitly access these services (if they are available) or, in some cases, develop them from scratch.
Early in 1999, Anne Manes[2] coined the term component transaction monitor (CTM) to describe the most sophisticated distributed object application servers. CTMs evolved as a hybrid of traditional TP monitors and ORB technologies. They implement robust server-side component models that make it easier for developers to create, use, and deploy business systems. CTMs provide an infrastructure that can automatically manage transactions, object distribution, concurrency, security, persistence, and resource management. They are capable of handling huge user populations and mission-critical work but also provide value to smaller systems because they are easy to use. CTMs are the ultimate application servers. Other terms for these kinds of technology include object transaction monitor (OTM), component transaction server, distributed component server, and COMware. This book uses the term “component transaction monitor” because it embraces the three key characteristics of this technology: the use of a component model, the focus on transactional management, and the resource and service management typically associated with monitors.
[1] Provided that the bean components and EJB servers comply with the specification, and no proprietary functionality is used in development.
[2] At the time that Ms. Manes coined the term, she worked for the Patricia Seybold Group under the name Anne Thomas. Ms. Manes is now the Director of Business Strategy for Sun Microsystems, Sun Software division.
Get Enterprise JavaBeans, Third Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
