Arquitectura de gestión de datos distribuidos

La arquitectura de red de sistemas (SNA) de IBM se diseñó inicialmente para permitir la conexión jerárquica de estaciones de trabajo a ordenadores centrales de IBM. Las redes de comunicación disponibles en aquel momento estaban rígidamente diseñadas en términos de conexiones fijas entre un ordenador central y su conjunto de estaciones de trabajo, las cuales estaban bajo el control total del software del ordenador central. Otras comunicaciones entre ordenadores centrales también se realizaban mediante conexiones fijas utilizadas por software definido para fines específicos. A medida que las redes de comunicación se volvieron más flexibles y dinámicas, se hizo deseable la comunicación genérica entre pares , en la que un programa en un ordenador pudiera iniciar e interactuar con un programa en otro ordenador.

Cuando a principios de la década de 1980 se definió la arquitectura APPC ( Advanced Program to Program Communications ) de IBM , también se hizo evidente que APPC podía utilizarse para proporcionar servicios de sistema operativo en ordenadores remotos. Un grupo de trabajo de SNA exploró esta idea y describió varios servicios distribuidos posibles, como servicios de archivos, servicios de impresión y servicios de consola del sistema, pero no logró iniciar el desarrollo del producto. El software APPC aún no estaba disponible para mainframes y, más concretamente, estos todavía se consideraban principalmente sistemas independientes. En consecuencia, el grupo de trabajo de SNA suspendió el desarrollo de servicios distribuidos.

Los miembros del grupo de trabajo SNA del laboratorio de desarrollo de IBM en Rochester, Minnesota, estaban convencidos de que existía una justificación comercial para los servicios distribuidos entre los sistemas informáticos de gama media producidos en Rochester. Se había implementado una forma primitiva de servicios de archivos distribuidos, denominada Distributed Data File Facility (DDFF), para conectar los miniordenadores IBM System/3 , IBM System/34 e IBM System/36 . Además, los ordenadores IBM System/36 e IBM System/38 se vendían a clientes en grandes cantidades, y existía una clara necesidad de permitir, por ejemplo, que los ordenadores de la sede central de una empresa interactuaran con los ordenadores de sus distintos almacenes. APPC se implementó en estos sistemas y fue utilizado por diversas aplicaciones de clientes. La idea de los servicios de sistemas operativos distribuidos se retomó entonces con el proyecto Golden Gate y se intentó justificar su desarrollo. Este intento también fracasó; la idea de los servicios distribuidos era demasiado novedosa para que los planificadores de productos de IBM pudieran cuantificar el valor del software que interconectaba ordenadores heterogéneos.

Sin embargo, John Bondy, planificador del Golden Gate , se mantuvo firme en su convicción y persuadió a la dirección para que creara un departamento fuera del control habitual del laboratorio de Rochester, de modo que no fuera necesario un plan de negocio predefinido. Además, limitó su misión a brindar soporte únicamente para la Gestión de Datos Distribuidos (DDM), en particular, para archivos orientados a registros . Posteriormente, convenció a Richard A. Demers, un experimentado arquitecto de software, para que se uniera a él en la tarea de definir la arquitectura DDM y presentar la idea de DDM a las empresas de sistemas de IBM.

El primer año de este esfuerzo resultó en gran medida infructuoso, ya que las empresas de sistemas IBM seguían exigiendo estudios de viabilidad por adelantado e insistían en formatos de mensajes isomorfos a las interfaces de bloques de control de sus sistemas de archivos locales. Además, a medida que las computadoras personales comenzaron a utilizarse como terminales conectadas a las computadoras centrales, se argumentó que simplemente mejorar el flujo de datos del 3270 permitiría a las PC acceder a los datos de la computadora central.

Durante este periodo, Demers diseñó un modelo arquitectónico de clientes y servidores DDM, de sus componentes y de las interacciones entre ordenadores que se comunicaban. Además, definió un formato genérico para los mensajes DDM basado en los principios de la programación orientada a objetos, tal como lo impulsaron el lenguaje de programación Smalltalk y el IBM System/38. Este modelo dejó claro cómo se podían implementar los productos DDM en diversos sistemas. Véase Cómo funciona DDM .

