extensión de los modelos uml para el diseño...

98 CITEG Revista Arbitrada. Año I. N°2. Julio - Diciembre 2007

Extensión de los Modelos UML para el Diseño Conceptual de Sistemas de Web Services basado en la Componente de Seguridad WS-SecurityMauricio Paletta

Extensión de los Modelos UML para el Diseño Conceptual de Sistemas de Web Services basado en la Componente de Seguridad WS-SecurityMauricio PalettaDepartamento de Ciencia y Tecnología. Universidad Nacional Experimental de [email protected]

RESUMENEn los últimos años se ha venido observando un creciente interés en el desarrollo de aplicaciones prácticas basadas en la tecnología de SOA (de sus siglas en inglés Service-Oriented Architecture), específicamente Web Services. El desarrollo de este tipo de aplicaciones requiere de una técnica sólida de modelado que tome en cuenta todos los elementos necesarios requeridos por este tipo de sistemas, en particular aquellos que están relacionados con la seguridad. Por otro lado, UML (de sus siglas en inglés Unified Modeling Language) se ha convertido en uno de los estándares más utilizados en la actualidad para el modelaje de sistemas de software. Suena lógico entonces combinar estas dos tecnologías para definir una técnica de modelado de Web Services basado en UML. Si bien hay diversas propuestas que toman en consideración esta relación, ninguna de ellas toca el tema relacionado con la seguridad, muy importante a la hora de desarrollar un Web Service. En este artículo se hace una revisión de los trabajos previos en el modelado de Web Services basado en UML y se presenta una propuesta de extensión de UML que considera el aspecto de seguridad basado en la tecnología WS-Security.

Palabras claves: UML, SOA, Web Service, WS-Security.

ABSTRACTExtension of UML models for the Design of Web Service Systems Based on the WS-Security Component

A growing interest in the practical applications of the Service-Oriented Architecture (SOA) technology, specifically Web Services, has been observed in recent years. A solid modeling technique, which takes into account all required elements, particularly those related to security, is necessary to develop this type of applications. UML (Unified Modeling Language), on the other hand, has become one of the most used standards for software systems modeling; it is therefore logical to combine these two technologies to define a UML based modeling technique for Web Service systems. Even though there are some different approaches that take this relationship into account, none of them is related to security, which is very important in the development of Web Service systems. This paper summarizes a review of previous works related to Web Service systems modeling based on UML and describes a proposal of extending UML in order to consider the security aspect associated with the WS-Security technology.

Keywords: UML, SOA, Web Service, WS-Security.

Artículo recibido el 25 de Octubre de 2007 y aceptado en su versión final el 13 de Noviembre de 2007

99CITEG Revista Arbitrada. Año I. N°2. Julio - Diciembre 2007, pp. 98 - 112


I. INTRODUCCIÓN

Sin lugar a dudas, los servicios son uno de los elementos de mayor importancia en el alcance de los sistemas de información Web (WIS - de sus siglas en inglés Web Information Systems). Una de las ideas centrales de este enfoque es concebir las aplicaciones como un conjunto de servicios disponibles en la Web. En este sentido, la tecnología de Web Services busca convertirse en la nueva manera de implementar aplicaciones de la Web y han tenido un gran impacto en la forma como se desarrollan productos de software hoy en día.

Sin embargo, no hay una base metodológica sólida para el desarrollo de los sistemas orientados a servicios (SOA - de sus siglas en inglés Service-Oriented Architecture), en particular los Web Services. Dado que esta tecnología parece estar consolidada adecuadamente, es importante ahora tomar en consideración la forma como estos sistemas pueden ser modelados para facilitar la implementación de los mismos, específicamente tener la capacidad de generar de forma automática el código necesario. Por esta razón, se requieren de nuevos métodos o técnicas de modelaje para garantizar la calidad de estos sistemas.

Por otro lado, UML [16] (de sus siglas en inglés Unified Modeling Language) se ha convertido en uno de los estándares más utilizados en la actualidad para el modelaje de sistemas de software. Permite a los creadores de sistemas generar diseños que capturen sus ideas en una forma convencional y fácil de comprender para comunicarlas a otras personas [21].

Mediante la definición de los llamados “perfiles UML” («UML profiles»), es posible adaptar el lenguaje de UML para ser usado en un contexto de modelaje particular. El caso de los Web Services no es una excepción, por lo que UML provee un «framework» que puede ser aplicado

adecuadamente para el desarrollo de estos sistemas.

Hacer modelos UML de la arquitectura de un Web Service permite hacer revisiones y discusiones del diseño conceptual en niveles altos de abstracción, independientemente de la forma como se haga la implementación, enfocándose en aspectos de relevancia como por ejemplo la consistencia de los servicios. Según Heckel y compañía [11], los lenguajes de modelado visuales de alto nivel como UML tienen ventajas importantes con respecto a los lenguajes de especificaciones de bajo nivel usados para implementar los Web Services, específicamente porque están basados en XML [25] (de sus siglas en inglés extensible Markup Language). Entre otras cosas, permiten una mejor abstracción de los detalles de implementación y ofrecen una mejor comprensión.

