TRABAJO DE ARQUITECTURA

CLIENTE/SERVIDOR

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.

Unidad del trabajo:

Una unidad del trabajo (UOW) es una sola transacción lógica. Consiste en una secuencia de declaraciones del SQL en las cuales o todas las operaciones se realizan con éxito, o la secuencia en su totalidad se considera fracasada.

Unidad distribuida del trabajo

Una unidad distribuida del trabajo (DUOW) , también conocida como actualización del multisite, es una función que permite a sus usos poner al día datos en servidores alejados de la base de datos, garantizándose la integridad de los mismos. Por ejemplo, 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.

Los productos de DB2 proporcionan la ayuda comprensiva para las actualizaciones del multisite. 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).

La unidad distribuida del trabajo implica más de un servidor de la base de datos dentro de una 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.

• Puede haber peticiones múltiples por unidad del trabajo.

• Hay un servidor de la gestión de la base de datos por petición.

• La comisión se coordina a través de los servidores múltiples 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. Mientras que un programa de uso puede poner al día varias bases de datos remotas, puede tener acceso solamente a una base de datos dentro de una unidad de trabajo.

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.

La petición distribuida proporciona la transparencia de la localización para los objetos de la base de datos. Si se mueve la información (en tablas), las referencias a esa información (llamada alias ) pueden ser actualizadas sin ningun cambio a los usos o programas que solicitan la información. La petición distribuida también proporciona la remuneración para DBMSs que no apoyan todo el dialecto de DB2 SQL, o ciertas capacidades de la optimización. Las operaciones que no se pueden realizar bajo tal DBMS (tal como SQL recurrente) funcionan debajo de DB2.

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. En el pasado, si los usuarios desearon intercambiar datos de diversas bases de datos, tuvieron que utilizar una mezcla de entradas propietarias, software e interfaces de programación no estándar. Hoy, 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. La respuesta es la arquitectura distribuida de bases de datos relacionales (DRDA). ¿La pregunta es, podrá crecer y llenar funciones adicionales importantes en la empresa de los datos?

En 1998 cuando el grupo abierto (Open Group), que es el consorcio de la industria para promover tecnologías abiertas, anunció su adopción del protocolo de DRDA, miraba un estándar de la industria para la interoperabilidad del acceso de base de datos. Tres años antes, IBM ofreció el protocolo de DRDA al grupo abierto y ciertos vendedores opusieron su adopción. La demanda específica de los clientes-miembros del grupo abierto ayudó a empujarlo para su revisión y adopción. Pero muchas compañías internacionales utilizaban ya los productos que la apoyaron. El encargado del servicio de la gerencia de datos de Boeing, Jim Presti, dijo, "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. Los estándares nos ayudan a reducir la variación dentro de nuestros usos, a disminuir nuestro coste para crear y sostener usos, y a mejorar la calidad total de los usos que resultan."

La idea es que un sólo estándar simplificará las comunicaciones entre los usos y las bases de datos, y entre diversas bases de datos.

El protocolo DRDA incluye las características para el acceso de bases de datos relacionales, de alto rendimiento, basado en SQL, y el flujo optimizado de alto rendimiento de la red basado en técnicas de codificación compactas. 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).

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, IBM y no IBM. 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. DRDA coordina la comunicación entre los sistemas definiendo qué debe ser intercambiado y cómo debe ser intercambiado.

Resumiendo, ¿Qué es DRDA?

DRDA es un sistema de protocolos, o de reglas, que permiten a un usuario tener acceso a los datos distribuidos sin importar donde residen físicamente. Proporciona un ambiente de base de datos distribuido heterogéneo, abierto y robusto. DRDA proporciona métodos para coordinar la comunicación entre localizaciones distribuidas. Esto permite que se tenga acceso a tablas alejadas en múltiples y varias localizaciones, y que al usuario del otro extremo le parezca como si estuvieran todas en un mismo ente lógico.

Una distinción se debe hacer, sin embargo, entre la arquitectura y la puesta en práctica. DRDA describe la arquitectura para los datos distribuidos y nada más. Define las reglas para tener acceso a los datos distribuidos, pero no proporciona los interfaces de programación de uso reales (APIs) para realizar el acceso. DRDA no es un programa real, sino es más como las especificaciones para un programa.

Cuando un DBMS se dice que es DRDA-obediente, implica que sigue las especificaciones de DRDA. DB2 es un producto DRDA-obediente de RDBMS.