En 1982, los planificadores del Sistema/36 se convencieron de que existía un mercado suficiente para los servicios de archivos orientados a registros DDM. ^{[ 3 ]}

El formato genérico de los mensajes DDM ya se había diseñado, pero ¿qué mensajes específicos debían definirse? El sistema de archivos System/36 se había definido para satisfacer las necesidades orientadas a registros de los lenguajes de programación de tercera generación (3GL), como Fortran , COBOL , PL/I e IBM RPG , al igual que el sistema de archivos System/38 y el sistema de archivos Virtual Storage Access Method (VSAM) de los ordenadores centrales de IBM. Sin embargo, sus funcionalidades e interfaces reales variaban considerablemente, por lo que ¿qué funcionalidades e interfaces debería admitir la arquitectura DDM? Véase archivos orientados a registros .

El trabajo inicial del proyecto Golden Gate sobre DDM siguió el estándar internacional FTAM ( File Transfer Access and Management ) para archivos distribuidos, pero era muy abstracto y difícil de adaptar a los servicios de archivos locales. De hecho, esta fue una de las barreras para su aceptación por parte de los fabricantes de sistemas IBM. Kenneth Lawrence, el arquitecto de sistemas responsable de los servicios de archivos de System/36, argumentó que sería mejor definir mensajes que al menos un sistema IBM pudiera implementar fácilmente y luego permitir que otros sistemas solicitaran los cambios que necesitaran. Naturalmente, abogó por el soporte de los requisitos de System/36. Tras un año de intentos fallidos por convencer a otros fabricantes de sistemas IBM de la idea de DDM, los argumentos de Lawrence prevalecieron.

Richard Sanders se unió al equipo de arquitectura de DDM y colaboró ​​con Lawrence y Demers para definir los mensajes específicos necesarios para System/36 DDM. El progreso en la definición de DDM impulsó la participación de System/38. Esto amplió el alcance de la compatibilidad con archivos de registro de DDM para satisfacer muchos de los requisitos del avanzado sistema de archivos de System/38.

Los archivos existen en un contexto proporcionado por un sistema operativo que ofrece servicios para organizarlos, compartirlos con usuarios concurrentes y protegerlos contra accesos no autorizados. En el nivel 1 de DDM, el acceso a directorios de archivos remotos no se admitía más allá de la transmisión del nombre completo del archivo que se iba a utilizar. Sin embargo, la seguridad y el uso compartido eran requisitos indispensables. Sanders se encargó del diseño en estas áreas. Sanders también definió protocolos específicos para el uso de las funciones de comunicación, que se incorporaron en un componente llamado DDM Conversational Communications Manager. Inicialmente implementado con APPC, posteriormente se implementó con TCP/IP .

Con la finalización del producto System/36 DDM, Lawrence trabajó con programadores del laboratorio de IBM Hursley Park, Reino Unido, para adaptar gran parte de la programación del servidor System/36 DDM para su uso en el entorno de procesamiento de transacciones del IBM Customer Information Control System (CICS) , convirtiendo así a CICS en un servidor DDM para los sistemas operativos de mainframe MVS y VSE. ^{[ 4 ]} Lawrence también trabajó con programadores del laboratorio de IBM Cary, Carolina del Norte, para implementar un cliente DDM orientado a registros para IBM PC DOS .

El Nivel 1 de la Arquitectura DDM se publicó formalmente en 1986. En el momento de este anuncio, IBM otorgó un Premio a la Trayectoria Técnica Sobresaliente a Kenneth Lawrence, un Premio a la Contribución Sobresaliente a Richard Sanders y un Premio a la Innovación Sobresaliente a Richard Demers.

• En este artículo, System/38 se utilizará de ahora en adelante para referirse al System/38 y sus sucesores: el IBM AS/400 (que fusionó la funcionalidad del System/36 y el System/38), el IBM iSeries y el IBM Power Series ^{[ 5 ]} (que fusionó el iSeries con el IBM RS/6000, la línea de productos de servidores y estaciones de trabajo basados ​​en RISC/UNIX de IBM).

