N 176, julio-agosto 2005, ao XXXI

Novtica, revista fundada en 1975 y decana de la prensa informtica espaola, es el rgano oficial de expresin y formacin continua de ATI (Asociacin de Tcnicos de Informtica). Novtica edita tambin UPGRADE, revista digital de CEPIS (Council of European Professional Informatics Societies), en lengua inglesa, UP y es miembro fundador de UP UPENET (UP UPGRADE European NET NETwork)
<http://www.ati.es/novatica/> <http://www.upgrade-cepis.org/> ATI es miembro fundador de CEPIS ( Council of European Professional Informatics Societies) y es representante de Espaa en IFIP ( International Federation for Information Processing); tiene un acuerdo de colaboracin con ACM (Association for Computing Machinery), as como acuerdos de vinculacin o colaboracin con AdaSpain AdaSpain, AI2 y ASTIC.
Consejo Editorial Antoni Carbonell Nogueras, Juan ManuelCueva Lovelle, Juan Antonio Esteban Iriarte,Francisco Lpez Crespo, Celestino Martn Alonso, Josep Molas i Bertrn, Olga Palls Codina, Fernando Piera Gmez (Presidente del Consejo), Ramn Puigjaner Trepat, Miquel Srries Gri, Asuncin Yturbe Herranz
Coordinacin Editorial Rafael Fernndez Calvo <rfcalvo@ati.es> Composicin y autoedicin Jorge Llcer Gil de Ramales Traducciones Grupo de Lengua e Informtica de ATI <http://www.ati.es/gt/lengua-informatica/> Administracin Toms Brunete, Mara Jos Fernndez, Enric Camarero, Felicidad Lpez

sumario
> 02 > 03

en resumen Normalizando la seguridad ... y buscando en la Intranet de Novtica Rafael Fernndez Calvo noticias de IFIP Informe de ATI sobre IFIP Actividades 2004-2005 Ramn Puigjaner Trepat

monografa
Estandarizacin y Seguridad TIC (En colaboracin con UP UPGRADE) Editores invitados: Paloma Garca Lpez, Stefanos Gritzalis, Javier Lpez Muoz Presentacin. La normalizacin en Seguridad TIC: una tarea colectiva internacional y multisectorial Paloma Garca Lpez, Stefanos Gritzalis, Javier Lpez Muoz Dnde nacen las normas voluntarias y las recomendaciones relativas a la seguridad de la informacin? Paloma Garca Lpez CEN/ISSS y su contribucin a la estandarizacin europea en Seguridad de las Tecnologas de la Informacin Luc Van den Berghe Medidas y mtricas de seguridad para los Sistemas de Informacin Jos A. Maas Argem Auditora de Seguridad de las TI desde la perspectiva de la normalizacin Marina Tourio Troitio Legislacin, estndares y recomendaciones relativos a la firma electrnica Josep Llus Ferrer Gomila, Apollnia Martnez Nadal El estndar X.509 para gestin de privilegios David Chadwick Estndares de seguridad de las TIC para aplicaciones en el mbito sanitario Spyros Kokolakis, Costas Lambrinoudakis

> 05 > 07 > 15 > 19 > 23 > 27 > 32 > 38

Secciones Tcnicas: Coordinadores