En resumen, DRDA es un estándar para distribuir la información de las bases de datos que tienen acceso a través de plataformas IBM, que siguen estándares del SQL.

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, DBM, 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. Por ejemplo, un subsistema DB2 puede comunicarse con otro subsistema DB2 . Alternativamente, un subsistema DB2 puede comunicarse con un RDBMS de una tercera persona.

Las plataformas no necesitan ser iguales. Mientras ambos se conformen con las especificaciones de DRDA, podrán comunicarse. DRDA se puede considerar una clase "de protocolo universal para realizar el distribuido de los datos."

Este trabajo describirá DRDA. Pero hay que tener presente que ningún vendedor ha puesto en marcha un RDBMS que apoya completamente toda la funcionalidad de DRDA.

Ventajas de DRDA

DRDA es solamente un protocolo para apoyar RDBMS. Además, 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. Cualquier producto que siga estas reglas puede integrarse con cualquier otro producto DRDA-obediente.

La ventaja más grande, sin embargo, es que hoy está muy disponible, y muchos vendedores están saltando al carro de la conformidad con DRDA.

Un alternativa a DRDA es utilizar un producto de entradas para tener acceso a datos distribuidos. Las entradas abarcan por lo menos a dos componentes, uno para cada localización distribuida. Estas piezas se comunican el uno con el otro. Las entradas, sin embargo, típicamente apoyan solamente el SQL dinámico.

Por lo tanto, 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, no es la única arquitectura en la industria. 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 será el método que usted utiliza para poner datos distribuidos en ejecucion con DB2 (por ejemplo).

• DRDA fue construido para trabajar con un subconjunto estándar del SQL que está disponible del DBMS para el DBMS.

• DRDA fue construido para funcionar con la extensión y plataforma específica al SQL.

• El SQL estático se puede utilizar con DRDA; con RDA solamente el SQL dinámico está disponible.

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, mientras que DRDA trata la edición de la interoperabilidad. Estos dos tipos de estándares son complementarios. El anterior se asegura de que haya conductores en cada plataforma que pueda entender la sintaxis del lenguaje, 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. 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.

El encargado de los datos del DB2 LM Ericsson, Roger Johnson, dijo: "el protocolo estándar de DRDA reducirá los costes para el software, la educación, y el mantenimiento. Si usted diseña sus usos con DRDA y TCP/IP, usted necesita solamente un cliente y el servidor OS/390. No habrá ninguna entrada adicional que pueda causar interrupciones indeseadas. Los usos de la web usando JDBC o los procedimientos almacenados SQLJ (vía DRDA y TCP/IP), o usando DB2 que tiene acceso para OS/390 vía el web server OS/390, 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), tales como Sybase, Informix, servidor de MS/SQL, y otras fuentes vía DataJoiner usando DRDA; pero en este caso usted necesita una entrada."

Sin embargo, la contribución de DRDA, moviéndose más allá de interoperabilidad del acceso a bases de datos, todavía debe ser mejorada.

¿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. 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. Actualmente, muchos vendedores, incluyendo Informix Software Inc., Oracle Corp., y Sybase Inc. , han licenciado las especificaciones de DRDA. El grupo abierto está supervisando el progreso de DRDA, enterado que otras organizaciones se están moviendo para adoptar DRDA.

"la adición de DRDA a la biblioteca del grupo abierto de especificaciones será muy beneficiosa para la industria," dijo Tony Gualtieri, arquitecto en las compañías de seguros de Kemper. "Kemper utiliza DBMSs de vendedores múltiples, y necesitamos una manera simple y constante de obtener y de manipular los datos de todas estas fuentes. Las entradas múltiples funcionan, pero complican la puesta en práctica y aumentan la probabilidad de problemas. Miramos hacia adelante al lanzamiento de los productos adicionales que apoyan las especificaciones de DRDA."

Aunque DRDA se coloca como estándar de la interoperabilidad entre las plataformas heterogéneas, DRDA es también el protocolo nativo usado por DB2/MVS de IBM. 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. Los usuarios pueden también esperar que el uso de DRDA sea encajado en entradas de CORBA y nuevos modelos basados en RPCs, así como llegar a ser ordinarios en otros productos de la red.

Usando este tipo de producto y un cliente DRDA, los usuarios pueden tener acceso a bases de datos remotas usando un formato estándar de la mensajería sobre TCP/IP o SNA, y eliminar los sistemas de entradas o el software propietario del anfitrión requeridos para tener acceso a IBM DB2.