Con la creciente importancia del IBM PC y el sistema operativo Unix en entornos de red, también se necesitaba compatibilidad con DDM para los directorios jerárquicos y los archivos orientados a flujo del IBM Personal Computer con IBM PC DOS y el IBM RS/6000 con IBM AIX (la versión de Unix de IBM). Véase Archivos orientados a flujo .

La arquitectura DDM de nivel 2 se publicó en 1988. Jan Fisher y Sunil Gaitonde realizaron la mayor parte del trabajo de arquitectura para el soporte de DDM para directorios y archivos de flujo.

En 1986, IBM comercializó cuatro productos de bases de datos relacionales (RDB) diferentes, cada uno diseñado para un sistema operativo específico de IBM. Los científicos del Laboratorio de Investigación Almaden de IBM habían desarrollado System/R*, un prototipo de RDB distribuida, y consideraron que había llegado el momento de convertirlo en un producto comercializable. Sin embargo, System/R* se basaba en System/R, un prototipo de investigación de una RDB, y no podía integrarse fácilmente en los productos RDB de IBM. Véase ^{[ 6 ]} para un análisis de las RDB en un entorno de procesamiento distribuido.

Roger Reinsch, del Centro de Programación de IBM Santa Teresa, lideró un equipo multidisciplinario para definir una Arquitectura de Base de Datos Relacional Distribuida (DRDA). Para ello, contó con la colaboración de:

• Representantes de cada uno de los cuatro productos RDB de IBM.
• Bruce Lindsay, investigador de System/R*,
• Paul Roever (del laboratorio de IBM en Sindelfingen, Alemania), quien había desarrollado una especificación para describir datos llamada Formatted Data: Object Content Architecture (FD:OCA).
• Richard Sanders y Richard Demers, del equipo de arquitectura de DDM, se encargaron de definir los modelos, mensajes y protocolos adecuados.

En 1990, la arquitectura DDM de nivel 3 y DRDA ^{[ 7 ]} se publicaron simultáneamente. Tanto DDM como DRDA fueron designados como componentes estratégicos de la arquitectura de aplicaciones de sistemas (SAA) de IBM. DRDA fue implementado por los cuatro productos RDB de IBM y por otros proveedores.

Se entregaron premios a los participantes clave en el diseño de DRDA. Richard Sanders recibió un premio a la Contribución Destacada , y Roger Reinsch y Richard Demers recibieron premios a la Innovación Destacada .

El proyecto de Gestión de Archivos Distribuidos (DFM) ^{[ 8 ]} se inició para agregar servicios DDM al sistema operativo MVS de IBM y permitir que los programas en computadoras remotas crearan, administraran y accedieran a archivos VSAM . John Hufferd, gerente del proyecto DFM, buscó en el equipo de Arquitectura DDM un método para convertir los campos de datos en los registros a medida que fluían entre sistemas. Richard Demers lideró este tema, con la ayuda de Koichi Yamaguchi del proyecto DFM. Véase Descripción y conversión de datos .

Richard Sanders, Jan Fisher y Sunil Gaitonde definieron los siguientes servicios adicionales en la arquitectura DDM de nivel 4:

• Para DFM, gestión de almacenamiento y atributos de archivo definidos por el usuario.
• Para DRDA, protocolos de control de compromiso de dos fases para unidades de trabajo distribuidas dirigidas por la aplicación.
• Las colas se pueden crear, vaciar o eliminar en un servidor remoto. Las entradas de cola son registros definidos por la aplicación que se agregan o se reciben de una cola. Consulte Colas DDM .
• Procesador de comandos del sistema, un gestor al que se pueden enviar para su ejecución los comandos definidos por el sistema anfitrión del servidor.
• Gestor de comunicaciones multitarea, que permite que varios agentes cliente se comuniquen con los agentes servidor correspondientes mediante una única conversación entre los sistemas cliente y servidor.
• El gestor de puntos de sincronización coordina las unidades lógicas de trabajo en varios servidores DDM. Los protocolos de compromiso en dos fases garantizan una recuperación coordinada de los recursos cuando falla alguna unidad lógica de trabajo.

La arquitectura DDM de nivel 4 se publicó en 1992.

El trabajo de arquitectura en el nivel 5 de DDM consistió en brindar soporte para