Si bien hay varios autores que han considerado en sus propuestas de modelado el uso de UML para el desarrollo de un Web Service [24], ninguna de estas propuestas toca el tema relacionado con la seguridad. Dado que los Web Services están disponibles en la Web, la seguridad cobra un papel importante a la hora de desarrollar este tipo de sistemas. En este artículo se hace una revisión de los trabajos previos en el modelado de Web Services basado en UML y se presenta una propuesta de extensión de UML que considera el aspecto de seguridad basado en la tecnología WS-Security. Aspectos conceptuales de las tecnologías de UML y Web Service son mostrados brevemente en la siguiente sección.

II. DESARROLLO

1. UML y la Tecnología de Web Services

UML es un lenguaje de notación visual para el modelado de sistemas, específicamente de software. Como lenguaje, contiene un



vocabulario (sintaxis) y reglas (semántica) que se enfoca en la representación conceptual y física bajo el principio de la orientación a objetos. UML es además un estándar avalado por la OMG [15] (de sus siglas en inglés Object Management Group). Este lenguaje se puede descomponer en 4 partes [21].

1) Vistas. Muestra diferentes aspectos del sistema que se está modelando; permite enlazar el modelo al proceso escogido para el desarrollo.

2) Diagramas. Gráficas que describen el contenido de una vista.

3) Elementos del modelo. Son los conceptos usados en los diagramas, asociados comúnmente a conceptos de la orientación a objetos: clase, objeto, mensaje, etc.

4) Mecanismos generales. Proveen comentarios, información u otros extras a los elementos del modelo.

Basado en los aspectos del sistema a modelar, se identifican 5 posibles vistas.

1) Vista de casos de uso. Muestra la funcionalidad del sistema tal como es percibida por los actores externos.

2) Vista lógica. Muestra cómo la funcionalidad está diseñada dentro del sistema, en términos de las estructuras estáticas y el comportamiento dinámico.

3) Vista de componentes. Muestra la organización de los componentes de código para construir el sistema.

4) Vista de concurrencia. Muestra la concurrencia (comunicación y sincronización) en el sistema.

5) Vista de despliegue. Muestra el despliegue o distribución del sistema en la arquitectura física (computadoras y otros dispositivos).

Distribuidos en las vistas anteriores se tiene un total de 9 tipos de diagramas.

1) Diagrama de casos de uso. Describe lo que un nuevo sistema debe hacer o lo que un sistema existente hace en término de los requerimientos y funcionalidades.

2) Diagrama de actividades. Son usados para mostrar el flujo de las actividades del sistema.

3) Diagrama de clases. Describe el modelo estático de un sistema en términos de sus clases y las relaciones entre ellas.

4) Diagrama de objetos. Representa la aso-ciación y relaciones entre objetos.

5) Diagramas de estados. Representa el comportamiento del sistema en el tiempo.

6) Diagrama de colaboración. Muestra la interacción entre objetos mediante el intercambio de mensajes que ocurre entre ellos.

7) Diagrama de secuencias. Similar al diagrama de colaboración pero haciendo énfasis en la línea de tiempo u orden secuencial en la cual ocurren los mensajes.

8) Diagrama de componentes. Permite modelar la estructura del software, incluyendo depen-dencias entre componentes en código fuente, componentes en código binario y componentes ejecutables.

9) Diagrama de distribución. Modela la distribución en tiempo de ejecución de los elementos de procesamiento y componentes de software, procesos y objetos asociados.

Los mecanismos generales de UML, cuyo objetivo principal es el de incrementar las capacidades semánticas de representación, se pueden resumir en las siguientes categorías.

1) Valores etiquetados. Son propiedades asociadas a los elementos de UML en forma de etiquetas. Permiten agregar semántica extra a los elementos asociados. También son usados para agregar información administrativa sobre el progreso o estado de un proyecto.

2) Restricciones. Reglas que restringen la semántica de uno o más elementos de UML. También llamadas condiciones semánticas



3) Estereotipos. Representa una semántica asociada a un elemento existente. Se pueden ver como un tipo de especialización del elemento. Es una extensión de la semántica pero no de la estructura del elemento.

Por otro lado, Web Services representa un conjunto de tecnologías que permite a las aplicaciones comunicarse entre sí a través de Internet [7]. Técnicamente hablando, Web Services son componentes funcionales disponibles en Internet y descritos mediante documentos escritos en WSDL [26] (de sus siglas en inglés Web Service Definition Language). Un documento WSDL describe la interfaz de un Web Service como uno o más tipos de puertos («port types»), cada uno de los cuales contiene un conjunto de operaciones («operations») con sus mensajes («messages») de entrada y salida correspondientes. Cuando una operación sólo tiene un mensaje de salida se dice que es una “notificación” («notification»); cuando es sólo un mensaje de entrada entonces se dice que es una operación de una sola vía («one-way»). La Fig. 1 muestra un diagrama de clases UML con los componentes que forman un WSDL [19].

Figura 1. Componentes de un WSDL (Provost, 2003)

