Técnicas Avanzadas para Gestión de Sistemas de Información. Tarea obligatoria sobre: Tecnologías para Sistemas de Información

Transcripción

1 Instituto de Computación Facultad de Ingeniería Universidad de la República Oriental del Uruguay Técnicas Avanzadas para Gestión de Sistemas de Información Carrera de Ingeniería en Computación Edición 2003 Tarea obligatoria sobre: Tecnologías para Sistemas de Información Título Estudiantes Estado del Arte en Federico Becaría Rodrigo Suárez Fabián Feijó Bernardo Fagalde Docente encargado: Dr. Ing. Hermann Steffen 1

2 T.A.G.SI Bernardo Fagalde Fabián Feijó Federico Becaría Rodrigo Suárez Instituto de Computación Facultad de Ingeniería Universidad de la República

3 Índice Índice... 2 Abstract... 4 Contexto... 4 Contenido... 4 I. Introducción... 4 Ubicación lógica... 6 Ubicación física... 6 Otras funcionalidades... 7 II. BEA TUXEDO Un poco de historia... 8 Características del sistema... 8 Componentes ATMI... 9 Infraestructura de BEA Tuxedo... 9 Interface de Programación ATMI BEA Tuxedo Workstation Componentes CORBA Tuxedo IIOP Listener/Handler Objetos de ambiente y TP Framework Cliente ActiveX Escalabilidad y Performance Soporte de plataformas, lenguajes y modelos de programación Seguridad Herramientas de administración Estándares soportados Acceso web a los servicios de aplicación de BEA Tuxedo Acceso a los servicios de aplicación de Tuxedo a través de Web Services III. MTS (Microsoft Transaction Server) Un poco de historia Propósito del MTS Características El modelo de operaciones en MTS Arquitectura de MTS Los componentes MTS Actividad Transaccional Dispensadores de Recursos Activación Just-in-Time Pooling de Recursos Seguridad Lenguajes y modelos de programación Component Object Model (COM) Componentes y objetos Conceptos fundamentales de COM DCOM COM El explorador COM Creación e instalación de paquetes IV ENCINA Especificaciones varias: Características generales Página 2 de 34

4 Soporte de estándares de la industria: Soporte de plataformas populares: Soporte de lenguajes de programación Escalabilidad y performance Alta disponibilidad y manejo de errores Seguridad Herramientas para administración: Componentes en el cliente y el servidor V Comparación Costos transaccionales entre MTS y Tuxedo Competencia de Encina Comparación entre Encina y Tuxedo Comercial Portabilidad e Interoperabilidad: Productividad de Programación: Integración con sistemas Legacy: Seguridad Escalabilidad Almacenamiento de Datos: Apéndice I: Glosario Apéndice II: Referencias Webgrafía Bibliografía Página 3 de 34

5 Abstract En este documento presentamos una visión general del estado actual de los monitores transaccionales. Se desarrollan a grandes rasgos tres de los productos mas conocidos en el mercado actual que implementan un monitor transaccional: TUXEDO, MTS y ENCINA Contexto Este trabajo se desarrolla en el marco de un obligatorio del curso Técnicas avanzadas para la gestión del Sistemas de Información (versión 2003). Esta materia forma parte de las materias electivas de la carrera de Ingeniería de computación de la Facultad de la República. Contenido En el primer Capítulo se define un monitor transaccional, se presenta a grandes rasgos la evolución de los mismos, su ubicación y se resume las funcionalidades más importantes que poseen. En los tres siguientes Capítulos se presentan los tres productos mas conocidos en el mercado actual que implementan un monitor transaccional: Capítulo II: TUXEDO, de BEA Systems Capítulo III: MTS, de Microsoft Capítulo IV: ENCINA, de IBM En el Capítulo V se presentan comparaciones entre los productos expuestos. En el Apéndice I se presenta el glosario y en el Apéndice II las referencias I. Introducción En la historia del acceso centralizado a datos, los primeros problemas que se plantearon fueron los de concurrencia al acceder a los mismos archivos. Estos problemas ya estaban siendo resueltos por los sistemas operativos multitarea. Por naturaleza, los problemas que resolvían eran los de acceso concurrente a distintos recursos. A medida que la tecnología y el volumen tanto de información como de usuarios fue aumentando, los Sistemas Operativos (SO) se vieron sobrecargados por estas actividades y su performance se vio afectada. Los Sistemas de Gestión de Base de Datos (SGBD) aparecieron como una solución para aliviar al SO y permitirle que se ocupara de las demás tareas. El SGBD se especializa en atender los requerimientos concernientes a la base de datos, pero de todas maneras no es independiente del SO. Estos requerimientos ya no eran simplemente consultas, sino que se maneja el concepto de transacción, fundamental para entender el ambiente en el que estamos desarrollando el tema. Por lo tanto daremos una pequeña introducción a lo que son y que características deben cumplir: Una transacción se define como una unidad lógica de procesamiento de base de datos. La duración de una transacción no es despreciable, pero lógicamente se debe ver como una unidad indivisible, es decir que se realiza por completo o no se realiza en absoluto. Una vez iniciada una transacción se considera distintos estados de la misma hasta su finalización. Cualquiera sea el camino que siga una transacción deberá Página 4 de 34

