Inside IBM's Distributed Data Management architecture

Inside IBM's DistributedData Managementarchitecture

IBM's Distributed Data Management (DDM)architecture is an element of Systems ApplicationArchitectureTNI that defines an open environmentfor sharing data in files and relational databases.DDM is a key element of IBM's DistributedRelational Database Architecture. DDMarchitecture enables programs to access andmanage data stored on remote systems. It is aframework for a wide range of additionalapplication services. Influenced by the conceptsof object-oriented technology, DDM architectureis designed to be object-oriented. This paperexamines DDM architecture from a number ofviewpoints, considering why and how it wascreated, what it is, and how it has evolved.

Systems Application Architecture* (SAA *) de-fines a consistent set of application services

that span IBM system platforms from personalcomputers to large systems, thereby making ap-plication services a unifying force for the future.Distributed application services are provided bySAA Common Communications Support (ccs).These SAA elements deal with how systems worktogether to provide services to applications dis-tributed throughout a network. For the most part,these ccs services are not seen by the user. Soft-ware products that companies install provide theinterfaces employed by programmers to developapplications that use ccs services. Knowing whatis within these products enhances an understand-ing of how they work and how to develop effec-tive distributed applications.

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992

by R. A. DemersJ. D. FisherS. S. GaitondeR. R. Sanders

Two key SAA application services are DistributedFile Management! and Distributed Relational Da-tabase Management. 2 Both of these services arebuilt to the specifications provided by IBM's Dis-tributed Data Management (DDM) architecture.DDM architecture enables programs to access andmanage data stored on remote systems in a cli-ent/server relationship.

This paper is not intended to be a tutorial on thetechnical details of DDM architecture. That levelof information is available in documents pub-lished on the architecture (particularly in Refer-ence 3). Rather it examines DDM architecturefrom a number of points of view, considering whyand how it was created, what it is now, and howit has evolved. The paper begins with a discussionof the role of software architecture in general, andcontinues with a brief history of DDM architecture.Next, the role of object-orientation in making DDMarchitecture uniform in style and highly consistentin structure is presented. It is followed by apresentation of the conceptual framework of thearchitecture in terms of formally defined layers ofobjects, along with discussions of its key classes ofobjects. Concluding the paper are discussions of

©Copyright 1992 by International Business Machines Corpo-ration. Copying in printed form for private use is permittedwithout payment of royalty provided that (1) each reproduc-tion is done without alteration and (2) the Journal referenceand IBM copyright notice are included on the first page. Thetitle and abstract, but no other portions, of this paper may becopied or distributed royalty free without further permissionby computer-based and other information-service systems.Permission to republish any other portion of this paper mustbe obtained from the Editor.

DEMERS ET AL. 459

product-unique extensions to DDM architecture andthe relationship OfDDM architecture to internationalstandards.

The role of software architecture

We begin by distinguishing a software architec-ture from implementations of the architecture. Asoftware architecture is really just a set of spec-ifications, a set of blueprints, for constructingproducts. As such, a software architecture is notinstalled on computer systems. Rather, productsbased on a software architecture are installed.What, then, is the role of software architecture indeveloping products?

Consider, for example, a suspension bridge overa large river. The bridge is designed by an archi-tectural firm to meet the requirements of its own-ers and of its users, the driving public. It is thenbuilt by a separate construction company. Onlyafter being certified for use by independent build-ing inspectors are people then allowed to driveover it. There are clear similarities between thisexample and designing, constructing, assuring,and delivering computer software products.

An architectural firm is responsible for designingthe bridge so that it meets the needs ofthe peoplewho will own it and the people who will use it. Forthe owners of the bridge, the architects must con-sider the cost and schedule of its construction, thecost of its operation, and its long-term mainte-nance requirements. For users of the bridge, theymust consider the structural integrity of thebridge, its carrying capacity, its relationship to itsenvironment, and its aesthetic appeal. All of theseconsiderations must be reflected in the blueprintsproduced by the architects. Software architectshave similar concerns for product owners andusers. A software design must meet the needs ofthe companies that implement products based onthe design, and it must meet the needs of the usersof those products. For large software develop-ment projects, these concerns are the ones thatdetermine the success or failure of the project.They must be given as much consideration asthey would be given in designing a major highwaybridge.

A construction company is bound by its contractto build a bridge according to the blueprints pro-vided by the architects, but real-world conditionscan require changes. In these cases, the architects

460 DEMERS ET AL.

are informed of the problems encountered andmake changes to the blueprints. Often, the archi-tects visit the construction site to see for them-selves how well their specifications are being re-alized and sometimes spot troubles before theconstruction crew is aware of them. The relation-ship between the architects and constructioncompany is an important factor in the success ofthe project. So too, with software architecture.The architects must be independent of the pro-gramming team but have a close working rela-tionship with them. The design produced by thesoftware architects must be seen as the essence ofthe implementation contract, but it must also beopen to change as real-world problems are de-tected.

Building inspectors also study the blueprints, notto build a bridge themselves, but to ensure thatthe bridge is actually built according to the spec-ifications. They test the quality of materials andconstruction as the bridge is being built so thatthey can certify it meets the requirements of theblueprints. In software development, this role isoften played by a systems assurance or qualityassurance team. But for the role to be played ef-fectively, the assurance team must measure animplementation against up-to-date specificationsthat clearly define what was supposed to be built.

Finally, the bridge is opened to traffic, and thedriving public decides whether it meets theirneeds, namely, getting across the river in a safe,timely, cost-effective manner. Similarly, a soft-ware product must fulfill the needs of its users.

After thousands of years of experience in con-structing bridges, buildings, and other large, com-plex structures, this process has been formalizedin both building codes and legal practices. Cleardivisions of responsibility among independent ex-perts are carefully observed. We are only nowbeginning to understand that this process appliesequally well to software projects, especially forlarge projects. In particular, we are slowly learn-ing that software architecture requires a differentskill than programming and should be done bypeople other than programmers.

The history of DDM architecture

What we call DDM architecture is actually anevolving set of specifications for distributed ap-plication services. The story of DDM architecture


begins in the mid-1970s when IBM's Systems Net-work Architecture (SNA) logical unit (LV) 6.24

was being designed. An important feature ofLV 6.2 is that it is possible for a program on onesystem to create a conversation with a programon another system and pass it parameters (effec-tively, a remote procedure call), then interchange

DDM architecture is actuallyan evolving set of

specifications for distributedapplication services.

messages with it. In addition to application pro-grams using LV 6.2, its architects saw the possi-bility of requesting system services and using theresources of remote systems with this mecha-nism. Indeed, they saw LV 6.2 as the foundationfor the development of a distributed operatingsystem, with access to remote files and databasesa clear priority.

Work began on an architecture that would useLV 6.2 capabilities to provide distributed datamanagement services, and it was thus called DDMarchitecture. Two things quickly became obvi-ous. First, the interfaces and capabilities of thedata management facilities of the participatingIBM systems were quite varied and would makethe design of a common distributed data manage-ment facility difficult, essentially being an exer-cise in negotiation and standardization. Second,there was no strong demand for LV 6.2 services onIBM large systems at that time because other com-munications services were in wide use. As a re-sult, work on the DDM architecture languished.

However, circumstances were somewhat differ-ent for the IBM System/34 family of midrange com-puters. No large installed base of users was alreadyemploying other communications services, andsome users were beginning to install System/34sin multiples for both horizontal growth and to de-centralize their processing. These factors made apeer-to-peer communications facility like LV 6.2desirable to System/34 users and made access to


data in remote System/34s crucial. From the ini-tial work that had been done on DDM architecture,a product called System/34 Distributed Data FileFacility (DDFF) was created and was announcedin 1980. Because it was intended to communicateonly with other System/34s, DDFF was able to by-pass the problems of nonstandard file interfacesand prove the value of the fundamental idea ofDDM architecture; that is, it is useful to be able torequest services from remote systems as if theyare local.

The DDFF product was carried forward to the suc-cessor of the System/34, the System/36* , in 1982.But in the attempt to do this for the System/38*family of computers, the problem of data man-agement standardization again arose because ofthe different data management interfaces andfacilities of the System/38. This time, however,the people interested in solving it were all part ofthe same IBM programming laboratory, in IBM'sRochester, Minnesota facility, responsible for theSystem/34, System/36, and System/38 families. Anew architecture group was formed in Rochesterin 1983 to work with representatives of these sys-tems and to define the syntax and semantics ofDDM messages. The result was Level 1 of DDMarchitecture, which was announced and pub-lished in 1986. At the same time, IBM announcedDDM products developed by the Rochester labo-ratory for use with the IBM Personal ComputerDisk Operating System (PC-DOS), System/36, Sys-tem/38, and Customer Information Control Sys-tem/Multiple Virtual Storage (CICS/MVS*).

The next step in the evolution OfDDM architecturewas the support of stream-oriented files. Client/server products for the System/36 and System/38required the ability to store, access, and managePC-DOS stream-oriented files and hierarchical di-rectories on a System/36 or System/38. This workresulted in Level 2 of DDM architecture, whichwas published in 1988.

At about the same time, the SAA subset of therecord file support of DDM architecture was de-fined and announced as an SAA Common Com-munications Support Architecture. As such, IBMalso announced its intention to provide Distrib-uted File Management (DFM) products on all fourIBM SAA systems: Operating System/2* (OS/2*),Operating System/400* (OS/400*), Virtual Ma-chine/Enterprise Systems Architecture (VM/ESA*),and Multiple Virtual Storage/Enterprise Systems

