《高级Web技术》参考资料：应用web - EJB 3RD EDITION - Richard Monson-Haefel

to the client using it. In this example, the client could be located on the same machine or on a different machine very far away, but the clients interaction with the business object is the same. One of the biggest benefits of distributed object systems is location transpar ency. Although transparency is beneficial, you cannot treat distributed objects as local sbjects in your design because of the performance differences. This book will provide you with good distributed object design strategies that take advantage of transparency while maximizing the distributed systems performance When this book talks about the stub on the client, we will often refer to it as a remote ref- erence to the business object. This allows us to talk more directly about the business Distributed object protocols such as CORBA, DCOM, and Java RMi provide a lot more infrastructure for distributed objects than the Person example. Most implementations of distributed object protocols provide utilities that automatically generate the appropriate stubs and skeletons for business objects. This eliminates custom development of these constructs and allows a lot more functionality to be included in the stub and skeleton Even with automatic generation of stubs and skeletons, the Person example hardly scratches the surface of a sophisticated distributed object protocol. Real world protocols like Java RMI and CORBa lloP provide error and exception handling, parameter passing, and other services like the passing of transaction and security context. In addition, distributed object protocols support much more sophisticated mechanisms for connecting the stub to the skeleton; the direct stub-to-skeleton connection in the Person example is rly primitive Real distributed object protocols, like CORBA, also provide an Object Request Broker (ORB), which allows clients to locate and communicate with distributed objects across the network. ORBs are the communication backbone, the switchboard, for distributed objects In addition to handling communications, ORBs generally use a naming system for locating objects and many other features such as reference passing, distributed garbage collection, and resource management. However, ORBs are limited to facilitating communication between clients and distributed business objects. While they may support services like transaction management and security, use of these services is not automatic. with ORB most of the responsibility for creating system-level functionality or incorporating services falls on the shoulders of the application developer Copyright(c)2001 OReilly Associates

DRAFT 10/21/0107/06/01 Copyright (c) 2001 O'Reilly & Associates to the client using it. In this example, the client could be located on the same machine or on a different machine very far away, but the client’s interaction with the business object is the same. One of the biggest benefits of distributed object systems is location transpar￾ency. Although transparency is beneficial, you cannot treat distributed objects as local objects in your design because of the performance differences. This book will provide you with good distributed object design strategies that take advantage of transparency while maximizing the distributed system’s performance. When this book talks about the stub on the client, we will often refer to it as a remote ref￾erence to the business object. This allows us to talk more directly about the business object and its representation on the client. Distributed object protocols such as CORBA, DCOM, and Java RMI provide a lot more infrastructure for distributed objects than the Person example. Most implementations of distributed object protocols provide utilities that automatically generate the appropriate stubs and skeletons for business objects. This eliminates custom development of these constructs and allows a lot more functionality to be included in the stub and skeleton. Even with automatic generation of stubs and skeletons, the Person example hardly scratches the surface of a sophisticated distributed object protocol. Real world protocols like Java RMI and CORBA IIOP provide error and exception handling, parameter passing, and other services like the passing of transaction and security context. In addition, distributed object protocols support much more sophisticated mechanisms for connecting the stub to the skeleton; the direct stub-to-skeleton connection in the Person example is fairly primitive. Real distributed object protocols, like CORBA, also provide an Object Request Broker (ORB), which allows clients to locate and communicate with distributed objects across the network. ORBs are the communication backbone, the switchboard, for distributed objects. In addition to handling communications, ORBs generally use a naming system for locating objects and many other features such as reference passing, distributed garbage collection, and resource management. However, ORBs are limited to facilitating communication between clients and distributed business objects. While they may support services like transaction management and security, use of these services is not automatic. With ORBs, most of the responsibility for creating system-level functionality or incorporating services falls on the shoulders of the application developer

