Extensión de los Modelos UML para el Diseño Conceptual de

Transcripción

Extensión de los Modelos UML para el Diseño Conceptual de Sistemas de Web Services basado en la Componente de Seguridad WS-Security
Mauricio Paletta
Extensión de los Modelos UML
para el Diseño Conceptual
de Sistemas de Web Services
basado en la Componente
de Seguridad WS-Security
Mauricio Paletta
Departamento de Ciencia y Tecnología.
Universidad Nacional Experimental de Guayana
[email protected]
RESUMEN
En 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.
ABSTRACT
Extension 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
98
CITEG Revista Arbitrada. Año I. N°2. Julio - Diciembre 2007
Mauricio Paletta
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
CITEG Revista Arbitrada. Año I. N°2. Julio - Diciembre 2007, pp. 98 - 112
99
Mauricio Paletta
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.
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 asociación y relaciones entre objetos.
el
5) Diagramas de estados. Representa el
comportamiento del sistema en el tiempo.
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.
6) Diagrama de colaboración. Muestra la
interacción entre objetos mediante el
intercambio de mensajes que ocurre entre
ellos.
2) Diagramas. Gráficas que
contenido de una vista.
describen
4) Mecanismos generales. Proveen comentarios,
información u otros extras a los elementos del
modelo.
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.
Basado en los aspectos del sistema a modelar,
se identifican 5 posibles vistas.
8) Diagrama de componentes. Permite modelar
la estructura del software, incluyendo dependencias entre componentes en código
fuente, componentes en código binario y
componentes ejecutables.
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.
100
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
Mauricio Paletta
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
101
Mauricio Paletta
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.
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:
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.
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
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.
102
Mauricio Paletta
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.
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):
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.
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.
Otra característica común que tienen varios
de los enfoques analizados, es la de definir
103
Mauricio Paletta
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
104
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)
Mauricio Paletta
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.
105
Mauricio Paletta
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.
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)
106
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
comportamiento del UDDI.
Diagrama de secuencia del envío de un
mensaje SOAP.
Modelo de clases del envío de un mensaje
SOAP.
del
uso
y
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.
Mauricio Paletta
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).
Figura 9b. Especificación de una clase bajo el estereotipo
«Port Type»
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.
Figura 10. Diagrama de componentes para un Web Service
(Heckel et al, 2003)
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 11. Diagrama de actividad según el estándar BPEL4WS
Figura 9a. Diagrama de casos de uso para un Web Service
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
107
Mauricio Paletta
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 metamodelo 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 metamodelos del diagrama de actividad de UML y
WSCI.
Figura 12. Construcción de un Web Service
compuesto según MDA
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
108
Mauricio Paletta
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».
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.
Figura 13. Modelo Web Service mediante perfil UML orientado
a aspectos (Ortiz et al, 2005)
WS-Federation: Describe cómo manejar y
romper las relaciones de confianza en un
ambiente federado heterogéneo.
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.
WS-Authorization: Define cómo los Web
Services manejan las políticas de autorización
a la data.
109
Mauricio Paletta
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:
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
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 WSFederation).
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
110
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.
Mauricio Paletta
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.
111
Mauricio Paletta
IV. REFERENCIAS
1. 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 ComputingICSOC 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).
112

Extensión de los Modelos UML para el Diseño Conceptual de

Transcripción

Documentos relacionados

Diapositiva 1 - Seminario de Ingeniería de Sistemas