DEMERS ET AL. 461

Architecture (MVS/ESA*). The DFM product effort,led by the IBM laboratory in San Jose, California,has also involved IBM laboratories in Boca Raton,Florida; Boulder, Colorado; Cary, North Caro-lina; Endicott, New York; Rochester, Minnesota;and Sindelfingen, Germany-truly a worldwideIBM effort.

Level 3 of the DDM architecture, published in 1990,supports IBM's Distributed Relational Database Ar-chitecture (DRDA). 5 This, too, was and continues tobe an IBM-wide effort. DRDA is based on the Sys-tem/R research originally done by the IBM AlmadenResearch Laboratory in San Jose, California. Un-der the leadership of the IBM Santa Teresa labora-tory, also in San Jose, the DRDA design group in-cludes individuals representing IBM Research, therelational database management products of allfourSAA systems, DDM architecture, Formatted Data:Object Content Architecture (FD:OCA), CharacterData Representation Architecture, and SNA. DDMLevel 3 architecture defines messages for request-ing relational database (RDB) services, for example,binding Structured Query Language (SQL) state-ments into RDB packages and subsequently execut-ing those packaged statements. Included in thesemessages are DDM structures for carrying SQL state-ments and responses and for carrying FD:OCA datadescriptors. DDM also defines how SNA LV6.2 com-munications protocols are used by DRDA.

Level 4 of DDM architecture is expected to bepublished in 1992. For the DFM products, storagemanagement attributes are supported for files, asdefined by the IBM Enterprise Storage Manage-ment" architecture," as well as support for user-defined attributes for files. For DRDA, two-phasecommitment control protocols are defined for ap-plication-directed distributed units of work. Andfor the OS/400 DDM and OS/400 PC Support prod-ucts, data queuing and system command pro-cessing classes are defined.

Clearly, there is a lag in time between the com-pletion of architectural work and the shipment ofproducts. Each of the IBM products implementingsome part of DDM architecture is doing so withinthe context of a complex system developmentenvironment, competing priorities, and limitedresources. In general, a new level of DDM archi-tecture is announced when at least one imple-menting product is ready to be announced. In thisway, feedback from at least one product on anyambiguities or problems found can go to the ar-

462 DEMERS ET AL.

chitects. The result is that published levels OfDDMarchitecture have been of high quality, with littleneed for subsequent corrections. Although non-IBM vendors have not been invited to participatein the design of DDM architecture, they have hadthe benefit of quality specifications without sig-nificant delay.

Blueprints by themselves are of little value to endusers. What counts to them are products they canuse. IBM products using DDM architecture aregiven in the appendix.

Numerous other companies have also expressedan interest in implementing products that provideconnectivity with IBM's Distributed File Manage-ment and Distributed Relational Database prod-ucts. An example of such a product is one underdevelopment by Object Technology Internationalfor OS/2 and Windows** that supports the devel-opment of cooperative applications with OS/400s.Written in Smalltalk/V" *, this product supportsthe development of OS/2 and Windows applica-tions written in SmalltalkN that use OS/400 serv-ices. Among other services, it implements DDMclient architecture for accessing and managingrecord files.

The relationship of DDM architecture to variousproducts is illustrated by Figure 1.

Object-orientation and OOM architecture

Being object-oriented is a frequent claim in thecomputer industry today, but it is not always clearwhat that means. Calling all the entities that com-prise an architecture objects is not sufficient (butis certainly a start). More important is a carefuladherence to the fundamental concepts of object-orientation and the design discipline they imply.

Before we look at how DDM architecture uses ob-ject-oriented concepts, a few definitions are nec-essary. From the object-oriented point of view,an object is a self-contained entity that has its ownprivate data and a set of operations to manipulatethose data.

Objects are created by special objects calledclasses and are known as instances of a class.

As defined by Wegner 7 there are three primarycharacteristics of object-oriented systems:


Figure 1 DDM architecture and its product environments

IBM MVS/ESA IBM CICS IBMVM/ESA(SAA) (SM) (SM)

Ir---- J-LL----, I

IIBM SYSTEM/36

II DDM !

IOTHER VENDORS

II ARCHITECTURE II II I

~-------------:I ABSTRACT, I

I IBM SYSTEM/38

II OBJECT-ORIENTED I

I'BMA'X

I: SPECIFICATIONS I

II Ir-------------,I - RECORD FILES II - STREAM FILES I: - RELATIONAL DATABASES II IBM AS/400

II - OTHER OBJECTS :

IIBM STORE

Ii I SYSTEMS(SM)

L----T-rT----.JI I

IBM PC-DOS IBM IBMOS/2PC SUPPORT/36 (SAA)OS/400 PC SUPPORT

1. Encapsulation: A technique for minimizing in-terdependences among separately writtenmodules by defining strict external interfaces.In this definition, the word object could be ex-changed for module.

2. Inheritance: A technique that allows new,more specialized classes to be built from theexisting classes while retaining all of the char-acteristics and capabilities of the existingclass.

3. Polymorphism: A technique that allows thesame command (or message in object-orientedterms) to be understood by different objects,which respond differently. Often, this goeshand in hand with dynamic binding. Polymor-phism eliminates much of the control structuretraditionally needed to differentiate between


objects, such as case statements and if thenelse statements.

All entities in DDM architecture are objects, andthe architecture consists of a large number ofclasses to which these objects belong. The refer-ence manual" for DDM architecture actually con-sists of formatted printouts of a large set ofclasses. These classes each have a name and arearranged alphabetically for ease of reference. Be-cause these terms refer to each other extensively,the reference manual is actually a hypertext doc-ument. Extensive cross-referencing informationand indexes are also provided.

The variables of a DDM architecture class specifyits inheritance, describe the variables of the class

DEMERS ET AL 463

and the variables of its instances, and specify thecommands to which the class responds and thecommands to which its instances respond. Thevariables of the class object are encapsulated bythe commands of the class, and the variables ofthe instances of the class are encapsulated by theinstance commands of the class.

DDM architecture uses the concept of inheritanceto simplify the architectural specifications. Forexample, the class of MANAGER defines the struc-ture and private data that are common to all DDMmanagers. The class of FILE, which is a subclassof MANAGER, inherits variables and commandsfrom the class of MANAGER. Since many manag-ers respond to some of the same commands, poly-morphism is an inherent attribute of DDM archi-tecture.

The fundamental concepts of object-orientationused in DDM architecture were derived from thebook Smalltalk-80: The Language and Its Imple-mentation. 9 Although the DDM architects attemptto remain faithful to these concepts, there are anumber of important differences between DDM ar-chitecture and Smalltalk:

• The DDM architecture class library is not de-signed for the same purposes as a Smalltalkclass library. A Small talk class library providesprogrammers with a computer-aided softwareengineering (CASE) environment and includes awide variety of classes that can be reused whencreating Smalltalk applications. In contrast, theclass library of DDM architecture contains onlyclasses related to the services covered by thearchitecture. Although DDM architecture can beimplemented in Smalltalk, the DDM architectureclass specifications are not intended to be aworking prototype of the architecture.

• The Smalltalk concept of meta-classes as first-class objects was considered both confusingand of marginal value to DDM architecture. In-stead, DDM architecture collapses each meta-class into its corresponding class. That is, eachclass defines its own variables and its own be-havior (with inheritance).

• Because DDM architecture is concerned withthe form of the messages that flow between cli-ents and servers, each command message is for-mally defined by its own class object. For ex-ample, the Clear File message is defined by theCLEAR class. Each class whose instances can be

464 DEMERS ET AL.

a receiver for this message specifies CLEAR asan instance command.

• Smalltalk defines only one error message: Doesnot understand. It is returned if the class of areceiving object does not recognize a request.This action was not considered adequate giventhe heterogeneous nature of DDM architectureclients and servers. Therefore, for each com-mand message, DDM architecture defines the setof reply messages that can be returned by anymethods that implement the command. Eachreply message is also defined by its own classobject, and all reply messages are subclasses ofclass RPYMSG, which defines a set of instancevariables that they all inherit. DDM architecturedefines a separate reply message class for eachexception that can occur. These reply messagesare then specified for whatever commands canraise each exception.

• Also, because DDM architecture is particularabout message formats, each instance variableof a command or reply class is fully typed. Thatis, DDM architecture specifies precisely whatclasses of objects can be specified for each vari-able. Clients are required to create messageswithin the range of this typing. Servers typecheck each variable of a command before it ispassed on to its receiver.

• Perhaps the most original aspect of the object-orientation of DDM architecture is the divisionof its objects and their classes into hierarchicallayers. Whereas Smalltalk considers all objectsto exist in a single, uniform space within a singlevirtual image, DDM architecture considers themto exist in a multilayer space where the objectsin one layer are composed of objects from thenext lower layer. This difference is discussed inthe next section.

With the exception of the Object Technology In-ternational product that is being implemented inSmalltalk/V, DDM products have been implementedusing procedural programming languages, such asC, because object-oriented programming languageswere not available or because the products had tobe integrated with other products. They have, nev-ertheless, benefited from the clarity, conciseness,and completeness of the object-oriented specifica-tions of DDM architecture.

The DDM architecture framework

The initial services defined by DDM architecturepertain to data management, but these services


Figure 2 The structural layers of DDM architecture