• Conjuntos de datos particionados de mainframe , que son archivos que constan de un directorio interno y varios miembros; en efecto, son bibliotecas de archivos similares.
• Las bibliotecas de ordenadores personales consolidan el acceso a archivos de varias carpetas en una sola biblioteca.
• Mejoras adicionales para DRDA.

Jan Fisher fue el arquitecto responsable del nivel 5 de DDM, que fue publicado por The Open Group , en lugar de IBM. Poco después, el grupo de arquitectura DDM de IBM fue disuelto.

La arquitectura DDM define un protocolo cliente/servidor; es decir, un cliente solicita servicios a un servidor que interactúa con sus recursos locales para realizar el servicio solicitado, cuyos resultados, datos e indicadores de estado, se devuelven al cliente. El diagrama anterior ilustra las funciones de los clientes y servidores DDM en relación con los recursos locales. (Aquí se utiliza la terminología común de clientes y servidores , pero en la arquitectura DDM, un cliente se denomina Servidor de Origen y un Servidor se denomina Servidor de Destino ).

1. An application program interacts with a local resource, such as a file, by means of programming interfaces provided by a local resource manager (LRM). But if the desired resource is in a remote computer, DDM is used to mediate the interaction. The application program continues to use the interfaces provided by its LRM, but they are redirected to a DDM client. DDM architecture does not specify how this redirection is to occur as it does not support a directory of remote resources. One method of redirection used by several DDM file-oriented products is to have the application open a special local file, called a DDM File by the System/38, that provides location and access information about the remote file. Redirection to the DDM Client then occurs.
2. DDM Architecture defines Manager level entities for files, relational databases, access methods, etc. A Client Resource Manager (CRM) polymorphically supports the functional interfaces defined by the client system's LRM. Its primary function is to generate appropriate linearized DDM command and data objects for each functional interface. (See DDM messages.) These objects are sent to the server resource manager (SRM) of the remote DDM server. Actually, though, they are routed through DDM client and server Agents and Communications Managers.
3. The DDM Client Agent puts a linearized command into an RQSDSS envelope and linearized objects into linked OBJDSS envelopes. (See DDM messages.) The Client Agent interacts with the Server Agent to create a path for the messages it receives from the CRM to flow to the SRM. If the application program needs to interact with only a single remote resource, this is straightforward. However, it is possible for the application program to concurrently interact with multiple resources of varying kinds that reside on multiple remote systems. The Client Agent represents the application program in all cases and routes messages on separate virtual paths to each resource.
4. The Client Communications Manager interacts with the ServerCommunications Manager to implement a conversational protocol of the form "I talk while you listen, and then you talk while I listen." Various telecommunication protocols can be used, including IBM's SNA APPC and the Internet's TCP/IP protocol.
5. DDM messages transmitted to the Server Communications Manager are passed to the Server Agent on the path specified by the message, and it forwards the messages to the SRM on the same path. If the Server Agent is interacting with a single client on a single path, this is straightforward. However, the Server Agent can interact with multiple clients on multiple paths.
6. The Server Resource Manager (SRM) parses DDM messages and determines what it must do to perform the request. It may use one or more of the functional interfaces of the server system's corresponding Local Resource Manager (LRM).
7. El SRM acumula los datos y los indicadores de estado del LRM y genera los objetos linealizados y los mensajes de respuesta correspondientes, que luego transmite al Agente del Servidor.
8. El agente del servidor empaqueta las respuestas y los objetos en sobres RPYDSS y OBJDSS y los reenvía al administrador de comunicaciones del servidor, que a su vez los envía al administrador de comunicaciones del cliente y al agente del cliente por la misma ruta que el comando original.
9. El agente cliente extrae la respuesta y los objetos de sus respectivos sobres RPYDSS y OBJDSS y los transfiere al administrador de recursos del cliente.
10. El Administrador de Recursos del Cliente analiza el objeto devuelto y los mensajes de respuesta, y los asigna según lo previsto por la interfaz funcional del LRM original para su devolución al programa de aplicación.

