La Arquitectura de gestión de datos distribuida ( 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 bases de datos relacionales distribuidas (DRDA) de IBM; y finalmente, se amplió para admitir la descripción y conversión de datos. Definido 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í mismo, una pieza de software; La implementación de DDM toma la forma de productos de cliente y servidor. Como arquitectura abierta , los productos pueden implementar subconjuntos de arquitectura DDM y los productos pueden ampliar DDM para cumplir 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 transmitirán, junto con consideraciones de gestión, seguridad y puntualidad de los datos. Existen tres modelos cliente-servidor para el diseño de aplicaciones distribuidas:
La arquitectura DDM se diseñó inicialmente para admitir el modelo de cliente pesado de aplicaciones distribuidas; también admite transferencias de archivos completos.
La arquitectura DDM proporciona aplicaciones distribuidas con los siguientes beneficios: [1]
La arquitectura DDM es un conjunto de especificaciones para mensajes y protocolos que permiten administrar y acceder a los datos distribuidos en 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 centrales 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 central y su conjunto de estaciones de trabajo, que estaban bajo el control completo del software de la computadora central. Otras comunicaciones entre mainframes también se realizaron 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, eran deseables las comunicaciones genéricas entre pares , en las que un programa en una computadora pudiera iniciar e interactuar con un programa en una computadora diferente.
Cuando se definió la arquitectura SNA Advanced Program to Program Communications (APPC) de IBM a principios de la década de 1980, también era evidente que APPC podía usarse para proporcionar servicios de sistema operativo en computadoras remotas. Un grupo de trabajo de SNA siguió esta idea y describió varios posibles servicios distribuidos, como servicios de archivos, servicios de impresora y servicios de consola del sistema, pero no pudo iniciar el desarrollo del producto. El software APPC todavía no estaba disponible en los mainframes y, más básicamente, los mainframes todavía se consideraban principalmente sistemas independientes. Como resultado, el grupo de trabajo de la 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 un caso de negocio 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 las minicomputadoras 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últiplos y había una clara necesidad de permitir, por ejemplo, que los ordenadores de la sede de una empresa interactuaran con los ordenadores de sus distintos almacenes. APPC se implementó en estos sistemas y fue utilizado por varias aplicaciones de clientes. La idea de los servicios de sistemas operativos distribuidos revivió luego como el proyecto Golden Gate y se intentó justificar su desarrollo. Este intento también fracasó; Toda 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 computadoras heterogéneas.
Sin embargo, un planificador del Golden Gate , John Bondy, siguió convencido y persuadió a la dirección para que creara un departamento fuera del control normal del laboratorio de Rochester, de modo que no hubiera necesidad inmediata de un caso de negocio predefinido. Además, redujo su misión para incluir únicamente 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 DDM y vender la idea de DDM a los fabricantes de sistemas IBM.
El primer año de este esfuerzo fue en gran medida infructuoso ya que los proveedores de sistemas de IBM continuaron exigiendo casos de negocios iniciales e insistieron en formatos de mensajes isomórficos 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 computadoras centrales, se argumentó que simplemente mejorar el flujo de datos 3270 permitiría a las PC acceder a los datos de la computadora central.
Durante este período, Demers diseñó un modelo arquitectónico de clientes y servidores DDM, de sus componentes y de las interacciones entre computadoras en comunicación. Además, definió un formato genérico para mensajes DDM basado en los principios de orientación a objetos iniciados por el lenguaje de programación Smalltalk y por IBM System/38. Este modelo dejó claro cómo se podrían implementar los productos DDM en varios sistemas. Vea cómo funciona DDM.
En 1982, los planificadores de System/36 se convencieron de que había suficiente mercado para los servicios de archivos orientados a registros DDM. [3]
El formato genérico de los mensajes DDM ya había sido diseñado, pero ¿qué mensajes específicos deberí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 del método de acceso al almacenamiento virtual (VSAM) de las computadoras centrales IBM. Y, sin embargo, sus instalaciones e interfaces reales variaron considerablemente, entonces, ¿qué instalaciones e interfaces debería admitir la arquitectura DDM? Ver 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 servicios de archivos locales. De hecho, ésta había sido una de las barreras a la aceptación por parte de los fabricantes 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 del System/36. Después de un año sin poder vender la idea de DDM a otras empresas de sistemas IBM, prevalecieron los argumentos de Lawrence.
Richard Sanders se unió al equipo de arquitectura de DDM y trabajó con Lawrence y Demers para definir los mensajes específicos necesarios para System/36 DDM. Los avances en la definición de DDM animaron a System/38 a participar también. Esto amplió el alcance del soporte de archivos de registros DDM para cumplir con muchos de los requisitos del sistema de archivos avanzado del System/38.
Los archivos existen en un contexto proporcionado por un sistema operativo que proporciona servicios para organizar archivos, compartirlos con usuarios simultáneos y protegerlos contra accesos injustificados. 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 utilizaría. Sin embargo, se requería seguridad y compartición. Sanders hizo 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 usando APPC, luego fue implementado usando 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 IBM Customer Information Control System (CICS). convirtiendo así a CICS en un servidor DDM para los sistemas operativos 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 DDM Architecture se publicó formalmente en 1986. En el momento de este anuncio, IBM entregó un Premio al Logro Técnico Sobresaliente 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 entornos de red, también se necesitaba soporte DDM para los directorios jerárquicos y archivos orientados a flujos de la computadora personal IBM que ejecuta IBM PC DOS y el IBM RS/6000 que ejecuta IBM AIX ( versión de IBM de Unix). Consulte Archivos orientados a secuencias.
DDM Architecture Level 2 se publicó en 1988. Jan Fisher y Sunil Gaitonde realizaron la mayor parte del trabajo de arquitectura sobre el soporte DDM para directorios y archivos continuos.
En 1986, IBM comercializó cuatro productos diferentes de bases de datos relacionales (RDB), cada uno de ellos creado para un sistema operativo IBM específico. Los científicos del Laboratorio de Investigación de IBM en Almaden habían desarrollado System/R*, un prototipo de RDB distribuido y sintieron que había llegado el momento de convertirlo en productos comercializables. Sin embargo, System/R* se basó en System/R, un prototipo de investigación de RDB, y no se podía agregar fácilmente a los productos IBM RDB. Consulte [6] para una discusión sobre los RDB en un entorno de procesamiento distribuido.
Roger Reinsch del Centro de programación IBM Santa Theresa lideró un equipo de productos cruzados para definir una arquitectura de base de datos relacional distribuida (DRDA). Se alistó:
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 IBM RDB y por otros proveedores.
Se entregaron premios a 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 programas en computadoras remotas creen, administren y accedan a archivos VSAM . John Hufferd, el director del proyecto DFM, recurrió al equipo de Arquitectura DDM en busca de 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. Ver Descripción y conversión de datos.
Richard Sanders, Jan Fisher y Sunil Gaitonde definieron los siguientes servicios adicionales en la arquitectura DDM en el nivel 4:
El nivel 4 de arquitectura DDM se publicó en 1992.
El trabajo de arquitectura en DDM nivel 5 consistió en soporte para
Jan Fisher fue el arquitecto responsable del DDM nivel 5, que fue publicado por Open Group, en lugar de IBM. Poco después, se disolvió el grupo de arquitectura IBM DDM.
La arquitectura DDM es un conjunto de especificaciones formalmente definido y altamente estructurado. Esta sección presenta conceptos técnicos clave que subyacen a 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 mediante un punto de código DDM y contiene datos definidos 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, cada nivel manifiesta propiedades emergentes en niveles cada vez más altos.
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 host. 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 arquitectura DDM; También pueden crear sus propias extensiones. [11]
El comando DDM 'Atributos del servidor Exchange' 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 a qué nivel da soporte a los gestores solicitados. Una regla general es que un producto que admite el nivel X de un administrador DDM también debe admitir 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 cumplir con distintos requisitos de productos:
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 funciones 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 puede transmitirse de un cliente a un servidor de esta forma; 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ámetros 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ámetros 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 el cliente y los servidores, incluidos comandos, registros y mensajes de respuesta.
Todos estos objetos linealizados se colocan en sobres que permiten a los agentes del cliente y del servidor coordinar su procesamiento. En la arquitectura DDM, estas envolventes 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). Sólo puede haber un comando en un RQSDSS y sólo 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 acomodar tantos objetos como sea necesario. Un DSS consta de la longitud total del DSS, un byte de bandera 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 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 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 con nombre en texto y 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 impresa del Manual de referencia de DDM Nivel 3 es voluminosa, tiene más de 1400 páginas y algo 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 secuencias y directorios jerárquicos.
La arquitectura DDM proporciona los siguientes servicios para administrar archivos remotos:
Los archivos orientados a registros se diseñaron para cumplir con 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 idioma proporcionara su propio soporte para estas capacidades, se incorporaron a los servicios proporcionados por 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 limitadas de entrada y salida, 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 los 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 accedan 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 distintos formatos (como en un registro de eventos). Algunos archivos son de sólo lectura en el sentido de que sus registros, una vez escritos en el archivo, sólo 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 varias maneras. Un método de acceso es una instancia del uso de un archivo creado mediante 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 mediante un comando CLOSE.
Un método de acceso realiza un seguimiento del registro que se está procesando actualmente mediante un cursor. Usando 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 clave específico o al registro anterior o siguiente según el orden. por sus llaves.
Se pueden abrir varias instancias de métodos de acceso en un archivo al mismo tiempo, cada una de las cuales atiende a un único cliente. Si se abre un archivo para acceder a la actualización, pueden ocurrir conflictos cuando varios clientes acceden al mismo registro. 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 obtiene un bloqueo en un registro para leerlo 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 secuencias constan de una única secuencia de bytes en la que los programas pueden asignar los datos de la aplicación como quieran. Los archivos continuos son el modelo de archivo principal admitido por Unix y sistemas operativos similares a Unix y por Windows . DDM define un modelo de archivo de secuencia única y un método de acceso a una secuencia única.
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 a la transmisión mediante el método de acceso a la transmisión. Los programas de aplicación escriben datos en partes de la secuencia, incluso si esos datos consisten en registros. Realizan un seguimiento de la ubicación de los elementos de datos en la secuencia de la forma que deseen. Por ejemplo, el flujo de datos de archivos de documentos lo define 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 Stream es una instancia de uso de un archivo de flujo por parte de un único cliente. Un cursor realiza un seguimiento de la posición del byte actual del subflujo que utiliza el cliente. Usando 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 atiende a un único cliente. Si se abre un archivo para acceso de "actualización", pueden ocurrir 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 obtiene un bloqueo en una subtransmisión para "leerlo" 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 cada uno un nombre con una ubicación. Una jerarquía ocurre cuando un registro de directorio identifica el nombre y la ubicación de otro directorio. Al utilizar productos de cliente y servidor DDM, un programa puede crear, eliminar y cambiar el nombre de directorios en una computadora remota. También pueden enumerar y cambiar los atributos de archivos de directorios remotos. Los registros de un directorio se pueden leer secuencialmente utilizando el método de acceso al directorio DDM. Los archivos identificados por los registros del directorio se pueden cambiar de nombre, 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. Hay tres subclases de colas DDM que se pueden crear en un sistema de destino mediante distintos comandos de creación:
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 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 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 competencia 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, gestión, consulta, actualización, indexación e interrelaciones de tablas de datos. Un usuario o programa interactivo puede emitir declaraciones SQL a una RDB y recibir tablas de datos e indicadores de estado en respuesta. Sin embargo, las sentencias SQL también se pueden compilar y almacenar en la RDB como paquetes y luego invocarlas por el nombre del paquete. Esto es importante para el funcionamiento eficiente de los programas de aplicación que emiten consultas complejas y de alta frecuencia. Es especialmente importante cuando las tablas a las que se accede están ubicadas en sistemas remotos.
La Arquitectura de Base de Datos Relacional Distribuida (DRDA) encaja perfectamente en el marco general de DDM, como se analiza en Orientación a objetos. (Sin embargo, DDM también puede verse como una arquitectura de componentes de DRDA, ya que también se requieren otras especificaciones [2] ). Los objetos de nivel de administrador DDM que admiten DRDA se denominan RDB (para base de datos relacional) y SQLAM (para SQL Application Manager).
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 una computadora remota. Para los archivos, esto lo lograron en gran medida los clientes DDM a nivel de interfaz/funcional, pero ¿qué pasa con los campos de datos en un registro? La transparencia total requiere que los programas de aplicaciones cliente puedan escribir y leer campos 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 varios compiladores de 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 maneja 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, A Data Language (ADL), [15] para describir vistas de registros de datos de clientes y servidores y para especificando conversiones. Luego, un servidor puede llamar a los programas ADL compilados 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 declaración del lenguaje de programación se pueden convertir automáticamente hacia 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 se llama a los programas ADL, cuando están disponibles, para realizar conversiones mediante DFM y 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 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}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace )CICS DDM ya no está disponible en IBM y el soporte se interrumpió el 31 de diciembre de 2003. CICS DDM ya no está disponible en CICS TS desde la versión 5.2 en adelante.
El soporte para CICS Distributed Data Management (DDM) está estabilizado en CICS TS para VSE/ESA V1.1.1. En una versión futura de CICS TS para z/VSE, IBM tiene intención de suspender el soporte para CICS DDM.
CICS Distributed Data Management (CICS/DDM) no es compatible con CICS TS para z/VSE V2.1.