DISTRIBUTED SYSTEM LAYER:AN INTERACTING GROUP OF SERVERS

CLIENT/SERVER LAYER;ENCAPSULATED GROUPS OF RESOURCE MANAGERS

-CICS/DDM- SYSTEM/36 DDM- SYSTEM/38 DDM-DDM/PC- PC SUPPORT/36

MANAGER LAYER;ENCAPSULATED GROUPS OF OBJECTS

- COMMUNICATIONS MANAGERS-AGENTS- DIRECTORIES- FILES

OBJECT LAYER;ENCAPSULATED DATA ENTITIES

-COMMANDS- PARAMETERS-OPERANDS- REPLIES-RECORDS

DATA LAYER;

- BIT STRINGS- CHARACTER STRINGS

-DB2-saUDS-OS/2 DBM-OS/400 DDM- PC SUPPORT/400

- SECURITY MANAGER- LOCK MANAGER- CLASS DICTIONARIES- RELATIONAL DATABASES

- SERVER ATTRIBUTES- MANAGER ATTRIBUTES- OBJECT ATTRIBUTES- FIELD ATTRIBUTES- DATA DESCRIPTORS

-INTEGERS- FIXED-POINT NUMBERS

- MVS/ESA DFM- VM/ESA DFM- OS/2 DFM- 4680 DFM

are specified within the context of a frameworkdesigned to accommodate the full range of appli-cation services typically provided by operatingsystems. This framework, illustrated in Figure 2,consists of nested structural layers. It is similar towhat we see in natural world systems, where mol-ecules are composed of atoms, atoms of particles,and particles of quarks. For DDM architecture, thefollowing five layers are defined:

• The Distributed System Layer consists of oneor more distributed systems in a network of het-erogeneous computer systems. Each distrib-


uted system provides a single system image ofoperating system services for its client pro-grams. Each is composed of DDM architectureclients and servers.

• The Client/Server Layer consists of the variousclients and servers of a distributed system. Theclients provide requesting programs with localor remote transparency, and the servers man-age and provide access to the resources of asingle system. A client or server is composed ofDDM architecture resource and service man-agers.

• The Manager Layer consists of the major com-

DEMERS ET AL. 465

ponents of a server. For clients, managers pro-vide local or remote transparency, routing serv-ices, communications services, and supportservices. For servers, managers provide re-source access and management services, rout-ing services, communications services, andsupport services. A manager is composed ofDDM architecture objects.

• The Object Layer consists of self-identifyingdata used by managers, stored by managers, orcommunicated between managers. An objectconsists of DDM architecture data elements.

• The Data Layer consists of the data elementsthat describe objects or represent their value.

The Distributed System Layer. A distributed sys-tem is one in which users and programs see asingle system image of the services available tothem through a network of heterogeneous, net-worked systems. In DDM architecture, a distrib-uted system consists of clients and servers thatinteract to process application requests. The cli-ents and servers use whatever communicationlinks and whatever communication protocols areavailable between them in a peer-to-peer fashion.In this sense, a DDM architecture distributed sys-tem is independent of the topology of the networkused by its servers. Multiple DDM architecturedistributed systems can reside in the same net-works, each with clients and servers in some ofthe same systems. A DDM architecture distributedsystem is illustrated in Figure 3.

There are two possibilities to be considered whendesigning a single system image: canonical serv-ices and mapped services. With canonical serv-ices, a single programming interface is defined foreach service, all client programs use that interfaceto request it, and all servers support precisely thatinterface for that service. A client program neednot be concerned with what server will actuallyprovide the service, and a server need not be con-cerned with who is requesting it. The design of themessages that flow between the client and serversystems is a simple translation of each serviceinterface into a transmittable stream of bytes.Client programs are highly portable between sys-tems but have to be specially written to the canon-ical interfaces. This approach is generally beingtaken by the Open Software Foundation Distrib-uted Computing Environment (OSF/DCE**). Thepresumption is that new client and server productswill be developed over time to provide the canon-ical services and interfaces.

466 DEMERS ET AL.

The second possibility for a single system imageis the one adopted for DDM architecture: mappedservices. Client programs use the interfaces of

Multiple DDM architecturedistributed systems can

reside in the samenetworks.

their local system to request services, regardlessof the system that actually provides them. If arequest is for a local service, it is directed to thelocal facility that provides that service. But if it isfor a remote service, the client system translatesthe request into a message designed for that classof service. The remote server translates the mes-sage into a request specified through a program-ming interface of the server. Thus, three program-ming interfaces are involved in a mapped requestfor a remote service:

1. The programming interfaces of the client sys-tem

2. The abstract programming interfaces definedby messages

3. The programming interfaces of the remoteserver

In this way, client programs can request serviceswithout concern for what programming interfacesactually need to be used. And conversely, a sys-tem can provide services without concern for theprogramming interfaces actually used by the re-questing application program. Any existing ornew program that uses a service can be a client ofeither the local system or of a remote system, butthese programs are not portable to another sys-tem without conversion to its service interfaces.

Whether canonical services or mapped servicesare used in the design of a single system image islargely a matter of objectives. Local interfacescan often be mapped to canonical services, andlocal interfaces can be designed to match the mes-sages of mapped services. In both cases, the syn-


Figure 3 DDM distributed systems and servers

DDM DISTRIBUTED SYSTEM

REGIONAL CORPORATEHEADQUARTERS HEADQUARTERS

I

DDMSERVERI

DDMCLlENT DDMSERVER

~I<l-~

SHIPPING ACCOUNTINGDEPARTMENT DEPARTMENT

DDMSERVER DDMSERVER-.

WORKSTATION WORKSTATION

DDM CLIENT ~~ DDMSERVER

I

tax and semantics of the services must be care-fully and formally defined for both clients andservers. The real issue is whether existing clientprograms and existing services should be changedto meet the requirements of canonical services.For DDM architecture, the choice of mapped serv-ices was dictated by the very large number ofexisting programs, files, and databases on IBMsystems. Ease of migration from single systems todistributed systems mandated the mapped serv-ices approach.

A final comment on this subject is that the ap-proach taken affects what services are defined. Todefine canonical services is largely an academicexercise, based on knowledge of similar services


(in the UNIX** environment for aSF/DeE), withattention to consistency and completeness, andcertainly with review and approval by peers in thesponsoring body. In contrast, the design ofmapped services is largely a standards exercise,requiring participation by representatives of mul-tiple client and server systems. As a mapped ser-vice model is designed, each representative mustcritique it in terms of the local services and in-terfaces available on his or her system, eitherfinding good mappings or arguing for changes thatwould allow good mappings. This process is ar-duous and time-consuming, but it leads to dis-tributed service models that better match theneeds of existing client programs and the capa-bilities of existing system services.

DEMERS ET AL. 467

Figure 4 Client/server architecture

CLIENT SYSTEM SERVER SYSTEM

APPLICATION PROGRAM

CLIENT ~ -------------- ~ SERVER

LOCAL FILES SNALU 6.2 SNA LU 6.2 FILE XCOMMUNICATIONS COMMUNICATIONSFACILITY FACILITY

The Client/Server Layer. In general terms, a clientis a layer of software in one system that routesservice requests to the server that owns a neededresource, such as a file, database, printer, or pro-cessor. The server can be either local or remote.The client/server model is illustrated by Figure 4.DDM architecture is in the client/server category.

DDM architecture calls clients source servers be-cause they are the source of requests for services,and it calls servers target servers because theyare the target of those requests. This difference interminology is simply the result of DDM architec-ture predating what is now called client/serverprocessing. This paper uses client/server termi-nology to avoid further confusion.

The servers in DDM architecture can be special-ized to handle specific resources. For example,one server (CICS/DDM) handles only files, whereasanother server (MVS DATABASE 2*) handles onlyrelational databases, and a third (Operating Sys-tem/400*) handles both files and relational data-bases. Multiple servers can reside in the samesystem.

A product implementing DDM architecture canprovide both client and server support, or it can

468 DEMERS ET AL.

be specialized as just a client or just a server. Asexamples, AS/400 DDM is both a client and a server,the DDM/PC product is only a client, and theCICS/DDM product is only a server.

The Manager Layer. A client or server in DDMarchitecture consists of a set of entities each ofwhich manages some aspect of the service, suchas a file, a database, or a conversation linking theserver to other servers. These entities are allcalled managers in DDM architecture. A client orserver can have zero or more instances of eachkind of manager defined by the architecture. Forexample, each file in a server is an instance of oneof the file manager classes in DDM architecture.

If a server supports only a subset of DDM archi-tecture, it has the managers of that subset, plusany managers on which they are dependent. Forexample, if a server supports only files, it only hasinstances of the manager classes required by files,but it does not have instances of the managersconcerned with relational databases.

The manager classes currently defined by DDMarchitecture can be categorized as files, data-bases, queues, access managers, support manag-ers, agents, and communications managers.


Figure 5 File manager request processing


APPLICATION PROGRAMCLEAR FILE(X)

CLIENT SERVER

----- --------------- ----CLIENT DDM CLRFIL MESSAGE SERVERFILEX

~-------------------------~FILE X

MANAGER MANAGER

f----- ---------------~----~ f

SERVERSCLEAR FILEINTERFACE

LOCAL SNA LU 6.2 SNA LU6.2 FILE XFILES COMMUNICATIONS COMMUNICATIONS

FACILITY FACILITY

