Acceso a aplicaciones y datos heredados

Transcripción

1 C A P Í T U L O 1 0 Acceso a aplicaciones y datos heredados 10 Mediante la conexión de la intranet al entorno de red Systems Network Architecture (SNA, Arquitectura de sistemas de red) de Microsoft, se puede obtener acceso a la riqueza de aplicaciones y datos disponibles en las plataformas de IBM tales como los sistemas Multiple Virtual Storage (MVS) y OS/400. Utilizando Microsoft SNA Server 4.0 SP2 como servidor de acceso a los datos, se pueden desarrollar secuencias de comandos sin dificultad en las páginas Active Server (ASP) que interactúen con las aplicaciones heredadas. Esto permitirá procesar los datos heredados y distribuirlos a través de la intranet y sobre Internet. Este capítulo presenta estrategias para la utilización de aplicaciones Web basadas en Servicios de Internet Information Server (IIS) 5.0 con el fin de acceder a las aplicaciones y los datos de sistemas IBM que se ejecutan en entornos SNA (mainframes que ejecutan MVS y computadoras AS/400 que ejecutan OS/400). Las estrategias y escenarios de este capítulo ayudarán a utilizar las herramientas de desarrollo de Microsoft y los paquetes de producción de software con el fin de integrar las aplicaciones y los datos heredados en las aplicaciones Web basadas en IIS 5.0. En este capítulo Identificación de estrategias, 405 Integración de IIS y las aplicaciones heredadas, 408 Obtención de acceso a los datos heredados, 414 Replicación de bases de datos heredadas, 418 Migración de procesos de transacción, 421 Recursos adicionales, 425 Identificación de estrategias Para conseguir las mejores ventajas de la tecnología Web, una empresa debe hacer sus aplicaciones y datos de negocio fácilmente accesibles a sus empleados, socios clave del negocio y clientes. Este objetivo es a menudo difícil de conseguir debido a que los datos de misión crítica (por encima del 80 por 100 de la información vital del negocio para empresas y agencias de administración muy grandes) se almacenan en sistemas de archi- 405

2 406 Microsoft Windows 2000 Server. Kit de recursos vos y bases de datos relacionales basados en el host sobre mainframes IBM o computadoras AS/400. Esta información (especificaciones de los productos, perfiles de los clientes, descripciones de las ubicaciones y mucho más) no suelen estar disponibles para la gente que más los necesita, en el momento en que podrían hacer el mejor uso de ellos. La entrega de grandes cantidades de datos de sistemas heredados a una amplia audiencia siempre ha sido problemática puesto que: El hardware de herencia y el software del sistema son muy caros, prohibiendo a menudo la expansión sobre una escala amplia de Internet. Los protocolos de red de IBM no son ampliamente soportados más allá del entorno de herencia (en Internet, por ejemplo). Los costes de desarrollo de aplicaciones son elevados, desanimando el desarrollo de las modificaciones necesarias para hacer los datos heredados más ampliamente disponibles. Mediante la utilización de aplicaciones Web basadas en IIS 5.0 para acceder a las aplicaciones y datos heredados en sistemas IBM, se puede: Integrar aplicaciones del host que se ejecutan en entornos de herencia dentro de aplicaciones ASP de IIS. Se conectan los procesadores de transacciones del host a Microsoft Windows 2000 Server, utilizando SNA Server 4.0 SP2 y Microsoft COM Transaction Integrator (COMTI) para las bases de datos de Customer Information Control System (CICS) e Information Management System (IMS). Acceder a los archivos heredados a nivel de registro utilizando SNA Server 4.0 SP2 y Microsoft OLE DB Provider para AS/400 y el Data Provider (Proveedor de datos) de Virtual Sequential Access Method (VSAM, Método virtual de acceso secuencial). Se envían los datos a una aplicación Web que se ejecuta sobre Windows 2000 Server. Adquirir las estructuras de las bases de datos del host utilizando Microsoft Host Data Replicator (HDR). Se replican para Microsoft SQL Server e IIS 5.0. Desplazar los procesos automatizados desde el entorno de herencia hacia el entorno Windows 2000 Server abierto y más eficiente en coste. Para conseguir esto, se utilizan IIS 5.0 y Servicios de componentes de Microsoft (anteriormente Microsoft Transaction Server). Conexión a SNA Cada una de las estrategias de acceso a la herencia tratadas en este capítulo requiere conexiones a las computadoras host de IBM a través de SNA. Para comprender cómo se implementa cada estrategia, se necesita una comprensión básica sobre la forma de construir el entorno SNA, la forma de conectarse a los recursos SNA y la forma de explotar estos recursos. Para una información más detallada sobre el entorno SNA, ver la documentación del producto SNA Server 4.0 SP2. El entorno SNA Para realizar una transmisión peer-to-peer de datos a través de SNA, se debe establecer una sesión entre dos Unidades lógicas (LU, Logical Units) de acuerdo con el protocolo LU 6.2, con una LU en el sistema host y la otra en el sistema cliente. Debido a que LU 6.2 es peer-to-peer, pueden iniciar una sesión tanto el mainframe host como el cliente. Nota: Las antiguas redes SNA son jerárquicas y no soportan las comunicaciones peer-to-peer. Además, no utilizan LU 6.2; en su lugar, se utilizan otros tipos de LU que se adaptan a un esquema jerárquico de interconexión de redes.

3 Acceso a aplicaciones y datos heredados 407 Como se muestra en la Figura 10.1, cualquier computadora conectada a una red SNA que utilice este protocolo, incluyendo las computadoras que ejecutan Windows 2000 Server o Microsoft Windows NT Server 4.0, puede participar en el entorno SNA y obtener acceso a: Los entornos de herencia del host, incluyendo monitores de procesamiento de transacciones. Archivos VSAM. Archivos AS/400 (tanto planos como no estructurados). Estructuras de datos de las bases de datos, como las tablas de datos DB2 de IBM. Conexión a través de Microsoft SNA Server SNA Server 4.0 SP2 proporciona acceso a las aplicaciones y los datos del entorno SNA desde Windows 2000 Server. Éste traduce las comunicaciones a través del Protocolo de control de transmisión/protocolo de Internet (TCP/IP, Transmission Control Protocol/Internet Protocol) de Windows 2000 Server al protocolo LU 6.2, proporcionando acceso a la riqueza de recursos del entorno de herencia. Ver la Figura SNA Server 4.0 SP2 se ejecuta sobre Windows NT Server 4.0 y sobre Windows 2000 Server. Desarrollo e implantación de aplicaciones bajo Windows Con la traducción de SNA Server entre TCP/IP y LU 6.2, se pueden desarrollar e implantar aplicaciones que accedan al entorno de herencia desde la parte Windows 2000 Server de la conexión. Las herramientas software utilizadas para obtener acceso a las aplicaciones y los datos SNA residen en las plataformas Windows 2000 Server y se aprovechan de las herramientas administrativas unificadas y los recursos de bajo coste del entorno Windows 2000 Server. También se consigue el desarrollo y la modificación de aplicaciones en el entorno Windows 2000 Server. Esto significa que se puede evitar la alta sobrecarga asociada con el desarrollo y la modificación de los recursos heredados del host. Mainframe (o AS/400) SNA Server Red SNA LU 6.2 MVS (u OS/400) Procesamiento de transacciones Windows 2000 Server Windows NT 4.0 DBMS Datos Aplicación Datos Figura El entorno SNA. SNA Server Intranet TCP/IP Red SNA LU 6.2 Aplicación del cliente Figura Windows 2000 Server Windows NT 4.0 SNA Server conecta Windows 2000 con SNA.

