http://go.galegroup.com.ezproxy.sfpl.org/ps/retrieve.do?tabID=T004&res...
`
`Three-tier client server architecture: achieving scalability, performance, and efficiency in client
`server applications
`Wayne W. Eckerson
`Open Information Systems. 10.1 (Jan. 1995): p3. From General OneFile.
`Copyright: COPYRIGHT 1995 Patricia Seybold Group, Inc.
`Full Text:
`
`Achieving Scalability, Performance, and Efficiency in Client/Server Applications
`
`Introduction: Setting the Stage
`
`Architecture Is Critical
`
`The most hardened mainframe bigot has come to realize that client/server computing is not just
`another passing fad in the computer industry. Client/server computing is here to stay. The challenge
`now facing users is not whether to adopt client/server computing but how to make it work effectively
`to solve business problems on an enterprise scale.
`
`Most client/server applications today are departmental in scope. They are built on a two-tier
`architecture that is designed to support 15 to 20 users and run non-mission-critical functions. Most
`of these applications have been built with popular graphical user interface (GUI) development tools
`that pack all the code for the user interface, application logic, and services in a Windows PC. The
`client issues SQL calls across a local area network to a relational database to retrieve data for
`processing.
`
`Encouraged by the successes of these initial client/server applications, companies have been quick
`to expand the scope and complexity of the applications to address pressing business opportunities
`or requirements. Managers have asked developers to increase the number of users, functions, and
`data sources supported by these applications. This inexorable "scope creep" has been the downfall
`of many early client/server applications.
`
`Developers are now recognizing that a two-tier architecture is not sufficient to support enterprise
`client/server applications that provide high performance, scalability, availability, and reliability.
`
`Middle Tier of
`
`Application Servers
`
`THREE-TIER MODEL. Enter the three-tier client/server architecture. The three-tier architecture
`extends the previous model by adding a middle tier of intermediate servers to support application
`logic and distributed computing services. The middle tier is critical for providing location and
`migration transparency of distributed resources as well as a variety of services required to provide
`reliable, secure, and efficient distributed computing.
`
`Companies planning to build more scalable client/server applications should consider deploying a
`three-tier architecture. A three-tier architecture will allow introduction: Setting the Stage companies
`to leverage their investments in client/server to create applications that provide real bottom-line
`payback.
`
`However, building three-tier applications isn't easy, and there's little real-world experience to shed
`light on the process. Several of the programming tools that shipped in the past year support the
`
`1 of 15
`
`10/20/2016 3:19 PM
`
`IPR2017-00184
`UNIFIED EX1007
`
`

`
`http://go.galegroup.com.ezproxy.sfpl.org/ps/retrieve.do?tabID=T004&res...
`
`design and deployment of three-tier applications, but these tools are still immature and don't
`provide all the services needed to support a distributed computing environment.
`
`This article analyzes the makeup of a three-tier client/server architecture and examine the benefits
`and challenges it offers. It also examines the tools available today for building three-tier
`client/server applications and the key features and services they should support. Finally, the report
`examines how three-tier client/server architecture lays the foundation for distributed object
`computing.
`
`Definition of Terms
`
`Application Components
`
`vs. Physical Platforms
`
`As with any new buzzword in the computer industry, three-tier architecture means slightly different
`things to different people. The precise definition of tiers and what they represent in user computing
`environments are fuzzy.
`
`A three-tier architecture has two aspects. One is the application architecture, and the other is the
`deployment architecture. Application architecture refers to the constituent parts that make up an
`application. These are presentation, functional logic and data. Together, these components
`comprise the logical representation of an application.
`
`A deployment architecture, on the other hand, specifies the physical configuration of computers on
`which an application runs. In a two-tier deployment architecture, the client portion of the application
`runs on a desktop PC or workstation, and the server portion runs on a server machine across a
`network. The workstations and server machines are considered the tiers in a deployment
`architecture.
`
`A three-tier deployment architecture inserts an intermediate server between the desktop PC and
`the central server. In a three-tier architecture, the desktop PC handles the application's
`presentation component, the intermediate server supports functional logic and services, and the
`back-end server handles data processing. Here the physical deployment environment mirrors the
`logical application architecture. This creates an inherent synergy that provides many benefits. (See
`Illustration 1.)
`
`Application Architecture
`
`Application Components
`
`As was mentioned above, the three basic elements of an application are presentation, functional
`logic, and data. Presentation refers to the user interface, or the part of an application that controls
`what is displayed on a user's workstation screen. Functional logic refers to the tasks and rules that
`govern the way a business operates and the services required to implement them. Business rules
`are embedded in programming code. Data refers to the information the business accumulates
`about its customers and operations as well as the services required to access and manage those
`data.
`
`DECOMPOSABILITY. The key to three-tier application architecture is to ensure that each of these
`application elements is a separate, independent component within the application. Another way to
`
`2 of 15
`
`10/20/2016 3:19 PM
`
`

`
`http://go.galegroup.com.ezproxy.sfpl.org/ps/retrieve.do?tabID=T004&res...
`
`say this is that three-tier applications can be decomposed into presentation, functional logic, and
`data. This means that each component can be modified or replaced without any of the other
`components being rewritten or changed.
`
`Many Applications Aren't
`
`Decomposable
`
`Most older mainframe applications and some early client/server applications are not
`decomposable. Instead of being logically separated, these components are inextricably intertwined
`in the fabric of the application. Consequently, application components can't be easily extracted and
`ported to another platform or changed without affecting other parts of the application. It is difficult,
`for example, to migrate these types of mainframe applications to client/server platforms. Either the
`code is ported in entirety to Unix, or the applications have to be rewritten from scratch.
`
`GUI Builders. Client/server applications developed with popular GUI builders, such as Powersoft's
`Powerbuilder, link presentation and logic and rely on a remote server to store and manage data.
`These tools let developers paint application screens with GUI objects, such as radio buttons and
`dialog boxes, and then attach scripts to each object. Clicking on the object activates the script,
`creating an event-driven program. The logic in these applications is tied to the GUI. Changing the
`logic requires rewriting a script and relinking the script to the appropriate GUI object.
`
`In a decomposable application, presentation and function are separate, independent entities. This
`allows developers to run presentation on a desktop PC and functional logic on one or more
`computers on the network, which makes it easier to update applications since the logic is located in
`one place instead of on hundreds of remote computers.
`
`Application Interfaces
`
`There are three ways to create decomposable applications. One is to use a traditional
`programming language to segment monolithic applications into callable procedures. Another is to
`link programs running presentation, logic, and data components via common interfaces, such as
`remote procedure calls (RPCs) or application programming interfaces (APIS). The third way is to
`build presentation, function, and data components from a series of autonomous objects. (See
`Illustration 2). Application interfaces can range from SQL APIs, such as Microsoft's Open Database
`Connectivity (ODBC) and Sybase's DB-Lib, to RPCs to vendor-proprietary APIs.
`
`Building interfaces
`
`between All Application
`
`Components May Be
`
`Overkill
`
`For example, middleware vendor Open Environment has helped evangelize the notion of three-tier
`architecture. Its tools enable developers to build interfaces between presentation, function, and
`data service components of an application using a proprietary RPC or the Open Software
`Foundation's (OSF's) Distributed Computing Environment (DCE) RPC. However, building RPC
`interfaces between all application components may be overkill for many client/server applications.
`The method begins to pay off as companies begin to create enterprise environments in which large
`
`3 of 15
`
`10/20/2016 3:19 PM
`
`

`
`http://go.galegroup.com.ezproxy.sfpl.org/ps/retrieve.do?tabID=T004&res...
`
`numbers of clients need access to lots of distributed services in order to execute applications.
`
`Hybrid interfaces. A more common approach is to leverage vendor interfaces to link up
`components that may be distributed across platforms. For example, 4GL vendor Magna provides a
`transactional API on Windows PCs that enables developers to integrate front-end GUI programs,
`such as those written with Powersoft's Powerbuilder, to the 4GL Magna code that resides on a
`server. Magna also provides an API to execute transactions on relational database management
`systems (RDBMSs). Developers can also use the API provided by their RDBMS vendor to access
`data stored that database.
`
`Component-based
`
`Software
`
`Procedural Programs. Aside from interfaces, developers can create decomposable applications
`within a single programming language. This requires up-front planning and discipline. With
`traditional programming languages, developers must define portions of their code to be segmented
`into callable procedures. These procedures can be ported to another platform and connected back
`via an RPC at a later date. Most new mainframe applications are being designed in this way, which
`makes it easier to migrate these applications to client/server portions. Developers can simply call
`out the presentation and logic procedures and port them to a client/server platform. Unfortunately,
`these applications can gradually lose their decomposability as patches are applied. Companies
`must be diligent about maintaining a strict separation of application components.
`
`Objects Extend
`
`Decomposability
`
`Object-oriented applications extend the decomposability of applications to much finer levels of
`granularity. Objects can represent presentation, functional logic or data, or smaller elements within
`each of these components. For example, an object might be a radio button on a GUI or an "account
`summary" command in a bank teller application. Because objects encapsulate their implementation
`behind a generic interface, moving them from one platform to another is easier. Swapping out the
`underlying program that executes the object's behavior or methods is also easier.
`
`Three-Tier Deployment Architecture
`
`Enterprise Applications
`
`Often Require Three
`
`Tiers
`
`Companies have discovered the hard way that client/server applications built on two-tier
`deployment architectures don't scale well enough to support enterprise applications. By
`"enterprise," we mean applications that support core operational systems that run the company,
`such as order entry, inventory, distribution, and finance.
`
`Enterprise Application Characteristics
`
`These bet-your-business applications typically have been run on mainframes and minicomputers,
`and they comprise millions of lines of code and hundreds of gigabytes of data. The applications are
`
`4 of 15
`
`10/20/2016 3:19 PM
`
`

`
`http://go.galegroup.com.ezproxy.sfpl.org/ps/retrieve.do?tabID=T004&res...
`
`complex, involving considerable up-front analysis and design. Traditionally, completing a program
`has required 50 to 100 developers working for a year or more. The applications are used by
`hundreds or even thousands of users spread across large geographic areas. Enterprise
`applications have requirements for high reliability, availability, portability, scalability and
`performance.
`
`Early Stages of
`
`Deployment
`
`These enterprise applications requirements are difficult for client/server applications to meet. Many
`leading-edge users claim that only a three-tier client/server architecture can achieve these
`requirements. However, we are still at an early juncture in the deployment of three-tier client/server
`applications. There is little empirical evidence to determine whether three-tier architectures or
`client/server computing in general are up to the task. The few companies that have deployed
`three-tier client/server applications have done so in support of decision-support tasks. Most
`companies are still running operational applications in terminal-host environments, whether the
`dominant platform is a mainframe, minicomputer, or Unix server.
`
`Three-tier Architectures
`
`Are Useful for
`
`Downsizing
`
`Ironically, many companies view the three-tier architecture as the most way to migrate from
`terminal-host to client/server computing environments. These companies are moving presentation
`to intelligent workstations and either porting or rewriting mainframe applications to run on
`intermediate servers. Many of them plan to eventually migrate data off the mainframe once there
`are sufficiently high-powered Unix systems and RDBMSs. For now, many are content to use
`mainframes as giant data servers. Some companies, however, are moving all application
`components to smaller computing platforms.
`
`The Many Roles that intermediate Servers Play
`
`Add Flexibility in
`
`Application Configuration
`
`A three-tier deployment architecture leverages the components of a decomposed application. Since
`application elements are independent modules linked via some sort of interface, this gives
`developers or architects the freedom to deploy these components on optimal platforms.
`
`For example, NASA may have an application that helps plot voyages of the space shuttle. Part of
`that application may involve computing the trajectory of the spacecraft at liftoff to obtain optimal
`orbit during a week-long voyage. This compute function might perform better if it were calculated on
`a high-performance workstation or supercomputer. A three-tier application would allow that function
`to run on a separate intermediate server. Moreover, it would make the function available to current
`and future applications that may need to perform similar calculations.
`
`A three-tier architecture allows users to create a middle tier of intermediate servers whose purpose
`
`5 of 15
`
`10/20/2016 3:19 PM
`
`

`
`http://go.galegroup.com.ezproxy.sfpl.org/ps/retrieve.do?tabID=T004&res...
`
`is to process services or functions shared by many applications. Intermediate servers inject
`scalability and reusability into client/server environments. Instead of writing the same function or
`service in every new application, developers can write the application once and place it on a server
`accessible by all applications.
`
`Data Warehouses
`
`Similarly, companies can use intermediate servers for staging mainframe data. Companies could
`regularly extract mainframe data pertinent to a given department and download the data to an
`intermediate server. This moves data closer to users who need it, offloads processing cycles from
`the mainframe, and eases network loads.
`
`Services Platforms:
`
`Gateways and
`
`Transaction Monitors
`
`Intermediate servers can also support communications gateways, database gateways, and
`transaction monitors. For example, companies can run a database gateway, such as Information
`Builders' EDA/SQL, on an intermediate server to give users transparent access to more than 50
`SQL and non-SQL data stores across a network. EDA/SQL translates client API calls to the
`appropriate syntax for accessing remote data sources and handles underlying communications.
`Application developers don't have to know the details of where remote data sources are
`implemented and how to access and navigate through them to find specific data.
`
`MIGRATION TRANSPARENCY HIDES PLATFORM CHANGES FROM USERS. Besides location
`transparency, gateways running on intermediate servers provide migration transparency. That is,
`users can change the location or implementation of back-end resources without having to rewrite
`front-end applications. Intermediate servers allow companies to detach client applications from
`back-end resources.
`
`Consider, for example, a company that wants to migrate an RDBMS that is reaching its capacity
`from a uniprocessor to a symmetric multiprocessing machine on another part of the network. The
`address change is made once in the database gateway, and all client requests are redirected to the
`right destination. Clients still use the same interface calls to request data services.
`
`FAILOVER, LOAD-BALANCING. Companies are increasingly deploying transaction monitors on
`intermediate servers to augment their RDBMSs with key services, such as failover, load-balancing,
`and rollback and recovery of transactions. Transaction monitors, such as AT&T Global Information
`Solutions Top End or Novell's Tuxedo, manage the flow of requests to application resources, which
`are typically, but not exclusively, relational database engines. The transaction monitor can balance
`fluctuating loads across multiple instances (servers) of an application resource. It can also sense
`when an application server has failed and automatically redirect requests to remaining available
`servers. This provides high availability of system resources.
`
`PRIORITIZATION. Transaction monitors can also enforce a prioritization scheme, in which
`high-priority requests are given immediate access to application resources while low-priority
`requests are throttled back. This feature can help companies prevent users issuing ad hoc SQL
`queries from bogging down an online transaction system that drives the company's core business.
`
`6 of 15
`
`10/20/2016 3:19 PM
`
`

`
`http://go.galegroup.com.ezproxy.sfpl.org/ps/retrieve.do?tabID=T004&res...
`
`TRANSACTIONS. Finally, transaction monitors provide two-phase commit capabilities to ensure
`that updates across one or more databases are handled correctly and that data integrity is not
`jeopardized. Although many DBMSs provide commit, recovery, and rollback services, as well
`others mentioned above, transaction monitors running on an intermediate gateway provide a
`DBMS-independent method for implementing these services. Many companies are now using
`transaction monitors to manage all aspects of client/server interaction, not just for DBMS access
`and transaction control.
`
`Other Kinds of
`
`Application Services
`
`The intermediate server provides the basis of the transparency and extensibility of a three-tier
`deployment architecture. Companies can create a true distributed environment by providing clients
`with access to a series of applications and services running on multiple intermediate servers across
`a wide area network. (See Illustration 5.)
`
`For example, a company can break out an application that provides information about the weather
`and make it available to all users in the corporation. Alternatively, they can run core services, such
`as data access, transaction processing, directory, and security, on intermediate servers instead of
`building these services from scratch for every new application.
`
`Distributed Application
`
`Servers
`
`Companies can achieve even greater flexibility by distributing the services instead of centralizing
`them on a single machine or cluster of machines. (See Illustration 6.) This eliminates single points
`of failure in servers and networks which arise in a central server model. It provides greater options
`for routing around network or server failures and minimizes wide area network traffic by processing
`most services locally.
`
`Hewlett-Packard (HP), for example, provides a data warehouse gateway in its Palo Alto, California,
`office which is accessed by users throughout the United States and the Far East across Hp's
`high-speed network backbone. The gateway provides transparent access to multiple warehouses
`located in Palo Alto and elsewhere in the United States.
`
`HP is currently working on distributing instances of the gateway to several global regions, including
`the Far East. Each gateway would support duplicate data definitions and provide direct access to
`regional or local data warehouses. The gateway would direct requests for nonlocal data to one of
`the other regional gateways that manages access to those data. Distributing services provides
`faster access to application resources and, in effect, creates a network of peer-to-peer computing
`resources.
`
`Building Three-Tier Applications
`
`New and Emerging Tools
`
`OBJECT-ORIENTED AND CASE TOOLS. A number of tools for building three-tier applications are
`coming on the market. These include second-generation, object-oriented, client/server
`development tools, such as Template Software's SNAP, Forte Software's Forte, Magna Software's
`
`7 of 15
`
`10/20/2016 3:19 PM
`
`

`
`http://go.galegroup.com.ezproxy.sfpl.org/ps/retrieve.do?tabID=T004&res...
`
`Magna X, and Dynasty Technologies' Dynasty. (See our sister publication, Distributed Computing
`Monitor, December 1994.) In addition, integrated computer-aided software development
`environments (CASE), such as Andersen Consulting's Foundation for Cooperative Processing and
`Texas Instruments' Integrated Engineering Facility, now support development and generation of
`three-tier applications.
`
`Mix and match, best-of-breed approach. In addition, developers can create their own three-tier
`applications using tools for generating each of the three components: presentation, business logic,
`and data. They can then snap the pieces together using interfaces supported by the different tools.
`Obviously, manually integrating the components within a three-tier application is more difficult than
`using one tool to generate all components. However, using a best-of-breed approach prevents
`users from getting locked into a single vendor's proprietary scripting language, communications
`engine, or services.
`
`Second generation tools. The second-generation client/server tools are designed to produce
`enterprise-caliber client/server applications, whose requirements and characteristics are described
`in "Three-Tier Architectures" above. The tools are designed to build all types of applications, not
`just database applications. They enable teams of developers to design the entire application - the
`GUI, business logic, data access routines, and communications code - and store the designs in a
`shared repository with version control capabilities. The tools usually contain a GUI toolkit for
`painting screens, a proprietary 4GL for writing business logic, and a point-and-click interface for
`defining services, such as SQL generation and translation, data access, communications modes,
`security, management, and transaction controls. The tools generally support development in a
`Windows environment and generate code for a range of client and server platforms, databases,
`networks, and database gateways.
`
`3 Key Features:
`
`Partitioning,
`
`Concurreny and
`
`Serialization, Services
`
`There are several key features that tools must support for ensuring the proper generation of
`three-tier client/server applications and adequate performance. The first of these is partitioning.
`Most of the tools support partitioning facilities that enable developers to divide their completed
`application into client and server modules based on performance or other requirements. (See
`Illustration 7.) Some of these tools, such as Forte, dynamically partition applications, while others
`require developers to build applications with a partitioning scheme in mind.
`
`[ILLUSTRATION OMITTED]
`
`Example of Partitioning
`
`Forte, for example, allows developers to build logically complete applications and then partition
`them into client and server processes upon generation. A performance-tuning utility included in the
`tool allows developers to monitor message traffic between partitions. Developers can use this
`information to repartition applications. Repartitioning doesn't affect the internals of an application.
`
`On the other hand, tools such as Magna X generate the server side of the code along with
`
`8 of 15
`
`10/20/2016 3:19 PM
`
`

`
`http://go.galegroup.com.ezproxy.sfpl.org/ps/retrieve.do?tabID=T004&res...
`
`message formats and data access routines. Magna's strategy is to allow application developers to
`develop the presentation and data components of an application with tools of their choice. It then
`ties all the pieces together using proprietary interfaces built on top of interfaces from third-party
`transaction monitors, namely Tuxedo and Encina. With Magna X, developers must come up with a
`partitioning scheme before any development can occur. The team building the GUI must know how
`much of the application it is going to write before handing off control to the Magna X portion.
`
`Concurrency and
`
`Serialization
`
`Concurrency. In three-tier applications, business logic and services are placed on an intermediate
`server and are accessible by multiple clients. To manage this environment, the application server
`needs to be able to process multiple requests simultaneously in order to speed throughput and
`ensure adequate response times for users. This capability, known as concurrency, increases in
`importance as more users access the same resources at the same time. In two-tier applications,
`concurrency is handled by the underlying platform of the database server. In three-tier applications
`where business logic runs on a separate server from the database engine, concurrency must be
`provided by some other means. Typically, this service is made possible by a transaction monitor or
`a sophisticated operating system, both of which can thread multiple requests within a single
`process.
`
`Serialization. Concurrency must be accompanied by another service: serialization. Serialization
`ensures that applications access resources one at a time. Serialization prevents conflict and
`contention for shared resources, ensuring data integrity. Databases enforce serialization via lock
`managers. When no database is present or when data are stored in memory or some other
`resource, the application server must provide serialization, on its own. Transaction monitors can be
`called upon to enforce serialization, or tools can embed serialization capabilities and make them
`available to applications.
`
`Distributed lock manager. One of the obstacles right now to three-tier applications is the
`coordination of updates or certain types of reads among distributed databases. Enforcing
`serialization among distributed databases requires a distributed lock manager. There are few tools
`or DBMSs that can support distributed lock managers with any degree of performance or reliability
`today. This deficiency forces most three-tier applications to centralize data in a single database or
`in several local database engines from the same vendor.
`
`Services
`
`Application services. Three-tiered client/server applications require robust services to safely and
`reliably integrate all components of a distributed application and to ensure data integrity and
`adequate performance.
`
`The Patricia Seybold Group's Open Client/Server Framework depicts core services required by all
`client/server applications as well as enabling services that may or may not be used depending on
`application requirements. Core services are directory, security, and data services; enablers include
`transaction monitors and DBMSs, among others. Both core services and enablers sit below
`business logic in the Patricia Seybold Group's Framework. In Illustration 8, the pyramid depicts the
`range of services required by three-tier applications.
`
`[ILLUSTRATION OMITTED]
`
`9 of 15
`
`10/20/2016 3:19 PM
`
`

`
`The Role of Communications in Building Three-Tier Applications
`
`http://go.galegroup.com.ezproxy.sfpl.org/ps/retrieve.do?tabID=T004&res...
`
`Client/Server and
`
`Server/Server
`
`Communications
`
`The flexibility and extensibility of any three-tier application depends, to a large degree, on the
`communications services it uses to link disparate applications. Two-tier applications support simple
`client/server interactions. Clients establish sessions with servers and issue requests of RDBMSs by
`sending SQL statements across a network. This request/response mode of communications takes
`place across a single network protocol and is handled by Remote Procedural Calls (RPCs).
`
`Communication Modes
`
`Three-tier applications are more complex than others. They involve multiple network protocols,
`platforms, and resource servers. Three-tier applications need a communications service that
`supports multiple modes of communications. These are:
`
`* Datagrams. Datagrams are one-shot, one-way messages. Clients don't expect a response from
`the server.
`
`* Synchronous Mode. In the synchronous mode, a client issues a request and waits for a response
`before continuing processing or issuing the next request. Synchronous communications require an
`active connection between client and server nodes.
`
`* Asynchronous Mode. In asynchronous mode, the client issues a request but continues processing
`until a response is returned. The client may issue multiple requests and can field them in whatever
`order they return. Asynchronous communications are network independent. Clients can issue
`requests even if the network or remote system is down.
`
`* Conversational Mode. In the conversational mode, clients and servers issue multiple requests and
`responses in serial fashion within a single network session. Conversational protocols are IBM's
`CPI-C and APPC.
`
`Server-to-Server
`
`Communications
`
`Besides client-server communications, many applications support server-to-server
`communications. For example, a controller on a shop floor may send messages to a server about
`the number of parts a die machine has stamped. Or a stock ticker on a trading floor may broadcast
`messages to a network of trader workstations. In these cases, a person sitting at a workstation is
`not initiating the conversation.
`
`Three types of middleware support many of the above communications modes across almost any
`network protocol: RPCs, message-oriented middleware (MOM), and object request brokers
`(ORBs). Each has its own strengths and limitations and is suited for specific types of applications.
`
`RPCs. RPCs are geared toward handling synchronous communications. RPCs have been the
`basis for most early client/server implementations that require a tight coupling between client and
`
`10 of 15
`
`10/20/2016 3:19 PM
`
`

`
`http://go.galegroup.com.ezproxy.sfpl.org/ps/retrieve.do?tabID=T004&res...
`
`server processes. An RPC allows an application to call a procedure on a remote machine as if it
`were part of the same application. The RPC establishes communications code and handles data
`translation transparently to developers. RPCs provide fast performance but are vulnerable to
`network and systems slowdowns or outages. Newer RPCs use threads to support asynchronous
`and conversational communications.
`
`MOM. MOM is geared toward asynchronous communications and works best with loosely coupled
`applications that don't require real-time information swapping. These include workflow applications,
`replication, and near-real-time batch updates. MOM sends messages between applications via
`queues that are located on local, remote, and network nodes. Queues are essentially buffers that
`can hold from one to hundreds of messages. The queues can be persistent (disk-based) or
`nonpersistent (memory-based). Persistent queues provide guaranteed delivery of messages.
`Nonpersistent queues provide faster performance but have the potential to lose messages if there
`is a prolonged network or systems outage. MOM can be easily set up to support most modes of
`interapplication communications.
`
`ORBs. ORBs are higher-level communications constructs that deal with objects rather than
`communications modes. ORBs can run on RPCs or MOM or directly on top of network interfaces,
`such as TCP/IP. The Object Management Group (OMG) recently declared an interoperability
`protocol that is based on TCP/IP. A minority faction within the OMG was pressing to create the
`interoperability