The CTM industry grew out of both the ORB and 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.
Transaction processing (TP) monitors have been evolving for about 30 years (CICS, the Customer Information Control System, was introduced in 1968) and have become powerful, high-speed server platforms for mission-critical applications. Some TP products, such as CICS and TUXEDO, may be familiar to you. TP monitors are operating systems for business applications written in languages such as COBOL. It may seem strange to call a TP monitor an “operating system,” but because it controls an application’s entire environment, it’s a fitting description. TP monitor systems automatically manage the entire environment in which a business application runs, 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 (RPCs). 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 though the procedures were 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; i.e., 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 monitors 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 a static method; there’s no such thing as a unique object. In addition, because TP monitors are based on procedural applications and not on objects, the business logic in a TP monitor is not as flexible, extensible, or reusable as business objects in a distributed object system.
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 in which 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.
As the advantages of distributed objects became apparent, the number of systems deployed using ORBs increased rapidly. 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 they 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, improving 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 in which TP monitors have always excelled.
With three decades of TP-monitor experience, it wasn’t long before companies such as IBM and BEA began developing a hybrid of ORBs and TP-monitor systems, which we refer to as component transaction monitors (CTMs). These types of application servers combine the fluidity 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 automatically managing concurrency, transactions, object distribution, load balancing, security, and resource management. 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 transaction management and other services, and a server-side component model. CTMs support 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 areas, including the relational database, application server, web server, CORBA ORB, and TP monitor industries. 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.
This chapter spends a lot of time talking about CTMs because they are essential to the definition 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 developers, 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 indexing 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 a waste of resources for an application developer to write a relational database from scratch when vendors such as Microsoft and Oracle already provide them.
Distributed business objects, if they are to be effective, require the same system-level management from CTMs as business data requires from relational databases. System-level functionality like concurrency, transaction management, and resource management is necessary if the business system is going to be used for large user populations or mission-critical work. It is unrealistic and wasteful to expect application developers to reinvent this system-level functionality when commercial solutions already exist.
CTMs are to business objects what relational databases are to data. CTMs handle all the system-level functionality, allowing the application developer to focus on the business problems. With a CTM, application developers can focus on the design and development of the business objects without having to waste thousands of hours developing the infrastructure in which the business objects operate.
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.