6 terminar habiendo logrado su objetivo inicial por completo o no habiéndolo logrado en absoluto. leer, escribir inicio fin trans. Parcialmente confirmar activa confirmada transacción confirmada abortar abortar fallida terminada Una vez iniciada la transacción, entra en un estado activo y permanece en él mientras se ejecuten las lecturas y escrituras que la componen. Una vez que estas hayan terminado pasa a un estado parcialmente confirmado hasta que el gestor de transacciones verifique la independencia de las lecturas y escrituras realizadas con las demás transacciones que se están ejecutando concurrentemente. También se chequea que la transacción quedará permanentemente registrada en caso de la caída del sistema. Si ambos chequeos resultan satisfactorios se confirmará la transacción y terminará. En caso contrario se abortará y resultará en una transacción fallida, deshaciendo lo realizado por la transacción y terminando. Un sistema transaccional debe tener la capacidad de mantener las características ACID de las mismas. Estas son: Atomicidad: (Atomicity) Una transacción es una unidad atómica de procesamiento. Se realiza por completo o no se realiza en absoluto Consistencia: (Consistency) La ejecución de la transacción no debe dejar a la Base de Datos en un estado inconsistente Aislamiento: (Isolation) Una transacción no debe afectar ni ser afectada por otra que se está ejecutando concurrentemente Durabilidad o permanencia: (Durability) Una vez que una transacción se ha confirmado, los efectos de modificación que esta tuvo en la Base de Datos deben ser mantenidos, incluso frente a una caída del sistema posterior. El manejo de los distintos estados, y el compromiso de mantener las características ACID son responsabilidad del SGBD. A medida que continuó el avance en los volúmenes de información y la concurrencia (especialmente esta última), el SGBD se ocupaba del manejo de las transacciones, y el cuello de botella se empezó a ver en la cantidad de conexiones que debían mantenerse (una por transacción). Para cada transacción era creado un proceso (asignación de recursos mediante) y luego se ejecutaba, cuando esta terminaba se consideraba el proceso finalizado y se liberaban los recursos asignados. Esta asignación de recursos, por lo tanto el proceso en sí era creado por el SO, aunque la ejecución y el acceso a la BD era manejado por el SGBD. Para atacar este problema se crean los monitores transaccionales (MT). Entonces, en principio los MT fueron creados para Página 5 de 34

7 gestionar los procesos (uno por conexión) que eran creados para acceder a la BD. Con el paso del tiempo se le fueron agregando otras funcionalidades como ser: - acceso a servicios (aplicaciones distribuidas) - balance de carga - control de seguridad (acceso a la BD) Por lo tanto, aplicaciones que acceden a la BD y antes estaban en el cliente o en el servidor se han trasladado al MT. Esto tiene la buena característica de no sobrecargar al servidor y ser accesible de mas puestos cliente. Ubicación lógica Un MT se encuentra en una capa intermedia entre los clientes (aplicaciones cliente) y el SGBD: MT El MT mantiene una conexión con cada cliente por cada requerimiento y una con el SGBD. También puede mantener mas de una conexión con el SGDB si la carga lo amerita, pero siempre mantendrá menor cantidad que las que mantiene con los clientes. Ubicación física El MT puede estar centralizado en un servidor o puede estar distribuido, parte en el cliente y parte en el servidor. Solamente en el servidor: Página 6 de 34

8 MT En el cliente y en el servidor: MT (client) MT (client) MT (client) MT (server) Otras funcionalidades Como se ha mencionado, en la evolución de los servidores transaccionales se le han ido agregando funcionalidades al mismo. La ubicación, ya que las transacciones pasan todas por él, lo hacen ideal para colocarle las políticas de seguridad a la BD y también aliviar al SGBD de esta tarea. Lo que en realidad no fue una ampliación de la funcionalidad, si no mas bien una fusión de componentes resulta en lo que hoy conocemos como servidor de aplicaciones. Los ORB (Object Request Brokers) eran componentes del SGBD que brindaban facilidad de acceso a procesos distribuidos. Resultaron entonces los servidores de aplicaciones que proporcionan un entorno de componentes (o servicios) en el servidor que gestiona la concurrencia, transacciones, balance de carga, seguridad, y gestión de recursos. Se podría ver gráficamente de la siguiente manera: Página 7 de 34