Component Models The term"component model"has many different interpretations. Enterprise JavaBeans specifies a server-side component model. Using a set of classes and interfaces from the javax. ejb package, developers can create, assemble, and deploy components that conform to the EJB specification The original JavaBeansM, is also a component model, but it's s not a serve component model like EJB. In fact, other than sharing the name" JavaBeans, these two omponent models are completely unrelated. In the past, a lot of the literature had referred to EJB as an extension of the original JavaBeans, but this is a misrepresentation. Other than the shared name, and the fact that they are both Java component models, the two APls serve very different purposes. EJB does not extend or use the original JavaBeans component model JavaBeans is intended to be used for intraprocess purposes, while EJB is designed to be used for interprocess components. In other words, the original Java Beans was not intended for distributed components. Java Beans can be used to solve a variety of problems, but is primarily used to build clients by assembling visual (GUn) and nonvisual widgets. It's an excellent component model, possibly the best component model for intraprocess development ever devised, but it's not a server-side component model. EJB is designed to address issues involved with managing distributed business objects in a three-tier architecture Given that JavaBeans and Enterprise JavaBeans are completely different, why are they both called component models? In this context, a component model defines a set of contracts between the component developer and the system that hosts the component. The contracts express how a component should be developed and packaged. Once a component is defined, it becomes an independent piece of software that can b distributed and used in other applications. A component is developed for a specific purpose but not a specific application. In the original JavaBeans, a component might be a push button or spreadsheet that can be used in any GUI application according to the rules pecified in the original Java Beans component model In EJB, a component might be a customer business object that can be deployed in any EJB server and used to develop any business application that needs a customer business object. Other types of Java component models include Servlets, JSPs, and Applets Copyright(c)2001 OReilly Associates

DRAFT 10/21/0107/06/01 Copyright (c) 2001 O'Reilly & Associates Component Models The term “component model” has many different interpretations. Enterprise JavaBeans specifies a server-side component model. Using a set of classes and interfaces from the javax.ejb package, developers can create, assemble, and deploy components that conform to the EJB specification. The original JavaBeans™, is also a component model, but it’s not a server-side component model like EJB. In fact, other than sharing the name “JavaBeans,” these two component models are completely unrelated. In the past, a lot of the literature had referred to EJB as an extension of the original JavaBeans, but this is a misrepresentation. Other than the shared name, and the fact that they are both Java component models, the two APIs serve very different purposes. EJB does not extend or use the original JavaBeans component model. JavaBeans is intended to be used for intraprocess purposes, while EJB is designed to be used for interprocess components. In other words, the original JavaBeans was not intended for distributed components. JavaBeans can be used to solve a variety of problems, but is primarily used to build clients by assembling visual (GUI) and nonvisual widgets. It’s an excellent component model, possibly the best component model for intraprocess development ever devised, but it’s not a server-side component model. EJB is designed to address issues involved with managing distributed business objects in a three-tier architecture. Given that JavaBeans and Enterprise JavaBeans are completely different, why are they both called component models? In this context, a component model defines a set of contracts between the component developer and the system that hosts the component. The contracts express how a component should be developed and packaged. Once a component is defined, it becomes an independent piece of software that can be distributed and used in other applications. A component is developed for a specific purpose but not a specific application. In the original JavaBeans, a component might be a push button or spreadsheet that can be used in any GUI application according to the rules specified in the original JavaBeans component model. In EJB, a component might be a customer business object that can be deployed in any EJB server and used to develop any business application that needs a customer business object. Other types of Java component models include Servlets, JSPs, and Applets

