Carnés UMA ad hoc: Interconexión de Sistemas y Servicios Web SOAP
Abstract
Este trabajo fin de grado tiene como finalidad el análisis y estudio de la interconexión de sistemas informáticos diferentes a través del desarrollo de Servicios Web SOAP, y su aplicación en un proyecto concreto. Una Arquitectura Orientada a Servicios (SOA) es una arquitectura que define cómo interoperan funciones de negocios independientes implementados por sistemas autónomos para ejecutar un proceso de negocios. El diseño Web tiende a ser cada vez más modular y las aplicaciones se componen de una serie de componentes reutilizables, que pueden encontrarse distribuidos a lo largo de una serie de máquinas conectadas en red. Los Servicios Web nos permiten distribuir nuestra aplicación a través de Internet, definiendo como clave la interoperatibilidad entre las aplicaciones. Los servicios Web SOAP utilizan mensajes XML para intercomunicarse que siguen el estándar SOAP, un lenguaje XML que define la arquitectura y formato de los mensajes, que deben contener una descripción de las operaciones ofrecidas y escrita en WSDL (Web Services Description Language). El formato de mensaje SOAP y el WSDL se ha extendido bastante y muchas IDE (Integrated Development Environment), por ejemplo NetBeans, Eclipse o JDeveloper, reducen la complejidad de desarrollar aplicaciones de servicios Web.
Full text
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 1
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 2
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 3 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA GRADO DE INGENIERIA DE COMPUTADORES Carnés UMA ad hoc: Interconexión de Sistemas y Servicios Web SOAP UMA’s CARD ad hoc: Systems Interconnection and Web Services SOAP Realizado por D. JOSÉ CARLOS BUSTAMANTE TOLEDO Tutorizado por D. MARINO CASTILLO CABEZAS Departamento LENGUAJE Y CIENCIAS DE LA COMUNICACIÓN UNIVERSIDAD DE MÁLAGA MÁLAGA, NOVIEMBRE DE 2016 Fecha defensa: El Secretario del Tribunal
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 4
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 5 Resumen: Este trabajo fin de grado tiene como finalidad el análisis y estudio de la interconexión de sistemas informáticos diferentes a través del desarrollo de Servicios Web SOAP, y su aplicación en un proyecto concreto. Una Arquitectura Orientada a Servicios (SOA) es una arquitectura que define cómo interoperan funciones de negocios independientes implementados por sistemas autónomos para ejecutar un proceso de negocios. El diseño Web tiende a ser cada vez más modular y las aplicaciones se componen de una serie de componentes reutilizables, que pueden encontrarse distribuidos a lo largo de una serie de máquinas conectadas en red. Los Servicios Web nos permiten distribuir nuestra aplicación a través de Internet, definiendo como clave la interoperatibilidad entre las aplicaciones. Los servicios Web SOAP utilizan mensajes XML para intercomunicarse que siguen el estándar SOAP, un lenguaje XML que define la arquitectura y formato de los mensajes, que deben contener una descripción de las operaciones ofrecidas y escrita en WSDL (Web Services Description Language). El formato de mensaje SOAP y el WSDL se ha extendido bastante y muchas IDE (Integrated Development Environment), por ejemplo NetBeans, Eclipse o JDeveloper, reducen la complejidad de desarrollar aplicaciones de servicios Web. Palabras claves: Servicios Web, SOAP, WSDL, SQL, NetBeans. Abstract: This final work aims to analyze and study the interconnection of different computer systems through the development of SOAP Web Services and its application in a specific project. A Service Oriented Architecture (SOA) is an architecture that defines how independent business functions implemented by autonomous systems interoperate to execute a business process. Web design tends to be increasingly modular and applications are made up of a series of reusable components, which can be distributed over a series of networked machines. Web Services allow us to distribute our application over the Internet, defining interoperability between applications as a key. SOAP Web services use XML messages to intercommunicate following the SOAP standard, an XML language that defines the architecture and format of the messages, which must contain a description of the operations offered and written in WSDL (Web Services Description Language). The SOAP message format and the WSDL have been quite widespread, and many IDEs, such as NetBeans, Eclipse, or JDeveloper, reduce the complexity of developing Web services applications. Keywords: Web Services, SOAP, WSDL, SQL, NetBeans
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 6
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 7 INDICE DE CONTENIDOS 1. Introducción. ........................................................................................................................ 9 2. Motivación. .......................................................................................................................... 11 3. Fundamentos y estado del arte. .................................................................................... 13 3.1. Introducción. .................................................................................................................. 13 3.1.1. Proceso de diseño de servicios software. ........................................................ 14 3.1.2. Aspectos de diseño de servicios software. ...................................................... 16 3.1.3. Características de los Servicios Web. ................................................................ 20 3.2. Tipos de Servicios Web. .............................................................................................. 20 3.2.1. Servicios Web SOAP. ............................................................................................... 20 3.2.2. Servicios Web REST................................................................................................. 21 3.3. Servicios Web SOAP y Java EE. ............................................................................... 22 3.3.1. Arquitectura de servicios Web SOAP. ................................................................ 23 3.3.2. SOAP. .......................................................................................................................... 25 3.3.3. WSDL. .......................................................................................................................... 26 3.3.4. UDDI. ............................................................................................................................ 28 3.5. Interoperatibilidad de los servicios Web. ............................................................... 31 3.5.1. Los Servicios desde la vista del Cliente. ........................................................... 33 3.5.2. Los servicios Web desde la vista del Servidor. ............................................... 34 3.5.3. NetBeans y ficheros WSDL. .................................................................................. 37 3.6. Composición de servicios y SOA. ............................................................................ 38 3.6.1. Breve Introducción a la Composición de Servicios. ...................................... 40 3.6.2. Orquestación vs. Coreografía. .............................................................................. 41 3.6.3. Workflow vs. Dataflow. ........................................................................................... 43 4. Metodología. ....................................................................................................................... 46 4.1. Metodología Scrum....................................................................................................... 49 5. Análisis de la interconexión de sistemas planteados. ............................................ 52 5.1 Análisis de servicios Web SOAP del sistema. ...................................................... 52 5.1.1. Consultas de usuarios - searchUsers. ............................................................... 53 5.1.2. Selección del usuario a emitir tarjeta - •searchUserById. ................................ 56 5.1.3. Envío de datos sobre tarjeta emitida - sendIssuedCard. .......................... 61 5.1.4. Objetos para el intercambio de datos. ............................................................... 65 5.1.5. Seguridad y despliegue de los Servicios Web. ................................................ 66 5.1.6. Tratamiento de errores y excepciones. .............................................................. 67 5.2. Análisis de diferentes modelos. ................................................................................ 68
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 8 5.2.1. Casos de Uso. ........................................................................................................... 68 5.2.2. Diagrama de base de datos. .................................................................................. 71 5.2.2.1. Tabla Alumnos. ...................................................................................................... 72 5.2.2.2. Tabla Expedientes. ................................................................................................ 72 5.2.2.3. Tabla Fotos. ............................................................................................................ 73 5.2.2.4. Vista BusquedaUser. ............................................................................................ 73 5.2.2.5. Vista BusquedaUserId. ........................................................................................ 73 5.2.2.6. Tabla Tarjetas. ........................................................................................................ 74 5.2.3. Diagrama de estados. ............................................................................................. 75 5.3. Análisis de requisitos de infraestructuras. ............................................................ 75 5.3.1. Análisis de requisitos del servidor iiServer. ..................................................... 77 5.3.1.1. Características iiServer ....................................................................................... 77 5.3.1.2. Comunicaciones iiServer .................................................................................... 77 5.3.1.3. Aplicaciones iiServer ........................................................................................... 78 5.3.1.4. Mantenimiento de iiServer .................................................................................. 78 5.3.2. Análisis de requisitos de los puntos de emisión ............................................ 78 5.3.2.1. Requisitos de red y comunicaciones. ............................................................. 79 5.3.2.2. Equipamiento del punto de emisión. ............................................................... 79 6 Plataformas tecnológicas utilizadas en el desarrollo. ............................................ 81 6.1. Desarrollo servicios Web SOAP con NetBeans. ................................................... 82 6.2. Gestión de base de datos con TOAD. ...................................................................... 92 6.3. Montaje del servidor iiServer del proyecto. ........................................................... 97 6.3.1. Drivers VirtIO. ............................................................................................................ 98 6.4. Codificación de los servicios Web SOAP con NetBeans. ................................ 100 6.4.1. Codificación searchUsers. .................................................................................. 101 6.4.2. Codificación searchUsersById. .......................................................................... 103 6.4.3. Codificación sendIssuedCard. ........................................................................... 106 6.5. Pruebas. ......................................................................................................................... 108 6.6. Caso de éxito. ............................................................................................................... 108 6.6.1 Integración tarjetas y parking UMA. .................................................................. 109 6.6.2 Identificación iDUMA con carné universitario. ............................................... 110 6.6.2.1. Obtención certificado digital de FNMT. ......................................................... 111 7. Conclusiones. .................................................................................................................. 112 8. Bibliografía. ....................................................................................................................... 113
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 9 1. Introducción. La finalidad de este trabajo fin de grado es realizar un estudio y análisis de la interconexión de sistemas informáticos diferentes a través del desarrollo de Servicios Web SOAP, así como su aplicación en un proyecto concreto: la emisión instantánea de carnés UMA. Así como sentar las bases de todos los servicios de valor añadido que irán obteniendo los alumnos de la UMA a través de su carné UMA. El desarrollo tecnológico actual, ha propiciado que el diseño software tienda a ser cada vez más modular. Los servicios web son un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones diferentes, facilitando que distintas aplicaciones de sistemas de información distintos, desarrollados en lenguajes y entornos de programación diferente y ejecutada sobre cualquier plataforma, puedan utilizar los servicios web para intercambiar datos. SOAP es un protocolo para el intercambio de mensajes sobre redes y basado en XML. Los mensajes SOAP, son independientes del sistema operativo, y pueden transportarse en varios protocolos de internet como SMTO, MIME y HTTP. Tras la integración de la UMA en el programa Santander Universidades durante el curso académico 2008 / 2009, el Banco Santander empezó a fabricar los carnés de estudiantes de la UMA. Desde entonces, se viene realizando dicho proceso con la subida a la plataforma Nexusc, Sistema de gestión de Tarjetas Universitarias Inteligentes (TUI), de los ficheros de datos de los alumnos. Pero durante el curso académico 2015 / 2016, se plantea la necesidad de integrar a las universidades en el nuevo Sistema de Emisión Instantánea de carnés del Banco Santander. El nuevo Sistema de Emisión Instantánea del Banco Santander ha diseñado la integración entre sistemas informáticos diferentes a través de Servicios Web SOAP, proporcionando a las universidades los interfaces WSDL que deben cumplir dichos servicios web a desarrollar. El cumplimiento de estas interfaces debe ser estricto, para que después el Sistema de Emisión Instantánea pueda integrarse sin errores. Como caso práctico del estudio de este proyecto, se desarrollarán los servicios web necesarios para interconectar los sistemas de información de la UMA y del Banco Santander. El fin último de dicho proyecto, es la emisión instantánea y entrega a los alumnos del carné de la UMA cuando se matriculan. El trabajo está estructurado en 8 capítulos incluyendo las conclusiones generales y bibliografía consultada. En el capítulo 2 se explica la motivación del trabajo fin de grado y se exponen las futuras aplicaciones a las que pone la base este proyecto.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 16 Este tipo de situación de funcionalidad que debe ser expuesta como un servicio puede darse en sistemas legados o legacy systems, que por su importancia funcional no pueden ser reconstruidos. Sin embargo, deben ser usados en un escenario de interoperabilidad e integración con otros sistemas. 3.1.2. Aspectos de diseño de servicios software. La encapsulación de servicios a través de interfaces y su invocación transparente, usando protocolos interoperables, son los medios fundamentales para alcanzar una mayor flexibilidad y reutilización en el uso de una arquitectura de servicios. Servicios débilmente acoplados Una de las claves para entender el diseño de una arquitectura orientada a servicios es el concepto de acoplamiento, que funciona como una métrica de calidad de diseño y determina muchas de las propiedades de un buen diseño arquitectónico. Uno de los objetivos de todo diseño estructural de elementos interrelacionados es alcanzar el mínimo acoplamiento posible entre sus componentes. Siempre existirá un grado de acoplamiento entre módulos, aunque se persigue que este sea mínimo, para tratar de lograr el menor impacto directo en la mantenibilidad del futuro sistema. En general un módulo funcional está acoplado si los cambios internos en su implementación se propagan a otros módulos que interactúan con él. Cuando hablamos de cambios y acoplamientos nos referimos a aspectos de implementación interna. Tales como, un cambio de estructura de datos, de variables o de programación en el contexto de servicios de plataforma lenguaje de programación. Idealmente, un servicio se construye para que no exista acoplamiento de este tipo. El acoplamiento puede tener su origen en diversos aspectos. El objetivo de SOA es aislar a un servicio de siguientes aspectos: la plataforma (sistema operativo, hardware o lenguaje), el protocolo de comunicación, la localización del servicio, la identidad del servicio, la seguridad, la versión y el estado en la interacción. Esto permite diseñar unidades funcionales con un acoplamiento mínimo.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 17 La orientación a servicios persigue disminuir el acoplamiento entre las partes a partir de las definiciones de servicios, mediante una interfaz explícita y abstracta. Las interfaces abstractas además simplifican la interacción. Servicios software, clases y componentes software Las arquitecturas de servicios se basan en el concepto de unidades funcionales independientes, desacopladas y pensadas para ser reutilizables. Estas características también se encuentran en los componentes software. Según esto, es posible pensar que no existen diferencias significativas entre los componentes software y servicios software. Con todo esto, llegamos a la conclusión de que la realidad es que tanto los principios de diseño del paradigma de orientación a objetos como los del diseño basado en componentes son aplicables a un servicio.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 18 Sin embargo, un servicio software es distinto a un componente software. Las diferencias entre un enfoque orientado al servicio y un enfoque orientado a componentes son los siguientes: o Los servicios pueden ser ofrecidos por varios proveedores y un componte suele ser exclusivo de uno. o Los servicios están pensados para ser independientes respecto del contexto de ejecución. Esto implica que no deben definir interfaces requeridas por el entorno. o Los servicios software son independientes de la plataforma donde se ejecutan: sistema operativo, lenguaje de programación, etc. o Un servicio está diseñado para ser publicado, buscado y usado en tiempo de ejecución. o Es posible el reconocimiento dinámico de nuevos servicios. o El grado de desacoplamiento es mayor que el de los componentes. Aunque, como hemos visto, existen diferencias entre un servicio software y un componente, los servicios software comparten principios de diseño propios de los basados en componentes y orientados a objetos como el desacoplamiento, la definición de interfaces y el encapsulamiento de una funcionalidad y sus detalles internos. Los componentes por sus características de diseño (desacoplamiento, encapsulación, interfaces explicitas, unidades independiente) se pueden transformar en servicios. Servicios independientes
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 19 Existe una cuestión fundamental a la hora de diseñar servicios. Se trata de determinar si mantendrán algún tipo de información de estado en la interacción o no. Esta cuestión determinará gran parte del grado de acoplamiento que tendrá el servicio respecto a su interacción con otros componentes. En general, los servicios software se diseñan para ser sin estado. Es decir, los servicios a partir de los parámetros de entrada de su interfaz serán capaces de desarrollar el aspecto funcional para el que está diseñado, sin guardar internamente ninguna información de la interacción. Esto tiene la consecuencia de que el servicio ofrecerá un grado de acoplamiento menor, aumentando su potencial de reutilización. La clave para implementar con éxito la interacción sin estado se basa en: o El uso de tecnología que impida que una interacción sea retenida por una instancia particular. o El diseño de interfaces de servicio que no dependan de ningún tipo de conocimiento implícito, compartido y creado a través de una secuencia de interacciones entre un solicitante y un proveedor del servicio. La primera cuestión puede ser abordada fácilmente por protocolos que permiten comunicaciones asíncronas. Mecanismos para guardar información de sesión tales como cookies o tokens de sesión no deberían usarse. La segunda consideración solo puede ser alcanzada tomando estas restricciones como un principio de diseño. Tamaño del servicio Para referirse al término servicio se usa la palabra large granularity. Es un servicio que se concibe como un aspecto funcional grande, completo e independiente. Aunque normalmente los servicios se conciben como aspectos funcionales de alto nivel y de un tamaño funcional grande, nada impide que un servicio esté descrito por una única función de granularidad considerada pequeña. Existen diversos niveles de funcionalidad que podrían ser desarrollados por un servicio, siendo además un hecho lo difícil que es de precisar un nivel de funcionalidad o granularidad de diseño común. No se debe confundir un servicio software en SOA con SAAS (Software as a Service). SAAS es una forma que proporciona funcionalidad sobre un servidor remoto donde acceden múltiples clientes y donde el servicio ofrecido mantendrá largas transacciones y el estado de la interacción. Un servicio software en SOA se diseña de manera para soportar una interacción corta y sencilla, y sin guardar estado en la interacción
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 20 3.1.3. Características de los Servicios Web. Las características deseables de un Servicio Web son: o Un servicio debe poder ser accesible a través de la Web. Para ello debe utilizar protocolos de transporte estándares como HTTP, y codificar los mensajes en un lenguaje estándar que pueda conocer cualquier cliente que quiera utilizar el servicio. o Un servicio debe contener una descripción de sí mismo. De esta forma, una aplicación podrá saber cuál es la función de un determinado Servicio Web, y cuál es su interfaz, de manera que pueda ser utilizado de forma automática por cualquier aplicación, sin la intervención del usuario. o Debe poder ser localizado. Deberemos tener algún mecanismo que nos permita encontrar un Servicio Web que realice una determinada función. De esta forma tendremos la posibilidad de que una aplicación localice el servicio que necesite de forma automática, sin tener que conocerlo previamente el usuario. 3.2. Tipos de Servicios Web. A nivel técnico, los servicios pueden implementarse de varias formas, podemos distinguir dos tipos de servicios Web: SOAP y REST. 3.2.1. Servicios Web SOAP. Los servicios Web SOAP, Simple Object Access Protocol, utilizan mensajes XML para intercomunicarse que siguen el estándar SOAP, un lenguaje XML que define la arquitectura y formato de los mensajes. Dichos sistemas normalmente contienen una descripción legible por la máquina de la descripción de las operaciones ofrecidas por el servicio, escrita en WSDL (Web Services Description Language), que es un lenguaje basado en XML para definir las interfaces sintácticamente. El formato de mensaje SOAP y el lenguaje de definición de interfaces WSDL se ha extendido bastante, y muchas herramientas de desarrollo, por ejemplo NetBeans, JDeveloper o Eclipse, pueden reducir la complejidad de desarrollar aplicaciones de servicios Web. El diseño de un servicio basado en SOAP debe establecer un contrato formal para describir la interfaz que ofrece el servicio Web. WSDL puede utilizarse para describir los detalles del contrato, que pueden incluir mensajes, operaciones, bindings, y la localización del servicio Web. También deben tenerse en cuenta los requerimientos no funcionales, como por ejemplo las transacciones, necesidad de mantener el estado, seguridad y coordinación
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 21 3.2.2. Servicios Web REST. Los servicios Web REST (Representational State Transfer Web Services) son adecuados para escenarios de integración básicos ad-hoc. Dichos servicios Web se suelen integrar mejor con HTTP que los servicios basado en SOAP, ya que no requieren mensajes XML o definiciones del servicio en forma de fichero WSDL Los servicios Web REST utilizan estándares muy conocidos como HTTP, SML, URI, MIME, y tienen una infraestructura "ligera" que permite que los servicios se construyan utilizando herramientas de forma mínima. Gracias a ello, el desarrollo de servicios REST es barato y tiene muy pocas "barreras" para su adopción. REST, es un estilo de arquitectura de software dirigidos a sistemas hipermedias distribuidos como lo es la Web y se refiere específicamente a una colección de principios (los cuales resumen la forma en que los recursos son definidos y diseccionados) para el diseño de arquitecturas en red. Este término es utilizado en su mayoría para describir a cualquier interfaz que transmite datos específicos de un domino sobre HTTP sin una capa adicional, como lo hace SOAP, en tal sentido éstos dos significados pueden chocar o incluso solaparse. La arquitectura de REST tiene que cumplir con estos 6 principios. o Cliente-servidor Esta define que deben de estar separados el cliente del servidor a través de interfaces uniformes, es decir el cliente no sabe nada de cómo se almacena la información, ni como se está obteniendo. Por otro lado los servidores no saben la manera en la que se está presentado la información. o No manejan estado El servidor no debe de contener ningún contexto sobre el cliente que está haciendo la solicitud. La solicitud del cliente debe tener toda la información necesaria para poder procesar la solicitud en el servidor, esto permite crear aplicaciones más escalables sin que tener preocupación sobre cómo debe de responder el servidor a la perdida de la sesión del cliente por perdida de conectividad. o Capaces de almacenarse en caché En el WWW los clientes no tienen un mecanismo de almacenar las respuestas en caché. Las respuestas deben de estar implícitas o en su defecto explícitamente deben definirse a sí mismas como almacenables en caché o no, para evitar que los clientes hagan uso inapropiado de información regresada por una solicitud. o Sistemas en capas El cliente no debe de saber si está conectado directamente a un servidor final o a un intermediario. un servidor intermediario te puede ayudar a balancear las cargas y la escalabilidad de la aplicación. o Código bajo demanda Los servidores pueden ser capaces de extender la funcionalidad de un cliente transfiriéndole lógica que puedan ejecutar, por ejemplo Java Applets o JavaScript.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 22 o Interface Uniforme Son recursos individuales que deben de estar incluidos dentro de la solicitud. 3.3. Servicios Web SOAP y Java EE. Nos centraremos en los servicios Web SOAP desarrollados en Java, siendo componentes con las siguientes características: o Implementa los métodos de una interfaz descrita mediante un WSDL. Dichos métodos se implementan utilizando un EJB de sesión de tipo Stateless/Singleton o bien un componente web JAX-WS. o Un servicio Web puede tener publicada su interfaz en uno o más "registros" durante su despliegue. o La implementación de un Servicio Web, la cual utiliza solamente la funcionalidad descrita por su especificación, puede desplegarse en cualquier servidor de aplicaciones que cumple con las especificaciones Java EE. o Los servicios requeridos en tiempo de ejecución (run-time), tales como atributos de seguridad, se separan de la implementación del servicio. Se utilizarán herramientas adicionales que pueden definir dichos requerimientos durante el ensamblado o despliegue. o Un contenedor actúa como mediador para acceder al servicio La especificación de Java EE para servicios Web define una serie de relaciones arquitectónicas requeridas para dichos servicios, que se pueden observar en el siguiente esquema:
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 23 Arquitectura Java EE Se trata de relaciones lógicas que no imponen requerimiento alguno para el proveedor del contenedor sobre cómo estructurar los contenedores y los procesos. Como añadido para la plataforma Java EE se incluye un componente port que depende de la funcionalidad de contenedor proporcionada por los contenedores web y EJB, y del transporte SOAP/HTTP. Los servicios Web para Java EE requieren que un componente Port pueda ser referenciado desde un cliente, así como desde los contenedores web y EJB. No se requiere que haya un Port accesible desde un contenedor de applets. Los servicios Web para Java EE pueden implementarse de dos formas: como una clase Java que se ejecuta en un contenedor Web o como un EJB de sesión stateless o singleton en un contenedor EJB. El contenedor del servicio Web debe proporcionar la gestión del ciclo de vida de la implementación del servicio, además de proporcionar soporte adicional para la gestión de concurrencia de la invocación de los métodos del servicio, y soporte para la seguridad. 3.3.1. Arquitectura de servicios Web SOAP. Aunque un servicio software puede ser implementado de muchas formas y empleando diferentes tecnologías, son los denominados servicios web los que han conseguido hacer efectiva la arquitectura orientada a servicios.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 24 Los servicios web son un conjunto de especificaciones tecnológicas basadas en estándares abiertos como XML, URL y HTTP, y que proporcionan un modelo de interacción sistema a sistema. Sobre la base de este modelo estándar de interacción existen otras normas relacionadas dirigidas, por ejemplo, al control de transacciones, a la seguridad en las comunicaciones extremo a extremo y relacionadas con la definición de procesos empresariales. Estas funciones de alto nivel, transversales a muchos sistemas, son necesarias para hacer que procesos empresariales puedan interactuar entre sí. El modelo de interacción de servicios web básico define interacciones entre los solicitantes de servicios, proveedores de servicios y directorios de servicios. Los solicitantes de un Servicio podrían encontrar los servicios web disponibles en un servicio de directorio UDDI, que han sido publicados previamente por los proveedores de servicio. Desde este servicio recuperan las descripciones de la interfaz del servicio en formato WSDL. Después de que la descripción de la interfaz WSDL haya sido recuperada, el servicio solicitante se une al proveedor de servicios invocando los servicios a través del protocolo SOAP. La descripción general de los estándares que forman la base tecnológica de servicios web es la siguiente:
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 25 3.3.2. SOAP. Es un protocolo de intercambio de mensajes basado en XML, que permite la comunicación entre servicios web. Este protocolo es independiente de cualquier protocolo de transporte específico, pudiendo usar varios de forma transparente. Normalmente usaremos SOAP para conectarnos a un servicio e invocar métodos remotos, aunque puede ser utilizado de forma más genérica para enviar cualquier tipo de contenido. Podemos distinguir dos tipos de mensajes según su contenido: o Orientados al documento: Contienen cualquier tipo de contenido que queramos enviar entre aplicaciones. o Orientados a RPC: servirá para invocar procedimientos de forma remota (Remote Procedure Calls). Podemos verlo como un tipo más concreto dentro del tipo anterior, ya que en este caso como contenido del mensaje especificaremos el método que queremos invocar junto a los parámetros que le pasamos, y el servidor nos deberá devolver como respuesta un mensaje SOAP con el resultado de invocar el método. Puede ser utilizado sobre varios protocolos de transporte, aunque está especialmente diseñado para trabajar sobre HTTP. Dentro del mensaje SOAP podemos distinguir los siguientes elementos: o Un sobre (Envelope), que describe el mensaje, a quien va dirigido, y cómo debe ser procesado. El sobre incluye las definiciones de tipos que se usarán en el documento. Contiene una cabecera de forma opcional, y el cuerpo del mensaje. o Una cabecera (Header) opcional, donde podemos incluir información sobre el mensaje. Por ejemplo, podemos especificar si el mensaje es obligatorio (debe ser entendido de forma obligatoria por el destinatario), e indicar los actores (lugares por donde ha pasado el mensaje). o El cuerpo del mensaje (Body), que contiene el mensaje en sí. En el caso de los mensajes RPC se define una convención sobre cómo debe ser este contenido, en el que se especificará el método al que se invoca y los valores que se pasan como parámetros. Puede contener un error de forma opcional. o Un error (Fault) en el cuerpo del mensaje de forma opcional. Nos servirá para indicar en una respuesta SOAP que ha habido un error en el procesamiento del mensaje de petición que mandamos. o El anexo (Attachment) opcional, puede contener cualquier tipo de contenido (incluido el XML). De esta forma podremos enviar cualquier tipo de contenido junto a un mensaje SOAP, sea o no XML. Además, si es necesario, nuestro mensaje podrá tener tantos anexos como se
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 32 Componentes de Metro Con JAX-WS, una invocación de una operación a un servicio web se representa con un protocolo basado en XML, como por ejemplo SOAP. La especificación SOAP define la estructura del "envoltorio" (envelope) del mensaje, reglas de codificación, y convenciones para representar invocaciones y respuestas del servicio web. Estas llamadas y respuestas son transmitidas como mensajes SOAP (ficheros XML) a través de HTTP. Si bien los mensajes SOAP son complejos, la API JAX-WS oculta esta complejidad al desarrollador de la aplicación. En la parte del servidor, el desarrollador especifica las operaciones del servicio web definiendo métodos en una interfaz escrita en lenguaje Java. El desarrollador también codifica una o más clases que implementan dichos métodos. Los programas cliente también son fáciles de codificar. Un cliente crea un proxy (un objeto local que representa el servicio) y a continuación simplemente invoca los métodos sobre el proxy. Con JAX-WS, el desarrollador no necesita generar o "parsear" mensajes SOAP. El runtime de JAX-WS convierte las llamadas y respuestas del API en y desde los mensajes SOAP. La siguiente figura muestra la interacción entre un cliente y un servicio web a través de JAX-WS. Comunicación entre un servicio Web y un cliente a través de JAX-WS Metro (y consecuentemente, JAX-WS) está incluido en Glassfish 3.x por defecto, por lo que haremos uso de él para implementar nuestros Servicios Web y clientes correspondientes.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 33 3.5.1. Los Servicios desde la vista del Cliente. La vista del cliente de un servicio Web es bastante similar a la de un Enterprise JavaBean. Un cliente de un servicio Web puede ser otro servicio Web, un componente Java EE, incluyendo una aplicación cliente Java EE, o una aplicación Java arbitraria. Una aplicación no Java o un servicio Web para una aplicación no Java EE también podrían ser clientes de un Servicio Web. Como puede observarse, la vista del cliente de un servicio Web es proporcionada por el proveedor del componente Port y el contenedor en el que éste reside, incluyéndose la clase/interfaz Service (SI: Service Interface), y la interfaz del Endpoint del servicio (SEI: Service Endpoint Interface). Vista de un cliente de un servicio Web La clase/interfaz Service (SI) define los métodos que un cliente puede utilizar para acceder a un Port de un servicio Web. Un cliente NO crea o destruye un Port. Utiliza la clase/interfaz Service para obtener el acceso a un Port. La clase/interfaz Service se define en la especificación JAX-WS, pero su comportamiento viene definido en el documento WSDL proporcionado por el proveedor del servicio Web. Las herramientas de despliegue del contenedor proporcionan una implementación de los métodos de la clase/interfaz Service generada por JAX-WS. El cliente accede a una implementación de un servicio Web utilizando el SEI. Dicho SEI es especificado por el proveedor del servicio. Las herramientas del despliegue y el run-time del contenedor proporciona las clases en la parte del servidor que van a atender las peticiones SOAP sobre la implementación de dicho servicio de los métodos especificados en el SEI. Un Port no tiene identidad para el cliente, que lo debe considerar como un objeto sin estado. JAX-WS define un modelo de programación en el que se realiza un mapeado de un documento WSDL a Java. Dicho mapeado proporciona una factoría (Service) para seleccionar qué Port (agregado en el servicio) desea usar el cliente. La herramienta JAX-WS que proporciona las clases necesarias en la parte del cliente para poder acceder a un servicio web se denomina wsimport. En general, el transporte, codificación, y dirección del Port son transparentes para el cliente. El cliente solamente necesita realizar llamadas sobre la interfaz del endpoint del servicio (Service Endpoint Interface), utilizando el PortType correspondiente para acceder a dicho servicio.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 34 3.5.2. Los servicios Web desde la vista del Servidor. Un documento WSDL nos proporciona la interoperabilidad de los servicios Web e incluye la especificación sobre requerimientos de transporte y formato de los datos a través de la red. En general, un WSDL no impone ningún requerimiento sobre el modelo de programación del cliente o del servidor. La especificación de servicios Web para Java EE (JSR-109) define tres formas de implementar la lógica de negocio de servicio Web: o Como un Bean de Sesión sin estado: la implementación del servicio Web (componente Port) se realiza creando un Bean de sesión sin estado, que implementa los métodos del SEI (Service Endpoint Interface) tal y como se describe en la especificación de EJB 3.0. o Como una clase Java: en este caso se implementa el Port como un Servlet JAX-WS. o Como un Singleton Session Bean: en este caso se crea un singleton session bean que implementa los métodos de un SEI según la especificación de EJB 3.1 Un componente Port define la vista del servidor de un Servicio Web. Cada Port proporciona un servicio en una dirección física particular definida por el atributo address de la definición <port> de un WSDL. Un componente Port "sirve" una petición de operación definida en un <portType> de un WSDL. La implementación del servicio (Service Implementation Bean) depende del contenedor del componente Port, pero en general es una clase Java que puede implementar los métodos definidos en el SEI (Service Endpoint Interface). El SEI es un mapeado java del <portType> y <binding> asociado a un <port> de un WSDL. Un servicio Web es un conjunto de Ports que difieren únicamente en su dirección física, y son mapeados en componentes Port separados, cada uno con su potencialmente único, pero probablemente compartido, Service Implementation Bean. La siguiente figura muestra la vista del servidor de un Servicio Web. Vista del servidor de un servicio Web El ciclo de vida del Port está completamente controlado por el contenedor, pero
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 35 en general sigue el mismo ciclo de vida que el del propio contenedor. Un Port es creado e inicializado por el contenedor antes de que la primera llamada recibida en la dirección del <port> del WSDL sea servida. Un Port es destruido por el contenedor cuando éste considera que sea necesario hacerlo, como por ejemplo cuando el propio contenedor es sutting down. Una implementación de un servicio Web JAX-WS reside en un contenedor Web, y por lo tanto puede desplegarse en un servidor Web o un servidor de aplicaciones, una implementación EJB, en cambio, reside en un contenedor EJB y sólo podrá desplegarse en un servidor de aplicaciones. Un componente Port asocia una dirección de puerto (port address de un WSDL) con la implementación del servicio (Service Implementation Bean). En general, el componente Port "pospone" la definición de los requerimientos del contenedor del servicio a la fase de despliegue, indicando dichos requerimientos en el descriptor de despliegue del componente. Un contenedor proporciona un listener en la dirección del puerto (port address de un WSDL) y un mecanismo para "enviar" la petición a la implementación del servicio Web. Un contenedor también proporciona servicios en tiempo de ejecución, tales como restricciones de seguridad y mapeados de referencias lógicas a referencias físicas de objetos distribuidos y recursos. Un desarrollador declara un componente Port en un descriptor de despliegue de servicios Web. El descriptor de despliegue incluye el documento WSDL que describe el PortType y binding del servicio Web. Cuando se usa JAX-WS, no es necesario proporcionar dicho descriptor de despliegue. La mayor parte de la información del descriptor de despliegue se incluye en las anotaciones de la implementación del servicio. Podríamos utilizar el descriptor de despliegue para "sobreescribir" o mejorar la información proporcionada por las anotaciones de la implementación del servicio. La plataforma Java EE 6, soporta las siguientes implementaciones de servicios Web: como un componente Web JAX-WS en un contenedor de Servlets, y como un componente EJB de sesión stateless o singleton. El empaquetado de un servicio Web en un módulo Java EE es específico de la metodología de implementación, pero sigue los requerimientos para un fichero EJB-JAR o fichero WAR. Contiene los ficheros de clases java del SEI y los documentos WSDL del servicio Web. Además contiene el descriptor XML de despliegue que define los Ports del servicio y su estructura. El modelo de programación JAX-WS Para desarrollar una implementación de un servicio web (web service endpoint) podemos optar por dos puntos de partida: una clase Java que implementa el servicio Web o un fichero WSDL. Cuando comenzamos por una clase java, utilizaremos herramientas para generar los artefactos necesarios, entre ellos el WSDL del servicio. Cuando nuestro punto de partida es un fichero WSDL (junto con los ficheros de esquema que describen los tipos de datos usados en el servicio), utilizaremos herramientas para generar el SEI (Service Endpoint Interface)
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 36 JAX-WS impone la existencia de un Service Implementation Bean anotado con javax.jws.WebService en un componente Port. Como ya hemos indicado en el apartado anterior, la implementación del servicio (Service Implementation Bean) va a depender del contenedor del componente Port, pero en general es una clase Java que puede implementar los métodos definidos en el SEI (Service Endpoint Interface). Si comenzamos por una clase java, tendremos la seguridad de que la clase que implementa el servicio tiene los tipos de datos java adecuados, pero el desarrollador tiene menos control sobre el esquema XML generado. Si comenzamos por el WSDL y esquemas, el desarrollador tiene un control total sobre qué esquema se está usando, pero menos control sobre el endpoint del servicio generado y de las clases que utiliza. Cuando nuestro punto de partida es una clase java, tenemos que seguir ciertas restricciones en la implementación de nuestro servicio. Una implementación válida de un servicio web es una clase java que cumple las siguientes restricciones: o La clase debe estar anotada con javax.jws.Webservice (o alternativamente con javax.xml.ws.Provider, si se desea trabajar directamente a nivel de mensajes XML) o Podemos anotar cualquiera de sus métodos con javax.jws.WebMethod o Todos sus métodos pueden lanzar la excepción java.rmi.RemoteException además de cualquier otra excepción propia del servicio. o Los parámetros de sus métodos y tipos de retorno deben ser compatible con JAXB (JAXB impone unas reglas para mapear tipos java con tipos de ficheros de esquema XML) o Ningún parámetro y/o tipo de retorno pueden implementar la interfaz java.rmi.Remote ni directa ni indirectamente. La clase java anotada con @WebService define un SEI de forma implícita por lo que no será necesario proporcionar dicha interfaz. Podemos especificar de forma explícita una interfaz añadiendo el atributo endpointInterface a la anotación @WebService. En ese caso, sí es necesario proporcionar la interfaz que defina los métodos públicos disponibles en la clase que implementa el servicio. Una implementación de un servicio Web que utiliza la anotación @WebService no es necesario que especifique la ubicación del WSDL. Si se utiliza el atributo wsdlLocation en la anotación @WebService, el fichero WSDL debe ser empaquetado junto con las clases java del servicio web. Creación de servicios a partir del WSDL Hemos visto cómo crear con NetBeans servicios web a partir de código Java que ya tenemos implementado. Esta es la forma más inmediata de crear servicios web, sin embargo, si lo que buscamos es una alta interoperabilidad, no resulta la forma más adecuada de hacerlo. Podría darnos problemas sobre todo en el caso
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 37 en que nuestras operaciones intercambien tipos de datos complejos, ya que podríamos tener problemas al intentar recomponer dichos tipos desde clientes de diferentes plataformas. Lo fundamental en un servicio web SOAP es el contrato que existe entre cliente y servicio, es decir, el documento WSDL. Por lo tanto, a la hora de crear servicios web complejos es recomendable empezar definiendo dicho contrato. De esta forma tendremos mayor control sobre los datos que se serializan durante la invocación del servicio, con lo que podremos definir las estructuras de datos que consideremos más adecuadas para el intercambio. Una vez definido el contrato (WSDL), generaremos a partir de él el esqueleto para la implementación del servicio que cumpla con dicho contrato. Creamos el WSDL y fichero de esquema En NetBeans podremos generar un servicio web a partir de un documento WSDL de forma sencilla. Lo primero que deberemos hacer es escribir el documento WSDL, y el esquema asociado que definirá nuestro servicio. Ya hemos visto cómo hacer esto en la sesión anterior. Recordemos que tenemos que pinchar con el botón derecho sobre nuestro proyecto y seleccionar New > Other .... Nos aparecerá la ventana para crear un nuevo fichero, y dentro de ella seleccionaremos la categoría XML y el tipo XML Schema (para el fichero de esquema), y WSDL Document, para el documento WSDL. Al continuar con el asistente, podremos introducir los datos básicos del documento WSDL , como su nombre, espacio de nombres, puertos, operaciones, mensajes, tipo de codificación, nombre del servicio, etc. Una vez hayamos terminado de escribir el documento WSDL que actuará como contrato de nuestro servicio, deberemos crear nuestro servicio web. Para crear un servicio web que se ajuste a dicho contrato pincharemos con el botón derecho sobre nuestro proyecto y seleccionaremos New > Web Service from WSDL.... Tras rellenar todos los datos del asistente se generarán una serie de clases con el esqueleto de la implementación de nuestro servicio y los tipos de datos necesarios. Ahora deberemos rellenar el código de cada operación del servicio para darle su funcionalidad, y con esto habremos terminado de implementar nuestro servicio. 3.5.3. NetBeans y ficheros WSDL. Saber "leer" y/o crear un fichero WSDL es importante para trabajar con servicios Web SOAP. NetBIOS permite trabajar de forma sencilla con ficheros WSDL. XML Schema es una recomendación del W3C, que proporciona mecanismos para definir la estructura, contenido y semántica de un documento XML. Un fichero WSDL utiliza el "lenguaje de esquemas" (XML Schema) para definir los tipos de datos y/o elementos utilizados por las operaciones de un servicio Web. El bloque de construcción principal de un documento XML es element. La definición de un elemento element debe contener una propiedad name, que representa su nombre, y una propiedad type para indicar el tipo de elemento.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 38 Podemos utilizar alguno de los tipos predefinidos (built-in types), por ejemplo xs:string, xs:integer, o bien podemos definir nuevos tipos utilizando etiquetas simpleType o complexType. NetBIOS nos permite crear ficheros WSDL de forma "visual", simplificando de forma significativa el proceso de edición de la especificación WSDL de nuestro servicio web. Los servicios Web SOAP tienen una serie de métodos a los que se llama mediante RPC desde cualquier lugar de Internet, por eso mismo debemos poder interpretar en nuestras aplicaciones los mensajes SOAP entrantes de petición para la invocación de un método. Después invocaremos el método solicitado, y con el resultado que nos devuelva, construimos un mensaje SOAP de respuesta y devolvérselo al cliente. Si tuviésemos que introducir nosotros el código para interpretar este mensaje de entrada, y generar manualmente el mensaje de respuesta, el desarrollo de Servicios Web sería una tarea altamente costosa. Es más, si se forzase al programador a componer el mensaje SOAP manualmente cada vez que desarrolle un Servicio Web, es muy probable que cometa algún error y no respete exactamente el estándar SOAP. Esto sería un grave problema para la interoperabilidad de los Servicios Web, que es una de las características que perseguimos con esta tecnología. Para evitar estos problemas, se utilizan librerías que permiten leer o generar mensajes SOAP para la invocación de métodos remotos, como es el caso de la API JAX-WS. Además, para facilitar aún más la tarea de desarrollar Servicios Web, normalmente contaremos con herramientas que a partir de las clases que implementan nuestro servicio generen automáticamente todo el código necesario para leer el mensaje SOAP de entrada, invocar el método, escribir el mensaje SOAP de salida, y devolverlo al cliente. De esta manera, logramos centrarnos únicamente en la tarea de programar la funcionalidad que implementan nuestros servicios, olvidándonos del mecanismo de invocación de éstos. 3.6. Composición de servicios y SOA. Podemos distinguir en una arquitectura SOA las siguientes capas de software: o Aplicaciones básicas: Son aquellos sistemas que se han desarrollado bajo cualquier tecnología, en cualquier lugar e independiente del autor de las mismas. o De exposición de funcionalidades: Son aquellas aplicaciones cuyas
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 39 funcionalidades son expuestas en forma de servicios (los llamados Servicios Web). o De integración de servicios: Son aquellos sistemas que facilitan el intercambio de datos entre procesos empresariales internos o en colaboración. o De composición de procesos: Aquellas aplicaciones que definen el proceso en términos de negocio y sus necesidades y que varían dependiendo de cuál sea dicho negocio. o De entrega: Son aquellos sistemas en los cuales los diferentes servicios se despliegan directamente a los usuarios finales. La arquitectura orientada a servicios permite la creación de sistemas que son altamente escalables y que reflejan de manera realista el negocio de la empresa, añadiendo además una manera clara de exposición e invocación de servicios web, lo cual facilita la interacción entre los diferentes sistemas existentes, ya sean propios o ajenos. Con la arquitectura SOA se obtiene una metodología y un marco de trabajo en el cual se pueden documentar las capacidades de negocio y dar soporte, además, a las actividades de integración y consolidación. Algunos beneficios que tiene adoptar esta arquitectura son: o Mejora en los tiempos de realización de cambios en los procesos o Facilidad para evolucionar a modelos de negocio basados en terceros o Facilidad para abordar modelos de negocio basados en colaboración con otras entidades o Poder para reemplazar elementos de la arquitectura SOA sin interrupción del proceso de negocio o Facilidad de integración de tecnologías diferentes. A diferencia de las llamadas arquitecturas orientadas a objetos, las arquitecturas SOA están formadas por servicios de aplicación débilmente acoplados y altamente interoperables, que para comunicarse se basan en una definición formal independiente de la plataforma y del lenguaje de programación. La interfaz encapsula las particularidades de la implementación, haciéndola por tanto independiente del fabricante, del lenguaje de programación o de la tecnología de desarrollo empleada. Así los componentes software desarrollados son muy reutilizables, ya que la interfaz se define siguiendo un estándar.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 40 3.6.1. Breve Introducción a la Composición de Servicios. En algunos casos los requerimientos de información planteados por el usuario no son alcanzados a través de un simple Servicio Web; entonces se hace necesario combinar varios de ellos para generar un servicio que pueda satisfacer los objetivos del usuario. La Composición de Servicios es una aplicación de la Web Semántica y las tecnologías de planificación automática que describe la manera de enlazar los diferentes servicios Web. Nace de la necesidad de disponer de metodologías que permitan desarrollar sistemas orientados a servicios y la dificultad de utilizar los Servicios Web en las etapas más tempranas de su desarrollo. Con base en los fundamentos de la programación orientada a servicios (SOC) y su arquitectura (donde se emplean los servicios web como los elementos fundamentales), se identifican posibles roles que los servicios web juegan dentro del proceso de composición. Tales roles pueden ser un repositorio de servicios, un servicio ejecutor de servicios o un planificador, dependiendo de la funcionalidad que se le desee proveer al servicio web para llevar a cabo un propósito en común. Distintas tecnologías han aportado soluciones a la Composición de Servicios Web, entre ellas se encuentran los Sistemas Multiagente (SMA), los cuales gracias a sus características de modularidad y distribución de funcionalidades entre nodos de red pueden acoger fácilmente los roles presentes en un proceso de Composición de Servicios Web. Para poder realizar la composición de servicios es necesario que el middleware de los servicios Web soporten la composición; la tecnología empleada es muy similar a la que se utiliza en los sistemas Workflow y se denomina “Business Process Execution Language for Web Services”, más conocido como BPEL. El proceso de ejecución debe soportar tanto los servicios simples como compuestos. Los trabajos realizados en la Composición de Servicios Web básicamente enfocan sus esfuerzos en tres áreas del conocimiento, que son, vía procesos de negocios, planificación en IA y síntesis de Programas. Se pueden distinguir dos maneras diferentes de combinar los distintos servicios, de los cuales hablaremos más adelante con mayor profundidad; estas dos formas se denominan orquestación y coreografía. La composición de servicios puede contener los dos tipos a la vez. Tanto en la orquestación como en la coreografía la secuencia de ejecución se determina en alguno de los archivos de los servicios. A esto se le denominan formas estáticas de composición, a diferencia de las dinámicas, que también pueden utilizarse para componer servicios, y en las que no está determinada la secuencia de ejecución completa de antemano. En este tipo de servicios, si la descripción de los mismos contiene su semántica de manera que pueda ser procesada por las máquinas, el propio proceso podría
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 41 decidir qué servicio invoca después de que haya comenzado. En el proceso de Composición de Servicios Web, se pueden distinguir dos pasos generales, que materializan un requerimiento de usuario: o La identificación de los requerimientos del usuario por medio de un método por el cual se pueda generar un plan o flujo de actividades o La selección de los Servicios Web para su posterior ejecución y monitoreo. A continuación se puede ver un gráfico que ejemplifica un framework de un sistema de composición de servicios. 3.6.2. Orquestación vs. Coreografía. Dentro de la composición de servicios se pueden distinguir diferentes aspectos. Orquestación y coreografía son dos aproximaciones que definen la composición de servicios, pero que no son lo mismo. Orquestación: Genéricamente, se entiende por Orquestación como el estudio y práctica de ordenar la música para una orquesta; básicamente, orquestación es decidir qué instrumentos deben tocar qué notas en una pieza de música. Coreografía: se define como la ordenación y el movimiento de los bailarines en un determinado escenario; sencillamente consiste en decidir cómo debe efectuarse el movimiento al ritmo de la música. Aplicado a los servicios Web, la Orquestación describe un proceso ejecutable que puede interactuar con servicios propios o ajenos; el flujo del proceso está controlado por un coordinador central y cada servicio tiene solamente conocimiento local y puede tomar decisiones solo para procesos propios. La orquestación se refiere a la habilidad para conectar servicios Web entre sí para dar lugar a procesos de negocio de alto nivel. Se centra en la composición de nuevos servicios a partir de otros ya existentes y nos proporciona una manera
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 48 producto, para que el product owner pudiera ir viendo los avances de la integración de los sistemas planteadas. Además del desarrollo de los servicios web, la integración de sistemas estuvo coordinada por dos otros dos equipos de especialistas del Servicio Central de Informática. Un equipo de dos especialistas del área de ATDI, que se encargó de montar el servidor iiServer en una máquina virtual Y otro equipo de dos especialistas del área de sistemas, que realizó todo lo concerniente a permisos y configuración de firewall, limitando desde las IP que tenían acceso, los servicios web del sistema desplegados en iiServer. Ambos equipos cumpliendo con los requisitos del product owner al respecto. Gracias a la metodología SCRUM, desde el principio de la fase de desarrollo se buscó la calidad del resultado, primando el desarrollo ágil y las entregas de productos parciales, dejando de un lado el intercambio de documentación para centrarnos en la obtención de resultados. Los procesos que se identificaron para abarcar el desarrollo del proyecto fueron: Estudio servicios Web SOAP. Estudio interfaz WSDL de servicios WEB. Análisis requisitos Sistema Emisión Instantánea. Creación y configuración iiServer. Seguridad a nivel de red para el Sistema Emisión Instantánea. Ajustes modelo de datos del sistema. Servicio Web búsqueda usuarios. Servicios Web usuario seleccionado. Servicio Web tarjeta impresa. Instalación de los diferentes puntos de emisión del sistema. Despliegue y testeo de servicios web en preproducción. Despliegue y testeo de servicios web en producción. Puesta en producción de la integración de sistemas realizada. Acceso a iDUMA con carné UMA.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 49 Pasando todos por las diferentes fases de desarrollo software en Scrum: TO DO, DOING y DONE TO DO DOING DONE despliegue pro ws selección usuario Estudio ws SOAP. puesta en producción ws tarjeta impresa Estudio interfaz WSDL Acceso a iDUMA con carné UMA. Modelo de datos Análisis requisitos Sistema iiServer Seguridad a nivel de red ws búsqueda de usuario despliegue prepro Puntos de emisión estado de la pizarra Scrum en un momento dado del proyecto 4.1. Metodología Scrum. Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 50 En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales. Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto. El proceso. En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones que normalmente son de 2 semanas, aunque en algunos equipos son de 3 y hasta 4 semanas, límite máximo de feedback y reflexión). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite. El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 51 Las actividades que se llevan a cabo en Scrum son las siguientes: o Planificación de la iteración: El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene dos partes: Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos más prioritarios que se compromete a completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de la iteración necesarias para desarrollar los requisitos a que se ha comprometido. La estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se autoasignan las tareas. o Ejecución de la iteración: Cada día el equipo realiza una reunión de sincronización (15 minutos máximos). Cada miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunión cada miembro del equipo responde a tres preguntas: ¿Qué he hecho desde la última reunión de sincronización? ¿Qué voy a hacer a partir de este momento? ¿Qué impedimentos tengo o voy a tener? Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad. Elimina los obstáculos que el equipo no puede resolver por sí mismo. Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad. Durante la iteración, el cliente junto con el equipo refinan la lista de requisitos (para prepararlos para las siguientes iteraciones) y, si es necesario, cambian o replanifican los objetivos del proyecto para maximizar la utilidad de lo que se desarrolla y el retorno de inversión. o Inspección y adaptación: El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos partes: Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo esfuerzo. En función de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteración, replanificando el proyecto. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargará de ir eliminando los obstáculos identificados.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 52 5. Análisis de la interconexión de sistemas planteados. El sistema desarrollado se sostiene sobre varios puntos claves que pasamos a analizar. 5.1 Análisis de servicios Web SOAP del sistema. La interconexión de los sistemas de información de la UMA y de emisión instantánea del Banco Santander, se sustentarán en el funcionamiento de los servicios Web SOAP que deben interconectar ambos sistemas de información. Dichos servicios web han sido especificados a través de sus correspondientes ficheros WSDL. El cumplimiento de las especificaciones de dichos ficheros debe ser estricto para que ambos sistemas puedan integrarse sin errores. Los servicios web a desarrollar se dividen en la búsqueda de alumnos, la petición de datos del alumno seleccionado para hacer la impresión de su carné y el envío de los datos de la tarjeta impresa a los sistemas de Información de la UMA. En concreto los servicios web son: searchUsers: servicio web que busca un usuario o un conjunto de usuarios en el sistema de información la UMA. Es utilizado en el proceso de emisión de carnés para localizar el usuario concreto al cual queremos emitir una tarjeta, ya sean alumnos, profesores y/o personal de administración y servicios. No obstante, en la primera fase de integración de los sistemas, sólo nos centraremos en el colectivo de alumnos de la UMA. searchUserById: servicio web que solicita los datos para poder emitir y personalizar un carné de la UMA a un usuario concreto. Sirve para recuperar todos los datos que serán utilizados en la personalización y grabación de su tarjeta inteligente. sendIssuedCard: servicio web que es invocado cada vez que se emite una tarjeta inteligente. Sirve para notificar a la UMA los datos de los carnés que son emitidos de cada usuario. Todo está preparado para que los servicios web puedan trabajar directamente identificando a los usuarios a través de iDUMA, pero actualmente la integración total del Sistema de Emisión de carnés con iDUMA no es posible, porque iDUMA no contiene de toda la información necesaria para el correcto funcionamiento de los servicios web. La identificación contra iDUMA está planificada como obligatoria hoy en día para cualquier servicio montado en la UMA, pero todavía hay trasvase de información que no se ha realizado porque se está planificando y analizando que datos son
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 53 los necesarios que deben llevarse a IDUMA, por ello la información del colectivo de alumnos de la UMA no está al 100% en iDUMA. Por todo ello, todos los servicios web se han desarrollado para que accedan a la base de datos Oracle que gestiona los sistemas de información de los alumnos de la UMA. Para los servicios web searchUsers y searchUserById, habrá que diseñar las vistas de consulta de datos de los alumnos del proyecto. Para el servicio web sendIssuedCard, se deberá crear una tabla en la que almacenar los datos de los carnés emitidos de cada usuario. 5.1.1. Consultas de usuarios - searchUsers. El sistema de emisión instantánea accederá en tiempo real a los datos de personalización utilizando los servicios web de consulta de usuarios. Con éste mecanismo se garantiza a la UMA un control total sobre los usuarios a los cuales se entrega una tarjeta universitaria inteligente TUI, y los datos utilizados en la personalización. La consulta de usuarios se realiza con dos funciones de búsquedas distintas para recuperar información. Estos dos métodos se describen a continuación, en las siguientes secciones. Búsqueda del usuario - searchUsers: Función que busca un usuario o un conjunto de usuarios en el sistema de información de la UMA. Es utilizada en el proceso de emisión para localizar el usuario concreto al cual queremos emitir una tarjeta. La búsqueda se hace por una combinación de “Documento de identidad” y “Nombre y Apellidos”. De esta forma el operador del Banco Santander puede localizar a un usuario por su DNI, por su Pasaporte o utilizando algún apellido del usuario en cuestión. El método de búsqueda recibe un único parámetro de entrada. Es una cadena de texto y se corresponde con la información introducida por el operador del Banco Santander en la iiTablet para buscar al alumno, PAS o PDI, que solicita la tarjeta. En la primera fase del proyecto, sólo se buscan alumnos de la UMA. Al recibir éste método, el servicio web desarrollado implementa una búsqueda de usuarios en el sistema de información de la UMA, utilizando el campo de
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 54 búsqueda data, y después retorna una lista de usuarios localizados. A la hora de implementar la búsqueda se tuvo en cuenta: o El listado devuelve siempre cualquier alumno que coincida con el criterio de búsqueda. Aunque ya tenga tarjeta entregada, no haya completado la matrícula, o no tenga derecho a ella. El control de todas estas situaciones se realiza en otro método distinto. Es importante que funcione así, para evitar incidencias cuando el operador del Banco no encuentre a un usuario en la iiTablet: si no se encuentra al usuario, debe ser porque realmente no existe, y no porque no tenga derecho a tarjeta. De esta manera, se reduce considerablemente el nivel de incidencias por no localización de usuarios. o Si el campo data enviado es vacío o nulo, se retorna una lista de usuarios vacía. De esta forma en la iiTablet del operador del Banco Santander se mostrará un mensaje indicando que afine la búsqueda. o Si en la búsqueda no se produce ninguna coincidencia, se debe retornar una lista vacía. En ningún caso se debe retornar una excepción. De esta forma en la iiTablet del operador del Banco Santander se mostrará un mensaje indicando que afine la búsqueda. o La función de búsqueda podría devolver muchos usuarios (por ejemplo si usamos un apellido muy común). Por esta razón, se decidió restringir el tamaño de la lista de usuarios resultante a 10 usuarios. De esta forma evitamos un retardo en el intercambio de información con la iiTablet. o En la búsqueda, se tiene en cuenta que el parámetro data puede tener caracteres especiales (acentos, tildes, diéresis, cedillas, etc.), por lo que se desarrolló ignorando estos caracteres especiales a la hora de hacer consultas en el sistema de información de la UMA. o La lista de usuarios retornada en éste método, no contiene datos sobre personalización de la tarjeta. Esta lista que es retornada a la iiTablet, se utiliza para informar al operador del Banco Santander de los usuarios que coinciden con el campo de búsqueda. Después el operador debe seleccionar uno de los usuarios de la lista, y en ese momento se invocará otro método distinto. o La información que debe retornarse para cada usuario de la lista es la siguiente: Nombre y apellidos (fullname): Texto con el nombre y apellido(s) juntos. Número de documento (document): Número de documento o pasaporte. ID del usuario (externalId): Identificador unívoco del usuario dentro del sistema de información de la UMA. Se eligió un identificador único de la tabla de alumnos. o Para notificar errores graves inesperados se puede lanzar cualquier excepción (Soap Fault) sin que sea necesario especificar ningún tipo en concreto. El servicio de emisión capturará las excepciones inesperadas y
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 55 mostrará un mensaje al operador del Banco Santander indicando que debe contactar con el Soporte Técnico. Un ejemplo de intercambio XML mediante SOAP en una búsqueda de usuarios: o Búsqueda de alumno por DNI.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 56 o Búsqueda de alumno por apellido. 5.1.2. Selección del usuario a emitir tarjeta - •searchUserById. Selección del usuario concreto a emitir tarjeta: Función que solicita los datos para poder emitir y personalizar una TUI a un usuario concreto de la UMA. Sirve para recuperar todos los datos que serán utilizados en la personalización y grabación de su tarjeta inteligente. Este método sólo acepta un parámetro de entrada. Es el identificador interno y unívoco del usuario, con el cual el Sistema de Información de la UMA debe buscarlo. Este parámetro se corresponde con el campo recibido externalId en el método de búsqueda del apartado anterior. Es decir, cuando el operador busca un usuario en la iiTablet, se invoca el método searchUsers y el servicio web retorna una lista de usuarios. Después esa lista de usuarios es mostrada en la iiTablet, y el operador del Banco Santander debe seleccionar uno de ellos para pedir sus datos completos. Al pulsar sobre un usuario de la lista, se invoca el método searchUserById utilizando el ID del usuario que fue retornado en el listado inicial.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 57 Por tanto, al recibir éste método, se ha implementado una búsqueda de los datos del usuario mediante el ID. Los datos, que se retornan mediante el objeto UserData, son los siguientes: o Los mismos datos que en la búsqueda inicial: Nombre y apellidos (fullname): Texto con el nombre y apellido(s) juntos. Número de documento (document): Número de documento o pasaporte. ID del usuario (externalId): Identificador unívoco del usuario. o Todos los datos que serán utilizados para la personalización de la tarjeta. Estos datos se almacenan en el objeto UserData, dentro de una estructura con formato de mapa (Clave– Valor) que se llama content. La estructura content es un mapa de valores abierto, que permite a la UMA especificar sus propios datos de personalización en la tarjeta. El mapa de valores para la estructura content de la UMA es: nya: Nombre y apellidos que son mostrados en el anverso de la tarjeta. Tiene un tamaño máximo de 26 caracteres, ya que si es mayor, será truncado. Además se retorna mayúsculas. linea1: Categoría (Estudiante/PAS/PDI) y número de identificación (Expediente, DNI). Debe tener un tamaño máximo de 40 caracteres y estar en mayúsculas. codbar: Código de barras único de cada usuario de la UMA, que se corresponde con la acreditación única que se tiene en la UMA y comienza por 061, dicho código de barras irá impreso en el reverso del carné. nia: Número de Identificación Académica. Es el número de expediente con el cual se identifica al alumno dentro de la universidad. Debe tener un tamaño máximo de 12 caracteres. documento: Documento de identificación con letra (NIF) o pasaporte. Debe tener un tamaño máximo de 9 caracteres. categoría: Código de la categoría del usuario (alumno, PAS, PDI, etc.). Es un número comprendido entre 1 y 99 cuya utilización depende de la UMA. centro: Código del centro de trabajo o estudios asociado al usuario.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 64 servicio de emisión capturará las excepciones inesperadas y las registrará para enviar una alarma al departamento de Soporte Técnico. A continuación se muestra un ejemplo de intercambio XML mediante SOAP en la notificación de una nueva tarjeta emitida: o Envío de los datos de una tarjeta emitida. El proceso de envío de tarjetas se hace en segundo plano, y nunca se notifican errores a los usuarios o al operador del Banco Santander. En caso de producirse algún error cuando la UMA incorpora los datos de la tarjeta en su sistema, y si lanza una excepción para indicar que hubo un problema, este excepción nunca se propaga a los usuarios finales. El error es registrado en el sistema de emisión instantánea del Banco Santander y desde el soporte técnico informarían a la UMA de que se ha producido un error para que se solucione. Además, el sistema de gestión de emisión instantánea permite volver a enviar a la universidad, a través de éste servicio web, los datos emitidos de una o un conjunto de tarjetas cualesquiera. Con todas estas medidas se garantiza que no se producirá ninguna pérdida de datos.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 65 5.1.4. Objetos para el intercambio de datos. A continuación paso a describir, en lenguaje Java, cómo son los objetos que he debido manejar cuando trabaje con los servicios web que se han desarrollado. o UserData: Objeto para almacenar información del usuario. Los datos del usuario se encapsulan en un objeto UserData que tiene la siguiente estructura. o CardData: Objeto para almacenar información de la tarjeta. Los datos de la tarjeta se encapsulan en un objeto CardData que tiene la siguiente estructura.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 66 5.1.5. Seguridad y despliegue de los Servicios Web. Los servicios web desarrollados por la UMA para este proyecto deben desplegar, tanto el endpoint (la implementación) que contiene el servicio, como el WSDL que lo describe, manteniendo el nombre del esquema de los servicios web debe mantenerse como, ya que si hubieran sido cambiados, los clientes de los servicios web del sistema de emisión instantánea no funcionarían, pues están compilados p ara utilizar éste esquema. Se incluyó seguridad en el acceso a los servicios web para que los servicios no puedan ser consultados o accedidos por ningún tercero, solo por la APP instalada en las iiTablet del sistema de Emisión Instantánea del Banco Santander a través del iiServer del sistema. Para ello se aplicó las siguientes medidas de seguridad: o Publicación HTTPS: Los servicios web fueron ser publicados mediante HTTPS. De ésta forma se garantiza que los datos viajen encriptados. o Restricción mediante IP: se incluyó una regla a los firewall de la UMA para que los servicios web sean restringidos en acceso a una sola DNS creada para dicho propósito para el proyecto. Los servicios web de integración son consultados de forma centralizada únicamente por el servidor central de emisión instantánea llamado iiServer. Por tanto, se puede securizar y
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 67 restringir esa conexión de forma muy sencilla con ésta técnica, sin necesidad de medidas adicionales. 5.1.6. Tratamiento de errores y excepciones. Otro aspecto importante en los servicios web es la posibilidad de utilizar excepciones, principalmente en el servicio web de consulta de usuarios. Cuando el sistema de emisión instantánea recibe una excepción, intenta extraer el mensaje de la misma, y lo muestra directamente en la iiTablet. De ésta forma, si un operador del Banco Santander realiza una búsqueda (ya sea el primer filtrado, o la búsqueda de un usuario concreto) y se produce una excepción, se le mostrará un mensaje indicando el error, y muy importante, en el mensaje hay que darle instrucciones de cómo debe proceder. Para el envío de excepciones utilizaremos las estructuras de excepciones definidas en el interfaz. El mensaje que se muestra en la iiTablet se corresponde con el atributo “message” de estas dos excepciones. o UserNotAllowedException se utiliza para indicar que el usuario no tiene derecho a tarjeta, por la razón que sea oportuna (no está en el colectivo adecuado, tiene demasiadas tarjetas emitidas, etc.). Esta es la excepción controlada que con más frecuencia se utilizan los servicios web desarrollados en el proyecto. La excepción tiene un atributo llamado “message” que permite especificar un texto, el cual será transmitido a la iiTablet para su visualización. o UserNotFoundException se utiliza cuando el usuario no es localizado en el sistema de información de la UMA. o Errores inesperados: en lenguajes como Java o .NET podemos lanzar cualquier tipo de excepción para indicar un error inesperado. Por ejemplo, excepciones de caída de la base de datos de la UMA, un error interno de programación, etc. Las librerías que permiten utilizar los servicios web se encargan automáticamente de transformar esa excepción en una Soap Fault, que será enviada al servicio de emisión. Ejemplo de código en lenguaje Java para error controlado:
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 68 Es importante tener en cuenta que en la iiTablet se mostrará el mismo texto que contiene la excepción. Por tanto, es importante que el mensaje de error sea “orientado al usuario de la aplicación”. Es decir, adaptados al operador del Banco Santander encargado de manejar la iiTablet y emitir tarjetas a los usuarios de la universidad. 5.2. Análisis de diferentes modelos. 5.2.1. Casos de Uso. En el presente capítulo se describen los diagramas de los principales casos de uso del sistema. Los mismos muestran la relación entre los actores y los casos de uso descritos. Se identificaron dos actores principales: o Usuario: Actor genérico que interactúa con el sistema para obtener un resultado concreto. En este caso específico, interactúa a través de las iiTablet a través de la APP del sistema de Emisión Instantánea de carnés. o Desarrollador: Desarrolla los servicios web y gestiona la infraestructura necesaria para que la integración de los sistemas de información de la UMA y el Banco Santander sean todo un éxito y no hay incidencias de mal funcionamiento durante la puesta en producción del proyecto.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 69 Caso de uso Buscar usuarios Actor usuario iiTablet Propósito Obtener listado de usuarios en el sistema de información la UMA. Es utilizado para localizar el usuario concreto al cual queremos emitir una tarjeta Caso de uso Seleccionar usuario Actor usuario iiTablet Propósito Obtener los datos para poder emitir y personalizar un carné de la UMA a un usuario concreto, que serán utilizados en la personalización y grabación de su tarjeta inteligente. Caso de uso solicitar carné UMA Actor usuario iiTablet Propósito Tras confirmar datos y foto, ya sea la que tenga la UMA o una nueva que se tome ad hoc, se manda a imprimir el carné UMA del usuario, tras lo cual, se notifica a la UMA los datos del carné que ha sido impreso al usuario.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 70 Caso de uso Gestionar modelo de datos Actor Desarrollador Propósito Crear las tablas y vistas necesarias en el sistema de base de datos de la UMA, para atender a los servicios web del sistema desarrollado, así como su posterior utilización en otros servicios de valor añadido de la UMA. Caso de uso Desarrollar servicios web Actor Desarrollador Propósito Desarrollar los servicios web SOAP de la UMA que deben integrarse en el sistema de emisión instantánea del Banco Santander Caso de uso Gestionar infraestructura Actor Desarrollador Propósito Crear el servidor iiServer así como solicitar los ajustes de red necesarios para el correcto funcionamiento del sistema de emisión instantánea dentro de la red informática de la UMA y su sistema de emisión instantánea.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 71 5.2.2. Diagrama de base de datos.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 72 5.2.2.1. Tabla Alumnos. Almacena los datos de los alumnos del sistema de base de datos de la UMA. Tabla ya existente en la base de datos Oracle de ordenación académica de los sistemas de información de la UMA. cod int identificador único autoincremental di varchar documento identificador: DNI, NIE, pasaporte, etc acre varchar código de barras universitario: 061123121X nombre varchar nombre del alumno ape1 varchar primer apellido del alumno ape2 varchar segundo apellido del alumno fnac date fecha de nacimiento movil varchar móvil del alumno email varchar correo electrónico 5.2.2.2. Tabla Expedientes. Almacena los datos de todos los expedientes de los alumnos del sistema de base de datos de la UMA. Tabla ya existente en la base de datos Oracle de ordenación académica de los sistemas de información de la UMA. cod number identificador único autoincremental num_exp number número de expediente único cod_alu number código único del alumno del expediente nota number nota del expediente fecha date fecha de estado del expediente estado varchar estado del expediente
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 73 5.2.2.3. Tabla Fotos. Almacena las fotos de todos los usuarios de la UMA. Sólo tiene una foto por usuario, asegurando que es la última foto aportada por el usuario. Tabla ya existente en la base de datos Oracle de ordenación académica de los sistemas de información de la UMA. di number documento identificador: DNI, NIE, pasaporte, etc acre number código de barras universitario: 061123121X foto blob foto binaria en formato jpg del usuario fecha date fecha de la foto 5.2.2.4. Vista BusquedaUser. Vista utilizada para localizar a los usuarios de la UMA, ya sea filtrando por documento identificador o nombre del usuario. cod number identificador único autoincremental di varchar documento identificador: DNI, NIE, pasaporte, etc fullname varchar nombre del alumno 5.2.2.5. Vista BusquedaUserId. Vista utilizada para proporcionar al sistema los datos de un usuario concreto al que se le va a hacer el carné. cod number identificador único autoincremental di varchar documento identificador: DNI, NIE, pasaporte, etc acre varchar código de barras universitario: 061123121X fullname varchar nombre completo del alumno foto varchar última foto binaria en formato jpg del usuario que tiene registrada en la UMA centro varchar centro del usuario estudios varchar estudios que está cursando el alumno
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 80 Incluye cargador y cable de datos USB. Funda protectora de silicona. Funda de transporte semi-rígida. o Otros materiales. Cable de conexión Ethernet RJ 5. Regletas eléctricas.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 81 6 Plataformas tecnológicas utilizadas en el desarrollo. Tras valorar los posibles IDE con los que realizar los servicios Web SOAP, por su funcionalidad y facilidad de uso, me decanté por el IDE de NetBeans para desarrollar el código de las diferentes funcionalidades de los servicios Web del proyecto. NetBeans es un entorno de desarrollo integrado libre, hecho principalmente para el lenguaje de programación Java. Existe además un número importante de módulos para extenderlo. NetBeans IDE2 es un producto libre y gratuito sin restricciones de uso. La plataforma NetBeans permite que las aplicaciones sean desarrolladas a partir de un conjunto de componentes de software llamados módulos. Un módulo es un archivo Java que contiene clases de java escritas para interactuar con las APIs de NetBeans y un archivo especial (manifest file) que lo identifica como módulo. Las aplicaciones construidas a partir de módulos pueden ser extendidas agregándole nuevos módulos. Debido a que los módulos pueden ser desarrollados independientemente, las aplicaciones basadas en la plataforma NetBeans pueden ser extendidas fácilmente por otros desarrolladores de software. Modularidad. Todas las funciones del IDE son provistas por módulos. Cada módulo provee una función bien definida, tales como el soporte de Java, edición, o soporte para el sistema de control de versiones. NetBeans contiene todos los módulos necesarios para el desarrollo de aplicaciones Java en una sola descarga, permitiéndole al usuario comenzar a trabajar inmediatamente. Algunas de las características del IDE de NetBeans son: o Gestión de la interfaz de usuario ( menús y barras de herramientas ) o Gestión de configuración de usuario o Gestión de almacenamiento (guardar o cargar algún tipo de dato) o Gestión de ventana o Marco Asistente (soporta diálogos para a paso) o Librería visual de NetBeans o Herramientas de desarrollo integrado o NetBeans IDE es libre, código abierto, multiplataforma con soporte integrado para el lenguaje de programación Java. Para la gestión de la base de datos Oracle con la que vamos a trabajar en el desarrollo de los servicios Web SOAP para el sistema de Emisión Instantánea de carnés de la UMA, vamos a hacer uso de la aplicación TOAD. TOAD, Tool for Oracle Application Developers, es una aplicación informática de desarrollo SQL y administración de base de datos, considerada una herramienta útil para los Oracle DBAs (administradores de base de datos). Actualmente está
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 82 disponible para las siguientes bases de datos: Oracle Database, Microsoft SQL Server, IBM DB2, y MySQL. 6.1. Desarrollo servicios Web SOAP con NetBeans. Lo primero fue instalar el IDE elegido, que lo descargué desde la web oficial del IDE (netbeans.org/downloads/), decantándome por la versión completa, para así tener que evitar la posterior descarga de módulos adicionales que pudieran ser necesarios. Una vez descargado el fichero de instalación, se procede a su ejecución hasta completar la instalación completa del IDE.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 83 Inicio de la instalación
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 84 Selección de carpeta de instalación
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 85 Tras completar la instalación del IDE, abrimos el entorno de desarrollo e iniciamos un proyecto, como vamos a desarrollar servicios web SOAP, lo que necesitaremos es crear un nuevo proyecto web, al que llamaremos umaCard.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 86 Debido a que se van a desarrollar un conjunto de servicios web para la interconexión de sistemas de información diferentes, la clase de proyecto a crear a través del IDE NetBeans, debe ser un proyecto java web.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 87 Asignamos un nombre al proyecto
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 88 Una vez que NetBeans nos ha generado el proyecto java web, el siguiente paso a realizar será crear en dicho proyecto los servicios web necesarios a través de los ficheros WSDL planteados en el Sistema de Emisión Instantánea de carnés. Para ello, nos situamos sobre el proyecto y clicando con el botón derecho del ratón, seleccionamos en el menú contextual la opción de Nuevo y Web Services from WSDL.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 89 Seleccionamos nuevo Servicio Web desde WSDL
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 96 Posteriormente, nos vamos a la ventana de edición directa de código SQL para lanzar el código de creación de vistas, asignando los permisos de consulta al usuario de la aplicación.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 97 6.3. Montaje del servidor iiServer del proyecto. Los "ocones" son las máquinas preparadas en la UMA sobre las que se montarán las máquinas virtuales con el software open source qemu. En el servicio ATDI de la UMA, hay disponibles varias máquinas en tres ocones, ocon1.sci.uma.es, ocon2.sci.uma.es, ocon3.sci.uma.es, y ocon4.sci.uma.es. Además, tenemos un Windows 2008 R2, sin activar, que nos sirve de base para replicar los servidores Windows que se necesiten a través del siguiente el proceso: 1. Solicité al área de sistemas que me replicara ese Windows 2008 R2 en una máquina virtual en un ocón y le asignara un puerto por donde conectarme por VNC. 2. Una vez que el área de sistemas ha completó el proceso anterior y me informó de ello, me conecté a la máquina por VNC. Windows no estaba activado, pero antes de activarlo y configurar la red debemos cambiar el SID del sistema operativo, para ello abrí una ventana de comando e hice: a. Ejecutar desde cmd: c:\windows\system32\sysprep\sysprep.exe b. Dejamos OOBE, para que cuando reinicie pregunte idioma, etc. c. Marcamos GENERALIZE, para que genere un nuevo SID 3. Cuando reinicie la máquina ya se puede configurar la IP, proxy (proxy.gestion.uma.es:3128), nombre netBIOS, activar RDesktop, etc. y sobre todo activar el producto. 4. Posteriormente, tenemos agregar la máquina a nuestro dominio a. Dominio: servicios.uma.es b. IP DNS: 192.168.92.3 5. El disco duro se queda en 15 Gb en vez de los 50 Gb que necesitamos para el iiServer, por lo que tenemos que extender la partición, para ello abrimos una ventana de comando y ejecutamos: a. c:\>diskpart b. diskpart> list volume c. Seleccionamos el volumen a extender, en mi caso el de 50 Gb es el volumen 4 d. diskpart> select volume 4 e. diskpart> extend f. diskpart> exit 6. Después debemos agregar los drivers de VirtIO 7. Una vez llegado a este punto, ya podemos utilizar la máquina para trabajar como iiServer.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 98 6.3.1. Drivers VirtIO. Para optimizar la Entrada/Salida de las máquinas virtuales con Windows 2008 R2 vamos a utilizar los drivers VirtIO, disponibles para Red, Almacenamiento (discos) y Gestión de Memoria (soportando ballooning). Instalando estos drivers pasamos de trabajar con dispositivos emulados por los Ocones a drivers que son capaces de 'hablar directamente' con el hardware de los Ocones. Debemos tener montada la imagen ISO con los drivers VirtIO en la máquina virtual, o por otro medio. 1. Agregamos nuevo Hardware Heredado en Administrador de Dispositivos (botón derecho sobre el nombre de la máquina) a. Agregamos Adaptador de Red usando disco ( se busca en ../Win7/amd64 para 64 bits, o en ../Win7/x86 para 32 bits ) -> Se añade el dispositivo Red Hat VirtIO Ethernet Adapter). b. Agregamos Controladores de Almacenamiento usando disco (se busca en ../Win7/amd64 para 64 bits, o en ../Win7/x86 para 32 bits). Se deben añadir 2, por seguridad, Red Hat VirtIO SCSI Controller v16.x.xx.xxx y v61.x.xx.xxx. Por ahora, al presentarle el disco tipo VirtIO ha cogido la versión v61.x.xx.xxx, pero no está de más que tenga ambas versiones. 2. Actualizamos drivers a. Actualizamos el controlador del dispositivo del sistema Controladora PCI de RAM estándar, haciendo que busque en disco ( se busca en ../Win7/amd64 ). b. Se sustituirá ese dispositivo por VirtIO Balloon Driver.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 99 Agregar hardware virtual Memoria
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 100 Balloon driver Una vez hecho esto, es cuando hay que 'presentar' los dispositivos VirtIO a la máquina virtual. 6.4. Codificación de los servicios Web SOAP con NetBeans. Llegados a este punto, ya disponemos en el sistema del modelo de datos necesario para el desarrollo y los servicios web SOAP, por lo que nos disponemos a entrar en NetBeans para codificar la funcionalidad de los distintos servicios web que debemos desarrollar. Dichos servicios web han de trabajar conectándose de forma inicial a la base de datos del sistema de información de la UMA, para posteriormente procesar el parámetro de entrada o parámetros de entrada obtenido, lanzar la consulta SQL que cada servicio web precise y procesar la información resultante. El código fuente del desarrollo, junto con toda la estructura de los ficheros de los servicios web desarrollados, puede descargarse desde el siguiente enlace: https://app.box.com/s/6p9rkye1squ2pzwtdfoo5mirnjd5p3k9
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 101 6.4.1. Codificación searchUsers. Seleccionamos en el explorador de ficheros de NetBeans el servicio web para iniciar su desarrollo. En la codificación del servicio web, le primer fue la comprobación de que la invocación del servicio no se realizar con el envío de un parámetro vació. Para lo cual, primero preparamos una lista del objeto UserData en la que retornar el resultado del servicio web al sistema de emisión instantánea y luego comprobamos que el parámetro enviado no se encuentre vacío, si fuera este el caso, aquí se terminaría el funcionamiento del servicio web, retornando la lista del objeto recién creada que se encuentra en su estado vacío. Si la ejecución continua es porque el parámetro enviado no iba vacío, por lo que debemos preparar la conexión con la base de datos.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 102 Una vez ejecutada la conexión de la base de datos, preparamos la consulta SQL, limitándola a un máximo de 10 registros, sabiendo que si en el primer envío de resultados el operador no localiza al alumno, deberá refinar la búsqueda y enviar un parámetro más específico que el inicial. Al ejecutar la consulta, debemos recorrer la colección de resultados e ir mapeándolo en el objeto userData que iremos añadiendo a la lista de respuesta creada inicialmente. Además, usamos un flag para asegurarnos que el retorno del servicio web no es una lista vacía porque la consulta SQL tuviera algún registro que mostrar. Finalmente, tras recorrer toda la colección de resultados de la consulta SQL, cerramos la conexión con la base de datos, comprobamos si hay por lo menos una fila de resultados que enviar (si no la hay, lanzamos la excepción al sistema), para finalizar enviando la lista de objetos userData con los resultados obtenidos en la consulta a base de datos que hemos tratado.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 103 6.4.2. Codificación searchUsersById. Seleccionamos en el explorador de ficheros de NetBeans el servicio web para iniciar su desarrollo. A diferencia del servicio web anterior, en la codificación de la funcionalidad de searchUsersById no debo preocuparme de comprobar si el argumento de entrada viene vacío, ya que dicha comprobación se realiza desde la APP del sistema de emisión instantánea, que sólo invocará al servicio web de un usuario concreto que haya sido seleccionado en la APP. Por todo lo anterior, lo único que debemos hacer al inicio de este servicio web es preparar la estructura de objetos con los que voy a contesta a la petición que ha llegado. Posteriormente, habilitamos la conexión con la base de datos.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 104 Y antes de ponernos a ejecutar la consulta SQL que me devuelva los datos del usuario seleccionado, debo comprobar que para dicho usuario no hayan sido impresas ya dos tarjetas universitarias. Si se da el caso de que para el alumno seleccionado ya han sido impresos dos carnés, se informa de ellos y se da por terminada la ejecución del servicio web. Por el contrario, si todavía el usuario tiene derecho a obtener una nueva tarjeta universitaria, pues deberemos preparar la consulta SQL que nos permita preparar la información del usuario que ha solicitado el carné. Tras la ejecución de la consulta SQL en la base de datos, vamos añadiendo los datos extraídos en los objetos preparados inicialmente, para su posterior retorno a la APP del sistema de emisión instantánea a través del servicio web. Además, antes de la inclusión de los datos en los objetos, debemos tratar la foto del usuario, convirtiéndola a una cadena de texto en base 64, para poder enviarla en el objeto del sistema.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 105 Una vez tenemos todos los datos preparados, los asignamos a la estructura de objetos creada inicialmente, para su posterior envío al sistema de emisión instantánea. Terminamos cerrando la conexión con la base de datos y devolviendo el objeto userData que contiene la información solicitada por el sistema.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 112 7. Conclusiones. SOAP permite a los diseñadores encapsular la complejidad del sistema, dando lugar a interfaces generadas automáticamente que permiten facilitar el diseño del sistema. Lo interesante de SOAP es que permite utilizar lenguajes de alto nivel para llamar y para implementar el servicio. Dado un fichero WSDL, los IDE actuales facilitan enormemente la tarea de programación de los servicios Web necesarios para la interconexión de sistemas informáticos diferentes. Lográndose un desarrollo rápido, limpio y eficaz. Como ejemplo de este estudio, hemos visto cómo se realizó el desarrollo de los servicios web necesarios para interconectar los sistemas de información de la UMA y el Banco Santander. Para lo cual me decidí por desarrollar los servicios web en NetBIOS que es un IDE o Entorno de Desarrollo Integrado libre, hecho principalmente para el lenguaje de programación Java. Existe además un número importante de módulos para extenderlo y es gratuito sin restricciones de uso. NetBIOS es un proyecto de código abierto de gran éxito con una gran base de usuarios, una comunidad en constante crecimiento, que permite que las aplicaciones sean desarrolladas a partir de un conjunto de componentes de software llamados módulos. Me gustaría recordar que una Arquitectura Orientada a Servicios (SOA) es una arquitectura que define cómo interoperan funciones de negocios independientes implementados por sistemas autónomos para ejecutar un proceso de negocios. El diseño Web tiende a ser cada vez más modular y las aplicaciones se componen de una serie de componentes reutilizables, que pueden encontrarse distribuidos a lo largo de una serie de máquinas conectadas en red. Los Servicios Web nos permiten distribuir nuestra aplicación a través de Internet, definiendo como clave la interoperatibilidad entre las aplicaciones. Hoy en día, la mayoría de las empresas disponen de sistemas de información independientes, que ofrecen y consumen servicios en internet, logrando conectar opciones de negocio implementadas en sistemas de información muy diferentes entre sí. Pero el principal beneficio de los servicios web SOAP recae en ser fuertemente acoplado, lo que permite poder ser testado y depurado antes de poner en marcha la aplicación, lográndose un desarrollo ágil y efectivo. SOAP ha demostrado ser fácil de utilizar, con una depuración simple, donde las operaciones complejas pueden ser escondidas detrás de una fachada simple, incrementando la privacidad. Además de que gracias a los IDE, como hemos demostrado con NetBeans, el desarrollo de servicios web SOAP a partir de ficheros WSDL, es muy sencillo y rápido.
TFG Ingeniería de Computadores | José Carlos Bustamante Toledo 113 8. Bibliografía. Programación Java Server con J2EE Edición 1.3 (Anaya Multimedia/Wrox) de Subrahmanyam Allamaraju, Cedric Beust, John Davies, Tyler Jewell, Rod Johnson, Andrew Longshaw, Ramesh Nagappan, Alex Toussaint, Sammer Tyagi, Gary Watson, Mark Wilcox, Alan Willianson y Daniel O’Connor. Revisión de los Servicios Web SOAP/REST - www.albertolsa.com/wpcontent/uploads/2009/07/mdsw-revision-de-los-servicios-web-soap_restalberto-los-santos.pdf Unraveling the Web services web: an introduction to SOAP, WSDL, and UDDI por Curbera, F; Duftler, M; Khalaf, R; Nagy, W; Mukhi, N; Weerawarana, S. – 0ieeexplore.ieee.org.jabega.uma.es/xpls/icp.jsp?arnumber=991449 Debate entre servicios web basados en REST y SOAP - carlosmayta.blogspot.com.es/ Scrum - proyectosagiles.org/que-es-scrum/ Guía Breve de Servicios Web - www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb Web Services Description Language (WSDL) - www.w3.org/TR/wsdl20primer/ Introduction to Web Services - netbeans.org/kb/docs/websvc/introws.html Scrum: metodologías ágiles - www.javiergarzas.com/metodologiasagiles