En el lado de UNIX, los servidores de la web están conduciendo la demanda para la conectividad a las bases de datos de IBM. Muchas de las compañías, particularmente en las actividades bancarias y los sectores financieros, están interesados en usar DRDA para comunicarse con el anfitrión. 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.

Otra tecnología a mirar de cerca es JSQL o SQLJ. JavaBeans podría hacer una parte importante de e-commerce proporcionando un interfaz simple a las transacciones bien definidas de DRDA. IBM se centró originalmente en DRDA como tecnología back-end para los applets basados en Java, altamente eficientes que obrarían recíprocamente en el servidor back-end.

El papel de DRDA en transacciones distribuidas

DRDA provee el acceso a bases de datos distribuidas. Las empresas podrán explotar el estándar de DRDA, pues en el futuro, los vendedores del DBMS agregarán DRDA a sus servidores. Entonces DB2 (como ejemplo de DBMS que obedece el protocolo DRDA) podrá compartir sus datos. Completamente apoyando el protocolo de DRDA para las transacciones distribuidas, los vendedores facilitarán la carga de los clientes confiándolos en ambientes heterogéneos. 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.

Los días en que la información corporativa era almacenada solamente en una unidad central de proceso es agua pasada. Las compañías están moviendo la información más cerca de usuarios finales y de clientes para que la productividad aumente, se bajen gastos de explotación, y se proporcione un nivel más alto para el servicio del cliente. Por lo tanto, los datos se almacenan en una variedad de lugares: sistemas del cliente, servidores del uso, sistemas del DBMS, y servidores de la web.

El cambio está creando desafíos logísticos porque los empleados y los clientes no pueden manipular solamente la información, pero sí tienen a menudo la capacidad de cambiarla. En la mayoría de los casos, trabajan con los extractos de bases de datos corporativas, así que las bases de datos múltiples tienen que seguir sincronizadas. Ciertos usos de negocio diarios requieren la sincronización perfecta entre diversas bases de datos. Por ejemplo, en una transacción de las actividades bancarias, los datos necesitan moverse partiendo de una base de datos a otra simultáneamente. Si los fondos se transfieren de la cuenta de ahorro de un cliente, ese cliente desea tener la seguridad de que esos fondos entraron en la otra cuenta especificada en el mismo instante. Un fallo de la red puede evitar que la actualización sea terminada correctamente. El dinero obtenido de la primera cuenta podría no haber sido transferido a la otra cuenta. El cliente tendría que entrar en contacto con el banco para descubrir qué sucedió. El resultado es un cliente furioso.

En otro ejemplo, una parte distribuida pude depender de una base de datos principal y ser replicada en una oficina de ventas local. 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. Después, el crédito de la oficina de ventas será una copia de la base de datos principal, y esa copia queda con datos desfasados. En este caso, el crédito del cliente ha bajado, pero ni la aplicación ni los agentes de ventas lo saben, y por consecuencia puede que se completen otras ordenes que no deberían de poder realizarse.

Para evitar ambos escenarios, 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. Las compañías pueden lograr esto de dos formas: de forma asíncrona o de forma síncrona.

Una operación de replicación en un sistema asíncrono como un DBMS distribuído corre sin bloqueos; una actualización síncrona trabaja como un sistema con bloqueos. Con un sistema asíncrono, no hay aislamiento de transacciones, 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. Con una replicación síncrona (también conocida como confirmación en dos fases), transacciones remotas corren concurrentemente y son serializadas con estrictos mecanismos de bloqueos y son tratadas como transacciones locales.

Con un mecanismo de transmisión asíncrona, los conflictos de actualizaciones pueden ocurrir si las aplicaciones confirman actualizaciones incompatibles de dos o más datos replicados. La existencia de esas actualizaciones concurrentes no serán detectadas hasta después de que sean propagadas a las demás bases de datos. Este no es el caso con la confirmación en dos fases de la transmisión síncrona. Con esta aproximación, ambas transacciones son confirmadas como una unidad, resultando que ambas actualizaciones serán confirmadas o ambas serán canceladas con un rollback como una unidad. Además, 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. La confirmación en dos fases entonces garantiza la integridad de los datos en todas las bases de datos.

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, SQL Server de Microsoft, Oracle y SQL Server de Sybase Inc. Sin embargo, los distribuidores han contado con protocolos propietarios que implementan la confirmación en dos fases. Mientras esta técnica de trabajo es buena solamente para un vendedor de DBMS, el trabajo externo es necesario en un entorno heterogéneo. En este escenario, una corporación podría tener que instalar DBMSs de múltiples vendedores. Este proceso puede ser caro, el despliegue dificultoso, y los caminos a menudo requieren mantenimiento continuo.