4 408 Microsoft Windows 2000 Server. Kit de recursos Integración de IIS y las aplicaciones heredadas Durante años, IBM ha animado a sus clientes a obtener un mejor control del desarrollo y mantenimiento de su software codificando sus lógicas de negocio en programas separados de sus lógicas de acceso al terminal. Muchas organizaciones de Servicios de información (IS, Information Services) han respondido mediante la codificación de sus reglas de negocio en programas de procesamiento de transacciones que se ejecutan bajo CICS o IMS. La obtención de acceso a estos programas del host desde el entorno Windows 2000 Server puede establecer las reglas de negocio para una aplicación completa, como el control de inventario o la presupuestación, creando así nuevas oportunidades para las aplicaciones distribuidas. La utilización de aplicaciones Web para acceder a la lógica de negocio ofrece ventajas significativas sobre los métodos tradicionales como la utilización del «ruido de pantalla» para obtener datos de los programas de emulación de terminales porque: Todos los datos y procesos que permite la lógica de negocio están accesibles, en lugar de estar accesibles sólo los datos y los procesos limitados de los programas de acceso a terminales individuales. No existen requerimientos para un emulador de terminal de la plataforma Windows 2000 Server puesto que el procesamiento no incluye el software de acceso al terminal. La utilización de protocolos nativos, como Advanced Program-to-Program Communications (APPC, Comunicaciones avanzadas programa a programa), requiere una menor traducción de datos, reduciendo así la probabilidad de errores. La integración de procesos heredados con aplicaciones basadas en IIS 5.0 que utilizan herramientas como COMTI es más fácil de conseguir y menos costosa que la mejora general de las aplicaciones en el entorno de herencia. COM Transaction Integrator (Integrador de transacciones COM) COMTI para CICS e IMS es una tecnología que integra programas de procesamiento de transacciones heredados (que se ejecutan en mainframes) con aplicaciones Web y procesos de transacción (que se ejecutan en el entorno Windows 2000 Server). Ver la Figura COMTI reduce el esfuerzo requerido para desarrollar aplicaciones, mediante la integración de programas COmmon Business Oriented Language (COBOL, Lenguaje orientado a negocios comunes) ejecutados en mainframes con clientes Automation ejecutados en Windows 2000 Server, Microsoft Windows 2000 Profes- Windows 2000 Server MVS COMTI SNA Server LU 6.2 Procesamiento de transacciones Aplicación del cliente Componente Componente Figura COMTI es un proxy para el mainframe.

5 Acceso a aplicaciones y datos heredados 409 sional, Microsoft Windows 95, Microsoft Windows 98 o cualquier otra computadora que admita Automation. Específicamente: COMTI puede crear de forma automática un conjunto de registros de los datos devueltos desde un programa de procesamiento de transacciones de un mainframe. A continuación, las secuencias de comandos de las páginas ASP pueden acceder a los datos del conjunto de registros, con formato de array tabular. COMTI coordina los programas de procesamiento de transacciones heredados del mainframe, que son administrados por Servicios de componentes. Esto extiende el entorno de transacciones para incluir las transacciones administradas por CICS o IMS en un mainframe IBM. COMTI desarrolla herramientas que asocian las declaraciones de datos en COBOL con los tipos de datos Automation. Descripción funcional del COM Transaction Integrator (Integrador de transacciones COM) La siguiente lista resume la forma en que COMTI obtiene acceso a las aplicaciones CICS. También muestra cómo COMTI integra los datos devueltos desde los programas de procesamiento de transacciones de CICS con IIS 5.0, mediante la utilización de componentes COM y Servicios de componentes. Específicamente, COMTI puede: Obtener acceso a los programas de procesamiento de transacciones de CICS. COMTI admite directamente cualquier programa de procesamiento de transacciones que se ejecute en CICS o IMS. Debido a que COMTI puede acceder a programas CICS, los desarrolladores pueden emitir llamadas de aplicación al entorno de herencia mediante la utilización de CICS para obtener acceso a cualquier programa bajo su control. Esto incluye las bases de datos DB2, los archivos VSAM o las bases de datos IMS. Redirigir las llamadas a métodos. COMTI es un proxy genérico para el mainframe. Intercepta las llamadas a métodos desde la aplicación cliente y las redirige a programas de procesamiento de transacciones que se ejecutan en el mainframe. Por ejemplo, cuando un navegador de Internet envía datos que ASP interpreta como los requeridos por COMTI, IIS reenvía los datos a COMTI. Cambiar el formato de las llamadas a métodos. Cuando COMTI intercepta una llamada a método, convierte y da formato a los parámetros del método desde tipos de datos Automation a tipos de datos del mainframe IBM System 390. Gestionar los valores devueltos. COMTI gestiona los valores devueltos por todos los parámetros y valores de salida del mainframe, convirtiéndolos y cambiándoles el formato según las necesidades de IIS. El procesamiento de COMTI se ejecuta en computadoras que utilizan Windows 2000 Server, no en el host SNA. Éste no requiere la instalación de ningún código ejecutable nuevo en el mainframe o en la computadora escritorio que está ejecutando el navegador de Internet. COMTI se comunica a través de SNA Server 4.0 SP2 y utiliza protocolos estándar (LU 6.2 o TCP/IP, cada uno de los cuales es soportado por SNA Server 4.0 SP2) para la comunicación entre la computadora que ejecuta Windows 2000 Server y el programa de procesamiento de transacciones del mainframe. Escenarios de desarrollo de COMTI Los dos siguientes escenarios muestran la forma en que se puede utilizar el entorno COMTI para desarrollar aplicaciones que integren programas de procesamiento de trasacciones con páginas ASP. Escenario uno: Integración de datos de procesamiento de transacciones heredados utilizando COM Transaction Integrator Este escenario muestra la forma de conectar un sitio Web basado en Windows 2000 Server a un programa COBOL existente con procesamiento de transacciones. Supóngase que se desea añadir dinámicamente el contenido de una base de datos heredada que se ejecuta bajo CICS en un mainframe IBM a una aplicación Web