9 MT II. BEA TUXEDO 8.1 BEA Tuxedo es un producto de middleware que brinda el framework necesario para construir aplicaciones escalables, de n-capas, en ambientes heterogéneos y distribuidos. Estas aplicaciones distribuidas son independientes del hardware, sistema operativo, ambiente de red y base de datos. Un poco de historia... La última versión de BEA Tuxedo es la 8.1, lo cual indica un largo trayecto en la evolución de este software. En el año 1983, Tuxedo comenzó como proyecto en los Laboratorios Bell de la compañía AT&T. En 1989, Tuxedo fue transferido al Laboratorio de Sistemas UNIX de AT&T, y comenzó a ofrecerse como producto comercial. En el año 1993, Tuxedo fue transferido a Novell cuando esta empresa adquirió el Laboratorio de Sistemas UNIX. Finalmente, en 1996, BEA Systems comenzó un acuerdo exclusivo con Novell para distribuir y continuar el desarrollo de Tuxedo en diversas plataformas, como Windows y la mayoría de sistemas Unix. Características del sistema BEA Tuxedo brinda los siguientes servicios de middleware: Interface de programación ATMI ATMI significa Application-to-Transaction Monitor Interface, es la API principal del Tuxedo. Incluye funciones de manejo transaccional, envío/recepción de mensajes, manejo de buffers entre otros. Interface de programación CORBA Esta interface consiste de ORBs de C++ y Java que permite la comunicación entre objetos CORBA. Página 8 de 34

10 BEA Tuxedo incluye servicios de ATMI y objetos C++ CORBA necesarios para el manejo transaccional, seguridad, transporte de mensajes, administración del sistema, y soporte de base de datos para el procesamiento two-phase commit. Componentes ATMI BEA Tuxedo ATMI es un conjunto de tecnologías que permite desarrollar aplicaciones ATMI que utilicen e integren distintas plataformas, base de datos y sistemas operativos. Implementan el modelo de procesamiento de transacciones distribuidas (DTP) de X/Open brindando todas las características y ventajas de un sistema de procesamiento online de transacciones (OLTP). El modelo DTP asegura que un trabajo se completa de manera atómica, lo que significa que todas las bases de datos involucradas se actualizan de manera consistente si el trabajo es correcto, o vuelven a su estado original si el trabajo resulta fallido. Tuxedo ATMI está compuesto por los siguientes componentes: Infraestructura Tuxedo. Provee de servicios básicos para correr y administrar una aplicación ATMI. Interface de Programación ATMI BEA Tuxedo Workstation Permite clientes ATMI residir en workstations y comunicarse a través de una red con el servidor de aplicaciones ATMI. Infraestructura de BEA Tuxedo La Infraestructura de Tuxedo provee de servicios básicos para correr y administrar las aplicaciones. Es común al entorno ATMI como al entorno CORBA. Los componentes fundamentales de la infraestructura Tuxedo son los siguientes: Paradigmas de mensajería: existen distintas modalidades de transferencia de mensajes entre cliente y servidor. Tuxedo incluye los siguientes paradigmas: request/response, conversacional, encolado, publish-and-subscribe y notificación no solicitada. MIB Management Information Base: en ésta base se almacena toda la información de Tuxedo y sus aplicaciones. Servicios de procesamiento de aplicaciones. Servicios administrativos Tuxedo implementa el protocolo XA para comunicarse con administradores de recursos (Resource Manager). En la siguiente figura se puede apreciar la infraestructura Tuxedo: Página 9 de 34

11 Interface de Programación ATMI La interface de programación ATMI está formada por un conjunto de funciones en C y COBOL, que permiten conectar clientes ATMI con el sistema Tuxedo. Algunas de las tareas más importantes que pueden realizarse con ATMI son: inicialización de clientes, mensajería, gestión de transacciones, despacho de servicios, etc. Algunos ejemplos de funciones son los siguientes (en lenguaje C): tpinit - permite a un cliente unirse a una aplicación. tpalloc permite crear un buffer de mensaje. tpbegin, tpcommit y tpabort para manejo transaccional. tpopen, tpclose abre o cierra un resource manager. Las aplicaciones ATMI envían y reciben datos en Typed Buffers. Estos buffers no se crean a partir de memoria del sistema operativo sino que son creados a partir del sistema Tuxedo, lo cual brinda ventajas ya que el sistema puede manejarlos de manera óptima durante las comunicaciones. Estos buffers contienen información sobre ellos mismos (metadata), lo cual permite al usuario desarrollador abstraerse de la representación de los datos en las distintas máquinas que forman parte de una aplicación Tuxedo, lográndose mantener una independencia de máquina. BEA Tuxedo Workstation Los componentes cliente de ATMI permiten a un cliente residir en un equipo remoto que no tenga una instalación completa del sistema. Las comunicaciones entre el cliente y el servidor de aplicaciones se realizan a través de la red. Algunas ventajas de tener estos componentes en el cliente son: Menos sobrecarga administrativa Mayor seguridad al mantener a los clientes por fuera de los servidores del sistema Tuxedo. Menor trabajo de CPU en los servidores Tuxedo. Los componentes involucrados en este proceso son los siguientes: Página 10 de 34