Las compañías se están moviendo en aplicaciones desplegadas, como el e-commerce, donde los datos críticos están almacenados en múltiples sistemas y la confirmación en dos fases es un requerimiento absoluto. Los sistemas basados en DRDA, como StarQuest Software's StarSQL, permitirá a las compañías instalar sistemas de una forma más sencilla y a un menor coste.

En el futuro, los soportes DRDA serán adaptados para incluír acceso directo a otros recursos, por ejemplo CICS o MQ Series. DRDA es un protocolo ligero que trata muy bien las cuestiones de interoperabilidad. DRDA, en su forma natural, es un protocolo especificado para empresas, por eso es ideal para usarse con las nuevas aplicaciones e-commerce. Una solución eficiente es usar una interface ODBC con transacciones basadas en CICS, con una aplicación servidora DRDA en el componente host que es capaz de aceptar peticiones DRDA y luego ejecutar transacciones CICS. En este caso, usando DRDA las aplicaciones no sufrirán cambios. Por tanto, las tecnologías DRDA van a brillar mucho en este mercado.

Las especificaciones para DRDA están disponibles en la web del grupo abierto:

http://www.opengroup.org/publications/catalog/c812.htm (DRDA Volume 1-Distributed Relational Database Architecture), c813.htm (DRDA Volume 2-Formatted Data Object Content Architecture), and c814.htm (DRDA Volume 3-Distributed Data Management).

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. Examinemos más a fondo estas tres funciones.

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. 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. Usando esta función, los programas de uso pueden tener acceso a datos remotos.

En teoría, si todos los datos en los que usted está interesado se localizan físicamente en alguna parte (es decir, distribuidos), no puede haber necesidad de un RDBMS local, y DRDA no requiere que el solicitante funcione en un sistema con un RDBMS local.

Servidor Del Uso

La función del servidor del uso de DRDA (COMO) es recibir peticiones de solicitantes del uso y procesarlas. Estas peticiones pueden ser declaraciones de SQL o peticiones de la preparacion del programa. 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. Esto es necesario si el RDBMS local no puede procesar la petición.

El AR está conectado con COMO usando un protocolo de comunicación llamado el protocolo de la ayuda del uso. El protocolo de la ayuda del uso es responsable de proporcionar el nivel apropiado de la conversión de datos. Esto es solamente necesario cuando diversas representaciones de datos están implicadas en la petición. Un ejemplo de esto es la conversión de los caracteres del ASCII al EBCDIC (o viceversa).

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. Estas peticiones pueden ser declaraciones del SQL o peticiones de la preparación del programa. Como el servidor del uso, el servidor de la base de datos procesará lo que puede y remitirá el resto a otro servidor de la base de datos.

Es importante observar que una petición del servidor de la base de datos puede ser un componente de una declaración del SQL. Esto ocurriría cuando los datos se distribuyen a través de dos subsistemas y se solicita un ensamblaje. La declaración de la union está solicitando datos de las tablas en dos localizaciones diferentes. Como tal, una porción se debe procesar en una localización; 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. Para ello se utiliza el protocolo de la ayuda de la base de datos. Éste existe por las razones siguientes:

• Para conectar un servidor del uso con un servidor de la base de datos

• Para conectar dos servidores de la base de datos

Como el protocolo de la ayuda del uso, 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.

Cuando una petición se procesa totalmente, el servidor del uso debe informar al proceso de la petición (el solicitante del uso). ¿Cómo se logra esto?

COMO pasa un código de retorno y un resultado fijados (si fue producido) de nuevo al AR. El código de retorno es el SQLSTATE (o SQLCODE).

Se utiliza este protocolo a menos que se emplee un cursor. Cuando las filas se traen de un cursor inalterable, el protocolo limitado del bloque puede ser utilizado. El protocolo limitado del bloque pasa múltiples filas a la vez a través de la red, aunque también puede procesarse solamente una fila a la vez. El protocolo limitado del bloque realza el funcionamiento total reduciendo al mínimo el tráfico de la red. Si el cursor no es inalterable (es decir, las filas pueden ser actualizadas), el protocolo limitado del bloque no se emplea.

Arquitecturas y protocolos relacionados

Para que DRDA exista, se confía en otros protocolos establecidos. Estas arquitecturas se examinan en las secciones siguientes:

Programa avanzado para programar la comunicación (APPC)
La comunicación avanzada del Programa-a-Programa proporciona la ayuda de la comunicación del par-nivel basada en protocolos del LU 6,2. El LU 6,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.
APPC/LU 6,2 proporciona la comunicación y las instalaciones del tratamiento transaccional necesitadas para la cooperativa que procesa, y el tratamiento transaccional distribuido.

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. Con DDM, los datos distribuidos que se alcanzarán pueden residir en archivos o bases de datos relacionales. Un RDBMS se implica, sin embargo, dentro del contexto de DRDA.

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. Usando FD:OCA, se empaquetan juntos tanto los datos como su descripción, de modo que cualquier DBMS DRDA-obediente pueda entender su estructura y contenido.

Arquitectura De la Representación De Datos De Carácter (CDRA)
La arquitectura de la representación de datos de carácter es la arquitectura utilizada para asegurarse de que cualquier símbolo o carácter usado en cualquier DBMS relacional SAA tiene el mismo significado, sin importar el juego de caracteres cifrados subyacente. CDRA proporciona un método inequívoco de identificar datos de cualquier plataforma de SAA.

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). Teóricamente, CDRA se puede ampliar para apoyar otros códigos (tales como Unicode, un nuevo esquema de codificación del carácter ).

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. Cada nivel representa un aumento de la distribución. Además, 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, 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. Por ejemplo, la capacidad distribuida de la petición implica la unidad distribuida del trabajo (que a su vez implica la unidad remota del trabajo).

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. Sin embargo, bajo este nivel de DRDA, el usuario final es consciente de la distribución y es un experto y participa en los accesos distribuidos. Para lograr la distribución Asistida por Usuario, el usuario debe:

• Extraer los datos necesarios del sistema original

• Cargar los datos extraídos al sistema solicitante

Este es un procedimiento intenso y costoso que debería no ser tomado a la ligera. Como ello implica replicar los datos, 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.
Incluso viendo estas limitaciones, la distribución Asistida por Usuario es útil para producir fotos de tablas y peticiones satisfactorias. Sin embargo, muchas veces, la distribución asistida por usuario no es considerada verdadéramente un acceso distribuído a los datos.

A menudo, la distribución asistida por usuario no es ni siquiera incluida como una forma de DRDA.

b) Peticiones remotas o alejadas (Remote Request)

Las peticiones remotas es verdadéramente el primer nivel de distribución con DRDA. Cuando un DBMS soporta DRDA con capacidad de peticiones remotas, una sola sentencia SQL pude ser distribuída para leer o modificar un único RDBMS remoto con una única unidad de trabajo.

Símplemente, un promotor de peticiones remotas opera con un RDBMS, y remite a diferentes RDBMS. Además, es posible utilizar capacidades de peticiones remotas para acceder a RDBMS remotos, incluso si el RDBMS local no está siendo usado.

DRDA con peticiones remotas provee la capacidad de emitir solo una petición SQL por unidad de trabajo, y solo un RDBMS por petición SQL.

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. RUW permite múltiples sentencias SQL. Sin embargo, el SQL solo puede leer y/o modificar un RDBMS remoto con una unidad de trabajo.

Para aclararnos, en el ámbito de un commit, con RUW se puede acceder solo a un RDBMS. Por tanto, DRDA con unidad remota de trabajo provee la capacidad de emitir múltiples peticiones SQL por unidad de trabajo, pero todavia se puede acceder solamente a un RDBMS por petición SQL.

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. Ahora, más de un RDBMS puede ser accedido por unidad de trabajo.

Sencillamente, DRDA con DUW permite múltiples sentencias SQL para leer y/o modificar múltiples RDBMSs con sólo una unidad de trabajo. Sin embargo, solo un RDBMS puede ser especificado por sentencia SQL.
Como con cualquier unidad de trabajo, todas las peticiones SQL en el ámbito de un commit deben tener éxito o ser canceladas. Esto requiere que esté establecido el protocolo de la confirmación en 2 fases.

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, el protocolo de la confirmación en 2 fases debe sincronizar todas las plataformas afectadas.

e) Petición distribuída (Distributed Request)

DRDA con capacidad de peticiones distribuidas permite la distribución completa de los datos. Usando peticiones distribuídas, la restricción del DUW de sólo un RDBMS por sentencia SQL es eliminada.

Adicionalmente, múltiples peticiones SQL, tanto distribuídas como no distribuídas, pueden ser contenidas con sólo una unidad de trabajo.