Al igual que ocurre con la mayoría de los lenguajes inmersos en la tecnología Web y con todos los que se utilizan en la tecnología de Web Services, WSDL es un lenguaje XML. En este mismo orden de ideas, la estructura y sub-elementos requeridos para armar un WSDL son definidos en un documento XML Schema

correspondiente [25]. El XML Schema es una alternativa basada en XML para describir los tipos de elementos y la estructura usados en un documento XML específico, también llamado DTD (de sus siglas en inglés Document Type Definition). WXS (de sus siglas W3C XML Schema) es el término genérico con el cual se identifica a los documentos XML Schema.

Es importante resaltar que el área de investigación de los Web Services contempla dos aspectos que deben ser modelados: el servicio y el flujo de control. El primero identifica los servicios a ser expuestos con sus interfaces y operaciones mientras que el modelado de flujos identifica los flujos de control y data que van desde un servicio a otro. Para Heckel y compañía [11], esta división de la arquitectura de un Web Service se identifica como una parte estructural para la descripción de los servicios y sus interfaces y una parte de comportamiento para el protocolo de interacción de cada servicio con sus socios.

En lo que respecta al modelado de servicios o parte estática de la arquitectura de un Web Service, el estándar que se utiliza es WSDL. Para el modelado de flujos o parte dinámica, las propuestas de lenguajes de especificación más usadas son WSCI [27] (de sus siglas en inglés Web Services Choreography Interface) y BPEL4WS [12] (de sus siglas en inglés Business Process Execution Language for Web Services). Ambos proveen una notación XML y una semántica para especificar comportamientos del proceso de negocio basados en Web Services describiendo el flujo de control y de mensajes entre los Web Services y otros servicios.

Un último concepto a mencionar involucrado en la tecnología Web Services es el de SOAP [29] (de sus siglas en inglés Simple Object Access Protocol). Se trata de un conjunto de convenciones y reglas, basados en XML, que especifican el formato de mensajes y la forma como estos son procesados. Un mensaje SOAP



consiste de un sobre SOAP que contiene 0 o más encabezados SOAP y un cuerpo SOAP que alberga el contenido del mensaje, como por ejemplo, el requerimiento de un servicio.

Figura 2. Modelo de negocio de un Web Service (Armstrong, 2002)

En la Fig. 2 se puede observar un esquema propuesto por Armstrong [6] que resume los elementos involucrados en el modelo de negocio de un Web Service, las relaciones entre estos elementos y los documentos involucrados en estas relaciones.

2. Modelado de Web Services haciendo uso de UML

Uno de los primeros enfoques presentados sobre la relación entre UML y Web Services es el de Scott Ambler [1,2,3,4] con su serie de cuatro artículos publicados en el IBM developer Works. El autor indica que para obtener un conjunto de Web Services desde una aplicación orientada a objetos, es necesario identificar “paquetes de dominio” y los servicios que cada paquete provee. Estos paquetes representan grupos de alto nivel de clases del dominio asociado al negocio, permitiendo definir como estrategia para representar la arquitectura de una aplicación, las siguientes capas de tipos de clases.

� Clases de interfaz de usuario: HTML, GUI, reportes, etc.

� Clases del dominio del negocio: entidades, conceptos del dominio, etc.

� Clases de proceso: lógica del negocio, Web Service, etc.

� Clases para almacenamiento: base de datos, archivos planos, etc.

� Clases del sistema: comunicación entre procesos, registro de errores, etc.

En sus artículos, Ambler presenta una metodología de 6 pasos que van desde la definición conceptual del sistema hasta la publicación de los servicios del Web Service. Como apoyo en la realización de los pasos, utiliza UML como herramienta de modelaje. Los pasos son los siguientes:

� Simplificar las clases del sistema y para el almacenamiento. No tomar en cuenta las clases que no tienen que ver con la identificación de los Web Services.

� Simplificar jerarquías. Las relaciones de herencia y agregación se pueden simplificar para reducir la complejidad del modelo. Se apoya en el diagrama de clases de UML.

� Identificar los contratos de las clases. Un contrato es un servicio o comportamiento de un objeto que otros objetos pueden requerir. Es una operación que responde directamente a un mensaje de otra clase. Los contratos definen la interfaz externa, también conocida como la interfaz pública de la clase.

� Identificar paquetes de dominio potenciales. Un paquete de dominio es un conjunto de clases que colaboran entre sí para soportar un grupo cohesivo de contratos. La idea es que cada paquete de dominio ofrezca uno o más Web Services a otros paquetes de dominio, aplicaciones o sistemas externos. Un objetivo clave es organizar el diseño en varios paquetes de manera tal de reducir la cantidad de información que fluye entre ellos (tiene implicaciones en el tráfico en la red). Un diagrama de colaboración de UML permite representar el flujo de mensajes entre las clases que ayuda a obtener la distribución



adecuada de clases en los paquetes de dominio.

� Definir los contratos de los paquetes de dominio. Los contratos entre paquetes de dominio son contratos de clases que son accesados por otras clases fuera del paquete. Es importante estar seguro que los contratos de un paquete sean cohesivos entre sí. Se puede modelar con un diagrama de componentes de UML en la cual se identifican los paquetes y las relaciones de dependencia entre ellos.