12 Workstation cliente (WC): un proceso instalado en la máquina que funciona como cliente ATMI. Workstation Listener (WSL): proceso que corre en un servidor Tuxedo, y acepta conexiones de los WC y asigna conexiones a los WSH, los cuales también corren en el servidor. El WSL maneja un pool de procesos WSH, los cuales activa según la demanda. Worsktation Handler (WSH): proceso que maneja las comunicaciones entre un WC y el servidor de aplicaciones. Pueden manejar múltiples clientes. Componentes CORBA Como alternativa a ATMI, Tuxedo brinda el modelo de programación CORBA como parte de su tecnología de procesamiento de transacciones. Combina el modelo ORB con funciones de procesamiento online de transacciones (OLTP) para crear un monitor transaccional de objetos (Object Transaction Monitor, OTM). Los componentes CORBA de Tuxedo utilizan los recursos existentes de la infraestructura Tuxedo con respecto al manejo de transacciones, seguridad, transporte de mensajes, administración del sistema y soporte para bases de datos que cumplan con XA. Los componentes centrales de Tuxedo CORBA son: ORB s Tuxedo IIOP Listener/Handler Objetos de ambiente y TP Framework Cliente ActiveX ORB s Tuxedo ORB, por Object Request Broker, es una librería que permite a clientes localizar y comunicarse con servidores independientemente de la ubicación del servidor y de las conexiones de red. Interface de Programación La interface de programación CORBA de Tuxedo consiste de un ORB C++ servidor, un ORB C++ cliente, un ORB Java cliente y un software cliente ActiveX del estilo ORB. Estos ORB s tienen soporte transaccional incorporado. EL ORB C++ en el servidor está directamente ligado a los procesos CORBA del servidor, mientras que los distintos ORB s cliente se comunican utilizando el protocolo de CORBA IIOP. Las aplicaciones CORBA de Tuxedo se desarrollan como un conjunto de objetos CORBA, y definiendo luego sus interfaces a través del lenguaje de definición de interfaces (IDL) de la OMG. La comunicación con el resto de los objetos se realiza a través de las ORB s. Tuxedo IIOP Listener/Handler El IIOP Listener/Handler permite a clientes CORBA que no residan en una máquina que tenga una instalación completa de Tuxedo, comunicarse con una aplicación CORBA en el servidor. Las ventajas que se obtienen son las mismas mencionadas cuando se habló del componente cliente (Workstation) de la interface ATMI. La arquitectura de comunicación consiste de los siguiente procesos: Cliente CORBA o ActiveX: proceso que corre en el equipo donde esté instalado cualquiera de los ORB s cliente. IIOP Listener (ISL): proceso que corre en un servidor Tuxedo, y acepta conexiones de los clientes CORBA y asigna conexiones a los ISH, los cuales también corren en el servidor. El ISL maneja un pool de procesos ISH, los cuales activa según la demanda. IIOP Handler (ISH): proceso que maneja las comunicaciones entre un cliente CORBA y el servidor de aplicaciones. Pueden manejar múltiples clientes. Página 11 de 34