Administracin Pblica electrnica Gumersindo Garca Arribas, Francisco Lpez 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> Auditora SITIC Marina Tourio Troitio, Manuel Palao Garca-Suelto (ASIA) <marinatourino@marinatourino.com>, <manuel@palao.com> Bases de datos Coral Calero Muoz, Mario G. Piattini Velthuis (Escuela Superior de Informtica, UCLM) <Coral.Calero@uclm.es>, <mpiattin@inf-cr.uclm.es> Derecho y tecnologas Isabel Hernando Collazos (Fac. Derecho de Donostia, UPV)<ihernando@legaltek.net> Elena Davara Fernndez de Marcos (Davara & Davara) <edavara@davara.com> Enseanza Universitara de la Informtica Joaqun Ezpeleta Mateo (CPS-UZAR) <ezpeleta@posta.unizar.es> Cristbal Pareja Flores (DSIP-UCM) <cpareja@sip.ucm.es> Gestin del Conocimiento Joan Baiget Sol (Cap Gemini Ernst & Young) <joan.baiget@ati.es> Informtica y Filosofa Josep Corco Juviny (UIC) <jcorco@unica.edu> Esperanza Marcos Martnez (ESCET-URJC) <cuca@escet.urjc.es> Informtica Grfica Miguel Chover Sells (Universitat Jaume I de Castelln) <chover@lsi.uji.es> Roberto Viv Hernando (Eurographics, seccin espaola) <rvivo@dsic.upv.es> Ingeniera del Software Javier Dolado Cosn (DLSI-UPV) <dolado@si.ehu.es> Luis Fernndez Sanz (PRIS-EI-UEM) <lufern@dpris.esi.uem.es> Inteligencia Artificial Federico Barber Sanchs, Vicente Botti Navarro (DSIC-UPV) <{vbotti, fbarber}@dsic.upv.es> Interaccin Persona-Computador Julio Abascal Gonzlez (FI-UPV) <julio@si.ehu.es> Jess Lors Vidal (Univ. de Lleida) <jesus@eup.udl.es> Internet Alonso lvarez Garca (TID) <alonso@ati.es> Lloren Pags Casas (Indra) <pages@ati.es> Lengua e Informtica M. del Carmen Ugarte Garca (IBM) <cugarte@ati.es> Lenguajes informticos Andrs Marn Lpez (Univ. Carlos III) <amarin@it.uc3m.es> J. ngel Velzquez Itrbide (ESCET-URJC) <a.velazquez@escet.urjc.es> Libertades e Informtica Alfonso Escolano (FIR-Univ. de La Laguna) <aescolan@ull.es> Lingstica computacional Xavier Gmez Guinovart (Univ. de Vigo) <xgg@uvigo.es> Manuel Palomar (Univ. de Alicante) <mpalomar@dlsi.ua.es> Mundo estudiantil Adolfo Vzquez Rodrguez (Rama de Estudiantes del IEEE-UCM) <a.vazquez@ieee.org> Profesin informtica Rafael Fernndez Calvo (ATI) <rfcalvo@ati.es> Miquel Srries Gri (Ayto. de Barcelona) <msarries@ati.es> Redes y servicios telemticos Luis Guijarro Coloma (DCOM-UPV) <lguijar@dcom.upv.es> Josep Sol Pareta (DAC-UPC) <pareta@ac.upc.es> Seguridad Javier Areitio Bertoln (Univ. de Deusto) <jareitio@eside.deusto.es> Javier Lpez Muoz (ETSI Informtica-UMA) <jlm@lcc.uma.es> Sistemas de Tiempo Real Alejandro Alonso Muoz, Juan Antonio de la Puente Alfaro (DIT-UPM) <{aalonso,jpuente}@dit.upm.es> Software Libre Jess M. Gonzlez Barahona, Pedro de las Heras Quirs (GSYC-URJC) <{jgb,pheras}@gsyc.escet.urjc.es> Tecnologa de Objetos Jesus Garca Molina (DIS-UM) <jmolina@correo.um.es> Gustavo Rossi (LIFIA-UNLP, Argentina) <gustavo@sol.info.unlp.edu.ar> Tecnologas para la Educacin Juan Manuel Dodero Beardo (UC3M) <dodero@inf.uc3m.es> Tecnologas y Empresa Pablo Hernndez Medrano (Bluemat) <pablohm@bluemat.biz> TIC para la Sanidad Valentn Masero Vargas (DI-UNEX) <vmasero@unex.es> TIC y Turismo Andrs Aguayo Maldonado, Antonio Guevara Plaza (Univ. de Mlaga) <{aguayo, guevara}@lcc.uma.es>

secciones tcnicas
Bases de datos Calidad de Datos en aplicaciones web: un "estado del arte" M Anglica Caro Gutirrez, Coral Calero Muoz, Ismael Caballero Muoz-Reja, Mario Piattini Velthuis Informtica grfica Generacin de penumbras con hardware grfico Pere-Pau Vzquez Alcocer, Dani Susn Acebo Lenguajes informticos Una arquitectura software multicapa para la integracin de sistemas Rafael Pastor Pastor, Antonio Guevara Plaza, Jos Luis Caro Herrero, Andrs Aguayo Maldonado Redes y servicios telemticos Ping Trunking: un mecanismo de control de congestin para trfico agregado basado en Vegas Sergio Herrera Alonso, Manuel Fernndez Veiga, Miguel Rodrguez Prez, Andrs Surez Gonzlez, Cndido Lpez Garca Referencias autorizadas > 45

> 49 > 54

> 61

> 67