6 410 Microsoft Windows 2000 Server. Kit de recursos que se ejecuta bajo IIS 5.0. Se puede comenzar utilizando páginas ASP para interpretar las demandas de usuario y dar formato a los datos devueltos por la aplicación del mainframe. A continuación, se puede utilizar COMTI para desarrollar un componente que procesará las llamadas a métodos desde el entorno IIS y el entorno del mainframe. Este escenario incluye seis pasos principales: Paso 1 (tiempo de configuración): Configuración de COMTI. Paso 2 (tiempo de diseño): Definición de los métodos y parámetros requeridos. Paso 3 (tiempo de diseño): Escritura de la aplicación. Paso 4 (tiempo de diseño): Prueba de la aplicación. Paso 5 (implantación): Implantación de los componentes de la aplicación. Paso 6 (postimplantación): Mantenimiento de la aplicación. Paso 1: Configuración de COMTI Para desarrollar un componente COMTI, se debe tener instalado lo siguiente: Windows 2000 Server o Windows 2000 Professional. IIS 5.0 con Servicios de componentes 2.0. Microsoft Windows Client para SNA Server. Microsoft Data Access Components (MDAC, Componentes de acceso a datos de Microsoft) 2.0. Además, deben estar instalados los siguientes componentes COMTI: El componente de administración, que recoge información sobre el entorno SNA del usuario. El componente de tiempo de ejecución, que intercepta las llamadas a métodos del mainframe y utiliza la biblioteca de componentes, creados para COMTI, para realizar la conversión real y dar formato a los parámetros de los métodos. Además, el componente de tiempo de ejecución interactúa con SNA Server y construye paquetes, que se envían al mainframe utilizando LU 6.2 o TCP/IP. Componentes de herramientas de desarrollo, destacando el Component Builder, un GUI utilizado para crear bibliotecas de componentes desde los programas COBOL del mainframe. El Component Builder se puede instalar como un elemento incorporado a Microsoft Visual Basic 5.0 y no necesita estar instalado en el mismo sistema que el resto de componentes. Los desarrolladores que no estén utilizando Visual Basic 5.0 pueden utilizar el Component Builder como una herramienta independiente. Paso 2: Definición de los métodos y parámetros requeridos 1. Se adquiere el código fuente COBOL desde el mainframe utilizando un mecanismo de transferencia de archivos, como el servicio de gateway FTP-AFTP que se incluye con SNA Server 4.0 SP2. 2. Se utiliza COBOL Import Wizard para: Seleccionar el código fuente COBOL. Especificar los métodos y los nombres de procesamiento de transacciones del mainframe. Seleccionar los parámetros de entrada, salida y valores devueltos. 3. Cuando sea necesario, se modifican las asociaciones entre los tipos de datos de COBOL y los Automation. 4. Se utiliza el Component Builder para realizar una biblioteca de tipos de componentes COMTI (.tlb). Esto es una biblioteca estándar que puede ser utilizada por software del cliente y por Servicios de componentes. Si se ha modificado la asociación de los tipos de datos del código COBOL, se requieren dos acciones más en este paso: Utilizar el Component Builder para generar nuevas declaraciones COBOL. Actualizar el programa del mainframe con las nuevas declaraciones de datos de COBOL. Ésta es la única instancia que requiere modificaciones en el entorno del mainframe.

7 Acceso a aplicaciones y datos heredados 411 Paso 3: Escritura de la aplicación 1. Se escribe el cliente en un lenguaje que admita la referencia de objetos Automation, como Visual Basic, Microsoft Visual C++ o Microsoft Visual J Se añade la biblioteca de componentes COMTI apropiada a la lista de referencias del proyecto y se añaden las referencias del componente al programa. 3. Se llama a los métodos de forma apropiada a lo largo de la aplicación. Si es necesario modificar el programa de procesamiento de transacciones del mainframe existente, se debe realizar una de las siguientes acciones: Realizar la modificación en el mainframe. Utilizar un entorno de desarrollo COBOL basado en Windows, como Microfocus COBOL. A continuación, se traslada el código al mainframe. Paso 4: Prueba de la aplicación Si el programa de procesamiento de transacciones del mainframe se queda inalterado, no requiere prueba. Si se ha modificado el programa de procesamiento de transacciones, entonces debería probarse independientemente el programa COBOL para asegurar que se ejecuta correctamente en su propio entorno. Para probar la aplicación nueva 1. Asegurarse de que la biblioteca de componentes COMTI está registrada en Servicios de componentes. 2. Probar el procesamiento de transacciones del mainframe independientemente, si se ha modificado de alguna forma. 3. Probar el componente COMTI desarrollado recientemente de forma independiente para asegurar que funciona correctamente. 4. Probar la aplicación, ejecutando el programa de procesamiento de transacciones del mainframe. Paso 5: Implantación de los componentes de la aplicación Antes de implantar la parte de la aplicación correspondiente al cliente, se debe instalar lo siguiente en la computadora de producción: Windows 2000 Server o Windows 2000 Professional. Windows Client para SNA Server. Servicios de componentes. Componentes COMTI de administración y de tiempo de ejecución. Bibliotecas de componentes COMTI registrados en Servicios de componentes. Aplicaciones del cliente que acceden a componentes COMTI. Paso 6: Mantenimiento de la aplicación Cuando se realizan las modificaciones en el programa de procesamiento de transacciones del mainframe, se debe realizar una o más de las siguientes acciones, según convenga: Adquirir el código fuente COBOL desde el mainframe. Utilizar el COBOL Import Wizard para volver a especificar los nombres de los métodos y los nombres de procesamiento de transacciones del host y volver a seleccionar los valores de los parámetros de entrada, salida y devolución.

8 412 Microsoft Windows 2000 Server. Kit de recursos Qué ocurre si no existe el procesamiento requerido para las transacciones del mainframe? En este caso, se deben modificar los pasos 2 y 3 de este escenario mediante el desarrollo de un programa de procesamiento de transacciones que se ejecuta bajo CICS (en el host del mainframe). En el paso 2, se utiliza el Component Builder de COMTI para: Introducir los métodos y parámetros de la aplicación. Añadir información sobre el nombre y la ubicación del nuevo programa de procesamiento de transacciones. Modificar las asociaciones por omisión producidas por el Component Builder, si es necesario. Crear la biblioteca de componentes COMTI. En el paso 3: Escribir el programa de procesamiento de transacciones del mainframe, en el mainframe o en el entorno Windows utilizando un producto como Microfocus COBOL y, a continuación, trasladar el programa al mainframe para su prueba. Escenario dos: Extensión de transaciones con COMTI Cuando se implanta en el entorno basado en Windows 2000 Server, COMTI puede extender las transacciones para incluir los programas de procesamiento de transacciones del mainframe que se ejecutan bajo CICS e IMS. Un desarrollador puede utilizar los siguientes pasos para conectar un sitio Web basado en Windows 2000 Server con un programa de procesamiento de transacciones COBOL existente. Con esto haremos que los datos heredados estén disponibles para las secuencias de comandos de las páginas ASP. En este escenario, se necesitan tareas adicionales para extender las transacciones que están bajo el control de CICS. Como el escenario anterior, este escenario también incluye seis pasos principales: Paso 1: Configuración de COMTI Para desarrollar el objeto COMTI, se debe tener instalado lo siguiente: Windows 2000 Server o Windows 2000 Professional. IIS 5.0. Windows 2000 Client para SNA Server. Servicios de componentes. Además, deben estar instalados los siguientes componentes COMTI (para las descripciones de cada uno de los componentes, ver el escenario uno): El componente de administración. El componente de tiempo de ejecución. El Component Builder. Paso 2: Definición de los métodos y parámetros requeridos Para hacer que los datos del programa de procesamiento de transacciones del mainframe estén disponibles para IIS, se realizan las siguientes tareas: 1. Se adquiere el código fuente COBOL desde el mainframe utilizando un mecanismo de transferencia de archivos, como el gateway FTP-AFTP que se entrega con SNA Server 4.0 SP2. 2. Se utiliza COBOL Import Wizard para: Seleccionar el código fuente COBOL. Especificar los métodos y los nombres de programas de procesamiento de transacciones del mainframe. Seleccionar los parámetros de entrada, salida y valores devueltos.