13 Objetos de ambiente y TP Framework Tuxedo brinda una serie de objetos CORBA para ayudar a los clientes. Estos objetos facilitan la tarea de loguearse al ambiente CORBA, invocar objetos CORBA, y comenzar y terminar transacciones. Los objetos para aplicaciones cliente son los siguientes: Objeto Bootstrap: este objeto facilita la conexión de un cliente con el servidor de aplicaciones. También brinda referencias a objetos comunes que un cliente utilza. Objeto CORBA OTS TransactionCurrent: este objeto coordina todo lo referente a transacciones. Objeto SecurityCurrent: este objeto obtiene las credenciales de seguridad del cliente del servicio de seguridad, y registra estos certificados al ISH, el cual los utiliza para permitir o denegar permisos. El TP Framework es un modelo de programación que ayuda a los desarrolladores de aplicaciones con las complejidades de las interfaces CORBA. Este modelo provee de una serie de funciones que son requeridas en una aplicación CORBA estándar. El desarrollador es responsable únicamente de escribir la lógica de negocios de la aplicación y de sobrescribir acciones que provee el TP Framework. Cliente ActiveX El componente cliente ActiveX permite a programas ActiveX interactuar con objetos CORBA de BEA como si fueran componentes ActiveX. BEA incluye herramientas que facilitan el trabajo con estos componentes, pero a partir de la versión 8.1 de Tuxedo este cliente y las herramientas son consideradas obsoletas. Escalabilidad y Performance Tuxedo reacciona de manera dinámica a cambios en la carga de trabajo, ya sea inicializando o terminando servidores (ATMI), o activando y desactivando objetos (CORBA). Realiza un balance de acuerdo a la carga de manera que los servicios u objetos disponibles sean efectivamente utilizados. Tuxedo brinda soporte tanto para un solo cliente y un solo servidor, como para varios miles de cliente y cientos de servidores, sin realizar ningún cambio en el código de la aplicación. De esta manera la performance no se ve alterada por un incremento en la cantidad de clientes o servidores. Soporte de plataformas, lenguajes y modelos de programación El sistema Tuxedo ha sido portado a diferentes plataformas tanto para el cliente como para el servidor. Los sistemas cliente soportados son: Windows 2000, XP y 98, y la mayoría de los sistemas workstations de Unix. Con respecto a los servidores, las plataformas soportadas son las siguientes: Windows 2000 Server, Compaq Tru64 Unix, HP-UX, IBM AIX, Red Hat Linux y Solaris. El sistema soporta dos modelos de programación y cinco lenguajes. Los modelos soportados son ATMI y CORBA, de los cuales se ha hablado previamente. Los lenguajes de programación soportados son los siguientes: Página 12 de 34

14 C y COBOL, soportados para aplicaciones ATMI cliente y servidor. C++, soportado para aplicaciones ATMI cliente y aplicaciones CORBA C++ tanto cliente como servidor. Java, soportado para aplicaciones cliente CORBA y Jolt (*). Visual Basic, soportado para aplicaciones ATMI cliente y aplicaciones CORBA cliente que incluyan ActiveX. (*) BEA Jolt es una librería de clases Java (accesible vía una API) que permite conectividad con servicios ATMI vía internet. Esto puede realizarse tanto desarrollando clientes Java remotos (applets o aplicaciones) como instalando representantes Jolt en servidores web para que clientes web puedan acceder a los servicios ATMI. Seguridad BEA Tuxedo incluye autenticación, autorización y encriptación para asegurar la privacidad de los datos en la comunicación a través de una red. Se soportan dos niveles de encriptación: Encriptación a nivel de red, utilizando el protocolo propietario LLE (Link-Level Encryption). Encriptación a nivel de aplicación, utilizando el protocolo SSL y encriptación basada en clave pública. El protocolo LLE es utilizado en la comunicación entre clientes ATMI y Jolt, y el servidor Tuxedo, y entre servidores Tuxedo. El protocolo SSL es utilizado básicamente en la comunicación entre clientes CORBA y ActiveX y el servidor Tuxedo. Herramientas de administración Existen varias opciones para administrar un sistema Tuxedo. Estas son: consola de administración, línea de comandos y MIB API. La consola de administración es una interfaz gráfica que permite realizar la mayoría de las tareas de administración y configuración de las aplicaciones. Está implementada como un conjunto de applets de Java, lo cual permite ejecutarla desde cualquier plataforma que soporte un browser que pueda correr applets de Java. Esta herramienta tiene como limitación que no ha sido actualizada para soportar nuevas características que han sido introducidas luego de la versión 7.1. La línea de comandos provee la mayoría de la funcionalidad necesaria para la modificación dinámica de las aplicaciones y de la configuración de un dominio BEA Tuxedo. La MIB API es una interfaz de programación que permite acceder y manejar la información de la MIB (Management Information Base, elemento central donde se maneja toda la información de configuración del sistema Tuxedo). Esta interfaz brinda un control total de la configuración de las aplicaciones, como también control en situaciones de fallas. A través de la API de MIB es la única forma de manejar cualquiera de las posibles fallas que puedan ocurrir. Página 13 de 34