� Definir las firmas del Web Service. Se refiere al diseño de las estructuras XML que los Web Services retornan para representar la información requerida. Hay que identificar también los parámetros pasados al Web Service y los valores de retorno correspondientes.

Un enfoque que se repite en varios planteamientos de modelaje de Web Services con UML es la definición de perfiles UML. En este sentido, Gardner [8] propone un perfil en el cual un proceso se representa como una clase mediante el estereotipo “«Process»” y sus atributos corresponden al estado del proceso. Thöne y compañía [22] definen el perfil UML-WSC que incluye una variante o extensión del diagrama de activación de UML, para la descripción de las composiciones de servicios orientados a procesos. Estos autores hacen uso de un estereotipo de clase para describir los Web Services con sus operaciones y parámetros.

En UML-WSC hay una modificación de la sintaxis de UML al agregar otros elementos como por ejemplo la inclusión de un hexágono (no incluido en el UML original) para representar estados transformados. En este caso ya no se está definiendo un perfil sino que se está haciendo una modificación del estándar que UML representa. Esto se hubiera podido evitar definiendo un estereotipo adecuado para la sintaxis de estado incluida en UML.

Otra característica común que tienen varios de los enfoques analizados, es la de definir

diagramas UML para la generación automática de descripciones del servicio en WSDL. En este caso la principal contribución son las reglas de conversión entre UML y Web Services descrito en documentos WSDL y XML Schema. Un ejemplo se observa en el trabajo de Marcos y compañía [14] en la cual se define una extensión de UML para este fin.

Figura 3. Pasos para el desarrollo de Web Services basado en modelos

(Grønmo-1 et al, 2004)

Un segundo ejemplo lo representa el trabajo de Grønmo y compañía [9], quienes plantean además, una secuencia de 6 pasos para desarrollar un Web Services basado en modelos (MDA de sus siglas en inglés Model Driven Architecture)[17]. Los pasos son los siguientes (ver en Fig. 3 diagrama de actividad UML correspondiente):

1) Se identifica el Web Service y se obtiene el WSDL correspondiente.

2) El WSDL es importado a UML mediante una transformación de ingeniería inversa; se obtienen uno o más modelos UML asociados.

3) Mediante una herramienta de UML se revisan e integran los modelos para obtener un nuevo modelo compuesto de Web Services.

4) Con el modelo anterior se genera un nuevo WSDL.

5) Se implementa el Web Service según el WSDL generado.

6) Se publica el Web Service para que esté disponible en la Web.



Con miras a ejemplificar las reglas de conversión entre UML y Web Services para la generación de los documentos WSDL y XML Schema, la Fig. 4 muestra un ejemplo genérico de clases basado en el perfil UML propuesto por Grønmo y compañía. Nótese el uso de los estereotipos «Interfaz» y «Servicio». El trabajo de Gardner [8] se basa en un esquema similar de modelado de flujos introduciendo un perfil UML para BPEL4WS.

En este mismo orden de ideas, Provost [19] presenta un perfil UML bastante completo que muestra diferentes mecanismos de extensión de UML usados para definir estereotipos para tipos específicos de WSDL / XML Schema y valores etiquetados para representar relaciones, URLs (de sus siglas en inglés Uniform Resource Locators), etc. Según este perfil, un Web Service debe ser modelado usando estos estereotipos y valores etiquetados específicos, dando lugar a un modelo basado en un WSDL. Otro factor indicado por el autor, es la gran ventaja de basar el diseño de los sistemas Web Service con UML al indicar que, principalmente a través de los estereotipos, UML puede expresar el diseño sobre tres dominios importantes: WSDL para la semántica de los mensajes, WXS para las publicaciones y el lenguaje orientado a objetos para la implementación del servicio o el cliente.

Figura 4. Ejemplo de clases basado en un perfil UML (Grønmo-1 et al, 2004)

En los estereotipos definidos por Provost se usa el prefijo “xs:” como notación para los elementos que representan a los WKS y “wsdl:” para los elementos que representan a los WSDL. Otro factor de interés es que se asocia a la interfaz de UML con el componente «portType» de WSDL y cada firma (publicación) del método asociado a la interfaz / «portType» debe ser explicado como mensajes SOAP del tipo «input», «output» y «faults». Lo que se busca es desarrollar un documento de diseño UML que exprese la descripción WSDL, incluyendo los soportes para los tipos WXS, la implementación del servicio y la interacción de los clientes con el servicio.

Figura 5a. Modelo de clases del servicio “El Amor es Ciego” (Provost, 2003)

Figura 5b. Diagrama de casos de uso(Provost, 2003)