9 Acceso a aplicaciones y datos heredados Cuando sea necesario, se modifican las asociaciones entre los tipos de datos de COBOL y los Automation. 4. Se utiliza el Component Builder para realizar una biblioteca de componentes COMTI (.tlb). Ésta es una biblioteca estándar que puede ser utilizada por el software de cliente y por Servicios de componentes. Si se ha modificado la asociación de los tipos de datos del código COBOL, se requieren dos acciones más en este paso: Utilizar el Component Builder para generar nuevas declaraciones COBOL. Actualizar el programa del mainframe con las nuevas declaraciones de datos de COBOL. Ésta es la única instancia que requiere modificaciones en el entorno del mainframe. Paso 3: Escritura de la aplicación 1. Se escribe el cliente en un lenguaje que admita la referencia de objetos Automation, como Visual Basic, Visual C++ o Visual J Se añade la biblioteca de componentes COMTI apropiada a la lista de referencias del proyecto y se añaden las referencias del componente en el programa. 3. Se llama a los métodos de forma apropiada a lo largo de la aplicación. 4. Se definen los atributos relacionados con las transacciones en el componente COMTI. Estos atributos manejarán las transacciones de manera transparente a la aplicación del cliente (por ejemplo, una aplicación de IIS 5.0 que utiliza ASP). El componente COMTI llamará tanto a Servicios de componentes/coordinador de transacciones distribuidas (DTC, Distributed Transaction Coordinator) como al programa de procesamiento de transacciones que se ejecuta bajo CICS. Paso 4: Prueba de la aplicación Si el programa de procesamiento de transacciones del mainframe se queda inalterado, no requiere prueba. Si se ha modificado el programa de procesamiento de transacciones, entonces debería probarse independientemente el programa COBOL para asegurar que se ejecuta correctamente en su propio entorno. Para probar la aplicación nueva 1. Probar independientemente el programa de procesamiento de transacciones del mainframe, si se ha modificado de alguna forma. 2. Probar el componente COMTI desarrollado recientemente de forma independiente para asegurar que funciona correctamente. 3. Probar la aplicación íntegramente, dirigiendo el objeto COMTI con la aplicación del cliente y ejecutando el programa de procesamiento de transacciones del mainframe. 4. Llevar a cabo una prueba de las transacciones. Para hacer esto, se prueba el objeto COMTI con las transacciones disponibles. Se comprueba el funcionamiento entre COMTI y Servicios de componentes, en conjunción con COMTI y el programa de procesamiento de transacciones que se ejecuta bajo CICS. Paso 5: Implantación de los componentes de la aplicación Antes de implantar la parte de la aplicación correspondiente al cliente se debe instalar lo siguiente en la computadora de producción: Windows 2000 Server o Windows 2000 Professional. Windows Client para SNA Server. Servicios de componentes. Componentes COMTI de administración y de tiempo de ejecución. Bibliotecas de componentes COMTI registrados en Servicios de componentes. Aplicaciones del cliente que acceden a componentes COMTI.

10 414 Microsoft Windows 2000 Server. Kit de recursos Paso 6: Mantenimiento de la aplicación Cuando se haya modificado el programa de procesamiento de transacciones del mainframe, se debe realizar una o más de las siguientes acciones, según convenga: Adquirir el fuente COBOL desde el mainframe. Utilizar el COBOL Import Wizard para volver a especificar los nombres de los métodos y los nombres de programas de procesamiento de transacciones del host y volver a seleccionar los valores de los parámetros de entrada, salida y devolución. Utilización de COMTI con IMS Las versiones actuales de COMTI no admiten la semántica transaccional (también conocida como un acuerdo en dos fases) bajo el subsistema IMS. Sin embargo, se puede acceder a una transacción de bases de datos IMS/DB a través de un programa de procesamiento de transacciones final del subsistema CICS. Es decir, si el entorno del mainframe admite el procesamiento de transacciones CICS contra IMS/DB, se puede extender la semántica transaccional de Servicios de componentes a la base de datos IMS/DB. En este caso, COMTI proporciona los mismos servicios que cualquier otro programa de procesamiento de transacciones que se ejecuta bajo CICS. Si no se requiere la semántica transaccional y sólo se desea obtener acceso a los datos, se puede acceder directamente a IMS. Obtención de acceso a los datos heredados Los proveedores de datos OLE DB facilitan el acceso a diversas fuentes de datos heredados desde IIS 5.0. Los proveedores de datos que tienen como objetivo los entornos de hosts heredados incluyen: Proveedor OLE DB para DB2. Proveedor OLE DB para AS/400 y VSAM. Esta sección describe la forma en que se pueden incorporar los sistemas de archivos heredados en las aplicaciones Web mediante la utilización de un proveedor de datos para acceder a los archivos de AS/400 y VSAM a nivel de registro y trasladar los datos al entorno IIS 5.0. Para obtener información sobre el proveedor OLE DB para DB2, ver la documentación del producto SNA Server. Datos de archivos heredados e IIS 5.0 Para desarrollar aplicaciones Web que proporcionen datos almacenados en archivos VSAM y AS/400, se necesita obtener acceso a los archivos VSAM y AS/400 desde el entorno Windows 2000 Server. Esto se puede conseguir haciendo que los datos estén disponibles para las aplicaciones de los consumidores de los datos que ejecutan ASP: Acceso a los sistemas de archivos heredados que se ejecutan bajo MVS y OS/400 para recuperar los datos de negocio almacenados en ellos. Integración de los datos heredados con las aplicaciones y los datos del entorno IIS 5.0 utilizando el proveedor OLE DB para AS/400 y VSAM. Acceso a archivos VSAM y AS/400 con OLE DB y ActiveX Data Objects El proveedor OLE DB para AS/400 y VSAM es la primera aplicación que hace que los sistemas de archivos VSAM y AS/400 del mainframe a nivel de registro estén disponibles para las aplicaciones ASP. El proveedor de datos permite que las aplicaciones ASP consumidoras tengan acceso a los datos de misión crítica disponi-

11 Acceso a aplicaciones y datos heredados 415 bles en dichos sistemas de archivos. El proveedor de datos se incluye con SNA Server 4.0 SP2, Windows Client para SNA Server y el SNA Server SDK. Para más información sobre el desarrollo de aplicaciones ASP, ver el capítulo «Desarrollo de aplicaciones Web» en este libro. Descripción funcional del proveedor de datos El proveedor OLE DB para AS/400 y VSAM consta de dos componentes principales. El primero es un proveedor de datos compatible con OLE DB que aisla las complejidades de la programación en LU 6.2 del programador de OLE DB o Microsoft ActiveX Data Objects (ADO, Objetos de datos ActiveX). El segundo es un programa de administración de transacciones SNA Distributed Data Management (DDM, Administrador de datos distribuidos SNA) que se ejecuta como un servicio de Windows 2000 Server o como una aplicación bajo Windows 95 o Windows 98. La siguiente lista resume los usos del proveedor de datos: Desde Windows 2000 Server, se puede obtener acceso a los sistemas de archivos VSAM y AS/400 a través de los componentes del servidor de protocolos DDM de IBM (Controlador OLE DB/DDM) instalados en la mayoría de los sistemas de hosts IBM. No existe la necesidad de instalar el software de Microsoft en el sistema de hosts. Se pueden utilizar aplicaciones personalizables para leer y escribir en archivos VSAM y AS/400 que se encuentren en computadoras de hosts IBM. No existe la necesidad de migrar los archivos al entorno Windows 2000 Server. Se puede obtener acceso a clases de extensión de registros lógicos fijas y variables, así como al bloqueo de archivos y registros, mientras se mantienen los atributos de los archivos y registros. Se puede obtener acceso a la mayoría de tipos de archivos AS/400 (tanto físicos como lógicos) y a la mayoría de tipos de conjuntos de datos de los mainframes populares: secuencial (SAM), secuenciada por claves VSAM (KSDS), secuenciada por entrada VSAM (ESDS), de registro relativo VSAM (RRDS) y particionada (PDS/PDSE). Consolidación de los sistemas existentes con el proveedor de datos El proveedor de datos posibilita la integración de datos de archivos heredados no estructurados con datos del entorno Windows 2000 Server. El protocolo DDM proporciona comunicaciones programa-a-programa a través de SNA Server 4.0 SP2 y protocolos de host nativos (como LU 6.2 y TCP/IP). No se requiere un desarrollo personalizado en el sistema de hosts. Los servidores DDM de IBM están disponibles en los sistemas de hosts que admiten acceso a archivos a nivel de registro. Por ejemplo, Distribute File Manager (Administrador de archivos distribuidos), un componente del IBM Data Facility Storage Management Subsystem (DFSMS) versión 1R2 o superior, es un servidor DDM destino instalado en muchos mainframes que se ejecutan bajo MVS u OS/390. En computadoras AS/400, OS/400 (versión 2R2 o superior) se ejecuta como un servidor DDM. El proveedor de datos comunica con el Data File Manager y OS/400 a través de LU 6.2 y TCP/IP. El proveedor de datos facilita a los desarrolladores la obtención de acceso a las interfaces de los componentes de alto nivel como OLE DB o ADO. Éste admite el desarrollo en Visual Basic, Visual C++, VBScript y Microsoft JScript. Los desarrolladores Web no necesitan conocer la forma de ejecutar SNA o LU 6.2. Escenario: Utilización del proveedor de datos para obtener acceso a los archivos del host Con el proveedor de datos, se puede obtener acceso a los datos de los archivos de un host IBM desde una aplicación Web basada en Windows 2000 Server. Supóngase que se desea añadir el contenido de un archivo heredado almacenado en un mainframe IBM o una computadora AS/400 a una aplicación ASP que se ejecuta bajo IIS 5.0. ASP puede interpretar las demandas de usuario y dar formato a los datos devueltos al usuario a través de las páginas Web. El proveedor de datos puede procesar las llamadas desde el entorno IIS 5.0 y pasar los datos devueltos desde el entorno del mainframe a IIS.