Sencillamente, una peticion SQL distribuída puede leer y/o actualizar múltiples RDBMSs al mismo tiempo.

La siguiente Tabla muestra un pequeño resumen de los niveles de DRDA:

Nivel de DRDA	Op. Sql	DBMS por UOW	DBMS por Op. de SQL
Asistido por Usuario	-	-	-
Petición Remotas	1	1	1
Unidad remota de trabajo	> 1	1	1
Unidad distribuida del trabajo	> 1	> 1	1
Petición Distribuida	> 1	>1	> 1

Tabla : Los Cinco Niveles de DRDA

Ejemplo juntando todos estos niveles

Consideramos un escenario donde son establecidas tres localizaciones de procesamiento remotos, cada uno con un RDBMS: A Coruña, Madrid y Barcelona. Vamos a examinar cómo cada una de las 4 opciones de DRDA podrían acceder a datos distribuídos de esas localizaciones.

Consideramos una situación en la que necesitamos accesos por columnas específicas de tablas en cada una de las localizaciones remotas. Hay cuatro tablas totales: dos en A Coruña, una en Madrid y otra en Barcelona. Además, asumimos que las peticiones proceden de Madrid. En un escenario de peticiones remotas, nosotros podremos acceder solamente a un RDBMS de una localización en una sola unidad de trabajo. La petición a una tabla de Madrid es una petición local; las peticiones a A Coruña y Barcelona son remotas. Cada petición viene incluída en una unidad de trabajo (indicado por un commit). Hay cuatro UOWs totales, una para Barcelona y Madrid, y dos para A Coruña, una por cada select a las dos tablas que existen en A Coruña.

Ahora, en contraste está la funcionalidad de unidad remota de trabajo con peticiones remotas. En vez de una única sentencia por unidad de trabajo, están permitidas varias sentencias. Por tanto, la peticion de A Coruña ahora puede consistir en ambas peticiones select (una por cada tabla) con la misma unidad de trabajo. Con RUW nosotros hemos pasado de cuatro UOWs a tres.

Después, la unidad distribuída de trabajo permite múltiples RDBMSs por unidad de trabajo. Las 4 tablas de las tres localizaciones pueden ser accedidas con una unidad de trabajo usando DRDA con funcionalidad DUW.

Finalmente, tenemos las peticiones distribuídas. Usando peticiones distribuídas, múltiples RDBMSs de varias localizaciones pueden ser accedidos usando solo una petición SQL. En este escenario, la aplicación cliente emite una petición a la aplicación servidora de Madrid, la cual enviará la petición al servidor de base de datos de Madrid. Este proceso puede y es pasado a uno de los otros servidores de base de datos ( por ej A Coruña). Con las peticiones distribuídas no sólo tenemos un UOW, sino que podemos tener una petición SQL uniendo tablas de otras localizaciones.

Seguridad en nuestros sistemas

La seguridad incorporada refleja la metodología más sólida de proceso y de diseño del desarrollo.

La seguridad es imprescindible, 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, la facturación, contabilidad, 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, aplicaciones cliente-servidor, nuevas herramientas y sobre todo por la interactividad entre distintos sistemas, lo cual nos obliga a modificar y actualizar constantemente nuestras medidas de seguridad. Además Internet forma parte de la infraestructura de operación de las empresas, lo cual "abre" nuestros sistemas a millones de usuarios, algunos de ellos demasiado curiosos.

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", todo ello gracias a que la seguridad está integrada en el sistema operativo. Pero cuando se integra en una red o permitimos el acceso desde aplicaciones externas (ODBC, JDBC, DRDA ) cualquier usuario puede modificar los datos, 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, su gestión es compleja. Además, en los escenarios actuales, son necesarias herramientas de seguridad activas y dinámicas, que nos sirvan para prevenir riesgos antes de que sucedan.

Además de disponer de una buena política de seguridad, la ley nos obliga a saber quien y como utiliza los datos y a garantizar la calidad de la misma, por lo que en algunos casos, estamos obligados a realizar auditorias de seguridad en nuestros sistemas y a tener logs de quien y cuando modifica un dato.

Algunos ejemplos de productos relacionados con DRDA

Han sido muchos los productos que han salido al mercado y que soportan el protocolo DRDA. Todos sabemos que el mundo de las tecnologías avanza contínuamente y siempre aparecen nuevos productos que intentan mejorar los anteriores. En esta sección expondré alguno de estos productos que han ido apareciendo a lo largo de estos años.