La Fig. 5a muestra el modelo de clases del ejemplo del servicio “El amor es ciego” (The Love Is Blind) incluido en el trabajo de Provost. Es interesante resaltar que las reglas de conversión entre UML y WSDL planteadas por el autor, se han implementado en la herramienta UMT [23] (de sus siglas en inglés UML Transformation Tool). Continuando con el trabajo de Provost, el autor incluye diagramas de casos de uso en la cual se aprecia la producción de los WSDL y WXS (ver Fig. 5b), que es uno de los principales objetivos del modelo. La Fig. 6a presenta un diagrama de clases más detallado del ejemplo “El Amor es Ciego” y la relación con el actor identificado en el diagrama de casos de uso. Nótese la forma como se utilizan los valores etiquetados para expresar los URI (de sus siglas en inglés Uniform Resource Identifier). Finalmente, un complemento interesante a la notación de clase/componente es el análisis dinámico expresado en un diagrama de colaboración (ver ejemplo del servicio “El Amor es Ciego” en Fig. 6b).

Figura 6a. Modelo de clases más detallado del servicio “El Amor es Ciego”

(Provost, 2003)

Figura 6b. Diagrama de colaboración del servicio “El Amor es Ciego”

(Provost, 2003)

Uno de los trabajos más completos sobre el modelaje de Web Services con UML es el realizado por Armstrong [6]. Lo importante a resaltar de este trabajo es que abarca la mayoría de los conceptos involucrados en Web Service y hace uso de varios de los diagramas pertinentes de UML. En la Fig. 7a se puede observar el diagrama de casos de uso planteado por Armstrong sobre el modelo de negocios de un sistema de Web Service.

En el perfil propuesto por Armstrong se definen estereotipos de clases para elementos que tienen que ver con mecanismos de análisis, mecanismos de diseño y mecanismos de implementación. Es decir, abarca diferentes etapas del modelaje conceptual de los Web Services. Algunos ejemplos de conceptos relacionados con estos estereotipos son la comunicación entre procesos, como un tipo particular de mecanismo de análisis, la codificación de la data, como un mecanismo de diseño y XML, como un caso particular de mecanismo de implementación.



Figura 7a. Diagrama de casos de uso del modelo de negocios de un Web Service

(Armstrong, 2002)

Figura 7b. Diagrama de distribución para SOAP(Armstrong, 2002)

En la Fig. 8 se observa un diagrama de clases con el uso de estos estereotipos.

Figura 8. Modelo de clases para Web Service (Armstrong, 2002)

Ciertamente, el trabajo realizado por Armstrong representa un modelo conceptual bastante completo de Web Services. Se toman en consideración varios temas relacionados con el dominio del problema, haciendo énfasis en lo que tiene que ver con SOAP y UDDI (de sus siglas en inglés Universal Description, Discovery and Integration). Adicionalmente a lo ya expuesto, en este mismo trabajo se pueden observar ilustraciones detalladas de los siguientes aspectos.

� Diagrama de secuencia de una petición SOAP hecho desde un navegador.

� Diagrama de clases que modela una petición SOAP en el servidor.

� Diagrama de secuencia para una petición SOAP en el servidor.

� Diagrama de distribución para SOAP. (Ver Fig. 7b).

� Modelo detallado de clases para WSDL y WSDL Schema.

� Modelo de clases para UDDI. � Diagrama de secuencia del uso y

comportamiento del UDDI. � Diagrama de secuencia del envío de un

mensaje SOAP. � Modelo de clases del envío de un mensaje

SOAP.

En otro orden de ideas, el tema de modelaje de Web Services con UML también se ha manejado en casos específicos o como complemento bajo otras estrategias de modelaje. En este sentido, Heckel y compañía [11] hacen una propuesta para aplicar una metodología general para especificar y analizar la consistencia de los modelos orientados a objetos de arquitecturas de Web Services a modelos UML. Ellos hacen énfasis en el modelado visual de la parte de comportamiento dado por BPEL4WS. Los autores presentan las siguientes asociaciones entre los elementos de UML y los elementos de un Web Service.



� Diagramas de casos de uso para describir el segmento de negocio permitiendo describir la utilidad final del Web Service. En la figura 9a se presenta un ejemplo.

� Diagramas de componentes para refinar las dependencias descritas en el diagrama de casos de uso. Un componente, en este caso, es usado para representar a un Web Service. Se usa la sintaxis UML para las “interfaces” con las interacciones entre estos componentes para representar los «port types». Si un Web Service provee un «port type» la “interfaz” se conecta al componente. Si el Web Service requiere el «port type» se modela como una dependencia entre el componente y la interfaz (ver Fig. 10).

� Los diagramas de clases proveen mayor detalle de los diferentes «port types» al agregar las operaciones con los correspondientes mensajes y parámetros. Se puede ver el ejemplo en la figura 9b.

� Los diagramas de actividad permiten modelar los protocolos de interacción y procesos del negocio. Las actividades corresponden a estereotipos para indicar recepción («receive»), contestación («reply») o invocación («invoke»), según lo que establece BPEL4WS (ver ejemplo en Fig. 11).

Figura 9a. Diagrama de casos de uso para un Web Service (Heckel et al, 2003)

Figura 9b. Especificación de una clase bajo el estereotipo «Port Type»

Figura 10. Diagrama de componentes para un Web Service (Heckel et al, 2003)

