TRABAJO DE ARQUITECTURA CLIENTE/SERVIDOR BASES DE DATOS DISTRIBUIDAS : DRDA

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
1
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.
2
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
3
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
4
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,
5
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
6
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
7
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
8
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.
9
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
10
Asistido por Usuario
Petición Remotas
Unidad remota de trabajo
Unidad distribuida del trabajo
Petición Distribuida
−
1
>1
>1
>1
−
1
1
>1
>1
−
1
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
11
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.
12
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.
13
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:
14
• 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).
15
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
16