Figure 1: The forces separating application components over a network across machines
Chris Tham
Architecture Consultant, Professional Services
AT&T Global Information Solutions
This paper gives an overview of the different ways of designing and implementing client/server architectures on open systems using de jure and de facto standards. It presents brief examples of client/server architectures that the author has encountered. It is not intended to be an exhaustive survey of the diversity of such architectures, whether in research or in industry. The paper also introduces the concept of transaction processing, and how it can be implemented on a client/server model. Finally, the paper describes an example of a client/server architecture incorporating several of the models outlined in this paper including distributed transaction processing.
The use of the term "client/server" has become as pervasive as a number of other Information Technology buzzwords that are supposed to cure whatever it is that ails organisations around the world: downsizing/rightsizing, object-oriented, graphical user interface, rapid application development, visual prototyping, etc.
It has been used to help sell hardware and software products in the same way that "biodegradable" is used to sell laundry detergents: one can almost imagine it on an evaluation checklist as part of a purchasing decision!
But what does the term actually mean? Or, for that matter, what exactly is a "distributed client/server architecture?" As is usual with many overly-hyped phrases, client/server technology has been described by so many sources in so many ways.
This paper attempts to relate the definition of client/server within the wider context of distributed co-operative processing and enterprise computing architectures. It discusses the factors encouraging the distribution of applications and enabling technologies.
A tour through different client/server models is presented, along with examples of several research and commercial client/server architectures employing these models and using open systems standards and technologies. This paper is not intended to be an exhaustive survey: for that a book would be necessary and the reader is guided towards the ones mentioned in the References section at the end of this paper.
Finally, an example of a distributed architecture using a hybrid approach (combining several client/server models within the architecture) is presented.
A computing architecture is a set of definitions, rules and terms that are used to construct a computing environment, possibly consisting of multiple hardware units and software packages. The architecture provides a framework for developing applications and ensures that they communicate and inter-operate with each other. The framework includes definitions of layers for specifying computing services, the standards that govern the use of those services, and the protocols for communication between layers.
An enterprise computing architecture tries to integrate information at all organisational levels to provide centralised control of information but decentralised access to information from multiple end-points. Depending on the organisation structure of the enterprise, enterprise computing architectures tend to be based on three forms of data access and processing:
The goal of a distributed enterprise computing architecture is to provide seamless integration of possibly heterogeneous systems:
reimplementing existing applications.
Enablers of seamless integration include the development of:
However, there are significant cultural and technical barriers to seamless integration which result in trade-offs when designing an enterprise computing architecture. These barriers include the changing nature of business, behavioural resistance, immature technology, ill-defined standards, etc.
A computing model is a representation of a generalised style of computing that can be used as a basis for designing computing architectures.
This paper discusses client/server computing models used to implement distributed computing architectures based on open systems standards.
It is important to note that distributed computing is not synonymous with the concept of open systems; the IBM SNA hierarchical network is an example of a very successful distributed computing architecture. However, a distributed client/server architecture based on open systems may realise the promises of open systems and adoption of standards: transparent program and data distribution and networking, inter-operability, and portability.
The client/server computing model was initially used to describe the co-operative processing interaction between two programs (on the same machine): an application (called the client) requesting information, and a supporting service (called the server) that processes the request and returns the information to the client.
This model was then extended to the concept of software/hardware components providing services or managing resources on behalf of other components across a network.
The natural extension of the client/server computing model is peer-to-peer processing, where computing resources can act as both clients and servers in a symbiotic and synergistic relationship with each other. The workload for any particular service can be distributed amongst available servers across the network.
The "ideal" is distributed co-operative processing and transparent access to resources where portions of applications run on different computers and data may be at various installations.
Client/server and peer-to-peer processing are instances of what the ACM Taskforce on the Core of Computer Science refer to as "models for distributed computation.".
The generalised concept, distributed processing or distributed computing, is defined by the ISO CCITT Open Distributed Processing (X.90x) draft as "that class of information processing activities in which discrete components may be located at more than one location, or where there is any reason which necessitates explicit communications among the components."
A distributed computing environment based on open system standards may be hosted on multi-protocol networks and heterogeneous computing platforms.
A pure distributed environment would consist of collections of general-purpose systems with equal capabilities. By contrast, typical distributed client/server architectures usually specify specialised client and server hardware components within a networking environment. This is done in order to achieve the full benefits from co-operative processing and to achieve high performance and inter-operability.
This has encouraged the wide-spread use of the terms client and server to refer to hardware components, i.e. different types of computers on a network.
What factors are responsible for the evolution of the client/server architecture into distributed co-operative processing? After all, it can be argued that a distributed environment is more complex and difficult to implement, as well as posing significant challenges in terms of management, security, performance measurement and capacity planning.
There are two opposing forces which tend to break up applications into multiple application components and distribute these components across multiple systems: one encourages the migration of components closer to end users, and the other encourages the migration of components to centralised systems.
Figure 1: The forces separating application components over a network across
machines
Other reasons for distributing application components include:
The evolution of intelligent personal workstations (i.e., personal computers as well as UNIX workstations) has caused a trend towards large numbers of inexpensive but powerful processors connected by high speed networks. The tremendous growth in the sheer computing power within each workstation has encouraged the migration of application functionality closer towards end users for price/performance reasons.
This is abetted by the availability of graphical user interfaces on workstations which support multiple, concurrent windows and allow users to manage higher volumes of information. Finally, enterprises are becoming flatter, more decentralised and loosely-coupled - which also encourages the down-sizing of business processing closer to users.
On the other hand, the increasing need for end users to access data collected from various sections of the enterprise or even across enterprises in a unified and integrated fashion has promoted the centralisation of strategic business logic on large systems and has pushed the conglomeration of data into centralised repositories (sometimes called Information Warehouses).
End users want to access information from multiple sources using multiple delivery channels:
There are many advantages of utilising a client/server computing model. The following are some examples:
On the negative side, client/server architectures are still evolving and some products are relatively immature. Client/server development requires a strong systems development and life cycle methodology.
The primary disadvantage of a client/server architecture is the perceived (and real) complexity, and there are significant operational issues (How does one manage a distributed environment successfully?) such as security, costs, etc.
A typical application has three basic components:
This is the part of the application that interacts with the user.
This is the part of the application that processes business tasks and manipulates data within the application.
This is the part of the application that stores and retrieves data into and from permanent storage (on a file system or on a database management system).
Figure 2: Application components
The separation of application logic into these components is not always straight-forward and the boundaries between the components are not always clearly defined.
Client/server architectures employ distributed co-operative processing to:
Distribution can be done to software components as well as hardware components but the major advantages of distribution (transparency, inter-operability, portability, availability and scalability) are mostly realised by distribution across hardware components.
A distributed client/server architecture needs to specify a mechanism for handling client/server interactions. The mechanism provides facilities for developing networked applications distributed across heterogeneous networking and operating systems. Client/server mechanisms consist of:
Fundamental core technologies used for implementing client/server mechanisms include:
RPCs allow programs to execute a set of instructions on a remote machine through what appears to be a local procedure call, and then wait for a response. The RPC code assembles the parameters of the procedure call and sends it across a network. The caller program and called procedure are tightly coupled: changing the procedure definition involves changing both ends.
As the client waits until it gets a response, network performance is critical to response time and a high speed LAN environment with sufficient bandwidth is required. RPCs are usually poor at handling exception conditions (such as when a network node is unavailable or unreachable).
RPCs are widely used as the underlying transport mechanism in many commercially available distributed computing products. Many distributed operating systems (e.g. Amoeba, Sprite, etc.) use RPC for kernel-to-kernel communication. Others, including the Stanford V System, Chorus, Mach (which is used as a model for the development of Microsoft Windows NT as well as Taligent Workplace OS) rely on message passing mechanisms (see below).
Message passing involves the use of messages between programs to exchange data either synchronously, asynchronously, or within the context of a conversation. It is useful for connecting loosely-coupled or autonomous application components.
Message passing techniques employ queues or buffers to log or hold messages on their way to destinations, and may support delivery acknowledgment, priority handling and content translation of messages. A message passing API is usually fairly simple: it consists of commands to establish and terminate conversations between clients and servers, message sending and receiving commands, and error handling.
Message passing bypasses the network-dependent, time-delay characteristics or RPCs and can guarantee message delivery in the event of network failure or an inoperable server.
Message passing are not as widely implemented as RPCs (read: less mature).
The most recent technology used to implement client/server processing is heavily dependent on object-orientation: Object Request Brokers act as an intermediary between objects distributed across a network and allows these objects to exchange messages. ORBs are still fairly immature and usually rely on more mature technologies (such as RPCs) as underlying transport mechanisms.
The Object Management Group (OMG) is currently developing standards for ORBs under the umbrella of the Common Object Request Broker Architecture (CORBA).
Strictly speaking, SQL is not a client/server mechanism but a database access language. However, many relational database management vendors have heavily promoted the use of SQL as a distributed application development language.
Examples include Oracle Cooperative Development Environment and Glue; Infomix 4GL, HyperScript and NewEra; Ingres Vision, Windows/4GL and Open Road; Progress 4GL/RDBMS and FastTrack; Sybase APT and GainMomentum.
These development tools and environments rely upon remote database access technologies such as Microsoft ODBC; Borland IDAPI; Oracle SQL*Net; Informix-Net and Informix-Star; Ingres/Net and Ingres/Star; Sybase Open Client and Open Server, as well as OmniSQL Gateway.
A client interacts with the server via a distributed SQL interface: i.e. SQL requests are executed on a remote database server. Hence, client/server interactions are limited to database operations. However, this simplifies the programming model and reduces the learning curve for programmers.
SQL access across a network is the most widely implemented client/server mechanism in commercial systems today. Some vendors are attempting to widen the access method beyond pure SQL statement processing, such as calling stored procedures or even semi-generalised procedural processing (e.g. Oracle PL/SQL and Oracle Procedural Gateway).
The questions that every client/server system designer asks are: what application components to distribute, when to distribute, and how to distribute. There is no universal recipe that works in all situations, and therefore different needs have resulted in several possible styles of co-operative processing between various distributed components.
The following models for designing distributed client/server architectures can be defined:
The following figure shows how each model distribute application components across client and server network nodes:
Figure 3: Client/server distribution models
In the DP model, presentation functions are distributed across two or more network nodes. Typically, a portion of the presentation logic (usually the graphical user interface, which has compute-intensive, event-driven requirements) resides on a specialised client workstation, whilst the remainder of the application is located on other nodes.
The canonical example of a client/server architecture employing the DP model is the X Window System. Somewhat confusingly, the X Window System model reverses the usual definition of client and server: The X Window server manages the display screen(s) and control of user input devices (i.e. the keyboard and mouse) and X Window clients are applications (distributed across the network) that the user wishes to interact with. X Window clients communicate to servers using the X Window protocol, which typically runs over TCP/IP.
Presentation functions are said to be remote (from the business logic component) when the entire presentation logic of the application resides on one network node whilst the remainder of the application resides on other nodes. This helps insulate business processing logic from deciding how data is to be displayed, and allows multiple user interfaces to use a common application source stream.
Many Berkeley networking utilities are written using a front-end vs back-end architecture. The front-end (e.g. ftp, telnet, rlogin) handles the presentation component and the back-end (ftpd, telnetd, rlogind) runs on a different network node.
Other UNIX applications written using Berkeley sockets typically follow this model, but some extend it. Two interesting examples are the multi-user game xtrek and the Mandelbrot generation and display program xmandel.
Xtrek has a front end responsible for presentation functions and a back-end (shared between players) responsible for co-ordinating the player against other players and computer generated players. The xmandel program distributes the calculation and generation of portions of a Mandelbrot fractal image across to multiple network nodes, but only the front-end is responsible for displaying the fractal image on an X Window display.
Both xtrek and xmandel are of course X Window applications, hence employ a client/server architecture that is based on a mixture of both the DP and RP models.
A somewhat complex example of the RP model in a commercial client/server implementation would be an Oracle SQL*Forms application (running on a UNIX workstation or Personal Computer) communicating with the Oracle RDBMS (running on a UNIX or VMS server) with business logic coded as stored procedures.
It is interesting to note that the logical extension of the RP model is the use of client access programs to access global information from many sources. The development of tools to browse, retrieve, and discover Internet resources is a prime example: starting with USENET news readers and finger to resource discovery systems such as WHOIS, archie, World Wide Web (WWW), Wide Area Information Servers (WAIS) and the Internet Gopher.
Distributing business logic across several computers can potentially realise the full benefits of using the distributed co-operative processing model: parallel processing, higher application availability through workload distribution and replication, and increased scalability. The DTP model is also the most difficult and complex model to implement as well as manage, since it requires a sophisticated underlying program-to-program communications mechanism, as well as features such as data integrity, availability, load balancing, and scalability.
Simple application distribution architectures can be constructed using a front-end/back-end split and many UNIX applications utilising Berkeley sockets are written this way, as well as early implementations of many relational databases on UNIX.
However, a generalised application distribution model is closely related to the notion of transactions and transaction management, which is why the model is called Distributed Transaction Processing.
The DTP approach focuses on designing application and business logic in terms of modular, well-defined functional chunks and then distributing them across several machines.
The great white hope of a vendor-neutral platform for supporting the DTP model is the Open Software Foundation's Distributed Computing Environment (DCE). DCE is organised as a set of services to enable the design and implementation of client/server systems where application components are distributed across a network. DCE include the following components to facilitate distributed programming:
Figure 4: DCE Architecture
DCE provides a very comprehensive set of services to enable distributed client/server architectures based on the DTP model to be built. However, DCE does not really provide transaction management features (although Transarc Encina layers transaction management facilities on top of DCE).
Transaction processing is based on the idea that a stream of requests can be executed as discrete units of work. Each logical unit of work, or transaction, has a definite beginning and end and takes a computing system from one consistent state to another.
A transaction is considered transient until the decision is made to either successfully complete (commit) the work performed within the transaction, or abort (rollback) the work. The work of a transaction may be "rolled back" anytime before the commit occurs. Once the commit is processed, the work of the transaction is considered permanent.
There are four basic properties of a transaction:
These four properties are collectively known as the ACID properties. Supporting these properties requires recovery and concurrency mechanisms, typically implemented by a transaction processing management system, sometimes called a transaction processing monitor. These systems typically provide tools for developing transaction processing systems, an execution environment for transaction management, and administrative support for configuring transaction processing systems.
Historically, transaction processing systems were based on the notion of a large central site to which all transaction requests were routed (e.g. the IBM Customer Information Control System or CICS for IBM mainframe transaction processing).
As distributed client/server architectures become prominent, the notion of distributed transaction processing was introduced. A distributed transaction (sometimes called a global transaction) require the same ACID properties but the work performed by the transaction may span multiple network nodes. The use of two-phase commit procedures, first introduced within the context of distributed databases, is critical for supporting data integrity, recovery and consistency.
In the two phase commit protocol, all participants responsible for updating data within the context of a transaction negotiate with a co-ordinator. Participants attempt to reach a common understanding with respect to committing or aborting data changes in the first phase, and then implement this decision in the second phase.
Distributed transaction processing monitors use client/server technologies to provide an environment for transaction management across a distributed computing environment, and hence allow designers to implement an architecture based on the client/server DTP model. These monitors also provide additional services, including client/server authorisation and authentication, distributed load balancing and scheduling, service replication, and links to resource managers (typically, relational databases but can be any subsystem managing resources) and other transaction management systems.
Examples of open systems based DTP monitors include:
Both Tuxedo and TOP END rely on message passing facilities using the UNIX System V Transport Layer Interface (TLI) for client/server communications. Encina and CICS/6000 relies on OSF/DCE RPC and in addition takes advantage of other DCE services, including threads, security and directory services.
In the RDM model, the application component executes business logic on one computer, but data is accessed and modified at a single remote location on the network. Essentially, an RDM environment consists of many clients accessing a single location of storage for data, so the data itself is not distributed.
A simple way to achieve this on a Personal Computer is by using the file sharing services provided by a Network Operating System (NOS). Although the application runs wholly on a single machine (the Personal Computer), data is stored on another machine (the file server). Another approach is to standardise on a data query/manipulation language (such as SQL) and writing applications that send data access commands over the network to remote backend database servers.
Sometimes the database also incorporates stored procedures (proprietary extensions to SQL to provide procedural capabilities). This allows some application or business functionality to be distributed onto the servers as well (resulting in a hybrid DTP-RDM model).
The chief strengths of the RDM model are: wide support for application development in terms of tools available (most "client/server" products available today utilise the RDM model), and the simplicity of the model. However, the full benefits of client/server distribution are not realised, and the large amounts of data being passed over the network for processing may inhibit the applicability of this model on "bandwidth-challenged" networks.
Most personal computer based Local Area Networks are characterised by using a specialised and dedicated server node to provide file and print sharing services to desktop computers. In essence, each client desktop views the server(s) as a peripheral with multiple file systems (these file systems are called network drives, mapped drives or share names depending on the LAN operating system) and printers contained within it. Examples include AppleTalk, Novell NetWare, Microsoft LAN Manager, Banyan Vines, etc.
Most file sharing services use some kind of RPC mechanism (usually proprietary) or protocol for remote access. For example, Novell Netware uses the NetWare Core Protocol (NCP) which runs on top of IPX/SPX, LAN Manager uses Server Message Blocks (SMB) on top of NetBIOS.
Recently, there has been a trend to extend the functionality of LAN file sharing services from a remote file system model to a distributed file system model. Examples include Novell NetWare 4.0, Microsoft NT Advanced Server, and the growing emergence of peer-to-peer file sharing services (Artisoft LANtastic, Novell Personal NetWare, Microsoft Windows for Workgroups, etc.). There has also been attempts to extend the functionality of LAN operating systems to include remote data management as well as remote file management (i.e. Microsoft SQL Server, Novell NetWare Loadable Modules etc.).
Many database management system vendors support the RDM model through the use of Structured Query Language (SQL) as the client/server interaction protocol, which is relatively easy to implement. An application component deals with a single source of data and sends SQL across a network. Examples include Oracle SQL*Net, Informix-Net, Ingres/Net and the Sybase Open Client/Server. Applications that access these databases tend to be fourth generation languages (4GLs) or forms designing tools, sometimes supplied by the database vendors themselves but also through third parties (e.g. PowerBuilder).
The DDM model is constrasted from the RDM model by the distribution of data over several nodes in a network. The goal is to implement a single logical data store from multiple heterogeneous data sources. Two common ways of implementing a DDM model are by using a distributed file system or a distributed database management system.
The most widely implemented method of distributing data across several machines but maintaining a single logical data store is by using a distributed file system.
Most distributed file systems use some kind of RPC mechanism (usually proprietary) or protocol for remote access. The de facto UNIX distributed file system is Sun's Network File System (NFS), which is defined in terms of a freely-available RPC specification relying on an external data definition protocol called XDR.
Other distributed file systems in the UNIX environment also define their own RPC access mechanisms, for example LOCUS (parts of which is incorporated in IBM AIX and provides remote access at the disk block level), Spritely NFS (which tries to combine the best features of both Sprite and NFS), the Andrew File System or AFS (which has been extended to become OSF/DCE DFS and uses DCE RPC), and RFS (using a "remote system call" interface).
Distributed file systems which are hosted on a distributed operating system tend to use the underlying operating system IPC mechanisms, e.g. Sprite (which uses kernel-to-kernel RPC), Plan 9 (which uses a message passing protocol called 9P), etc.
Some distributed file systems also allow applications to access remote devices and non-file objects (including IPC mechanisms) as part of the distributed file system services, provided these devices and objects can be represented as files in the file system name space. For example, one of the design goals of Plan 9 was to eliminate special case operations by treating nearly all operating system resources as files.
Recently, researchers have begun designing experimental distributed file systems that span across large geographic areas and organisational boundaries. For example, the Prospero File System supports customised views of a global file system consisting of files available from the Internet through NFS, AFS, FTP, plus documents available from WAIS and Gopher.
A database management system is organised around a data model which is ideally independent of any particular application. A distributed database implies that data from more than one site can be accessed within an application. This can be achieved in several different ways:
The application component serially accesses different sources of data in a non-transparent manner, and then presents the illusion of a single database to the user via the presentation component. In order for this to be achieved, the application component must be written in a language that can support accessing multiple databases using different access methods.
Many database independent 4GLs work this way, by providing drivers to popular database engines and flat file record managers.
The application component communicates to a middle translation or gateway layer (usually and appropriately termed "middleware") that isolates the individual access methods and protocols used to communicate to each data source and provides a uniform way to communicate to multiple data sources to the application component.
This is the strategy underlying the efforts by the SQL Access Group of developing a standard Call Level Interface (CLI) for submitting SQL statements to an RDBMS (as well as the ISO Remote Database Access (RDA) protocol for OSI environments), and vendor developed solutions based on the SAG CLI (such as Microsoft ODBC and Borland IDAPI).
The application component accesses a single database which then provides a logical view of multiple data sources by implementing gateways into each data source. Many of the leading database vendors provide gateways to IBM DB/2 and to each other. Examples include Oracle SQL*Connect, Informix-Gateway, Sybase OmniSQL Gateway.
The application component accesses multiple databases using a common access protocol, but views the databases as a single logical database.
When updating data across multiple databases, the two-phase commit protocol is used to ensure the integrity of data.
The major database vendors are beginning to support externalised two-phase commit protocols (such as the X/Open DTP XA interface) and some have also implemented the two-phase protocol internally in a transparent manner.
Distributed databases usually distribute data entities across multiple locations. Distribution of a single data entity (i.e. a relational table) across multiple locations (vertical or horizontal fragmentation) is exceedingly complicated and rarely implemented.
Two phase commit is an expensive operation and is very sensitive to network response time and node availability. Some database vendors are also exploring the alternative of providing mechanisms to replicate data across databases.
Replicated Databases can be implemented in several ways: by the user or application manually extracting data from multiple databases and copying it from location to location; by the database system itself taking snapshot copies of data or subsets of data and automatically or manually refreshing those snapshots at periodic intervals; and by the database system actively creating replicas of data and maintaining data consistency between replicas either synchronously or asynchronously.
It is of course quite possible to design a distributed client/server architecture that combines several models into a hybrid model.
The following is a brief description of an actual enterprise computing architecture based on open systems that incorporates multiple client/server models.
The design of the architecture revolves around the need to provide end users with graphical user interfaces, but at the same time preserve the investment in existing mainframe legacy applications (which are character based). The goal of the architecture was to surround or encapsulate the business logic embedded in these legacy applications within a distributed transaction processing framework. Over time, the business logic can then be migrated across the distributed environment into different hardware and operating system platforms. New applications would be implemented directly within the distributed framework.
The distributed processing environment consists of four logical components:
The personal computers run office productivity applications (including word processors, spreadsheet software, electronic mail, etc.) which are located on the UNIX LAN server, which provided file and print sharing services (using the LAN Manager protocol) to the LAN (an example of the RDM model in action). The LAN server also runs a Relational DataBase Management System (RDBMS) which can be accessed from the personal computers using Microsoft ODBC (another example of the RDM model).
Users execute core business functionality (ultimately processed by a legacy mainframe application) by accessing a Windows application that contained mostly presentation logic (a hybrid RP-DP model). The application and data management logic are distributed and managed by a distributed transaction processor (using the DTP model).
The distributed transaction processor provides the strategic business logic encapsulation: new application functionality will be implemented as transaction processing services using the client/server computing model.
Since each UNIX server runs an RDBMS, the transaction processor also helps in managing data integrity by using the two-phase commit protocol between databases (an example of the DDM model). UNIX servers of course can also share files using NFS (another example of the DDM model).
The UNIX machines acting as gateways into the host applications use a variety of means to do so: via transaction processor gateways (DTP model), database gateways (DDM model), and by emulating user login sessions (RP model).
As can be seen by the above brief description, it is possible to mix and match client/server computing models as well as different standards and technologies to create a viable distributed computing environment based on products available today from multiple vendors.
Chris Tham graduated from the University of Sydney in 1988 with a University Medal and a B.Sc.(Hons 1st. Class) in Computer Science, and again in 1994 from Macquarie University with a Master of Applied Finance. Chris has been involved for a number of years in developing applications on the UNIX operating system for a variety of employers, mainly in the finance industry.
Chris Tham is currently employed as an Architecture Consultant, Professional Services at AT&T Global Information Solutions. Chris specialises in enterprise architecture and planning, and designing overall solutions aimed at meeting the business objectives of AT&T customers.
Chris has had a long relationship with the Oracle product set, including both tools and the database server technology, beginning with Oracle Version 5 on HP-UX in 1987. Chris was an Oracle 6 Database Administrator for two years and have been involved in SQL*Forms development projects. Last year, Chris was the technical liaison between AT&T and Oracle in Australia.
Chris Tham can be contacted at:
AT&T Global Information Solutions
8-20 Napier Street
North Sydney NSW 2060
Phone: +612 964-8451
Fax: +612 964-8340
Internet: Chris.Tham@Australia.NCR.COM