Las opiniones expresadas por los autores son responsabilidad exclusiva de losmismos. Novtica permite la reproduccin de todos los artculos, a menos que lo impida la modalidad de o copyright elegida por el autor, debindose en todo caso citar su procedencia y enviar a Novtica un ejemplar de la publicacin.
Coordinacin Editorial, Redaccin Central y Redaccin ATI Madrid Padilla 66, 3, dcha., 28006 Madrid Tlfn.914029391; fax.913093685 <novatica@ati.es> Composicin, Edicin y Redaccin ATI Valencia Av. del Reino de Valencia 23, 46005 Valencia Tlfn./fax 963330392 <secreval@ati.es> Administracin y Redaccin ATI Catalua Ciudad de Granada 131, 08018 Barcelona Tlfn.934125235; fax 934127713 <secregen@ati.es> Redaccin ATI Andaluca Isaac Newton, s/n, Ed. Sadiel, Isla Cartuja 41092 Sevilla, Tlfn./fax 954460779 <secreand@ati.es> Redaccin ATI Aragn Lagasca 9, 3-B, 50006 Zaragoza. Tlfn./fax 976235181 <secreara@ati.es> Redaccin ATI Asturias-Cantabria <gp-astucant@ati.es> Redaccin ATI Castilla-La Mancha <gp-clmancha@ati.es> Redaccin ATI Galicia Recinto Ferial s/n, 36540 Silleda (Pontevedra) Tlfn.986581413; fax 986580162 <secregal@ati.es> Suscripcin y Ventas <http://www.ati.es/novatica/interes.html>, o en ATI Catalua o ATI Madrid Publicidad Padilla 66, 3, dcha., 28006 Madrid Tlnf.914029391; fax.913093685 <novatica.publicidad@ati.es> Imprenta Derra S.A., Juan de Austria 66, 08005 Barcelona. Depsito legal: B 15.154-1975 -- ISSN: 0211-2124; CODEN NOVAEC Portada: Antonio Crespo Foix / ATI 2005 Diseo: Fernando Agresta / ATI 2005

sociedad de la informacin
Programar es crear La casa ms grande (CUPCAM 2005, problema B, enunciado) Manuel Abellanas Oar Domin Solitario (CUPCAM 2005, problema A, solucin) Antonio Fernndez Anta > 74 > 75

asuntos interiores
Coordinacin editorial / Programacin de Novtica Normas de publicacin para autores / Socios Institucionales > 76 > 77

Monografa del prximo nmero: "Computacin ubicua"

secciones tcnicas Lenguajes informticos

Rafael Pastor Pastor, Antonio Guevara Plaza, Jos Luis Caro Herrero, Andrs Aguayo Maldonado
Sistemas de Informacin Cooperativos de la Universidad de Mlaga (SICUMA), ETSI Informtica, Universidad de Mlaga
<{rpastor, guevara, jlcaro, aguayo}@lcc.uma.es>

Una arquitectura softwaremulticapa para la integracin de sistemas

1. Introduccin Actualmente existe una necesidad creciente en muchas empresas de integrar sus aplicaciones entre s no slo a nivel de informacin sino, tambin, a nivel de servicios. En muchos de estos casos, la integracin 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 tecnologas proyectamos sus datos hacia el mundo web o hacia otra aplicacin para ofrecer o aprovechar servicios que utilicen estos datos. Con esta integracin se persiguen objetivos esenciales como: Integracin B2B (Business to Business) Soporte multidispositivo para acceso a informacin y servicios Implantacin y mantenimiento sencillos de nuevos servicios En este entorno, las tecnologas XML (eXtensible Markup Language) se estn imponiendo en la industria a travs de estndares 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 arquitecturas multicapa como arquitecturas software para definir plataformas de servicios en la Web permite desarrollar, implantar y mantener de forma fcil nuevas aplicaciones y servicios sobre los sistemas existentes. Tambin nos proporcionan un modo de adaptar dichos sistemas al mundo web de una forma sencilla y escalable permitiendo la integracin entre servicios Web y los SGBDs (Sistema de Gestin de Bases de Datos) de las empresas. Asimismo, el uso de estas arquitecturas, junto con las tecnologas XML, facilita la separacin entre los datos y la presentacin de los mismos, lo cual es un requisito fundamental para el soporte multidispositivo. La integracin B2B es muy importante para muchas empresas, sobre todo para aquellas cuyas transacciones ms importantes se dan
54 novtica n 176 julio-agosto 2005

