La arquitectura de gestión de datos distribuidos ( DDM ) es la arquitectura de software abierta y publicada de IBM para crear, gestionar y acceder a datos en una computadora remota. DDM se diseñó inicialmente para admitir archivos orientados a registros; se amplió para admitir directorios jerárquicos, archivos orientados a flujos, colas y procesamiento de comandos del sistema; se amplió aún más para ser la base de la arquitectura de base de datos relacional distribuida (DRDA) de IBM; y, finalmente, se amplió para admitir la descripción y conversión de datos. Definida en el período de 1980 a 1993, DDM especifica los componentes, mensajes y protocolos necesarios, todos basados en los principios de la orientación a objetos. DDM no es, en sí misma, una pieza de software; la implementación de DDM toma la forma de productos cliente y servidor. Como arquitectura abierta , los productos pueden implementar subconjuntos de la arquitectura DDM y los productos pueden extender DDM para cumplir con requisitos adicionales. En conjunto, los productos DDM implementan un sistema de archivos distribuido .
Los diseñadores de aplicaciones distribuidas deben determinar la mejor ubicación de los programas y datos de la aplicación en términos de la cantidad y frecuencia de los datos que se deben transmitir, junto con consideraciones de gestión de datos, seguridad y puntualidad. Existen tres modelos cliente-servidor para el diseño de aplicaciones distribuidas:
La arquitectura DDM fue diseñada inicialmente para soportar el modelo de cliente pesado de aplicaciones distribuidas; también admite transferencias de archivos completos.
La arquitectura DDM proporciona a las aplicaciones distribuidas los siguientes beneficios: [1]
La arquitectura DDM es un conjunto de especificaciones para mensajes y protocolos que permiten gestionar y acceder a datos distribuidos a través de una red de computadoras. [2]
La arquitectura de red de sistemas (SNA) de IBM se diseñó inicialmente para permitir la conexión jerárquica de estaciones de trabajo a computadoras mainframe de IBM. Las redes de comunicación disponibles en ese momento estaban diseñadas rígidamente en términos de conexiones fijas entre una computadora mainframe y su conjunto de estaciones de trabajo, que estaban bajo el control completo del software de la computadora mainframe. Otras comunicaciones entre mainframes también se realizaban en términos de conexiones fijas utilizadas por software definido para propósitos específicos. A medida que las redes de comunicación se volvieron más flexibles y dinámicas, las comunicaciones peer to peer genéricas se volvieron deseables, en las que un programa en una computadora podía iniciar e interactuar con un programa en una computadora diferente.
Cuando se definió la arquitectura de comunicaciones avanzadas de programa a programa (APPC) de IBM a principios de los años 80, también quedó claro que APPC podía utilizarse para proporcionar servicios de sistema operativo en computadoras remotas. Un grupo de trabajo de SNA persiguió esta idea y describió varios servicios distribuidos posibles, como servicios de archivos, servicios de impresora y servicios de consola del sistema, pero no pudo iniciar el desarrollo del producto. El software APPC aún no estaba disponible en mainframes y, más básicamente, los mainframes todavía se consideraban principalmente sistemas independientes. Como resultado, el grupo de trabajo de SNA suspendió el trabajo sobre 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, llamada 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 los clientes en múltiples 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 diversos almacenes. APPC se implementó en estos sistemas y fue utilizado por diversas aplicaciones de los clientes. La idea de los servicios distribuidos de sistemas operativos resurgió entonces como el proyecto Golden Gate y se intentó justificar su desarrollo. Este intento también fracasó; la idea de los servicios distribuidos era demasiado nueva para que los planificadores de productos de IBM pudieran cuantificar el valor del software que interconectaba ordenadores heterogéneos.
Sin embargo, un planificador de Golden Gate , John Bondy, siguió convencido y persuadió a la gerencia para crear un departamento fuera del control normal del laboratorio de Rochester para que no hubiera una necesidad inmediata de un caso de negocios predefinido. Además, limitó su misión para incluir solo soporte para la Gestión de Datos Distribuidos (DDM), en particular, soporte para archivos orientados a registros . Luego convenció a un arquitecto de software experimentado, Richard A. Demers, para que se uniera a él en las tareas de definir la arquitectura de DDM y vender la idea de DDM a las casas de sistemas de IBM.
El primer año de este esfuerzo fue en gran medida infructuoso, ya que las empresas de sistemas IBM seguían exigiendo argumentos comerciales 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, cuando las computadoras personales comenzaron a usarse como terminales conectadas a las computadoras mainframe, se argumentó que simplemente mejorando el flujo de datos 3270 se permitiría a las PC acceder a los datos de las computadoras mainframe.
Durante este período, Demers diseñó un modelo arquitectónico de los clientes y servidores DDM, de sus componentes y de las interacciones entre los ordenadores que se comunicaban. Además, definió un formato genérico para los mensajes DDM basado en los principios de la orientación a objetos, iniciados por el lenguaje de programación Smalltalk y por el IBM System/38. Este modelo dejó claro cómo se podían implementar los productos DDM en varios sistemas. Consulte Cómo funciona DDM.
En 1982, los planificadores del Sistema/36 se convencieron de que habí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 se debían definir? 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 , y lo mismo se había hecho con el sistema de archivos System/38 y el sistema de archivos Virtual Storage Access Method (VSAM) de los mainframes de IBM. Y, sin embargo, sus funciones e interfaces reales variaban considerablemente, así que ¿qué funciones e interfaces debería soportar la arquitectura DDM? Véase archivos orientados a registros.
El trabajo inicial sobre DDM por parte del proyecto Golden Gate había seguido el ejemplo del estándar internacional File Transfer Access and Management ( FTAM ) para archivos distribuidos, pero era muy abstracto y difícil de mapear a los servicios de archivos locales. De hecho, esta había sido una de las barreras para su aceptación por parte de las empresas de sistemas IBM. Kenneth Lawrence, el arquitecto de sistemas responsable de los servicios de archivos System/36, argumentó que sería mejor definir mensajes que al menos un sistema IBM pudiera implementar fácilmente y luego dejar que otros sistemas solicitaran los cambios que necesitaran. Naturalmente, abogó por el apoyo a los requisitos de System/36. Después de un año de fracasos en vender la idea de DDM a otras empresas de sistemas IBM, los argumentos de Lawrence prevalecieron.
Richard Sanders se unió al equipo de arquitectura de DDM y trabajó con Lawrence y Demers para definir los mensajes específicos necesarios para DDM de System/36. El progreso en la definición de DDM animó a System/38 a participar también. Esto amplió el alcance de la compatibilidad de archivos de registro de DDM para cumplir con muchos de los requisitos del sistema de archivos avanzado de System/38.
Los archivos existen en un contexto proporcionado por un sistema operativo que proporciona servicios para organizar archivos, compartirlos con usuarios concurrentes y protegerlos de 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, se requerían seguridad y compartición. Sanders realizó el trabajo de diseño en estas áreas. Sanders también definió protocolos específicos con respecto al uso de las instalaciones de comunicación, que se incorporaron en un componente llamado DDM Conversational Communications Manager. Inicialmente implementado utilizando APPC, luego se implementó utilizando TCP/IP .
Con la finalización del producto System/36 DDM, Lawrence trabajó con programadores del laboratorio 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 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 IBM Cary, Carolina del Norte, para implementar un cliente orientado a registros DDM para IBM PC DOS .
El nivel 1 de la arquitectura DDM se publicó formalmente en 1986. En el momento de este anuncio, IBM entregó un Premio al Logro Técnico Destacado a Kenneth Lawrence, un Premio a la Contribución Destacada a Richard Sanders y un Premio a la Innovación Destacada a Richard Demers.
Con la creciente importancia de IBM PC y el sistema operativo Unix en los entornos de red, también se necesitó soporte DDM para los directorios jerárquicos y los archivos orientados a secuencias de IBM Personal Computer que ejecutaban IBM PC DOS y IBM RS/6000 que ejecutaban IBM AIX (la versión de IBM de Unix). Consulte Archivos orientados a secuencias.
El nivel 2 de arquitectura DDM se publicó en 1988. Jan Fisher y Sunil Gaitonde realizaron la mayor parte del trabajo de arquitectura sobre 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 creado 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 una RDB distribuida, y consideraron que había llegado el momento de convertirlo en productos comercializables. Sin embargo, System/R* se basaba en System/R, un prototipo de investigación de una RDB, y no se podía añadir fácilmente a los productos RDB de IBM. Véase [6] para una discusión de las RDB en un entorno de procesamiento distribuido.
Roger Reinsch, del Centro de programación de IBM Santa Theresa, dirigió un equipo multiproducto para definir una arquitectura de base de datos relacional distribuida (DRDA). Reclutó a:
En 1990, se publicaron al mismo tiempo DDM Architecture Level 3 y DRDA [7] . 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 Distributed File Management (DFM) [8] se inició para agregar servicios DDM al sistema operativo MVS de IBM para permitir que los programas en computadoras remotas creen, administren y accedan a archivos VSAM . John Hufferd, el gerente del proyecto DFM, recurrió al equipo de arquitectura DDM para encontrar un medio para convertir los campos de datos en registros a medida que fluían entre sistemas. Richard Demers tomó la iniciativa en este tema, con la ayuda de Koichi Yamaguchi del proyecto DFM. Consulte Descripción y conversión de datos.
Los siguientes servicios adicionales fueron definidos por Richard Sanders, Jan Fisher y Sunil Gaitonde en la arquitectura DDM en el nivel 4:
El nivel 4 de arquitectura DDM se publicó en 1992.
El trabajo de arquitectura en el nivel 5 de DDM consistió en brindar soporte para
Jan Fisher fue el arquitecto responsable del nivel 5 de DDM, que fue publicado por Open Group, en lugar de IBM. Poco después, el grupo de arquitectura de DDM de IBM se disolvió.
La arquitectura DDM es un conjunto de especificaciones definidas formalmente y altamente estructuradas. Esta sección presenta los conceptos técnicos clave que sustentan la DDM. [2]
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 ).
La arquitectura DDM está orientada a objetos . Todas las entidades definidas por DDM son objetos definidos por objetos de clase autodefinidos . Los mensajes, respuestas y datos que fluyen entre sistemas son objetos serializados. Cada objeto especifica su longitud, identifica su clase por medio de 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, y cada nivel manifiesta propiedades emergentes en niveles cada vez más superiores.
Si bien la arquitectura DDM está 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 Smalltalk de DDM para IBM PC , con clases Smalltalk apropiadas 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 'Exchange Server Attributes' es el primer comando que se envía cuando un cliente se conecta con un servidor. Identifica al cliente y especifica los administradores que requiere el cliente y el nivel de arquitectura DDM en el que se requiere soporte. El servidor responde identificándose y especificando en qué nivel soporta los administradores solicitados. Una regla general es que un producto que soporta el nivel X de un administrador DDM también debe soportar el nivel X-1 para que los nuevos productos de servidor se conecten con productos de cliente más antiguos.
Se pueden implementar subconjuntos de DDM para satisfacer distintos requisitos del producto:
Cuando un cliente DDM está conectado a un servidor DDM conocido, como un cliente System/38 a un servidor System/38, la arquitectura DDM también se puede ampliar agregando
Estas extensiones se pueden definir dentro del marco orientado a objetos de DDM para que se puedan utilizar las facilidades de manejo de mensajes de DDM existentes.
En una implementación de DDM puramente orientada a objetos, los clientes y servidores y todos los administradores y objetos que contienen existen en un montón de memoria, con punteros (direcciones de memoria) que se utilizan para interconectarlos. Por ejemplo, un objeto de comando apunta a cada uno de sus objetos de parámetro. Pero un comando no se puede transmitir de un cliente a un servidor de esta manera; se debe crear una copia isomórfica del comando como una única cadena de bits contigua. En el montón, un comando consta del tamaño del comando en el montón, un puntero a la clase del comando y punteros a cada uno de los objetos de parámetro del comando. Linealizado, el comando consta de la longitud total del comando linealizado, un punto de código que identifica la clase del comando 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 sencilla técnica 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 sobres que permiten que los agentes de cliente y servidor coordinen su procesamiento. En la arquitectura DDM, estos sobres se denominan estructuras de flujo de datos (DSS). Los comandos se colocan en un DSS de solicitud (RQSDSS), las respuestas se colocan en un DSS de respuesta (RPYDSS) y otros objetos se colocan en un DSS de objeto (OBJDSS). Solo puede haber un comando en un RQSDSS y solo una respuesta en un RPYDSS, pero muchos objetos, como registros, se pueden colocar en un OBJDSS. Además, se pueden encadenar muchos OBJDSS a un RQSDSS o un PRYDSS para dar cabida a tantos objetos como sea necesario. Un DSS consta de la longitud total del DSS, un byte de indicador que identifica el tipo de DSS, un identificador de solicitud y los objetos linealizados en el DSS. El identificador de solicitud vincula un RQSDSS con los OBJDSS posteriores 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 de menú, ayuda y clase con nombre. Las subclases de la clase DDM Class se describen mediante variables que especifican
Estos objetos pueden contener referencias a otros objetos nombrados en el texto y las especificaciones, creando así vínculos de hipertexto entre las páginas del Manual de referencia de DDM. Las páginas de menú y ayuda forman un tutorial integrado sobre DDM. La versión en papel del Manual de referencia de DDM Nivel 3 es voluminosa, con más de 1400 páginas, y un poco incómoda de usar, pero también se creó una versión interactiva utilizando las instalaciones de comunicación internas de IBM. Dada la velocidad relativamente lenta de esas instalaciones de comunicación, se utilizó principalmente en el 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 de archivos generales: archivos orientados a registros, archivos orientados a flujos y directorios jerárquicos.
La arquitectura DDM proporciona los siguientes servicios para gestionar archivos remotos:
Los archivos orientados a registros se diseñaron para satisfacer los requisitos de entrada, salida y almacenamiento de datos de los lenguajes de programación de tercera generación (3GL), como Fortran, Cobol, PL/I y RPG. En lugar de que cada lenguaje brindara su propio soporte para estas capacidades, se incorporaron a los servicios que brindan los sistemas operativos.
Un registro es una serie de campos de datos relacionados, como el nombre, la dirección, el número de identificación y el salario de un solo empleado, en el que cada campo está codificado y asignado a una cadena contigua de bytes. Las primeras computadoras tenían capacidades de entrada y salida limitadas, generalmente en forma de pilas de tarjetas perforadas de 80 columnas o en forma de papel o cintas magnéticas. Los registros de aplicaciones, como los registros de datos de empleados, se leían o escribían secuencialmente un registro a la vez y se procesaban en lotes. Cuando los dispositivos de almacenamiento de acceso directo estuvieron disponibles, los lenguajes de programación agregaron formas para que los programas accedieran aleatoriamente a los registros uno a la vez, como el acceso por los valores de los campos clave o por la posición de un registro en un archivo. Todos los registros de un archivo pueden tener el mismo formato (como en un archivo de nómina) o formatos diferentes (como en un registro de eventos). Algunos archivos son de solo lectura en el sentido de que sus registros, una vez escritos en el archivo, solo se pueden leer, mientras que otros archivos permiten que sus registros se actualicen.
Los modelos de archivos orientados a registros de DDM constan de atributos de archivo, como su fecha de creación, la fecha de la última actualización, el tamaño de sus registros y las ranuras en las que se pueden almacenar los registros. Los registros pueden tener una longitud fija o variable, según el medio utilizado para almacenar los registros del archivo. DDM define cuatro tipos de archivos orientados a registros:
La arquitectura DDM también define una variedad de métodos de acceso para trabajar con archivos orientados a registros de diversas maneras. Un método de acceso es una instancia de uso de un archivo creado por medio de un comando OPEN que se conecta al archivo después de determinar si el cliente está autorizado a usarlo. El método de acceso se desconecta de un archivo por medio de un comando CLOSE.
Un método de acceso realiza un seguimiento del registro que se está procesando actualmente mediante un cursor. Mediante el uso de varios comandos SET, se puede hacer que el cursor apunte al principio o al final del archivo, al registro secuencial anterior o siguiente del archivo, al registro con un valor de clave específico o al registro anterior o siguiente según el orden de sus claves.
Se pueden abrir varias instancias de métodos de acceso en un archivo al mismo tiempo, cada una de las cuales sirve a un solo cliente. Si se abre un archivo para obtener acceso de actualización, pueden producirse conflictos cuando varios clientes acceden al mismo registro. Para evitar dichos conflictos, se puede obtener un bloqueo en un archivo completo. Además, si se abre un archivo para obtener acceso de actualización , el primer cliente que lee un registro obtiene un bloqueo y lo libera cuando ese cliente lo actualiza. Todos los demás clientes deben esperar a que se libere el bloqueo.
Los archivos orientados a flujos consisten en una única secuencia de bytes en la que los programas pueden asignar datos de la aplicación como deseen. Los archivos de flujo son el modelo de archivo principal compatible con los sistemas operativos Unix y similares a Unix y con Windows . DDM define un único modelo de archivo de flujo y un único método de acceso a flujos.
El modelo de archivo de flujo DDM consta de atributos de archivo, como su fecha de creación y el tamaño del flujo, y un flujo continuo de bytes. Se puede acceder al flujo mediante el método de acceso al flujo. Los programas de aplicación escriben datos en partes del flujo, incluso si esos datos consisten en registros. Realizan un seguimiento de la ubicación de los elementos de datos en el flujo de la forma que deseen. Por ejemplo, el flujo de datos de los archivos de documentos se define mediante un programa de procesamiento de texto como Microsoft Word y el de un archivo de hoja de cálculo mediante un programa como Microsoft Excel .
Un método de acceso a un flujo es una instancia de uso de un archivo de flujo por parte de un solo cliente. Un cursor registra la posición del byte actual del subflujo que utiliza el cliente. Mediante varios comandos SET, se puede hacer que el cursor apunte al principio o al final del archivo, a cualquier posición específica en el archivo o a cualquier desplazamiento positivo o negativo desde la posición actual.
Se pueden abrir varias instancias del método de acceso Stream en un archivo al mismo tiempo, cada una de las cuales sirve a un solo cliente. Si se abre un archivo para obtener acceso de "actualización", pueden producirse conflictos cuando varios clientes acceden al mismo subflujo. Para evitar tales conflictos, se puede obtener un bloqueo en un archivo completo. Además, si se abre un archivo para actualizarlo, el primer cliente que lo "lea" obtiene un bloqueo en un subflujo y lo libera cuando ese cliente lo "actualiza". Todos los demás clientes deben esperar a que se libere el bloqueo.
Los directorios jerárquicos son archivos cuyos registros asocian un nombre a una ubicación. Una jerarquía se produce cuando un registro de directorio identifica el nombre y la ubicación de otro directorio. Mediante los productos cliente y servidor DDM, un programa puede crear, eliminar y cambiar el nombre de directorios en un equipo remoto. También pueden enumerar y cambiar los atributos de archivo de directorios remotos. Los registros de un directorio se pueden leer secuencialmente mediante el método de acceso a directorios de DDM. Los archivos identificados por los registros de directorio se pueden renombrar, copiar y mover a un directorio diferente.
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 los programas de varios sistemas pueden acceder a ella. Existen tres subclases de colas DDM que se pueden crear en un sistema de destino mediante comandos de creación distintos:
El modelo de cola DDM consta de atributos de cola, como su fecha de creación, la cantidad de registros que puede contener la cola y la longitud de los registros. Los registros de 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 registros a una cola y recibir registros de una cola según lo determine la clase de la cola. Los programas también pueden borrar registros de una cola, detener operaciones en una cola, enumerar los atributos de una cola y cambiar los atributos de una cola. Los programas también pueden bloquear una cola o registros individuales en una cola para inhibir la contención de otros programas. Todos 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 admite la creación, administración, consulta, actualización, indexación e interrelaciones de tablas de datos. Un usuario o programa interactivo puede emitir sentencias SQL a una RDB y recibir tablas de datos e indicadores de estado como respuesta. Sin embargo, las sentencias SQL también se pueden compilar y almacenar en la RDB como paquetes y luego invocarse por nombre de paquete. Esto es importante para el funcionamiento eficiente de los programas de aplicación que emiten consultas complejas de alta frecuencia. Es especialmente importante cuando las tablas a las que se accede se encuentran en sistemas remotos.
La arquitectura de base de datos relacional distribuida (DRDA) se adapta perfectamente al marco general de DDM, como se analiza en Orientación a objetos. (Sin embargo, DDM también puede considerarse una arquitectura de componentes de DRDA, ya que también 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 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 logró en gran medida mediante los clientes DDM en el nivel de interfaz/funcional, pero ¿qué sucede con los campos de datos de un registro? La transparencia total requiere que los programas de aplicación cliente puedan escribir y leer campos tal como están codificados por su sistema de gestión de datos local, independientemente de cómo los codifique cualquier servidor remoto, y eso implica conversiones automáticas de datos .
Por ejemplo, las computadoras mainframe de IBM codifican números de punto flotante en formato hexadecimal y datos de caracteres en EBCDIC , mientras que las computadoras personales de IBM los codifican en formato IEEE y ASCII . Surgió una mayor complejidad debido a las formas en que los compiladores de varios lenguajes de programación asignan 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 vista del servidor de un registro. Dadas estas descripciones, los campos de las vistas del cliente y del servidor se pueden hacer coincidir, por nombre de campo, y se pueden realizar las conversiones apropiadas.
La cuestión clave es obtener descripciones de registros suficientemente detalladas, pero las descripciones de registros generalmente se especifican de manera abstracta en los programas de aplicación mediante declaraciones definidas por el lenguaje de programación, y el compilador del lenguaje se encarga de los detalles de codificación y mapeo. En un entorno de procesamiento distribuido, lo que se necesita es una forma única y estandarizada de describir registros que sea independiente de todos los lenguajes de programación, una que pueda describir la amplia variedad de formatos de registros de longitud fija y variable que se encuentran 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, un lenguaje de datos (ADL), [15] para describir las vistas de los registros de datos por parte del cliente y del servidor 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 medio por el cual las declaraciones de lenguaje de programación pueden convertirse automáticamente a y desde ADL, y por lo tanto 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 ADL y los programas ADL se invocan, cuando están disponibles, para realizar conversiones por DFM y por el IBM 4680 Store System. [16] Sin embargo, es necesario que los programadores de aplicaciones escriban manualmente los programas ADL.
Los siguientes productos de IBM implementaron varios subconjuntos de la arquitectura DDM:
Para obtener una lista completa de los productos que han implementado DRDA, consulte la Tabla de identificadores de productos DRDA de código abierto.
{{cite journal}}: CS1 maint: varios nombres: lista de autores ( enlace )CICS DDM ya no está disponible en IBM y se interrumpió el soporte a partir del 31 de diciembre de 2003. CICS DDM ya no está disponible en CICS TS a partir de la versión 5.2.
El soporte para CICS Distributed Data Management (DDM) se ha estabilizado en CICS TS para VSE/ESA V1.1.1. En una futura versión de CICS TS para z/VSE, IBM tiene la intención de discontinuar el soporte para CICS DDM.
CICS Distributed Data Management (CICS/DDM) no es compatible con CICS TS para z/VSE V2.1.