15 BEA Tuxedo brinda un agente SNMP (por Simple Network Management Protocol) que permite a sistema de administración compatibles con SNMP administrar un sistema Tuxedo utilizando este protocolo. Además de realizar tareas de administración, estas herramientas son utilizadas para aislar errores y realizar tareas de recuperación cuando ocurren fallas en una aplicación. BEA Tuxedo puede recuperarse automáticamente de varios tipos de fallos, sin embargo los fallos más serios requieren la intervención de una administrador para determinar la falla. Estándares soportados BEA Tuxedo cumple con los estándares de X/Open del Open Group. Incluye soporte para el estándar XA para el procesamiento two-phase commit, la API ATMI, y el estándar para la internacionalización del lenguaje XPG (X/Open Portability Guide). Como se mencionó anteriormente implementa el modelo DTP. También soporta la especificación CORBA para el desarrollo de aplicaciones distribuidas. Otros estándares soportados son: LDAP protocolo para el acceso a directorios de información. Certificados digitales X.509. Public-Key Cryptography Standard 7 (PKCS-7) uno de los estándares de clave pública desarrollado por RSA. Acceso web a los servicios de aplicación de BEA Tuxedo Por acceso web entendemos tener disponibles servicios de aplicación a clientes web a través de un servidor de aplicaciones web. El procedimiento general es el siguiente: en el servidor de aplicaciones web se encuentra una aplicación la cual se comunica con los clientes a través del protocolo HTTP. Por otro lado, utilizando un gateway Tuxedo, la aplicación en el servidor de aplicaciones web puede acceder a los servicios ATMI o CORBA del servidor Tuxedo. Existen tres mecanismos para este acceso: A través del Workstation Client: este caso el servidor de aplicaciones C/C++ utiliza un Workstation Client instalado en el servidor para comunicarse con servicios ATMI del servidor Tuxedo. A través de BEA Jolt: este mecanismo ofrece dos posibles servidores, cualquier servidor de aplicaciones Java o Microsoft Internet Information Server. En el primer caso, la aplicación es un HTTP servlet que permite conectarse con Tuxedo para acceder a servicios ATMI, mientras que en el segundo caso existe una ASP de Jolt que permite conectarse con Tuxedo para acceder servicios ATMI, de manera que los clientes Web utilizan estos servicios a través de la ASP. En ambos casos es necesarios instalar paquetes de la API Jolt en el servidor. Página 14 de 34

16 Utilizando el servidor de aplicaciones de BEA WebLogic: en este caso la aplicación residente en el servidor de WebLogic puede acceder tanto a servicios ATMI como CORBA a través de gateways especiales para cada caso. Acceso a los servicios de aplicación de Tuxedo a través de Web Services En la actualidad se está trabajando para exponer servicios ATMI y CORBA de Tuxedo como Web Services utilizando el servidor de aplicaciones WebLogic. El mecanismo de comunicación sería de la siguiente manera: cualquier aplicación cliente, Java o no, accede a los servicios de Tuxedo expuestos como Web Services construyendo un mensaje SOAP y enviándolo vía HTTP al servidor WebLogic. Este llama al servicio Tuxedo a través del WebLogic Tuxedo Connector (WTC), empaqueta la respuesta en un mensaje SOAP y la envía vía HTTP al cliente que realizó el pedido. En la figura se aprecian los componentes principales de la propuesta de BEA Para lograr esta funcionalidad se deben brindar las siguientes características: Proveer del ambiente de web services y componentes Java para la creación de interfaces de web services para los servicios de Tuxedo Generar los WSDL que describa las interfaces de los componentes Java. Publicitar los WSDL a través de registros UDDI. Automáticamente mapear y rutear pedidos SOAP de clientes a los apropiados servicios Tuxedo a través del gateway WTC. Rutear respuestas de servicios Tuxedo a los clientes correspondientes. III. MTS (Microsoft Transaction Server) El MTS es un sistema de proceso transaccional basado en componentes para el desarrollo de aplicaciones sobre Internet e Intranet, escalables, robustas y de alta performance. Utilizando el MTS el desarrollo de aplicaciones es más simple puesto que desliga al programador de aspectos que antes debían ser contemplados y programados por el. El objetivo del MTS es facilitar el desarrollo y gestión de componentes que llevan a cabo trabajos en el ámbito de transacciones. MTS es parte de Windows DNA, un framework para construcción de componentes basado en la arquitectura de tres capas. Es una estrategia para desarrollar aplicaciones usando tecnologías Microsoft. Las principales tecnologías y productos provistos para este modelo son COM, MTS, UDA, ASP, DHTML, MSMQ, y COMTI [MS1] [GRO1]. Página 15 de 34