Figura 11. Diagrama de actividad según el estándar BPEL4WS (Heckel et al, 2003)

Estos mismos autores recalcan la importancia de la consistencia que deben tener los modelos UML cuando se desarrolla una arquitectura Web Service. Afirman que el manejo de la



consistencia en un proceso de desarrollo basado en UML es una tarea difícil. Para especificar y analizar la consistencia de los modelos proponen una metodología que se resume en los siguientes criterios.

� Los problemas de consistencia debe ser identificados, documentados y clasificados.

� Por cada problema de consistencia semántica, un dominio semántico conveniente debe ser escogido, se debe designar una formalización parcial para hacer el mapeo con los modelos UML en el dominio semántico y se deben indicar las condiciones de consistencia.

� Se debe definir un chequeo de consistencia por cada problema de consistencia.

� Los chequeos de consistencia deben estar integrados al proceso de desarrollo existente.

Otra área en la cual se encuentran propuestas de uso de UML para el modelado de Web Services es aquella que tiene que ver con el contexto de MDA. En este sentido, Bordbar y compañía [7] usan UML como herramienta de apoyo para mostrar mediante sus diagramas, algunos de los procesos de transformación del sistema Web Service bajo las premisas de MDA. Incluye la representación de un meta-modelo simplificado de UML que contiene los elementos de modelaje necesarios para definir las secciones de “Acciones” y “Actividades”. Estos meta-modelos crean una vista clara de los elementos del modelo disponibles, así como sus relaciones y dependencias. Los autores también muestran las reglas de correspondencia entre los elementos del modelo incluidos en los meta-modelos del diagrama de actividad de UML y WSCI.

Figura 12. Construcción de un Web Service compuesto según MDA (Grønmo-2 et al, 2004)

En este mismo orden de ideas, Grønmo y Solheim [10] proponen la construcción de Web Services compuestos siguiendo los principios de MDA. Para ello se comienza con la definición de los modelos de alto nivel usando UML, se definen las reglas de conversión desde UML a la plataforma final y se usa la generación automática de código para obtener gran parte de la implementación requerida. La Fig. 12 contiene un diagrama de actividad que ilustra este algoritmo (según los autores, los flujos para las composiciones de Web Services son modelados con diagramas de actividad). Cabe destacar los siguientes criterios de éxito para el modelado UML, que estos autores identifican.

� Los elementos de UML deben ser capaces de expresar la mayoría de los patrones requeridos.

� El modelo UML debe ser fácil de entender. � El modelo UML debe ser lo suficientemente

preciso y contener los detalles suficientes para que se pueda generar un documento XML que contenga el flujo completo.

� El modelo UML debe ser independiente de los lenguajes XML particulares que se usen para representar los flujos.

Por otro lado, un trabajo reciente que llama la atención, por tratarse de un área novedosa como es el caso de AOSD [5] (de sus siglas en inglés Aspect-Oriented Software Development) es el



realizado por Ortiz y compañía [18]. Se refiere a un paradigma emergente que busca incrementar y mejorar la expresividad de los modelos de orientación a objetos. En este sentido, los autores basan sus propuestas en la idea de desarrollar un software de mayor calidad mediante la separación de propósitos, especificando cada uno de ellos de forma separada y las relaciones existentes entre los mismos, para posteriormente, utilizando un mecanismo adecuado, componerlos formando un sistema completamente coherente. Ellos presentan un enfoque en la cual se modela el Web Service mediante un perfil UML orientado a aspectos. Para ello se definen estereotipos que representan los cinco tipos de elementos orientados a aspectos descritos por los autores. La Fig. 13 muestra un ejemplo del perfil UML orientado a aspectos propuesto por estos autores. Una acción («Action») debe ser una operación («Operation») del aspecto («Aspect») y debe estar limitada a una operación o a una clase por una asociación («Assotiation») del tipo «ApplyExecutionAspect» o «ApplyCallAspect».

Figura 13. Modelo Web Service mediante perfil UML orientado a aspectos (Ortiz et al, 2005)

En la próxima sección se presenta una alternativa que considera el tema de seguridad en el modelado de Web Services, haciendo uso de la tecnología WS-Security.

3. Agregando seguridad a los modelos UML de diseño de Web Services

Si se hace un compendio de todas las propuestas presentadas en la sección anterior se puede obtener un planteamiento muy completo de modelaje de un Web Service con UML. Pero se está dejando por fuera un concepto de mucha importancia en el modelaje de estos sistemas que tiene que ver con la seguridad. Dado que los Web Services exponen información valiosa y crítica del negocio, codificada en XML, la seguridad es un concepto crítico e importante que debe ser completamente entendido.

La tecnología y estándares de seguridad relacionados con Web Services están enmarcados en el concepto WS-Security [13]. En forma resumida, WS-Security describe extensiones SOAP para el manejo de mensajes seguros y es compatible con tecnologías de seguridad ya establecidas y maduras como es el caso de SSL, IPSec, XML Signature y XML Encryption. Está formado por la siguiente familia de estándares [20].

� WS-Policy: Define cómo expresar las capacidades y restricciones de políticas de seguridad.