12 416 Microsoft Windows 2000 Server. Kit de recursos Este escenario requiere seis pasos principales: Paso 1 (organización y configuración): Configuración del proveedor de datos. Paso 2 (tiempo de diseño): Definición de los requerimientos de la aplicación. Paso 3 (tiempo de diseño): Escritura de la aplicación. Paso 4 (tiempo de diseño): Prueba de la aplicación. Paso 5 (implantación): Implantación de los componentes de la aplicación. Paso 6 (postimplantación): Mantenimiento de la aplicación. Paso 1: Configuración del proveedor de datos Para desarrollar una aplicación utilizando el proveedor de datos, se deben utilizar los siguientes requisitos del sistema: Windows 2000 Server o Windows 2000 Professional. IIS 5.0 o superior. Éste incluye las Microsoft Data Access Components 2.1 (MDAC 2.1, Componentes de acceso a datos de Microsoft) admitidas por el proveedor de datos. Microsoft Windows Client para Microsoft SNA Server o SNA Server 4.0. Hay que configurarlo para que se conecte a SNA Server 4.0 SP2. Además, deben estar instalados y configurados los siguientes paquetes: El proveedor de Microsoft OLE DB para AS/400 y VSAM. El proveedor de Microsoft OLE DB para los conectores de AS/400 y VSAM para Microsoft Management Console (MMC). Se configura el servicio DDM para el host destino y el PC local. Opcionalmente, se configuran las fuentes de datos si no se está pasando la información a través de las aplicaciones consumidoras ADO. Se configura la descripción de las columnas de datos del mainframe para su asociación con los tipos de datos de OLE DB. Paso 2: Definición de los requerimientos de la aplicación 1. Se compila una lista de archivos del host destino, claves y caminos de índice alternativos. Se define el subconjunto de registros que se va a leer desde la aplicación Web destino. 2. Se especifican los objetos, métodos, propiedades y colecciones ADO admitidos por el proveedor de datos, que se van a utilizar en la aplicación. 3. Se considera la utilización de Recordset.Filter para definir conjuntos de registros basados en criterios de búsqueda lógica y para buscar registros en base al programa de aplicación y la entrada del usuario. 4. Se utiliza la colección de errores ADO para producir errores en formatos que el programa pueda comprender. Esto evitará el paso de condiciones de error innecesarias al navegador Web. 5. Se utiliza la transformación automática de datos de AS/400 a OLE DB, o una asociación personalizada, utilizando un archivo de descripción de las columnas de datos del host de servicio DDM. 6. Se decide si se asocian automáticamente los identificadores de los usuarios conectados obtenidos desde el navegador Web. 7. Se selecciona una opción de implantación y se decide si se ejecuta el servicio DDM en la computadora que ejecuta SNA Server o en la computadora que ejecuta Windows Client para SNA Server. Paso 3: Escritura de la aplicación 1. Se escriben secuencias de comandos para obtener acceso a ADO 2.0 desde una página ASP. Esta debería estar escrita en un lenguaje que admita la referencia de objetos Automation, como VBScript o JScript. 2. Se convierten los datos para asociar los tipos de datos de OLE DB y del host. Se debe hacer referencia al esquema del conjunto de registros para determinar qué tipos de datos del host se admiten. Se garantiza que el dato del host es válido antes de escribir en los archivos del host, especialmente si una aplicación del host obtiene acceso de forma concurrente a los archivos de datos del host.

13 Acceso a aplicaciones y datos heredados Se comprueba la sintaxis de los métodos y las propiedades de OLE DB admitidos. Se debe prestar una atención especial a la cadena de conexión (que se construye utilizando los cuadros de diálogo del enlace de datos) y a los parámetros de Recordset.Open. Éstos son únicos para cada proveedor OLE DB. 4. Si resulta apropiado, se utiliza el marcador de posición MS$NAME para pasar el identificador y la contraseña de usuario a la utilidad de seguridad del host SNA Server 4.0 SP2. La utilidad de seguridad realiza una asociación de la seguridad entre las cuentas de Windows y las cuentas del mainframe. 5. Se programan algunos bucles para asegurar que los conjuntos de registros destino contienen datos antes de pasar los métodos del conjunto de registros. Esto permitirá los retardos provocados por las condiciones de la red y la lejanía de los hosts destino. Paso 4: Prueba de la aplicación La prueba de la nueva aplicación asegura que: Las páginas ASP se ejecutan correctamente. Existen comunicaciones puras entre ADO y el Servicio DDM de la parte de Windows 2000 Server. Se considera el inicio automático del Servicio DDM en Windows 2000 Server para asegurar la disponibilidad oportuna de una conexión del PC al host con tiempo mínimo de establecimiento de la sesión. Existen operaciones fiables y eficientes entre el Servicio DDM y el host por medio de SNA Server 4.0 SP2. Se considera el mantenimiento de la conexión entre SNA Server y la conexión activa del host para reducir el tiempo de establecimiento de la sesión. Existe una visualización apropiada de los datos de las aplicaciones Web. Se asegura la integridad de los datos de los archivos del host, debido a que puede existir una pérdida de precisión cuando se trasladan datos desde el host hacia el PC y viceversa. Paso 5: Implantación de los componentes de la aplicación Antes de implantar la aplicación se debe instalar lo siguiente en cada computadora de producción: Windows 2000 Server o Windows 2000 Professional. Windows Client para SNA Server. IIS 5.0. El proveedor OLE DB para AS/400 y VSAM. Las páginas ASP que solicitan datos de los archivos heredados. El Servicio DDM que se ejecuta con Windows Client para SNA Server o SNA Server 4.0. Para mejorar la sensibilidad, se considera que el Servicio DDM se inicia automáticamente cuando se reinicia el sistema. Paso 6: Mantenimiento de la aplicación Si se modifican las secuencias de comandos de las páginas ASP, se necesita volver a probar la aplicación utilizando las siguientes directrices: Probar la aplicación completamente si se añaden nuevas secuencias de comandos o fragmentos de secuencias de comandos a las páginas ASP existentes que solicitan datos desde nuevas fuentes de datos. Si se reestructuran los archivos de datos del host destino o se añaden nuevas tablas al host, se necesitan incorporar estas modificaciones en la aplicación Web modificando los métodos ADO y creando nuevos conjuntos de registros cuando sea necesario. Si cambia la conectividad del host, se debería verificar el Windows Client para la configuración de SNA Server o las fuentes de datos del proveedor de datos.

