sumario Nº 176, julio-agosto 2005, año XXXI

Transcripción

1 Novática, revista fundada en 1975 y decana de la prensa informática española, es el órgano oficial de expresión y formación continua de ATI (Asociación de Técnicos de Informática). Novática edita también UPGRADE, revista digital de CEPIS (Council of European Professional Informatics Societies), en lengua inglesa, y es miembro fundador de UPENET (UP UPGRADE European NETwork) < < ATI es miembro fundador de CEPIS (Council of European Professional Informatics Societies) y es representante de España en IFIP (International Federation for Information Processing); tiene un acuerdo de colaboración con ACM (Association for Computing Machinery), así como acuerdos de vinculación o colaboración con AdaSpain, AI2 y ASTIC. Consejo Editorial Antoni Carbonell Nogueras, Juan ManuelCueva Lovelle, Juan Antonio Esteban Iriarte,Francisco López Crespo, Celestino Martín Alonso, Josep Molas i Bertrán, Olga Pallás Codina, Fernando Piera Gómez (Presidente del Consejo), Ramón Puigjaner Trepat, Miquel Sàrries Griñó, Asunción Yturbe Herranz Coordinación Editorial Rafael Fernández Calvo <rfcalvo@ati.es> Composición y autoedición Jorge Llácer Gil de Ramales Traducciones Grupo de Lengua e Informática de ATI < Administración Tomás Brunete, María José Fernández, Enric Camarero, Felicidad López Secciones Técnicas: Coordinadores Administración Pública electrónica Gumersindo García Arribas, Francisco López Crespo (MAP) <gumersindo.garcia@map.es>, <flc@ati.es> Arquitecturas Enrique F. Torres Moreno (Universidad de Zaragoza) <enrique.torres@unizar.es> Jordi Tubella Morgadas (DAC-UPC) <jordi@ac.upc.es> Auditoría SITIC Marina Touriño Troitiño, Manuel Palao García-Suelto (ASIA) <marinatourino@marinatourino.com>, <manuel@palao.com> Bases de datos Coral Calero Muñoz, Mario G. Piattini Velthuis (Escuela Superior de Informática, UCLM) <Coral.Calero@uclm.es>, <mpiattin@inf-cr.uclm.es> Derecho y tecnologías Isabel Hernando Collazos (Fac. Derecho de Donostia, UPV)<ihernando@legaltek.net> Elena Davara Fernández de Marcos (Davara & Davara) <edavara@davara.com> Enseñanza Universitaría de la Informática Joaquín Ezpeleta Mateo (CPS-UZAR) <ezpeleta@posta.unizar.es> Cristóbal Pareja Flores (DSIP-UCM) <cpareja@sip.ucm.es> Gestión del Conocimiento Joan Baiget Solé (Cap Gemini Ernst & Young) <joan.baiget@ati.es> Informática y Filosofía Josep Corco Juvinyà (UIC) <jcorco@unica.edu> Esperanza Marcos Martínez (ESCET-URJC) <cuca@escet.urjc.es> Informática Gráfica Miguel Chover Sellés (Universitat Jaume I de Castellón) <chover@lsi.uji.es> Roberto Vivó Hernando (Eurographics, sección española) <rvivo@dsic.upv.es> Ingeniería del Software Javier Dolado Cosín (DLSI-UPV) <dolado@si.ehu.es> Luis Fernández Sanz (PRIS-EI-UEM) <lufern@dpris.esi.uem.es> Inteligencia Artificial Federico Barber Sanchís, Vicente Botti Navarro (DSIC-UPV) <{vbotti, fbarber}@dsic.upv.es> Interacción Persona-Computador Julio Abascal González (FI-UPV) <julio@si.ehu.es> Jesús Lorés Vidal (Univ. de Lleida) <jesus@eup.udl.es> Internet Alonso Álvarez García (TID) <alonso@ati.es> Llorenç Pagés Casas (Indra) <pages@ati.es> Lengua e Informática M. del Carmen Ugarte García (IBM) <cugarte@ati.es> Lenguajes informáticos Andrés Marín López (Univ. Carlos III) <amarin@it.uc3m.es> J. Ángel Velázquez Itúrbide (ESCET-URJC) <a.velazquez@escet.urjc.es> Libertades e Informática Alfonso Escolano (FIR-Univ. de La Laguna) <aescolan@ull.es> Lingüística computacional Xavier Gómez Guinovart (Univ. de Vigo) <xgg@uvigo.es> Manuel Palomar (Univ. de Alicante) <mpalomar@dlsi.ua.es> Mundo estudiantil Adolfo Vázquez Rodríguez (Rama de Estudiantes del IEEE-UCM) <a.vazquez@ieee.org> Profesión informática Rafael Fernández Calvo (ATI) <rfcalvo@ati.es> Miquel Sàrries Griñó (Ayto. de Barcelona) <msarries@ati.es> Redes y servicios telemáticos Luis Guijarro Coloma (DCOM-UPV) <lguijar@dcom.upv.es> Josep Solé Pareta (DAC-UPC) <pareta@ac.upc.es> Seguridad Javier Areitio Bertolín (Univ. de Deusto) <jareitio@eside.deusto.es> Javier López Muñoz (ETSI Informática-UMA) <jlm@lcc.uma.es> Sistemas de Tiempo Real Alejandro Alonso Muñoz, Juan Antonio de la Puente Alfaro (DIT-UPM) <{aalonso,jpuente}@dit.upm.es> Software Libre Jesús M. González Barahona, Pedro de las Heras Quirós (GSYC-URJC) <{jgb,pheras}@gsyc.escet.urjc.es> Tecnología de Objetos Jesus García Molina (DIS-UM) <jmolina@correo.um.es> Gustavo Rossi (LIFIA-UNLP, Argentina) <gustavo@sol.info.unlp.edu.ar> Tecnologías para la Educación Juan Manuel Dodero Beardo (UC3M) <dodero@inf.uc3m.es> Tecnologías y Empresa Pablo Hernández Medrano (Bluemat) <pablohm@bluemat.biz> TIC para la Sanidad Valentín Masero Vargas (DI-UNEX) <vmasero@unex.es> TIC y Turismo Andrés Aguayo Maldonado, Antonio Guevara Plaza (Univ. de Málaga) <{aguayo, guevara}@lcc.uma.es> Las opiniones expresadas por los autores son responsabilidad exclusiva de losmismos. Novática permite la reproducción de todos los artículos, a menos que lo impida la modalidad de o copyright elegida por el autor, debiéndose en todo caso citar su procedencia y enviar a Novática un ejemplar de la publicación. Coordinación Editorial, Redacción Central y Redacción ATI Madrid Padilla 66, 3º, dcha., Madrid Tlfn ; fax <novatica@ati.es> Composición, Edición y Redacción ATI Valencia Av. del Reino de Valencia 23, Valencia Tlfn./fax <secreval@ati.es> Administración y Redacción ATI Cataluña Ciudad de Granada 131, Barcelona Tlfn ; fax <secregen@ati.es> Redacción ATI Andalucía Isaac Newton, s/n, Ed. Sadiel, Isla Cartuja Sevilla, Tlfn./fax <secreand@ati.es> Redacción ATI Aragón Lagasca 9, 3-B, Zaragoza. Tlfn./fax <secreara@ati.es> Redacción ATI Asturias-Cantabria <gp-astucant@ati.es> Redacción ATI Castilla-La Mancha <gp-clmancha@ati.es> Redacción ATI Galicia Recinto Ferial s/n, Silleda (Pontevedra) Tlfn ; fax <secregal@ati.es> Suscripción y Ventas < o en ATI Cataluña o ATI Madrid Publicidad Padilla 66, 3º, dcha., Madrid Tlnf ; fax <novatica.publicidad@ati.es> Imprenta Derra S.A., Juan de Austria 66, Barcelona. Depósito legal: B ISSN: ; CODEN NOVAEC Portada: Antonio Crespo Foix / ATI 2005 Diseño: Fernando Agresta / ATI 2005 Nº 176, julio-agosto 2005, año XXXI sumario en resumen Normalizando la seguridad... y buscando en la Intranet de Novática > 02 Rafael Fernández Calvo noticias de IFIP Informe de ATI sobre IFIP Actividades > 03 Ramón Puigjaner Trepat monografía Estandarización y Seguridad TIC (En colaboración con UPGRADE) Editores invitados: Paloma García López, Stefanos Gritzalis, Javier López Muñoz Presentación. La normalización en Seguridad TIC: una tarea colectiva internacional y multisectorial > 05 Paloma García López, Stefanos Gritzalis, Javier López Muñoz Dónde nacen las normas voluntarias y las recomendaciones relativas a la seguridad de la información? > 07 Paloma García López CEN/ISSS y su contribución a la estandarización europea en Seguridad de las Tecnologías de la Información > 15 Luc Van den Berghe Medidas y métricas de seguridad para los Sistemas de Información > 19 José A. Mañas Argemí Auditoría de Seguridad de las TI desde la perspectiva de la normalización > 23 Marina Touriño Troitiño Legislación, estándares y recomendaciones relativos a la firma electrónica > 27 Josep Lluís Ferrer Gomila, Apol lònia Martínez Nadal El estándar X.509 para gestión de privilegios > 32 David Chadwick Estándares de seguridad de las TIC para aplicaciones en el ámbito sanitario > 38 Spyros Kokolakis, Costas Lambrinoudakis Bases de datos Calidad de Datos en aplicaciones web: un "estado del arte" > 45 Mª Angélica Caro Gutiérrez, Coral Calero Muñoz, Ismael Caballero Muñoz-Reja, Mario Piattini Velthuis Informática gráfica Generación de penumbras con hardware gráfico > 49 Pere-Pau Vázquez Alcocer, Dani Susín Acebo Lenguajes informáticos Una arquitectura software multicapa para la integración de sistemas > 54 Rafael Pastor Pastor, Antonio Guevara Plaza, José Luis Caro Herrero, Andrés Aguayo Maldonado Redes y servicios telemáticos Ping Trunking: un mecanismo de control de congestión para tráfico agregado basado en Vegas > 61 Sergio Herrería Alonso, Manuel Fernández Veiga, Miguel Rodríguez Pérez, Andrés Suárez González, Cándido López García Referencias autorizadas > 67 sociedad de la información Programar es crear La casa más grande (CUPCAM 2005, problema B, enunciado) > 74 Manuel Abellanas Oar Dominó Solitario (CUPCAM 2005, problema A, solución) > 75 Antonio Fernández Anta asuntos interiores Coordinación editorial / Programación de Novática > 76 Normas de publicación para autores / Socios Institucionales > 77 Monografía del próximo número: "Computación ubicua"