La arquitectura DDM está orientada a objetos . Todas las entidades definidas por DDM son objetos definidos por objetos de clase autodefinibles . Los mensajes, respuestas y datos que fluyen entre sistemas son objetos serializados. Cada objeto especifica su longitud, identifica su clase mediante un punto de código DDM y contiene datos según lo definido por su clase. Además, su clase especifica los comandos que se pueden enviar a sus instancias cuando un objeto reside en un cliente o servidor DDM, encapsulando así el objeto mediante un conjunto limitado de operaciones.

Estructuralmente, la arquitectura DDM consta de niveles jerárquicos de objetos, donde cada nivel manifiesta propiedades emergentes en niveles cada vez más superiores.

• Un campo es una cadena de bits que codifica un número, un carácter u otra entidad de datos. Las instancias de una subclase de Campo están encapsuladas por las operaciones que puede realizar su clase; por ejemplo, operaciones aritméticas con campos enteros.
• Un objeto es una entidad autoidentificada que consta de uno o más campos encapsulados por un conjunto definido de operaciones. Los objetos de este nivel se inspiraron en las clases de objetos del núcleo del lenguaje de programación Smalltalk ^{[ 9 ].}
  • Un objeto escalar consta de un único campo, codificado y descrito por su clase. Los objetos escalares se utilizan como parámetros de los objetos de comando y respuesta. También se emplean como valores de atributos de objetos, como la longitud de un objeto en la documentación de DDM. Los métodos de codificación utilizados para los valores de estos objetos escalares están completamente definidos por la arquitectura de DDM.
  • Un objeto mapeado consta de uno o más campos, como los de un registro definido por la aplicación. Los métodos de codificación y la alineación de estos campos no están definidos por la arquitectura DDM, sino por las declaraciones del programa de aplicación y los métodos de codificación y alineación de su lenguaje de programación.
  • Un objeto de colección es un contenedor de objetos, tal como lo define la clase de la colección. Ejemplos de objetos de colección son los comandos y respuestas de DDM.
• Un administrador es una entidad autoidentificada que proporciona un entorno para el almacenamiento y procesamiento de objetos. Un administrador está encapsulado por las operaciones definidas por su clase. Juntos, un conjunto de administradores implementa el entorno de procesamiento general de un cliente o servidor DDM. Las entidades de administrador en este nivel se inspiraron en los objetos del sistema del sistema operativo System/38. ^{[ 10 ]} Los administradores definidos por DDM incluyen: Diccionario, Supervisor, Agente, Directorio, Archivo(s), Método(s) de acceso, Base de datos relacional, Administrador de aplicaciones SQL, Cola, Administrador de bloqueo, Administrador de seguridad, Administrador de recuperación, Procesador de comandos del sistema, Administrador(es) de comunicación.
• Un servidor es una entidad que se identifica a sí misma y que proporciona un entorno para el almacenamiento y procesamiento de datos, ya sea como cliente o servidor, en un entorno de procesamiento distribuido. Ejemplos de ello son los clientes y servidores especializados en la gestión distribuida de archivos o bases de datos relacionales distribuidas.

Si bien la arquitectura de DDM es orientada a objetos, los productos DDM se implementaron utilizando los lenguajes y métodos típicos de sus sistemas anfitriones. Object Technology International desarrolló una versión de DDM en Smalltalk para IBM PC , con las clases de Smalltalk correspondientes creadas automáticamente a partir del Manual de Referencia de DDM.

DDM es una arquitectura abierta. Los productos DDM pueden implementar subconjuntos de la arquitectura DDM; también pueden crear sus propias extensiones. ^{[ 11 ]}

El comando DDM 'Atributos del servidor Exchange' es el primero que se envía cuando un cliente se conecta a un servidor. Identifica al cliente y especifica los administradores que necesita, así como el nivel de arquitectura DDM que requiere. El servidor responde identificándose y especificando el nivel de compatibilidad con los administradores solicitados. Por regla general, un producto compatible con el nivel X de un administrador DDM también debe ser compatible con el nivel X-1 para que los nuevos servidores se conecten con clientes más antiguos.

Se pueden implementar subconjuntos de DDM para satisfacer diferentes requisitos del producto:

• como cliente, servidor o ambos. Por ejemplo, DDM/PC es solo un cliente, CICS/DDM es solo un servidor y System/38 DDM es tanto cliente como servidor.
• para admitir gestores específicos, como archivos orientados a registros, archivos orientados a flujos, bases de datos relacionales (como parte de DRDA) o cualquier combinación de estos. Por ejemplo, MVS Database 2 proporciona soporte de cliente y servidor solo para el subconjunto de DDM requerido por DRDA.
• para admitir únicamente determinados comandos de un administrador, como la capacidad de cargar y descargar registros de un archivo secuencial.
• para admitir parámetros seleccionados de un comando, como el parámetro 'Devolver registros inactivos' del comando 'Obtener registro'.

Cuando un cliente DDM se conecta a un servidor DDM conocido, como un cliente System/38 a un servidor System/38, la arquitectura DDM también se puede extender añadiendo

• nuevos gerentes específicos de producto.
• nuevos comandos para un administrador DDM existente.
• nuevos parámetros para un comando DDM o un mensaje de respuesta.

Dichas extensiones pueden definirse dentro del marco orientado a objetos de DDM, de modo que se puedan utilizar las funcionalidades existentes de gestión de mensajes de DDM.

En una implementación puramente orientada a objetos de DDM, los clientes y servidores, junto con todos sus gestores y objetos, existen en un montón de memoria, interconectados mediante punteros (direcciones de memoria). Por ejemplo, un objeto de comando apunta a cada uno de sus objetos de parámetro. Sin embargo, un comando no puede transmitirse de un cliente a un servidor de esta forma; debe crearse una copia isomorfa del comando como una única cadena contigua de bits. En el montón, un comando consta del tamaño del comando, un puntero a su clase y punteros a cada uno de sus objetos de parámetro. Linealizado, el comando consta de la longitud total del comando linealizado, un punto de código que identifica su clase y cada uno de sus objetos de parámetro linealizados. La arquitectura DDM asigna puntos de código únicos a cada clase de objeto. Esta técnica sencilla se utiliza para todos los objetos transmitidos entre clientes y servidores, incluidos comandos, registros y mensajes de respuesta.

Todos estos objetos linealizados se colocan en contenedores que permiten a los agentes cliente y servidor coordinar su procesamiento. En la arquitectura DDM, estos contenedores se denominan Estructuras de Flujo de Datos (DSS). Los comandos se colocan en una DSS de Solicitud (RQSDSS), las respuestas en una DSS de Respuesta (RPYDSS) y otros objetos en una DSS de Objeto (OBJDSS). Solo puede haber un comando en una RQSDSS y una sola respuesta en una RPYDSS, pero se pueden colocar muchos objetos, como registros, en una OBJDSS. Además, se pueden encadenar varias OBJDSS a una RQSDSS o una RPYDSS para acomodar tantos objetos como sea necesario. Una DSS consta de la longitud total de la DSS, un byte indicador que identifica el tipo de DSS, un identificador de solicitud y los objetos linealizados en la DSS. El identificador de solicitud vincula una RQSDSS con las OBJDSS subsiguientes del cliente, como los registros que se cargarán en un archivo mediante el comando Cargar Archivo . El identificador de solicitud también vincula el RQSDSS del cliente con un RPYDSS o los OBJDSS del servidor al cliente.

El Manual de Referencia de DDM ^{[ 12 ] [ 13 ]} consta de objetos con nombre Menu, Help y Class. Las subclases de la clase Class de DDM se describen mediante variables que especifican

• la superclase de la clase. Las clases se definen mediante una jerarquía de herencia; por ejemplo, Archivo de registro es una subclase de Archivo, que a su vez es una subclase de Administrador, y hereda sus datos y comandos. La clase Clase y sus subclases se autodescriben mediante comandos de clase y variables de clase , incluyendo:
• un título que describe brevemente la clase.
• el estado de la clase en relación con el trabajo en curso sobre la arquitectura DDM.
• Texto descriptivo y gráficos que relacionan la clase con sus componentes y su entorno.
• los datos (campos, objetos, administradores, etc.) encapsulados por instancias de la clase.
• los comandos que se pueden enviar a sus instancias.

