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:
DBMS por
Nivel de DRDA Op. Sql DBMS por UOW
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:
o Ambiente runtime 1.1 de Jave o más alto

o Microsoft Internet Explorer 4.0 o más alto

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

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