Files. DDM architecture defines file classes forboth record-oriented files typically found on largesystems and stream files typically found in work-stations.

The DDM architecture model of a file consists ofinformation about the file (its attributes), the datacontent of the file (either records or a stream), andfor keyed files, an index over the records of thefile. Messages can be sent to a server to create,delete, rename, lock, unlock, or clear files. Fur-ther, data can be loaded into or unloaded from afile. Figure 5 illustrates how a request to clear afile of its data is passed from the client file sur-rogate to the server. The client file surrogateknows where the real file is located and how toaccess it.


Some of the attributes of a file must be specifiedby the requester when the file is created to de-termine its size, capabilities, and status in the sys-tem. Other attributes can also be specified to pro-vide application or user information about the file.And still other attributes, such as the date the filewas last changed, are managed by the file system.For each file class, DDM architecture allows cer-tain attributes to be retrieved from the file andcertain attributes to be changed.

Record-oriented files. A record-oriented file con-sists of a set of slots in which application-definedunits of data, called records, can be stored. Insome files, all records are the same length andhave the same data structure, whereas in otherfiles, records can vary in length and have varying,

DEMERS ET AL. 469

sometimes quite complex, structures. Most filesystems contain no information about the datacontent of the records in files. A record-orientedfile simply stores, and provides access to, the rec-ords of a file as whole units. DDM architecturerecord-file classes also treat records in this way,but metadata about records would allow manyadditional services to be provided, as discussed inReferences 10 and 11.

DDM architecture defines several subclasses ofrecord-oriented files in order to better match thesemantics of existing file systems:

• Sequential files: These files simply consist of aset of numbered slots with no relationships de-fined among them. The records in these files canbe accessed relative to the position of an accessmethod cursor (next or previous slot) or ran-domly by slot number.

• Direct files: These files consist of a set of num-bered slots, but there is an application-definedrelationship between the data contents of therecords in the slots and the number of the slot.The records in these files can be accessed rel-ative to the position of an access method cursor(next or previous slot) or randomly by slot num-ber.

• Keyed files: These files consist of a set of num-bered slots and an index that associates the val-ues of the key fields of each record with slotnumbers. In addition to relative and random ac-cessing by slot number, these files can be ac-cessed by using the index. The record with akeyvalue that is next or previous, relative to thekey value of the current record addressed bythe access method cursor, can be accessed.Any record can be randomly accessed by spec-ifying its key value.

• Alternate index files: These files consist of onlyan index that associates alternate fields of therecords of a base file with their slot numbers inthe base file. They provide an alternate accesspath to the records in the base file. The base filecan be a direct file, a sequential file, or a keyedfile. The access path of the index maintains aspecified ordering relationship for these fields.

Stream files. These files consist of a single streamof bytes. Applications can access or update anypart of the stream by specifying the starting po-sition and length of a portion of the stream. As

470 DEMERS ET AL.

with the record file classes, the DDM architecturestream file class has no knowledge of the contentsof the stream.

File access managers. DDM architecture file ac-cess manager classes each define a model of howa file can be used by a single local or remote user.Here too, the key problem is that each host sys-tem includes access managers with unique inter-faces. The DDM architecture file access managerseach define a single, consistent set of interfacesfor working with a file that can be mapped to andfrom the interfaces of host systems. An exampleof a file access manager is the Relative by RecordNumber Access Method of DDM architecture.

Figure 6 shows how an application accesses a re-mote file. When the application program opensthe file, an instance of a client file access manageris created. The client file access manager obtainsthe location of the file from the client file surro-gate and sends a request to create an accessmanager to the server. This server opens a pathto the real file. The bound path remains in exist-ence until the application closes the client accessmethod.

Figure 7 shows multiple application programs inthe same server accessing the same remote file.Note that they share the use of the same com-munications facility.

Relational databases. Relational databases (RDBs)have been implemented on many systems, eachwith its own interfaces and internal structures. Butthey also have much in common; in particular, sup-port for Structured Query Language (SOL). Distrib-uted Relational Database Architecture (DRDA) is theSAA CCS architecture concerned with distributed re-lational databases. DRDA is a composite architec-ture, as shown in Figure 8.

• DDM architecture defines the DRDA model of re-lational databases, the DRDA model of an SOLaccess manager, the messages and replies trans-mitted between a DRDA client and server, themeans by which SOL statements and FormattedData:Object Content Architecture (FD:OCA) de-scriptors are transmitted, and the ways in whichSNA communications protocols are used.

• SNA LV 6.2 is the communications facility usedby DRDA.


Figure 6 Access manager request processing


APPLICATION PROGRAM

CLIENT SERVER

____ _ ______________ L ___

CLIENT DDM MESSAGES .1 SERVERFILE ACCESS

~~~~~--~~~~~~~~~~~~~~~~~~~~ ~~:g~:SSMANAGER

1 T!

CLIENT CLIENTFILE X FILE XMANAGER MANAGER

LOCAL SNALU 6.2 SNA LU6.2 FILE XFILES COMMUNICATIONS COMMUNICATIONS

FACILITY FACILITY

• FD:OCA is used by DRDA to describe data. 12 Thedata are either input data to an SQL statement tobe executed or a result of executing an SQLstatement.

• Character Data Representation Architecture(CDRA) 13 is used by FD:OCA to tag character datawith its encoding scheme (such as ASCII andEBCDIC).

All database operations performed by the RDB oc-cur within a logical unit of work. A logical unit ofwork identifies the processing performed to takea set of recoverable resources from one state (A)to another (B) in an atomic fashion. If the pro-cessing succeeds, the new state of the recover-able resources is B, and if the processing fails, therecoverable resources return to state A. The


changes made by the application during the de-sired transition from state A to state B becomepermanent (committed) when the processing suc-ceeds, and the changes are undone (rolled back)when the processing fails.

Using normal SQL interfaces, applications andusers can interact with local or remote relationaldatabases. Consider the following types of sup-port for distributed relational databases:

• User-assisted distribution, in which users areinvolved in extracting data from an RDB, mov-ing the data to another system, and then loadingthe data into their RDB.

• Remote request, in which each request for serv-

DEMERS ET AL. 471

Figure 7 Multiple file access processing

APPLICATION APPLICATIONPROGRAM A PROGRAMB

CLIENT SERVER

CLIENTFILE CLIENTFILE SERVER FILE SERVER FILEACCESS ACCESS ACCESS ACCESSMANAGER A MANAGERB MANAGER A MANAGERB

11 1!

CLIENT SERVERFILEX FILEXMANAGER MANAGER

LOCAL SNALU 6.2 SNALU 6.2 FILEXFILES COMMUNICATIONS COMMUNICATIONS

FACILITY FACILITY

ices is independently sent to a remote RDB andexecuted, and the results are then returned.Each request is an independent unit of work.

• Remote unit of work, in which related requestsfor services from a remote RDB are exe-cuted within a single unit of work whose effectson the RDB can then be committed or rolledback.

• Distributed unit of work, in which related re-quests for services from multiple RDBs, local orremote, are executed within a single unit ofwork, whose effects on all of the RDBs can becommitted or rolled back.

472 DEMERS ET AL.

• Distributed requests, in which each requestwithin a distributed unit of work can result ininteractions with multiple remote RDBs.

Initially, DRDA defines support for a remote unitof work. The DDM architecture model for per-forming these operations is independent of thehardware architecture, the operating system, andthe local RDB interfaces and facilities of either theclient system where the application executes orthe server system where the RDB is located. The


model consists of the SQL Application Manager(SQLAM) and the relational database manager. Figure 8 The architectures used by DRDA

OOM architecture defines a single-system modelofthe relationships between an application and itslocal ROB. This model is illustrated by Figure 9. Inthis model, the application uses the SQLAM tocommunicate with the local ROB. The SQLAM usesother system services, such as directories and thesecurity manager, in establishing a connectionwith the ROB.

This model is extended to distributed processingas shown in Figure 10 by allowing the processingof the SQLAM to be split between the client andserver systems. Communications between the cli-ent and server SQLAMs are provided by agent andcommunications managers of the OOM architec-ture that are themselves functionally split be-tween the client and server systems. The clientsystem and the server system can be of differenttypes. The individual OOM architecture imple-mentations can be designed in whatever mannerbest utilizes their system environment.

DRDA

II DRDA RULES

CORA

FD:OCA

DDM

SNA LU 6.2

SINGLE-SYSTEM MODEL

I DIRECTORY

DICTIONARY

SUPERVISOR

SECURITYMANAGER

I APPLICATION

Figure 9 The single-system model of ROB accessThe process for obtaining access to a remote ROBis as follows. A client application obtains ROBservices by interfacing with a client SQLAM. Theclient SQLAM establishes a connection to the re-mote ROB. Client directory services are used todetermine the network location of the ROB beingcontacted. The client SQLAM then creates a clientAGENT and sends the Access Relational Database(ACCROB) command to that agent for transmissionto the server system. When the server systemprocesses the ACCROB command, a connection isestablished between the server SQLAM and theserver ROB. In general, the database requests sentby the application to the client SQLAM are routedto the server SQLAM for processing. However, theclient and server SQLAMs cooperate in the pro-cessing of many commands. For example, duringquery processing, data are buffered by both theclient and server SQLAMs to optimize the use ofthe communications facilities. The server SQLAMmanages all accesses to the ROB by a single re-mote requester. The server SQLAM is bound be-tween the server agent and a single ROB. OOMarchitecture commands are then received by theSQLAM for processing by the bound ROB.

