Distributed Data Management Architecture
Defined in the period from 1980 to 1993, DDM specifies necessary components, messages, and protocols, all based on the principles of object-orientation.
Other communications between mainframes was also in terms of fixed connections used by software defined for specific purposes.
The idea of distributed operating system services was then revived as the Golden Gate project and an attempt made to justify its development.
This attempt also failed; the whole idea of distributed services was too new for IBM product planners to be able to quantify the value of software that interconnected heterogeneous computers.
However, one Golden Gate planner, John Bondy, remained convinced and persuaded management to create a department outside of the normal control of the Rochester laboratory so that there would be no immediate need for a predefined business case.
During this period, Demers designed an architectural model of DDM clients and servers, of their components, and of interactions between communicating computers.
Further, he defined a generic format for DDM messages based on the principles of object-orientation as pioneered by the Smalltalk programming language and by the IBM System/38.
After a year of failure to sell the idea of DDM to other IBM system houses, Lawrence's arguments prevailed.
This broadened the scope of DDM record-file support to meet many of the requirements of the System/38's advanced file system.
Jan Fisher and Sunil Gaitonde did most of the architecture work on DDM support for directories and stream files.
Scientists at IBM's Almaden Research Laboratory had developed System/R*, a prototype of a distributed RDB and they felt it was now time to turn it into marketable products.
Roger Reinsch from the IBM Santa Theresa Programming Center lead a cross-product team to define a Distributed Relational Database Architecture (DRDA).
Both DDM and DRDA were designated as strategic components of IBM's Systems Application Architecture (SAA).
The Distributed File Management (DFM)[8] project was initiated to add DDM services to IBM's MVS operating system to enable programs on remote computers to create, manage, and access VSAM files.
John Hufferd, the manager of the DFM project looked to the DDM Architecture team for a means of converting the data fields in records as they flowed between systems.
The above diagram illustrates the roles of DDM clients and servers in relation to local resources.
This straightforward technique is used for all objects transmitted between client's and servers, including commands, records, and reply messages.
All of these linearized objects are put into envelopes that enable the client and server agents to coordinate their processing.
The subclasses of DDM class Class are described by variables that specify These objects can contain references to other named objects in text and specifications, thereby creating hypertext linkages among the pages of the DDM Reference Manual.
Multiple instances of access methods can be opened on a file at the same time, each serving a single client.
Stream-oriented files consist of a single sequence of bytes on which programs can map application data however they want.
Multiple instances of the Stream access method can be opened on a file at the same time, each serving a single client.
Using DDM client and server products, a program can create, delete and rename directories in a remote computer.
An interactive user or program can issue SQL statements to a RDB and receive tables of data and status indicators in reply.
The Distributed Relational Database Architecture (DRDA) fits nicely into the overall DDM framework, as discussed in Object-Orientation.
The DDM manager-level objects supporting DRDA are named RDB (for relational database) and SQLAM (for SQL Application Manager).
Without recompilation, it should be possible to redirect existing application programs to the data management services of a remote computer.
Further complexity arose because of the ways in which various programming language compilers map record fields onto strings of bits, bytes, and words in memory.
The key issue is obtaining sufficiently detailed record descriptions, but record descriptions are generally specified abstractly in application programs by declaration statements defined by the programming language, with the language compiler handling encoding and mapping details.
In a distributed processing environment, what is needed is a single, standardized way of describing records that is independent of all programming languages, one that can describe the wide variety of fixed and varying length record formats found in existing files.