14 418 Microsoft Windows 2000 Server. Kit de recursos Replicación de bases de datos heredadas Muchos de los datos almacenados en sistemas heredados residen en bases de datos relacionales. Una forma de obtener acceso a los datos heredados que utilizará IIS 5.0 es replicar las tablas de las bases de datos desde una aplicación heredada hacia SQL Server 7.0 ejecutándose sobre Windows 2000 Server. Por qué la replicación? La replicación de las bases de datos heredadas es un conjunto de procesos de conversión que copia, vuelve a dar formato y migra las tablas de las bases de datos para utilizarlas en las bases de datos relacionales que se ejecutan bajo Windows 2000 Server. Utilizando los datos replicados desde una base de datos heredada, los desarrolladores y los ingenieros de sistemas pueden: Integrar los datos heredados con datos de la parte de Windows 2000 Server. Si se replican los datos para almacenarlos en una base de datos de la parte de Windows 2000 Server, IIS 5.0 conecta los clientes Internet o intranet a las páginas Web creadas dinámicamente. A continuación, se recuperan los datos a través del proveedor de OLE DB o Conectividad abierta de bases de datos (ODBC, Open Database Connectivity). Someter prontamente los datos a una nueva lógica de negocio. Para los nuevos procesos incluidos en la base de datos, el desarrollo en Windows es menos costoso que el desarrollo de sistemas heredados. Administrar los datos eficientemente. Windows 2000 Server con IIS 5.0 proporciona un conjunto común de herramientas de administración de sistemas, herramientas de administración de bases de datos, servidores de aplicaciones Web y servicios de transacciones. Si la aplicación lo requiere, se vuelven a replicar los datos desde SQL hacia la base de datos heredada. Replicación de datos usando Servicios de transformación de datos Servicios de transformación de datos (DTS, Data Transformation Services) es una característica estándar de Microsoft SQL Server 7.0. Con DTS se pueden importar datos a SQL Server 7.0 desde las bases de datos heredadas utilizando OLE DB. A continuación se proporciona una introducción a las capacidades y características de DTS. Para una información detallada, ver la documentación del producto SQL Server 7.0. Si aún se está utilizando una versión de SNA Server 4.0 anterior a SP2, se pueden replicar los datos de DB2 mediante HDR. Ver el apartado «Replicación de tablas DB2 utilizando Host Data Replicator (Replicador de los datos del host)» más adelante en este capítulo. Importar, exportar y transformar los datos de las bases de datos De forma interactiva o automática, DTS simplifica el proceso de importación y transformación de datos desde fuentes múltiples y heterogéneas. Admite la dinastía de los datos, lo que facilita el seguimiento del origen de los datos. Además, DTS permite trasladar y transformar los datos hacia y desde las siguientes fuentes: Los proveedores de OLE DB para SQL Server 7.0 y otros. Fuentes de datos ODBC como Microsoft Access, Oracle y DB2, que utilizan el proveedor de OLE DB para ODBC. DTS proporciona la funcionalidad para importar, exportar y transformar los datos entre Microsoft SQL Server 7.0 y cualquier formato OLE DB. Utilizando DTS, es posible construir almacenes de datos y mercados de datos en SQL Server 7.0 importando y transformando los datos desde múltiples fuentes heterogéneas sobre una base planificada regularmente (sin requerir la intervención del usuario).

15 Acceso a aplicaciones y datos heredados 419 DTS importa y exporta datos entre aplicaciones leyendo y escribiendo datos en un formato común. Por ejemplo, DTS puede importar datos desde un archivo de texto ASCII o una base de datos Oracle en SQL Server 7.0. Alternativamente, los datos pueden exportarse desde SQL Server 7.0 a una fuente de datos ODBC o una hoja de cálculo de Microsoft Excel. Nota: DTS sólo traslada la estructura y los datos entre fuentes de datos heterogéneas. Los disparadores, procedimientos almacenados, reglas, valores por omisión, restricciones y tipos de datos definidos por el usuario no se convierten entre fuentes de datos heterogéneas. Las transformaciones se aplican a los datos fuente antes de que se almacenen en su nuevo destino. Por ejemplo, DTS permite calcular nuevos valores desde uno o más campos fuente. También permite almacenar un campo simple que se haya dividido en múltiples valores en columnas de destino separadas. Las transformaciones facilitan la implementación de la validación, refinado y mejora de los datos complejos durante la importación y la exportación. DTS admite paquetes multietapa, donde varios archivos se pueden procesar independientemente y, a continuación, agruparlos en una única etapa final. Los registros simples de un archivo se pueden dividir en múltiples registros de destino, o múltiples registros fuente se pueden agregar en registros únicos de destino. Creación de paquetes DTS con asistentes DTS Export Wizard DTS Export Wizard conduce a través del proceso de creación de paquetes DTS para exportar datos desde una base de datos SQL Server 7.0 hacia fuentes de datos heterogéneas. Este asistente incluye una ayuda. DTS Import Wizard DTS Import Wizard conduce a través del proceso de creación de paquetes DTS para importar datos heterogéneos hacia una base de datos SQL Server 7.0. Este asistente incluye una ayuda. Replicación de tablas DB2 utilizando Host Data Replicator (Replicador de los datos del host) Si aún se está utilizando una versión de SNA Server 4.0 anterior a SP2, se pueden replicar los datos DB2 mediante HDR e IIS 5.0. HDR (Host Data Replicator, Replicador de los datos del host) es un producto software de replicación de bases de datos que copia los datos predefinidos de las tablas de las bases de datos DB2 de IBM en las tablas de las bases de datos de Microsoft SQL Server. Se pueden realizar por demanda, en un único momento planificado o de acuerdo a un plan recurrente. HDR también tiene la capacidad de invertir el proceso, replicando las tablas SQL Server 7.0 para su utilización en una base de datos DB2. HDR está compuesto por el servicio replicador de datos (un servicio del sistema operativo Windows 2000) y Data Replicator Manager (una aplicación del sistema operativo Windows 2000 para la administración). Data Replicator Manager tiene una interfaz de usuario similar a las que aparecen en SQL Enterprise Manager y las partes de planificación de SQL Executive. Replicación bidireccional HDR realiza una replicación de refresco bidireccional completa. Se copia una «instantánea» completa de la tabla fuente en la tabla de la base de datos de destino, mediante Bulk Copy Program (BCP) cuando se copia a SQL Server 7.0, o «inserciones» ODBC cuando se copia a DB2. Todos los registros de la tabla de destino se sobreescriben cada vez que ocurre una replicación. Opcionalmente, se pueden agregar datos al final de la tabla existente, sin proporcionar cambios en la estructura de la tabla.

