In today's Ethernet era, there are four overlapping client/server paradigms--SQL databases, TP monitors, groupware, and distributed objects. The next big wave is about to catapult them all into the intergalactic client/server era.
Robert Orfali, Dan Harkey, and Jeri Edwards
If you're like most of us, just now comfortable with your Ethernet LAN and local database server, you may not want to hear that the industry is poised for a second client/server revolution. Fasten your seat belts, because this next one will prove to be just as traumatic as the first, which chain-sawed mainframe applications into client and server pieces. Exponential network growth and network-aware multithreaded desktop operating systems augur a transition from Ethernet client/server
to intergalactic client/server, an era in which servers are plentiful instead of scarce (because every client can be a server) and in which proximity no longer matters.
Is the client/server infrastructure ready for intergalactic prime time? Can our NOSes (network operating systems) deal with millions of machines that can be both clients and servers? What kinds of applications will live on the global network? How will these applications be created, deployed, and managed? We'll answer these questions with a sweeping overview of today's operating systems and four dominant client/server models--SQL databases, TP (transaction processing) monitors, groupware, and distributed objects.
New Age Operating Systems
In the Ethernet era, operating systems were clearly segregated along client/server lines. Client operating systems managed the desktop; server operating systems managed shared resources. But the intergalactic era requires new hybrid operating systems that do both jobs well.
The operating system must provide robust 32-bit preemptive multitasking that protects applications from one another. Clients and servers alike need threads to react quickly to events originating on the desktop and in the global network.
Clients will sport an OOUI (object-oriented user interface), which is a "place" for integrating multiple "things" that run concurrently. Things are on-screen objects that resemble their real-world counterparts. Users interact with things directly, and things exchange information by means of drag-and-drop and live links. Technologies such as OpenDoc and OLE 2 further the OOUI paradigm, enabling users to assemble, link, script, store, and transport places and the things that they contain.
The client must also run the thousands of existing desktop applications, including DOS, Windows, OS/2, and Macintosh programs, as well as the thousands of device drivers that users have acquired. It's a daunting task, but that's what it takes to be an integrating client platform
in this new era.
Of course we can't afford to ship a system administrator with every $99 operating system, so we need push-button CD-ROM installation, with dynamic discovery and configuration of resources. To achieve shrink-wrapped client/server plug and play, operating systems will bundle the required middleware. This will include protocol stacks, NOSes, resource binderies, and security features. Some of them may even have production-strength databases, TP monitors, work-flow engines, and ORBs (Object Request Brokers).
To be effective as a server, a new age operating system must be upwardly scalable. It should minimally be able to exploit shared-memory SMP (symmetric multiprocessing) hardware. However, ubiquitous WAN communication also creates the need for massively parallel, "shared-nothing" clustered servers that can service hundreds of thousands of clients and manage tons of data--video on demand, document databases, high-volume transaction processing, and information warehouses.
The New Age NOS
NOSes have always been in the business of hiding the location of resources from applications. But in the intergalactic client/server era, they must become real Houdinis, creating the illusion of a single system image across, potentially, millions of hybrid client/server machines. Here are some of the elements of that illusion:
--
Location transparency.
Users, services, and resources join and leave the network constantly, but they are never tied to fixed locations. In this continual flux, the NOS global directory brings people, programs, and things into conjunction to perform work. The global directory is a distributed, replicated object database. Distribution means that autonomous administrative domains can exist. Replication enhances availability and performance. Object orientation enables the directory to grow organically, like the real-world structures it represents.
--
Namespace transparency
. Everything on the global network m
ust appear to belong to the same namespace. Names must resolve uniquely within a given context or naming authority, but the NOS can grow a tree of federated namespaces, each with autonomous naming authority. You can think of the telephone system's area codes as federated namespaces.
--
Administrative transparency
. The NOS must appear to integrate with the local operating system's management services and provide replication transparency. If a naming directory is shadowed on many machines, for example, it's up to the NOS to synchronize updates. The NOS must also shield users from network failures, transparently handle retries and session reconnects, and synchronize clocks on geographically dispersed machines.
--
Secured-access transparency
. Users have to be able to access any server resource from anywhere, including hotel rooms, offices, homes, and cellular phones, using a single log-on. Security must be built on mutual distrust. Clients must prove to servers that they
are who they claim to be and vice versa by appealing to a trusted third party. MIT's Kerberos, which is the DCE (Distributed Computing Environment) security system, works this way. After authentication, the server applications must use ACLs (access control lists) to regulate clients' access to functions and data.
--
Communications transparency
. Modern NOSes are learning to hide the complexities of multiple protocols and dissimilar data representations behind a set of abstractions for interprocess communication. All offer peer-to-peer conversational interfaces, and most provide some form of RPC (remote procedure call) that makes a server appear to be one function call away. Another model--message queuing, or MOM (message-oriented middleware)--can be incredibly helpful when clients and servers can tolerate communications delay. Current NOSes generally don't come with MOM, but it's available as an add-on.
The Ethernet-era NOSes, including NetWare 3.x, LAN Server, LAN Manager, and Wi
ndows NT Server, were built for LANs with small numbers of servers. It would be suicidal to deploy them in intergalactic environments. However, a new generation of NOSes is on the horizon, and these systems are increasingly capable of the Houdini magic needed for intergalactic environments.
The main contenders are the OSF's (Open Software Foundation) DCE, Novell's NetWare 4.x, and Sun's ONC (Open Network Computing). DCE is a technically superior NOS that meets most of the requirements; it's also the strategic NOS for major intergalactic players, including Digital Equipment, Hewlett-Packard, IBM, Microsoft, and Tandem.
Novell dominates today's client/server environments. However, the transition to NetWare 4.x has so far been a difficult one. ONC, which is entrenched on millions of Unix nodes, influenced the development of the Internet's communications infrastructure.
New Age Client/Server Applications
Everyone's imagining a planetary electronic mall, with virtual bou
tiques, department stores, bookstores, brokerage services, banks, travel agencies, and more. Like a Club Med, the mall will issue its own electronic currency to facilitate round-the-clock shopping and for business-to-business transactions. Electronic agents will roam the network, looking for bargains and negotiating with other agents. Billions of transactions and oceans of multimedia data will flow through the network every day.
Clearly, we're not talking about today's Internet, where users surf hypertext webs of HTML-tagged (Hypertext Markup Language) information. The volume and complexity of transactions, and the richness of the data on which they operate, will create the need for new enabling technologies, including:
--
Rich transaction processing
. We'll need nested transactions that can span servers, transactions that execute over long periods of time as they travel from server to server, queued transactions for secure business-to-business dealings, and "sagas" that can chain
together many pieces of work and selectively undo some of the effects of a transaction. Most nodes on the network should be able to participate in a secured transaction. Superserver nodes will handle the massive transaction loads.
--
Roaming agents
. Consumers will have personal agents that look after their interests. Businesses will deploy agents to sell their wares on the network. Sniffer agents will look for trends and gather statistics. Agent technologies include cross-platform scripting engines, work-flow engines, and an infrastructure that lets agents live on any machine on the network.
--
Rich data management
. From anywhere on the network, we'll create, store, view, and edit compound documents with multimedia content. Most nodes will offer compound document technology (e.g., OLE or OpenDoc) for local document management. Superservers will provide repositories for storing and distributing massive numbers of documents. Of course, we can't forget about structured
data (e.g., SQL databases) either.
The Four Client/Server Application Models
What technology base will be used to create these intergalactic client/server applications? The four competing paradigms are SQL databases, TP monitors, groupware, and distributed objects. Each one of them can create complete client/server applications, each provides tools to do that (some more than others), and each introduces its favorite form of middleware. In the remainder of the article, we'll explain what each contender does well and fearlessly pick a winner.
SQL DATABASES
SQL database servers dominate the client/server landscape today. SQL began as a declarative language for manipulating data using 10 simple commands. But as SQL applications moved to more demanding client/server environments, it became clear that just managing data wasn't enough. There was also a need to manage the functions that manipulated the data. Stored procedures, sometimes called "TP lite," met
the need.
A stored procedure is a named collection of SQL statements and procedural logic that is compiled, verified, and stored in a server database. Sybase pioneered the concept of stored procedures. Now virtually all SQL vendors support stored procedures along with other SQL extensions (e.g., triggers and rules). The extensions are used to enforce data integrity, perform system maintenance, and implement the server side of an application's logic. No two vendor implementations are alike. Note that stored procedures offer minimal transaction support.
Because SQL standards seem to lag vendor implementations by at least five years, almost everything that's interesting in client/server database technology is nonstandard. This includes database administration, data replication, stored procedures, user-defined data types, client APIs, and the formats and protocols on the network. Thus, the best you can do in heterogeneous database environments is to create a loose federation of databases whose leas
t common denominator is typically dynamic SQL.
In defense of SQL, we can say that it is easy to create client/server applications in single-vendor/single-server environments. A wealth of GUI tools makes SQL applications easy to build, and SQL is familiar to millions of programmers and users.
TP MONITORS
You can't create mission-critical applications without managing the programs (or processes) that operate on data. That's why, in the mainframe world, a TP monitor comes with every mission-critical database. TP monitors manage processes and orchestrate programs by breaking complex applications into pieces of code called transactions. The modern client/server incarnations of TP monitors haven't dominated the Ethernet era, but they'll be major players in the intergalactic era. It's not farfetched to assume that every machine on the network will have a TP monitor to represent it in global transactions.
Transactions are more than just business events; they've become an ap
plications design philosophy that guarantees robustness in distributed systems. Under the control of a TP monitor, a transaction can be managed from its point of origin--typically on a client--across one or more servers and back to the originating client. When a transaction ends, all parties involved agree that it either succeeded or failed.
The transaction is the contract that binds the client to one or more servers. It's the fundamental unit of recovery, consistency, and concurrency in a client/server system. Of course, all participating programs must adhere to the transactional discipline; otherwise, a single faulty program can corrupt an entire system. In an ideal world, all client/server programs will be written as transactions.
Transaction models define when a transaction starts, when it ends, and what the appropriate units of recovery are in case of failure. The flat-transaction model has long been the workhorse of the current generation of TP monitors (and other transactional systems). I
n a flat transaction, all work done within a transaction's boundaries occurs at the same level. The transaction starts with a begin_transaction and ends with either a commit_transaction or an abort_transaction. It's all or nothing--there's no way to commit or abort parts of a flat transaction. However, newer transaction models offer finer control of a transaction's threads and can more closely mirror their real-world counterparts.
Most alternatives to the flat transaction extend the flow of control beyond the simple unit of work, either by chaining units of work in linear sequences of minitransactions or via nested subtransactions (see the figure "
Nested Transactions
"). A subtransaction's effects become permanent after it issues a local commit and all its ancestors commit. If a parent transaction aborts, all descendant transactions abort whether or not they issue local commits. The beauty of it is that subtransactions can run on different nodes.
TP monitors were invented to r
un applications that serve thousands of clients. By interjecting themselves between clients and servers, TP monitors can manage transactions, route them across systems, load-balance their execution, and restart them after failures. A TP monitor can manage transactional resources on a single server or across multiple servers, and it can cooperate with other TP monitors in federated arrangements. TP monitors also perform a "great funneling act" that helps the operating system and server resource managers deal with large numbers of clients (see "Scale Up with TP Monitors").
X/Open and the OMG (Object Management Group) have created complementary standards that define how TP monitors interact with applications, resource managers, and other TP monitors in both procedural and distributed-object environments. Some good tools are available to help you create TP-monitor applications.
TP monitors are probably overkill in single-server, single-vendor departmental applications. That's one reason they've been
slow to take off. Moreover, vendors haven't come to grips yet with the realities of the shrink-wrapped software market, and they haven't been able to explain the advantages TP monitors offer. The intergalactic era will make those advantages increasingly self-evident.
GROUPWARE
Groupware comprises five foundation technologies geared to support collaborative work: multimedia document management, work flow, E-mail, conferencing, and scheduling. Groupware isn't another downsized mainframe technology. It's a genuinely new model of client/server computing. It helps users collect unstructured data--including text, images, faxes, mail, and on-line conference proceedings--and organize that data as a set of documents. It further enables users to view those documents, store them, replicate them, and route them anywhere on the network. The multimedia document is to groupware what a table is to a SQL database--the basic unit of management.
Groupware excels in the art of document datab
ase management and makes effective use of E-mail, which is its preferred form of middleware. E-mail is one of the easiest ways for electronic processes to communicate with humans. Asynchronous by nature, it's a good match for the way businesses really work. E-mail is ubiquitous, with over 50 million globally interconnected electronic mailboxes.
To appreciate what makes groupware technology so different, consider Lotus Notes, the premier groupware product in the industry (see "Document Repositories"). The secret of Notes' success is that its whole is much more than the sum of its parts. Like all good groupware, Notes makes effective use of E-mail and can manage document databases in a client/server fashion.
What makes Notes revolutionary, however, is widespread replication of these databases. What happened to locking and data integrity, the watchwords of SQL databases? Notes doesn't care--it was more important to get the information out. Now, that's revolutionary! With release 3, Notes introduced
a level of version control that provides adequate protection for document-oriented applications. But Notes is not recommended if you require concurrency or immediate updates.
Managing business processes by means of work flow is another revolutionary aspect of groupware. In a work flow, data (and sometimes functions) passes from one program to the next in structured or unstructured client/server environments. Modern work-flow software electronically simulates real-world collaborative activity. Work can be routed in ways that correspond to interoffice communications. You can create sequential routes, parallel routes (i.e., alternate paths), routes with feedback loops, circular routes, and more.
A good work-flow package lets you specify acceptance criteria for moving work from one stage to the next. So, work flow brings the information to the people (and programs) who can act on it. It can also coordinate existing software and track processes to make sure the work gets done by the right people.
Groupware provides many of the components we need for creating intergalactic client/server applications. The technology is also starting to encroach on its competitors' turf. For example, Lotus Notes--via DataLens--can access information that's stored in SQL databases; it also gives SQL applications access to Notes data by way of ODBC (Open Database Connectivity).
New tools (e.g., Notes VIP) integrate GUI-building client facilities with data that can be accessed from document or SQL databases. At its best, groupware can flexibly combine different client/server technologies and adapt to the way people do business in both structured and ad hoc settings.
DISTRIBUTED OBJECTS
Distributed-object technology promises the most flexible client/server systems. This is because it encapsulates data and business logic in objects that can roam anywhere on networks, run on different platforms, talk to legacy applications by way of object wrappers, and manage themselves and the resour
ces they control.
When it comes to standards, distributed-object technology is ahead of the other client/server approaches. Since 1989, a consortium of object vendors--called the OMG--has been busily specifying the architecture for an open software bus on which object components written by different vendors can interoperate across networks and operating systems. The OMG currently boasts 440 member companies, and the object bus is well on its way to becoming the mother of all client/server middleware.
The secret to the OMG's success is that it defined how to specify an interface between a component and the object bus--using working technologies as a model--but didn't prescribe how to implement those specifications. Specifications are written in IDL (interface definition language), independent of any programming language. Components specify in IDL the types of services that they provide, including the methods they export and their parameters, attributes, error handlers, and inheritance relationshi
ps with other components.
IDL becomes the contract that binds clients to server components. The beauty of IDL is that it can easily be used to encapsulate existing applications. You don't have to rewrite your entire inventory of applications to take advantage of distributed-object technology.
The object bus provides an ORB that lets clients invoke methods on remote objects either statically or dynamically. If a component interface is already defined, you can bind your program to an IDL-generated stub to call its methods. Otherwise, you can discover how the interface works at run time by consulting an OMG-specified interface repository.
In late 1994, the OMG approved a set of specifications that's called CORBA 2.0 (Common Object Request Broker Architecture), which defines a TCP/IP-based ORB-to-ORB backbone. CORBA 2.0 also specifies an optional inter-ORB communications service based on DCE. The new interface-repository specification defines extensions that let the components generate univer
sal global IDs for their interfaces--using IDL, of course--to ensure that they are unique at the intergalactic level.
In addition to defining the object bus, the OMG has specified an extensive set of ORB-related services for creating and deleting objects, accessing them by name, storing them, externalizing their states, and defining complex relationships among them. In late 1994, the OMG also defined a comprehensive set of services for transactional objects. The idea is that you'll be able to create an ordinary object and make it transactional, lockable, and persistent by having it inherit the appropriate services using simple IDL entries.
The OMG created important alliances to make sure that its standards are universally accepted. The CORBA-defined persistence service is closely aligned with the new ODMG-93 (Object Database Management Group) specifications for object databases. The object-transaction services can interoperate with X/Open-defined procedural transactions. The OMG is also working
with X/Open to help define ORB-based system management interfaces, including security.
In addition, CI Labs--which is the consortium of companies responsible for OpenDoc--picked CORBA as its object model for intercomponent communications. Both Taligent and OpenStep are providing CORBA gateways for their external object communications. Even Microsoft approached the OMG in late 1994 with a proposal for an official OLE-to-CORBA gateway.
It looks like the object community may be well on the way to building an object infrastructure that can meet the demands of the intergalactic client/server era. Distributed objects with the proper component packaging and infrastructure may provide the ultimate building blocks for creating client/server solutions, including suites of cooperating business objects.
In all honesty, though, the current generation of CORBA 1.2-compliant ORBs is not ready for intergalactic prime time. We believe that CORBA 2.0 and the new object services--including transactions, loc
king, life cycle, naming, and persistence--must be implemented in commercial ORBs before the technology can take off. The good news is that in this case, unlike the SQL world, the standards lead rather than lag the commercial offerings.
Once distributed-object technology takes off, it can subsume all other forms of client/server computing, including TP monitors, SQL databases, and groupware. Distributed objects can do it all and do it better. Objects can help us break large monolithic applications into more manageable components that coexist on the intergalactic bus. They are also our only hope for managing the millions of software entities that will live on intergalactic networks.
As shown in the figure "
Three Waves of Client/Server Computing
," the Ethernet era of client/server saw a file-centered applications wave followed by a database-centered wave. TP monitors and groupware generated minor ripples. Distributed objects are the next big wave, and we believe they're the onl
y way to make the intergalactic client/server vision real. Are you ready to catch the wave?
illustration_link (11 Kbytes)
Nested transactions can capture the true complexity of real-world business processes while distributing the transaction load across many server nodes.
illustration_link (7 Kbytes)
In the Ethernet client/server era, which is still very much in progress, SQL databases, TP (transaction processing) monitors, and groupware have begun to displace file servers. But the intergalactic client/server era, with its distributed-object infrastructure, is fast approaching.
Robert Orfali, Dan Harkey, and Jeri Edwards are the authors of Esse
ntial Client/Server Survival Guide (Van Nostrand Reinhold, 1994). Edwards is the director of transaction processing and client/server software development at Tandem Computers. Orfali and Harkey work on the application of distributed-object technology at IBM; they have worked on applied client/server technology for the last eight years. You can reach them on BIX c/o "editors."
Intergalactic Client/Server Computing