Estos objetos pueden contener referencias a otros objetos con nombre en el texto y las especificaciones, creando así enlaces de hipertexto entre las páginas del Manual de Referencia de DDM. Las páginas de Menú y Ayuda conforman un tutorial integrado sobre DDM. La versión impresa del Manual de Referencia de DDM Nivel 3 es voluminosa, con más de 1400 páginas, y algo incómoda de usar, pero también se desarrolló una versión interactiva utilizando las herramientas de comunicación internas de IBM. Dada la velocidad relativamente lenta de dichas herramientas, su uso se limitaba principalmente al laboratorio de IBM en Rochester.

Además del Manual de Referencia de DDM, un documento de Información General ^{[ 1 ]} proporciona información de nivel ejecutivo sobre DDM, y una Guía del Programador ^{[ 11 ]} resume los conceptos de DDM para programadores que implementan clientes y servidores.

La arquitectura DDM define tres modelos generales de archivos: archivos orientados a registros, archivos orientados a flujos y directorios jerárquicos.

La arquitectura DDM proporciona los siguientes servicios para la gestión de archivos remotos:

• crear, borrar y eliminar archivos,
• copiar, cargar y descargar los datos de un archivo,
• bloquear y desbloquear archivos,
• obtener y cambiar atributos de archivo,

Las colas son un mecanismo de comunicación que permite la comunicación, generalmente a corto plazo, entre programas mediante registros. Una cola DDM reside en un único sistema, pero puede ser accedida por programas en múltiples sistemas. Existen tres subclases de colas DDM que se pueden crear en un sistema de destino mediante comandos de creación distintos:

• Las colas FIFO (primero en entrar, primero en salir) son un canal asíncrono entre los programas que encolan y los que desencolan.
• Colas de último en entrar, primero en salir, una pila de empuje descendente.
• Colas con clave, un mecanismo de ramificación donde las entradas seleccionadas se pueden extraer de la cola mediante el valor de la clave.

El modelo de cola DDM consta de atributos como la fecha de creación, la cantidad de registros que puede contener y la longitud de los registros. Los registros en una cola pueden tener una longitud fija o variable.

A diferencia de los modelos de archivos DDM, no es necesario abrir un método de acceso en una cola. Los programas pueden agregar y recibir registros de una cola según la clase de la misma. También pueden eliminar registros, detener operaciones, listar sus atributos y modificarlos. Además, pueden bloquear una cola o registros individuales para evitar conflictos con otros programas. Los demás clientes deben esperar a que se libere el bloqueo.

Una base de datos relacional (RDB) es una implementación del lenguaje de consulta estructurado (SQL) que permite la creación, gestión, consulta, actualización, indexación e interrelación de tablas de datos. Un usuario o programa interactivo puede enviar sentencias SQL a una RDB y recibir tablas de datos e indicadores de estado como respuesta. Sin embargo, las sentencias SQL también pueden compilarse y almacenarse en la RDB como paquetes, para luego ser invocadas mediante su nombre. Esto es fundamental para el funcionamiento eficiente de programas de aplicación que realizan consultas complejas y frecuentes, especialmente cuando las tablas a las que se accede se encuentran en sistemas remotos.

La arquitectura de base de datos relacional distribuida (DRDA) se integra perfectamente en el marco general de DDM, como se explica en Orientación a objetos . (Sin embargo, DDM también puede considerarse una arquitectura de componentes de DRDA, ya que se requieren otras especificaciones ^{[ 2 ]} ). Los objetos de nivel de administrador de DDM que admiten DRDA se denominan RDB (base de datos relacional) y SQLAM (administrador de aplicaciones SQL).

La transparencia es un objetivo clave de la arquitectura DDM. Sin necesidad de recompilación, debería ser posible redirigir los programas de aplicación existentes a los servicios de gestión de datos de un equipo remoto. En el caso de los archivos, esto se lograba en gran medida mediante clientes DDM a nivel de interfaz/funcional, pero ¿qué ocurre con los campos de datos de un registro? La transparencia total exige que los programas de aplicación cliente puedan escribir y leer los campos tal como los codifica su sistema de gestión de datos local, independientemente de cómo los codifique cualquier servidor remoto, lo que implica conversiones de datos automáticas .

