Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training,
learning paths, books, tutorials, and more.

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 introduced 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 systems whose applications are 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 system
runs in, including transactions, resource management, and fault
tolerance. The business logic in TP monitors is made up of procedural
applications that are often accessed through network
messaging or
remote procedure calls (RPC),
which are ancestors of RMI. Messaging allows a client to send a
message directly 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 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 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 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 objects allow
unique objects that have state and
identity to be distributed across a network so that they can be
accessed by other systems. 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
available and implemented in 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, 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 where TP monitors
have always excelled.

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 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 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 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 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
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
waste of resources for an application developer to write a relational
database from scratch when vendors like Microsoft, Oracle, and others
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 that the business objects operate in.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training,
learning paths, books, interactive tutorials, and more.