16 420 Microsoft Windows 2000 Server. Kit de recursos Procesamiento y filtrado flexibles HDR reproduce de forma flexible los datos del host en su totalidad o en parte de acuerdo a los criterios de selección determinados por el usuario: Replicación de las columnas seleccionadas («descomposición vertical»). Replicación de las filas seleccionadas («descomposición horizontal»). Replicación de las columnas seleccionadas de las filas seleccionadas (descomposición vertical y horizontal combinada). HDR puede tablas completas o mezclar los datos replicados con tablas existentes que se ubican en la base de datos de destino. Se pueden realizar cambios en el formato o en los valores de los datos de varias formas: Construcción de columnas de destino calculadas («derivadas») a partir de datos fuente. Utilización de expresiones SQL para modificar los datos de las tablas de destino antes o después de la replicación. Modificar los nombres de las columnas, los tipos de datos de las columnas o el orden de las columnas entre fuente y destino. Planificación HDR ofrece la posibilidad de realizar la replicación simple por demanda (repetible posteriormente o a través de interfaces de programación como SP_RUNTASK). También permite la replicación simple o repetida en tiempos predefinidos. Estadísticas Las estadísticas acumuladas por HDR están disponibles a través de Data Replicator Manager o a través del Monitor de sistema de Windows 2000 Server. Las estadísticas incluyen lo siguiente: Productividad de cada operación de replicación. Número de bytes transferidos en cada operación de replicación. Tiempo transcurrido para cada operación de replicación. Seguridad Data Replicator Manager solicita al administrador que proporcione una cuenta y una contraseña válidas de SQL Server 7.0 cada vez que establezca una conexión al Servicio Data Replicator. Si no se proporcionan una cuenta y una contraseña correctas, Data Replicator Manager cierra la conexión, evitando así la administración del servicio asociado y sus suscripciones (una suscripción es una operación de replicación que incluye una tabla fuente y una tabla destino. Un único Servicio Data Replicator puede gestionar muchas suscripciones). Para DB2, durante la configuración de la suscripción, un administrador debe proporcionar una cuenta y una contraseña válidas de DB2. HDR también admitirá la opción 3.0 Single Sign On de SNA Server 4.0. Los administradores de bases de datos que utilizan HDR no necesitan hacer un seguimiento a las múltiples contraseñas. La propiedad de la tabla de destino SQL Server 7.0 se puede definir durante la configuración de la suscripción. El acceso a los datos replicados es entonces controlado a través de las medidas de seguridad normales de SQL Server 7.0. Rendimiento Se pueden filtrar los nombres de las tablas fuente para reducir el tráfico de la red y mejorar el rendimiento durante la configuración. Esto permite que las suscripciones se actualicen en entornos con gran número de

17 Acceso a aplicaciones y datos heredados 421 posibles tablas fuente. Además, se pueden agrupar las conexiones a los servidores fuente y destino para evitar costes de rendimiento por el restablecimiento innecesario de las conexiones. Los tamaños de las agrupaciones se pueden ajustar según las necesidades. El Servicio Data Replicator almacena en la caché la información de la suscripción. De esta forma, se evitan los costes de rendimiento por la obtención de la información desde la base de datos de control del replicador de datos en cada instante de replicación planificado. HDR no coordina las transacciones en línea de las bases de datos. De esta forma, no es una herramienta apropiada para realizar actualizaciones rutinarias de las bases de datos. Plataformas admitidas HDR se admite en las siguientes plataformas: SNA Server 4.0 o superior. Microsoft Windows NT Server 3.51 o superior (para Intel y Alpha). Microsoft SQL Server 6.5 o superior. DB2 de IBM incluyendo DB2 (MVS), DB2/VM (SQL/DS), DB2/400 y la familia común (DB2/2, DB2/6000 y DB2/2 Windows 2000 Server mediante APPC). Migración de procesos de transacción Servicios de componentes es un servidor de gestión de transacciones que proporciona una gestión de las transacciones fiable y segura para las aplicaciones Web. La siguiente sección proporciona información que puede ayudar a planificar una migración de aplicaciones conducidas por transacciones desde cualquier entorno de herencia al entorno Windows 2000 Server, donde Servicios de componentes gestionan las transacciones solicitadas por IIS. Por qué se utilizan las transacciones? Dos modificaciones en el uso de la tecnología de la información hacen que la implantación incrementada de los sistemas de gestión de transacciones afecte a muchas organizaciones: La creciente demanda para utilizar Internet e intranets para el intercambio de información segura, incluyendo intercambios financieros a través de comercio en línea. La creciente tendencia a ejecutar múltiples componentes software reutilizables dentro de una aplicación, incluyendo los componentes utilizados en el acceso a bases de datos. Como se indicó, el crecimiento explosivo de Internet e intranets organizacionales ha presentado nuevas oportunidades para hacer negocio a través de redes de datos. La expresión elemental de hacer negocio, el intercambio de dinero por productos o servicios, requiere la actualización de más de una base de datos para cada intercambio. Además, el diseño de software está avanzando hacia un modelo de componentes en el que las aplicaciones se construyen a partir de varios segmentos de código que funcionan de manera independiente. A menudo, una aplicación permite que más de un componente actualice una o más bases de datos de forma concurrente. Las actualizaciones concurrentes requieren un administrador de transacciones para asegurar la integridad de las transacciones mientras se optimiza el rendimiento. Para más información, ver el apartado «Acceso a datos y transacciones» de este libro.

18 422 Microsoft Windows 2000 Server. Kit de recursos Migración a Servicios de componentes Puesto que existe una creciente necesidad de gestionar las transacciones del Web y debido a que existen muchos sistemas de transacción sobre datos de procesamiento de redes heredados que son críticos para el negocio, muchas organizaciones necesitan gestionar las transacciones en ambos entornos. Un obstáculo serio para conseguir esto es que los sistemas de transacción heredados no se extienden a través de los límites, como el límite entre las redes SNA heredadas y las intranets basadas en TCP/IP con Windows 2000 Server. En otras palabras, un programa de procesamiento de transacciones heredado que se ejecuta bajo CICS o IMS no puede hacer un seguimiento o verificar una actualización de la base de datos sobre una red Windows 2000 Server. Adicionalmente, los costes de desarrollo, alojamiento y escalado son mayores en el entorno de herencia que en la red Windows 2000 Server. La mejor solución es un sistema de gestión de transacciones basado en Windows 2000 Server que coordine las transacciones Web basadas en IIS 5.0 con los programas de procesamiento de transacciones heredados. Cualquier transacción puede entonces incluir actualizaciones de bases de datos ejecutándose bajo Windows 2000 Server, un programa de procesamiento de transacciones del mainframe o ambos a la vez. Los procesos de transacción se pueden migrar selectivamente a un software de gestión de bases de datos basado en Windows 2000 Server, como SQL Server 7.0 y cualquier proceso de transacción que abandone el mainframe puede ser gestionado también desde Windows 2000 Server. Características y capacidades Servicios de componentes expande las capacidades de IIS 5.0 para incluir la gestión de transacciones basada en Web. Esencialmente, ésta es una solución de gestión de transacciones basada en componentes que proporciona un modelo de programación, un entorno en tiempo de ejecución y herramientas de administración de servidores gráficos, requeridos todos ellos para diseñar y desarrollar una aplicación de transacción y migrar un proceso heredado hacia ella. Con Servicios de componentes, los desarrolladores Web que utilicen páginas ASP pueden desarrollar capacidades completas de gestión de transacciones para su implantación en el Web. Mediante la implantación de Servicios de componentes como sistema de gestión de transacciones, se puede sacar provecho de las ventajas del entorno Windows 2000 Server y migrar los procesos transaccionales heredados que estén seleccionados. Mientras tanto, Servicios de componentes extiende la gestión de transacciones para incluir el abandono de procesos que se ejecutan en el entorno de herencia. Además de la monitorización y la gestión completa de las transacciones, así como el bajo coste de los sistemas y software escalados que se basan en Windows 2000 Server, Servicios de componentes ofrece ventajas sobre sus partes correspondientes basadas en mainframe en tiempo de diseño y de ejecución. Otras ventajas son la referentes al mantenimiento y la administración. Tiempo de diseño de Servicios de componentes El modelo de programación de Servicios de componentes proporciona la base para el desarrollo de componentes que encapsulan la lógica de negocio. Servicios de componentes se ajusta perfectamente en un modelo de programación de tres niveles. Actuando como middleware, gestiona los componentes que hacen posible que una aplicación Web administre muchos clientes. También proporciona a los desarrolladores una gran flexibilidad: El modelo acentúa una arquitectura lógica para las aplicaciones, más que una física. Cualquier servicio puede llamar a cualquier componente. Servicios de componentes conecta las demandas de transacciones (llamadas desde secuencias de comandos en páginas ASP) con la lógica de negocio y con las aplicaciones de bases de datos, de forma que no se requiere el desarrollo de estos procesos. Las aplicaciones están distribuidas, lo que significa que se pueden ejecutar los componentes correctos en los lugares correctos. Esto beneficia a los usuarios y optimiza los recursos de la red y la computadora.