The client and server SQLAMs exchange theFO:OCA data representation specifications whenthe connection is established with the relational

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992 DEMERS ET AL. 473

Figure 10 The remote system model of ROB access


I APPLICATION r-------------HRDB

I IIDICTIONARY II CLIENT SQLAM r------------- , SERVER SQLAM II DICTIONARY II I

I DIRECTORY II CLIENT AGENT r------------- , SERVER AGENT II DIRECTORY II I

SECURITY CLIENT SERVER SECURITYMANAGER COMMUNICATIONS COMMUNICATIONS MANAGER

MANAGER MANAGER

I SUPERVISOR

IISUPERVISOR

I.- -.. LOGICAL CONNECTIVITY

-----"''1--- COMMUNICATIONS CONNECTIVITY

database. These specifications provide the infor-mation necessary for the SQLAMs to determinehow their counterparts represent data, for exam-ple, character data or floating-point data. TheSQLAMs can then decide whether any data con-versions are necessary. When necessary, the dataconversions are performed by the SQLAM (clientor server) that receives the data.

When an application runs, a call is made to theclient SQLAM for each executable SQL statementin the application. The type of call to the SQLAMdepends on the RDB function to be performed asdetermined by the precompiler from the SQLstatement. The client SQLAM builds a DDM archi-tecture command to send to the server SQLAM

474 DEMERS ET AL.

based on the type of call received from the ap-plication.

Queues. Queues are important to many applica-tions because they allow either data or requestsfor services to be passed asynchronously fromone program to another. DDM Level 4 architecturedefines three subclasses of queues:

• First-in-first-out queues that act as an asynchro-nous pipe between the enqueuing and dequeu-ing programs

• Last-in-first-out queues that act as a push-downstack

• Keyed queues that act as a fan-out mechanism,


allowing different programs to dequeue only se-lected entries

As with files, the contents of the entries on aqueue, called records, are application-definedand can be of any format or complexity. The in-stance commands defined by DDM architectureallow a queue to be created, deleted, or cleared ina remote server. The attributes of a queue can beretrieved, and selected attributes can be changed.Records can be added to a queue or received froma queue. When receiving a record from a queue, theclient specifies the amount of time to wait beforetiming-out, if there is no entry on the queue.

Support managers. These managers support theuse of the resource and access managers by mul-tiple local and remote users.

Supervisor. Every client and server has a singleinstance of a manager called the supervisor. In thecurrent levels of DDM architecture, the supervisoris only responsible for exchanging informationbetween clients and servers about their classname, product release level, and the architecturallevels of the manager classes supported.

Class dictionaries. When two people speak toeach other in the same language, they can under-stand each other because they share commonwords, common syntax, common protocols, andcommon concepts. So too with distributed sys-tems. In DDM architecture, the common wordsexchanged between clients and servers are in-stances of the command, reply, and data classes.The common syntax consists of the ways in whichDDM architecture allows these objects to be re-lated to each other. The common protocol con-sists of the rules in DDM architecture governingwhen each server can send messages. And thecommon concepts consist of the semantics of theDDM architecture manager models in response topredefined commands.

With the exception of protocols, which are theresponsibility of communications managers, thesyntax and semantics of messages in DDM archi-tecture are defined by special objects, calledclasses, that reside in managers called class dic-tionaries. To be able to communicate with eachother, the client and the server must each have acopy of the same class dictionaries.

Security manager. When a local user logs onto asystem, the user's rights to use the system are


validated by the security facilities of the system.When that user then attempts to use a systemresource, such as a file or database, his or herauthorization to use the resource in the way inwhich an attempt is being made to use it is alsovalidated. Each type of system has its own se-curity facilities, each with its own model of se-curity and its own programming interfaces to thatmodel. Among these interfaces are those that al-low a user to be authorized to the system as awhole, and those that allow authorizations to spe-cific resources to be granted, revoked, and sharedwith other users. Examples of security facilitiesare the Resource Access Control Facility (RACF*)on MVS/ESA and VM/ESA, the security manager ofOS/400, and the GRANT/REVOKE functions of rela-tional database managers.

Validation of authorizations must also be per-formed when a remote user attempts to use a DDMarchitecture server or one of its resources. Whenan SNA LV 6.2 conversation is used for communi-cations, the user identity and password of the re-quester are passed to the communications facilityof the server system for validation. This processoccurs before any part of a DDM architectureserver is invoked, thereby guaranteeing that allremote requesters are authorized to the server.Although no interfaces are defined by DDM archi-tecture between SNA LV 6.2 and the security man-ager, their existence and use is assumed. Any se-curity violations are reported back to the client bySNA LV 6.2 messages.

But not all communications facilities provide thislevel of security. For example, if TransmissionControl Protocol/Internet Protocol (TCP/IP) isused, a communications manager for TCP/IPwould have to pass the user identity and passwordin special messages and then call the securitymanager to validate the requested authorization.In general, communications managers must makeup for any deficiencies in the communications fa-cilities they use.

Similarly, when a DDM architecture command isreceived by a server, the remote requester'srights to issue the command and to use the re-sources it requests are validated by the securitymanager. Here too, no interfaces are defined byDDM architecture for performing these valida-tions. The use of local security facilities are as-sumed. However, DDM architecture does define a

DEMERS ET AL. 475

variety of messages for reporting any authoriza-tion violations back to the client.

In the current levels of the DDM architecture, thesecurity manager is essentially just a stub thatrepresents whatever security facilities are avail-able on the local system. No DDM architecturemessages have yet been defined for working with

Files that are created, deleted,renamed, or moved are

addressed by techniques usedin ECF and AFS.

or modifying the authorizations of users to serverresources. All such changes to user authoriza-tions must be performed by logging onto the sys-tem that owns the resource. Clearly this is aninconvenience to users, and clearly, supportingthese services would be a desirable enhancementto DDM architecture.

Directories. When an application accesses a localresource, it does so by specifying its name, ac-cording to the naming scheme of the local system.This name is used to search the directories ofresources maintained by the local system to ob-tain addressability to the resource. Each type ofsystem has its own model of directory servicesand its own programming interfaces for usingthem. For example, MVS/ESA has a catalog thatsupports multipart names, Virtual Machine/Con-versational Monitor System (VM/CMS) has mini-disks, OS/4oo has libraries, and OS/2 has hierarchicaldirectories.

But how can these directories be extended to in-clude resources that are actually located in othersystems and have names that are foreign in syntaxto the local directory services? Several answersto this question are available among the IBM prod-ucts that have implemented DDM architecture.

In the Systern/36 DDM product, a side directorycalled the Network Resource Directory (NRD) wasdeveloped in which the information required tolocate a remote file can be placed. Names in the

476 DEMERS ET AL.

System/36 are simple eight-byte tokens, and thesystem maintains only a single directory of allsuch names. The NRD is really just an extensionof the system directory such that there is still onlyone name space in the system. If a name cannotbe found in the system directory, the NRD issearched, and if the name is found, the followinginformation is available about the file:

• The real name of the file on the server system• The network address of the DDM architecture

server• Other communications-related parameters

Thus, it is possible for the client to specify thename expected by the server in the DDM archi-tecture commands to open and access the file,while a System/36 name is used as an alias in theclient. An NRD entry is actually a surrogate for theremote file, or, in DDM architecture terminology,it is a client manager of class FILE.

A similar approach was taken with the Systern/38and the AS/400, except that these systems supportmultiple user libraries and allow a remote file tobe addressed from any of them. In these systems,a special type of system object, called a DDM File,is created in a library to contain the real name ofthe file and communications information. Theseobjects also act as file surrogates.

In contrast, the DDM/PC and PC Support productstook the view that they were primarily acting asclients attached to known hosts. Therefore, it wasonly necessary to redirect requests to the correctserver. The name specified by an application pro-gram is then just a drive letter, indicating the re-mote host system, followed by the server systemname. Although the concept of a client file sur-rogate is a bit vague in this approach, it is none-theless implicit.

These approaches all serve to provide address-ability to a remote file. It is a programmer's oradministrator's responsibility to set up conditionscorrectly so that needed remote files can be lo-cated. But such approaches clearly have limits.

First, these approaches ignore the problems thatarise because new files are created and old filesare deleted, renamed, and moved to differentservers for a variety of application reasons. Ex-cept for relatively static applications, maintainingfile surrogates in the servers of a distributed sys-


tem can quickly become a major usability prob-lem. A variety of solutions have been devised fordealing with this problem:

• The IBM Enhanced Connectivity Facilities(ECF) product, which implemented a client/server architecture, provided name-mappingservices. Given that a client workstation couldonly be attached to a limited number of hostservers of known types, it is possible to mapclient names to host names for a broad range ofnames. The OS/2 name a:FLOWERS. SCR, forexample, can be mapped to the VM/CMS nameFLOWERS SCRIPT A. But this approachclearly has limited scope.

• The Andrew File System (AFS)14 has taken amore comprehensive approach. AFS provideshierarchical directories that allow the namespace to be of indefinite size and depth. Thisname space is mapped over all AFS file serversgiving all clients the ability to locate any An-drew file. Communications between AFS clientsand servers, along with caching and other op-timizations, are required to provide directoryservices with good performance. In broadterms, the same approach is also being taken byOpen Systems Interconnection (OSI) directoryservices and the X.SOO network interface stan-dard. By making the assumption that the lowestlevels of a qualified name actually specify a lo-cal name, this approach allows the local direc-tory services of each system to become a partof the encompassing distributed, hierarchicaldirectory.