� WS-Trust: Describe el modelo para establecer las relaciones de confianza.

� WS-Privacy: Habilita a los usuarios a tener preferencias de privacidad y a los Web Services a tener e implementar prácticas de privacidad.

� WS-SecureConversation: Describe cómo manejar y autentificar el intercambio de mensajes.

� WS-Federation: Describe cómo manejar y romper las relaciones de confianza en un ambiente federado heterogéneo.

� WS-Authorization: Define cómo los Web Services manejan las políticas de autorización a la data.



� WS-PolicyAssertions: Provee consideraciones particulares que se deben aplicar a un tipo específico de política.

� WS-PolicyAttachment: Da indicaciones de cómo relacionar una política a un recurso (por ejemplo un WSDL).

� WS-SecurityPolicy: Es un tipo específico de política que usa el WS-Policy que responde a ciertos requerimientos de seguridad y preguntas de configuración de un Web Service (por ejemplo el algoritmo de encriptación soportado).

La propuesta de definición del perfil UML basado en WS-Security consiste en tomar en consideración los siguientes aspectos:

1) La definición de estereotipos para cada uno de los conceptos de la familia de WS-Security que identifican meta-clases que representan los elementos correspondientes.

2) La definición de las clases para el concepto «Security Token Service» y asociar estas clases al concepto de Web Service.

3) La definición de las clases para los conceptos «Policy» y «Security Token» como parte del mensaje seguro SOAP.

4) La definición de las clases para los conceptos usados en los dominios o escenarios de cada estándar (por ejemplo IP/STS usado en WS-Federation).

5) La realización de los diagramas de colaboración/secuencia para representar el protocolo de intercambio de mensajes requeridos para cada mecanismo de seguridad.

6) La consideración en el modelo de los elementos que tienen que ver con los conceptos de XML Encryption y XML Signature.

Basado en las consideraciones antes expuestas, la Fig. 14a presenta el diagrama de clases propuesto para incorporar al modelaje de Web Service, los elementos de seguridad basados en

el estándar WS-Security. La Fig. 14b muestra un ejemplo de un diagrama de secuencias que representa el protocolo de intercambio de mensajes seguros definido por WS-Federation. La propuesta completa contempla la realización de un diagrama similar para cada uno de los protocolos de intercambio seguros.

Figura 14a. Modelo de clases para el perfil UML basado en WS-Security

Figura 14b. Diagrama de secuencias con protocolo WS-Federation

Como se puede notar, bastan dos acciones para incorporar la componente de seguridad al modelado de Web Services con UML: 1) definir los estereotipos adecuados asociados a los conceptos propios de WS-Security y 2) modelar los procesos que rigen el intercambio seguro de mensajes.



III. CONCLUSIONES

Los lenguajes de modelado visuales de alto nivel como UML tienen ventajas importantes con respecto a los lenguajes basados en XML de especificaciones de bajo nivel. Entre otras cosas, permiten una mejor abstracción de los detalles de implementación y ofrecen una mejor comprensión del diseño del sistema. Un documento UML puede proveer imágenes más claras y limpias del diseño de un Web Service, tanto para la implementación como para la documentación y comunicación al grupo de desarrollo.

La mayoría de los modelos para Web Services que tratan de encontrar una forma apropiada de modelar la composición de servicios con UML, usan la estructura de WSDL para modelar los servicios. La forma más natural de elaborar un modelo UML para Web Services, es planteando un perfil UML que se corresponda con los conceptos propios de este tipo de sistema. La definición de los perfiles UML se concentra principalmente en la identificación apropiada de estereotipos y valores etiquetados.

UML, mediante sus 9 tipos diferentes de diagramas, soporta todas las áreas requeridas para el modelaje de los sistemas basados en Web Services, tanto la parte estructural o conceptual como la parte de flujos de datos y procesos o dinámica. El diagrama de clases de UML es el

más apropiado para modelar la parte estructural de los Web Services. En lo que respecta a la parte dinámica, los diagramas de actividad y secuencia son los más idóneos. UML puede ser utilizado también como herramienta de apoyo en el modelaje de Web Services con otros paradigmas de diseño, como es el caso de MDA y AOSD.

Un área débil que se identifica en el modelaje de Web Services con UML es lo que tiene que ver con la consistencia de los servicios. Puede implicar la incorporación en el proceso de modelaje, de elementos de chequeo y prueba de consistencia.

Cabe destacar la posibilidad de contar con herramientas automatizadas que permitan hacer generación automática de código, desde un modelo UML a los documentos XML y XML Schema del Web Service correspondiente. Estas herramientas también pueden tener la capacidad de hacer ingeniería inversa al generar los modelos UML a partir de los documentos.

En este artículo se realizó un compendio de los trabajos que involucran el modelado de Web Services con UML. Se hizo mención de que estos trabajos no consideran el aspecto de seguridad, importante para este tipo de sistemas. Se planteó una propuesta para agregar a estos modelos la componente de seguridad basada en el estándar WS-Security.



IV. REFERENCIAS1. Ambler S; Deriving Web Services from UML models, Part 1: Establishing the process. IBM developerWorks – Web