Host Integration Server 2000

Microsoft sustituyó su SNA Server, parte de la suite empresarial BackOffice, por su último servidor de interoperabilidad empresarial, cuyo nombre en clave era Babylon y que finalmente se denominaría Host Integration Server 2000. Al igual que hizo con SNA Server, Microsoft diseñó Host Integration Server 2000 para integrar los mainframes IBM y AS/400 en redes de Windows.

Sin embargo, 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. En segundo lugar, Microsoft se proponía ahondar en el nivel de integración que ofrece el servidor. Si, con SNA Server, Microsoft pretendía ofrecer un nivel básico de conectividad entre hosts (unidades centrales), con Host Integration Server 2000, además de ofrecer ese nivel básico de conectividad, profundizó en el campo de la integración de aplicaciones. Pero también es cierto que a Host Integration Server 2000 aún le faltaban varias piezas del rompecabezas de la interoperabilidad empresarial.

En cuanto a la Interoperabilidad del acceso a datos, 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. IBM desarrolló esta arquitectura para hacer posibles las operaciones entre bases de datos distribuidas. Host Integration Server 2000 puede funcionar como servidor DRDA encaminando las peticiones DRDA que reciba hacia un sistema SQL Server de Microsoft. Esta función permitirá a los hosts de IBM y demás productos que sean compatibles con DRDA (Data Propagator, 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. 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. Además, 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.

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, Virtual Storage Access Method (VSAM), Oracle, DB2/400, OS/400 y Sybase. Host Integration Server 2000 incluye controladores ODBC para DB2, Oracle y Sybase, así como proveedores OLE DB para VSAM, DB2, OS/400, Oracle y Sybase. Tanto el controlador ODBC como el proveedor OLE DB para DB2, VSAM y OS/400 utilizarán TCP/IP y SNA. Por su parte, 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.

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. Esta función permite la replicación bidireccional entre SQL Server, DB2, DB2/400 y Oracle mediante la tecnología de replicación instantánea, incremental y por fusión. Como ya indica su nombre, la replicación instantánea consiste en la transferencia periódica de una copia de la totalidad de los datos al suscriptor. 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. La replicación por fusión permite, por su parte, que las sedes autónomas efectúen fusiones bidireccionales periódicas de todos los cambios que se produzcan en las bases de datos.

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.0 . SQL Server 7.0 permite la replicación instantánea unidireccional en VSAM, DB2, Oracle y DB2/400. Host Integration Server 2000 mejoraba esta función al permitir los tipos de replicación incremental y por fusión, así como la posibilidad de replicar datos de DB2, Oracle y DB2/400 en SQL Server. 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. Estos activadores pasan, entonces, 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. 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.

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, OS/390 y OS/400.

En octubre de 2002 HiT Software anunció que la nueva versión de sus productos “middleware” para SQL, ODBC, OLE DB y JDBC permitían transacciones distribuidas y estáticas para base de datos DB2 corriendo sobre plataformas con sistemas operativos z/OS, OS/390 y OS/400. Al permitir transacciones distribuidas, las aplicaciones podían confirmar las actualizaciones de múltiples bases de datos antes de permitir una transacción. Sin el soporte para transacciones distribuidas, 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. Como consecuencia, algunos cambios temporales en la base de datos podían causar decisiones inapropiadas y pérdidas importantes.

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, liberar recursos de CPU del servidor y utilizar al máximo las ventajas de seguridad en el acceso a los datos. 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.
La performance del servidor DB2 se mejora debido a que no se requiere un acceso dinámico a los datos SQL, con lo que se ahorran ciclos de CPU.
También, como los paquetes estáticos de SQL son creados por el “HiT SQL Middleware”, se puede fortalecer la estructura de seguridad para esos paquetes mas que para las tablas DB2.

Los productos “HiT Middleware ODBC y OLE DB” son totalmente compatibles en entorno de Microsoft Transaction Server para aplicaciones Windows. El producto “HiT JDBC SQL” cumple con los standard XA de la industria para aplicaciones en JAVA. Ambos productos, Windows y JAVA soportan DB2 UDB para OS/390 v6.1, DB2 UDB for OS/400 V5R1 y posteriores versiones DB2 sobre estas plataformas. No es necesario instalar software adicional en el servidor para estos entornos. 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, y ellos se interrelacionan como un cliente estándar con una base DB2. Además, todos los productos “HiT SQL middleware” soportan SSL v3.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. 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.

El HiT ODBC y OLE DB SQL middleware se puede instalar en sistemas operativos Windows XP, 2000 y 9X, clientes NT y servidores. El producto HiT JDBC SQL se puede instalar en cualquier plataforma JDK 1.2 o posterior.

El HiT ODBC, OLE DB y JDBC SQL con soporte para transacciones distribuidas ya se encuentra disponible.

DB2 Connect

Explotando completamente la arquitectura de DRDA, DB2 Connect oferta una solución barata con las características de los sistemas que demandan los clientes.

En terminología de DRDA, un solicitante del uso (AR) es el código que maneja el extremo del uso de una conexión distribuida; es el uso que está solicitando datos. Un servidor del uso (COMO) es el código que maneja el extremo de la base de datos de la conexión. DB2 Connect puede funcionar solamente como solicitante del uso. 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.

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, DRDA utiliza también otras arquitecturas, 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)

