Race to the Middle
Beth Gold-Bernstein
A component-based architecture is most adaptable to rapid changes. The trick is understanding the pieces of the middleware puzzle in order to make good business decisions
In today's business environment, the rate of change has accelerated beyond the point where we can accurately predict future needs. The only thing we can be sure of is more change; therefore, application architecture and supporting infrastructure must be designed for rapid deployment of new solutions.Client/server computing began with the idea of separating database management from the application; by putting the database on a server, it could be more easily shared and managed. In fact, a primary benefit of database server technology was the ability to ensure referential integrity in the database itself rather than in the application code.
E.F. Codd's primary design goal for the relational model was data independence. Indeed, client/server computing proved that data could be so independent as to be placed on different computers. All that was necessary was a mechanism for the application to send the SQL call across the network to the database and to have the database respond to the appropriate applications. This scenario describes the basic connectivity among clients and servers and is now being extended to the Internet as well.
However, two-tier client/server systems do not support evolving needs; they do not scale well to support large numbers of users, high transaction volumes, and the unpredictable workloads of new Internet applications. For these reasons, most emerging application architectures are multitiered--they feature thin clients (for example, browsers requiring no application installation or support), application servers that manage the business logic, and data sources on various platforms.
This new application architecture is distributed and integrated. Furthermore, there is a growing consensus that a component-based architecture is most adaptable to rapid changes in business and technology. The goal of a such an architecture is to assemble new applications from prefabricated components; these components may be purchased components or applications, "wrapped" legacy applications, and custom-built ones. They may reside on different technology platforms within and outside the organization. Properly designed, a component-based architecture will easily integrate legacy, current, and emerging technology.
Enabling seamless integration and communication among these components is by no means easy. It requires an extensive infrastructure or middleware architecture to connect the multitier application. This emerging middle-tier middleware is called various names: transaction server, application server, component server, and business rules server. Regardless of the name, terminology, or technology used in the current vendor solutions, the same set of services is required to deliver the full functional abilities of a distributed component architecture. These abilities include scalability, adaptability, recoverability, and manageability.
In this article, I'll describe the features and functions of what I call a generic application component server. It defines all the pieces of the middleware puzzle in order to help you evaluate vendor alternatives and make good decisions based on your needs.
Communication Modes and Mechanisms
There are three basic communication modes for distributed applications: conversational mode, remote invocation, and messaging.
Conversational mode. As its name implies, conversational mode is a synchronous communication--both parties are actively engaged in the conversation. Synchronous communications require a separate connection to the server for each request; consequently, conversational mode maintains state consistency. For example, an application that connects to a database can scroll through a large result set, and a placeholder in the result set will be maintained. This capability made conversational mode a natural choice for early two-tier client/server applications in which the client connected to the server.
Conversational designs are easy implemented and do not require an extensive infrastructure. However, as enterprise solutions are deployed to hundreds of users, synchronous communications can clog the network and strain the database. Therefore, the conversational mode is the least scalable alternative. Business applications for which synchronous conversational communications are best suited include decision support, applications that have a short expected life span, administrative applications such as table maintenance, and applications that do not require scalability and are not expected to adapt to business changes.
The basic conversational mechanism is the database API. In the early days of client/server computing, each database vendor published its API so that third-party vendors could write software to connect client applications to database servers. Powersoft gained significant early market share with its data window technology that automated the database connection process. The problem was that vendors had their own APIs--third-party tool vendors had to write code specifically to connect to each database. The answer to this problem was the standard call-level interface (CLI).
While the ANSI SQL Access Group worked on a standard CLI, Microsoft adopted the specs, ran with them, and developed ODBC. An ODBC driver is necessary for each target database, but the client-side code for connecting to the database is the same, making the application independent of any specific database. In the early days, there was much debate about the performance of ODBC vs. native database drivers. However, the adaptability of a standard database access mechanism, combined with the performance improvements of ODBC drivers, made ODBC the clear winner.
In conversational mode, the state of the query and transaction are maintained by the database. Most DBMS products offer a robust transaction management facility and database cursors that maintain the state of the query when processing the result set. The client process cannot be out of sync with the database process because the requesting application is blocked from further processing until it receives a reply.
The problem with conversational mode is that it requires a separate connection to the database for each process, and therefore does not scale well. Enterprise solutions with thousands of users or Internet solutions with unpredictable processing loads and numbers of users require a more scalable solution. This solution may include moving to multitier architectures and multiplexing connections to the server (see "Connection Management" in Figure 4).
Remote Invocation. Remote invocation is the process in which application code on one computer invokes the services of another code segment on another computer. In a synchronous form of remote invocation, the calling program is usually blocked from processing until results are returned from the remote computer. However, it is also possible for a remote invocation to be asynchronous. In that case, the calling program fires the remote procedure call (RPC) and continues processing while waiting for results from the remote process.
Remote invocation is a common communication mode; it extends common structured programming techniques to a distributed architecture. It delivers better performance than conversational mode because the remote code segment is precompiled. Remote invocation is widely used for multitier and thin-client distributed applications through three mechanisms: RPCs, CORBA ORBs, and Microsoft's COM.
RPCs enable a local system to invoke a procedure on a remote system as though it were located on the same processor. RPCs are easy for programmers to understand because they look similar to local subroutine calls. The Open Software Foundation (OSF) has even defined a standard transfer syntax for RPCs that allows for various representations of different types of data. It enables data transformation when the sender and receiver have different data formats. RPCs are widely used in distributed applications, and many RPC-based products are on the market.
Here's how it works. The client calls a local procedure called the client stub. It appears to the client that the client stub is the actual server procedure that it wants to call. The stub packages the request into a network message in a process called marshaling. The RPC is language independent in so far as a program written in any traditional 3GL can call the stub. The network message can be transmitted through either a connection-oriented or a connectionless protocol, but usually, RPCs are synchronous connections.
The RPC mechanism hides many underlying network complexities from the programmer, including establishing connections, assembling packets in the correct order, performing data conversions, passing arguments and results among client and server stubs, and invoking the remote procedures.
RPCs may be written in standard 3GLs such as C or with a tool that enables visual RPC development. Database vendors have also created proprietary procedural extensions to SQL that enable procedural code to be stored within the database. The client application can then issue a database RPC to execute the code. Unlike standard DCE RPCs, database RPCs are not platform-independent because they are written in proprietary languages.
In contrast to RPC, an ORB is a mechanism for implementing invocation among objects. It enables application processes or objects to access the services of other objects on local or remote machines; the location of the requested service or object is transparent to the calling process. ORBs provide language independence through language mapping, also called binding, as well as transparency for internetworking. The standard specification for the ORB is defined by CORBA.
Figure 1 illustrates the CORBA 2.0 ORB architecture. (Note that the yellow-colored components are new to the CORBA specification.) The client Interface Definition Language (IDL) stubs are much like those of RPC; the stub is a local proxy--a static interface--for the remote object. It also includes code for marshaling (packaging requests into network packets) much like RPCs do, relieving the programmer from low-level network programming.
The Dynamic Invocation Interface (DII)
allows for run-time method invocation. It includes an API for accessing metadata
that defines server object interfaces. The calling program can find the required
service at run time. This approach enables new services to be easily implemented
with minimal impact to existing code.
The ORB Interface contains APIs to local
application services for both the client and the server. The Interface
Repository API provides access to the IDL-defined object interfaces. This works
much like an active dictionary providing run-time metadata.
The server skeletons are essentially server
IDL stubs; they provide interfaces to the server object or service. The CORBA
2.0 spec defines both static and dynamic skeletons. The static skeletons are
created by the IDL compiler; the dynamic skeletons determine the target object
from the parameter values. They can be used to dynamically generate object
implementations or implement bridges among ORBs.
The Object Adapter provides the run-time
environment for instantiating server objects. It assigns object IDs and manages
requests and results. The Implementation Repository provides run-time
information about the classes a server supports, instantiated objects, and their
IDs.
There are currently a number of ORB products
on the market with varying degrees of compliance to CORBA. However, today's ORB
technology is too slow and inefficient to manage mission-critical applications.
Scalability and fault tolerance must be enabled before ORBs fully take over
middleware infrastructures. Even so, IBM is just one of a number of vendors
committed to implementing fully compliant CORBA solutions. CORBA is the standard
for open distributed computing and therefore best able to deliver a
platform-independent solution that can integrate all types of distributed
components.
Microsoft's Distributed Component Object
Model (DCOM) does not comply to standard CORBA specifications. The DCOM
infrastructure is built into Microsoft's operating system. This integration
means that DCOM can run only on Microsoft platforms, whereas CORBA is platform
independent.
The DCOM approach, while proprietary, can
potentially perform well. It also enables reuse of system services such as
naming services, storage, and uniform data transfer. As shown in Figure 2, COM
supports three types of servers: In-Process Server can be loaded into the client
process and is implemented as dynamic link libraries (DLLs), Local Server runs
in a separate process on the same machine and is implemented as an executable
module (EXE), and Remote Server runs on a different computer and can be
implemented with either DLLs or EXEs.
Messaging. Messaging is a form of
asynchronous communication that is efficient because the participants do not
have to be available at the same time. For example, consider a telephone
answering machine. In just the last few years, it has become ubiquitous.
Asynchronous messaging is an essential form of communication in the new
distributed architectures for many of the same reasons answering machines have
become an essential part of modern life.
Message-oriented middleware (MOM) provides
an API across hardware platforms, operating systems, and networks. One of the
distinguishing features of MOM is that it provides guaranteed message delivery
even if the destinations are not synchronously available. One of its drawbacks
has been that although messaging solutions have been available for some time,
they have usually been proprietary. As a result, the industry consortium
Message-Oriented Middleware Association (MOMA; www.moma-inc.org/moma_qa.html)
was created in 1994 to educate the market and "facilitate convergence
opportunities with complementary technologies." MOMA currently has close to 40
corporate, auditing, and user members. Corporate members include Application
Communications Inc., BEA Systems, DEC, IBM UK Labs Ltd., Momentum Software, NCE
Corp., PeerLogic Inc., Software AG, Sun Microsystems Inc., Talarian Corp., and
Veri-Q.
Figure 3 shows the structure of MOM. A
messaging product is installed on each of the participating platforms.
Asynchronous message queuing as well as synchronous message queuing are
supported; both reduce the number of required server connections and therefore
increase scalability.
In synchronous message queuing, the
connection is live. The application sending the request goes into suspend mode
until the acknowledgment to the message is returned. This task is performed
through connection-oriented protocols. In asynchronous message queuing, the
application sends the message and continues processing.
Messaging makes it easier to integrate
legacy systems, purchased applications, multiple custom applications, and
multiple technical platforms because one application or component does not need
to know the internal structure of another component or application--it only
needs to know the interface. However, a single business transaction will involve
the coordination of multiple distributed components (where a component may be
any of the above). The challenge is to ensure the integrity of distributed
transactions.
Transactional integrity is defined by the
ACID test (atomicity, consistency, isolation, and durability). Atomicity ensures
that all updates for a specific transaction are committed or they are all rolled
back. Consistency ensures that all parts of transaction are a correct
transformation of system state; in other words, it ensures that the business
transaction will accurately be represented in the system state of all
distributed components. Isolation protects concurrent transactions from
inconsistencies that could be caused by other transactions. Durability ensures
that uncommitted updates survive communication, process, and system failures.
Many distributed tools and mechanisms have
already been developed to ensure the integrity of distributed transactions,
including database transaction logs and transaction managers such as Tuxedo,
Encina, and others. Other essential distributed system services include
directory services for maintaining location transparency, security services for
maintaining access control across distributed components, and timing services to
synchronize transactions across computers, networks, and time zones. These
services were defined by the OSF in its Distributed Computing Environment (DCE).
Many of the technology pieces are available,
but lack of standards, multiple technology options, and different vendor
offerings make building an integrated, robust middleware infrastructure for
distributed components difficult as well as confusing. The middleware that truly
enables component architecture will make it possible to make many components on
different computing platforms appear as a single system.
Internet Communication Mechanisms
Many organizations are viewing the Web as the computing platform of the future,
enabling truly platform-independent applications that can be distributed without
administration overhead. As the uses of the Web evolve from static information
publishing to dynamic information retrieval and electronic commerce, the
supporting middleware must also evolve to support high-volume secure
transactions.
Web applications are multitier architectures where the client is a universal
browser and all the business logic is executed at the middle tier. The Internet
communication mechanisms are HTTP, CGI, IIOP, and JDBC.
As everyone knows by now, hypertext transfer
protocol (HTTP) is the primary communication mechanism among Web browsers and
servers. HTTP is a stateless protocol, meaning there is little ability for the
server and client to be aware of the state of the other. However, maintaining
information on system state is essential for database operations such as
scrolling result sets. Proposals to change the HTTP standard to remedy this
situation include adding state information to the protocol and implementing
persistent connection streams.
Because of the stateless nature of the Web,
each transaction consumes time and resources in the setup and tear down of
network and database connections. In OLTP-intensive applications, this
additional overhead becomes significant. The standards-track proposal regarding
persistent HTTP connections will have a significant, positive impact as it
becomes standardized.
Common Gateway Interface (CGI) is primarily
used for static data access to create new HTML pages. CGI creates a new HTML
page for the results of a SQL stored procedure or CGI-based procedure. It is a
synchronous and stateless communication mechanism that performs poorly for ad
hoc queries because result-set processing requires state management.
Internet Inter-ORB Protocol (IIOP) is a
dynamic invocation interface for the Web; it enables a Java applet to generate
server requests at run time. As IIOP is a synchronous communication mechanism,
the session between the client and server objects persists until either side
disconnects.
Java Database Connectivity (JDBC)--a
database API for Java--is obviously similar to ODBC. Like ODBC, it provides
synchronous communication mechanism to most relational databases through a
common API, providing database-independent access.
Middleware for the Middle Tier
Design and technology options may be possible for implementing a distributed
component architecture. A successful architecture will enable business solutions
that are adaptable, recoverable, and manageable; solutions that are difficult to
build and manage will not deliver business value over time. The goal of a robust
middleware infrastructure is to enable rapid deployment of business solutions
and decrease management overhead and cost.
The middleware infrastructure itself is a
component architecture. Middleware components provide system services, and may
be implemented in different ways. The current product offerings include:
- Implementing functionality through operating system services
- Building a specialized component/ application server product with a pragmatic mixture of proprietary and standard technology
- Using and expanding the services of the universal database
- Expanding the services of transaction monitors
- Generating the middle tier and communication among tiers with proprietary multitier development environments
- Implementing a standards-based approach based on the not-yet-finalized Object Management Group (OMG) Business Object Facility specification.
The current middleware trend is to package a robust set of middleware services in an application or component server. The OMG RFP for middle-tier server (the Business Object Facility) includes the features (along with some object-oriented specific services) shown in Table 1.
| TABLE 1. Business objects facility features |
|
General Application Component Server
Figure 4 shows the functional components of a general application component server. It is a composite sketch of the OMG-defined capabilities, current technology and system services, and emerging vendor offerings. Unlike those of OMG, this model is not meant to be a specification or a standard; it has not been subjected to the rigor of specification review. Rather, it provides a pragmatic look at the capabilities of this middle tier and provides a guide for evaluating products and component solutions. As I mentioned earlier, its functionality may be delivered in an application or component server, a transaction server closely integrated with the operating system, a universal database, or a combination of multiple technologies.
Keep in mind that no current vendor
offering provides all the services defined in the model. Most of the products
have been released within the past six to eight months (or are still in beta)
and are at version 1.0. In other words, the technology is still in its infancy
but evolving rapidly.
First of all, the architecture must support
multiple types of clients, including browsers with no application footprints,
browsers with installed Java applets ("hefty" clients), and "fat" client/server
applications where the code continues to run on the client. The fat clients may
not call upon the services of the business components, but will require other
services for scalability, adaptability, and manageability.
The communication mechanisms in this layer
will be determined by the type of client and access required. Most organizations
will need several different communication mechanisms. However, to increase
recoverability and decrease complexity and management costs, the number of
different mechanisms should be kept to the absolute minimum.
The boxes in Figure 4 represent generic
services (see sidebar, "Anatomy of an Architecture") that are required to
support the business requirements of scalability, adaptability, recoverability,
and manageability, security, and several less crucial functions. These services
that deliver the required functionality may be implemented in a variety of
ways--including through the operating system, specialized middle-tier server
software, enhanced technology solutions (such as TP monitors), universal
databases, or combinations of all of these. But because the permutations and
combinations of a solution can become complex and extremely difficult and
expensive to manage, robust, integrated solutions are always a good idea.
Scalability. In terms of scalability, a
system can scale to accommodate more users and higher transaction volumes in
several different ways:
- Upgrade the hardware platform. Solutions that offer platform independence enable rapid deployment and easier integration of new technology.
- Improve the efficiency of communications. In a distributed environment, the communications overhead is often a performance bottleneck. Session management will improve communication among clients and servers through session pooling.
- Provide transparent access to multiple servers to increase throughput during peak loads. Load balancing is especially necessary to support the unpredictable and uncontrollable demands of Internet applications. Load balancing is offered by some TP monitor products.
- Improve communication between the application component server and various data sources through connection management (pooling).
Adaptability. Adaptability is also essential for keeping pace with rapid change. It's enhanced when the middle-tier technology is a component-based solution that easily accommodates the integration of multiple technologies. Independence from hardware, operating system, and language creates the most adaptable and portable solutions. The connectivity mechanisms to multiple data sources also increase adaptability. Fortunately, this area is one in which several solutions are available, including ODBC, JDBC, native database drivers, messaging, RPCs (to database stored procedures), ORBs, and database gateways.
Recoverability. Recoverability from hardware failure, network failure, software failure, and distributed transaction failure is essential for any distributed component architecture that supports mission-critical applications. System solutions for recoverability include failover, fault-tolerant capabilities, and server cluster technology (in addition to its scalability benefits). Network availability is also essential for robust distributed systems of any kind.
Obviously, some of these services are in the system hardware architecture, operating system, and network infrastructure. However, the multitier architecture is dependent on them all.
One of the most important services that provides recoverability is transaction management. For example, the OMG RFP refers to a function called "backout," which is the ability to restore the system to an earlier state in the case of a failed distributed transaction.
Distributed transaction management can either be synchronous or asynchronous. The synchronous distributed transaction protocol involves two-phase commit; as the name implies, it is a two-phase process where all participating systems are polled about their readiness to commit, and if all respond affirmatively, the transaction is committed in all locations. If the transaction fails in any instance, all parts of the transaction are rolled back. This task is clearly a job for TP monitor technologies, some of which also enables asynchronous transaction management.
Manageability. Manageability refers to the set of services that ensures the continued integrity, or correctness, of the component application. It includes security, concurrency control, and server management:
- Security is essential for ensuring access to component services and that data is appropriately managed; these issues are particularly important in Internet applications. Integrated network, Internet, server, and application security is the most manageable solution. This approach can be simply described by "single login," which requires a rich infrastructure of network and system services. Firewalls and authentication mechanisms must also be supported for Internet security.
- With concurrency control, multiuser access can be managed without requiring explicit application code.
- Server management refers to the set of system facilities for starting and stopping the server, installing new components, managing security permissions, and so on. These services can be implemented through a "best of breed" third-party product approach, integrated in a middle-tier server product, or through operating system facilities.
Multiple database connectivity mechanisms. These mechanisms define how the components integrate with legacy systems, multiple data sources, and purchased applications. The middleware mechanisms, including an extensive offering of gateway technology, have been well defined. Messaging is especially important for communication with external, purchased, or legacy applications.
Complex Question, Complex Answer
While multitier component architectures can best support the adaptability, scalability, recoverability and manageability of rapidly changing business requirements, they are extremely complex to build. Parts of the technology solution have been available for some time, and others are rapidly being released. The solutions span hardware, operating systems, servers, databases, networks, and protocols.
Clearly, standard component interfaces are only part of the solution. Rapid development and deployment of new business solutions requires a robust middleware infrastructure and an integrated enterprise approach.
| Figure 4 depicts a standard set of middle-tier services. Lack of available tools and products to provide these services has made building multitier applications complex. The emerging vendor solutions offer different approaches to providing this functionality, including embedding much of it in the operating system (making the solution less portable), relying more on universal database technology, expanding existing TP monitor technology for application servers, using proprietary technology (as in multitier development tools), and focusing on just part of the solution (Web application servers). The purpose of this generic look at the middle-tier services is to help define what is and is not currently available in the products you are evaluating, and how that might affect your implementation.
Directory Services, also called naming services, provide location transparency for optimal adaptability. That means the application does not need to know where the required service is to access it. With directory services, components can "declare themselves"--advertise the availability of their services to the rest of the world by automatically publishing their interfaces in the directory. The OMG RFP includes search capabilities to permit locating qualified objects based on logical business needs rather than technical implementation solutions. Event Notification automated by the server, or "push" technology, saves a lot of application programming; it is also more adaptable for real-time information delivery. As soon as an event occurs to which a user or process subscribes, it will be notified automatically without having to "pull" the information. Business Component Management is actually a collection of services for managing access to the business services of the component (see Figure 5). At run time, the Component Manager calls on all the other services to manage the component application processing.
|
Beth Gold-Bernstein is president of IllumiSys Corp., a
company specializing in designing distributed enterprise systems and seminars.
Her book Designing Enterprise Client/Server Systems was published by Prentice
Hall in 1997. You can reach her at bgb@illumisys.com.
References
Resources and Suggested Reading
Web stes:MOMA: http://www.moma-inc.org/
Microsoft COM: http://www.microsoft.com/oledev/olecom/Ch01.htm
Microsoft Transaction Server :
Reviewer's Guide for in-depth information): http://www.microsoft.com/transaction/
White Paper: http://www.microsoft.com/transaction/learn/mtswp.htm
Microsoft DTC (Distributed Transaction Coordinator):http://www.microsoft.com/syspro/technet/boes/bo/sql/technote/dtcover.htm and http://www.microsoft.com/syspro/technet/boes/bo/sql/technote/dtcapps.htm
OMG RFP for Business Object Facility: http://www.dataaccess.com/bodtf/RFP.htm
OMG Business Application Architecture White Paper: http://www.tiac.net/users/jsuth/oopsla/bowp2.html
Oracle Web Application Server 3.0: http://www.oracle.com/products/asd/was/collateral
Sybase Jaguar CTS (Component Transaction Server) white papers: http://www.powersoft.com/products/jaguar/wp_jag2.html
and
http://www.powersoft.com/products/jaguar/wp_jag.html
Sybase dbQueue for MQSeries (asynchronous messaging to databases): http://www.sybase.com/products/internet/dbq
INFORMIX-NewEra (tool for multitier application development): http://www.informix.com/informix/corpinfo/zines/whitpprs/wht2/app/apppart.htm
"Objects in Middleware: How Bad Can It Be?" by Michael Stonebraker and Paul Brown: http://www.informix.com/informix/corpinfo/zines/whitpprs/howbad.htm
IBM Component Broker Connector White Papers: http://www.software.ibm.com/ad/cb
Full redbook: http://www.redbooks.IBM.com/SG242022/2022main.html
Books
Orfali R. and D. Harkey. Client/Server Programming with JAVA and
CORBA. Wiley, 1997.
Orfali R., D. Harkey, and J. Edwards. The Essential Distributed Objects
Survival Guide. Wiley, 1996.
Linthicum, D. Client/Server and Intranet Development. Wiley, 1997.