services articles. http://www.ibm.com/developerworks/webservices/ library/ws-uml1/. (2002). (Visitado 2007, octubre).

2. Ambler S; Deriving Web Services from UML models, Part 2. IBM developerWorks – Web services articles. http://www.ibm.com/developerworks/webservices/library/ws-uml2/. (2002). (Visitado 2007, octubre).

3. Ambler S; Deriving Web Services from UML models, Part 3: Identifying domain packages. IBM developerWorks – Web services articles. http://www.ibm.com/developerworks/ webservices/library/ws-uml3/. (2002). (Visitado 2007, octubre).

4. Ambler S; Deriving Web Services from UML models, Part 4: Defining Web services. IBM developerWorks – Web services articles. http://www.ibm.com/developerworks/webservices/ library/ws-uml4/. (2002). (Visitado 2007, octubre).

5. AOSD; aosd.net Homepage. http://aosd.net/. (2001). (Visitado 2007, octubre).6. Armstrong C; Modeling Web Services with UML. OMG Web Services Workshop. (2002).7. Bordbar B., Staikopoulos A; Modelling and Transforming the Behavioural aspects of Web Services. Proc. 3rd

Workshop in Software Model Engineering (WiSME) and Satelite workshop at the 7th International Conference on the UML. Lisboa, Portugal. (2004).

8. Gardner T; UML Modelling of Automated Business Processes with a Mapping to BPEL4WS. Proc. 17th European Conference on Object-Oriented Programming (ECOOP). Darmstadt, Alemania. (2003).

9. Grønmo R., Skogan D., Solheim I., Oldevik J; Model-driven Web Services Development. Proc. IEEE International Conference on e-Technology, e-Commerce and e-Service (EEE-04). Taipei, Taiwan. (2004).

10. Grønmo R., Solheim I; Towards Modeling Web Service Composition in UML. Proc. 2nd International Workshop on Web Services: Modeling, Architecture and Infrastructure. Porto, Portugal. (2004).

11. Heckel R., Voigt H., Küster J., Thöne S; Towards Consistency of Web Service Architectures. Proc. 7th World Multiconference on Systemics, Cybernetics and Informatics (SCI). Orlando, USA. (2003).

12. IBM-1; Business Process Execution Language for Web Services. http://www.ibm.com/ developerworks/library/specification/ws-bpel/; (2002). (Visitado 2007, octubre).

13. IBM-2; Web Services Security. http://www.ibm.com/developerworks/library/specification/ ws-secure/; (2002). (Visitado 2007, octubre).

14. Marcos E., de Castro V., Vela B; Representing Web Services with UML: A Case Study. Service Oriented Computing-ICSOC 2003. Springer Verlag. 15 – 27. (2003).

15. OMG-1; The Object Management Group. http://www.omg.org/. (1997). (Visitado 2007, octubre).16. OMG-2; UML® Resource Page. http://www.uml.org/. (1997). (Visitado 2007, octubre).17. OMG-3; Model Driven Architecture (MDA). http://www.omg.org/mda/. (1997). (Visitado 2007, octubre).18. Ortiz G., Hernández J., Clemente P., Amaya P; How to Model Aspect-Oriented Web Services. Proc. Workshop on

Model-driven Web Engineering at ICWE2005. Sydney, Australia. (2005).19. Provost W; UML for Web Services. From O’Reilly WebServices.xml.com. http://www.xml.com/pub/a/ws/2003/08/05/

uml.html. (2003). (Visitado 2007, octubre).20. Rosenberg J., Remy D; Securing Web Services with WS-Security. Sams Publishing. ISBN: 0-672-32651-5. (2004).21. Schmuller J; SamsTeach Yourself UML in 24 Hours, Complete Starter Kit. Sams, 3 edition. ISBN-10: 0672322382.

(2004).22. Thöne S., Depke R., Engels G; Process-Oriented, Flexible Composition of Web Services with UML. Proc. Third

International Joint Workshop on Conceptual Modeling Approaches for E-business: A Web Service Perspective (eCOMO 2002). Tampere, Finlandia. (2002).

23. UMT; UMT-QVT Homepage. http://umt-qvt.sourceforge.net/. (2005). (Visitado 2007, octubre).24. Wiley J; Modeling Web Services with UML 2.0. John Wiley & Sons Inc. Landry. ISBN: 0471227137. (2003).25. W3C; XML Schema; http://www.w3.org/XML/Schema. (2000). (Visitado 2007, octubre).26. W3C; Web Services Description Language (WSDL). http://www.w3.org/TR/wsdl. (2001). (Visitado 2007, octubre).27. W3C; Web Service Choreography Interface (WSCI). http://www.w3.org/TR/wsci/. (2002). (Visitado 2007, octubre).28. W3C; Extensible Markup Language (XML). http://www.w3.org/XML/. (2003). (Visitado 2007, octubre).29. W3C; Simple Object Access Protocol (SOAP). http://www.w3.org/TR/soap/. (2004). (Visitado 2007, octubre).

extensión de los modelos uml para el diseño...

Documents