Component Transaction Monitors The CTm industry grew out of both the ORB and the transaction processing monitor (TP onitor)industries. The CTM is really a hybrid of these two technologies that provides a powerful, robust distributed object platform. To better understand what a CTM is, we will examine the strengths and weakness of TP monitors and orbs TP Monitors Transaction processing monitors have been evolving for about 30 years(CICS was intro- duced in 1968)and have become powerful, high-speed server platforms for mission-critical applications. Some TP products like CICS and TUXEDO may be familiar to you. TP monitors are operating systems for business applications written in languages like COBOL. It may seem strange to call a TP monitor an"operating system, " but because they control an application's entire environment, it's a fitting description. TP monitor systems automatically manage the entire environment that a business application runs in, including transactions, resource management, and fault tolerance. The business applications that run in TP monitors are written in procedural programming languages(e.g. COBOL and C that are often accessed through network messaging or remote procedure calls(RPC) Messaging allows a client to send a message to a TP monitor requesting that some application be run with certain parameters. It's similar in concept to the Java event model Messaging can be synchronous or asynchronous, meaning that the sender may or may not be required to wait for a response. RPC, which is the ancestor of RMI, is a distributed mechanism that allows clients to invoke procedures on applications in a TP monitor as if the procedure was executed locally. The primary difference between RPC and RMI is that RPC is used for procedure-based applications and RMI is used for distributed object systems. With RMI, methods can be invoked on a specific object identity, a specific business entity. In RPC, a client can call procedures on a specific type of application, bu there is no concept of object identity. RMI is object oriented; RPC is procedural TP monitors have been around for a long time, so the technology behind them is as solid as a rock; that is why they are used in many mission-critical systems today. But TP moni- tors are not object oriented. Instead, they work with procedural code that can perform complex tasks but has no sense of identity. Accessing a TP monitor through RPC is like executing static methods; theres no such thing as a unique object. In addition, because TP monitors are based on procedural applications, and not objects, the business logic in a TP monitor is not as flexible, extensible, or reusable as business objects in a distributed object system Copyright(c)2001 OReilly Associates

DRAFT 10/21/0107/06/01 Copyright (c) 2001 O'Reilly & Associates Component Transaction Monitors The CTM industry grew out of both the ORB and the transaction processing monitor (TP monitor) industries. The CTM is really a hybrid of these two technologies that provides a powerful, robust distributed object platform. To better understand what a CTM is, we will examine the strengths and weakness of TP monitors and ORBs. TP Monitors Transaction processing monitors have been evolving for about 30 years (CICS was intro￾duced in 1968) and have become powerful, high-speed server platforms for mission-critical applications. Some TP products like CICS and TUXEDO may be familiar to you. TP monitors are operating systems for business applications written in languages like COBOL. It may seem strange to call a TP monitor an “operating system,” but because they control an application’s entire environment, it’s a fitting description. TP monitor systems automatically manage the entire environment that a business application runs in, including transactions, resource management, and fault tolerance. The business applications that run in TP monitors are written in procedural programming languages (e.g. COBOL and C) that are often accessed through network messaging or remote procedure calls (RPC). Messaging allows a client to send a message to a TP monitor requesting that some application be run with certain parameters. It’s similar in concept to the Java event model. Messaging can be synchronous or asynchronous, meaning that the sender may or may not be required to wait for a response. RPC, which is the ancestor of RMI, is a distributed mechanism that allows clients to invoke procedures on applications in a TP monitor as if the procedure was executed locally. The primary difference between RPC and RMI is that RPC is used for procedure-based applications and RMI is used for distributed object systems. With RMI, methods can be invoked on a specific object identity, a specific business entity. In RPC, a client can call procedures on a specific type of application, but there is no concept of object identity. RMI is object oriented; RPC is procedural. TP monitors have been around for a long time, so the technology behind them is as solid as a rock; that is why they are used in many mission-critical systems today. But TP moni￾tors are not object oriented. Instead, they work with procedural code that can perform complex tasks but has no sense of identity. Accessing a TP monitor through RPC is like executing static methods; there’s no such thing as a unique object. In addition, because TP monitors are based on procedural applications, and not objects, the business logic in a TP monitor is not as flexible, extensible, or reusable as business objects in a distributed object system

Object Request brokers Distributed object systems allow unique objects that have state and identity to be accessed across a network. Distributed object technologies like CORBA and Java RMI grew out of RPC with one significant difference: when you invoke a distributed object method, it's on an object instance, not an application procedure. Distributed objects are usually deployed on some kind of ORB, which is responsible for helping client applications find distributed objects easily ORBs, however, do not define an"operating system"for distributed objects. They are simply communications backbones that are used to access and interact with unique remote objects. When you develop a distributed object application using an ORB, all the responsibility for concurrency, transactions, resource management, and fault tolerance falls on your shoulders. These services may be supported by an OrB, but the application developer is responsible for incorporating them into the business objects. In an ORB there is no concept of an"operating system, where system-level functionality is handled automatically. The lack of implicit system-level infrastructure places an enormous burden n the application developer. Developing the infrastructure required to handle concurrency, transactions, security, persistence, and everything else needed to support large user populations is a Herculean task that few corporate development teams are equipped to accomplish CTMs: The Hybrid of ORBs and TP Monitors As the advantages of distributed objects became apparent, the number of systems deployed using ORBs increased very quickly. ORBs support distributed objects by employing a somewhat crude server-side component model that allows distributed objects to be connected to a communication backbone, but dont implicitly support transactions, security, persistence, and resource management. These services must be explicitly accessed through APls by the distributed object, resulting in more complexity and, frequently, more development problems. In addition, resource management strategies such as instance swapping, resource pooling, and activation may not be supported at all These types of strategies make it possible for a distributed object system to scale, improv- ng performance and throughput and reducing latency. Without automatic support for resource management, application developers must implement homegrown resource management solutions, which requires a very sophisticated understanding of distributed bject systems. ORBs fail to address the complexities of managing a component in a high volume, mission-critical environment, an area where TP monitors have always excelled Copyright(c)2001 OReilly Associates

DRAFT 10/21/0107/06/01 Copyright (c) 2001 O'Reilly & Associates Object Request Brokers Distributed object systems allow unique objects that have state and identity to be accessed across a network. Distributed object technologies like CORBA and Java RMI grew out of RPC with one significant difference: when you invoke a distributed object method, it’s on an object instance, not an application procedure. Distributed objects are usually deployed on some kind of ORB, which is responsible for helping client applications find distributed objects easily. ORBs, however, do not define an “operating system” for distributed objects. They are simply communications backbones that are used to access and interact with unique remote objects. When you develop a distributed object application using an ORB, all the responsibility for concurrency, transactions, resource management, and fault tolerance falls on your shoulders. These services may be supported by an ORB, but the application developer is responsible for incorporating them into the business objects. In an ORB, there is no concept of an “operating system,” where system-level functionality is handled automatically. The lack of implicit system-level infrastructure places an enormous burden on the application developer. Developing the infrastructure required to handle concurrency, transactions, security, persistence, and everything else needed to support large user populations is a Herculean task that few corporate development teams are equipped to accomplish. CTMs: The Hybrid of ORBs and TP Monitors As the advantages of distributed objects became apparent, the number of systems deployed using ORBs increased very quickly. ORBs support distributed objects by employing a somewhat crude server-side component model that allows distributed objects to be connected to a communication backbone, but don’t implicitly support transactions, security, persistence, and resource management. These services must be explicitly accessed through APIs by the distributed object, resulting in more complexity and, frequently, more development problems. In addition, resource management strategies such as instance swapping, resource pooling, and activation may not be supported at all. These types of strategies make it possible for a distributed object system to scale, improv￾ing performance and throughput and reducing latency. Without automatic support for resource management, application developers must implement homegrown resource management solutions, which requires a very sophisticated understanding of distributed object systems. ORBs fail to address the complexities of managing a component in a high￾volume, mission-critical environment, an area where TP monitors have always excelled

With three decades of TP monitor experience, it wasnt long before companies like IBM and Bea began developing a hybrid of ORBs and TP monitor systems, which we refer to as component transaction monitors. These types of application servers combine the fluid ity and accessibility of distributed object systems based on ORBs with the robust "operating system"of a TP monitor. CTMs provide a comprehensive environment for server-side components by managing concurrency, transactions, object distribution, load balancing, security, and resource management automatically. While application developers still need to be aware of these facilities, they don' t have to explicitly implement them when using a ctm The basic features of a CTM are distributed objects, an infrastructure that includes trans- action management and other services, and a server-side component model. CTMs sup port these features in varying degrees; choosing the most robust and feature-rich CTM is not always as critical as choosing one that best meets your needs. Very large and robust CTMs can be enormously expensive and may be overkill for smaller projects. CTMs have come out of several different industries, including the relational database industry, the application server industry, the web server industry, the CORBa ORB industry, and the TP monitor industry. Each vendor offers products that reflect their particular area of expertise. However, when you're getting started, choosing a CTM that supports the Enterprise Java Beans component model may be much more important than any particular feature set. Because Enterpr rise JavaBeans is implementation independent, choosing an EJB CTM provides the business system with the flexibility to scale to larger CTMs as needed. We will discuss the importance of EJB as a standard component model for CTM later in this chapter Analogies to Relational Databases This chapter spent a lot of time talking about CTMs because they are essential to the defi- nition of EJB. The discussion of CTMs is not over, but to make things as clear as possible before proceeding, we will use relational databases as an analogy for CTMs Relational databases provide a simple development environment for application develop- ers, in combination with a robust infrastructure for data. As an application developer using a relational database, you might design the table layouts, decide which columns are primary keys, and define indexes and stored procedures, but you don't develop the index- ng algorithm, the SQL parser, or the cursor management system. These types of system level functionality are left to the database vendor, you simply choose the product that best fits your needs. Application developers are concerned with how business data is organized, not how the database engine works. It would be waste of resources for an application developer to write a relational database from scratch when vendors like Microsoft, Oracle, and others already provide them Copyright(c)2001 OReilly Associates

DRAFT 10/21/0107/06/01 Copyright (c) 2001 O'Reilly & Associates With three decades of TP monitor experience, it wasn’t long before companies like IBM and BEA began developing a hybrid of ORBs and TP monitor systems, which we refer to as component transaction monitors. These types of application servers combine the fluid￾ity and accessibility of distributed object systems based on ORBs with the robust “operating system” of a TP monitor. CTMs provide a comprehensive environment for server- side components by managing concurrency, transactions, object distribution, load balancing, security, and resource management automatically. While application developers still need to be aware of these facilities, they don’t have to explicitly implement them when using a CTM. The basic features of a CTM are distributed objects, an infrastructure that includes trans￾action management and other services, and a server-side component model. CTMs sup￾port these features in varying degrees; choosing the most robust and feature-rich CTM is not always as critical as choosing one that best meets your needs. Very large and robust CTMs can be enormously expensive and may be overkill for smaller projects. CTMs have come out of several different industries, including the relational database industry, the application server industry, the web server industry, the CORBA ORB industry, and the TP monitor industry. Each vendor offers products that reflect their particular area of expertise. However, when you’re getting started, choosing a CTM that supports the Enterprise JavaBeans component model may be much more important than any particular feature set. Because Enterprise JavaBeans is implementation independent, choosing an EJB CTM provides the business system with the flexibility to scale to larger CTMs as needed. We will discuss the importance of EJB as a standard component model for CTMs later in this chapter. Analogies to Relational Databases This chapter spent a lot of time talking about CTMs because they are essential to the defi￾nition of EJB. The discussion of CTMs is not over, but to make things as clear as possible before proceeding, we will use relational databases as an analogy for CTMs. Relational databases provide a simple development environment for application develop￾ers, in combination with a robust infrastructure for data. As an application developer using a relational database, you might design the table layouts, decide which columns are primary keys, and define indexes and stored procedures, but you don’t develop the index￾ing algorithm, the SQL parser, or the cursor management system. These types of system￾level functionality are left to the database vendor; you simply choose the product that best fits your needs. Application developers are concerned with how business data is organized, not how the database engine works. It would be waste of resources for an application developer to write a relational database from scratch when vendors like Microsoft, Oracle, and others already provide them