Resumen: cada vez ms, las empresas se estn integrando en el mundo web a nivel de informacin y servicios. Las tecnologas XML (eXtensible Markup Language) aplicadas conjuntamente con arquitecturas software multicapa nos permiten realizar la integracin con los sistemas existentes en estas empresas construyendo aplicaciones escalables y fcilmente mantenibles al mismo tiempo que conseguimos acceso multidispositivo a la informacin, gracias, principalmente, a la separacin de los datos de la presentacin de los mismos, caracterstica que ofrecen tanto el empleo de XML como el uso de una arquitectura software multicapa. El artculo finaliza presentando un caso prctico de integracin de sistemas usando la arquitectura descrita. Palabras clave: acceso multidispositivo, arquitecturas multicapa, B2B, J2EE, middleware, mundo web, XML. con otras organizaciones. Las tecnologas XML proporcionan una forma eficiente de conseguirla, utilizndose como formato de intercambio de datos estndar entre negocios, sin eliminar las ventajas del uso de otras tecnologas, por ejemplo, EDI (Electronic Data Interchange). De esta manera se permite tambin combinar flexibilidad en la presentacin y transformacin de los datos mediante, por ejemplo, XSL (eXtensible Stylesheet Language), para automatizar procesos en organizaciones que pueden as, de forma individual, desarrollar el modo ms adecuado de presentar los documentos intercambiados segn 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 informacin entre organizaciones y de implantar y mantener nuevos servicios de forma eficiente y sencilla [1].
2. Solucin multicapa

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 informacin de la empresa--, una capa de lgica 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 presentacin presentacin, que se ocupa de mostrar el resultado de la lgica sobre los datos de forma adecuada. Las aplicaciones que se diseen 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 disear e implementar aplicaciones multicapa podemos mencionar J2EE (Java 2 Enterprise Edition de Sun) y DNA (Distributed Network Architecture de Microsoft) as como la evolucin de est ltima (.NET). Tomaremos como referencia a lo largo de este artculo la primera. Una de las caractersticas ms importantes de XML es la separacin que realiza entre los datos y la presentacin, elemento que, como hemos mencionado, es una caracterstica esencial en una arquitectura software multicapa. XML nos ayudar, pues, a realizar esta separacin en aplicaciones diseadas para arquitecturas multicapas, pues mediante el uso de XML podemos hacer que la capa de presentacin sea lo ms independiente posible de la de negocio y sta, a su vez, lo sea de la de datos. Ser clave que la obtencin de servicios, el despliegue de nuevas aplicaciones, la interfaz de usuario y, en general, el flujo de informacin desde la capa de datos a la de presentacin, se pueda
secciones tcnicas

La caracterstica 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 divisin nos permite dimensionar cada capa de forma independiente en funcin de las necesidades del problema, distribuir nuestras aplicaciones de forma sencilla y escalable, prcticamente transparente a la implementacin, y conseguir una alta disponibilidad y rendimiento de las mismas. Todas estas caractersticas son cada vez ms importantes para el soporte de procesos de negocios sobre todo en sistemas utilizados a travs de la Web.

gestionar de una manera extensible, escalable, estndar e independiente del dispositivo, es decir, con la aplicacin de tecnologas XML, las cuales permiten obtener todas estas caractersticas 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 idneos para datos que quepan en filas y columnas, no pueden manejar adecuadamente otros "tipos de datos" de ms alto nivel, muy tpicos en la Web, como audio, vdeo, documentos complejos, etc. Por otro lado, la no dependencia de un motor especfico de base de datos para tratar los datos con XML, hace que este lenguage sea adecuado como medio de integracin entre sistemas heterogneos (SGDBs, sistemas de ficheros indexados, etc.) existentes en la empresa. Uno de los elementos clave para aplicar las tecnologas XML a la integracin de los sistemas ser la existencia de un repositorio XML que nos permita la gestin tanto de los datos existentes como los nuevos. Por un lado, de la misma manera que hasta ahora se venan tratando y, por otro, proyectndolos 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

Lenguajes informticos secciones tcnicas

La integracin B2B es muy importante para muchas empresas

