TRABAJO DE CLIENTE/SERVIDORARQUITECTURA BASES DE DATOS DISTRIBUIDAS : DRDA Introducción En este trabajo trataré de explicar la tecnología DRDA, que es la arquitectura distribuida para bases de datos relacionales, y que fue desarrollada por IBM. Empezaré dando un pequeño número de definiciones previas relacionadas con este tema de las bases de datos distribuídas, y que a lo largo del trabajo serán mencionadas. A continuación, me centraré ya en lo que es púramente el trabajo en sí: DRDA. Empezaré con los motivos que llevaron a la aparición de DRDA, y seguídamente expondré en qué consiste esta arquitectura. Después, también me referiré a algunos protocolos que son utilizados junto con DRDA, y clasificaré en 5 los posibles niveles que se pueden considerar para una arquitectura DRDA. Como broche final al trabajo, mencionaré y hablaré un poco sobre algunos productos existentes en el mercado, que incorporan la tecnología DRDA. Definiciones previas: Sistema distribuido: Un ambiente computacional se dice distribuido cuando sus programas o BDs están ubicados en dos o más computadores. Las operaciones que no se pueden realizar bajo tal DBMS (tal como SQL recurrente) funcionan debajo de DB2. las referencias a esa información (llamada alias ) pueden ser actualizadas sin ningun cambio a los usos o programas que solicitan la información. Por ejemplo. Mientras que un programa de uso puede poner al día varias bases de datos remotas. Esta ayuda está disponible para los usos desarrollados usando el SQL regular así como los usos que utilizan a monitores del tratamiento transaccional (monitores TP). puede tener acceso solamente a una base de datos dentro de una unidad de trabajo. Unidad distribuida del trabajo Una unidad distribuida del trabajo (DUOW) . Peticiones distribuidas Una petición distribuida es una función de la base de datos distribuida que permite que los usos y los usuarios sometan declaraciones del SQL que referencian dos o más DBMSs o bases de datos en una sola declaración. o la secuencia en su totalidad se considera fracasada. es una función que permite a sus usos poner al día datos en servidores alejados de la base de datos. Si se mueve la información (en tablas). Los productos de DB2 proporcionan la ayuda comprensiva para las actualizaciones del multisite. La petición distribuida también proporciona la remuneración para DBMSs que no apoyan todo el dialecto de DB2 SQL. • Puede haber peticiones múltiples por unidad del trabajo. Una DUOW tiene las características siguientes: • Más de un servidor de la gestión de la base de datos es actualizado por unidad del trabajo. garantizándose la integridad de los mismos. Unidad del trabajo: Una unidad del trabajo (UOW) es una sola transacción lógica. • La comisión se coordina a través de los servidores múltiples de la base de datos. . o ciertas capacidades de la optimización. Consiste en una secuencia de declaraciones del SQL en las cuales o todas las operaciones se realizan con éxito. una transacción de las actividades bancarias que implique la transferencia del dinero a partir de una cuenta a otra en diversos servidores de la base de datos. Unidad remota del trabajo Una unidad remota del trabajo apoya el acceso a una base de datos dentro de una unidad de trabajo. La petición distribuida proporciona la transparencia de la localización para los objetos de la base de datos. La unidad distribuida del trabajo implica más de un servidor de la base de datos dentro de una unidad del trabajo. también conocida como actualización del multisite. • Hay un servidor de la gestión de la base de datos por petición. si los usuarios desearon intercambiar datos de diversas bases de datos. miraba un estándar de la industria para la interoperabilidad del acceso de base de datos. tuvieron que utilizar una mezcla de entradas propietarias. La demanda específica de los clientes-miembros del grupo abierto ayudó a empujarlo para su revisión y adopción. los usuarios desean usar el mejor software sin importar las soluciones de hardware que posean. y desean eliminar el coste asociado a tener diversos conductores para diversas bases de datos. "Boeing ha utilizado el protocolo de DRDA como estándar interno hace varios años para realzar la interoperabilidad del uso a través de múltiples sistemas de gestión heterogéneos de las bases de datos. que es el consorcio de la industria para promover tecnologías abiertas. a disminuir nuestro coste para crear y sostener usos. Tres años antes. Jim Presti. y entre diversas bases de datos. IBM ofreció el protocolo de DRDA al grupo abierto y ciertos vendedores opusieron su adopción. En el pasado. Pero muchas compañías internacionales utilizaban ya los productos que la apoyaron. podrá crecer y llenar funciones adicionales importantes en la empresa de los datos? En 1998 cuando el grupo abierto (Open Group). Los estándares nos ayudan a reducir la variación dentro de nuestros usos. anunció su adopción del protocolo de DRDA. basado en SQL. Hoy. ¿La pregunta es. La respuesta es la arquitectura distribuida de bases de datos relacionales (DRDA). El encargado del servicio de la gerencia de datos de Boeing. de alto rendimiento." La idea es que un sólo estándar simplificará las comunicaciones entre los usos y las bases de datos. y el flujo optimizado de alto rendimiento de la red basado en técnicas de codificación compactas. . software e interfaces de programación no estándar. DRDA apoya completamente el principio de sistemas en linea transaccionales como el sistema de control de la información del cliente de IBM (CICS) y el servidor de transacción de Microsoft (MTS). dijo. y a mejorar la calidad total de los usos que resultan.Comienzo del trabajo: DRDA La promesa de DRDA Comenzó con una necesidad de tener una manera simple y constante de obtener y de manipular datos de DBMSs de vendedores múltiples. El protocolo DRDA incluye las características para el acceso de bases de datos relacionales. " . un subsistema DB2 puede comunicarse con un RDBMS de una tercera persona. DRDA proporciona métodos para coordinar la comunicación entre localizaciones distribuidas. Las plataformas no necesitan ser iguales. ¿Qué es DRDA? DRDA es un sistema de protocolos. DB2 es un producto DRDA-obediente de RDBMS. Cuando un DBMS se dice que es DRDA-obediente. Una distinción se debe hacer. Esto permite que se tenga acceso a tablas alejadas en múltiples y varias localizaciones. SQL/DS y los sistemas de base de datos SQL/400 Apoya sistemas multivendor de bases de datos Apoya la transacción (unidad de trabajo) que procesa bases de datos distribuidas Es una arquitectura que permite que datos relacionados sean distribuidos entre múltiples plataformas. sin embargo. Resumiendo. DRDA es un estándar para distribuir la información de las bases de datos que tienen acceso a través de plataformas IBM. Por ejemplo. DRDA tiene las capacidades siguientes: • • • • Define los protocolos para proporcionar interfaces entre los clientes y las bases de datos back-end Proporciona un marco para interconectar DB2. o de reglas. implica que sigue las especificaciones de DRDA. Proporciona un ambiente de base de datos distribuido heterogéneo. DBM.Vamos ahora a entrar un poco más a fondo en esta tecnología: Arquitectura Distribuida De la Base de datos relacional La arquitectura distribuida de la base de datos relacional (DRDA) es un sistema de protocolos que permite sistemas múltiples de bases de datos. un subsistema DB2 puede comunicarse con otro subsistema DB2 . pero no proporciona los interfaces de programación de uso reales (APIs) para realizar el acceso. IBM y no IBM. DRDA se puede considerar una clase "de protocolo universal para realizar el distribuido de los datos. que siguen estándares del SQL. En resumen. Mientras ambos se conformen con las especificaciones de DRDA. podrán comunicarse. DRDA coordina la comunicación entre los sistemas definiendo qué debe ser intercambiado y cómo debe ser intercambiado. DRDA describe la arquitectura para los datos distribuidos y nada más. Alternativamente. que permiten a un usuario tener acceso a los datos distribuidos sin importar donde residen físicamente. y que al usuario del otro extremo le parezca como si estuvieran todas en un mismo ente lógico. sino es más como las especificaciones para un programa. abierto y robusto. DRDA no es un programa real. entre la arquitectura y la puesta en práctica. Define las reglas para tener acceso a los datos distribuidos. Cualquier combinación de productos de gestion de bases de datos relacionales que utilizan DRDA se pueden conectar para formar un sistema de gestión distribuido de la base de datos relacional. y el último se asegura de que el mismo conductor pueda proporcionar que el request/reply fluya entre los clientes y los servidores de diversos vendedores en una manera estandarizada. sin embargo. y muchos vendedores están saltando al carro de la conformidad con DRDA. y el mantenimiento. otra de las ventajas de DRDA es que no hay asociación con cada entrada y su código Aunque DRDA es la arquitectura distribuida utilizada por DB2. Ventajas de DRDA DRDA es solamente un protocolo para apoyar RDBMS. es que hoy está muy disponible. Estos dos tipos de estándares son complementarios. La Compatibilidad De los Estándares Los estándares como X/Open CLI y ANSI/IOS SQL tratan la edición de la portabilidad del uso. usted necesita solamente un cliente y el servidor OS/390. Las entradas. Un alternativa a DRDA es utilizar un producto de entradas para tener acceso a datos distribuidos. Un estándar de la interoperabilidad de la base de datos tal como DRDA mejora la gerencia de los despliegues de la empresa reduciendo al mínimo el número de los conductores del cliente que tienen que ser desplegados en cada sitio de trabajo. permite la distribución completa de los datos La ventaja más grande proporcionada por DRDA es su sistema de reglas claramente indicado para apoyar el acceso distribuido de los datos. no es la única arquitectura en la industria. Pero hay que tener presente que ningún vendedor ha puesto en marcha un RDBMS que apoya completamente toda la funcionalidad de DRDA. dijo: "el protocolo estándar de DRDA reducirá los costes para el software. Estas piezas se comunican el uno con el otro. típicamente apoyan solamente el SQL dinámico. No habrá ninguna entrada adicional que . El anterior se asegura de que haya conductores en cada plataforma que pueda entender la sintaxis del lenguaje. DRDA fue construido para funcionar con la extensión y plataforma específica al SQL.Este trabajo describirá DRDA. DRDA (acceso a bases de datos distribuidas) es un sistema competente de protocolos desarrollados por los comités del estándar de la ISO y del ANSI. • • • DRDA fue construido para trabajar con un subconjunto estándar del SQL que está disponible del DBMS para el DBMS. Además. Si usted diseña sus usos con DRDA y TCP/IP. La ventaja más grande. con RDA solamente el SQL dinámico está disponible. Las entradas abarcan por lo menos a dos componentes. uno para cada localización distribuida. Cualquier producto que siga estas reglas puede integrarse con cualquier otro producto DRDA-obediente. sin embargo. Por lo tanto. Roger Johnson. mientras que DRDA trata la edición de la interoperabilidad. DRDA será el método que usted utiliza para poner datos distribuidos en ejecucion con DB2 (por ejemplo). El SQL estático se puede utilizar con DRDA. El encargado de los datos del DB2 LM Ericsson. la educación. IBM se centró originalmente en DRDA como tecnología back-end para los applets basados en Java. y otras fuentes vía DataJoiner usando DRDA. así como llegar a ser ordinarios en otros productos de la red. Los conductores que utilizan DRDA se pueden también utilizar para tener acceso a los nuevos productos de bases de datos de IBM que funcionan en UNIX o Windows NT. tales como Sybase.. DRDA es también el protocolo nativo usado por DB2/MVS de IBM. "Kemper utiliza DBMSs de vendedores múltiples. JavaBeans podría hacer una parte importante de e-commerce proporcionando un interfaz simple a las transacciones bien definidas de DRDA. Usando este tipo de producto y un cliente DRDA. arquitecto en las compañías de seguros de Kemper. y Sybase Inc. . . ¿Cuál es el futuro para DRDA? DRDA se contrapesa por hacer para el mercado del acceso a los datos lo que TCP/IP ha hecho ya para la industria de las comunicaciones de datos. Informix. El grupo abierto está supervisando el progreso de DRDA. Muchas de las compañías. servidor de MS/SQL. Actualmente. muchos vendedores. han licenciado las especificaciones de DRDA. enterado que otras organizaciones se están moviendo para adoptar DRDA. moviéndose más allá de interoperabilidad del acceso a bases de datos. En el lado de UNIX. Oracle Corp.. o usando DB2 que tiene acceso para OS/390 vía el web server OS/390. particularmente en las actividades bancarias y los sectores financieros. Los usuarios pueden también esperar que el uso de DRDA sea encajado en entradas de CORBA y nuevos modelos basados en RPCs. pero en este caso usted necesita una entrada. los servidores de la web están conduciendo la demanda para la conectividad a las bases de datos de IBM. altamente eficientes que obrarían recíprocamente en el servidor back-end. pero complican la puesta en práctica y aumentan la probabilidad de problemas. incluyendo Informix Software Inc. la contribución de DRDA. Miramos hacia adelante al lanzamiento de los productos adicionales que apoyan las especificaciones de DRDA. todavía debe ser mejorada.pueda causar interrupciones indeseadas. están interesados en usar DRDA para comunicarse con el anfitrión. Otra tecnología a mirar de cerca es JSQL o SQLJ. La adopción de DRDA debe vigorizar el mercado de las bases de datos con la estandarización de los productos existentes en cuanto a la conectividad y las nuevas ofrendas de la interoperabilidad. DRDA permitirá a la generación siguiente de los conductores de OLE/DB y de JDBC lograr el nivel más alto del funcionamiento gozado actualmente por los usos de ODBC. y eliminar los sistemas de entradas o el software propietario del anfitrión requeridos para tener acceso a IBM DB2." Aunque DRDA se coloca como estándar de la interoperabilidad entre las plataformas heterogéneas. y necesitamos una manera simple y constante de obtener y de manipular los datos de todas estas fuentes. Los usos de la web usando JDBC o los procedimientos almacenados SQLJ (vía DRDA y TCP/IP). los usuarios pueden tener acceso a bases de datos remotas usando un formato estándar de la mensajería sobre TCP/IP o SNA. Las entradas múltiples funcionan." dijo Tony Gualtieri. "la adición de DRDA a la biblioteca del grupo abierto de especificaciones será muy beneficiosa para la industria." Sin embargo. son la manera más eficiente de reutilizar habilidades en las cuales su compañía ya ha invertido. Usted puede también tener acceso a otras fuentes del sistema de gestión de bases de datos relacionales (RDBMS). Las empresas podrán explotar el estándar de DRDA. Una operación de replicación en un sistema asíncrono como un DBMS distribuído corre sin bloqueos. no hay aislamiento de transacciones. se bajen gastos de explotación. por lo que ellas corren en paralelo sin ninguna garantia de que una transacción vea el estado más reciente de la base de datos haciendo una actualización. trabajan con los extractos de bases de datos corporativas. los vendedores del DBMS agregarán DRDA a sus servidores. Después. una parte distribuida pude depender de una base de datos principal y ser replicada en una oficina de ventas local. el crédito de la oficina de ventas será una copia de la base de datos principal. una actualización síncrona trabaja como un sistema con bloqueos. Si los fondos se transfieren de la cuenta de ahorro de un cliente. Un agente de una de esas oficinas recibe una orden de un cliente y una aplicación de venta lleva a cabo una mejora para asegurar que ese cliente tiene un crédito suficiente antes de procesar la orden. así que las bases de datos múltiples tienen que seguir sincronizadas. Las compañías pueden lograr esto de dos formas: de forma asíncrona o de forma síncrona. Con un sistema asíncrono. Ciertos usos de negocio diarios requieren la sincronización perfecta entre diversas bases de datos. Entonces DB2 (como ejemplo de DBMS que obedece el protocolo DRDA) podrá compartir sus datos. Por ejemplo. El cliente tendría que entrar en contacto con el banco para descubrir qué sucedió. sistemas del DBMS. los datos necesitan moverse partiendo de una base de datos a otra simultáneamente. y se proporcione un nivel más alto para el servicio del cliente. Las compañías están moviendo la información más cerca de usuarios finales y de clientes para que la productividad aumente. En otro ejemplo. y por consecuencia puede que se completen otras ordenes que no deberían de poder realizarse. El tratamiento transaccional distribuido basado en el protocolo DRDA también ofrecerá un mejor funcionamiento para las compañías que los actuales sistemas de entradas. las organizaciones tienen que asegurar que sus sistemas reconozcan transacciones válidas sólamentes cuando las actualizaciones de ambas bases de datos hayan sido totalmente completadas. Los días en que la información corporativa era almacenada solamente en una unidad central de proceso es agua pasada. los datos se almacenan en una variedad de lugares: sistemas del cliente. pero ni la aplicación ni los agentes de ventas lo saben. En este caso. pero sí tienen a menudo la capacidad de cambiarla. El cambio está creando desafíos logísticos porque los empleados y los clientes no pueden manipular solamente la información. Con una replicación síncrona (también conocida como confirmación en dos fases). y esa copia queda con datos desfasados. El resultado es un cliente furioso. en una transacción de las actividades bancarias. y servidores de la web. ese cliente desea tener la seguridad de que esos fondos entraron en la otra cuenta especificada en el mismo instante. pues en el futuro. Un fallo de la red puede evitar que la actualización sea terminada correctamente. servidores del uso. El dinero obtenido de la primera cuenta podría no haber sido transferido a la otra cuenta. el crédito del cliente ha bajado. . Completamente apoyando el protocolo de DRDA para las transacciones distribuidas. Por lo tanto. los vendedores facilitarán la carga de los clientes confiándolos en ambientes heterogéneos.El papel de DRDA en transacciones distribuidas DRDA provee el acceso a bases de datos distribuidas. En la mayoría de los casos. transacciones remotas corren concurrentemente y son serializadas con estrictos mecanismos de bloqueos y son tratadas como transacciones locales. Para evitar ambos escenarios. Además. Mientras esta técnica de trabajo es buena solamente para un vendedor de DBMS. una corporación podría tener que instalar DBMSs de múltiples vendedores. como el ecommerce. DRDA es un protocolo ligero que trata muy bien las cuestiones de interoperabilidad. usando DRDA las aplicaciones no sufrirán cambios.org/publications/catalog/c812. Una solución eficiente es usar una interface ODBC con transacciones basadas en CICS.htm (DRDA Volume 2Formatted Data Object Content Architecture). and c814. La característica de la confirmación en dos fases ha sido disponible y desplegada en los principales sistemas de gestión de bases de datos: DB2 de IBM. Dynamic Server de Informix. . las tecnologías DRDA van a brillar mucho en este mercado. Este no es el caso con la confirmación en dos fases de la transmisión síncrona. resultando que ambas actualizaciones serán confirmadas o ambas serán canceladas con un rollback como una unidad. los distribuidores han contado con protocolos propietarios que implementan la confirmación en dos fases.opengroup. DRDA. y los caminos a menudo requieren mantenimiento continuo. permitirá a las compañías instalar sistemas de una forma más sencilla y a un menor coste. Oracle y SQL Server de Sybase Inc. Las compañías se están moviendo en aplicaciones desplegadas. como StarQuest Software’s StarSQL.htm (DRDA Volume 1Distributed Relational Database Architecture). Sin embargo. c813. donde los datos críticos están almacenados en múltiples sistemas y la confirmación en dos fases es un requerimiento absoluto. La confirmación en dos fases entonces garantiza la integridad de los datos en todas las bases de datos. el despliegue dificultoso. Este proceso puede ser caro. Con esta aproximación. los conflictos de actualizaciones pueden ocurrir si las aplicaciones confirman actualizaciones incompatibles de dos o más datos replicados. por ejemplo CICS o MQ Series. en su forma natural.htm (DRDA Volume 3Distributed Data Management). En este caso. ambas transacciones son confirmadas como una unidad. La existencia de esas actualizaciones concurrentes no serán detectadas hasta después de que sean propagadas a las demás bases de datos. con una aplicación servidora DRDA en el componente host que es capaz de aceptar peticiones DRDA y luego ejecutar transacciones CICS.Con un mecanismo de transmisión asíncrona. el trabajo externo es necesario en un entorno heterogéneo. los soportes DRDA serán adaptados para incluír acceso directo a otros recursos. las acciones de transacciones con confirmación en dos fases son tomadas como un grupo y se vigila que no se viole ninguna de las restricciones de integridad asociadas al sistema. por eso es ideal para usarse con las nuevas aplicaciones e-commerce. En este escenario. Las especificaciones para DRDA están disponibles en la web del grupo abierto: http://www. En el futuro. Por tanto. Los sistemas basados en DRDA. SQL Server de Microsoft. es un protocolo especificado para empresas. Funciones de DRDA Tres funciones son utilizadas por DRDA para proporcionar el acceso distribuido de los datos: • • • Solicitante Del Uso (AR) Servidor Del Uso (COMO) Servidor De la Base de datos (Ds) Estas tres funciones interaccionan con otras para permitir el acceso distribuido. Servidor Del Uso La función del servidor del uso de DRDA (COMO) es recibir peticiones de solicitantes del uso y procesarlas. el servidor de la base de datos procesará lo que puede y remitirá el resto a otro servidor de la base de datos. Examinemos más a fondo estas tres funciones. Como tal. Servidor De la Base de datos La función del servidor de la base de datos de DRDA (DS) es recibir peticiones de los servidores del uso o de otros servidores de la base de datos. distribuidos). Un ejemplo de esto es la conversión de los caracteres del ASCII al EBCDIC (o viceversa). En teoría. no puede haber necesidad de un RDBMS local. Es importante observar que una petición del servidor de la base de datos puede ser un componente de una declaración del SQL. Para ello se utiliza el protocolo de la ayuda de la base de datos. El protocolo de la ayuda del uso es responsable de proporcionar el nivel apropiado de la conversión de datos. y DRDA no requiere que el solicitante funcione en un sistema con un RDBMS local. Estas peticiones pueden ser declaraciones de SQL o peticiones de la preparacion del programa. Esto ocurriría cuando los datos se distribuyen a través de dos subsistemas y se solicita un ensamblaje. Esto es solamente necesario cuando diversas representaciones de datos están implicadas en la petición. El AR está conectado con COMO usando un protocolo de comunicación llamado el protocolo de la ayuda del uso. Solicitante Del Uso La función del solicitante del uso de DRDA (AR) es permitir la preparación de peticiones del SQL y del programa a ser solicitado por programas de uso. COMO actúa sobre las porciones que se pueden procesar y las transmiten al resto de los servidores de la base de datos de DRDA para el proceso subsecuente. Usando esta función. una porción se debe procesar en una localización. La declaración de la union está solicitando datos de las tablas en dos localizaciones diferentes. si todos los datos en los que usted está interesado se localizan físicamente en alguna parte (es decir. la otra porción en la otra localización. Vemos entonces que los servidores de la base de datos implicados en una petición distribuida no necesitan ser iguales. Estas peticiones pueden ser declaraciones del SQL o peticiones de la preparación del programa. Como el servidor del uso. los programas de uso pueden tener acceso a datos remotos. El AR acepta peticiones del SQL de un uso y las envía al servidor apropiado del uso (o a los servidores) para el proceso subsecuente. Esto es necesario si el RDBMS local no puede procesar la petición. Éste existe por las razones siguientes: • Para conectar un servidor del uso con un servidor de la base de datos . arquitecturas se examinan en las secciones siguientes: Programa avanzado para programar la comunicación (APPC) Estas La comunicación avanzada del Programa-a-Programa proporciona la ayuda de la comunicación del par-nivel basada en protocolos del LU 6. Con DDM.• Para conectar dos servidores de la base de datos Como el protocolo de la ayuda del uso. se empaquetan juntos tanto los datos como su descripción. y el tratamiento transaccional distribuido. El protocolo limitado del bloque realza el funcionamiento total reduciendo al mínimo el tráfico de la red. APPC/LU 6. Datos Ajustados a formato: Arquitectura Contenta Del Objeto (FD:OCA) FD:OCA es una arquitectura que prevé la distribución y el intercambio de datos ajustados al formato de campo. el protocolo limitado del bloque no se emplea. CDRA proporciona un método inequívoco de cualquier plataforma de SAA. sin embargo. Si el cursor no es inalterable (es decir. las filas pueden ser actualizadas). de modo que cualquier DBMS DRDA-obediente pueda entender su estructura y contenido. Cuando una petición se procesa totalmente. dentro del contexto de DRDA. Arquitectura De la Representación De Datos De Carácter (CDRA) La arquitectura de la representación de datos de carácter utilizada para asegurarse de que cualquier símbolo o carácter DBMS relacional SAA tiene el mismo significado. sin importar el cifrados subyacente. Arquitecturas y protocolos relacionados Para que DRDA exista. el servidor del uso debe informar al proceso de la petición (el solicitante del uso). se confía en otros protocolos establecidos.2 proporciona la comunicación y las instalaciones del tratamiento transaccional necesitadas para la cooperativa que procesa. Se utiliza este protocolo a menos que se emplee un cursor. el protocolo limitado del bloque puede ser utilizado. Cuando las filas se traen de un cursor inalterable. Gerencia De Datos Distribuida (DDM) La gerencia de datos de la arquitectura distribuida define las instalaciones para tener acceso a datos distribuidos a través de una red usando APPC y LU 6.2. el protocolo de la ayuda de la base de datos se utiliza para asegurar la compatibilidad de peticiones entre diversos servidores de la base de datos. El protocolo limitado del bloque pasa múltiples filas a la vez a través de la red.2 es una arquitectura avanzada de la comunicación que define los formatos y los protocolos para la comunicación entre las unidades lógicas funcionalmente equivalentes. ¿Cómo se logra esto? COMO pasa un código de retorno y un resultado fijados (si fue producido) de nuevo al AR.2. El código de retorno es el SQLSTATE (o SQLCODE). Usando FD:OCA. los datos distribuidos que se alcanzarán pueden residir en archivos o bases de datos relacionales. es la arquitectura usado en cualquier juego de caracteres de identificar datos . aunque también puede procesarse solamente una fila a la vez. El LU 6. Un RDBMS se implica. se debe tener cuidado con la documentación del sistema de registros y las fechas de extracciones en casos de que estén permitidas futuras modificaciones. Como ello implica replicar los datos. la capacidad distribuida de la petición implica la unidad distribuida del trabajo (que a su vez implica la unidad remota del trabajo). la distribución asistida por usuario no es considerada verdadéramente un acceso distribuído a los datos. Teóricamente. Cada nivel representa un aumento de la distribución. los niveles reflejan: • • el número de peticiones y de RDBMSes por unidad de trabajo el número de RDBMSes por petición En orden creciente de complejidad. A continuación hablaré de los 5 posibles niveles que se pueden considerar para una arquitectura DRDA: Los Cinco Niveles de DRDA Hay cinco niveles dentro de DRDA. el usuario debe: .Extraer los datos necesarios del sistema original . Para lograr la distribución Asistida por Usuario. Estos niveles se discuten con mayor detalle a continuación: a) Distribución Asistida por Usuario (user-assisted distribution) La distribución Asistida por Usuario es la forma más simple de distribución de los datos. A menudo. la distribución asistida por usuario no es ni siquiera incluida como una forma de DRDA. muchas veces. la distribución Asistida por Usuario es útil para producir fotos de tablas y peticiones satisfactorias. los cinco niveles de DRDA son: • • • • • Distribución Asistida por Usuario Petición Remota Unidad remota de trabajo (RUW) Unidad distribuida del trabajo (DUW) Petición Distribuida El resultado al ir aumentando los niveles es aditivo. Sin embargo. un nuevo esquema de codificación del carácter ).Cargar los datos extraídos al sistema solicitante Este es un procedimiento intenso y costoso que debería no ser tomado a la ligera. Incluso viendo estas limitaciones. bajo este nivel de DRDA. Además. Sin embargo.CDRA es necesario particularmente cuando los datos se transfieren entre un sitio de trabajo de PC (que usa código del ASCII) y un chasis (que usa código del EBCDIC). CDRA se puede ampliar para apoyar otros códigos (tales como Unicode. . el usuario final es consciente de la distribución y es un experto y participa en los accesos distribuidos. Por ejemplo. múltiples peticiones SQL. en el ámbito de un commit. pueden ser contenidas con sólo una unidad de trabajo. una sola sentencia SQL pude ser distribuída para leer o modificar un único RDBMS remoto con una única unidad de trabajo. y solo un RDBMS por petición SQL. Sin embargo. DRDA con DUW permite múltiples sentencias SQL para leer y/o modificar múltiples RDBMSs con sólo una unidad de trabajo. Para aclararnos. con RUW se puede acceder solo a un RDBMS. pero todavia se puede acceder solamente a un RDBMS por petición SQL. La siguiente Tabla muestra un pequeño resumen de los niveles de DRDA: DBMS por Nivel de DRDA Op. el protocolo de la confirmación en 2 fases debe sincronizar todas las plataformas afectadas. Por tanto. más de un RDBMS puede ser accedido por unidad de trabajo. RUW permite múltiples sentencias SQL. Esto requiere que esté establecido el protocolo de la confirmación en 2 fases. el SQL solo puede leer y/o modificar un RDBMS remoto con una unidad de trabajo. La confirmación en 2 fases distribuída es funcionalmente equivalente a la confirmación en 2 fases y es la que es llevada a cabo por DB2 cuando está ejecutado bajo CICS o IMS/TM. Cuando un programa DUW emite un commit. e) Petición distribuída (Distributed Request) DRDA con capacidad de peticiones distribuidas permite la distribución completa de los datos. Sencillamente. de SQL Asistido por Usuario Petición Remotas 1 >1 1 1 1 1 Unidad remota de trabajo . Cuando un DBMS soporta DRDA con capacidad de peticiones remotas. d) Unidad distribuida del trabajo (Distributed Unit of Work) La unidad distribuída del trabajo (DUW) se construye sobre la funcionalidad de la unidad remota de trabajo. una peticion SQL distribuída puede leer y/o actualizar múltiples RDBMSs al mismo tiempo. tanto distribuídas como no distribuídas. Sql DBMS por UOW Op. Como con cualquier unidad de trabajo. Símplemente. incluso si el RDBMS local no está siendo usado. solo un RDBMS puede ser especificado por sentencia SQL. la restricción del DUW de sólo un RDBMS por sentencia SQL es eliminada. es posible utilizar capacidades de peticiones remotas para acceder a RDBMS remotos. Adicionalmente.b) Peticiones remotas o alejadas (Remote Request) Las peticiones remotas es verdadéramente el primer nivel de distribución con DRDA. Ahora. DRDA con unidad remota de trabajo provee la capacidad de emitir múltiples peticiones SQL por unidad de trabajo. c) Unidad remota de trabajo (Remote Unit of Work) El nivel DRDA con unidad remota de trabajo (RUW) se añade a la funcionalidad de peticiones remotas. Usando peticiones distribuídas. Sencillamente. DRDA con peticiones remotas provee la capacidad de emitir solo una petición SQL por unidad de trabajo. Además. todas las peticiones SQL en el ámbito de un commit deben tener éxito o ser canceladas. Sin embargo. y remite a diferentes RDBMS. un promotor de peticiones remotas opera con un RDBMS. En este escenario. Las 4 tablas de las tres localizaciones pueden ser accedidas con una unidad de trabajo usando DRDA con funcionalidad DUW. Vamos a examinar cómo cada una de las 4 opciones de DRDA podrían acceder a datos distribuídos de esas localizaciones. Madrid y Barcelona. En un escenario de peticiones remotas. están permitidas varias sentencias. Consideramos una situación en la que necesitamos accesos por columnas específicas de tablas en cada una de las localizaciones remotas. en contraste está la funcionalidad de unidad remota de trabajo con peticiones remotas. la peticion de A Coruña ahora puede consistir en ambas peticiones select (una por cada tabla) con la misma unidad de trabajo. Este proceso puede y es pasado a uno de los otros servidores de base de datos ( por ej A Coruña). Usando peticiones distribuídas. la aplicación cliente emite una petición a la aplicación servidora de Madrid. Además. tenemos las peticiones distribuídas. La petición a una tabla de Madrid es una petición local. Hay cuatro tablas totales: dos en A Coruña. la unidad distribuída de trabajo permite múltiples RDBMSs por unidad de trabajo. Con RUW nosotros hemos pasado de cuatro UOWs a tres. asumimos que las peticiones proceden de Madrid. Cada petición viene incluída en una unidad de trabajo (indicado por un commit). Por tanto. y dos para A Coruña. cada uno con un RDBMS: A Coruña. Hay cuatro UOWs totales. Finalmente. nosotros podremos acceder solamente a un RDBMS de una localización en una sola unidad de trabajo. una por cada select a las dos tablas que existen en A Coruña.Unidad distribuida del trabajo Petición Distribuida Tabla : Los Cinco Niveles de DRDA >1 >1 >1 >1 1 >1 Ejemplo juntando todos estos niveles Consideramos un escenario donde son establecidas tres localizaciones de procesamiento remotos. una para Barcelona y Madrid. una en Madrid y otra en Barcelona. . Con las peticiones distribuídas no sólo tenemos un UOW. En vez de una única sentencia por unidad de trabajo. la cual enviará la petición al servidor de base de datos de Madrid. sino que podemos tener una petición SQL uniendo tablas de otras localizaciones. múltiples RDBMSs de varias localizaciones pueden ser accedidos usando solo una petición SQL. Después. las peticiones a A Coruña y Barcelona son remotas. Ahora. algunos de ellos demasiado curiosos. DRDA ) cualquier usuario puede modificar los datos. .Seguridad en nuestros sistemas La seguridad incorporada refleja la metodología más sólida de proceso y de diseño del desarrollo. son necesarias herramientas de seguridad activas y dinámicas. todo ello gracias a que la seguridad está integrada en el sistema operativo. la ley nos obliga a saber quien y como utiliza los datos y a garantizar la calidad de la misma. en los escenarios actuales. porque ¿qué sucedería si algún usuario no autorizado pudiera suprimir los fuentes de los programas o extraer y modificar la lista de los clientes. su gestión es compleja. nuevas herramientas y sobre todo por la interactividad entre distintos sistemas. y las antiguas estrategias de seguridad ya no nos sirven. Aunque el iSeries dispone de herramientas de recolección de la información de seguridad. o la lista de precios de una empresa? El escenario anterior a los cambios vividos en las empresas. en el que el AS400 (iSeries) operaba de forma aislada con conexiones a terminales "tontas" y que nos permitía con una pólitica básica de seguridad (menús y contraseñas) mantener la integridad del AS400 ha sido sustituido paulatinamente por conexiónes de redes locales. por lo que en algunos casos. Por suerte para nosotros el AS400 partía y parte con un sistema de seguridad muy robusto en lo que respecta a las conexiones "tontas". contabilidad. JDBC. que nos sirvan para prevenir riesgos antes de que sucedan. Pero cuando se integra en una red o permitimos el acceso desde aplicaciones externas (ODBC. estamos obligados a realizar auditorias de seguridad en nuestros sistemas y a tener logs de quien y cuando modifica un dato. La seguridad es imprescindible. lo cual "abre" nuestros sistemas a millones de usuarios. Además Internet forma parte de la infraestructura de operación de las empresas. Además de disponer de una buena política de seguridad. aplicaciones cliente-servidor. lo cual nos obliga a modificar y actualizar constantemente nuestras medidas de seguridad. Además. la facturación. Oracle y Sybase. Esta compatibilidad con DRDA también permitirá a los administradores hacer que las aplicaciones remotas que se ejecuten en hosts IBM y AS/400 establezcan conexiones SQL remotas (Connect) con SQL Server. En segundo lugar. la compatibilidad de Host Integration Server 2000 con DRDA permitirá a las aplicaciones acceder a bases de datos de SQL Server mediante una conexión par a par como si el sistema en el que se encontrara SQL Server fuera un host IBM. con Host Integration Server 2000. Todos sabemos que el mundo de las tecnologías avanza contínuamente y siempre aparecen nuevos productos que intentan mejorar los anteriores. con SNA Server. Microsoft pretendía ofrecer un nivel básico de conectividad entre hosts (unidades centrales). VSAM y OS/400 utilizarán TCP/IP y SNA. DB2. Al igual que hizo con SNA Server. profundizó en el campo de la integración de aplicaciones. OS/400. Host Integration Server 2000 puede funcionar como servidor DRDA encaminando las peticiones DRDA que reciba hacia un sistema SQL Server de Microsoft. Host Integration Server 2000 Microsoft sustituyó su SNA Server. Host Integration Server 2000 incluye también varios controladores ODBC (Open DataBase Connectivity o Conectividad abierta de bases de datos) y proveedores OLE DB que amplían el acceso a datos de las aplicaciones de Microsoft Office y BackOffice a DB2. Host Integration Server 2000 incluye controladores ODBC para DB2. una de las principales mejoras que incluía Host Integration Server 2000 en el campo del acceso a los datos es la compatibilidad con DRDA (Distributed Relational DataBase Architecture o Arquitectura distribuida de bases de datos) de IBM. Virtual Storage Access Method (VSAM). DB2/400. además de ofrecer ese nivel básico de conectividad. Por su parte. OS/400 y Sybase.Algunos ejemplos de productos relacionados con DRDA Han sido muchos los productos que han salido al mercado y que soportan el protocolo DRDA. En cuanto a la Interoperabilidad del acceso a datos. el controlador ODBC y el proveedor OLE DB para Oracle exigirán la previa instalación de la compatibilidad en tiempo de ejecución con clientes de Oracle. Oracle. Si. Otra función relativa a la integración del acceso a datos que incluyó Microsoft en Host Integration Server 2000 es la de replicación heterogénea. Sin embargo. IBM desarrolló esta arquitectura para hacer posibles las operaciones entre bases de datos distribuidas. Tanto el controlador ODBC como el proveedor OLE DB para DB2. por ejemplo) acceder a bases de datos de SQL Server de la misma forma que acceden a bases de datos DB2 de otros hosts remotos. Pero también es cierto que a Host Integration Server 2000 aún le faltaban varias piezas del rompecabezas de la interoperabilidad empresarial. parte de la suite empresarial BackOffice. Esta función permite la replicación bidireccional entre SQL Server. Oracle y Sybase. por su último servidor de interoperabilidad empresarial. DB2/400 y Oracle mediante la . DB2. Microsoft se proponía ahondar en el nivel de integración que ofrece el servidor. En esta sección expondré alguno de estos productos que han ido apareciendo a lo largo de estos años. Esta función permitirá a los hosts de IBM y demás productos que sean compatibles con DRDA (Data Propagator. uno de los principales objetivos que perseguía Microsoft con Host Integration Server 2000 era superar las limitaciones que presenta SNA Server y adoptar plenamente TCP/IP como protocolo de red subyacente. cuyo nombre en clave era Babylon y que finalmente se denominaría Host Integration Server 2000. Microsoft diseñó Host Integration Server 2000 para integrar los mainframes IBM y AS/400 en redes de Windows. Además. así como proveedores OLE DB para VSAM. con lo que se ahorran ciclos de CPU. Los productos “HiT Middleware ODBC y OLE DB” son totalmente compatibles en entorno de Microsoft Transaction Server para aplicaciones Windows. como los paquetes estáticos de SQL son creados por el “HiT SQL Middleware”. DB2. La replicación heterogénea que ofrece Host Integration Server 2000 ampliaba el esquema de replicación básico de SNA Server y SQL Server 7. La replicación heterogénea se ejecuta en Host Integration Server 2000 como un servicio de NT y funciona creando un conjunto de activadores (triggers) que deben incluirse en la base de datos del host. algunos cambios temporales en la base de datos podían causar decisiones inapropiadas y pérdidas importantes. SQL Server 7. Oracle y DB2/400. La performance del servidor DB2 se mejora debido a que no se requiere un acceso dinámico a los datos SQL. a formar parte de una tabla de transacciones ubicada en el host a la que se accede mediante uno de los proveedores OLE DB de Host Integration Server 2000. Windows y JAVA soportan DB2 UDB para OS/390 v6. así como la posibilidad de replicar datos de DB2. entonces. La replicación incremental consiste en el envío al suscriptor de los cambios incrementales que se vayan produciendo con una periodicidad tal que casi se efectúe en tiempo real. se puede fortalecer la estructura de seguridad para esos paquetes mas que para las tablas DB2. Como ya indica su nombre. El producto “HiT JDBC SQL” cumple con los standard XA de la industria para aplicaciones en JAVA. No .tecnología de replicación instantánea.1. la replicación instantánea consiste en la transferencia periódica de una copia de la totalidad de los datos al suscriptor. Como consecuencia.0 . Host Integration Server 2000 mejoraba esta función al permitir los tipos de replicación incremental y por fusión. En octubre de 2002 HiT Software anunció que la nueva versión de sus productos “middleware” para SQL. por su parte. El soporte estático sobre SQL permite desarrollos para precompilar las sentencias SQL usadas dentro de una aplicación para incrementar significativamente la “performance” (rendimiento) de la aplicación cliente. Sin el soporte para transacciones distribuidas. Al permitir transacciones distribuidas. OS/390 y OS/400. Oracle y DB2/400 en SQL Server. DB2 UDB for OS/400 V5R1 y posteriores versiones DB2 sobre estas plataformas. La replicación por fusión permite. OLE DB y JDBC permitían transacciones distribuidas y estáticas para base de datos DB2 corriendo sobre plataformas con sistemas operativos z/OS. liberar recursos de CPU del servidor y utilizar al máximo las ventajas de seguridad en el acceso a los datos. OS/390 y OS/400. También. incremental y por fusión. Ambos productos. El soporte estático de SQL de HiT no requiere la modificación del cliente ni de la aplicación DB2 server e incluye utilidades para precompilar y unir paquetes de sentencias SQL en un servidor DB2. Estos activadores pasan.0 permite la replicación instantánea unidireccional en VSAM. las aplicaciones debían actualizar las bases de datos individualmente y un potencial cambio en las grabaciones múltiples produciría un fallo en la actualización de la base de datos. ODBC. las aplicaciones podían confirmar las actualizaciones de múltiples bases de datos antes de permitir una transacción. que las sedes autónomas efectúen fusiones bidireccionales periódicas de todos los cambios que se produzcan en las bases de datos. Productos HiT Software HiT Software lanzó al mercado una línea de productos completa para SQL de aplicación sobre sistemas “DB2 Distributed Transactions and Static SQL” aplicable sobre sistemas operativos z/OS. Los proveedores OLE DB permiten al servicio de replicación heterogénea de Host Integration Server 2000 acceder a los datos del host sin necesidad de que exista en éste ningún otro componente para la replicación. todos los productos “HiT SQL middleware” soportan SSL v3.es necesario instalar software adicional en el servidor para estos entornos. Las aplicaciones Windows y JAVA usando conectividad estándar SQL pueden migrar a la nueva versión de HiT Software a fin de utilizar todas las ventajas y potencialidad del acceso directo y las transacciones distribuidas. como: • Arquitectura De la Representación De Datos De Carácter (CDRA) • Arquitectura Distribuida De la Gerencia De Datos (DDM) • Arquitectura Ajustada al formato Del Contenido Del Objeto De los Datos (FD:OCA) . El HiT ODBC. En terminología de DRDA. DRDA utiliza también otras arquitecturas. OLE DB y JDBC SQL con soporte para transacciones distribuidas ya se encuentra disponible..2 o posterior.. Un servidor del uso (COMO) es el código que maneja el extremo de la base de datos de la conexión.0 cuando se los usa con el “HiT SSL Server” para una autenticación segura y encriptado de datos transportados entre las aplicaciones y los servidores DB2. El HiT ODBC y OLE DB SQL middleware se puede instalar en sistemas operativos Windows XP. . El producto HiT JDBC SQL se puede instalar en cualquier plataforma JDK 1. DB2 Connect Explotando completamente la arquitectura de DRDA. DB2 Connect puede funcionar solamente como solicitante del uso. es el uso que está solicitando datos. un solicitante del uso (AR) es el código que maneja el extremo del uso de una conexión distribuida. Además. clientes NT y servidores. Los productos HiT Software soportan Arquitectura distribuida de base de datos relacional de IBM (DRDA) y los protocolos de optimización de la base de datos. DB2 Connect oferta una solución barata con las características de los sistemas que demandan los clientes. Para poner las conexiones entre los sistemas de gerencia de la base de datos del servidor de DRDA y los clientes de la base de datos. 2000 y 9X. La siguiente figura muestra el flujo de datos entre el servidor DB2 Connect y el anfitrión o el servidor de los iSeries en el caso donde haya clientes locales solamente. y ellos se interrelacionan como un cliente estándar con una base DB2. DB2 Connect pasa estas sentencias al servidor de sistema principal o iSeries. como por ejemplo la longitud máxima de columna. DB2 Connect acepta algunas sentencias de SQL que DB2 Universal Database no soporta. ésta también puede acceder a la base de datos OS/390 o VSE utilizando DB2 Connect. la portabilidad de las sentencias de SQL en Lenguaje de definición de datos (Data Definition Language . y la interfaz del nivel de la llamada DB2 (DB2 CLI).Una petición se encamina a la destinación correcta por medio de los directorios que contienen varios tipos de información de la comunicación y del nombre de la base de datos del servidor de DRDA que es alcanzada. no define los interfaces de programación. zSeries e iSeries. Estas herramientas son parte del cliente de DB2. Todos los servidores de DRDA que hay disponibles pueden ejecutar peticiones SQL remitidas por un programa de uso con DB2 Connect. como por ejemplo DB2 Universal Database para OS/390 y z/OS. El cliente DB2 Connect apoya varios tipos de API: SQL encajado. DB2 Connect le permite utilizar las API siguientes con productos de base de datos de sistemas principales. hay que consultarlo en los límites de SQL (algún manual sobre SQL). pero las de la tercera categoría habrá que cambiarlas antes. En general. • Estén disponibles en todos los productos de bases de datos relacionales de IBM (vea la información de consulta de SQL para obtener más detalles).DDL) no es tan grande como la de las que están en Lenguaje de manipulación de datos (Data Manipulation Language . Puede crear nuevas aplicaciones o modificar las aplicaciones existentes para que se ejecuten en un entorno de sistema principal o iSeries. Por ejemplo. • Sean exclusivas para el sistema de base de datos al que acceda. Si se traslada una aplicación CICS desde OS/390 o VSE para que se ejecute bajo otro producto CICS (por ejemplo. La portabilidad de las sentencias de SQL de las dos primeras categorías es muy grande. JDBC. o APIs. una aplicación que se ejecute en Windows puede acceder a datos de una base de datos DB2 Universal Database para OS/390 y z/OS. Se puede encontrar con sentencias de SQL que: • Sean iguales para todos los productos de base de datos que utilice. DB2 Connect permite que un programa de aplicación acceda a datos de bases de datos DB2 en servidores System/390. Para obtener más detalles se tendría que consultar los manuales CICS/6000 Application Programming Guide y CICS Customization and Operation. SQLJ. Aunque DRDA define protocolos de comunicación de la base de datos. y de varias plataformas de Unix. independientemente de los estándares. IBM provee las herramientas para generar las peticiones SQL para Windows. tanto estático como dinámico • La Interfaz a nivel de llamada de DB2 • La API ODBC de Microsoft • JDBC Algunas sentencias de SQL difieren según los productos de base de datos relacional. Para obtener información sobre los límites en las distintas plataformas.DML). . Estos APIs pueden ser utilizados por los programadores para construir usos en una variedad de lenguajes de programación. que deben ser utilizados por los programadores. También es posible desarrollar aplicaciones en un entorno y trasladarlas a otro. siempre que dichos productos soporten estos elementos: • SQL incorporado. CICS para AIX). Intranet o Extranet sin la instalación de ningún middleware propietario.0 o más alto Netscape Navigator 4. Los gracias a su funcionamiento optimizado. Cualquier otro browser compatible de Java 1. Se garantiza el acceso a todos los usos de Java y los Java applets que apoyan JDBC. Gracias a HOBLink J-drda.1 del Netscape Navigator. HOBLink J-drda ofrece todos los browsers modernos de la web y los ambientes de Java que tienen acceso a las bases de datos. HOBLink J-DRDA se conforma con la especificación de los microsystems JDBC 2. e. HOBLink J-drda es un conductor del tipo 4 de JDBC que permite conectividad de la base de datos a las bases de datos DB2 sobre cualquier red de TCP/IP.HobLink HOBLink J-DRDA es el conductor puro de Java JDBC del protocolo nativo que utiliza DRDA para conectarse con DB2 y otras bases de datos compatibles de DRDA. Para usar HobLink J-DRDA se requiere alguno de los siguientes casos: o o o o Ambiente runtime 1.0 API del SOL.02 con la ayuda del JDK 1. HotJava . en un ambiente heterogéneo.1. HOBLink J-drda permite acceso directo vía Internet. usted puede hacer bases de datos centrales accesibles a cada usuario.1 de Jave o más alto Microsoft Internet Explorer 4.g.