17 Un poco de historia... MTS aparece en la Conferencia de desarrolladores en San Diego a principios del año 1997 como un servidor transaccional multi-threaded basado en RPC. Es una extensión al COM que facilita la creación y el uso de componentes de software en cualquier lenguaje [HPD1]. Propósito del MTS MTS fue creado para atacar dos problemas principales que existían en la arquitectura de tres capas: 1. La inhabilidad de los objetos para escalar. 2. La inhabilidad de los objetos para unirse a otros objetas en transacciones atómicas. MTS extiende el soporte transaccional a la capa de Información, y permite enlistar varios componentes en únicas transacciones. Para proveer escalabilidad en los componentes provee servicios para el manejo de múltiples usuarios, escalamiento de recursos, y otros factores relativos. MTS actúa como un ORB (Object request broker), o sea un intermediario entre la aplicación y las bases de datos, administrando la creación y la asignación de objetos e hilos de ejecución. MTS provee transacciones anidadas [SRA1] [MS3]. Características Las aplicaciones están compuestas por colecciones de componentes ActiveX que proveen la lógica de las reglas de negocio. Instalando estos componentes en el ambiente MTS hace posible que automáticamente se permite la concurrencia de varios clientes en un modo transaccional de ser necesario [DOC1]. MTS puede manejar transacciones entre objetos bajo MS Windows y otros entornos como UNIX. Los componentes que se instalan en MTS son componentes COM, compilados como DLL s. MTS es compatible con bases de datos relacionales como MS SQL, Oracle, y Sysbase. Cuando un componente está controlado durante su ejecución por MTS todas sus operaciones son susceptibles de enmarcarse en transacciones. MTS se ocupa de resolver todos los problemas de concurrencia, en memoria, en lógica de programa y en gestión de recursos [MS2] [TPC1]. El modelo de operaciones en MTS El objetivo es crear una aplicación que se ubique en un servidor (o varios colaborando entre ellos) y que sea accedida por clientes que van a consultar, actualizar o gestionar los datos que conforman el estado de una aplicación. Las operaciones sobre el estado de la aplicación, la lógica de negocio, van a implementarse con componentes COM cuyos aspectos transaccionales van a ser controlados y gestionados por el MTS [ISD1]. Arquitectura de MTS Componentes ActiveX, implementan la lógica de la aplicación. Página 16 de 34

18 El Transaction Server Executive, que provee los servicios en tiempo de ejecución utilizados por los componentes de la aplicación. Procesos de servidor, que proveen el ambiente de procesos para los componentes de la aplicación. Dispensadores de Recursos, que manejan la información utilizada por los componentes en los procesos. El Microsoft Distributed Transaction Coordinator (DTC), que permite transacciones coordinadas entre múltiples administradores de recursos, dispensadores de recursos, y componente de aplicación. Los componentes MTS Cada uno de los componentes de la aplicación, que en principio van a ser un componente COM cualquiera, se convierten en un componente MTS. Un componente MTS es un componente COM constituido como una DLL, y que se ejecuta en el entorno de Transaction Server. Del mismo modo que una instancia de un componente COM es un objeto COM, toda instancia de un componente MTS es un objeto MTS. Cuando creamos un ejemplar de un componente MTS el servidor crea automáticamente un objeto asociado de contexto (Context Object) que contiene información sobre quién originó la creación del objeto y cómo se está ejecutando, principalmente desde el punto de vista de las transacciones en las que el objeto está inmerso. Cada uno de estos objetos será accedido por los clientes, y él a su vez realizará solicitudes a otros componentes o a los recursos (esencialmente datos) que desee manejar. Actividad Transaccional MTS actúa como un TP-Monitor (monitor de proceso transaccional). MTS crea, ejecuta, y administra las aplicaciones de proceso transaccional, y se asegura de que todos los requerimientos para esa transacción se cumplan. El TP-Monitor del MTS esta construido sobre el estándar de X/Open DTP model. En el ambiente MTS, las aplicaciones usan el Microsoft Distributed Transaction Coordinator (DTC transaction manager) para coordinar las transacciones. El MS DTC es un servicio de Windows que es responsable de asegurarse que todas las entidades que forman parte de la transacción sean notificadas acerca del resultado de la misma. El mismo coordina las transacciones que abarcan múltiples manejadores de recursos. Cada servidor en un sistema distribuido tiene su administrador de transacciones, MS DTC utiliza el protocolo transaccional OLE Página 17 de 34