A second problem with the approaches taken byearly DDM architecture products is that it is notpossible to work with the directories on remoteservers; that is, to list their entries, create anddelete subdirectories, or establish a current di-rectory to shorten the length of transmittednames. Given the range of directory systemsfound on IBM systems, it is clear that many ofthese services cannot be supported. However, itis possible to adopt a general hierarchical modelof directories and allow each server to supportwhatever common services it can. In Level 2 ofDDM architecture, such a hierarchical directorymodel was added. Because transparent support ofPC-DOS and OS/2 interfaces was considered crucialto the PC Support products, the DDM architecturedirectory model and its capabilities were based onthose of PC-DOS and OS/2. This still does not pro-vide the level of distributed directory support that

IBM SYSTEMS JOURNAL, VOL 31, NO 3. 1992

has been pioneered by AFS and should be addedto DDM architecture. Clearly it is needed.

Lock manager. When an application programopens a file, there is always the possibility thatsome other application program has alreadyopened it or will open it while the first program isstill using it. The potential exists, therefore, forprograms to interfere with one another's use ofthe file and to corrupt one another's data. Toavoid these problems, each system providessome level of concurrency control that serializesthe use of a file or parts of a file by multiple ap-plications. In general, control is in the form oflocks that are requested on a file prior to its useand that are released afterward.

If one client has a lock on a file and another clientrequests a lock, the requested lock mayor maynot conflict with the locks already held. If there isno conflict, the lock is granted; otherwise, therequester must wait for the lock. But waiting forlocks leaves open the possibility of deadlocks oc-curring. To prevent deadlocks, DDM architecturerequires lock requests to time-out, that is, to failafter a period of time determined by each server.

The lock manager of a server is the DDM archi-tecture abstraction of local system concurrencycontrol facilities. Whereas relational databasesprovide their own concurrency control for theirinternal resources, files and other resources typ-ically depend on a system concurrency controlfacility.

Recovery manager. It is one thing to access andmanage remote files and databases, but quite an-other to do so in support of complex applicationtransactions that can update multiple files and da-tabases in a variety of systems. Each transactionmust be completed successfully or all of its effectson all files and databases must be backed out. Nodata can be allowed to remain in a file or databasein a partially updated, inconsistent form.

The recovery manager of DDM architecture isbased on whatever local facility each system pro-vides for transaction commitment or rollback. Nospecial flows are defined in DDM architecture forthese operations. Instead, these operations aremanaged by the sync point manager of the com-munications facility. The purpose of the recoverymanager is to allow the semantics of recovery

DEMERS ET AL. 477

operations on files and databases to be correctlydefined in the architecture.

System command processor. Each system onwhich a DDM architecture server product is im-plemented provides many more services than areavailable through DDM architecture messages.These services are requested through commandlanguage statements unique to that system. Forexample, through AS/400 commands, operationson jobs, spooling queues, and user profiles can berequested, none of which is yet covered by DDMarchitecture. Other systems have many similarservices, but there is no common command lan-guage syntax for requesting them. DDM Level 4architecture allows a client to submit commands,in the syntax of the command language of a spe-cific system, to a remote server. A client systemcommand processor sends the command to thesystem command processor of the remote serverfor execution.

Here DDM architecture provides a common modelof system command processing but not of the ex-ecution of any particular commands. It is cer-tainly contrary to the concept of a single systemimage but is of great use when a client knows whattype of server it is using, which is often the case.As products identify a need for a single systemimage in a given area, DDM architecture can beformally enhanced to meet that need.

Agents. As shown in Figures 11 and 12, agentshave several functions, but they can be viewedprimarily as message routers. In a client, an agentroutes a request for services to a communicationsmanager and routes responses back to the re-questing resource or access manager. In theserver, an agent routes requests to a resource oraccess manager and routes responses back to acommunications manager.

Agents also represent an application programwithin a DDM architecture client or server. A cli-ent agent keeps track of the access paths thathave been opened by its application to variousresources and knows which communicationsmanagers have outstanding requests pending re-sponses. A server agent also keeps track of pathsopened by its application and represents its ap-plication in regard to security and concurrencyconsiderations. Together, they perform variouscleanup and recovery functions in cases of com-munications failures or failures in the application.

478 DEMERS ET AL.

Communications managers. When one servercommunicates with another server, the program-ming interfaces provided by local communica-tions facilities must be used to initiate communi-cations, send messages, receive messages, andeventually to terminate communications. Theprogramming interfaces defined for SNA LV 6.2communications facilities, for example, are richin options, supporting a wide variety of commu-nications requirements, and can be used in manydifferent ways. The designers of a distributed ap-plication are free to use whatever communica-tions capabilities they want. But to achieve con-nectivity among DDM architecture clients andservers implemented in a variety of products,communications must be tightly and specificallydefined. That is, only certain communications ca-pabilities can be used, in only predefined ways, insupport of predefined protocols. Otherwise, theclient and server simply do not understand eachother.

Two principles that have guided DDM architecturecommunications usage are the following:

1. Only a small number of protocols are neces-sary to support the communications require-ments of a wide range of distributed services.

2. If each protocol is kept relatively simple, it canbe mapped to a wide variety of different com-munications facilities.

The DDM architecture communications managersthat have been defined are the following, but thisshould not be viewed as an exhaustive list.

• SNA LV 6.2 conversational: This communica-tions manager defines how the basic DDM ar-chitecture conversational protocol should beimplemented when using SNA LV 6.2 conversa-tions. It is a straightforward I speak and youlisten, and then you speak and I listen protocol.The client sends commands and data to theserver; the server executes the commands andthen returns reply messages and data to the cli-ent.

• SNA LV 6.2 multitasking: This communicationsmanager also defines how the basic conver-sational protocol is implemented when usingSNA LV 6.2 conversations but adds the ability tomultiplex concurrent conversations for severaltasks onto a single SNA LV 6.2 conversation.


Figure 11 Agent routing to resource and access managers

APPLICATION PROGRAM A

ACCESS ACCESSPATH 1 PATH 2TO FILE X TO FILE X

CLIENT SERVER

CLIENT FILE CLIENT FILE SERVER FILE SERVER FILEACCESS ACCESS ACCESS ACCESSMANAGER MANAGER MANAGER MANAGERPATH 1 PATH 2 PATH 1 PATH 2

1 1 11 •

1 1CLIENT CLIENT AGENT SERVER AGENT SERVERFILE X FOR FOR FILE XMANAGER PROGRAM A PROGRAM A MANAGER

CLIENT CLIENTCOMMUNICATIONS COMMUNICATIONSMANAGER FOR A MANAGER FOR A

LOCAL SNA LU 6.2 SNA LU 6.2 FILE XFILES COMMUNICATIONS COMMUNICATIONS

FACILITY FACILITY

Products are free to define whatever additionalcommunications managers are required for thenetwork protocols they have available. For ex-ample, DDM architecture communications couldbe implemented using the Remote Procedure Call(RPC) facility of the Open Software Foundation'sDCE instead of SNA LV 6.2.


The Object Layer. Although all entities of DDMarchitecture are objects (that is, instances ofclasses), the entities in the Object Layer arecalled objects because they closely resemble theobjects found in object-oriented programming en-vironments with dynamic binding, such as Small-talk. In this layer, an object is a self-identifying

DEMERS ET AL. 479

Figure 12 Agent routing to communications managers

I---SERVER

SERVERACCESS

APPLICATION PROGRAM A MANAGERPATH2

ACCESS ACCESS

f 1PATH1 PATH2TOFILEY TO FILEX

~SERVER SERVERAGENTA FILEXPATH2 MANAGER

CLIENT,

CLIENT CLIENTACCESS ACCESS SERVERMANAGER MANAGER COMMUNICATIONSPATH1 PATH2 MANAGER PATH2•

J t

1 ~

! TCP/IP FILE X

CLIENT CLIENT CLIENT .....-~FILEY FILEX AGENT

FORA

f! SERVER

CLIENT CLIENTSERVERCOMMUNICATIONS COMMUNICATIONS

MANAGER MANAGER ACCESSPATH1 PATH2 MANAGER

PATH1..f 1I

! lLOCAL SNALU 6.2 TCP/IP SERVER SERVERFILES AGENTA FILEY

r PATH1 MANAGER

SERVERCOMMUNICATIONSMANAGERPATH1

f~

SNALU6.2 FILEY

480 DEMERS ET AL. IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992

Figure 13 DDM architecture objects

A MANAGER MEMORY SPACE

A

LENGTH

-+ I

-+ C

-+ D

-+ B

B

LENGTH

-+ J

NUMBER

cLENGTH

-+ K

FIELDMARRAYNSTRUCTUREPFIELDQ

D

LENGTH

-+ L

LONGSTRING

E

LENGTH

-+ J

NUMBER

F G

LENGTH LENGTH

-+ L -+1LONG -+ HSTRING

-+ F

-+ E

H

LENGTH

-+ K

FIELDMARRAYNSTRUCTURE PFIELDQ

DDMARCHITECTURE CLASSDICTIONARY

J K L

LENGTH

-+ CLASS

CLASSDESCRIPTION

LENGTH

-+ CLASS

CLASSDESCRIPTION

LENGTH

