Guía Funcional del Módulo de Integración con Sistemas Heredados. Versión 5.1.0

Transcripción

1 Guía Funcional del Módulo de Integración con Sistemas Heredados Versión 5.1.0

2

3 1. Introducción Una buena definición de un sistema heredado se puede encontrar en el Omnibus Lexicon Un sistema heredado es un componente técnicamente obsoleto de un entorno de gestión de contenido. Aunque la funcionalidad que un sistema heredado ofrece a los procesos empresariales puede estar disponible a través de una tecnología más moderna, la posibilidad de una interrupción del servicio durante la actualización de sistemas puede impedir una migración hacia el uso de sistemas más nuevos, o incluso la puede impedir dada la dificultad percibida en la conversión del contenido heredado para ajustarse a los nuevos modelos de contenido y formatos. La amplia presencia de viejos sistemas informáticos y aplicaciones en las organizaciones a las que el proyecto va dirigido, como por ejemplo Ayuntamientos, Centros de Asistencia Sanitaria, PYME, etc, y la necesidad de extraer información de estos sistemas heredados, hace necesario el desarrollo de nuevas herramientas para trabajar con aplicaciones no orientadas en la red a través de Internet. Obviamente la modernización de estos sistemas anticuados es deseable, pero muchas veces no es muy asequible, no sólo por razones económicas sino también por razones críticas de entrega de servicios. El enfoque del problema de las aplicaciones heredadas es el de evitar cualquier modificación en los sistemas heredados que pueda poner en peligro la entrega de servicios; este enfoque también elimina la formación de los usuarios del sistema heredado al nuevo sistema, con el beneficio evidente del ahorros de costes y tiempos en la adquisición de nuevo equipamiento y el período de adaptación requerido para utilizarlo. Un punto que debemos remarcar es que no estamos intentando transformar la aplicación entera heredada empleada internamente en una organización determinada, sino hacer que algunasde sus partes sean accesibles a los ciudadanos a través de la web. Las funcionalidades de las aplicaciones heredadas son diseñadas para usuarios internos (p.ej. los funcionarios de un Ayuntamiento) y no son nuestro objetivo; sólo esas funciones orientadas hacia el usuario final (ciudadanos) tienen que ser tratadas. La solución propuesta debería ser tan transparente como sea posible para el dueño del sistema heredado y fácil de integrar en ISUM. Casi todos los productos probados en el mercado están basados en el client thin de Java; es decir que un applet Java se descarga al navegador web para tener acceso a las aplicaciones heredadas. Hay productos que producen resultados sin Java applets pero están completamente basados en productos Microsoft, es decir que el resultado son páginas ASP que requieren un Servidor Microsoft Windows NT con un Servidor Microsoft IIS Web (con soporte para ASP) y extensiones Microsoft Front Page. Otro problema con una solución del tipo no-fácil es que casi todo el software disponible en el mercado relacionado con los sistemas Legacy y Web-to- Host está orientado a Mainframes y AS/400. Una Mainframe es una máquina propietaria específica para un propósito (orientado al acceso y cuidado de los datos estratégicos de Empresas) orientada al I/O con OS propietario; no es un servidor de aplicaciones(como lo eran las máquinas 1

4 UNIX). Así que no podemos utilizar estas herramientas para construir un sistema Web-to-Host contra una máquina UNIX a través del telnet (que, por cierto, no está soportado). Podemos concluir que no hay ningún producto que produzca un resultado puro en HTML que sea completamente compatible con cada navegador Web y capaz de trabajar contra una amplia variedad de sistemas heredados independientes de productos de marca y con un coste asequible. Hay algo que se puede usar, y son las especificaciones OHIO, a pesar de no ser una solución completa y acabada (sólo está disponible una versión beta), merece la pena usarlo como un punto de partida para desarrollar nuestra propia solución. Los problemas mencionados arriba han forzado la decisión de desarrollar una nueva herramienta para producir HTML puro de una aplicación heredada y hacer que sea accesible desde la web al público en general. Estas herramientas no deberían emular la aplicación heredada en un web browser sino ofrecer algunas de sus funcionalidades (aquellas seleccionadas por el dueño de la aplicación heredada) a los ciudadanos. Podemos establecer dos grandes familias de sistemas heredados, aplicaciones Cliente/Servidor, como por ejemplo una aplicación Windows desarrollada con Visual basic, y aplicaciones basadas en Host como SNA (IBM) y VT family. Hemos decidido no tener como objetivo las aplicaciones Cliente/Servidor debido a la alta complejidad del problema, cada aplicación tiene su propio lógica que debería ser reprogramada o dispuesta en un servidor intermedio para ejecutar la lógica de la parte del cliente para todos los usuarios conectados a la aplicación heredada, lo cual requerirá una gran anchura de banda y un ordenador muy potente para dar una tasa baja de concurrencia, una solución que no es asequible para un número de usuarios medio/alto. Aplicaciones basadas en Host tienen un conjunto más estandarizado de características que nos permitirá transformar una aplicación Host (Mainframe/Unix) a una aplicación habilitada para la web sin reescribir el código original. El sistema propuesto es una solución Web-to-Host integrada en ISUM con nuestro integrador, que requiere un solo login para acceder a todos los servicios externos permitidos (los nombres de usuarios y contraseñas para los servicios Host están almacenados en la base de datos del sistema). El sistema está configurado como un servicio normal de ISUM y también está parametrizado y completamente configurable. Este servicio debería: proporcionar la autentificación del usuario abrir y cerrar conexiones al Host guardar el estatus de todas las conexiones convertir las pantallas del Host al formato html web automáticamente y en tiempo real gestionar conexiones seguras (SSL) 2