19 (en lugar del protocolo X/Open) para comunicarse con otros administradores de transacciones. El administrador de transacciones es el encargado de que las características ACID se cumplan. DTC implementa el protocolo two-phase commit, y soporta administradores de recursos que implementen transacciones OLE, X/Open, protocolos XA, y LU 6.2 Sync Level 2 [GSR1]. Dispensadores de Recursos Los dispensadores de recursos son otra parte del MTS. Estos dispensadores manejan, entre otras cosas, las conexiones a las bases de datos. Tienen dos interfaces, API s para las aplicaciones, y otra para comunicarse con el administrador de dispensador de recursos del MTS (DispMan). DispMan provee un pooling de recursos para los dispensadores y se asegura que los recursos provistos por el dispensador de recursos sean enlistados de manera correcta en las transacciones. Los recursos de los que hablamos son básicamente los datos, que se ubican en uno o varios servidores, como por ejemplo SQL Server. Cada uno de estos datos, que conforman el estado de nuestra aplicación, es controlado por un gestor de recursos (Resource Manager). SQL Server es un ejemplo de gestor de recursos que puede atender a transacciones distribuidas. El MTS provee dos dispensadores de recursos que son visibles para los desarrolladores. Uno de ellos es el administrador para ODBC, que es un dispensador de recursos para conexiones de base de datos ODBC. El otro es el Shared Property Manager, que es usado para datos compartidos. Los gestores de recursos son consultados y tomados bajo su ámbito de acción por MTS para asegurar que las transacciones que operan sobre los citados datos son llevadas a cabo correctamente. Los dispensadores de recursos (Resource Dispenser) son administrados por el Administrador de Recursos (Manager Dispenser), que mantiene la información para cada tipo de recurso. Los componentes MTS no acceden directamente a los gestores de recursos, sino que lo hacen a través de un módulo intermedio (el dispensador de recursos Resource Dispenser) que permite la independencia de la llamada a los gestores de recursos, con lo que diferentes componentes podrán llamar a diferentes gestores de recursos sin variar significativamente la tarea de programación. Por ejemplo, si SQL Server es un gestor de recursos, ODBC es un dispensador para él. Activación Just-in-Time Cuando se trabaja con componentes estándares, una aplicación cliente que crea una instancia de un componente la va a mantener abierta durante todo el proceso de trabajo con el componente. Esto acarrea que los recursos que utiliza el componente van a mantenerse ocupados inclusive durante el tiempo en el que el mismo este ocioso. Cuando MTS administra los objetos, una llamada por parte del cliente para crear una instancia de un componente no necesariamente asigna los recursos de forma inmediata. MTS va a crear una instancia de un componente solo cuando sea necesario, dando privilegio a aquellos componentes que están actualmente atendiendo a otras solicitudes de otros clientes. Esto implica que los componentes son cargados y descargados muchas veces durante el tiempo en el cual la aplicación cliente presuntamente tenga el componente abierto. Esto sirve para engañar a clientes como el IIS que le hace creer que Página 18 de 34

20 el objeto que el necesitaba fue creado, cuando en realidad la creación se efectúa cuando un método es invocado. MTS agrega dos fases al paradigma tradicional de programación que son la activación y desactivación. La secuencia de eventos para una clase de VB por ejemplo, que haya sido creada bajo el contexto del MTS sería: creación, activación, desactivación, y destrucción. Cuando un cliente crea un objeto, MTS crea el objeto pero no lo activa hasta que el cliente hace un llamado al primer método del objeto [MS4]. Pooling de Recursos Los componentes utilizan más recursos que memoria. Para que un componente haga su trabajo va a precisar de recursos tales como hilos de ejecución, o conexiones a bases de datos. Estos recursos pueden ser muy costosos en términos de recursos del sistema. Por ejemplo, cuando una aplicación cliente o componente intenta obtener datos de un servidor de base de datos como el MS SQL Server, debe realizar esto a través de una conexión a una base de datos. Puesto que las conexiones a las bases de datos insumen mucha memoria en el servidor de SQL, el número de conexiones esta restringido por el administrador del Server. Algo que se suele hacer para que la aplicación se mantenga más ágil, es realizar las conexiones a las bases de datos antes y liberarlas cuando todo el proceso haya culminado. Esto implica que el estado de la conexión este ocioso, desperdiciando capacidad que puede ser utilizada por otros usuarios. MTS administra todas las conexiones a la base de datos, así como otros recursos, permitiendo el pooling de conexiones para que sean usadas de forma más eficiente. Seguridad MTS define un modelo de seguridad llamado seguridad de paquetes, que permite asignar una identidad de usuario a un paquete. Un paquete esta compuesto por componentes. Esto hace que los paquetes se comporten como usuarios virtuales. Estos paquetes pueden ser considerados como grupos de usuarios. Las identidades de los paquetes les dan privilegios para realizar acciones sobre los servidores de base de datos. Además, a cada grupo de usuarios definido en el servidor de dominio, se les definen accesos a esos paquetes. La seguridad del MTS se administra en la capa de paquetes. Esto hace más fácil la tarea del administrador puesto que la seguridad a nivel de los recursos (bases de datos), se administra otorgando accesos a los paquetes [BSE1 [GSR1]. Lenguajes y modelos de programación Los componentes de aplicación del MTS son ActiveX in-process servers (DLLs). Estos componentes se pueden crear e implementar con Microsoft Visual Basic, Visual C++, Visual J++, o cualquier herramienta de desarrollo ActiveX o compatible que se base en el modelo COM. Component Object Model (COM) El desarrollo de aplicaciones se está orientando a un escenario, Internet, en el que los programas creados deben estar preparados para poder ejecutarse en máquinas desconocidas, con requerimientos y sistemas operativos también desconocidos. En este Página 19 de 34