you're conversant in the JDBC API, or at least SQL. If you're not familiar with JDBC,see Database Programming with JDBCTM and Java M 2 Edition, by George Reese One of Java's most important features is platform independence. Since it was first eleased, Java has been marketed as"write once, run anywhere. While the hype has got ten a little heavy-handed at times, code written with Sun's Java programming language is remarkably platform independent. Enterprise Java Beans 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 dont have to code to a particular database implementation; just change JDBC drivers and you change database It's the same with Enterprise JavaBeans. Ideally, an Enterprise JavaBeans component,an enterprise bean, can run in any application server that implements the Enterprise JavaBeans(EJB)specification. This means that you can develop and deploy your EJB business system in one server, such as Orion, and later move it to a different EJB server such as Pramati, BEAs WebLogic, IBMs WebSphere, or open source projects like OpenEJB, JOnAS, and JBoss. Implementation independence means that your business components are not dependent on the brand of server, which means there are more Setting the Stage Before defining Enterprise Java Beans more precisely, lets set the stage by discussing a number of important concepts: distributed objects, business objects, and component transaction monitors and asynchronous messaging Distributed objects Distributed computing allows a business system to be more accessible. Distributed sys- tems allow parts of the system to be located on separate computers, possibly in many dif- ferent 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 any- where. The most recent development in distributed computing is distributed objects. DiS- I Provided that the bean components and EJB servers comply with the specification and no proprietary functionality is used in development. Copyright(c)2001 OReilly Associates
DRAFT 10/21/0107/06/01 Copyright (c) 2001 O'Reilly & Associates you’re conversant in the JDBC API, or at least SQL. If you’re not familiar with JDBC, see Database Programming with JDBC™ and Java™, 2nd Edition, by George Reese. 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 Enterprise JavaBeans. Ideally, an Enterprise JavaBeans component, an enterprise bean, can run in any application server that implements the Enterprise JavaBeans (EJB) specification.1 This means that you can develop and deploy your EJB business system in one server, such as Orion , and later move it to a different EJB server, such as Pramati, BEA’s WebLogic, IBM’s WebSphere, or open source projects like OpenEJB, JOnAS, and JBoss. Implementation independence means that your business components are not dependent on the brand of server, which means there are more options before you begin development, during development, and after deployment. Setting the Stage Before defining Enterprise JavaBeans more precisely, let’s set the stage by discussing a number of important concepts: distributed objects, business objects, and component transaction monitors and asynchronous messaging. Distributed Objects 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. Dis- 1 Provided that the bean components and EJB servers comply with the specification and no proprietary functionality is used in development
tributed object technologies such as Java RMI, CORBA, and Microsofts 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, which is used in TP monitor systems such as IBMs CICS or BEAs 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 terminals for the presentation tier(first tier), COBOL or PL/I applications on 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 dis- tributed business object architecture might have a sophisticated graphical or web based interface, business objects on the middle tier, and a relational or some other database on the backend. More complex architectures are often used in which there are many tiers: different objects reside on different servers and interact to get the job done. Creating these n-tier architectures with Enterprise Java Beans is relatively easy Server-Side Components 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 GUls, to simplify access to data, and to encapsulate the business logic. The encapsulation of business logic into business objects has become is a fairly recent focus in the infor mation technology industry. Business is fluid, which means that a businesss 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. They 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 presentation layer of a three-tier architecture. The eJB 2.0 message-driven beans which are discussed later, are a Copyright(c)2001 OReilly Associates
DRAFT 10/21/0107/06/01 Copyright (c) 2001 O'Reilly & Associates tributed 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, which is used in TP monitor systems such as IBM’s CICS or 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 terminals for the presentation tier (first tier), COBOL or PL/1 applications on 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, business objects on the middle tier, and a relational or some other database on the backend. More complex architectures are often used in which there are 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. Server-Side Components 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 has become 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. They 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 presentation layer of a three-tier architecture. The EJB 2.0 message-driven beans, which are discussed later, are a
server-side components that is used for routing asynchronous messages from one source to anot 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 components 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 eflects those changes. Imagine a business system as a collection of server-side components that model concepts like 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 s accessible because the components can be distributed Component Transaction Monitors 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, ORBs, MOM(message-oriented middleware), 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 facilitate connectivity between the client applications and the distributed objects and are called object request brokers(ORBs). ORBs allow client applications to locate and use distributed objects easily ORBs, however, have frequently proven to be nadequate in high-volume transactional environments. ORBs provide a communication backbone for distributed objects, but they 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 Copyright(c)2001 OReilly Associates
DRAFT 10/21/0107/06/01 Copyright (c) 2001 O'Reilly & Associates server-side components that is used for routing asynchronous messages from one source to another. 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 like 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. Component Transaction Monitors 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, ORBs, MOM (message-oriented middleware), 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 facilitate connectivity between the client applications and the distributed objects and are called object request brokers (ORBs). ORBs allow client applications to locate and use distributed objects easily. ORBs, however, have frequently proven to be inadequate in high-volume transactional environments. ORBs provide a communication backbone for distributed objects, but they 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 hey are available)or, in some cases, develop them from scratch Early in 1999, Anne Manes" 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 ransactions, object distribution, concurrency, security, persis tence, 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 server. Other terms for these kinds of technology include object transaction monitor(OTM), component transaction server, distributed component server, COMware, and so forth. 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 anagement typically associated with monitors Enterprise JavaBeans: Defined Sun Microsystems' definition of Enterprise JavaBeans 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 lat form that supports the Enterprise JavaBeans specification. Wow! Now thats a mouthful and not atypical of how Sun defines many of its Java tech nologies-have you ever read the definition of the Java language itself? It's about twice s long. This book offers a shorter defin 2 At the time that Ms Manes coined the term she worked for the Patricia Seybold Group under her maiden name, Anne Thomas. Ms. Manes is now the Directory of Business Strategy for Sun Microsystems, Sun Software division. 3 Sun Microsystems Enterprise Java TM Specification, v2.0, Copyright 2001 by Sun Microsystems Inc Copyright(c)2001 OReilly Associates
DRAFT 10/21/0107/06/01 Copyright (c) 2001 O'Reilly & Associates 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 Manes2 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 serverside 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 server. Other terms for these kinds of technology include object transaction monitor (OTM), component transaction server, distributed component server, COMware, and so forth. 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. Enterprise JavaBeans: Defined Sun Microsystems’ definition of Enterprise JavaBeans 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 multiuser secure. These applications may be written once, and then deployed on any server platform that supports the Enterprise JavaBeans specification.3 Wow! Now that’s a mouthful and 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: 2 At the time that Ms. Manes coined the term she worked for the Patricia Seybold Group under her maiden name, Anne Thomas. Ms. Manes is now the Directory of Business Strategy for Sun Microsystems, Sun Software division. 3 Sun Microsystems’ Enterprise JavaBeans™ Specification, v2.0, Copyright 2001 by Sun Microsystems, Inc
Enterprise JavaBeans is a standard server-side component model for component transac. tion monitors We have already set the stage for this definition by briefly defining the terms distributed objects, server-side components, and component transaction monitors. To provide you with a complete and solid foundation for learning about Enterprise JavaBeans, this chap- ter will now expand on these definitions If you already have a clear understanding of distributed objects, transaction monitors CTMs, and asynchronous messaging feel free to skip the rest of this chapter an move on Distributed Object Architectures EJB is a component model for component transaction monitors, which are based on dis- tributed object technologies. Therefore, to understand eJB you need to understand how distributed objects work. Distributed object systems are the foundation for modern three- tier architectures. In a three-tier architecture, as shown in Figure 1-1, the presentation logic resides on the client (first tier, the business logic on the middle tier(second tier), and other resources, such as the database, reside on the backend third tier) FIGUREI Figure 1-1: Three-tier architecture All distributed object protocols are built on the same basic architecture, which is designed to make an object on one computer look like it's residing on a different computer. Dis- tributed object architectures are based on a network communication layer that is really very simple. Essentially, there are three parts to this architecture: the business object, the skeleton and the stub The business object is the business object that resides on the middle tier. It's an instance of an object that models the state and business logic of some real-world concept, like person, order, account. Every business object class has matching stub and skeleton classes built specifically for that type of business object. So, for example, a distributed business object called Person would have matching Person stub and Person skeleton classes. As shown in Figure 1-3, the business object and skeleton reside on the middle tier. and the stub resides on the client The stub and the skeleton are responsible for making the business object, which lives on the middle tier, look as if it is running locally on the client machine. This is accomplished Copyright(c)2001 OReilly Associates
DRAFT 10/21/0107/06/01 Copyright (c) 2001 O'Reilly & Associates Enterprise JavaBeans is a standard server-side component model for component transaction monitors. We have already set the stage for this definition by briefly defining the terms distributed objects, server-side components, and component transaction monitors. To provide you with a complete and solid foundation for learning about Enterprise JavaBeans, this chapter will now expand on these definitions. If you already have a clear understanding of distributed objects, transaction monitors, CTMs, and asynchronous messaging feel free to skip the rest of this chapter an move on to chapter 2. Distributed Object Architectures EJB is a component model for component transaction monitors, which are based on distributed object technologies. Therefore, to understand EJB you need to understand how distributed objects work. Distributed object systems are the foundation for modern threetier architectures. In a three-tier architecture, as shown in Figure 1-1, the presentation logic resides on the client (first tier), the business logic on the middle tier (second tier), and other resources, such as the database, reside on the backend (third tier). [FIGURE] Figure 1-1: Three-tier architecture All distributed object protocols are built on the same basic architecture, which is designed to make an object on one computer look like it’s residing on a different computer. Distributed object architectures are based on a network communication layer that is really very simple. Essentially, there are three parts to this architecture: the business object, the skeleton, and the stub. The business object is the business object that resides on the middle tier. It's an instance of an object that models the state and business logic of some real-world concept, like person, order, account. Every business object class has matching stub and skeleton classes built specifically for that type of business object. So, for example, a distributed business object called Person would have matching Person_Stub and Person_Skeleton classes. As shown in Figure 1-3, the business object and skeleton reside on the middle tier, and the stub resides on the client. The stub and the skeleton are responsible for making the business object, which lives on the middle tier, look as if it is running locally on the client machine. This is accomplished