-+ CLASS

CLASSDESCRIPTION

LENGTH

-+ CLASS

CLASSDESCRIPTION

data structure. Each object specifies the followingabout itself:

• Its total length in bytes• The identifier of its class• Its data variables

Only three kinds of DDM architecture objects arein this layer, as shown in Figures 13 and 14:

• Simple scalars, which contain only a single in-stance of a DDM architecture data class, such asa single number or a single character string.


DDM architecture attributes, such as theLENGTH attribute, are simple scalars, consistingof their length, class identifier, and the datavalue of the attribute. The memory space for-mat and data stream format of simple scalarsare the same.

• Mapped scalars, which contain a sequence ofinstances of the data classes. Records are anexample of mapped scalars, consisting of theirlength, class identifier, and a sequence of datavalues. The memory space format and datastream format of mapped scalars are the same.

• Collections, which contain a sequence of ob-

DEMERS ET AL. 481

Figure 14 DDM architecture object interchange format

INTERCHANGE DATA STREAM FORM OF OBJECT A

LENGTH OF A CLASS ICODEPOINT

NOTE: LENGTH OF A INCLUDES TOTALLENGTH OF THE DATA STREAMREPRESENTING A AND ALL OF ITSCOMPONENT OBJECTS

LENGTHOFC CLASSK FIELDM ARRAYN STRUCTURE P FIELDQCODEPOINT

LENGTHOFD CLASS L LONG STRINGCODEPOINT

LENGTHOFB CLASSJ NUMBERCODEPOINT

jects or collections of objects. DDM architecturecommands and reply messages are examples ofcollection objects. There are two formats forcollections, a memory space format and a datastream format. In the memory space format,each variable of a collection is actually a pointerto an object of the collection. For example, col-lectionA contains pointers to the mapped scalarC, the simple scalar D, and the simple scalar B.In the data stream format, the tree structure ofcollection A has been linearized. The length ofcollectionA now includes the sum of the lengthsof the scalars C, D, and B, and the pointers ofA have been replaced by full copies of the sca-lars C, D, and B.

DDM architecture defines many subclasses ofthese kinds of objects. Although there have beenmany temptations to define classes of objects thatare a hybrid of mapped scalars and collections(structures containing both scalar values andpointers to other objects), the DDM architectshave, so far, resisted doing so. The marginal gainsin efficiency that can be obtained have not beenconsidered worth the tradeoff of increased com-plexity.

482 DEMERS ET AL.

In the abstract model of DDM architecture, man-agers store information as objects and communi-cate by exchanging objects. Within a client orserver, the memory space format of objects isused, and between clients and servers, the datastream format is used. Consider, for example, thecreation of DDM architecture commands in re-sponse to a service request through a local inter-face. First, objects are individually created in amemory space for each command, parameter,and data item to be transmitted. The values of thevariables of collection objects, such as com-mands, point to other objects. The result is aneasily processed structure of objects linked bypointers. This structure is passed through a clientagent to a client communications manager, whichlinearizes it in a data stream. The communica-tions manager of the receiving server reversesthis process to recreate linked objects in a servermemory space that can be easily processed by theserver's agent, resource managers, or accessmanagers.

The key advantages of this approach are that onlythe communications managers need be concernedwith building or parsing linearized data streams


and that many different forms of linearized datastreams can be used. One such form is defined byDDM architecture, but as an alternative, the BasicEncoding Rules of OSI could also be used.

The Data Layer. Each type of system supports anumber of ways of representing data of differenttypes. For example, Personal System/2* comput-ers support ASCII character data encodings, byte-reversed two's complement binary numbers, andIEEE (Institute of Electrical and Electronics En-gineers) floating-point numbers. In contrast, aSystem/390* supports EBCDIC character data en-codings, two's complement binary numbers, andhexadecimal floating-point numbers. Fundamen-tal to communications between systems is estab-lishing how each type of data is to be represented.Several approaches to this problem have beentaken.

The first is to convert all data to or from a ca-nonical form that is used primarily for communi-cations. This approach was taken by the BasicEncoding Rules of OSI as the concrete represen-tation of its Abstract Syntax Notation 1 (ASN.l).In general, this approach requires all data items toalways be converted twice, once from the datarepresentations of the client to the canonicalform, and then from the canonical form to therepresentations of the server system. These con-versions are performed whether or not the clientand server systems are of the same type or haveany representations in common.

The OSI approach does achieve universal connec-tivity, but only if both the sending and receivingapplications agree on what data are being trans-mitted. OSI assumes that ASN.l descriptions of thetransmitted data are separately communicatedbetween the programmers of the sending and re-ceiving applications. It is then up to the program-mers to include the necessary conversions in theircommunicating applications.

A second approach is based on the fact that foreach type of data only a small number of differentrepresentation schemes are commonly used.Therefore, a flag can be sent from the client sys-tem to the server system, identifying whichschemes the client system will use for each type.Where the client and the server use the samescheme, no conversions are required. Otherwise,conversions need be performed only once by the


server system. This general approach has beenadopted by the Open Software Foundation's DCEfor remote procedure calls. As with the OSI ap-proach, a separate flow of information is requiredbetween the programmers of the sending and re-ceiving applications. For DCE, a file containingNetwork Interface Description Language, essen-tially enhanced C-Ianguage data declarations,must also be transmitted.

A third approach simply acknowledges that alldata have to be represented according to somescheme, and if all senders and receivers use thesame scheme, only some conversions will be re-quired some of the time. The key is to pick therepresentation schemes that are most frequentlyused in order to minimize the number of conver-sions performed.

The primary products involved in the definition ofDDM architecture (in 1982) were the System/36,System/38, and System/370*. Most of the datarepresentation schemes used by these systemsare identical, and DDM architecture was not con-cerned with those data types that were not, suchas the floating-point formats. But along came theDDM/PC and PC Support products which use dif-ferent schemes for binary numbers and characterdata. In order to communicate with the Sys-tem/36, System/38, and System/370 DDM archi-tecture products, the PC products were forced toconstruct and parse objects according to the rep-resentations previously chosen by DDM architec-ture.

Given the DDM architecture two-step model oftranslating programming interfaces to data streamstructures (see the previous subsection), the PCproducts are able to create objects whose valuesare represented according to PC representations.The client communications manager can thenconvert them, as needed, to the representationsrequired by DDM architecture. But it would alsobe possible to enhance the architecture along thelines of the DCE approach. If this were done, a flagsent by the client to the server could identify therepresentation schemes to be used, thereby al-lowing DDM architecture objects to be transmittedin whatever way the communicating serverschoose. In particular, it would allow like systems,such as an OS/2 client and an OS/2 server, to com-municate using their native representationschemes.

DEMERS ET AL 483

The approach used by DDM architecture workswell for objects defined by the architecture, but itignores mapped scalars that contain applicationdata, such as file records, which DDM architecturetreats as streams of undefined bytes. There is no

Distributed relational databasesupport in Level 3 of OOMarchitecture addresses data

representations and anynecessary conversions.

way for DDM architecture products to know whatthese data look like or to know how the data arewanted. Any necessary conversion of these datais a responsibility of the requesting applicationprogram.

With the introduction of distributed relational da-tabase support in Level 3 of DDM architecture,this situation changed. Clearly, the client andserver database managers each know their rep-resentations of the SQL data types, and conver-sions can be performed by either server if de-scriptions of these data are also transmitted. TheIBM Formatted Data:Object Content Architecture(FD:OCA) was selected by the Distributed Rela-tional Database Architecture to convey this de-scriptive information. Previously defined as ameans of describing tabular data included in doc-uments, FD:OCA was well-suited to describing tab-ular relational database data. New DDM architec-ture objects were defined to carry FD:OCA datastreams between the client and server SQL appli-cation (access) managers, which performed anynecessary conversions.

The approach being considered for describing andconverting file records is discussed in References10 and 11.

PrOduct-unique extensions

File and relational database managers of DDM ar-chitecture define standardized models of data

484 DEMERS ET AL.

management. DDM architecture also defines ab-stract services to complement these models anddefines common data stream structures for thecanonical representation of data objects, com-mands, and replies.

This framework has also been designed to supportextensions to DDM architecture for homogeneousproduct connectivity. Any extensions that per-tain to multiple products are candidates for thedevelopment of standardized DDM architecture.But other requirements are unique to single prod-ucts, especially requirements for horizontal prod-uct growth or function distribution. Althoughproduct-unique extensions are not candidates forstandardization, architectural definition, by theproduct, is still required.

In both cases, the framework of existing DDM ar-chitecture classes can be used as the basis forextensions to the architecture. DDM architectureallows the following types of product-unique en-hancements:

• Whole new classes of managers (such as librar-ies or mailboxes) can be defined, either withnew commands and replies unique to the classor reusing DDM architecture commands and re-plies as appropriate.

• The function of DDM architecture managers canbe enhanced by defining new commands for aclass.

• New parameters can be added to existing DDMarchitecture commands.

• New values can be defined for existing DDM ar-chitecture parameters.

A good example of product-unique extensions isprovided by the AS/400. When connected to a non-AS/400 server, an AS/400 server complies strictlywith DDM architecture. But when connected to anAS/400 server, a wide variety of extensions areused to make the full function of the data man-agement system of the AS/400 available to remoteAS/400 users, including many capabilities not cov-ered by DDM architecture.

DDM architecture and internationalstandards