...

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.

Aunque DRDA define protocolos de comunicación de la base de datos, no define los interfaces de programación, o APIs, que deben ser utilizados por los programadores. Todos los servidores de DRDA que hay disponibles pueden ejecutar peticiones SQL remitidas por un programa de uso con DB2 Connect.

IBM provee las herramientas para generar las peticiones SQL para Windows, y de varias plataformas de Unix. Estas herramientas son parte del cliente de DB2. El cliente DB2 Connect apoya varios tipos de API: SQL encajado, JDBC, SQLJ, y la interfaz del nivel de la llamada DB2 (DB2 CLI). Estos APIs pueden ser utilizados por los programadores para construir usos en una variedad de lenguajes de programación.

DB2 Connect permite que un programa de aplicación acceda a datos de bases de datos DB2 en servidores System/390, zSeries e iSeries. Por ejemplo, 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. Puede crear nuevas aplicaciones o modificar las aplicaciones existentes para que se ejecuten en un entorno de sistema principal o iSeries. También es posible desarrollar aplicaciones en un entorno y trasladarlas a otro.

DB2 Connect le permite utilizar las API siguientes con productos de base de datos de sistemas principales, como por ejemplo DB2 Universal Database para OS/390 y z/OS, siempre que dichos productos soporten estos elementos:

• SQL incorporado, 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. Se puede encontrar con sentencias de SQL que:

• Sean iguales para todos los productos de base de datos que utilice, independientemente de los estándares.

• 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).

• Sean exclusivas para el sistema de base de datos al que acceda.

La portabilidad de las sentencias de SQL de las dos primeras categorías es muy grande, pero las de la tercera categoría habrá que cambiarlas antes. En general, la portabilidad de las sentencias de SQL en Lenguaje de definición de datos (Data Definition Language - DDL) no es tan grande como la de las que están en Lenguaje de manipulación de datos (Data Manipulation Language - DML).

DB2 Connect acepta algunas sentencias de SQL que DB2 Universal Database no soporta. DB2 Connect pasa estas sentencias al servidor de sistema principal o iSeries. Para obtener información sobre los límites en las distintas plataformas, como por ejemplo la longitud máxima de columna, hay que consultarlo en los límites de SQL (algún manual sobre SQL).

Si se traslada una aplicación CICS desde OS/390 o VSE para que se ejecute bajo otro producto CICS (por ejemplo, CICS para AIX), ésta también puede acceder a la base de datos OS/390 o VSE utilizando DB2 Connect. Para obtener más detalles

se tendría que consultar los manuales CICS/6000 Application Programming Guide y CICS Customization and Operation.

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.
HOBLink J-DRDA se conforma con la especificación de los microsystems JDBC 2.0 API del SOL. Se garantiza el acceso a todos los usos de Java y los Java applets que apoyan JDBC.

Gracias a HOBLink J-drda, usted puede hacer bases de datos centrales accesibles a cada usuario, en un ambiente heterogéneo. 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 J-drda ofrece todos los browsers modernos de la web y los ambientes de Java que tienen acceso a las bases de datos. Los gracias a su funcionamiento optimizado, HOBLink J-drda permite acceso directo vía Internet, Intranet o Extranet sin la instalación de ningún middleware propietario.

Para usar HobLink J-DRDA se requiere alguno de los siguientes casos:

• Ambiente runtime 1.1 de Jave o más alto

• Microsoft Internet Explorer 4.0 o más alto

• Netscape Navigator 4.02 con la ayuda del JDK 1.1 del Netscape Navigator.

• Cualquier otro browser compatible de Java 1.1, e.g. HotJava