2 Lenguajes informáticos Rafael Pastor Pastor, Antonio Guevara Plaza, José Luis Caro Herrero, Andrés Aguayo Maldonado Sistemas de Información Cooperativos de la Universidad de Málaga (SICUMA), ETSI Informática, Universidad de Málaga <{rpastor, guevara, jlcaro, 1. Introducción Actualmente existe una necesidad creciente en muchas empresas de integrar sus aplicaciones entre sí no sólo a nivel de información sino, también, a nivel de servicios. En muchos de estos casos, la integración de aplicaciones de las empresas, EAI (Enterprise Application Integration), no puede llevarse a cabo mediante la estrategia de "destruir y reemplazar" los sistemas existentes (legacy systems). Es por ello que se impone una estrategia integradora que permita mantener los sistemas ya implantados en la empresa a la misma vez que mediante nuevas tecnologías proyectamos sus datos hacia el mundo web o hacia otra aplicación para ofrecer o aprovechar servicios que utilicen estos datos. Con esta integración se persiguen objetivos esenciales como: Integración B2B (Business to Business) Soporte multidispositivo para acceso a información y servicios Implantación y mantenimiento sencillos de nuevos servicios En este entorno, las tecnologías XML (extensible Markup Language) se están imponiendo en la industria a través de estándares que permiten dar mucha versatilidad a los sistemas antiguos de las empresas y proyectarlos hacia el mundo de los servicios web sin que dichos sistemas tengan que ser reemplazados. Por otro lado, la emergencia de las arquitec- turas multicapa como arquitecturas software para definir plataformas de servicios en la Web permite desarrollar, implantar y mantener de forma fácil nuevas aplicaciones y servicios sobre los sistemas existentes. También nos proporcionan un modo de adaptar dichos sistemas al mundo web de una forma sencilla y escalable permitiendo la integración entre servicios Web y los SGBDs (Sistema de Gestión de Bases de Datos) de las empresas. Asimismo, el uso de estas arquitecturas, junto con las tecnologías XML, facilita la separación entre los datos y la presentación de los mismos, lo cual es un requisito fundamental para el soporte multidispositivo. La integración B2B es muy importante para muchas empresas, sobre todo para aquellas cuyas transacciones más importantes se dan Una arquitectura softwaremulticapa para la integración de sistemas Resumen: cada vez más, las empresas se están integrando en el mundo web a nivel de información y servicios. Las tecnologías XML (extensible Markup Language) aplicadas conjuntamente con arquitecturas software multicapa nos permiten realizar la integración con los sistemas existentes en estas empresas construyendo aplicaciones escalables y fácilmente mantenibles al mismo tiempo que conseguimos acceso multidispositivo a la información, gracias, principalmente, a la separación de los datos de la presentación de los mismos, característica que ofrecen tanto el empleo de XML como el uso de una arquitectura software multicapa. El artículo finaliza presentando un caso práctico de integración de sistemas usando la arquitectura descrita. Palabras clave: acceso multidispositivo, arquitecturas multicapa, B2B, J2EE, middleware, mundo web, XML. con otras organizaciones. Las tecnologías XML proporcionan una forma eficiente de conseguirla, utilizándose como formato de intercambio de datos estándar entre negocios, sin eliminar las ventajas del uso de otras tecnologías, por ejemplo, EDI (Electronic Data Interchange). De esta manera se permite también combinar flexibilidad en la presentación y transformación de los datos mediante, por ejemplo, XSL (extensible Stylesheet Language), para automatizar procesos en organizaciones que pueden así, de forma individual, desarrollar el modo más adecuado de presentar los documentos intercambiados según el dispositivo de acceso. Mediante SOAP (Simple Object Access Protocol) [6], protocolo cuya parte fundamental es el uso de XML, tenemos una forma automatizada y en tiempo real de realizar intercambio de información entre organizaciones y de implantar y mantener nuevos servicios de forma eficiente y sencilla [1]. 2. Solución multicapa La característica fundamental de una arquitectura software multicapa es el hecho de que nos permite desarrollar aplicaciones y componentes software distribuyendo la complejidad de los mismos entre cada una de las capas que, de manera independiente, tratan de resolver un punto de vista del problema. Esta división nos permite dimensionar cada capa de forma independiente en función de las necesidades del problema, distribuir nuestras aplicaciones de forma sencilla y escalable, prácticamente transparente a la implementación, y conseguir una alta disponibilidad y rendimiento de las mismas. Todas estas características son cada vez más importantes para el soporte de procesos de negocios sobre todo en sistemas utilizados a través de la Web. El uso de arquitecturas software dividas en tres capas está bastante extendido. De forma concisa podemos ver una capa de datos -- constituida por los servidores de bases de datos y sistemas de información de la empresa--, una capa de lógica de negocio -- constituida por 'aplicaciones' que realizan las tareas necesarias por los procesos de la empresa, entre los cuales puede estar el acceso a los datos--, y una capa de presentación, que se ocupa de mostrar el resultado de la lógica sobre los datos de forma adecuada. Las aplicaciones que se diseñen para arquitecturas como éstas deben tener, como premisa fundamental, la independencia entre todas sus capas, de forma que consigan ser aplicaciones escalables. Como ejemplo de plataformas software sobre las que diseñar e implementar aplicaciones multicapa podemos mencionar J2EE (Java 2 Enterprise Edition de Sun) y DNA (Distributed Network Architecture de Microsoft) así como la evolución de está última (.NET). Tomaremos como referencia a lo largo de este artículo la primera. Una de las características más importantes de XML es la separación que realiza entre los datos y la presentación, elemento que, como hemos mencionado, es una característica esencial en una arquitectura software multicapa. XML nos ayudará, pues, a realizar esta separación en aplicaciones diseñadas para arquitecturas multicapas, pues mediante el uso de XML podemos hacer que la capa de presentación sea lo más independiente posible de la de negocio y ésta, a su vez, lo sea de la de datos. Será clave que la obtención de servicios, el despliegue de nuevas aplicaciones, la interfaz de usuario y, en general, el flujo de información desde la capa de datos a la de presentación, se pueda 54 novática nº 176 julio-agosto 2005

3 Lenguajes informáticos La integración B2B es muy importante para muchas empresas gestionar de una manera extensible, escalable, estándar e independiente del dispositivo, es decir, con la aplicación de tecnologías XML, las cuales permiten obtener todas estas características y muchas otras. 3. XML en la capa de datos En la capa de datos hay que considerar el modo en que se van a gestionar los datos teniendo en cuenta los sistemas existentes en la empresa. Por un lado, la necesidad de almacenar los datos en XML (de una manera que no afecte bruscamente al rendimiento) viene dada por una serie de ventajas sobre los SGBD tradicionales. Por ejemplo, mientras los SGBD tradicionales pueden resultar idóneos para datos que quepan en filas y columnas, no pueden manejar adecuadamente otros "tipos de datos" de más alto nivel, muy típicos en la Web, como audio, vídeo, documentos complejos, etc. Por otro lado, la no dependencia de un motor específico de base de datos para tratar los datos con XML, hace que este lenguage sea adecuado como medio de integración entre sistemas heterogéneos (SGDBs, sistemas de ficheros indexados, etc.) existentes en la empresa. Uno de los elementos clave para aplicar las tecnologías XML a la integración de los sistemas será la existencia de un repositorio XML que nos permita la gestión tanto de los datos existentes como los nuevos. Por un lado, de la misma manera que hasta ahora se venían tratando y, por otro, proyectándolos al mundo web en formato XML aprovechando así las ventajas que esto conlleva. Este repositorio XML formará parte de la capa de datos de nuestra arquitectura. La manera de construir el repositorio XML variará en gran parte dependiendo del volumen de datos gestionado por los sistemas actuales. En una primera aproximación en el que dichos sistemas fueran inexistentes (obviamente, no se puede hablar de integración), se podría plantear el uso exclusivo de un sistema de bases de datos XML nativo pero éste es un caso poco práctico puesto que en las empresas, al menos actualmente, no suelen usar este tipo de bases de datos sino sistemas de bases de datos convencionales (normalmente relacionales). En el caso más común existirán bases de datos convencionales y una opción podría ser utilizar una aplicación o componente software middleware que realice la transformación de los datos almacenados en el SGBD convencional a XML para su posterior tratamiento por el resto de las capas de la arquitectura. El problema de esta opción es que, normalmente, el software middleware limita el rendimiento y en su forma más básica, una aplicación o componente middleware no acepta consultas expresadas en un lenguaje de consulta XML sino expresadas en el propio LMD (Lenguaje de Manipulación de Datos) del SGBD (normalmente SQL, Structured Query Language), lo cual puede suponer un fuerte obstáculo para el desarrollo de ciertas aplicaciones y para el aprovechamiento de las ventajas que ofrecen los lenguajes de consulta XML. Se puede aprovechar la circunstancia de disponr tanto de un SGBD como de una base de datos XML nativa y esta última ofrece opciones de mapeo de datos con un SGBD (por ejemplo, Tamino, de Software AG, posee esta característica). Sin embargo, debe tenerse en cuenta que esta opción no cubre todos los requisitos deseables: si bien podemos obtener datos en XML del SGBD, introducir datos en XML hacia el SGBD y realizar consultas expresadas en el lenguaje de consulta XML del que dispone la base de datos XML nativa, no podemos, por ejemplo, realizar consultas en el LMD del SGBD para que se nos devuelva el resultado en XML, que puede ser requerido por algún componente de la capa de lógica de negocio. La ampliación a esta opción sería disponer, además del SGBD y la base de datos XML nativa, de una aplicación o componente middleware con funcionalidades como: mapeo/sincronización entre SGBD y BD XML nativa, traducción de consultas en SQL a XQuery, traducción entre distintos lenguajes de consulta XML, conversión entre distintos lenguajes de definición de esquemas XML, etc. (figura 1). 1 Todo esto se traduce en que la capa de datos debe proporcionar, fundamentalmente, una representación estándar de los datos (XML, XMLSchema), un formulación de las consultas mediante lenguajes universales (SQL, XQuery) y un acceso a los datos mediante una vía estándar (por ejemplo, el protocolo http, HyperText Transmission Protocol). 4. XML en la capa de negocio En esta capa implementaremos toda la lógica de negocio de las aplicaciones construidas sobre nuestra arquitectura y la diseñaremos teniendo en cuenta que todas las operaciones de la lógica de negocio, en el caso de una plataforma J2EE, serán accesibles a través de componentes EJBs (Enterprise Java Beans) de sesión, con el objetivo que el cliente sólo tenga que acceder a un componente para hacer uso de la aplicación desde servidores web, aplicaciones Java nativas u otros tipos de interfaz. En muchos casos este componente invocará a EJBs de entidad asociados a objetos de la base de datos. La descripción de la persistencia sobre objetos, los métodos para encontrar el objeto de la base de datos, el despliegue de los componentes en la arquitectura, etc., se definen en formato XML. Figura 1. Uso de un middleware para acceso un SGBD y BD XML nativa. Otra alternativa es que no se utilicen EJBs de entidad y sí EJBs de sesión que invocan procedimientos almacenados, lanzan consultas, realizan inserciones, etc., sobre la novática nº 176 julio-agosto

4 Lenguajes informáticos tratada en un entorno controlado (servidor). Para la parte cliente la lógica siempre debe ser muy básica y lo más estándar posible. De hecho, en las aplicaciones cliente se debería limitar el tipo de lógica a ejecutar, impidiendo de forma tajante características fuera del estándar. Existen otro tipo de consideraciones relativas a la seguridad que también desaconsejan la ejecución de lógica por parte de los clientes. Figura 2. Capa Intermedia (gateway) para mejorar separación entre lógica y datos. base de datos, el repositorio XML o el middleware, para lo que podemos utilizar también XML en una capa intermedia de configuración (formada por documentos XML) para minimizar el mantenimiento del código en la capa de negocio cuando cambia algo en la capa de datos. Estos XML estarán gestionados por un componente cuya misión es generar dichos XML, configurar los posibles cambios a los mismos (backoffice de la aplicación) y servir de pasarela entre otros componentes que van a acceder a la capa de datos (figura 2). Obviamente, al añadir esta nueva capa debemos hacer consideraciones sobre el rendimiento de la aplicación y llegar a un compromiso entre aquello que merece la pena o no flexibilizar a costa de pérdida de eficiencia. A esta pasarela se le pueden añadir las funcionalidades de la aplicación middleware de la capa de datos (figura 3) 3 y, en cualquier caso, considerar que este componente pasarela y los XML que gestiona constituyen una capa intermedia entre la de datos y la de negocios que pretende aislar dichas capas aún más para minimizar las interacciones entre las mismas. Si bien, comparada con esta solución, el uso de EJBs de entidad (en una plataforma J2EE) es más homogéneo y estándar (figura figura 4), 4 esta técnica es más flexible y común para conseguir el objetivo de separación entre las capas de datos y negocio, tanto en una plataforma J2EE como en una plataforma MS.NET. Además, en el primer tipo de plataforma podría plantearse un uso mixto de ambas soluciones. Language; VoiceXML, etc.), páginas generadas dinámicamente por el servidor (JSP, Java Server Pages; ASP, Active Server Page; PHP, Hypertext Preprocessor; etc.), componentes ejecutables (servlets; CGIs, Common Gateway Interface; etc.), componentes multimedia, etc. La segunda consta de todo aquello ejecutado en el navegador o dispositivo utilizado para acceder a la aplicación (PDA, Personal Digital Assistant; Web TV, etc.). En la capa cliente hay parte de lógica implementada principalmente mediante componentes de la parte cliente (applets, componentes ActiveX, etc.) y lenguajes de script (JavaScript, VBScript, etc.). Como norma general se tiende a minimizar este tipo de lógica siempre que esto no represente una saturación en la parte del servidor. El hecho de minimizar esta lógica en el cliente nos libera de la problemática de las incompatibilidades entre distintos clientes ya que la mayor parte de lógica ha sido Centrándonos en una plataforma J2EE, podemos considerar la opción de comunicar la capa de presentación con la capa de negocio mediante un JavaBean que efectúa una función de Proxy y que será el encargado de conservar las referencias remotas al servidor de aplicaciones. Por otro lado, una razón fundamental para la existencia de esta otra capa intermedia es el mantenimiento de las páginas JSP, que siempre es complejo. Este mantenimiento se simplifica mediante el uso de TagLibs [9]. Las clases que implementan los Tags realizan directamente la invocación a los componentes de la capa de negocio o bien a través del JavaBean Proxy (figura 5). Esta solución puede afectar al rendimiento dependiendo de la aplicación, por lo que de nuevo debemos llegar a un compromiso entre el rendimiento y el mantenimiento fácil del sistema. Hay un importante uso de XML a la hora de definir los TagLibs y desplegarlos en el sistema ya que mediante XML construimos los descriptores de TagLibs (ficheros TLD) en los que se guarda información de la versión de TagLibs usada, la versión de JSP, el nombre que tomará la librería de tags y, para cada tag, el nombre de la clase de tag, localización de la clase y descripción del cuerpo del tag. Estos ficheros TLD se despliegan en un recurso del Servidor Web que viene descrito en XML en el fichero (normalmente 5. XML en la capa de presentación Podemos considerar esta capa dividida en una capa Web y una capa cliente. La primera da el acceso a la aplicación y consta de componentes como páginas estáticas (XHTML, extensible Hypertext Markup Language; HTML; WML, Website Meta Figura 3. Uso del middleware para gestionar la capa gateway. 56 novática nº 176 julio-agosto 2005

5 Lenguajes informáticos El uso de arquitecturas software dividas en tres capas está bastante extendido llamado web.xml) que poseen los servidores Web que dan soporte a TagLibs. Tal y como se define en el modelo MVC (Model-View-Controler), usaremos un controlador (servlet) para gestionar el flujo de la aplicación y guardar el estado de la interfaz del usuario y como responsable de recoger las entradas del usuario y decidir cuál de las vistas es la adecuada para mostrarle. Cada página JSP implementa una vista y se limita a recoger ciertos parámetros del controlador, mostrar los contenidos de forma adecuada y proporcionar al usuario enlaces que ejecutan funciones del controlador. En cuanto al acceso multidispositivo, las páginas JSP pueden tener su aplicación en la generación de la correspondiente vista (XHTML, WML, VoiceXML, XHTML Basic, etc.) por sí mismas (multiple pipeline), en combinación con transformaciones XSL (single pipeline) o de forma mixta (combination pipeline). Uno de los puntos básicos para el soporte multidispositivo es el acceso, que --según la arquitectura propuesta-- se realizará teniendo como punto de entrada el servlet controlador, que determinará la respuesta válida para el dispositivo correspondiente mediante la comprobación de la información relativa al agente de usuario (user-agent). Esto nos permitirá distinguir qué dispositivo está Figura 4. Arquitectura propuesta en una plataforma J2EE. realizando la petición al servidor Web (figu- ra 6). 6 Por ejemplo, si en la petición HTTP detectamos text/html, text/xhtml o text/plain sabremos que la petición la ha realizado un navegador y por lo tanto devolveremos HTML, XHTML o texto plano respectivamente. Si detectamos text/wml sabremos que la petición la ha realizado un dispositivo WAP. Si detectamos text/vxml entonces sabremos que se está accediendo a través de un teléfono y lo que el usuario espera es una interacción mediante la voz con el sistema, que deberá poseer un sistema de portal de voz para satisfacer la petición. Figura 5. Capa Intermedia (TagLibs) para mejorar la separación entre lógica y presentación. Precisamente los portales de voz están tomando un auge considerable desde la aparición de propuestas de estándares para lenguajes de aplicaciones de voz basadas en XML, como por ejemplo VoiceXML [10]. Para dar soporte a un portal de voz dentro de nuestra arquitectura se necesitará tener un equipo de telefonía con tarjetas para soporte de primarios y/o líneas analógicas asociadas a uno o varios números de teléfono que recogen las peticiones realizadas vía telefónica (figura 7). Una vez se recibe una petición, existen una serie de procesos software asociados al hardware anterior que realizan tareas de interpretación de los documentos VoiceXML que, mediante sintaxis XML, describen el diálogo entre el usuario y el sistema, las posibles opciones a elegir por parte del usuario, la redirección a otro documento VoiceXML (contenido, por ejemplo, en la base de datos XML nativa) o página JSP (que dinámicamente generará el contenido VoiceXML a partir, por ejemplo, de información de nuestro SGBD). Otro de estos procesos es el TTS Server (Servidor de Texto a Voz) cuya funcionalidad es transformar el texto que se le proporciona a voz que pueda ser escuchada por el usuario. También existen procesos para el control de las gramáticas de cada idioma, que utilizan definiciones del modelo acústico del idioma correspondiente para realizar un buen reconocimiento de las palabras que el usuario pronuncia. Esta característica hace que nuestra arquitectura esté preparada para dar so- novática nº 176 julio-agosto

6 Lenguajes informáticos Figura 6. Capas intermedia, web y cliente. porte a aplicaciones de voz y, así, los usuarios pueden utilizar las aplicaciones vía telefónica. En este sentido, existen arquitecturas comerciales que aplican desde hace tiempo los estándares XML para voz [11]. 6. Tendencias, patrones y modelos en la integración de sistemas Algunos autores [4] plantean, si no arquitecturas, sí modelos para la integración que presentamos, de forma resumida, en los siguientes puntos: Integración a través de datos: usando exclusivamente técnicas de acceso a datos (JDBC, Java DataBase Connectivity) o de intercambio de datos en XML (JAXP, Java API for XML Parsing). Integración de métodos de negocio: Uso de componentes de lógica de negocio (CORBA, Common Object Request Broker Architecture; EJBs; COM; etc.). Integración en la capa de presentación: usando exclusivamente JSPs y servlets para la integración de los datos mostrados en la capa de presentación. Integración B2B: uso de XML desde la capa de datos, XSL aplicado a estos datos para la definición de interfaces y uso de Web Services y tecnologías asociadas (SOAP, Simple Object Access Protocol; UDDI, Universal Description, Discovery and Integration; y WSDL, Web Services Description Language). Nuestra arquitectura no se puede enmarcar dentro de ninguno de los modelos porque en cada parte de la misma se utilizan características de alguno de los modelos planteados. Otros autores [13] han definido patrones a seguir en la integración de sistemas que definen conjuntos de subsistemas predefinidos, relaciones entre los mismos y reglas para la organización de esas relaciones. Estos patrones se aplican a nivel de arquitectura para dar consistencia a las aplicaciones que intervienen en la aplicación y, dentro de una aplicación dada, para cumplir un papel específico dentro de la arquitectura. Como ejemplo se referencian los siguientes patrones de integración: Patrón adaptador: convierte una interfaz de una aplicación existente en la interfaz deseada. Patrón mensajero: describe un método para minimizar las dependencias de comunicación entre las aplicaciones. Patrón fachada: proporciona una interfaz simplificada para minimizar las dependencias entre las aplicaciones clientes y las aplicaciones servidor. Patrón mediador: encapsula la lógica de interacción de la aplicaciones para minimizar las dependencias entre aplicaciones. Patrón automatizador: describe un método para minimizar las dependencias entre la lógica de automatización de procesos y las aplicaciones. Hay partes en la arquitectura propuesta que se pueden identificar con el resultado de aplicar alguno de los patrones anteriores. Por ejemplo, el uso de XSL, servlets y JSPs para generar interfaces multidispositivo mediante las técnicas de multiple pipeline, single pipeline o combination pipeline anteriormente descritas se puede ver como una clara aplicación del patrón adaptador. Por último, una tendencia de integración entre sistemas con interfaces Web bastante interesante es el uso de las tecnologías relacionadas con la Web semántica [2], [3] especialmente indicada cuando estos sistemas web van a quedar abiertos a nuevas integraciones con otros sistemas aún no conocidos. Dotando a los datos de los sistemas de metainformación mediante el uso RDF (Resource Description Framewok) + RDFSchema y disponiendo dicha información en repositorios XML, que pueden ser accesibles vía sindicación, se consigue disponer de los datos de una forma estándar. Luego, puede ser necesaria o no la aplicación de un patrón adaptador para poder disponer de la información como realmente nos interese proporcionarla al middleware que realizaría la integración según el modelo de métodos de negocio. Un ejemplo de la disposición de la información vía sindicación es el uso en portales y blogs de RSS (Really Simple Syndication), especialmente indicado para servir noticias. Esto es solo un ejemplo de lo que las tecnologías relacionadas con la Web semántica Figura 7. Arquitectura genérica para plataforma VoicePortal. 58 novática nº 176 julio-agosto 2005

7 Lenguajes informáticos Las aplicaciones para estas arquitecturas deben tener independencia entre todas sus capas ATTRIBUTES (reserved AS reserved), XMLFOREST ( fselect XMLELEMENT ("week", XMLirstname, lastname AS "owner", contact AS " ") ) FROM weeks <week reserved="true"> <owner>chris Jonhanson</owner> < >cjonhanson@xxxxxxx.com</ > </week> Por otro lado, la empresa trata la información mediante un acceso restringido (sólo lectura) a un ERP (sistema B) de una empresa externa que gestiona la multipropiedad a nivel mundial. Este ERP está basado en un SGBD (Oracle) al que se realizaban las consultas sobre las semanas disponibles por cada apartamento del hotel que deben introducirse con cierta prioridad en el sistema A y que de ninguna manera directa puede integrarse en el mismo. nos pueden proporcionar en lo que se refiere al acceso a datos, pero también se puede profundizar en el uso de estas técnicas aplicadas a la integración de sistemas aún no conocidos usando ontologías para definir términos (datos) de una manera precisa y dotar de significado a los datos que esperan participar en la integración. Aparte de la precisión y diferenciación que se consigue al definir términos con ontologías se obtiene también una ventaja adicional, que es la reutilización de estas codificaciones para definir datos haciendo el conocimiento reutilizable. Para ello la W3C (World Wide Web Consortium) ha creado OWL (Ontology Web Language) como el lenguaje de definición de ontologías en la Web [5]. 7. Un caso práctico Esta arquitectura ha sido llevada a la práctica en una empresa de gestión hotelera y multipropiedad (time-sharing). En ella se gestiona la información para los hoteles propios mediante un PMS (Property Management System), al que llamaremos sistema A y que hace las veces de ERP (Enterprise Resource Planning) para hotel, basado en ficheros indexados (COBOL). La integración del sistema A y B se llevó a cabo a través de la implementación de un software middleware con varios componentes (EJBs). Uno de ellos realizaba el acceso al sistema B y comunicaba la información a otro componente vía SOAP. Este segundo componente accedía a un recurso compartido en el sistema A generando un fichero XML que un proceso batch introducía en los ficheros indexados COBOL del sistema A con una periodicidad adecuada. Para la implementación de este componente se utilizó SQLX (también conocido como SQL/XML) [7], [8] que es un lenguaje de consulta con sintaxis SQL que permite generar la salida de la consulta en formato XML. Está soportado cada vez más por los SGBDs lo que hace que sea uno de los lenguajes con más proyección en las arquitecturas para EAI. Como ejemplo, se muestran (arriba) una consulta y su resultado: Los XML validados sufren un proceso de validación usando Apache Xerces [12]. Si bien no era un requisito de la integración, también se podía realizar el proceso en tiempo real aunque penalizando bastante el rendimiento por el gran tamaño de los ficheros indexados. Este es un caso muy típico de integración B2B mediante el uso de XML y SOAP. Figura 8. Esquema de integración de empresa hotelera. Otro componente del middleware fue el usado para hacer disponible esta información a dispositivos inalámbricos que leían la información en XHTML. Para ello se utilizaron plantillas XSLT (Extensible Stylesheet Language Transformations) que convertían los XML generados por los componentes anteriores en el formato XHTML requerido. Este requisito era debido a que ciertos empleados debían conocer esta información en linea y vía teléfono móvil sin estar en su novática nº 176 julio-agosto

8 Lenguajes informáticos puesto de trabajo para así poder preparar las llegadas de los clientes. Referencias Hubo que interactuar con un tercer sistema (sistema C) que daba el servicio de reservas de hotel a través de la Web. Era una aplicación sin ningún intercambio de datos con el PMS (sistema A) del hotel y cuya única actividad con el usuario (empleado del hotel) era el envío de un correo electrónico cuando se realizaba o cancelaba una reserva. En este caso no había SGBD propiamente dicho por lo que se hizo un nuevo componente (EJB) en el middleware receptor de los correos electrónicos de reservas y cancelaciones, que generaba el correspondiente código XML que sería introducido en el PMS por el proceso batch. Finalmente, el mantenimiento de los servicios se hizo de una forma sencilla gracias a un pequeño repositorio de XML, que guarda la configuración de los componentes y servicios a los que estos acceden (fundamentalmente del sistema B) para prevenir futuros cambios en formato de datos, parámetros de conexión, parámetros de recepción de correos electrónicos, etc. Los resultados de la integración de los tres sistemas en el sistema A (figura 8) redundaron en la desaparición de muchos de los procesos manuales y la homogeneización de los entornos de trabajo: después de la integración, en el sistema A se dispone de toda la información que maneja y gestiona la empresa. [1] Amit Asaravala. Talk SOAP. Web Techniques, octubre < archives/2001/10/asaravala/>. [2] T. Berners-Lee, J. Hendler, O. Lassila. The Semantic Web, Scientific American, mayo < articleid= D2-1C70-84A9809EC588EF21>. [3] John Davies, Dieter Fensel, Fran van Harmelen (Eds.). Towards the Semantic Web. Ontologydriven Knowledge Management, John Wiley & Sons Ltd., [4] Matjaz B. Juric, Ramesh Nagappan, Rick Leander, S. Jeelani Basha. Professional J2EE EAI, Wrox Press Ltd., [5] OWL Web Ontology Language. W3C Recomendation, febrero < org/tr/2004/rec-webont-req />. [6] SOAP Versión 1.2. W3C Recomendation, junio < [7] SQLX. < [8] Oracle SQL/XML. < technology/tech/xml/xquery/sqlxml/index.html>. [9] Java tm 2 Platform, Enterprise Edition Blueprints,Copyright Sun Microsystems, Inc. < [10] Voice XML Forum. < [11] Nuance Voice Platform. < nuance.com/prodserv/platform.html>. [12] Apache Xerces. < xerces-j/>. [13] Jeffrey C. Lutz. EAI Architecture Patterns, EAI Journal, < Lutz.pdf>. 8. Conclusiones Se ha expuesto cómo las características de las arquitecturas multicapa y las de las tecnologías XML son ideales para realizar la integración con sistemas existentes y para la construcción de aplicaciones escalables y mantenibles. Este tipo de arquitecturas permiten proyectar los datos de sistemas antiguos al mundo Web y el acceso multidispositivo a dichos datos, sobre todo gracias a la separación de los datos de la presentación de los mismos, que ofrecen tanto XML como una arquitectura multicapa. Finalmente, se ha descrito un caso práctico donde se han cumplido los tres objetivos de la arquitectura enumerados al principio. La escalabilidad de las arquitecturas multicapa y la extensi-bilidad de XML proporcionan un magnífico punto de partida para realizar la integración de sistemas en el mundo Web. 60 novática nº 176 julio-agosto 2005