5 BD services servicios Web Browser HTTP Non-permanent connection Conexion no-permanente Web Server JVM ISUM JDBC TN Vt* Permanent connection Conexión permanente HOST Ilustración 1. Diagrama general de sistema. El objetivo principal del sistema es pasar de un protocolo no orientado a conexiones a uno que esté orientado a conexiones. Es muy importante recordar cada cambio de estatus en los dos lados. Para el desarrollo del sistema se ha utilizado una biblioteca de clases de Aviva Solutions basada en un especificación estándar muy reciente (aprobación final pendiente por la Internet Engineering Task Force, IETF) sobre Host Access (OHIO, Open Host Interface Objects, and ftp://ftp.boulder.ibm.com/software/standards/ohio/java/) desarrollado por IBM y Attachmate. Permite al administrador del sistema elegir entre un número de proveedores distintos que tienen soporte para esta especificación. Proporcionamos acceso a los Hosts a través de telnet con tres emuladores principales de terminales: TN3270 (para IBM y Mainframes compatibles con IBM), vt* family (para servidores generales de aplicaciones UNIX) y TN5250 (AS/400). La implementación del proveedor Aviva Solutions, proporciona una solución que cubre la emulación de todos los terminales dependiendo de una serie de parámetros de configuración. 3

6 2. Familias de terminales Familia TN3270 Este tipo de terminal permite una solución general para un gran número de aplicaciones Host. Este tipo de terminal se utiliza con IBM y mainframes compatibles con IBM. Los terminales soportados son los siguientes: IBM 3279 (modelos 2A, 2B, 3A, 3B) IBM 3278 (modelos 2, 3, 4, 5) TN3270 y TN3270E Está orientado a pantallas, por lo tanto, su funcionalidad básica está basada en pantallas que van desde servidor a cliente y al revés. Las pantallas están compuestas de texto, atributos de texto y campos: Texto: es el texto de salida, que aparece en la pantalla. Atributos de texto: Como color, highlight, etc... Campos: o de entrada o de salida, y o numérico o alfanumérico. Son empleados para trabajar con la aplicación Host. Este servicio genera automáticamente una salida HTML de aplicaciones de Mainframes orientados a texto y parecidos a las terminales y se integra completamente en la plataforma ISUM. Los Hosts se acceden a través de telnet utilizando protocolos de emulación de terminal TN3270 o TN3270E. El Host tiene que soportar al menos uno de los mencionados protocolos. Este requisito no tiene por que ser un problema porque son los más empleados en el acceso de Hosts. Familia VT TN5250 Los terminales VT, normalmente nos permiten acceder a Host DEC y UNIX. Dentro de las familias de VT soportadas se encuentran las siguientes: VT100 VT220 VT52 A pesar de que la emulación de los terminales VT no suele estar orientada a pantallas, la implementación de OHIO realizada por Aviva Solutions, sí permite el tratamiento de una sesión con Host de la misma forma que en el caso de los terminales de la familia TN3270. Por tanto, al igual que antes, este servicio genera automáticamente una salida HTML de aplicaciones de Mainframes orientándola a texto de una forma similar a como hacen los terminales y se integra completamente en la plataforma ISUM. TN5250 constituye un protocolo de comunicación que, vía TCP/IP, emula el funcionamiento de un terminal IBM

7 Los terminales IBM 5250 contienen software de emulación NetManage, así como programas de comunicación para conectar un PC a un IBM AS/400 host. Dicha comunicación la realizan a través de conexiones tradicionales que soportan 5250 (twinax, 802.2, etc), así como a través de TCP/IP usando TN

8 3. Funcionamiento Los servicios de comunicación con Host se encuentran totalmente integrados dentro de la plataforma de ISUM, de forma que cada una de las diferentes conexiones a un host distinto se debe definir como un nuevo servicio ISUM. Esto implica que una conexión host se puede incluir como una pieza de contenido más dentro de un portal concreto, y así este nuevo servicio de conexión host tendrá que definirse en la base de datos, de la misma forma en que se definen los diferentes servicios dentro de ISUM. Para que ISUM sea capaz de identificar el nuevo servicio como una conexión host, se ha definido un nuevo protocolo host://. Este protocolo seguido del nombre lógico del host al que nos vamos a conectar constituye la URL del nuevo servicio. Así, por ejemplo, si nuestro host se trata de la librería del congreso (Library of Congress: LOCIS), la url que define nuestro servicio será de la siguiente forma: host://locis Este nombre lógico es el que ISUM utiliza para acceder a los diferentes ficheros de configuración dentro del directorio de recursos, y mediante los cuales se configuran todas las características de la conexión en cuestión (tipo de terminal, dirección del Host, etc) 6

9 4. Ejemplos de conexiones con Host A continuación se pueden ver una serie de ejemplos de cómo ISUM integra diferentes conexiones host dentro de un portal de ejemplo. El siguiente ejemplo muestra la diferencia de aspecto entre una pantalla de una conexión TN3270 y la misma pantalla dentro de ISUM. Ilustración 2 Ilustración 3 7

10 El siguiente ejemplo muestra la diferencia de aspecto entre una pantalla de una conexión VT100 y la misma pantalla dentro de ISUM. Ilustración 4 Ilustración 5 8