Middleware: a Model for Distributed System Services

Various types of middleware are classified,

their properties described, and their evo-

lution explained, providing a conceptual

model for understanding today’s and

tomorrow’s distributed system software. Middle

he computing facilities of large- control. Some servers are gateways to services offered scale enterprises are evolving into outside the enterprise, such as travel or information a utility, much like power and retrieval services, news feeds (e.g., weather, stock telecommunications. In the prices), and electronic document interchange with vision of an information utility, business partners. In response to such connectivity, each knowledge worker has a some businesses are redefining their business desktop appliance that connects processes to use the utility to bridge formerly isolated to the utility. The desktop appli- component activities. In the long term, the utility ance is a computer or computer-like device, such as a should provide the information that people need Tterminal, personal computer, workstation, word when, where, and how they need it. processor, or stock trader’s station. The utility itself is Today’s enterprise computing facilities are only an an enterprise-wide network of information services, approximation of the vision of an information utility. including applications and databases, on the local- Most organizations have a wide variety of heteroge- area and wide-area networks. neous hardware systems, including personal comput- Servers on the local-area network (LAN) typically ers, workstations, minicomputers, and mainframes. support files and file-based applications, such as elec- These systems run different operating systems (OSs) tronic mail, bulletin boards, document preparation, and rely on different network architectures. As a and printing. Local-area servers also support a direc- result, integration is difficult and its achievement tory service, to help a desktop user find other users uneven. For example, local-area servers are often and find and connect to services of interest. Servers isolated from the WAN. An appliance can access files on the wide-area network (WAN) typically support and printers on its local server, but often not those on access to databases, such as corporate directories and the servers of other LANs. Sometimes an application electronic libraries, or transaction processing appli- available on one local area server is not available on cations, such as purchasing, billing, and inventory other servers, because other departments use servers

Philip A. Bernstein

86 February 1996/Vol. 39, No. 2 COMMUNICATIONS OF THE ACM Middle ware eware: A Model for Distributed System Services

COMMUNICATIONS OF THE ACM February 1996/Vol. 39, No. 2 87 on which the application cannot run. So some appli- meters into a packet, and a server stub, which unmar- ances cannot access the application. Wide-area shals the packet into a local server call (see Figure 1). servers often can support only dumb terminals, which The client stub can marshal parameters from a lan- a desktop appliance must emulate to access a server. guage and machine representation different from Sometimes a desktop appliance can gain access to a the server stub’s, thereby enabling interoperation. An wide-area server only if a local-area server was explic- RPC implementation also includes a run-time library, itly programmed for access to the wide-area server. A which implements the protocol for message user may have to log into each server separately with exchanges on a variety of network transports, independently maintained passwords and through enabling interoperation at that level. At least one ven- different user interfaces, each with a different look dor (Microsoft) has implemented the protocol inde- and feel. Even if the desktop appliance can access a pendently (without using the OSF implementation) remote application, its spreadsheet or word processor yet can interoperate with other implementations. often cannot access data provided by that application As another example, many vendors have imple- without special programming. These are only some mented IBM’s 3270 protocol to interoperate with of the limitations of such systems. IBM mainframe applications. These vendors often In response to their frustrations in implementing support a programming interface different from what enterprise-wide information systems, large enterpris- IBM offers on its systems. But since they support the es are pressuring their vendors to help them solve same protocol, the systems can interoperate. heterogeneity and distribution problems. One way is To help solve customers’ heterogeneity and distri- by supporting standard programming interfaces. bution problems, and thereby enable the implemen- Standard programming interfaces make it easier to tation of an information utility, vendors are offering port applications to a variety of server types, giving distributed system services that have standard pro- the customer some independence from the vendors. gramming interfaces and protocols. These services In the past, supporting a standard programming lan- are called middleware services, because they sit “in the guage, such as Cobol or C, was enough, but not any- middle,’’ in a layer above the OS and networking soft- more. Today’s typical application may use database, ware and below industry-specific applications. communication, presentation, and other services, Like large enterprises, application developers also whose interfaces are not part of the language defini- have heterogeneity and distribution problems they tion. To port an application, these interfaces must be want vendors to solve. Developers want their applica- supported on the target platform. So users want inter- tions to depend only on standard programming interfaces that are widely supported, that is, standard. faces, so the applications will run on most popular Increasingly, standard interfaces are important to systems. This increases their potential market and helps server vendors themselves. Customers buy applica- their large-enterprise customers who must run applications, not servers. Customers will choose any server tions on different types of systems. Developers need that can run the applications they want. By support- higher-level interfaces, which mask the complexity of ing many standard interfaces, a vendor increases the networks and protocols and thereby allow developers to number of applications that run on their servers, focus on application-specific issues, where they are making their servers more attractive to customers. most qualified to add value. Since customers focus on buying applications, not the underlying computer sys- nother way vendors solve het- tems, vendors are anxious to meet these requirements erogeneity problems is by sup- so they can attract popular applications to their systems. porting standard protocols. As with large enterprises, vendors respond to applica- Standard protocols enable pro- tion developers by offering middleware. grams to interoperate. By inter- For many new applications, middleware compo- operate, we mean that a program nents are becoming more important than the underly- on one system can access pro- ing OS and networking services on which the grams and data on another sys- applications formerly depended. For example, new tem. Interoperation is possible only if the two systems applications often depend on a relational database sys- useA the same protocol, that is, the same message for- tem rather than on the OS’s record-oriented file system mats and sequences. Also, the applications running and on an RPC mechanism rather than on transport- on the systems must have similar semantics, so the level messaging (e.g., send-message, receive-message). messages map to operations that the applications In general, middleware is replacing the nondistributed understand. The systems supporting the protocol functions of OSs with distributed functions that use the may use different machine architectures and OSs, yet network (e.g., distributed database, remote file access, they can still interoperate. RPC). For many applications, the programming inter- For example, the Open Software Foundation’s Dis- face provided by middleware defines the application’s tributed Computing Environment (OSF DCE) fully computing environment. For example, many applica- specifies its remote procedure call (RPC) protocol. tions regard fourth-generation languages (4GLs), An implementation of DCE RPC includes a compiler transaction processing (TP) monitors (e.g., IBM’s that translates an interface definition into a client CICS, Digital’s ACMSxp), and office frameworks (e.g., stub, which marshals a procedure call and its para- Lotus Notes, Digital’s LinkWorks) in this way.