Por ejemplo, los ordenadores centrales de IBM codifican los números de coma flotante en formato hexadecimal y los datos de caracteres en EBCDIC , mientras que los ordenadores personales de IBM los codifican en formato IEEE y ASCII . La complejidad aumenta debido a la forma en que los compiladores de distintos lenguajes de programación asignan los campos de registro a cadenas de bits, bytes y palabras en la memoria. La conversión transparente de un registro requiere descripciones detalladas tanto de la vista del cliente como de la del servidor. Con estas descripciones, se pueden comparar los campos de ambas vistas, por nombre, y realizar las conversiones pertinentes.

La clave reside en obtener descripciones de registros suficientemente detalladas, pero en los programas de aplicación, estas descripciones suelen especificarse de forma abstracta mediante declaraciones definidas por el lenguaje de programación, mientras que el compilador se encarga de la codificación y la asignación de datos. En un entorno de procesamiento distribuido, se necesita una única forma estandarizada de describir los registros, independiente de cualquier lenguaje de programación, capaz de describir la amplia variedad de formatos de registro, tanto fijos como de longitud variable, presentes en los archivos existentes.

El resultado fue la definición de una arquitectura integral de Descripción y Conversión de Datos (DD&C), ^{[ 14 ]} basada en un nuevo lenguaje de programación especializado, A Data Language (ADL), ^{[ 15 ]} para describir las vistas del cliente y del servidor de los registros de datos y para especificar las conversiones. Los programas ADL compilados pueden ser llamados por un servidor para realizar las conversiones necesarias a medida que los registros fluyen hacia o desde el servidor.

La arquitectura DD&C fue más allá y definió un método para convertir automáticamente las declaraciones de lenguajes de programación a y desde ADL, y así, de un lenguaje de programación a otro. Esta capacidad nunca se implementó debido a su complejidad y costo. Sin embargo, se creó un compilador de ADL y, cuando está disponible, se invocan programas ADL para realizar conversiones mediante DFM y el sistema de almacenamiento IBM 4680. ^{[ 16 ]} No obstante, es necesario que los programadores de aplicaciones escriban manualmente los programas ADL.

Los siguientes productos de IBM implementaron varios subconjuntos de la arquitectura DDM:

• Sistema IBM/370
  • MVS (MVS/SP, MVS/ESA)
    • Base de datos 2 : cliente y servidor DRDA
    • CICS : servidor de archivos de registro dentro del entorno de procesamiento de transacciones de CICS. Se ha descontinuado en CICS para z/OS V5.2 y versiones posteriores. ^{[ 17 ]}
  • Máquina virtual (sistema operativo) (VM/SP, VM/ESA)
    • SQL/DS - Cliente y servidor DRDA
  • DOS/VSE
    • CICS - Servidor de archivos de registro dentro del entorno de procesamiento de transacciones de CICS. Se ha descontinuado en CICS para z/VSE V2.1 y versiones posteriores. ^{[ 18 ] [ 19 ]}
  • z/OS
    • Gestión de archivos distribuidos - Servidor de archivos de registro
    • Base de datos 2 : cliente y servidor DRDA
• Sistema/36
  • Programa de soporte del sistema : cliente y servidor de archivos de registro
• System/38 y sus sucesores: AS/400, iSeries y Power Series.
  • Cliente y servidor de archivos de registro
  • Cliente y servidor de archivos de directorio y transmisión
  • Cliente y servidor DRDA
• Ordenador personal IBM
  • PC DOS
    • Netview/PC - Cliente y servidor de archivos de directorio y transmisión
    • DDM/PC - Cliente de archivos de directorio y transmisión.
    • Soporte para PC/36 - Cliente de archivos de directorio y transmisión.
    • Soporte para PC/400 - Cliente de archivos de directorio y transmisión.
  • Sistema Personal/2 - SO/2
    • PC/Soporte/400 - Cliente y servidor de transmisión de archivos y directorios
    • Cliente y servidor DRDA
• Sistemas de almacenamiento IBM 4680 e IBM 4690
  • Cliente y servidor de archivos de registro
  • Cliente y servidor de archivos de directorio y transmisión
• RS/6000 AIX
  • Cliente y servidor DRDA

Para obtener una lista completa de los productos que han implementado DRDA, consulte la Tabla de identificadores de productos DRDA de código abierto .