construir el repositorio XML variar en gran parte dependiendo del volumen de datos gestionado por los sistemas actuales. En una primera aproximacin en el que dichos sistemas fueran inexistentes (obviamente, no se puede hablar de integracin), se podra plantear el uso exclusivo de un sistema de bases de datos XML nativo pero ste es un caso poco prctico 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 ms comn existirn bases de datos convencionales y una opcin podra ser utilizar una aplicacin o componente software middleware que realice la transformacin 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 opcin es que, normalmente, el software middleware limita el rendimiento y en su forma ms bsica, una aplicacin o componente middleware no acepta consultas expresadas en un lenguaje de consulta XML sino expresadas en el propio LMD (Lenguaje de Manipulacin de Datos) del SGBD (normalmente SQL, Structured Query Language), lo cual puede suponer un fuerte obstculo 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 caracterstica). Sin embargo, debe tenerse en cuenta que esta opcin 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 algn componente de la capa de lgica de negocio. La ampliacin a esta opcin sera disponer, adems del SGBD y la base de datos XML nativa, de una aplicacin o componente middleware con funcionalidades como: mapeo/sincronizacin entre SGBD y BD XML nativa, traduccin de consultas en SQL a XQuery, traduccin entre distintos lenguajes de consulta XML, conversin entre distintos lenguajes de definicin de esfigura 1 quemas XML, etc. (figura 1). Todo esto se traduce en que la capa de datos debe proporcionar, fundamentalmente, una representacin estndar de los datos (XML, XMLSchema), un formulacin de las consultas mediante lenguajes universales (SQL, XQuery) y un acceso a los datos mediante una va estndar (por ejemplo, el protocolo http, HyperText Transmission Protocol). 4. XML en la capa de negocio En esta capa implementaremos toda la lgica de negocio de las aplicaciones construidas sobre nuestra arquitectura y la disearemos teniendo en cuenta que todas las operaciones de la lgica de negocio, en el caso de una plataforma J2EE, sern accesibles a travs de componentes EJBs (Enterprise Java Beans) de sesin, con el objetivo que el cliente slo tenga que acceder a un componente para hacer uso de la aplicacin 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 descripcin de la persistencia sobre objetos, los mtodos para encontrar el objeto de la base de datos, el despliegue de los componentes en la arquitectura, etc., se definen en formato XML. Otra alternativa es que no se utilicen EJBs de entidad y s EJBs de sesin que invocan procedimientos almacenados, lanzan consultas, realizan inserciones, etc., sobre la
novtica n 176 julio-agosto 2005 55

Figura 1. Uso de un middleware para acceso un SGBD y BD XML nativa.

secciones tcnicas

secciones tcnicas Lenguajes informticos