88 February 1996/Vol. 39, No. 2 COMMUNICATIONS OF THE ACM Middle ware

IDL Development { Environment IDL source

Application client IDL compiler Application server procedure procedure

Language-specific Interface Language-specific call interface header call interface Client stubs Server stubs

RPC API RPC API RPC run-time RPC protocols RPC run-time service library service library

DCE directory services

DCE security services

Legacy applications, built before portable middle- describes their proper- ware became popular, can also benefit from middle- ties, and explains their Figure 1. Remote ware services. One can encapsulate the legacy evolution. The goal is to Procedure Call application as a set of functions and use communica- provide a conceptual architecture tions middleware services to provide remote access to model for understanding those functions. For example, one can use an imple- today’s and tomorrow’s mentation of the Object Management Group’s distributed system soft- (OMG’s) Common Object Request Broker Architec- ware. Regrettably, there Figure 2. ture (CORBA) for this purpose. This includes an is no standard terminolo- Middleware object-oriented aplication programming interface gy for many of the con- (API) for binding to remote applications (objects) cepts discussed here. We and for invoking them, through either a static inter- have attempted to follow common industry usage of face (like RPC stubs) or a dynamic interface (of the terms and to add some precision to the definitions. form Call(application-name, parameter1, parame- However, vendors and consortia use these terms in ter2, ...)). One can also provide an advanced user conflicting ways. We therefore warn the reader to be interface to a legacy application through high-level careful in interpreting these terms outside the con- presentation middleware services, for example, by text of this article. intercepting character terminal I/O and translating it into operations on a graphical user interface Middleware Services (GUI). Or one can replace some internal compo- We describe properties of middleware and the prob- nents of the legacy application with middleware ser- lems they do and don’t solve. See also [4]. vices. For example, one can replace A middleware service is a general-purpose service that application-specific database sits between platforms and functions with middleware applications (see Figure 2). By database services. This saves Application. . . Application platform, we mean a set of low- maintenance by relying more level services and processing on the middleware vendor, elements defined by a proces- which often improves func- APIs sor architecture and an OS’s tionality, since the middleware API, such as Intel x86 and Win- Middleware vendor has greater resources (distributed system services) 32, Sun SPARCstation and Sun to expend on these distributed OS, IBM RS/6000 and AIX, system functions than the Alpha AXP and OpenVMS, and application developer does. Platform interface Platform interface Alpha AXP and Windows NT. This article classifies differ- Platform Platform A middleware service is ent kinds of middleware, • OS . . . • OS defined by the APIs and pro- • Hardware • Hardware

February 1996/Vol. 39, No. 2 89 A middleware service meets the needs of a wide variety of applications across many industries. tocols it supports. It may have multiple implementa- will interoperate. However, if a middleware service tions that conform to its interface and protocol spec- really does run on all popular platforms, it may be ifications, such as the different implementations of regarded as standard even though its protocols are DCE RPC and IBM 3270 protocol mentioned earlier. not published. For example, most database system Like many high-level system concepts, middleware products have this property. If platform coverage is is hard to define in a technically precise way. However, good enough, customers may not push vendors to middleware components have several properties that, conform to a standard protocol when it is developed. taken together, usually make clear that the component For example, the SQL Access Group’s client-server is not an application or platform-specific service: They protocol has not gained much acceptance, although are generic across applications and industries, they run its API (ODBC) is quite successful, since it is support- on multiple platforms, they are distributed, and they ed by Microsoft on its Windows operating systems. support standard interfaces and protocols. We A middleware service should support a standard describe each of these properties in turn. API. A middleware service is transparent with respect A middleware service meets the needs of a wide to an API if it can be accessed via that API without variety of applications across many industries. For modifying that API. Nontransparent middleware example, a message switch, which translates messages requires a new API. Middleware that is transparent between different formats, is considered middleware with respect to a standard API is more easily accept- if it makes it easy to add new formats and is usable by ed by the market, because applications that use the many applications. If it deals with formats only for a existing API can use the new service without modifi- single industry (e.g., trading securities) and is embed- cation. For example, several different distributed ded in a single application (e.g., a back-office broker- file-sharing protocols have been implemented under age system), then it is not middleware. the standard file access API, as in Digital’s PATH- A middleware service must have implementations WORKS product, which includes file services for per- that run on multiple platforms. Otherwise, it is a plat- sonal computers. form service. For example, relational database man- If a vendor has broad platform coverage and sub- agement systems (DBMSs) are middleware. Many stantial market share, then its API and protocol may relational database products run on multiple plat- be regarded as de facto standards, even if they are not forms. By contrast, byte-stream file systems are plat- supported by other vendors. For example, the rela- form services. Each OS has its own implementation, tional database systems ORACLE and SYBASE sup- usually with an OS-specific interface. By running on port their own dialects of the SQL language yet are multiple platforms, a middleware service enhances regarded as standard enough by most customers. the platform coverage of applications that depend on Similarly, IBM’s CICS TP monitor uses a proprietary it. If the service is distributed, this also enhances API and protocol (LU6.2) yet is a de facto standard. interoperability, since applications on different plat- Whether a given service is classified as middle- forms can use the service to communicate and/or ware may change over time. A facility that is cur- exchange data. To have good platform coverage, rently regarded as part of a platform may, in the middleware services are usually programmed to be future, become middleware, to simplify the OS portable, meaning that they can be ported to another implementation and make the service generally platform with modest and predictable effort. available for all platforms. For example, we used to A middleware service is distributed. That is, it regard a record-oriented file system as a standard either can be accessed remotely (e.g., a database or part of OSs, as indeed they were in all commercial presentation service) or enables other services and OSs developed before 1980. However, today we applications to be accessed remotely (e.g., a commu- often think of this as middleware, such as imple- nications service). A remotely accessible middleware mentations that conform to the X/Open C-ISAM service usually includes a client part, which supports API. Conversely, middleware can migrate into the the service’s API running in the application’s address platform, to improve the middleware’s performance space, and a server part, which supports the service’s and to increase the commercial value of the plat- main functions and may run in a different address form. For example, interfaces to transport-level pro- space (i.e., on a different system). There may be mul- tocols were often regarded as “communications tiple implementations of each part. access method’’ products, separate from the OS. Ideally, a middleware service supports a standard Now they are usually bundled with the OS. protocol (e.g., TCP/IP or the ISO OSI protocol Due to the importance of standard interfaces for suite), or at least a published one (e.g., IBM’s SNA application portability and standard protocols for LU6.2). That way, multiple implementations of the interoperability, middleware has been the subject of service can be developed and those implementations many standardization efforts, some through formal

90 February 1996/Vol. 39, No. 2 COMMUNICATIONS OF THE ACM Middle ware standards bodies such as ISO and ANSI, some abstraction worthwhile. through industry consortia such as X/Open, OSF, The categories listed here are arbitrary. They are and OMG, and some through the sponsorship of a just a convenient way of grouping the services, mak- company with a major market share, such as ing them easier to remember and discuss. Microsoft’s Windows Open Services Architecture The main purpose of middleware services is to (WOSA). (The existence of these industry-wide orga- help solve many of the problems discussed earlier in nizations and their growing impact on products is this article. They provide platform-independent APIs, itself a testimonial to the importance of middleware.) so applications will run on multiple platforms. And Sometimes an individual service gathers a major mar- they include high-level services that mask much of ket share and thereby becomes a de facto standard, the complexity of networks and distributed systems. such as Adobe’s PostScript, IBM’s CICS TP monitor, They also factor out commonly used functions into and Sun’s Network File Service (NFS). independent components, so they can be shared Standardization efforts are, in turn, leading to cor- across platforms and software environments. porate procurement standards. That is, companies However, middleware services are not a panacea. and governments are selecting some standards as ven- First, there is a gap between principles and practice. dor requirements, to ensure that similar products Many popular middleware services use proprietary APIs obtained from different vendors will support the (usually making applications dependent on a single same applications and will interoperate. Some exam- vendor’s product) and proprietary and unpublished ples of customer-oriented procurement standards are protocols (making it difficult for different vendors to the U.S. government’s Government Open System build interoperable implementations). For example, as Interconnect Profile (GOSIP) and Nippon Tele- mentioned earlier, many relational DBMSs support graph and Telephone’s Multivendor Integration proprietary SQL dialects and proprietary protocols. Architecture (MIA), which has led to the broader Some are not available on many popular platforms SPIRIT Consortium, covering telecommunications (limiting the customer’s ability to connect or port to and perhaps other industries. heterogeneous systems), such as Oracle’s (formerly Vendors often respond to standards by adding Digital’s) Rdb and IBM’s DB2 relational DBMSs. Even advanced nonstandard features, in an attempt to pro- when a middleware service is state-of-the-art, an appli- duce more desirable products and lock in customers cation developer that depends on it has a new risk to to features that are not available from competing manage, the risk that the service will not keep pace with standard products. For example, relational database technology. For example, many applications that used vendors have been adding features to SQL for many a network (e.g., CODASYL) DBMS had to be rewritten years, with the standards processes struggling to keep to benefit from relational DBMSs that have replaced up by defining vendor-independent standard defini- them as the de facto standard. tions for those features. The following components are or could be mid- econd, the sheer number of middle- dleware services: ware services is a barrier to using them. Even a small number of middleware • Presentation management: Forms manager, graphics services can lead to much program- manager, hypermedia linker, and printing manager. ming complexity, when one considers • Computation: Sorting, math services, international- each service’s full API, including not ization services (for character and string manipula- only service calls but also language tion), data converters, and time services. bindings, system management inter- • Information management: Directory server, log man- faces, and data definition facilities. To keep their com- ager, file manager, record manager, relational Sputing environment manageably simple, developers database system, object-oriented database system, have to select a small number of services that meet repository manager. their needs for functionality and platform coverage. • Communications: Peer-to-peer messaging, remote Third, while middleware services raise the level of procedure call, message queuing, electronic mail, abstraction of programming distributed applications, electronic data interchange. they still leave the application developer with hard • Control: Thread manager, transaction manager, design choices. For example, the developer must still resource broker, fine-grained request scheduler, decide what functionality to put on the client and coarse-grained job scheduler. server sides of a distributed application. It is usually • System management: Event notification service, beneficial to put presentation services on the client accounting service, configuration manager, soft- side, close to the display, and data services on the ware installation manager, fault detector, recovery server side, close to the database. But this isn’t always coordinator, authentication service, auditing ser- ideal, and in any case leaves open the question of vice, encryption service, access controller. where to put other application functions.

Not all of these services are currently distributed, Frameworks portable, and standard. But a sufficiently large num- A framework is a software environment that is designed ber of them are or will be to make the middleware to simplify application development and system man-

COMMUNICATIONS OF THE ACM February 1996/Vol. 39, No. 2 91 agement for a specialized application domain (see Fig- with a common syntax. More often, it adds value by ure 3). A framework is defined by an API, a user inter- specializing the user interface, simplifying the API by face, and a set of tools. It may also have maintaining shared context, or adding framework- framework-private middleware services, in addition to private middleware services. For example, all TP ones that it imports from other products. Some popu- monitors we know of add value in this way. lar types of frameworks include office system environ- Sometimes services grow up into frameworks. For ments (e.g., Lotus Notes, Microsoft Office, Digital’s example, most relational DBMSs have evolved to LinkWorks), TP monitors (e.g., IBM’s CICS, Digital’s include rich toolsets accessible through a special user ACMSxp, Novell’s Tuxedo, Transarc’s Encina), 4GLs interface, retaining SQL as the API. Sometimes a set of (e.g., Uniface, Cognos, and Focus), computer-aided services is sufficiently integrated to resemble a frame- design frameworks (e.g., Mentor Graphics’ Falcon, work. For example, OSF’s DCE integrates RPC, a nam- Digital’s Powerframe), computer-aided software engi- ing service, an authentication service, a time service, a neering workbenches (e.g., HP’s SoftBench, Texas unique universal identifier service, and a file service. Instruments’ Composer by IEF, Andersen Consulting’s Although it has no special user interface (UI), and its Foundation, Digital’s COHESIONworX), and system API is just those of its component services, it does main- management workbenches (e.g., HP’s OpenView, tain context across calls (authenticated user id) and Tivoli’s Management Environment, IBM’s NetView). transparently invokes services to simplify certain opera- Frameworks are a kind of middleware. For clarity, tions, such as transparently invoking the name service we therefore use the term “middleware services’’ for to find a server that can process an RPC call. underlying distributed system services and “middle- Since a framework layers on middleware services, ware’’ for middleware services and/or frameworks. a framework provider is a customer of middleware A framework’s API may be a profile of APIs for a set services. By the same token, an application that lay- of middleware services, or it may be a new API that ers on a framework is the framework’s customer, and only indirectly the middleware service’s customer. Given the wide variety and com- Framework plexity of middleware services, a substantial Application Tool and growing fraction of applications depend on frameworks to simplify their API veneer User underlying middleware environment rather interface Mapping to Framework than directly accessing middleware services. Middleware Services Private Service This is analogous to the past trend of applications to move away from direct use of plat- Application . . . form services and rely more heavily on more abstract middleware services. APIs A framework may have its own UI, which is a specialization of the GUIs of the underlying Middleware platforms it runs on and which has a special (distributed system services) look and feel. For example, an office system framework may specialize the GUI to provide the appearance of a desktop, with icons and lay- out suitable for office users and applications. If Platform interface Platform interface a framework supports multiple GUIs (such as Platform Platform Motif, Microsoft Windows, and Macintosh), • OS . . . • OS • Hardware • Hardware then this GUI specialization makes it easier for users to move between GUIs (e.g., between their Windows laptop and Unix workstation). One way a framework can simplify its API is simplifies the APIs of by maintaining context across calls to different ser- Figure 3. Frame- underlying middleware services. For example, in most frameworks, service calls work architecture vices that it abstracts. For require a user identifier (for access control) and a example, a computer-aided device identifier (for communications binding) as design (CAD) or computer- parameters. However, the framework can maintain aided software engineering (CASE) framework’s API these identifiers as context for the application and may include a presentation service, an invocation not require them as parameters, thereby simplifying service (to call tools from the user interface), and a the API. For example, the CASE framework COHE- repository service (to store persistent data shared SIONworX maintains a context containing an between tools); it could be simply the union of those authenticated user name, a display name, and a work services’ APIs, or it could be abstracted by a new API area consisting of file directories and pointers to that maps to those services. If a framework’s API is objects. Maintaining context is not a unique property different from that of the underlying services, it may of frameworks; a service can maintain context too, be only a veneer that covers the underlying services though that context is usually local to the one service.

92 February 1996/Vol. 39, No. 2 COMMUNICATIONS OF THE ACM Middle ware

For example, DCE RPC maintains an authenticated shared by many tools, tools may share online access to user id across multiple RPC calls. the fine-grained data (as in the previous examples of A framework can also simplify its API by exploiting database catalog, CASE framework repository, and a work model that does not require all of the features 4GL dictionary), or they may transfer the data in bulk of the middleware services it uses. For example, a from tool to tool (for example, using the CASE Data CASE environment may offer a simplified interface Interchange Format between CASE tools or the for software configuration management that does not Express exchange format between CAD tools). If the expose all of the features of the underlying reposito- data is accessed online, then the tools may have to ry manager. This improves ease of use and increases agree on protocol, that is, on the set of operations the number of services that are transparent with allowed on the data and the allowed sequences of respect to the APIs. those operations. Often, a framework offers a middleware service In control integration, a user or tool operating that is private to the framework, usually because the within a framework can invoke another tool, and the framework requires the service but no standard mid- called tool can exchange data and control signals dleware service is available. For example, many TP appropriately with its caller. This involves making the monitors use a private implementation of RPC. How- tool’s interface known to the framework, invoking ever, with the availability of the OSF DCE, which the tool (or creating an instance of the tool, if neces- includes an RPC, some of these TP monitors are sary), and exchanging messages with the tool. For replacing their proprietary RPC implementations example, in Digital’s COHESIONworX, HP’s Soft- with the standard DCE RPC middleware, such as Bench, and Sun’s SPARCworks, each tool in the IBM’s CICS/6000, Transarc’s Encina, and Digital’s CASE framework can send messages, which are for- ACMSxp. As another example, CASE and CAD warded to all other tools that have declared an inter- frameworks often offer framework-specific services est in messages of that type. Sometimes it’s useful if for versioning and configuration management. the tool executes on a different system from the one These services may be replaced in the future by stan- that the framework is executing, in which case con- dard middleware if a repository technology emerges trol integration requires a remote invocation service. as such a standard. For example, Digital’s COHESIONworX uses a Frameworks usually include tools, which are gener- CORBA implementation (Digital’s Object Broker) to ic applications that make the framework easier to use. invoke tools on remote systems. Tools may be designed for end users, programmers, or system managers. They may be provided by the n presentation integration, a tool shares framework’s vendor or other parties. They may be the display with other tools executing in designed to be used with a particular framework or the framework. Preferably, it has the same with a variety of frameworks. Examples of tools look and feel as those other tools, usually include editors, help facilities, forms managers, com- achieved by using the same GUI and pilers, script interpreters, debuggers, performance adopting standard usage conventions, monitors, and software installation managers. such as offering semantics similar to those Although in principle a framework does not need to of abstract operations (e.g., cut, paste, have tools, in practice they all do, to make them suf- drag, drop). The look and feel may be guided by a ficiently attractive to human users. Imetaphor, such as a virtual desktop, which leads to A tool is part of a framework if it is integrated usage conventions for screen space, control panel lay- through data, control, and/or presentation. In data out, etc. Sometimes presentation integration drives integration, a tool shares (usually persistent) data the requirements for data and control integration. with other tools that are part of its framework. This For example, if a spreadsheet is invoked from a com- requires that the tools agree on the object model (the pound document editor, both data integration (of abstract model in which data formats are defined) the spreadsheet’s contents) and control integration and on the format of the shared data. Sometimes the (for launching the spreadsheet application) are format is defined by one tool that owns and exports needed, but it was the presentation integration that the data; other tools can reference that data provided even allowed the user to express the concept. they can cope with the owning tool’s format, such as Pragmatically, presentation and control integra- a relational database catalog. Other times the data is tion are usually more urgently needed than data inte- equally shared by two or more tools, which is easiest gration, because most users need multiple tools and to arrange if all tools are supported by one vendor. do not want to deal with tool-specific look and feel For example, CASE frameworks often contain a and invocation techniques. While there are often repository that is shared by tools for analysis and great benefits to data integration, tools are still useful design and for program generation, such as Ander- and easy to use without this integration. sen Consulting’s Foundation and Texas Instruments’ Presentation and control integration are often easi- Composer by IEF. Similarly, a 4GL typically has a data er to implement than data integration. For control dictionary that is shared by its forms manager, query integration, each tool can be independently integrated language, and application programming language. by defining its interfaces and providing access to those Whether the data is owned by one tool or equally interfaces through a middleware communications ser-

COMMUNICATIONS OF THE ACM February 1996/Vol. 39, No. 2 93 vice. This work is localized at the tool’s interface and manager can tell the transaction manager when it is requires no modification of the body of the tool. The accessed by a transaction and the transaction manag- same is true for presentation integration, by intercept- er can tell resource managers when the transaction ing display I/O operations and translating them into has committed or aborted. A transaction manager operations on a common GUI. By contrast, data inte- implements the two-phase commit protocol, to gration requires that all tool vendors agree on a com- ensure that all or none of the resource managers mon format for the data they share. Since data accesses accessed by a transaction commit (see [2], chap. 7). are scattered throughout the tool’s implementation, Transactional interprogram communications sup- changing data formats is often tedious and expensive. port the propagation of a transaction’s context when One can localize the tool changes by creating a data- one program calls another. This allows the called pro- base view of shared data that allows the tool to access gram to access resources on behalf of the same trans- shared data in its native format. However, the shared action as the caller. The communications paradigm data is often stored in a data manager that doesn’t sup- may be peer-to-peer (i.e., send-message, receive-mes- port views or supports views that are not updatable, sage) or RPC (i.e., send-request, receive-reply). making the views approach nonviable. A queue manager is a resource manager that sup- The distinctions among data, presentation, and ports (usually) persistent storage of data to move control integration are blurred somewhat by taking an between transactions. Its basic operations are object-oriented view of the interfaces a tool calls. In all enqueue and dequeue. A distributed queue manager cases, the tool is invoking methods on objects, so the can be invoked remotely and may provide system distinctions among calling a presentation interface, management operations to forward elements from invoking a tool, and accessing data disappear. Howev- one queue to another. er, the different effects of the three types of integration A forms manager supports operations to send and on user capabilities remain, as does the critical techni- receive forms to and from display devices. It has a cal problem of data integration. That is, the tools that development system for defining forms and translating share data must agree on the format of each data type them into an internal format and a run-time system for they share, which is equally difficult whether it is man- interpreting the content of a form in an application. ifested in a method name or in method parameters. Early TP monitors implemented all of these functions as framework-specific services, relying only on TP Monitors—An Example platform services. Today, many of these framework- To illustrate middleware concepts, we will look at one specific services are available as off-the-shelf middle- type of framework: TP monitors [1]. The main function ware. TP monitors being built today make use of such of a TP monitor is to coordinate the flow of requests off-the-shelf services, such as record managers, trans- between terminals or other devices and application pro- action managers, and queue managers. These ser- grams that can process these requests. A request is a mes- vices may also be used directly by applications or by sage that asks the system to execute a transaction. The other middleware services (e.g., a DBMS) or frame- application that executes the transaction usually access- works (e.g., an office system framework). es resource managers, such as database and communi- All of the preceding services are the subject of cations systems. A typical TP monitor includes functions efforts to standardize their APIs and protocols. For for transaction management, transactional interpro- example, X/Open is working on standard APIs for gram communications, queuing, and forms and menu transaction management and transactional commu- management (see Figure 4). nication, and ISO is working on a protocol standard Transaction management involves support for for queuing. operations that start, commit, and abort a transac- Most TP monitors were highly dependent on the tion. It also has interfaces platform for which they were built. Today’s monitors, to resource managers layered on middleware services, are more portable. Figure 4. TP moni- (e.g., database systems) They are designed to be dependent mostly on the tor architecture that are accessed by a middleware they use, not on the platform that sits transaction, so a resource below the middleware. They have selected middle-

TP Monitor API Mapping TP Monitor API to Middleware APIs TP Monitor Context = Framework {user-id, transaction-id device id, last msg}

Forms and Transactions menus RPC Middleware Services SQL DB Indexed files Queuing

94 February 1996/Vol. 39, No. 2 COMMUNICATIONS OF THE ACM Middle ware

Server Desk View Server Chronos Design Report Editor Install Application

User Spell Mailer interface Catalog Replicator Event Router Import/Export Lotus Notes API

Document Object Store Security Indexing Messaging Events Management Management

Network Logging Naming Add-in Installation Administration Middleware Services

Memory Management File Management Process Management

Platform Isolation Environment Statistics Primitive Data Types Services

ware services that are themselves portable and have an example of control and been ported to many platforms, such as OSF DCE. presentation integration. Figure 5. Therefore, such TP monitors can be ported to a vari- A TP monitor also Architecture of ety of platforms. For example, IBM has built a new incorporates tools for sys- Lotus Notes R3.0 implementation of its CICS TP monitor layered on tem management. These transaction middleware from Transarc Corp. and has tools allow one to display announced that the implementation will be ported to the state of a transaction or request, to determine non-IBM Unix systems. what components are currently unavailable, and to A TP monitor integrates the services so they are monitor performance and tune performance para- accessible via a simplified and uniform API. One way meters. System management may be implemented in it simplifies the API is by maintaining context to avoid its own framework, which ties together the system passing certain parameters. For example, a TP moni- management facilities of the TP monitor with the tor typically maintains context about the current platform’s and database system’s system management request, transaction, and user. Most application func- functions, so all resources can be managed in the tions need not specify this information. Rather, the same way from the same device. TP monitor fills in the necessary parameters when Most customers buy a complete TP system from translating an application call into a call on the one system vendor, including the TP monitor, data- underlying middleware service. For example, an base system, and platform. The system vendor may or application may ask to enqueue a message, and the may not be the author of the TP monitor software. TP monitor would add as parameters the current Still, the system vendor is responsible for ensuring transaction identifier (so the queue manager can tell that the complete software complement has suitable the transaction manager it was accessed by the trans- performance, reliability, usability, etc. action) and user identifier (so the queue manager can check the user’s authorization). Lotus Notes A TP monitor may specialize the user interface. For Another popular framework product that illustrates example, it may have a stylized interface for login, dis- our points is Lotus Notes. It supports the development play of errors, and display and interaction with menus. and execution of applications that create, access, A TP monitor generally incorporates tools for appli- track, share, and organize information represented as cation programming. For example, it may include a documents. We describe some of the key features of data dictionary for sharing record definitions between Lotus Notes in terms of our middleware model. the forms manager, application programs, and data- Applications are stored in databases on servers base system. Digital used its Common Data Dictio- across networks of occasionally connected comput- nary/Repository to integrate its TP Monitor (ACMS), ers. Each database contains documents, forms (which relational DBMS (Rdb), forms manager (DECforms), define the design of multimedia documents), and and compilers in this way. This is an example of data views (which provide, for example, different subsets integration. It also may include a CASE framework for and orders of documents in databases). The majority simplifying the invocation and use of tools for compila- of application development can be done by nonpro- tion, software configuration management, and testing, grammers using forms, views, and a formula language as in Digital’s DECadmire and TP Workcenter. This is similar to those in spreadsheets. The databases are

COMMUNICATIONS OF THE ACM February 1996/Vol. 39, No. 2 95 managed with little centralized control. That is, each ment), installation (of a complete “Lotus Notes Lotus Notes server (i.e., an installation of Lotus Notes server”), and administration (which supports man- on one system) independently defines its databases. agement control from a remote console). Middleware services are provided to track and control these independent but related databases. Some traditional middleware functions are per- Lotus Notes R3.0 is structured in three layers: a plat- formed by independent server processes, which one form isolation layer, a set of middleware services could classify as either tools or services, such as: accessed through an integrated API, and a set of tools (see Figure 5). The platform isolation layer is a set of • Replicator—The naming system defines connec- services for memory, file, process, and environment tions between two servers and defines schedules for management. To enable portability of higher layers, reconciling their common databases. For each these services have the same semantics across various inter-server connection, the replicator copies new versions of many platforms, such as Microsoft Windows, and updated entries in each database to the corre- Apple Macintosh, IBM OS/2, Novell Netware, and sev- sponding database(s) on the other server. In the eral variants of Unix. Data type functions are provided event of a conflict (e.g., independent updates to the to encapsulate the behavior of primitive data types. same object in both servers), it arbitrates by select- Functions are also available to manage different ing a “winner” entry and flagging the likely loser. platform representations and enable binary compati- • Catalog—The catalog produces a global directory bility of applications, databases, and network mes- of all databases in a Notes network. It is a discov- sages. Though not strictly a part of the platform ery process that updates a special catalog data- isolation layer, there is a network component that base with information about local databases. insulates higher layers from network architectures Replication among the catalog replicas results in and differences in transport-level messaging and a a global directory. platform-independent UI that insulates higher layers • Router—The router transfers mail messages from differences in GUIs and window managers. Iso- between servers. lating a framework or middleware service from a plat- • Design—Databases are self-describing, in that they form using such services is common practice. For contain definitions of all application components as example, most portable database systems and well as the data. Some databases, called templates, portable TP monitors are built this way. contain only definitions. The design process propa- Many framework-specific, platform-independent gates design information in templates or databases middleware services sit above the platform isolation between servers, much like the replicator. layer. These services are accessed via C functions that • Chronos—This is a scheduler that executes formu- define the Lotus Notes API. Middleware services las (in the formula language) in the background. include the following: • Event, report—These are administration programs. • Server—This server does job initiation and sched- • object management service, which supports simple uling for the preceding servers. There are other data types and bulk information storage; built-in server programs, and users can write their • document management service, which uses the own and register them with the add-in middleware object management service and names documents, service. organizes documents, and supports the formula language (a script language for building user A variety of other tools are supported, including applications); Editor for manipulating forms, View for defining and • security service, which supports encryption, digital navigating views, and Desk for organizing access to signatures, and discretionary access control. It uses applications. Each tool also includes private services services in security middleware from RSA Data for specific functions, such as spell checking, sending Security; messages, and document format conversions. Lotus • indexing, which provides indexed access to docu- Notes is typical of new types of framework in that it ment content (using the content-based retrieval uses framework-specific middleware services and a engine from Verity Corp.) and to summary data framework-unique API. If other frameworks of this (i.e., document descriptors); type become popular, we would expect to see com- • messaging, which supports mail transports and mon middleware services between those frameworks mail addressing, including addressing to groups and a standard API. of names and hierarchically organized names; • events, which support dynamic notification via a Integrating Middleware Services mail message or log entry; An important way to add value to a set of middleware • logging, for auditing events on persistent storage services is by integrating them so they work well as a • naming, which supports client-server binding and coherent system. For example, one can ensure that integrates with transports and security services, they use a common naming architecture, have com- much like DCE (Lotus Notes pre-dates DCE); patible performance characteristics, support the same • system management functions, including add-in international character sets, and execute on the same (for server application configuration manage- platforms. These integrated services are often encap-

96 February 1996/Vol. 39, No. 2 COMMUNICATIONS OF THE ACM Middle ware sulated in a framework, but they need not be. For explained that some OS services will migrate up to example, the OSF DCE is an integrated set of services become middleware and some middleware services that is not a framework. Making services work well will migrate down into the OS. Another strong driver together is what distinguishes an integrated system of middleware evolution is new application areas, such from a set of commodity services. The activity of cre- as mobile computing, groupware, and multimedia. ating such an integrated system out of independently New applications usually have some new requirements engineered piece-parts is called system engineering. that are not met by existing middleware services. Ini- Applications, middleware, and systems can be mea- tially, vendors build frameworks to meet these sured in a variety of dimensions, including usability, requirements. Over the longer term, when a success- distributability, integration, conformance to stan- ful framework-specific service generates demand out- dards, extensibility, internationalizability, manage- side the context of that framework (to be used directly ability, performance, portability, reliability, or in other frameworks), it is usually made available as scalability, and security. We call these pervasive attrib- an independent piece of middleware. utes, since they can apply to the system as a whole, not There is already too much diversity of middle- just to the system’s components. ware for many customers and application develop- Users want to see their applications rate highly on ers to cope with. Customers and standards bodies pervasive attributes. Application programmers can are responding to this problem by developing pro- help accomplish this by layering their applications on files, which include a subset of middleware services middleware that rates highly on these attributes. Sys- that cover a limited set of essential functions with- tem engineers can improve things further by ensur- out duplication (i.e., only one service is selected of ing a set of middleware uniformly attains certain each type). The X/Open Portability Guide is one pervasive attributes (by using common naming, com- especially well-known profile [7]. Unfortunately, patible performance characteristics, etc.). They may different profiles select different services, putting a do this by defining building codes for applications to heavy burden on vendors that want to sell to cus- use middleware services in a common way (e.g., com- tomers that require different profiles. This hurts mon naming conventions), by influencing the design users, since vendors dilute their resources by of middleware services (e.g., require that they use a investing in different profiles. Standards groups particular security service to authenticate their are becoming more sensitive to this problem and callers), or by selecting services that are compatible are working harder to coordinate their efforts to (e.g., trading off performance for portability of some avoid a proliferation of competing standards. In services to ensure the system as a whole has good per- the end, the market will sort this out when certain formance). components and profiles become low-cost com- Today, system engineering is mostly an ad hoc modities, making it hard for offbeat components activity. For some pervasive attributes, such as perfor- and profiles to compete. mance and reliability, there are techniques for mea- suring, analyzing, and implementing systems to meet hile profiles can simplify specified goals. For most attributes there is little the- a set of middleware, ory or technique to apply, other than common sense they can also lead to and an orderly engineering process. Since the trend integration problems. is to increase the use of off-the-shelf components to Independently designed build software systems, more and better techniques middleware services may for system engineering are urgently needed. Devel- be hard to use together oping such techniques is a major opportunity and unless certain usage challenge for computer systems researchers. guidelines are adopted, such as common name for- In addition to integrating middleware services into matW and common context (e.g., user and session a system, it is important to characterize the result of identifiers). In addition, not all popular implemen- that integration. For the performance attribute, it is tations of such services may be able to coexist on a common practice to characterize the system by its platform without some reengineering. For exam- behavior on benchmarks. For some attributes, one ple, they may generate naming conflicts or may can characterize the system relative to specific func- require different versions of underlying OS or com- tional capability (e.g., the U.S. Department of Defense munications services. Therefore, when defining a “Orange Book’’ security labels: A1, B2, and so forth). profile, one needs a profile-level architecture that For other attributes, such characterization is more dif- addresses these issues. Unfortunately, all too often, ficult, since there are no generally agreed-upon met- profile definers leave this work to vendors and cus- rics (e.g., extensibility or ease of use). Developing tomers to sort out. such metrics is another major research opportunity. Vendors too are responding to the complexity of middleware. They have formed consortia, often joint- Trends ly with large users, to identify profiles that both ven- Although the concept of middleware will be with us dors and customers need. X/Open and the Object for a long time, the specific components that consti- Management Group are examples. Consortia are also tute middleware will change over time. Earlier, we working to integrate sets of middleware services,

COMMUNICATIONS OF THE ACM February 1996/Vol. 39, No. 2 97 which can then be used as a single component. For and expanding its functionality into new application example, the OSF DCE integrates RPC with directory, areas are likely to increase this reliance in the future. time, security, and file services [6]. OSF is pursuing a similar style effort with its Distributed Management Acknowledgments Environment (DME) [3]. Individual vendors are pub- This article arose from several years of work with lishing their preferred sets of middleware interfaces, dozens of engineers on Digital’s NAS middleware to tell application developers what they can count on. architecture and products. I am indebted to the late For example, Digital is doing this with its Network David Stone, who created management focus on Application Support (NAS) [5] and Microsoft with its the problems addressed here and who encouraged Windows Open Services Architecture (WOSA). me to pursue them. I thank Wendy Caswell, Scott The complexity of current middleware is unten- Davis, Hans Gyllstrom, Chip Nylander, Barry Rubin- able over the long term. Therefore, when developing son, John Miles Smith, Mark Storm, and especially a new middleware service, a vendor must immediate- Leo Laverdure for many stimulating discussions ly embark on a path to make its service a de facto stan- about middleware issues and for helping to develop dard. This seemingly works against the vendor’s best some of the key abstractions in this article. I am interest by prematurely commoditizing the technolo- grateful to Ken Moore of Iris Associates, who col- gy. However, application vendors won’t rely on a mid- laborated on the description of Lotus Notes, and to dleware service unless they’re confident it will the following people for many suggested improve- become a de facto standard. Thus, the vendor’s only ments to this article: Ed Balkovich, Mark Bramhall, (unappealing) alternative to early standardization is Michael Brodie, John Colonna-Romano, Judy Hall, to wait until another vendor follows this path, ren- Meichun Hsu, Hans de Jong, Murray Mazer, and dering the first vendor’s technology obsolete. Some Calton Pu. C technologies are defined by independent standards bodies. These standards are truly open and may References 1. Bernstein, P.A. Transaction processing monitors. Commun. therefore be implemented by multiple vendors. Since ACM 33, 11 (Nov. 1990), 75–86. each vendor’s implementation supports the same 2. Bernstein, P., Hadzilacos, V., and Goodman, N. Concurrency standard functions, vendors can compete by better Control and Recovery in Database Systems. Addison-Wesley, Read- attainment of pervasive attributes or by extending the ing, Mass., 1987. 3. Chappell, D. The OSF distributed management environment. functionality in nonstandard, high-value ways. In the ConneXions 6, 10 (Oct. 1992), 10–15. latter case, they must now pursue the standardization 4. King, S.S. Middleware. Data Communications. (Mar. 1992), route for the extensions, or again, application ven- 58–67. dors will resist using them. 5. Laverdure, L., Colonna-Romano, J., Srite, P. Network Application Large enterprises are already relying on middleware Support Architecture Reference Manual. Digital Press, 1993 6. Rosenberry, W., Kenney, D., and Fisher, G. Understanding DCE. to support their current approximations of an infor- O’Reilly, Sebastapol, Calif., 1992. mation utility. The trends of simplifying middleware 7. X/Open Portability Guide. The X/Open Company, Reading, England.

About the Author: PHILIP A. BERNSTEIN is an architect at Microsoft Corporation. Glossary of Acronyms He currently works on repository technology in support of CASE tools. Author’s Present Address: One Microsoft Way, Redmond, ANSI—American National Standards Institute WA 98052-6399; email: [email protected] API—Application Programming Interface CAD—Computer-Aided Design CASE—Computer-Aided Software Engineering The following registered trademarks are referenced in this article: PostScript of Adobe Systems, Inc.; Foundation of Andersen Consulting; Macintosh of CORBA—Common Object Request Broker Architecture Apple Computers Inc.; Cognos of Cognos Corp.; ACMS, ACMSxp, Alpha DCE—Distributed Computing Environment AXP, COHESIONworX, DECadmire, DECforms, LinkWorks, NAS, Open- DBMS—Database Management System VMS, PATHWORKS, Powerframe, and TP Workcenter of Digital Equipment Corp.; SoftBench of Hewlett-Packard Corp.; AIX, CICS, DB2, IBM, and GOSIP—Government Open System Interconnect Profile NetView of the IBM Corp.; Focus of Information Builders Inc.; Intel of Intel GUI—Graphical User Interface Corp.; Lotus Notes of Lotus Development Corp./IBM; Falcon of Mentor Graphics; Windows and Windows/NT of Microsoft Corp.; Netware, Unix, ISO—International Organization for Standardization and Tuxedo of Novell, Inc.; OSF of the Open Software Foundation; ORA- ODBC—Open Database Connectivity CLE and Rdb of Oracle Corp.; NFS, SPARCstation, and Sun of Sun Microsys- OMG—Object Management Group tems, Inc.; SYBASE of Sybase, Inc.; Composer by IEF of Texas Instruments; Encina of Transarc Corp.; Uniface of Uniface International; and X/Open of OS—Operating System X/Open Company Ltd. OSF—Open Software Foundation OSI—Open System Interconnect RPC—Remote Procedure Call Permission to make digital/hard copy of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or SQL—Structured Query Language distributed for profit or commercial advantage, the copyright notice, the title TP—Transaction Processing of the publication and its date appear, and notice is given that copying is by WOSA—Windows Open Services Architecture permission of ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specific permission and/or a fee. 4GL—Fourth Generation Language

98 February 1996/Vol. 39, No. 2 COMMUNICATIONS OF THE ACM