19 Acceso a aplicaciones y datos heredados 423 Aplicaciones de tres niveles y middleware Una aplicación de tres niveles divide una aplicación de red en tres áreas lógicas. Middleware, como Servicios de componentes, conecta los tres niveles: presentación, lógica de negocio y procesamiento de datos. El nivel 1 maneja la presentación. En una aplicación Web, el navegador demanda datos y se le envían desde el servidor Web para su visualización. El nivel 2 procesa la lógica de negocio (el conjunto de reglas para el procesamiento de la información del negocio). En una aplicación Web basada en IIS 5.0, el procesamiento del nivel 2 se realiza mediante los componentes de IIS 5.0. El nivel 3 procesa los datos (las bases de datos y los archivos asociados en que se almacenan los datos). En una aplicación Web, el nivel 3 consta de un sistema de gestión de bases de datos (DBMS) o un sistema de acceso a archivos con sus datos asociados. Los sistemas de tres niveles son más fáciles de modificar y de mantener que los sistemas de dos niveles debido a que la programación de la presentación, la lógica de negocio y el procesamiento de datos están separados por el diseño. Esta arquitectura permite repetir el desarrollo para que actúe sobre un nivel, sin afectar a los otros. Middleware, como Servicios de componentes, hace un uso eficiente de los recursos de forma que los programadores de aplicaciones Web se pueden concentrar en la lógica de negocio. Servicios de componentes puede conectar las demandas del navegador (nivel 1) con la lógica de negocio (nivel 2). En el nivel 3, éste puede conectar la lógica de negocio con las bases de datos y gestionar todas las actividades de la transacción. Eficiencia del desarrollo Las interfaces de programación de aplicaciones (API) y los distribuidores de recursos hacen que las aplicaciones sean escalables y robustas. Los distribuidores de recursos son servicios que gestionan la arquitectura de estado compartido no duradero en nombre de los componentes de la aplicación dentro de un proceso. De esta forma, no hay que encargarse de las tareas de programación tradicionales asociadas con el mantenimiento del estado. Servicios de componentes funciona con cualquier herramienta de desarrollo de aplicaciones capaz de generar bibliotecas de enlace dinámico basadas en COM (DLL). Por ejemplo, se puede utilizar Visual Basic, Visual C++, Visual J++ o cualquier otra herramienta Microsoft ActiveX para desarrollar aplicaciones de Servicios de componentes. Servicios de componentes está diseñado para funcionar con una amplia variedad de gestores de recursos, incluyendo sistemas de bases de datos relacionales, sistemas de archivos y sistemas de almacenamiento de documentación. Los desarrolladores y los proveedores de software independientes pueden seleccionar de entre un amplio rango de gestores de recursos y pueden utilizar dos o más gestores de recursos dentro de una misma aplicación. El modelo de programación de Servicios de componentes simplifica la migración haciendo el desarrollo de aplicaciones de transacción más simple y rápido que el que permiten los modelos de programación tradicionales. Para más información sobre el desarrollo de aplicaciones de Servicios de componentes, ver el apartado «Acceso a datos y transacciones» de este libro. Tiempo de ejecución de Servicios de componentes El entorno en tiempo de ejecución de Servicios de componentes es una plataforma de segundo nivel para la ejecución de componentes COM. Este entorno proporciona un conjunto comprensivo de servicios del sistema incluyendo: Transacciones distribuidas. Gestión automática de procesos y elementos de proceso. Instancia de objetos y gestión de zonas de conexión para mejorar la escalabilidad y el rendimiento de la aplicaciones. Un servicio de seguridad distribuido que controla la llamada y el uso de los objetos. Una interfaz gráfica de usuario (GUI) que admite la administración de sistemas y la gestión de componentes.

20 424 Microsoft Windows 2000 Server. Kit de recursos Esta infraestructura de tiempo de ejecución facilita mucho el desarrollo, la implantación y la gestión de las aplicaciones haciéndolas escalables y robustas. El rendimiento global se optimiza mediante la gestión de la instanciación de componentes y los conjuntos de conexión. Servicios de componentes instancia los componentes justo en el momento de las transacciones. A continuación, depura la información del estado desde la instancia cuando se completa la transacción y reutiliza la instancia para la siguiente transacción. Por ejemplo, los usuarios pueden introducir demandas de transacciones desde sus navegadores a una página ASP que contiene el código necesario para llamar a un componente COM. Cuando Servicios de componentes recibe estos mensajes, se gestionan las transacciones utilizando componentes ya instanciados. Esto minimiza la instanciación de objetos y el número de conexiones requerido, lo que a menudo inhibe el rendimiento de los sistemas que admiten transacciones. Herramienta administrativa Servicios de componentes El Explorador de Servicios de componentes de Microsoft es una herramienta de administración gráfica utilizada para registrar, implantar y gestionar los componentes que se ejecutan en el entorno en tiempo de ejecución de Servicios de componentes. Con el Explorador de Servicios de componentes, se pueden desarrollar secuencias de comandos de objetos de administración para automatizar la implantación de los componentes. Planificación de una migración a Servicios de componentes Cuando se migran procesos y bases de datos desde un entorno de herencia (programas de procesamiento de transacciones que se ejecutan bajo CICS en un mainframe) hacia Servicios de componentes, los programas de procesamiento de transacciones continuarán su ejecución en el mainframe durante un momento. Para migrar a Servicios de componentes: Se utilizan Servicios de componentes y COMTI para extender la gestión de las transacciones de forma que incluya todas las partes de cada transacción. Esto incluye las actualizaciones que tienen lugar en las bases de datos que se ejecutan bajo Windows 2000 Server, así como las actualizaciones que tienen lugar en el mainframe. Se desarrollan las secuencias de comandos de las páginas ASP de forma que IIS 5.0 llama a los componentes COM que ejecutan la transacción. Se pueden migrar partes de la infraestructura de transacciones heredadas a SQL Server 7.0 y utilizar Servicios de componentes para gestionar las partes de la transacción del host heredado. IIS 5.0 puede acceder a todos los datos mediante secuencias de comandos en páginas ASP. Asignación de las tareas de transacción con aplicaciones basadas en Windows 2000 Server La Tabla 10.1 asocia las funciones relacionadas con las transacciones con las aplicaciones utilizadas para admitirlas en el entorno Windows 2000 Server. Tabla Funciones relacionadas con las transacciones y aplicaciones basadas en Windows 2000 Server. Tarea relacionada con las transacciones Aplicación basada en Windows 2000 Server Gestión de transacciones Servicios de componentes Gestión de recursos de datos SQL Server 7.0 Llamada a las transacciones desde páginas Web ASP Conexión a una red heredada SNA Server 4.0 SP2 Extensión de las transacciones a programas de COMTI procesamiento de transacciones heredados