tratada en un entorno controlado (servidor). Para la parte cliente la lgica siempre debe ser muy bsica y lo ms estndar posible. De hecho, en las aplicaciones cliente se debera limitar el tipo de lgica a ejecutar, impidiendo de forma tajante caractersticas fuera del estndar. Existen otro tipo de consideraciones relativas a la seguridad que tambin desaconsejan la ejecucin de lgica por parte de los clientes. Centrndonos en una plataforma J2EE, podemos considerar la opcin de comunicar la capa de presentacin con la capa de negocio mediante un JavaBean que efecta una funcin de Proxy y que ser el encargado de conservar las referencias remotas al servidor de aplicaciones. Por otro lado, una razn fundamental para la existencia de esta otra capa intermedia es el mantenimiento de las pginas JSP, que siempre es complejo. Este mantenimiento se simplifica mediante el uso de TagLibs [9]. Las clases que implementan los Tags realizan directamente la invocacin a los componentes de la capa de negocio o figura 5 bien a travs del JavaBean Proxy (figura 5). Esta solucin puede afectar al rendimiento dependiendo de la aplicacin, por lo que de nuevo debemos llegar a un compromiso entre el rendimiento y el mantenimiento fcil 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 informacin de la versin de TagLibs usada, la versin de JSP, el nombre que tomar la librera de tags y, para cada tag, el nombre de la clase de tag, localizacin de la clase y descripcin del cuerpo del tag. Estos ficheros TLD se despliegan en un recurso del Servidor Web que viene descrito en XML en el fichero (normalmente

Figura 2. Capa Intermedia ( gateway) para mejorar separacin entre lgica y datos.

base de datos, el repositorio XML o el middleware, para lo que podemos utilizar tambin XML en una capa intermedia de configuracin (formada por documentos XML) para minimizar el mantenimiento del cdigo en la capa de negocio cuando cambia algo en la capa de datos. Estos XML estarn gestionados por un componente cuya misin es generar dichos XML, configurar los posibles cambios a los mismos (backoffice de la aplicacin) y servir de pasarela entre otros componentes que van a acceder a la figura 2 capa de datos (figura 2). Obviamente, al aadir esta nueva capa debemos hacer consideraciones sobre el rendimiento de la aplicacin y llegar a un compromiso entre aquello que merece la pena o no flexibilizar a costa de prdida de eficiencia. A esta pasarela se le pueden aadir las funcionalidades de la aplicacin middleware figura 3 de la capa de datos (figura 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 an ms para minimizar las interacciones entre las mismas. Si bien, comparada con esta solucin, el uso de EJBs de entidad (en una plataforma J2EE) es ms homogneo y figura 4 estndar (figura 4), esta tcnica es ms flexible y comn para conseguir el objetivo de separacin entre las capas de datos y negocio, tanto en una plataforma J2EE como en una plataforma MS.NET. Adems, en el primer tipo de plataforma podra plantearse un uso mixto de ambas soluciones. 5. XML en la capa de presentacin Podemos considerar esta capa dividida en una capa Web y una capa cliente. La primera da el acceso a la aplicacin y consta de componentes como pginas estticas (XHTML, eXtensible Hypertext Markup Language; HTML; WML, Website Meta
56 novtica n 176 julio-agosto 2005

Language; VoiceXML, etc.), pginas generadas dinmicamente 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 aplicacin (PDA, Personal Digital Assistant; Web TV, etc.). En la capa cliente hay parte de lgica 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 lgica siempre que esto no represente una saturacin en la parte del servidor. El hecho de minimizar esta lgica en el cliente nos libera de la problemtica de las incompatibilidades entre distintos clientes ya que la mayor parte de lgica ha sido

Figura 3. Uso del middleware para gestionar la capa gateway.

secciones tcnicas

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 aplicacin y guardar el estado de la interfaz del usuario y como responsable de recoger las entradas del usuario y decidir cul de las vistas es la adecuada para mostrarle. Cada pgina JSP implementa una vista y se limita a recoger ciertos parmetros del controlador, mostrar los contenidos de forma adecuada y proporcionar al usuario enlaces que ejecutan funciones del controlador. En cuanto al acceso multidispositivo, las pginas JSP pueden tener su aplicacin en la generacin de la correspondiente vista (XHTML, WML, VoiceXML , XHTML Basic, etc.) por s mismas (multiple pipeline), en combinacin con transformaciones XSL ( single pipeline ) o de forma mixta (combination pipeline). Uno de los puntos bsicos para el soporte multidispositivo es el acceso, que --segn la arquitectura propuesta-- se realizar teniendo como punto de entrada el servlet controlador, que determinar la respuesta vlida para el dispositivo correspondiente mediante la comprobacin de la informacin relativa al agente de usuario (user-agent). Esto nos permitir distinguir qu dispositivo est

Lenguajes informticos secciones tcnicas

El uso de arquitecturas software dividas en tres capas est bastante extendido

Figura 4. Arquitectura propuesta en una plataforma J2EE.

Una vez se recibe una peticin, existen una serie de procesos software asociados al hardware anterior que realizan tareas de interpretacin de los documentos VoiceXML que, mediante sintaxis XML, describen el dilogo entre el usuario y el sistema, las posibles opciones a elegir por parte del usuario, la redireccin a otro documento VoiceXML (contenido, por ejemplo, en la base de datos XML nativa) o pgina JSP (que dinmicamente generar el contenido VoiceXML a partir, por ejemplo, de informacin 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. Tambin existen procesos para el control de las gramticas de cada idioma, que utilizan definiciones del modelo acstico del idioma correspondiente para realizar un buen reconocimiento de las palabras que el usuario pronuncia. Esta caracterstica hace que nuesFigura 5. Capa Intermedia (TagLibs) para mejorar la separacin entre lgica y presentacin. tra arquitectura est preparada para dar sonovtica n 176 julio-agosto 2005 57

figurealizando la peticin al servidor Web (figura 6 6). Por ejemplo, si en la peticin HTTP detectamos text/html, text/xhtml o text/plain sabremos que la peticin la ha realizado un navegador y por lo tanto devolveremos HTML, XHTML o texto plano respectivamente. Si detectamos text/wml sabremos que la peticin la ha realizado un dispositivo WAP. Si detectamos text/vxml entonces sabremos que se est accediendo a travs de un telfono y lo que el usuario espera es una interaccin mediante la voz con el sistema, que deber poseer un sistema de portal de voz para satisfacer la peticin.

Precisamente los portales de voz estn tomando un auge considerable desde la aparicin de propuestas de estndares 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 telefona con tarjetas para soporte de primarios y/o lneas analgicas asociadas a uno o varios nmeros de telfono que recogen las peticiones realizadas va teleffigura 7 nica (figura 7).

secciones tcnicas

secciones tcnicas Lenguajes informticos

zar las dependencias entre aplicaciones. Patrn automatizador: describe un mtodo para minimizar las dependencias entre la lgica de automatizacin 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 tcnicas de multiple pipeline, single pipeline o combination pipeline anteriormente descritas se puede ver como una clara aplicacin del patrn adaptador. Por ltimo, una tendencia de integracin entre sistemas con interfaces Web bastante interesante es el uso de las tecnologas relacionadas con la Web semntica [2], [3] especialmente indicada cuando estos sistemas web van a quedar abiertos a nuevas integraciones con otros sistemas an no conocidos. Dotando a los datos de los sistemas de metainformacin mediante el uso RDF ( Resource Description Framewok ) + RDFSchema y disponiendo dicha informacin en repositorios XML, que pueden ser accesibles va sindicacin, se consigue disponer de los datos de una forma estndar. Luego, puede ser necesaria o no la aplicacin de un patrn adaptador para poder disponer de la informacin como realmente nos interese proporcionarla al middleware que realizara la integracin segn el modelo de mtodos de negocio. Un ejemplo de la disposicin de la informacin va sindicacin 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 tecnologas relacionadas con la Web semntica

Figura 6. Capas intermedia, web y cliente.

porte a aplicaciones de voz y, as, los usuarios pueden utilizar las aplicaciones va telefnica. En este sentido, existen arquitecturas comerciales que aplican desde hace tiempo los estndares XML para voz [11]. 6. Tendencias, patrones y modelos en la integracin de sistemas Algunos autores [4] plantean, si no arquitecturas, s modelos para la integracin que presentamos, de forma resumida, en los siguientes puntos: Integracin a travs de datos: usando exclusivamente tcnicas de acceso a datos (JDBC, Java DataBase Connectivity) o de intercambio de datos en XML (JAXP, Java API for XML Parsing). Integracin de mtodos de negocio: Uso de componentes de lgica de negocio (CORBA, Common Object Request Broker Architecture; EJBs; COM; etc.). Integracin en la capa de presentacin: usando exclusivamente JSPs y servlets para la integracin de los datos mostrados en la capa de presentacin. Integracin B2B: uso de XML desde la capa de datos, XSL aplicado a estos datos para la definicin de interfaces y uso de Web Services y tecnologas 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 caractersticas de alguno de los modelos planteados. Otros autores [13] han definido patrones a seguir en la integracin de sistemas que definen conjuntos de subsistemas predefinidos, relaciones entre los mismos y reglas para la organizacin de esas relacio58 novtica n 176 julio-agosto 2005

nes. Estos patrones se aplican a nivel de arquitectura para dar consistencia a las aplicaciones que intervienen en la aplicacin y, dentro de una aplicacin dada, para cumplir un papel especfico dentro de la arquitectura. Como ejemplo se referencian los siguientes patrones de integracin: Patrn adaptador: convierte una interfaz de una aplicacin existente en la interfaz deseada. Patrn mensajero: describe un mtodo para minimizar las dependencias de comunicacin entre las aplicaciones. Patrn fachada: proporciona una interfaz simplificada para minimizar las dependencias entre las aplicaciones clientes y las aplicaciones servidor. Patrn mediador: encapsula la lgica de interaccin de la aplicaciones para minimi-

Figura 7. Arquitectura genrica para plataforma VoicePortal .

secciones tcnicas

ATTRIBUTES (reserved AS reserved), XMLFOREST ( fSELECT XMLELEMENT ("week", XMLirstname || , || lastname AS "owner", contact AS "email") ) FROM weeks <week reserved="true"> <owner>Chris Jonhanson</owner> <email>cjonhanson@xxxxxxx.com</email> </week>
nos pueden proporcionar en lo que se refiere al acceso a datos, pero tambin se puede profundizar en el uso de estas tcnicas aplicadas a la integracin de sistemas an no conocidos usando ontologas para definir trminos (datos) de una manera precisa y dotar de significado a los datos que esperan participar en la integracin. Aparte de la precisin y diferenciacin que se consigue al definir trminos con ontologas se obtiene tambin una ventaja adicional, que es la reutilizacin de estas codificaciones para definir datos haciendo el conocimiento reutilizable. Para ello la W3C (World Wide

Lenguajes informticos secciones tcnicas

Las aplicaciones para estas arquitecturas deben tener independencia entre todas sus capas

Por otro lado, la empresa trata la informacin mediante un acceso restringido (slo 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. La integracin del sistema A y B se llev a cabo a travs de la implementacin de un software middleware con varios componentes (EJBs). Uno de ellos realizaba el acceso al sistema B y comunicaba la informacin a otro componente va SOAP. Este segundo componente acceda a un recurso compartido en el sistema A generando un fichero XML que un proceso batch introduca en los ficheros indexados COBOL del sistema A con una periodicidad adecuada. Para la implementacin de este componente se utiliz SQLX (tambin 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 ms por los SGBDs lo que hace que sea uno de los lenguajes con ms proyeccin en las arquitecturas para EAI. Como ejemplo, se muestran (arriba) una consulta y su resultado: Los XML validados sufren un proceso de validacin usando Apache Xerces [12]. Si bien no era un requisito de la integracin, tambin se poda realizar el proceso en tiempo real aunque penalizando bastante el rendimiento por el gran tamao de los ficheros indexados. Este es un caso muy tpico de integracin B2B mediante el uso de XML y SOAP. Otro componente del middleware fue el usado para hacer disponible esta informacin a dispositivos inalmbricos que lean la informacin en XHTML. Para ello se utilizaron plantillas XSLT ( Extensible Stylesheet Language Transformations) que convertan los XML generados por los componentes anteriores en el formato XHTML requerido. Este requisito era debido a que ciertos empleados deban conocer esta informacin en linea y va telfono mvil sin estar en su
novtica n 176 julio-agosto 2005 59

Web Consortium) ha creado OWL (Ontology Web Language) como el lenguaje de definicin de ontologas en la Web [5].
7. Un caso prctico Esta arquitectura ha sido llevada a la prctica en una empresa de gestin hotelera y multipropiedad (time-sharing). En ella se gestiona la informacin 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).

Figura 8. Esquema de integracin de empresa hotelera.

secciones tcnicas

secciones tcnicas Lenguajes informticos

puesto de trabajo para as poder preparar las llegadas de los clientes. Hubo que interactuar con un tercer sistema (sistema C) que daba el servicio de reservas de hotel a travs de la Web. Era una aplicacin sin ningn intercambio de datos con el PMS (sistema A) del hotel y cuya nica actividad con el usuario (empleado del hotel) era el envo de un correo electrnico cuando se realizaba o cancelaba una reserva. En este caso no haba SGBD propiamente dicho por lo que se hizo un nuevo componente (EJB) en el middleware receptor de los correos electrnicos de reservas y cancelaciones, que generaba el correspondiente cdigo XML que sera introducido en el PMS por el proceso batch. Finalmente, el mantenimiento de los servicios se hizo de una forma sencilla gracias a un pequeo repositorio de XML, que guarda la configuracin de los componentes y servicios a los que estos acceden (fundamentalmente del sistema B) para prevenir futuros cambios en formato de datos, parmetros de conexin, parmetros de recepcin de correos electrnicos, etc. Los resultados de la integracin de los tres figura 8 sistemas en el sistema A (figura 8) redundaron en la desaparicin de muchos de los procesos manuales y la homogeneizacin de los entornos de trabajo: despus de la integracin, en el sistema A se dispone de toda la informacin que maneja y gestiona la empresa. 8. Conclusiones Se ha expuesto cmo las caractersticas de las arquitecturas multicapa y las de las tecnologas XML son ideales para realizar la integracin con sistemas existentes y para la construccin 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 separacin de los datos de la presentacin de los mismos, que ofrecen tanto XML como una arquitectura multicapa. Finalmente, se ha descrito un caso prctico 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 magnfico punto de partida para realizar la integracin de sistemas en el mundo Web.

Referencias

[1] Amit Asaravala. Talk SOAP. Web Techniques , octubre 2001. <http://www.webtechniques.com/ archives/2001/10/asaravala/>. [2] T. Berners-Lee, J. Hendler, O. Lassila. The Semantic Web, Scientific American, mayo 2001. <http://www.sciam.com/article.cfm? articleID= 00048144-10D2-1C70-84A9809EC588EF21>. [3] John Davies, Dieter Fensel, Fran van Harmelen (Eds.). Towards the Semantic Web. Ontologydriven Knowledge Management, John Wiley & Sons Ltd., 2002. [4] Matjaz B. Juric, Ramesh Nagappan, Rick Leander, S. Jeelani Basha. Professional J2EE EAI, Wrox Press Ltd., 2002. [5] OWL Web Ontology Language. W3C Recomendation, febrero 2004. <http://www.w3. org/TR/2004/REC-webont-req-20040210/>. [6] SOAP Versin 1.2. W3C Recomendation, junio 2003. <http://www.w3.org/TR/soap/>. [7] SQLX. <http:www.sqlx.org>. [8] Oracle SQL/XML. <http://www.oracle.com/ technology/tech/xml/xquery/sqlxml/index.html>. [9] Java tm 2 Platform , Enterprise Edition Blueprints,Copyright 1995-2001 Sun Microsystems, Inc. <http://java.sun.com/blueprints/>. [10] Voice XML Forum. <http://www.voicexml.org/>. [11] Nuance Voice Platform. <http://www. nuance.com/prodserv/platform.html>. [12] Apache Xerces. <http://xml.apache.org/ xerces-j/>. [13] Jeffrey C. Lutz. EAI Architecture Patterns, EAI Journal, 2000. <http://www.eaijournal.com/PDF/ Lutz.pdf>.

60 novtica n 176 julio-agosto 2005

secciones tcnicas