The International Organization for Standardiza-tion (ISO) has defined an evolving set of standards


for OSI. The OSI standards are formulated arounda powerful, seven-layer framework whose pur-pose is to allow venders to mix and match imple-

The DDM architecture fits intothe ISO standard in the Open

Systems Interconnection layer 7,which is the application layer.

mentations of each layer and thereby achieveinterconnectivity among their various implemen-tations.

How does IBM's DDM architecture fit into thisframework? The simple answer is that all of thearchitecture fits into the OSI layer 7, the applica-tion layer. As mentioned previously, DDM archi-tecture was designed to be independent of thecommunications facilities that are used to actu-ally transmit messages between systems. Wehave even noted that OSI's Basic Encoding Rulescould be used to encode messages in DDM archi-tecture.

But what about the OSI File Transfer, Access, andManagement (FTAM) standard that appears to bein competition with the file support of DDM ar-chitecture in layer 7? A comparison of the filemanager classes of DDM architecture with FTAMshows that they are actually complementary andnot really in competition, since they were de-signed to meet different requirements. For DDMarchitecture, the prime requirement was an abil-ity to provide local or remote transparency to ex-isting application programs and file systems. ForFTAM, the prime requirement was to define a pow-erful new file model for use by new applicationsin accessing new file systems. As an internationalstandard, FTAM certainly sets a goal for long-termfile system revolution, but not evolution, as doesDDM architecture.

Since IBM has committed to supporting OSI on itsSAA systems, a challenge to DDM architecture is tointegrate the FTAM file models into the DDM ar-


chitecture framework, and for DDM architectureto make use of OSI level 6 communications facil-ities.

Summary

As discussed in this paper, DDM architecture is aframework for distributed application services.Multilayered and object-oriented, DDM architec-ture has defined a variety of distributed file andrelational database services that can be providedover many different communications facilities.These services have evolved as a series of pub-lished levels of the architecture was developed.The openness of the DDM architecture frameworkinvites the addition of a wide range of additionaldistributed application services.

Acknowledgments

When as many people have worked on a projectas have worked on DDM architecture and its im-plementations, it is impossible to acknowledgethem all. However, special acknowledgmentmust be given to John L. Bondy, the IBM managerwho encouraged the DDM architects to exploreinnovative approaches to software architecture.

Appendix: Products using DDM architecture

The specifications of DDM architecture have beenused to build and deliver a variety of IBM productsallowing users to access and manage distributedfiles, including:

• System/36 System Support Program Distrib-uted Data Management

• System/38 Control Program Facility Distrib-uted Data Management

• Operating System/400 Distributed Data Man-agement

• The DDM/PC and NetView/PC* client productsfor PC-DOS systems

• The CICS/DDM server product for use under theIBM Customer Information Control System (forboth Multiple Virtual Storage and Virtual Stor-age Extended) 15

• PC Support/36 and AS/400 PC Support client/server products

• 4680 Store Systems Distributed File Manage-ment

New products are under development to extenddistributed file services to:

DEMERS ET AL. 485

• Operating System/2 Distributed File Manage-ment (OS/2 DFM)

• MVS/ESA Distributed File Management (MVSDFM)

• VM/ESA Distributed File Management (VM DFM)

Additional IBM products will provide distributedrelational database services to users of:

• DATABASE 2 (MVS DB2*)• Structured Query Language/Data System

(SQUDS*)• OS/2 Extended Services Database Manager

(OS/2 DBM)• RISC System/6000* Advanced Interactive Ex-

ecutive* (AIX*)

'Trademark or registered trademark of International BusinessMachines Corporation.

"Trademark or registered trademark of Microsoft Corpora-tion, Digitalk, Inc., Xerox, Inc., the Open Software Founda-tion, or UNIX Systems Laboratories, Inc.

Cited references1. R. A. Demers, "Distributed Files for SAA," IBM Sys-

tems Journal 27, No.3, 348--361 (1988).2. R. Reinsch, "Distributed Database for SAA," IBM Sys-

tems Journal 27, No.3, 362-369 (1988).3. IBM Distributed Data Management Architecture: Imple-

mentation Programmer's Guide, SC21-9529-03, IBMCorporation; available through IBM branch offices.

4. SNA Transaction Programmer's Reference Manual forLU Type 6.2, GC30-3084, IBM Corporation; availablethrough IBM branch offices.

5. IBM Distributed Relational Database Architecture Ref-erence, SC26-4651, IBM Corporation; available throughIBM branch offices.

6. J. P. Gelb, "System-Managed Storage," IBM SystemsJournal 28, No.1, 77-103 (1989).

7. P. Wegner, "Concepts and Paradigms of Object-OrientedProgramming," OOPS Messenger I, No.1, 7-87 (August1990).

8. IBM Distributed Data Management Architecture: Refer-ence Manual, SC21-9526-03,IBM Corporation; availablethrough IBM branch offices.

9. A. Goldberg and D. Robson, Smalltalk-80: The Languageand Its Implementation, Addison-Wesley Publishing Co.,Reading, MA (1983).

10. R. A. Demers and K. Yamaguchi, "Data Description andConversion Architecture," IBM Systems Journal 31, No.3, 488--515 (1992, this issue).

11. IBM Distributed Data Management Architecture: Spec-ifications for A Data Language, SC21-8286, IBM Corpo-ration; available through IBM branch offices.

12. Formatted Data Object Content Architecture Reference,SC31-6806, IBM Corporation; available through IBMbranch offices.

13. Character Data Representation Architecture Level 1,Reference, SC09-1390, IBM Corporation; availablethrough IBM branch offices.

486 DEMERS ET AL.

14. 1. H. Morris, M. Satyanarayanan, M. H. Conner, J. H.Howard, D. S. H. Rosenthal, and F. D. Smith, "Andrew:A Distributed Personal Computing Environment," Com-munications oftheACM29, No.2, 184--201 (March 1986).

15. K. Deinhart, "SAA Distributed File Access to the CICSEnvironment," IBM Systems Journal 31, No.3, 516-534(1992, this issue).

Accepted for publication March 6, 1992.

Richard A. Demers 110 Salem Point SfY, Rochester, Min-nesota 55902. Mr. Demers is a consultant on software archi-tecture. In 1968he joined IBM as an applications programmerin White Plains, New York. He received a B.A. degree inphilosophy from Canisius College in 1969. In 1972, he movedto Endicott, New York, where he worked on systems softwarefor the IBM 3895 Optical Check Reader. Mr. Demers movedto Rochester in 1975 to design the message handling and ser-vice components of the System/38 operating system. From1982to 1991, he was the lead architect in the design of IBM'sDistributed Data Management (DDM) architecture, partici-pated in the design of IBM's Distributed Relational DatabaseArchitecture (DRDA), and was the lead architect for IBM'sdata description and conversion architecture. He has receivedIBM Outstanding Innovation Awards for his work on DDMarchitecture (1987) and DRDA (1991). A member of the As-sociation for Computing Machinery, his professional interestsinclude operating systems, distributed processing, data man-agement, programming languages, and object-oriented pro-gramming.

Jan David Fisher IBM Application Business Systems, 3605Highway 52 North, Rochester, Minnesota 55901. Mr. Fisheris a senior programmer in the Rochester programming labo-ratory. He has been with IBM for 27 years. He joined theWichita, Kansas, IBM branch office as a systems engineer,then moved to Rochester to join the Plastics CompetencyCenter (IBM System/7s and plastic injection molding ma-chines). He also worked in the Rochester Marketing SupportCenter and System/34, System/36 planning organization as thecommunications software product planner. He joined the Dis-tributed Data Architecture Department in 1985 as a seniorplanner and later became the team leader of the architectsworking on the Distributed Data Management architecture.Mr. Fisher graduated from Purdue University with a B.S.E.E.in 1965,and has been taking graduate courses. He is a memberof Toastmasters International, and his interests include bothhistory and science fiction. He is a judge for Odessey of theMind.

Sunil S. Gaitonde IBM Application Business Systems, 3605Highway 52 North, Rochester, Minnesota 55901. Dr. Gai-tonde is an advisory programmer working on the operatingsystem of the AS/400. He received his bachelor's degree fromthe Indian Institute of Technology, Kharagpur, India in elec-trical engineering and holds a master's degree and Ph.D. incomputer engineering from Iowa State University. He joinedIBM at Rochester in 1988. Dr. Gaitonde worked on the Dis-tributed Data Management architecture to extend it to supportIBM's Distributed Relational Database Architecture. His cur-rent focus is on the Open Software Foundation's Distributed


Computing Environment. His interests include operating sys-tems, computer network protocols, and object-oriented pro-gramming languages.

RichardR.SandersIBMApplication Business Systems, 3605Highway 52 North, Rochester, Minnesota 55901. Mr. Sandersis a senior programmer in the AS/400 Data Management De-sign Control group. He was an architect of the DistributedData Management (DDM) architecture for over five years andspent over two years as the AS/400 representative to the Dis-tributed Relational Database Architecture (DRDA). He hasreceived two IBM Outstanding Technical AchievementAwards for his contributions to DDM and DRDA. Mr. Sand-ers received a B.S. in computer science and mathematics fromMankato State College in 1972. He joined IBM in Rochesterin 1977.

Reprint Order No. G321-5482.

IBM SYSTEMS JOURNAL, VOL 31, NO 3, 1992 DEMERS ET AL. 487

Documents

Inside IBM's Distributed Data Management architecture