ActasJSWEB2010 Rev

Actas de las
VI Jornadas Cientfico-Tcnicas en Servicios Web y

SOA (JSWEB2010)
!"#$%&!'

3.3. El flujo de servicio
Los elementos anteriormente descritos se
relacionan entre ellos para dar servicio a un ciclo
completo de una peticion.
En el flujo de una peticion es preciso conectar con
los diferentes sistemas de informacion a travs de
los servicios publicados mediante la herramienta
ESB.
Cada uno de los conectores a los diferentes
sistemas se divide en dos partes:
Parte de comunicacion a travs de la
herramienta ESB.
Parte de consolidacion de datos
implementada en el web service proxy.
El diagrama a continuacion nos muestra el flujo
genrico de una peticion.

Con el objetivo de mejorar el rendimiento de la
plataforma y reducir la sobrecarga en los sistemas
hospitalario se utiliza un elemento que actua de
cache.
Una vez delegada la peticion al conector
especifico en ocasiones es preciso que colaboren
entre ellos para poder servir correctamente la
peticion.
3.4. Seguridad SOA
En todo momento la comunicacion entre los
diferentes clientes y el web service proxy se
encuentra protegida con tal de garantizar la
privacidad de la informacion mdica del paciente,
catalogada como de nivel alto en relacion con la
ley de proteccion de datos.
La proteccion de esta comunicacion se establece
en base a:
uso de certificados SSL de 128 bits.
Politicas de filtrado en el firewall del proxy.
El web service se encuentra ubicado dentro de un
area DMZ desde la cual puede acceder al sistema
que implementa la capa de comunicacion para la
acceder a la informacion necesaria.
4. Casos de uso
A continuacin comentaremos brevemente
algunos de los escenarios que presenta el proyecto
y como el web service proxy ha permitido la
creacion de estos servicios a un bajo coste
1
.
4.1. Sitio web de pacientes en el hospital.
Desarrollo de un sitio web vinculado al dominio
http://pacientes.hcin.es a travs del cual los
pacientes pueden consultar informacion asociada
1
Ver problematica del grado de implatacin
tercnologica en el entorno publica sanitario.
4 VI Jornadas Cientfico-Tcnicas en Servicios Web y SOA
a sus historias clinicas relacionada con el
ambito de:
Citas pendientes con el sistema de salud.
Peticion de cambios de modificaciones y
anulaciones de cita.
Exportacion del listado de citas a formato
ical compatible.
Peticion de cambios de informacion
demografica del paciente.
Informacion de caracter demografico desde
el sistema de identificacion unica de
pacientes.
A partir de la utilizacion de web service proxy ha
sido posible construir un sitio web para paciente
abstrayendo los detalles de cada uno de los
sistemas de informacion hospitalario y por tanto
permitiendo que la empresa adjudicadora haya
podido realizar el desarrollo sin conocimientos
previos de los estandares existentes en el entorno
sanitario.
Desarrollado utilizando tecnologias java, xml y
web services.
4.2. Sitio web de recomendaciones
medicas
Desarrollo de un sitio web a travs del cual los
pacientes pueden obtener una serie de
recomendaciones mdicas personalizadas
relacionadas con sus patologias, tratamientos y
prestaciones sanitarias recibidas.
A partir de la utilizacion del web service Proxy ha
sido posible aislar a los editores de contenidos del
sitio de los detalles particulares de cada uno de los
sistemas en los que residen la historia clinica del
paciente y centrar su actividad en la redaccion de
recomendaciones medicas especificas.
4.3. Interface telefnica
Para aquellos usuarios que disponen de
conexion a internet o que no se encuentre
familiarizados con el uso de las nuevas
tecnologias se ha implementado una interface a
travs de telfono que permite:
Identificacion de usuario a travs de tarjeta
sanitaria.
Consulta de la citas pendientes del pacientes
con el hospital y resto de centros de salud
asociados.
Consulta de la informacion demografica del
paciente.
Consulta del tiempo de espera en las
diferentes consultas y servicios del hospital.
Los usuarios puede interactuar con el
sistema a travs de eventos de teclado
(DTFM) o reconocimiento de comandos de voz.
Mediante la utilizacion del web service Proxy se
ha permitido que la solucion de voz ip existente en
el hospital se comunique con los sistemas de
gestion hospitalaria existentes en el hospital para
la implementacion de un nuevo de tipo de
itnerface.
El desarrollo ha utilizado la plataforma de voz ip
existente en el hospital, la solucion open source
de voz ip asterisk y el estandar de generacion de
interfaces voz ip VoiceXML.
4.4. Pantallas de informacin.
Instalacion de un sistema de publicacion
de informacion interno al hospital que
permita a los pacientes obtener informacion
relacionada con el estado de las diferentes
consultas y cualquier otra informacion sanitaria
de inters.
El sistema se compone de una serie de pantallas
de gran tamano ubicadas de manera estratgica en
las diferentes salas de espera del hospital.
Estas pantallas cuenta con la funcionalidad
de reproduccion de manera autonoma de
informacion de tipo diverso.
La utilizacion del web service Proxy ha permitido
crear un nuevo tipo de servicio mediante el cual
los usuarios pueden estar informados de la
operativa de cada una de las consultas.
VI Jornadas Cientfico-Tcnicas en Servicios Web y SOA 5
En este caso la funcionalidad desarrollada
especificamente para consumo interno por parte
de las pantallas de informacion puede tambin ser
consultada mediante los diferentes clientes
consumidores de informacion anteriormente
descritos.
4.S. Desarrollo internos por parte del
hospital.
La creacion de un conjunto de servicios
consumibles a travs del web service Proxy ha
permitido al hospital poner en marcha una serie de
desarrollo internos, especialmente en el area de
enfermeria, y que utilizan una vision unificada de
la informacion que es dotada por el web service
Proxy.
S. Prximos pasos
En fases posteriores se pretende ampliar el
numero de sistemas de informacion accesibles con
el desarrollo de conectores especificos para
Sistema de receta electronica. Integracion de
esta informacion en los canales actuales,
incluso desarrollo de un aplicativo especifico
para el envio de recordatorios de medicacion.
Sistema de gestion hospitalaria de atencion
primaria.
.
6. Conclusin
Se ha presentado la estructura modular basada en
SOA usada en el proyecto portal del paciente.
Mediante el uso de esta estructura hemos sido
capaces de integrar diferentes sistemas de
informacion hospitalaria independientes y acceder
a ellos de forma transparente usando una API
sencilla, lo que nos ha llevado a desarrollar
diferentes canales de informacion orientados al
usuario final.
Plataforma de computacin genrica basada en servicios Web
para problemas de transporte y logstica
Francisco Almeida, Vicente Blanco, Julio Brito,
Andrs Crespo, Jos A. Moreno, Adrin Santos
PETrans: Proyecto Estructurante de Transporte
Dep. de Estadstica, I.O. y Computacin
Universidad de La Laguna
{falmeida, vblanco, jbrito, acrespo, jamoreno, asmarre}@ull.es

Resumen

En el anlisis y planificacin de los sistemas de
transporte y en los estudios de movilidad es
frecuente el uso de los Sistemas de Informacin
Geogrfica (GIS). Tanto en las grandes
organizaciones como en las pequeas empresas, es
habitual o necesario el uso de datos que tienen
atributos de carcter espacial, y cada vez ms
surgen necesidades de anlisis de los mismos.
En este trabajo planteamos el desarrollo de
una plataforma basada en servicios web orientada
a problemas de transporte y de logstica. Haciendo
uso del framework de desarrollo para servicios
web PyOpenCF integramos en un mismo entorno
servicios orientados a la geolocalizacin, a la
optimizacin logstica, etc. Desarrollamos un
cliente PyOpenCF cuya interfaz grfica permite
lanzar procesos con datos de carcter espacial y la
visualizacin de resultados.
1. Introduccin
El tratamiento de datos referentes al transporte es
un problema multidisciplinar: ingenieros y
gegrafos en la planificacin, economistas para
los estudios de movilidad, ingenieros en la
optimizacin logstica, etc.; y que compete a
diferentes sectores y mbitos, tanto pblicos como
privados, cada uno con una visin y unas
necesidades particulares.
Aunque los avances en los GIS han permitido
la estandarizacin en la representacin e
intercambio de la informacin. No siempre estn
disponibles los conocimientos y los medios
necesarios para ello. Tanto los modelos como los
procesos de adquisicin, almacenamiento y
mantenimiento de la informacin son propios de
cada fuente y suponen un nicho de informacin de
difcil interaccin entre herramientas y sistemas
distintos. Adems los procesos necesarios para el
anlisis o la planificacin pueden llegar a ser
complejos y necesitar de gran cantidad de datos
para el clculo, lo que hace inviable el trfico de
dichos datos y apunta a la ejecucin en servidores
casi como nica solucin posible.
La mayora de empresas y organizaciones
cuentan con una gran cantidad de datos con
componente espacial, y muchas de stas tienen
necesidades de procesamiento geo-espacial, pero
no disponen ni de los medios ni de los
conocimientos adecuados para su uso eficiente y
compartido. Una plataforma basada en servicios
web que permitiera a dichas entidades realizar
estos procesos sin necesidad de software ni
hardware extra, y preocupndose slo del
mantenimiento de los datos propios sera de gran
utilidad para los mismos [12].
Por otro lado, en los centros de investigacin
se desarrollan nuevos modelos y mtodos que
requieren trabajar con casos reales e interactuar
con entidades para confirmar o corregir dichos
modelos.
En este trabajo se ofrecen las herramientas
necesarias para el intercambio y la interaccin,
independizando los procesos y datos de
infraestructuras de los datos particulares de los
consumidores. Para ello se hace uso de la
plataforma PyOpenCF [13,15] que facilita el
acceso y ejecucin de aplicaciones en sistemas
remotos tanto a usuarios finales como a los
administradores de la misma.
Consideramos que es nuestra principal
contribucin, adentrarnos en la construccin de

sistemas de informacin basados en servicios Web
que faciliten la planificacin y la gestin del
transporte y la movilidad. Hemos desarrollado y
probado algunos componentes modulares capaces
de comunicarse entre s, para el cumplimiento de
funcionalidades especficas. Entre estas
funcionalidades, como caso de uso experimental
se encuentran las que permitin geo-referenciar y
ubicar nodos de demanda, calcular distancias y
rutas entre nodos y planificar rutas ptimas.
Tambin se implementa una interfaz para facilitar
el trabajo de los usuarios. sta amplia la interfaz
de la plataforma PyOpenCF permitiendo la
visualizacin de los datos geo-referenciados
mediante geodjango [6].
El trabajo se ha estructurado como sigue: la
seccin 2 contextualiza el artculo y describe
trabajos relacionados, la seccin 3 presenta el
framework de desarrollo PyOpenCF y cmo se ha
adaptado al contexto que nos ocupa, la seccin 4
describe la plataforma desarrollada mostrando los
servicios y funcionalidades considerados.
Finalizamos con una seccin de conclusiones y
trabajos futuros en la que mostramos las lneas de
inters en el marco de la plataforma.

2. Trabajos relacionados
Los avances tecnolgicos, en particular de los
sistemas de Informacin Geogrfica (GIS) han
permitido en los ltimos aos muchas
experiencias en la aplicacin de estos sistemas en
tareas de anlisis, ordenamiento, planificacin o
reestructuracin de los sistemas de transporte
[2,14]. Es frecuente encontrar herramientas GIS
que incorporan modelos de datos y procesos para
el tratamiento especfico de problemas y, de esta
forma, satisfacer necesidades concretas de un
sector o una entidad determinada.
Los procesos de adquisicin, almacenamiento
y mantenimiento de la informacin son aspectos
crticos en este tipo de sistemas. La alta
variabilidad y volumen de los datos hace que las
entidades responsables de estos procesos tengan
graves problemas en su gestin. En general la
informacin se encuentra dispersa. La
descentralizacin de la informacin convierte el
acceso a las fuentes de dicha informacin en un
elemento crucial para evitar los nichos de
informacin.
La estandarizacin en la representacin e
intercambio de la informacin en los GIS ha
avanzado. Los estndares del Open Geospatial
Consortium (OGC) [10] han conciliado
herramientas GIS dispares y facilitan el
intercambio de informacin espacial en diferentes
formatos. No obstante, an existen mltiples
escollos a la hora de intercambiar la informacin
entre diferentes herramientas o fuentes, por
ejemplo, con frecuencia es necesario aplicar
cambios en los sistemas de coordenadas para
poder representar o manejar datos de diferentes
fuentes.
Las herramientas GIS han encontrado en
Internet una forma de acceder a los datos
directamente de la fuente mediante los servicios
Web. La OGC ha publicado estndares de
servicios con mayor o menor acogida. Entre ellos,
el servicio WMS (Web Map Service) [19] que
produce mapas de datos representados
geogrficamente de forma dinmica, se ha
implementado en la mayora de herramientas GIS
y gran cantidad de entidades pblicas y privadas
ofrecen informacin mediante este estndar.
Tambin han surgido bibliotecas de funciones
(API) que facilitan una interfaz grfica integrada
en la Web para el manejo de los mapas y la
interaccin con estos servicios. Dichas bibliotecas
facilitan la creacin de Mashups [9] que combinan
los mapas suministrados mediante WMS con
informacin propia geo-referenciada. Esta
combinacin no pasa de ser una simple
superposicin de capas y no realiza ninguna
interaccin entre datos, ya que el WMS slo es
una imagen para la representacin.
El estndar WFS (Web Feature Service) [18],
a diferencia del WMS, nos permite recuperar la
informacin vectorial representada mediante el
formato GML (Geography Markup Language) [7]
que deriva del XML. Con este servicio estndar
podemos realizar interaccin entre los datos y de
esta forma realizar una transformacin de los
mismos utilizando datos propios o de otros
suministradores.
La dificultad de WFS por las que no est tan
fuertemente implantado como WMS es la
magnitud de los datos que se suministran.
Mientras que la respuesta de WMS est acotada y
siempre ser una imagen de unas dimensiones
concretas, la respuesta de WFS puede contener
demasiada informacin para su manejo Web, y
muchas veces innecesaria. Un ejemplo concreto lo

encontramos en el proceso de obtencin de las
infraestructuras de transporte de una localidad
(paradas y lneas de bus y tranva, paradas de
taxis, estaciones de tren, etc.), WFS nos dar las
entidades solicitadas con su representacin
geogrfica y atributos. En cambio WMS nos dar
un grfico del tamao solicitado con la
informacin representada. Ahora bien, si hacemos
un zoom y alejamos considerablemente abarcando
varias localidades, la respuesta WMS seguir
siendo un grfico de tamao concreto aunque con
menos definicin de detalle, en cambio la
respuesta WFS ser toda la informacin solicitada
referida a todas estas localidades, lo que aumenta
considerablemente su tamao. Es por ello que el
servicio WFS debe de estar muy bien acotado y a
las caractersticas se le suelen aplicar restricciones
segn la escala. Un caso particular sera no
devolver informacin de las paradas de bus hasta
no alcanzar una escala lo suficientemente cercana
a una localidad.
Como hemos indicado, existe un estndar de
servicio web que permite obtener informacin de
diferentes fuentes para su procesamiento, pero la
dificultad radica en la cantidad de informacin
que tiene que transferirse para realizar
procesamiento. Es por eso por lo que el estndar
WPS (Web Processing Service) [20], diseado
para estandarizar el formato de procesos GIS que
se ofrecen a travs de Internet, tiene gran
importancia, ya que permite realizar ciertos
procesamientos directamente donde se encuentra
la informacin, evitando un trfico innecesario.
Adems permite al consumidor de dicho servicio
abstraerse del proceso en s, ya que ste reside en
el servidor. Es por ello por lo que se perfilan como
un complemento primordial para cualquier
herramienta GIS, aunque an estn poco
generalizados.
No obstante, el problema de la interaccin
entre datos se agrava cuando la informacin es de
ms alto nivel como pueden ser redes de
carreteras o ferroviarias, lneas de transporte, etc.
Cada fuente suele tener su modelo de datos
propio, y en algunos casos, como suele ocurrir con
herramientas privadas, dichos modelos son
privados.
Desde la directiva europea INSPIRE
(Infraestructure for Spatial Information in Europe)
[5] se aspira a crear una infraestructura de datos
geoespaciales en Europa, lo que es la base para
satisfacer necesidades prcticas de otras reas,
tales como agricultura y transporte. Aunque
INSPIRE ya aporta directrices para las
especificaciones de datos en las redes de
transporte [8], se encuentran an en un estado
inicial que no han sido tenidas en cuenta en la
mayora de los sistemas actuales.
La versatilidad de modelos de datos dificulta o
imposibilita la explotacin de la informacin en
una herramienta diferente a la original. Como
ejemplo puede citarse el clculo de la ruta ms
corta a travs de una red de transporte, como
puede ser de carreteras, lneas de autobuses, etc.
Dicho proceso ser dependiente del modelo de
datos de la red. Lo que implica que dos modelos
de datos tendrn diferentes implementaciones de
un mismo proceso. Y adems, para poder usar
datos de un modelo diferente, se debe crear un
adaptador para el proceso.
En la actualidad, existen varias APIs que
permiten algunas funciones como la
geolocalizacin o hallar la ruta ms corta entre
dos puntos, pero carecen de funcionalidades ms
complejas sobre logstica y transporte. Tambin
existen algunas compaas que ofrecen sus
servicios a travs de la web [17], pero no se puede
hablar de servicios web ya que no estn orientados
a la interaccin con otros sistemas.
3. PyOpenCF
La plataforma PyOpenCF, al igual que su
predecesora OpenCF, procura una independencia
software de los servicios finales que sern
ejecutados. La arquitectura software de
PyOpenCF es similar a la de OpenCF, mostrada
en la figura 1, y destaca por un diseo modular:
mdulo servidor y mdulo clientes. Los mdulos
pueden ser extendidos independientemente e
incluso reemplazados para proveer nuevas
funcionalidades sin alterar el resto de
componentes del sistema.


El cliente y el servidor implementan las tres
capas inferiores de la pila que describen los
servicios Web: Descripcin de Servicios,
Mensajera XML y Transporte. El cuarto nivel,
Descubrimiento de Servicios, no ha sido
implementado por motivos de seguridad. Por
tanto, los administradores de sistema siguen
controlando el acceso por parte de los clientes a
las plataformas paralelas a travs de tcnicas
tradicionales de autenticacin.
El servidor gestiona todas las cuestiones
relacionadas con los trabajos, hacindolos
disponibles en el servicio y controlando su estado
y ejecucin. Cuando el servidor HTTP captura
una nueva peticin del cliente, le asocia un hilo de
ejecucin en el que se crea una instancia
independiente del mdulo servidor.
El cliente provee una interfaz para el usuario
final y traduce las peticiones en consultas para el
servidor. El servidor recibe las peticiones desde
los clientes autenticados y las transforma en
trabajos para el gestor de colas. Estos mdulos, a
su vez, estn tambin modularizados. Los
mdulos Control de Acceso, Procesador de
Peticiones y Recolector se pueden encontrar tanto
en el lado del servidor como del cliente. El cliente
tambin mantiene una base de datos para manejar
la informacin generada por el sistema. El
servidor incluye elementos para la generacin de
scripts y lanzamiento de trabajos en el sistema de
colas.
PyOpenCF server es ligero y permite crear
servicios fcilmente a partir de procesos
existentes, con independencia del software. Slo
hay que aadir una descripcin XML que
Figura 1. Arquitectura de OpenCF

especifique el servicio para cada una de las rutinas
disponibles, como puede verse en el algoritmo 1
donde se describe el XML para un cdigo que
calcula la ruta ms corta entre dos puntos. En esta
descripcin se indica la ruta del ejecutable y los
argumentos del mismo. Con lo que podemos crear
un servicio a partir de cualquier herramienta GIS
que nos permita obtener un fichero de resultado a
partir de una serie de parmetros de entrada.

<?xml version="1.0"
encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl"
href="job.xsl"?>

<job
xmlns:xsi="http://www.w3.org/2001
/XMLSchema-instance"
xsi:noNameSpaceSchemaLocation="jo
b.xsd">
<name>Hallar ruta</name>
<service_name>ruta_google</serv
ice_name>
<binary>bin/ruta_google.exe</bi
nary>
<description>Halla la ruta ms
corta usando la API de
google</description>
<argument type="double">
<name>O_lat</name>
<sdesc>Latitud
origen</sdesc>
</argument>
<name>O_lon</name>
<sdesc>Longitud
origen</sdesc>
</argument>
<name>D_lat</name>
<sdesc>Latitud
destino</sdesc>
</argument>
<name>D_lon</name>
<sdesc>Longitud
destino</sdesc>
</argument>
<output_file>
<name>out</name>
<description>Fichero de
salida</description>
</output_file>
</job>
Algoritmo 1. Descripcin XML para un cdigo de
clculo de la ruta ms corta
Debido a que los problemas de planificacin de
rutas pueden ser de un alto coste computacional,
como calcular la matriz distancia entre muchos
puntos, el tiempo de ejecucin puede llegar a ser
elevado. PyOpenCF permite lanzar los procesos y
una vez acabados, enva un correo al cliente para
indicar la finalizacin del proceso y que pueda
acceder a los resultados.
4. Plataforma de servicios
Tal y como se ha indicado, hemos desarrollado
una plataforma basada en servicios web para
problemas de transporte y de logstica, aunque la
arquitectura propuesta podra ser til para muchos
sectores que necesitan procesamiento de datos
espaciales. En concreto, como banco de pruebas,
se han integrado los procesos que facilitan el
clculo de rutas ptimas de reparto.
Se ha desarrollado un nuevo cliente
PyOpenCF con una interfaz grfica que acta
como cliente de los servicios ofertados y permite
el manejo de datos espaciales.

Figura 2. Arquitectura de la plataforma de
servicios.
La plataforma integra bajo una misma vista
servicios proporcionados por diferentes sistemas
de informacin geogrfica que, de forma
"#$%&'($
rver
"
#
$
Pro
ces
os
"#$%&'($

"#$%&'($
PyOpenCF Server
BD
"#$
Procesos
Nuevo Cliente
PyOpenCF Cliente

Interfaz grfica de
datos espaciales
Cliente
PyOpenCF Cliente


autnoma, proporcionan recursos a los usuarios.
As mismo, facilita la incorporacin de terceros
(empresas, centros de investigacin,
administracin pblica) en un marco de
cooperacin que favorezca la complementariedad
de los distintos agentes. Estos servicios se han
incorporado al servidor PyOpenCF siguiendo la
metodologa de este framework y se ofertan al
usuario a travs de una interfaz grfica (figura 2).
4.1. Interfaz grfica
El cliente PyOpenCF proporciona una interfaz
grfica que permite entre otras utilidades, lanzar
trabajos y consultar los resultados. Este mdulo
est desarrollado como un proyecto en Django [4]
un entorno de desarrollo web de cdigo abierto,
escrito en Python, basado en el paradigma del
Modelo Vista Controlador.
En este trabajo se ampla la interfaz grfica
del cliente PyOpenCF para manejar datos con
componente espacial, como se muestra en la
figura 3. Esto permite a los usuarios crear y
visualizar datos de carcter espacial. Para ello se
ha ampliado el entorno de Django con Geodjango,
que contiene las herramientas necesarias para
trabajar con datos de carcter espacial y de esta
forma facilita la construccin de aplicaciones web
SIG. La interfaz acta como cliente de los
servicios proporcionados en la plataforma. La
informacin geogrfica (datos y procesos) se
proporciona como servicio web y el usuario la
solicita a travs de esta u otra interfaz.
Para que esta interfaz sea ms verstil, se ha
aadido a los tipos de datos que PyOpenCF
soporta como argumento el tipo point, que se
compone de dos tipos double (latitud y longitud).
El ejecutable no necesita ser cambiado ya que el
argumento tipo point vuelve a ser convertido en
dos argumentos tipo double por el servidor, pero
para la interfaz grfica es muy til ya que puede
tratar dichos datos como un punto para su
visualizacin y de esta forma poder usar un mapa
para ayudar al usuario a ubicar el punto y
automticamente obtener las coordenadas
geogrficas.

Figura 3. Ejemplo de datos geo-referenciado.
<?xml version="1.0"
encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl"
href="job.xsl"?>

<job
xmlns:xsi="http://www.w3.org/2001
/XMLSchema-instance"
xsi:noNameSpaceSchemaLocation="jo
b.xsd">
<name>Hallar ruta</name>
<service_name>ruta_google</serv
ice_name>
<binary>bin/ruta_google.exe</bi
nary>
<description>Halla la ruta ms
corta usando la API de
google</description>
<argument type="point">
<name>origen</name>
<sdesc>Punto de
origen</sdesc>
</argument>
<argument type="point">
<name>destino</name>
<sdesc>Punto de
destino</sdesc>
</argument>
<output_file>
<name>out</name>
<description>Fichero de
salida</description>
</output_file>
</job>

Algoritmo 2. Descripcin XML para un cdigo de
clculo de la ruta ms corta con tipo
point.
4.2. Servicios i mplementados
Mostramos en esta seccin los servicios
considerados en nuestra plataforma. Con este
grupo de servicios propuestos, se pretende ofrecer
las bases para modelar y resolver algunos de los
principales problemas de transporte.
Geo-referenciar
La mayora de las organizaciones tienen datos
localizados con una direccin postal, como
pueden ser clientes, proveedores, empleados,
etc. Esta direccin postal debe ser geo-
referenciada y de esta forma proporcionar una
nica posicin geogrfica. Este proceso
depende de la base de datos que se consulte y
de la direccin postal suministrada. Por tanto,
es frecuente que en ocasiones no se pueda
identificar una posicin concreta o que haya
varias posiciones posibles.
Una primera implementacin de este
proceso se ha realizado con la API de Google
[1].
Geo-referenciar listado
Este proceso trata de resolver la geo-
referenciacin masiva de datos. De esta forma,
el usuario puede enviar un listado de datos con
direcciones postales y obtener una respuesta
con las coordenadas.
Clculo de la ruta ms corta
El clculo de la ruta ms corta entre dos
puntos a travs de una red es una de las
necesidades ms importantes en los problemas
de transporte. Como ejemplo se hace uso del
clculo del camino ms corto (o rpido) entre
dos puntos usando la API de Google, y por
tanto, su red de carreteras.
Clculo de la mat riz de distancia
La matriz distancia consiste en calcular la
distancia entre todos los puntos dados, y es
uno de los datos necesarios para los
algoritmos de planificacin de rutas. Esta
matriz se obtiene mediante repetidos clculos
del camino ptimo entre dos puntos. La matriz
distancia puede devolver nicamente la
distancia (longitud o tiempo) o la distancia y
toda la descripcin de la ruta para su
representacin.
Planificacin de rutas
Este proceso resuelve el problema de rutas de
vehculos (Vehicle Routing Problem VRP)
[3,16], en concreto la variante con ventana de
tiempo, para lo que necesita un listado de
objetivos geo-referenciados y la matriz de
distancia entre ellos (slo necesita el valor de
la distancia, no la representacin del camino
ptimo). Devuelve un listado ordenado de
objetivos para cada vehculo. Aunque no
devuelve la representacin de la ruta, esta se
puede obtener de la matriz de distancia que se
calcul anteriormente.

Adems de estos servicios se pueden crear
otros o tambin pueden ser duplicados en
diferentes servidores, con diferentes datos de
infraestructura. As entre otros, se pueden ofrecer
procesos que permitan geo-referenciar haciendo
uso de otra base de datos especfica de una regin
concreta y ms detallada; hacer clculo de rutas
con otros mapas de carreteras y ampliados con
datos de trfico, caractersticas especficas de
vehculos, etc.; o tambin ampliar la gama de
algoritmos utilizados en la resolucin de
problemas, de forma que puedan ser evaluados
con datos reales de las empresas.
5. Conclusin y t rabajo futuro
En este artculo se presenta una herramienta Web
para la gestin de procesos con datos geo-
referenciados. Esta herramienta compuesta de
mdulos cliente y servidor extensibles, permite
convertir de forma ligera un ejecutable en un
servicio Web que puede ser gestionado desde la
interfaz de la herramienta y que adems tiene
soporte para la visualizacin de los resultados.
A su vez ejecuta procesos con un alto coste
computacional y la propia plataforma avisa por
correo cuando se ha finalizado el proceso para
poder acceder al resultado.
Mediante la interfaz, se permite a los usuarios
hacer uso de herramientas GIS sin necesidad de
adquirir nuevo software o hardware, y lo que es
ms crtico, sin necesidad de adquirir o mantener
datos geogrficos relevantes. Adems permite a
los investigadores ofrecer sus aplicaciones para
casos reales, sin necesidad de buscar o solicitar los
datos de las empresas.

Una futura mejora de la interfaz grfica es
incrementar los tipos de datos orientados a la
visualizacin.
Como lnea de trabajo futuro se propone la
composicin de procesos, de forma que el usuario
pueda indicar que la salida de un proceso sea
automticamente la entrada de otro sin la
necesidad de interactuar con la plataforma. Esto
plantea nuevos problemas a resolver como la
compatibilidad entre los formatos de salida de un
proceso y de entrada del siguiente. Como lo que
se quiere es aprovechar ejecutables que ya existen
y que no se quieren o pueden adaptar a un
determinado formato de entrada o salida, siempre
se puede crear un nuevo ejecutable de conversin
de formatos entre uno y otro, que establecido
como servicio, se puede usar como proceso
intermedio en la composicin. Para ello, ser
necesario establecer una capa intermedia entre
servidores y clientes, como puede ser un ESB
(Enterprise Service Bus) [11], que permita la
gestin en la composicin de procesos.
Agradeci mientos
Este trabajo ha sido parcialmente financiado por
los proyectos TIN2008-06872-C04-01 y
TIN2008-06570-C04-03 del Gobierno de Espaa,
y ULLAPD-08/01, PIL2210901 y PIL2210902 del
Gobierno de Canarias.
Referencias
[1] API de Google Maps.
http://code.google.com/intl/es-ES/apis/maps
[2] Arampatzis, G., Kiranoudis, C.T.,
Scaloubacas, P., Assimacopoulos, D. A GIS-
based decisin support system for planning
urban transportation policies. European
Journal of Operational Research 152 (2004)
465-475.
[3] Cordeau et al. Vehicle Routing, Handbook in
OR & MS, Vol. 14, Chap. 6, Elsevier, 2007
B.V. DOI: 10.1016/S0927-0507(06)14006-2.
[4] Django. The web framework for perfectionists
with deadlines. http://www.djangoproject.com
[5] European Commission INSPIRE.
http://inspire.jrc.ec.europa.eu
[6] Geodjango. A world-class geographic web
framework. http://geodjango.org
[7] GML:
http://www.opengeospatial.org/standards/gml
[8] INSPIRE Data Specification on Transport
Networks Guidelines 07/09/2009
http://inspire.jrc.ec.europa.eu/documents/Data
_Specifications/INSPIRE_DataSpecification_
TN_v3.0.pdf
[9] Mashup:
http://en.wikipedia.org/wiki/Mashup_%28web
_application_hybrid%29
[10] Open Geospatial Consortium, Inc. OpenGIS
Standards.
http://www.opengeospatial.org/standards
[11] Papazoglou, Michael P. Whats in Service?
Flavio Oquendo (Ed): ECSA 2007, LNCS
4758, pp. 11-28, 2007.
[12] Ro, M., Fraga Fernndez, J.A y A.
Servicios Web con funcionalidad Geogrfica
como herramientas para el anlisis y
generacin de informacin estratgica en las
organizaciones.
[13] Santos, A., Almeida, F., and Blanco, V.
Lightweight web services for high performace
computing. In European Conference on
Software Architecture ECSA2007, number
4758 in Lecture Notes in Computer Science,
Madrid, Spain, Sept. 2007. Springer-Verlag,
Berlin, Heidelberg.
[14] Tarantilis, C.D., Diakoulaki, D., Kiranoudis
C.T. Combination of geographical
information system and efficient routing
algorithms for real life distribution operations.
European Journal of Operational Research
152 (2004) 437-453.
[15] The Open Computacional Framework.
OpenCF. PyOpenCF. http://opencf.pgc.ull.es/
[16] Toth, P., Vigo, D. The vehicle routing
problem. SIAM monographs on discrete
mathematics and application, 2002.
[17] Viamente S.r.l., Route Planner.
http://apps.viamente.com
[18] WFS:
http://www.opengeospatial.org/standards/wfs
[19] WMS:
http://www.opengeospatial.org/standards/wms
[20] WPS:
http://www.opengeospatial.org/standards/wps
Specifying and testing recoverability requirements in
WS-BusinessActivity transactions
Ruben Casado
1

Departamento de InIormatica
Universidad de Oviedo
Spain
rcasadolsi.uniovi.es
Javier Tuya
Departamento de InIormatica
Universidad de Oviedo
Spain
tuyalsi.uniovi.es
Muhammad Younas
Department oI Computing
OxIord Brookes University
OxIord, U.K.
m.younasbrookes.ac.uk

Resumen
Transactions are a Iundamental issue in the reliability oI
web service-based applications, whereas WS-
Coordination and WS-BusinessActivity are the most
recent and widely accepted standards to manage these
processes. This paper addresses the issue oI testing the
web service transactions to which current research has
given little attention. The approach deIines a model to
speciIy the Iunctional requirements oI a WS-
BusinessActivity transaction and risk-based techniques
are used to deIine test cases Ior checking the
recoverability oI the process. A case study is presented
in order to illustrate our approach.
1. Introduction
Transactions are a Iundamental concept in
building reliable distributed applications. A
transaction is a mechanism to ensure all the
participants in an application achieve a mutually
agreed outcome. Traditionally, transactions
Iollowed the ACID model which has widely been
used in the distributed database environment. It
sets Iorward Iour goals that every transaction
management system must achieve: Atomicity,
Consistency, Isolation and Durability.
1

In a Web Services (WS) environment,
transactions are complex, involve multiple parties,
span many organizations, and can have long
duration. Strictly enIorcing the ACID properties is
not appropriate to a loosely coupled world oI
autonomous trading partners due to the increased
length oI time that Iorbids the use oI locks on
resources, and hence makes roll-back activities
impossible. The kind oI transactions which have
these new Ieatures are called long-lived
transactions |14| (also knows as long-running

1
Visiting researcher at OxIord Brookes University
transactions). In order to deal with these new
Ieatures, various extended transaction models
have been adapted Ior WS. These models mainly
relax the strict atomicity and isolation policy oI
ACID properties so that intermediate results oI
active transactions are visible to other transactions
|24|.
In order to manage long-lived WS transactions
several standard speciIications have been
published. Business Transaction Protocol |5| is a
speciIic Iramework to manage transactions but has
not been speciIically designed Ior WS. Web
Services Composite Application Framework |21|
is a Iramework Ior composite applications and has
a speciIic protocol Ior transactions (called WS-
TXM). Web Services Business Process Execution
Language (WS-BPEL) |23| is an executable
language Ior speciIying interactions with WS and
deIines a basic model Ior long-lived transactions.
Web Service Coordination (WS-COOR) |22|,
Web Service Atomic Transactions (WS-AT) |19|
and Web Service Business Activity (WS-BA) |20|
are a set oI speciIic protocols Ior coordinating
ACID and long-lived web transactions. As
indicated by Curbera et al. in |11|, WS-COOR,
WS-BA and WS-AT complement WS-BPEL to
provide mechanisms Ior deIining speciIic standard
protocols to be used by transaction processing
systems, workIlow systems, or other applications
that wish to coordinate multiple WS.
Although the literature presents a number oI
approaches and techniques on WS testing
addressing Ieatures such as unit testing or WS
composition, there is a lack oI research work that
Iocuses on testing WS transactions |7|. The goal
oI our research is to address the problem oI testing
long-lived transactions in WS environments. Our
objective is to deIine speciIic techniques to test
transactions managed with WS-COOR and WS-

BA standards because these are the most recent
and widely accepted standards.
In |8| we presented a conceptual Iramework to
test long-lived WS transactions. Within that work
we studied the transactions Ieatures and proposed
to deIine general svstem properties where risk
analysis could be applied in order to deIine test
case speciIications. Building on that research, in
|9| we deIined the set oI svstem properties
(Composition, Sorting, Visibility, Consistency,
Durability, Controllability, and Recovery) and
introduce how the Fault Tree Analysis (FTA) |18|
technique could be used to deIine test case
speciIications.
In this paper we extend the previous works in
order to enhance the model, speciIy the
transactional requirements and adapt the risk-
based approach to the WS-BA standard. The
practical useIulness oI our approach is illustrated
with a new case study, where the Iunctional
requirements are speciIied using the proposed
model and two test cases are deIined using the risk
scenarios achieved in the FTA.
The rest oI the paper is organized as Iollows.
Section 2 outlines WS-COOR and WS-BA
standards. Section 3 presents the model and
notation proposed to speciIy the transactional
requirements. In Section 4 the model is illustrated
using a case oI study based on our own
experience. The case study is used to show how
the risk scenarios |9| are adapted to deIine
speciIic test cases Ior WS-BA in Section 5. We
compare our approach with existing works in
Section 6. Conclusions and Iuture work are
presented in Section 7.
2. WS transactions standards
The WS-COOR standard deIines the protocol Ior
distributing the coordination context oI a
transaction (i.e. a unique transaction ID,
transaction conIiguration and the deIinition oI
shared inIormation) to its participants. One oI the
WS-COOR tasks is to speciIy the interIace oI a
transaction manager (called coordinator) Ior
creating a new or joining an already existing
transaction.
The coordinator consists oI the Iollowing
services:
Activation service: operations that enable an
application to create a coordination instance or
context.
Registration service: operations that enable an
application and participants to register Ior
coordination protocols.
Protocol service: a set oI coordination types
that deIine how to manage the transaction
(WS-BA Ior long-lived transactions or WS-
AT Ior classic ACID transactions).
When a participant needs to initiate a new
transaction, it requests and receives a coordination
context Irom a coordinator using the Activation
service. The participant who started the
transaction notiIies all the participants by
Iorwarding the coordination context to them.
Then, all the participants register their own
transaction protocols to the coordinator using the
Registration service. Finally, the coordinator
manages the transaction by exchanging messages
with all the transaction participants via the
Protocol service.
Both WS-AT and WS-BA are built on top oI
WS-COOR. The main purpose oI WS-BA is to
coordinate long-running compensation-based
activities that may consist oI several atomic
transactions. AIter a subtransaction is successIully
committed it can be semantically undone
executing a compensation. For instance, a process
dedicates to book a holiday package that consists
oI accommodation, transport and rental car where
each reservation is made by an independent
service. II the transport is cancelled once the hotel
room was booked, it needs to be undone. It means
that the room has to appear as available in the
hotel system and Iurthermore, according to the
conditions the customer may have to pay a penalty
charge.
The WS-BA deIines two coordination types.
An AtomicOutcome coordination type must direct
all participants either to close or to compensate. In
a MixedOutcome type, the coordinator may direct
each individual participant either to close or
compensate.
Figure 1 depicts the main states during the
liIe-cycle oI a participant using WS-BA and the
messages exchanged between each participant and
the coordinator.

Figure 1. WS-BusinessActivity abstract diagram
3. Transaction model
A long-lived transaction in a WS environment is
structured as sagas |13|, a sequence oI several
smaller subtransactions, each with an associated
compensation. II one oI the subtransactions in the
sequence aborts, the compensations associated
with all committed subtransactions are executed in
reverse order. So to ensure the consistency oI the
whole transaction is really important to check the
recoverability oI each subtransaction. In this
section we propose an easy to understand model
and notation to speciIy the transaction Iunctional
requirements. This model will be used to simpliIy
the deIinition oI test cases.
A long-lived Web Service Transaction
denoted by wT comprises a group oI activities
(subtransactions) executed by diIIerent web
services (participants) that can take a substantial
amount oI time to complete. A wT is deIined by
wTS, C,
I
,
E
,
C
~ where S is a set oI
subtransactions, C a set oI compensatory actions,
I
is a set oI states that deIine the requirements so
that each subtransaction can be executed (initial
states),
E
is a set oI states that deIine the
requirements aIter each subtransaction is
completed (executed states) and
C
is a set oI
states that deIine the requirements aIter each
subtransaction is compensated (compensated
states).
The set S{s
1
, . ,s
n
} deIines the
subtransactions where each s
i
is an atomic
transaction or another wT. A subtransaction is
replaceable iI there is another participant that can
execute the same task but using a diIIerent
participant. A subtransaction s
f
is dependent oI s
i
,
denoted s
f
< s
i
, iI it can be executed only aIter s
i

is successIully completed.
A set oI subtransactions S has a concrete
organization, denoted by O(S). We denote s
i
, s
f
iI
the subtransaction s
i
has been Iinished beIore s
f

could begin (serial execution). We denote s
i
[ s
f
iI
both subtransactions can be executed in parallel. It
is denoted [s
i
[ s
f
] to deIine replaceable
subtransactions that can be executed in parallel
and Iinally choose one to be committed. It is used
[s
i
: s
f
] to speciIy that s
i
and s
f
are replaceable and
s
f
can be executed aIter s
i
only iI it has Iinished
incorrectly. II strictly only one can be executed, it
is denoted [s
i
, s
f
]. The graphic notation Ior these
relationships is shown in Figura 2.
s
i
, s
f

s
i
[ s
f

s
f
< s
i

[s
i
: s
f
]

[s
i
[ s
f
]

[s
i
, s
f
]

Figure 2. Graphic notation to speciIy the
subtransactions relationships
Any subtransaction s
i
has a compensatorv action
denoted by c
i
. A compensatory action c
i
undoes,
Irom a semantic point oI view, the actions
perIormed by s
i
, but does not necessarily return
the transaction to the state that existed when the
execution oI s
i
began. The set oI all compensatory
actions is denoted by C{c
1
, ., c
n
}. Any
compensatory action c
i
could be executed only iI
s
i
has been completed. Any compensatory action
may be an empty action, denoted by z.
3.1. Participants and coordinator
A participant p
i
is the service responsible Ior
executing the subtransaction s
i
and perIorming
s
i
s
f

s
i
s
f
s
i

s
f

s
f
s
i

s
i
s
f

s
i

s
f


other necessary tasks such as taking compensatory
action c
i
.
A transaction notification is the
communication between two participants oI a wT.
The notation i
wT
[m
1
]f
wT
is used to denote that the
participant p
i
intervenes in the transaction wT and
sends the message m
1
to another participant p
f
also
part oI the transaction wT. II the participant is the
coordinator, it is denoted by . We use i
wT
[m
1
]f
wT

l
wT
[m
2
]o
wT
. v
wT
[m
n
]:
wT
to denote a
sequence oI transaction notiIications.
A Coordinator is the participant that
manages the subtransactions oI a wT. It executes
diIIerent subtransactions, manages Iailures and
compensations, and collects the results Irom the
participants in order to provide the system with a
consistent state aIter the execution oI a
transaction.
The Internal visibilitv is the coordinator's
ability to show the partial results oI a transaction
and the current state oI the system to an external
agent. This attribute will be required to veriIy the
correct Iunctioning oI the processes involved in
the transactions.
Figure 3 depicts three participants (p
i
, p
f
, p
l
)
involved in two independent transactions (wT
1
,
wT
2
). Both transactions are managed Ior the same
coordinator K.

Figure 3. WS Transactions and participants
3.2. States of a subtransaction
The Initial state
i
is the necessary
requirement so that the participant p
i
can execute
s
i
. The set oI all initial states is denoted by
I
{
1
,. ,
n
}.
The Executed state
*
i
deIines the
requirements that the participant p
i
has to satisIy
once the s
i
execution has correctly Iinished. The
set oI all executed states is denoted by
E
{
*
1
,
.,
*
n
}. The requirements speciIied in an
executed state
*
i
may be included in the
necessary requirements to execute the next
subtransaction s
i1
, speciIied in the initial state
i1
.
The Compensated state
i
deIines the
requirements that the participant p
i
has to satisIy
once the c
i
execution has correctly Iinished. The
set oI all compensated states is denoted by
C

'
1
, ., '
n
}.
The Compensatorv action c
i
undoes, Irom a
semantic point oI view, the actions carried out by
s
i
. The system changes to
i
. This state is not
necessarily equal to
i
due to the impossibility oI
undoing some operations (e.g. undoing a sent
email). We use o
s
i
- o
-
to denote that, starting
Irom the initial state
i
, the executed state *
i
is
reached aIter the subtransaction s
i
is completed
and the next subtransaction(s) can be executed. In
the same way, we use o
-
s
i
- o
i
to denote that,
starting Irom the executed state *
i
, the
compensated state
i
is reached aIter the
compensatory action c
i
is completed and the next
compensatory action(s) can be executed.
The states oI a subtransaction s
i
are shown in
Figure 4. Although the requirements model aims
to be used with all long-lived transactions
protocol, there is a the relationship oI the proposal
model the WS-BA states diagram (Figure 1). Note
that
i
can be mapped with Active state since is the
state beIore executing the subtransaction
(complete message). In the same way,
*
is related
to Completed state and
i
to End state achieved
throw the compensated message.
Figure 4. WS Transactions and participants
4. Case study
We describe a WS transaction-based example in
order to show how our practical approach can be
used to model the Iunctional transactions
requirements and test cases can be deIined to test
them.
Compensate / c
i

Registration
Complete / s
i

i

i
*

i
Closed
Compensated

Grant Service (Figure 5) is a web service
dedicated to the processing oI PhD students
request to work in a Ioreign university. The
service provides complete Iunctionality Ior
scholarship assignation, university request and
registration, accommodation and payment.
The Phd student provides to the service
application the personal details, the dates Ior the
internship and an ordered list oI universities where
he/she is interested to work. A request is
simultaneously sent to the government scholarship
service and to the all candidate universities. AIter
the proposal is analyzed, the scholarship service
responds with the subvention details. The
subvention amount depends oI the country where
the student is going to live and the length that
he/she will stay there. The subvention can be
either accepted or denied. When all the
universities have responded, the best-ranked is
selected based on the student preIerence. The
service notiIies the decision to the rest oI
candidate universities. Whether the subvention is
denied or all universities reject the request, the
process is cancelled and the student will be
notiIied. Once the university has accepted the
proposal and the studentship is assigned, the next
step is to register in the selected university. This
activity is composed Ior two tasks: booking
accommodation in a hall oI residence, and to
register in the research system in order to be able
to use the computers, get an email account and so
on. The last step is charge the accommodation
payment in the student bank account and emails
all scholarship details to the student.
There are multiple dependencies in this
example, among and within that transaction.
ThereIore it is vitally important to ensure
consistency during and at the end oI the process
either it Iinished successIully or cancelled
(recovered the executed actions). Even assuming
that all services work Iine, several dangerous
scenarios can appear due the transactional nature
oI the process. The Iollowing are examples oI
speciIics situations that should be checked:
II an awarded scholarship is rejected by the
student and there are students waiting Ior one,
is a new grant awarded to another student?
II all candidate universities accept the
proposal, is the best-ranked one selected? Do
the remaining universities cancel the
proposal?
II there are no available rooms in the hall oI
residence, is the bank service notiIied to avoid
the payment?
II aIter all tasks are conIirmed the student is
not able to stay all the time, does the bank
return a part oI the grant? Does the hall oI
residence cancel the rest oI the
accommodation?
Figure 5. Grant Service
4.1. Specification
In this section we show how to speciIy the
transactions requirements Ior the Grant Service
using the notation speciIied above . We assume
that the student would study either in University
oI Oviedo(UO) or OxIord Brookes University
(OBU).
1. DeIinition
wIgiantSgiant,Cgiant,Igiant,Egiant,Cgiant
Porticiponts{Scholaiship,00univeisity,
OBUuniveisity, 00hall, OBUhall, 00ieseaich,
OBUieseaich, Payment, Cooiuinatoi]
Sgiant{sscholaiship,s00_uni, sobu_uni,
s00_hall,sbiookes_hall, suo_ieseaich, sobu_ieseaich,
spayment}
Cgiant{cscholaiship,cuo_uni, cobu_uni, cuo_hall,cbiookes_hall,
cuo_ieseaich, cobu_ieseaich, cpayment}
Igiant oscholaiship, ouo_uni, ouo_hall, oobu_uni,
obiookes_hall, ouo_ieseaich, oobu_ieseaich, opayment,}
Scholarship
University
Request
Hall of
Residence
Research
System
Payment
University
Request

Egianto
-
scholaiship,o
-
uo_uni,o
-
obu_uni,
o
-
uo_hall,o
-
obu_hall, o
-
uo_ieseaich, o
-
obu_ieseaich
o
-
payment}
Cgiantoscholaiship,ouo_uni,oobu_uni, ouo_hall,
oobu_hall, ouo_ieseaich, oobu_ieseaich, opayment}
2. Subtransactions
As described in Section 2, there are transactional
requirements that have to be IulIilled. For
example, there is a dependency between the hall
oI residence and the research system; both have to
be owned by the same university. There are also
replaceable relationships since UO and OBU both
can accept the students proposal. The order is
shown in Figure 6.
sscholaiship: It receives the student personal details, the
work duration and the host university details. II the
grant is awarded, the service will contact with the
Payment service in order to transIer the money. The
output is the result about the awarding.
suo_uni anu sobu_uni: Both receive the student proposal
and shall response iI it is either accepted or rejected.
suo_hall anu sobu_hall: Both receive the university
acceptance, the booking dates and the student details.
A room will be booked iI there is any available. Then,
the service will contact the Payment service to charge
the payment Irom the student bank account. The
service shall response with the reserve details.
suo_ieseaich anu sobu_ieseaich: Both receive the student
details and the working dates. The service registers
the student in the research system (email account and
computers access) and shall response either ok iI all
was right or sending a Iailure message.
spayment: It receives the accounts details and the amount
to be transIerred. The service shall response either ok
iI all was right or sending a Iailure message.
0 (Sgiant) (sscholaiship || suo_uni

| sobu_uni]); |(suo_hall
< suo_uni)

, (sobu_hall < sobu_uni)] ; |(suo_ieseaich <
sobu_uni)

, (sobu_ieseaich < sobu_uni) ] ; spayment
Figure 6. Grant Service order
3. Compensatory actions
cscholaiship: To cancel the awarded grant and try to give a
new one to another student.
cuo_uni anu cobu_uni: To cancel the student acceptance.
cuo_hall anu cobu_hall: To cancel the booking and notiIy
to the payment service.
cuo_ieseaich anu cobu_ieseaich: To delete the student Irom
the research system.
cpayment: The bank cancel the students charge.
4. Initial states
oscholaiship: The service shall have received the student
personal details, the work duration and the host
university details.
ouo_uni anu oobu_uni: The service shall have received
the students proposal.
ouo_hall anu oobu_hall: The service shall has received the
student details, the book dates and the university
acceptance.
ouo_ieseaich anu oobu_ieseaich: The service shall have
received the student details, the book dates and the
university acceptance.
opayment: The service shall have received the student
personal inIormation, the grant details and the
accommodation details.
5. Executed states
o
*
scholaiship: The service shall have notiIied the result
about the awarding. II the grant was awarded, the
service has contacted with the Payment service in
order to transIer the money.
o
*
uo_uni anu o
*
obu_uni: Both shall have received the
students proposal. It has been stored in the system
waiting Ior the Iinal decision. AIter the accept/reject
decision was taken, it was sent to the application.
o
*
uo_hall anu o
*
obu_hall: Both shall have notiIied the
result about the reservation. II there were available
rooms, the accommodation was booked Ior the
received dates.
o
*
uo_ieseaich anu o
*
obu_ieseaich: The student shall have
been registered in the research system. A new email
account and personal proIile was created using the
student personal inIormation. The service has notiIied
the register details.
o
*
payment: The grant shall have been deposited in the
students bank account. The accommodation payment
was charged in the same account.
6. Compensated states
o'scholaiship: The awarded grant shall have been
cancelled in the scholarship system. II there were any
students waiting Ior a grant and the dates are still
open, the application has started the process again to
give a new one to another student.
o'uo_uni anu o'obu_uni : The accepted student shall have
been deleted Irom the system. II there were any
rejected students, one oI them has been accepted. The
service has notiIied the new acceptance.
o'uo_hall anu o'obu_hall : The room reservation shall have
been cancelled in the hall oI residence system. The
payment service is notiIied.
sscholaiship
suo_hall
subo_hall
suo_ieseaich
sobu_ieseaich
spayment
suo_uni
sobu_uni

o'uo_ieseaich anu o'obu_ieseaich : The user shall have been
deleted Irom the researcher system so both the email
account and personal proIile were cancelled.
o'payment: II the accommodation had not been charged
yet in the student account, the payment shall have
been cancelled. In other case, the money shall have
been reIunded. II the grant has been deposited, the
money shall have been transIerred again to the
scholarship service account.
5. Test cases specification for the
recovery property
A risk is deIined as an undesirable event that, iI it
occurs, represents a threat to the correct behavior
oI a process |4|. Risk analysis is a set oI
techniques used to investigate problems created
by uncertainty and to assess their eIIects.
Originally it was used in areas such as the nuclear,
chemical and space industries. Nowadays it is
used in soItware development where saIety is also
very important |3|.
The proposed approach uses FTA to derive
hierarchically risk scenarios during the liIe cycle
oI a WS transaction. Each svstem propertv is a
root and the risk tree is elaborated determining the
causes until individual scenarios (leaI nodes) are
achieved |9|.
Figure 7 depicts a small part oI the Iault tree
Ior the Recovery property in order to model the
risks oI the WS transaction compensatory
mechanism. The tree begins with the main risk
(Iailure in the recovery process) that can occur
due to diIIerent causes: the compensatory action is
not executed at all (2) or incorrectly executed (3)
or it Iails due to the loss oI messages between the
participants and the coordinator (4). In order to
illustrate the approach, we Iurther extend the part
oI the branch derived Irom node (4) to reach leaI
nodes that will be used to deIine test cases Ior the
case study in next subsections.
The risk (4) could be due to problems with
participant messages (5) or coordinator messages
(6). The problems related to participant are that it
does not receive the compensation message (7), it
receives the message when it should not receive
this message (8) or the compensate message has
Iinished with timeout (9). When a participant has
problems receiving compensate messages Irom
the coordinator, it could receive the message in an
unsuitable state and wrongly execute the
compensatory action. It means that the participant
receives the message without executing its
subtransaction (10), the participant receives a
compensate message when it has Iinished its
participation in the transaction (11), it receives the
compensate message when it has already executed
its compensatory action (12) or it receives the
compensate message when it does not need to
execute any compensatory action (13).
One oI the possible situations identiIied in (10) is
that a participant was in a failing state (14). This
situation means that a participant was registered in
a transaction wT and then, while it was executing
its subtransaction, the participant reaches the
failing state because a Iailure that has happened.
One possible situation based in (11) is that a
compensate message is received when the
participant has executed its subtransaction and it
was not necessary to execute the compensatory
action, thereIore the participant is in the ended
state (15).
Note that the rest oI non-leaI nodes would be
developed in the same way.

Figure 7. FTA Ior recoverability in WS-BA
LeaI nodes represent likely dangerous
situations that should be tested. Test cases
speciIication Ior WS-BA standard can be
generated Iollowing the hierarchical derivation oI
causes. In the next subsections, leaI nodes (14)
and (15) are used to deIine test cases Ior the case
study using the notation presented in section 4.
5.1. Failing scenario
The Iirst Iailure scenario reIers to a participant
that received a compensate message when it is in a
failing state (leaI node (14), Figure 7). That means
that a problem has occurred while the participant
was executing its subtransaction so that all its
(7) Not received (8) Unsuitable state
(5) Participant
(4) Messages (2) Not executed (3) Incorrectly
(1) Recovery
(6) Coordinator
(9) TimeOut
(11) Finish (12) Compensated (13) MixedOutcome (10) Not complete
(14) Failing (15) Ended

Iunctionality could not have been completed.
ThereIore iI it receives a compensate message and
executes its compensatory action a Iailure will
occur because some Ieatures oI the subtransaction
will be undone when they had not been carried
out. This scenario must be checked Ior each
participant.
In the Grant Service example this scenario has
to be checked. In Table 1 we present a test case in
order to avoid that a new student is accepted when
it is not able. Assume that the UOuniversitv
service notiIies a Iailure while was studying the
proposal, but anyway there are no vacancies Ior
new students. The original student was not
accepted but due to the compensate message, the
services notiIies to a new student because, to its
knowledge, there is a vacancy. That new student
may reject other universities and at least, he would
not be able to be registered in neither oI the
universities.
Preconditions wTgrant is correctly initialized.
Input
sequence
UOuniversitv
grant
[register]K -
OBUuniversitv
grant
[register]K -
K[complete] UOuniversitv
grant
-
UOuniversitv
grant
[fail]K -
K[compensate] UOuniversitv
grant

Expected
output
UOuniversitv

ignores the
compensate message so does not
execute cuo_uni. Thus the system
remains in ouo_uni so o
*
uo_uni is not
met. UOuniversitv

still waits Ior
the failed message.
Table 1. Failing test case Ior Grant Service
5.2. Ended scenario
The second unsaIe scenario reIers to a participant
that has Iinished correctly its mission in the
transaction executing its subtransaction, (leaI node
(15), Figura 7). So it means that it receives the
compensate message when it is in the ended state.
This could occur due to a coordinator problem but
the participant must be ready to ignore the
compensate message because iI it accepts the
message the subtransaction will be undone.
A test case deIinition Ior the Grant Service
Iollowing this leaI node is illustrated in Table 2.
This Iault could cause that once the transaction
has Iinished the OBU research service delete the
user Irom the system. Due to the Iact that
OBUresearch participant is in the ended state, it
will not be able to report to the coordinator so
apparently the transaction will be correctly
Iinished. II the OBUresearch accepts the
compensate message when has already Iinished in
the transaction the student would be deleted Irom
the system. In other words, he/she would lose its
personal proIile with the emails, working on
documents, etc.
Preconditions
wTgrant is correctly initialized.
o
*
obu_ieseaich
reached.
Input
sequence
OBUresearch
grant
[register]K -
K[complete] OBUresearch
grant
-
OBUresearch
grant
[completed]K -
K[ended] OBUresearch
grant
-
K[compensate] OBUresearch
grant

Expected
output
OBUresearch
grant
ignores the
compensate message so does not
execute cobu_ieseaich. Thus the
system remains in o
*
obu_ieseaich so
o'obu_ieseaich is not met.
Table 2. Ended test case Ior Grant Service
6. Related work
Most literature on the topic deals with business
transaction modeling Irom a design
perspective|1,6|. Chalin |10| demonstrates how
business transaction requirements can be captured
in use case models, whereas Banagala |2|
proposes to use the Problem Frames Approach.
Unlike those works, we propose a new easy to
understand model to deIine the Iunctional
requirements oI a WS-BA transaction that
Iacilitate to derive tests.
To the best oI our knowledge, there are no
practical approaches to test WS-BA transactions.
Some works are Iocused on veriIying the long-
lived transactions Irom a theoretical point oI view.
Lanotte |16| developed a model oI
Communicating Hierarchical Timed Automata
suitable to describe long-running transactions and
the automaton-theoretic approach allows the
veriIication oI properties by model checking.

Emmi |12| proposes a technique to translate
programs with compensations to tree automata in
order to veriIy compensating transactions
supporting the illusion oI atomicity. Li |17|
proposes a Iormal model to veriIy the requirement
oI relaxed atomicity with temporal constraints.
Unlike other works, our approach studies the
viability oI a practical approach in contrast to
other research where a theoretical model is used to
Iormal veriIication. Our work is Iocused in to
determine risk scenarios where dynamic testing
has to be applied, in order to deIine test cases
speciIications to test the WS-BA standard.
7. Conclusions and future work
We have presented a practical approach to test the
recoverability in WS-BA transactions. This
approach uses an easy to understand model to
speciIy Iunctional requirements in long-lived
transactions in order to be tested. The test cases
are deIined Iollowing the scenarios achieved in a
risk analysis using the Fault Tree Analysis
technique. The approach is illustrated with a case
study. Since the transactions are based on
diIIerent independent services, the objective oI
this work is to improve the integration testing.
Further research is required to analyze the
relationship and complementarity oI this approach
with other testing techniques.
A short-term work is to execute the deIined
test cases in a real implementation by developing
the presented example (i.e. using Jboss
Transactions |15| API) in order to measure the
quality oI the test cases. We will also work to
improve the transaction model to make it
independent oI the protocol used. That generic
model would be used to speciIy both Iunctional
requirements and risks in order to make easier the
test cases generation.
Referencias
|1| AlriIai, M., P. Dolog and W. Nejdl,
'Transactions Concurrency Control in Web
Service Environment, Proc. oI ECOWS '06,
2006.
|2| Banagala, V., 'Analysis oI transaction
problems using the problem Irames
approach, International workshop on
Advances and applications oI problem Irames,
2006.
|3| Bennett, J., Bohoris, G., Aspinwall, E. and
Hall, R., 'Risk analysis techniques and their
application to soItware development,
European Journal oI Operational Research,
1996, vol. 95, pp. 467-475.
|4| Benoit, A., Patri, M. and Rivard, S., 'A
Iramework Ior inIormation technology
outsourcing risk management, ACM SIGMIS
Database, 2005, vol. 36, pp. 9-28.
|5| Business Transaction Protocol. |Online|.
Available: http://www.oasis-
open.org/committees/download.php/1184/200
2-06-03.BTPctteespec1.0.pdI
|6| Butler, M., C. Ferreira and M. Ng, 'Precise
modeling oI transactions and its application to
BPEL, Journal oI Universal Computer
Science, 11, 2005.
|7| CanIora, G. and Di Penta, M., 'Service-
Oriented architectures testing: a survey,
Lecture Notes in Computer Science, 2009,
vol. 5413, pp. 78-105.
|8| Casado, R., Tuya, J., 'Testing transactions in
service oriented architectures, 9th
International ConIerence on Web
Engineering, DC, 2009
|9| Casado, R., Tuya, J. and Younas, M., 'Testing
long-lived web services transactions using a
risk-based approach,10
th
International
ConIerence on Quality SoItware, 2010
|10| Chalin, P., Sinning, D. and Torkzadeh, K.,
Capturing business transaction requirements
in use case models, ACM symposium on
Applied computing, 2008.
|11| Curbera, F., KhalaI, R., Mukhi, N., Tai, S.
and Weerawarana, S., 'The next step in web
services, Communications oI the ACM,
2003, vol. 46, pp. 29-34.
|12| Emmi, M. and Majumdar, R. , 'VeriIying
compensating transactions, Lecture Notes in
Computer Science, 2007, vol. 4349, pp. 29-43
|13| GarciaMolina, H. and Salem, K., 'Sagas,
ACM SIGMOD Record, 1987, vol. 16, pp.
249-259.
|14| Guidi, C., Lucchi, R. and Mazzara, M., 'A
Iormal Iramework Ior web services
coordination, Electronic Notes in Theoretical
Computer Science, 2007, vol. 180, pp. 55-70.
|15| JBoss Transaction. |Online|. Available:
http://www.jboss.org/jbosstm

|16| Lanotte, R., Maggiolo-Schettini, A., Milazzo,
P. and Troina, A., 'Design and veriIication oI
long-running transactions in a time
Iramework, Science oI Computer
Programming, 2008, vol. 73, pp. 76-94.
|17| Li, J., Zhu, H. and He, J., 'SpeciIying and
veriIying web transactions, 28th IFIWG 6.1
Int. conI. on Formal Techniques Ior
Networked and Distributed Systems, 2008, pp.
149-168
|18| Vesley, W., Goldberg, F., Roberts, N. and
Haasl, D., 'Fault tree handbook, NUREG-
0492, U.S. Nuclear Regulatory Commission,
1981.
|19| Web Service Atomic Transactions. |Online|.
Available: http://docs.oasis-open.org/ws-
tx/wstx-wsat-1.2-spec-os/wstx-wsat-1.2-spec-
os.html
|20| Web Service Business Activity. |Online|.
tx/wstx-wsba-1.2-spec-os/wstx-wsba-1.2-
spec-os.html
|21| Web Services Composite Application
Framework. |Online|. Available:
http://docs.oasis-open.org/ws-caI/ws-
context/v1.0/OS/wsctx.html
|22| Web Service Coordination. |Online|.
tx/wstx-wscoor-1.2-spec-os/wstx-wscoor-1.2-
spec-os.html
|23| WS-BPEL. |Online|. Available:
http://docs.oasis-
open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html
|24| Younas, M., Chao, K., Lo C. and Li Y., 'An
eIIicient transaction commit protocol Ior
composite web services, 20th International
ConIerence on Advanced InIormation
Networking and Applications, 2006, vol. 1,
pp. 591-596.

Una Adaptacin Unificada para Servicios Web
AlIonso Garcia de Prado Fontela
Departamento de Lenguajes y Sistemas InIormaticos
Escuela Superior de Ingenieria, Universidad de Cadiz
alIonso.garciadepradogmail.com
Guadalupe Ortiz Bellot
Grupo Quercus de Ingenieria del SoItware
Universidad de Extremadura
1

gobellotunex.es

1
En la actualidad G. Ortiz pertenece al departamento de Lenguajes y Sistemas InIormaticos de la Universidad de Cadiz.
Resumen

Los servicios Web han supuesto un exito para las
comunicaciones independientes de plataIorma
entre aplicaciones distribuidas. Aunque hay
multiples ejemplos de buenas practicas en el
diseo, desarrollo y gestion de servicios Web, no
hay propuestas eIicientes para aquellos escenarios
en los que se requiere la adaptacion del servicio en
Iuncion del contexto, el dispositivo o el propio
cliente. Las aproximaciones actuales se centran
principalmente en la adaptacion de la aplicacion
cliente; sin embargo, otra opcion es llevar a cabo
la adaptacion en el servicio evitando sobrecargar
la aplicacion cliente. En este articulo, proponemos
la adaptacion del servicio, salvaguardando
siempre la estructura de la implementacion de su
Iuncionalidad principal mediante el uso de codigo
orientado a aspectos para la adaptacion; es mas, le
Iacilitamos la labor al desarrollador mediante un
procedimiento dirigido por modelos. De este
modo, a partir de los modelos del sistema,
generamos automaticamente un codigo bien
estructurado y desacoplado para Iacilitar la
adaptacion del servicio.
1. Introduccin
Los servicios Web permiten una comunicacion
eIectiva, debilmente acoplada e independiente de
plataIorma entre aplicaciones distribuidas |1|,
Iacilitandonos la creacion de sistemas soItware de
gran Ilexibilidad y mas Iacil mantenimiento. Se
trata de aplicaciones modulares auto-descriptivas,
que pueden ser publicadas, localizadas e
invocadas desde cualquier punto de la red.
Ademas, el exito de los servicios Web radica en la
seleccion de XML como lenguaje comun de
intercambio de inIormacion, satisIaciendo la
necesidad de interoperabilidad entre las
aplicaciones Web.
A pesar de la existencia de excelentes
procedimientos para el diseo, desarrollo y
gestion de servicios Web, hay areas en las que se
producen necesidades especiIicas que requieren la
adaptacion de los servicios. Por ejemplo, podemos
tener servicios para los que seria conveniente
adaptar sus respuestas al contexto especiIico del
cliente que los invoca, la respuesta de otros
servicios podria adaptarse dependiendo del tipo de
dispositivo que realiza la invocacion o servicios
que podrian devolver diIerentes respuestas
dependiendo del cliente que lo este usando. Estas
adaptaciones de los servicios Web deberian
implementarse manteniendo la naturaleza
debilmente acoplada de los servicios, asi como
permitiendo la integracion de su implementacion
en el ciclo de vida completo del servicio.
Las aproximaciones actuales enIocan la
solucion a este problema desde el punto de vista
del cliente: seria la implementacion del cliente la
que tendria que adaptar la respuesta del servicio al
contexto, al dispositivo o al cliente. Sin embargo,
esto puede poner en peligro el resultado de una
invocacion. Por ejemplo, puede darse el caso de
que un dispositivo movil no tenga suIiciente
memoria para tratar la inIormacion recibida desde
un servicio cuya respuesta no ha sido adaptada
para este tipo de dispositivos. Esto nos puede
obligar a hacer uso de recursos innecesarios en el
cliente, lo que podria evitarse llevando a cabo la
adaptacion en el servicio, donde se supone que los
recursos son mucho mayores. No solo eso, ademas
podemos obtener respuestas muy genericas desde
aquellos servicios que no tienen en cuenta el
contexto; comportamiento que puede ser mejorado
si permitimos la adaptacion de los servicios Web
en Iuncion del contexto de los clientes.

En este sentido, proponemos un enIoque
dirigido por modelos en el que podemos
especiIicar que adaptaciones requiere el servicio
desde las primeras etapas de su desarrollo. De esta
Iorma, sugerimos que las adaptaciones requeridas
sean especiIicadas en los modelos del sistema.
Ademas, proponemos una adaptacion orientada a
aspectos, evitando la necesidad de crear codigo
intrusivo en el codigo Iuente principal del
servicio, asi como Iacilitando la tarea al
desarrollador de aadir, si Iuera necesario a lo
largo de la vida util del servicio, nuevo codigo
para su adaptacion. Ademas, nos enIrentaremos al
problema de la adaptacion desde diIerentes
perspectivas (contexto, dispositivo, usuario, etc.)
mediante una unica metodologia con el Iin de
uniIicar y simpliIicar la solucion, disminuyendo la
complejidad de la implementacion del sistema.
El resto del articulo esta organizado de la
siguiente Iorma: La seccion 2 proporciona varios
ejemplos sobre la necesidad de adaptacion en el
servicio. Despues, la Seccion 3 explica como se
lleva a cabo el desarrollo dirigido por modelos
para la adaptacion de servicios. A continuacion,
en la seccion 4 resumimos como se ha utilizado la
orientacion a aspectos para la implementacion de
dicha adaptacion de una Iorma no intrusiva. En la
seccion 5 comentamos trabajos relacionados y,
Iinalmente, las conclusiones y los planes de
trabajo Iuturo se exponen en la seccion 6.
2. Motivacin
En los siguientes parraIos describimos varios
escenarios en los que podemos necesitar la
adaptacion de servicios Web.
! La adaptacion al contexto es un tema
recurrente en la investigacion actual. En el
caso de los servicios Web podemos encontrar
varios ejemplos: cuando estamos buscando
restaurantes en una ciudad determinada
obtendremos una lista ordenada dependiendo
de la localizacion exacta desde donde
hagamos la consulta, o dependiendo del
idioma conIigurado en el dispositivo
invocador, podemos devolver el resultado del
servicio en dicho idioma. Podemos encontrar
algunas propuestas sobre estos temas, pero en
general estan enIocadas desde el punto de
vista de la modiIicacion del codigo cliente y
no de la adaptacion del servicio.
! La adaptacion a los dispositivos tambien ha
tomado gran relevancia recientemente debido
al gran aumento del uso de dispositivos
moviles. Incluso siendo conscientes de que los
dispositivos moviles han evolucionado
considerablemente, que tienen mayores
pantallas y tambien procesadores mas
eIicientes que los dispositivos anteriores, no
se pueden comparar con la potencia y
capacidad de un PC ni con una TFT de 19
pulgadas. La principal razon es obviamente
que los PCs y los dispositivos moviles no
persiguen el mismo objetivo, siendo la
movilidad la principal meta de los ultimos. Sin
embargo, los usuarios de dispositivos moviles
actualmente quieren hacer uso desde su
teleIono movil de los mismos servicios a los
que acceden desde un ordenador de sobremesa
y, por lo tanto, necesitamos adaptar dichos
servicios. En |6| se puede encontrar
inIormacion sobre un caso de estudio concreto
en el que seria necesaria esta adaptacion, asi
como el trabajo que hemos realizado
previamente en este area.
! Finalmente, los escenarios Software as a
Service (SaaS) requieren la personalizacion de
los servicios. Estos son alojados por un
distribuidor o proveedor de servicios y
oIrecidos a diIerentes clientes a traves de
Internet, demandando por tanto una
adaptacion en Iuncion de las necesidades
especiIicas de cada cliente (multitenancv).
La manera de abordar la adaptacion en cada
uno de estos escenarios no deberia recaer en el
lado del cliente (en algunos casos, como en el
escenario SaaS, es absolutamente inviable).
Ademas, el problema deberia abordarse con una
unica metodologia, Iacilitando las tareas del
desarrollador y disminuyendo la complejidad del
sistema desarrollado. En las siguientes secciones
proponemos un enIoque dirigido por modelos
orientado a aspectos para hacer Irente a la
adaptacion de servicios Web desde las diIerentes
perspectivas propuestas.
3. Adaptacin de servicios Web mediante
un desarrollo dirigido por modelos
En esta seccion presentamos las arquitecturas
dirigidas por modelos y como se lleva a cabo la
adaptacion del servicio dirigida por modelos.

3.1. Arquitecturas dirigidas por modelos
La comunidad de ingenieria del soItware esta
migrando hacia el desarrollo de aplicaciones
basadas en modelos y no en tecnologias. El
desarrollo dirigido por modelos nos permite
Iocalizar los aspectos esenciales de nuestro
sistema, retrasando la decision de la tecnologia
especiIica de implementacion para un paso
posterior. Podremos hacer uso de los modelos
necesarios en las distintas Iases del desarrollo,
desde las especiIicaciones iniciales del sistema
hasta su testeo y despliegue, con el Iin principal
de permitir la separacion de la tecnologia Iinal de
implementacion de la logica de negocio del
sistema. Posteriormente, las transIormaciones
entre modelos y de modelo a codigo nos
permitiran un desarrollo semi-automatico del
sistema a partir de los modelos de este.
Asi pues, el principal objetivo de las
Arquitecturas Dirigidas Por Modelos (MDA) |12|
es la promocion de los modelos en el desarrollo de
soItware. En dichas arquitecturas se realiza una
clasiIicacion de los modelos en varias categorias:
Modelos Independientes de la Computacion
(CIM), que proporcionan inIormacion sobre los
requisitos del sistema en un lenguaje especiIico
del dominio y que normalmente escapa de las
competencias del desarrollador; Modelos
Independientes de Plataforma (PIM),
representando el sistema sin ninguna ligadura
especiIica a la plataIorma o lenguaje de
implementacion; Modelos Especificos de
Plataforma (PSM), los cuales caracterizan el
sistema ligado a una plataIorma, tecnologia y
lenguaje de programacion especiIico y, Iinalmente
la capa de codigo, que proporciona el codigo de
la aplicacion Iinal. Tambien Iorman parte del
proceso un conjunto de reglas de transIormacion
que se utilizaran para convertir automaticamente
los modelos independientes de plataIorma en
modelos especiIicos de plataIorma y mas tarde
estos en el codigo Iinal de la aplicacion.
3.2. Desarrollo dirigido por modelos de la
adaptacin del servicio
En este articulo proponemos un metodo uniIicado
para la adaptacion de los servicios Web. Este
metodo deberia proveer una sintaxis comun para
describir las diversas adaptaciones requeridas por
el servicio, asi como la Iorma de incluir dichos
requerimientos en los modelos del sistema.
Figura 1. Modelo del servicio estereotipado para su
adaptacion al dispositivo invocador.
En nuestros trabajos anteriores hemos usado una
serie de estereotipos para marcar los elementos del
modelo que deberian ser adaptados segun las
invocaciones desde diIerentes dispositivos (Iigura
1). En la Iigura podemos ver, por una parte, que se
ha marcado la Iuncion Operation1 del servicio
con el estereotipo ws4md (Web service for mobile
device) lo que quiere decir que este servicio va a
devolver los objetos (Info) adaptados en Iuncion
del tipo de dispositivo que lo invoque. Por otra,
vemos que hay una serie de atributos marcados
con el estereotipo cldc (cldc representa la
conIiguracion de JavaMe Connected Limited
Device Configuration, normalmente usada por
dispositivos moviles); estos van a ser los unicos
atributos que seran devueltos si quien realiza la
invocacion es un dispositivo movil. Desde este
modelo independiente de plataIorma y aplicando
una serie de reglas de transIormacion, obtenemos
un modelo especiIico de plataIorma (ver Iigura 2),
a partir del cual vamos a poder generar
automaticamente el codigo necesario para la
adaptacion del servicio al dispositivo invocador.
Los detalles de implementacion estan Iuera del
ambito de este articulo y aceptados para su
publicacion en |7|.
Figura 2. Modelo especiIico de plataIorma obtenido a
partir del modelo de la Figura 1.

En este sentido, continuamos con el trabajo
realizado hasta ahora, siendo nuestro objetivo
extender el conjunto de estereotipos deIinidos
para la adaptacion no solo a dispositivos, sino
tambien al contexto, asi como para la
personalizacion en entornos SaaS. En cualquier
caso, siempre sera nuestro objetivo mantener una
sintaxis y metodologias uniIicadas para la
adaptacion de los servicios.
4. Adaptacin de servicios Web usando
tcnicas de orientacin a aspectos.
En esta seccion introducimos la programacion
orientada a aspectos y como el uso de tecnicas de
orientacion a aspectos Iacilita la adaptacion de los
servicios.
4.1. Programacin orientada a aspectos
La Programacion Orientada a aspectos surge
debido a determinados problemas detectados en la
Programacion Orientada a Objetos: se supone que
la programacion orientada a objetos permite la
encapsulacion y modularizacion de datos y
metodos con un objetivo comun. Sin embargo, a
veces resulta imposible modelar diversas
caracteristicas de interes de nuestro sistema en una
unica descomposicion estructurada de este. Esto
es asi por la existencia de determinadas
propiedades de interes de nuestro sistema,
denominadas crosscutting concerns bajo la
nomenclatura de AOP (propiedades que cortan y
atraviesan) que, al no poderse incluir en la
estructura logica del codigo, causan que el codigo
se encuentre mezclado y disperso a lo largo de la
aplicacion.
AOP describe cinco tipos de elementos para
modularizar los crosscutting concerns |2|: en
primer lugar, el modelo de puntos de union, que
nos indica los puntos en los que podria incluirse el
nuevo comportamiento. A continuacion, la manera
de especiIicar los puntos de union concretos de
nuestra aplicacion. Despues, como especiIicar el
nuevo comportamiento a inyectar en los puntos de
union. Finalmente, encapsularemos los puntos de
union y su comportamiento asociado en unidades
independientes que, por ultimo, son tefidas con el
codigo original.
El analisis e integracion de distintos
crosscuting concerns, utilizando tecnicas AOP,
ya se utiliza con exito en el ambito de los
Servicios Web para desacoplar propiedades no
Iuncionales |8| o para el control y la gestion de la
calidad de servicio |5|, manteniendo en ambos
casos el codigo bien modularizado y encapsulado.
En este articulo haremos uso de AOP para
implementar el codigo necesario para la
adaptacion del servicio, tal como explicamos a
continuacion.
4.2. Adaptacin de servicios Web orientada a
aspectos
Como hemos mencionado anteriormente, el uso de
AOP para implementar el codigo requerido en la
adaptacion de los servicios nos proporciona la
posibilidad de desarrollar el sistema sin generar
codigo intrusivo en la parte que implementa la
Iuncionalidad principal del servicio. Ademas,
cualquier adaptacion requerida por necesidades
Iuturas, podra ser incluida Iacilmente en el
servicio; asi como el mantenimiento general del
sistema se simpliIica y Iacilita gracias a la
implementacion orientada a aspectos.
El Servicio podria devolver diIerentes resultados
dependiendo de su adaptacion. Por ejemplo, como
hemos descrito en la seccion 2, el servicio puede
devolver una lista diIerente de restaurantes en
nuestra ciudad dependiendo de la localizacion de
nuestro GPS. Otro ejemplo podria ser devolver un
resultado adaptado dependiendo del dispositivo
que realiza la invocacion, tal como se explica en
|6|.
En cualquier caso, cuando adaptamos el
servicio, ya sea al contexto, al dispositivo
invocador o al usuario invocador, necesitaremos
alguna inIormacion que debera ser proporcionada
en la invocacion del cliente, para poder conocer
cual es el contexto, dispositivo o usuario en
cuestion que esta llevando a cabo la invocacion.
Esta inIormacion se puede incluir en la cabecera
del mensaje SOAP en el cliente; un handler en el
servicio sera el encargado de recuperar esta
inIormacion de la cabecera del SOAP que indica
el contexto, tipo de dispositivo o usuario
especiIico de la invocacion realizada. Esta
inIormacion estara disponible para las clases del
servicio y para el aspecto que implementa la
adaptacion.

Adicionalmente, el aspecto, cuyo codigo
podemos ver en la Figura 3, interceptara cualquier
invocacion al servicio que pueda requerir una
adaptacion y obtendra la inIormacion pertinente
de la cabecera del mensaje SOAP. Esta
inIormacion, relacionada con el contexto,
dispositivo, usuario o cualquier otro area donde se
requiera adaptacion, sera procesada por el aspecto,
que procedera a adaptar la respuesta del servicio
en los casos en los que sea necesario.
La declaracion del aspecto la podemos
encontrar en la linea (1). La linea (2) especiIica el
poincut, es decir, el punto el cual vamos a
interceptar. Como podemos ver, vamos a
interceptar la ejecucion de Operation1 en Class1.
Desde las lineas (3) a (9) implementamos el
codigo que va a ejecutarse en el punto
interceptado del programa (el advice). La palabra
reservada around en la linea (3) indica que el
codigo va a ser ejecutado en lugar de la operacion
interceptada, y para ello el aspecto ha de retornar
la misma clase que la operacion interceptada. En
la linea (4) obtenemos el tipo de contexto que esta
indicado en la cabecera del mensaje SOAP
recibido. Despues, en la linea (5) procedemos a la
ejecucion normal de la operacion interceptada,
recogiendo el resultado en un tipo extendido. A
continuacion, dependiendo del contexto (en este
caso si es un dispositivo CLDC), en las lineas (6)
a (8) convertimos el resultado en un objeto acorde
a dicho contexto.
Es importante destacar que se ha optado por
esta solucion, basada en el uso de la cabecera del
mensaje SOAP, como medio para hacer
consciente al servicio del contexto del cliente o de
las caracteristicas del dispositivo o del usuario,
tras el estudio y evaluacion de diversas
alternativas. Para mas inIormacion sobre dicho
estudio y los criterios en Iuncion de los cuales se
ha elegido esta metodologia se pueden consultar
en |6| y |7|.
5. Trabajos relacionados
La mayor parte de los trabajos que podemos
encontrar en el area de adaptacion al contexto se
centran especialmente en la composicion de
servicios dependiendo del contexto (por ejemplo,
la disertacion de Vukovic |11|) o en la adaptacion
del cliente (ver el trabajo de Kolari et al |4|).
Ambos son trabajos destacables; sin embargo
consideramos que la adaptacion podria realizarse
en el lado del servicio, evitando descargar toda la
responsabilidad en la implementacion del cliente.
Otro articulo objeto de estudio es el de Pauty et.al
|9|, donde se propone el desarrollo del servicio
consciente del contexto mediante una propuesta
basada en una ontologia dependiente de su
plataIorma. La alternativa que nosotros
proporcionamos pretende ser independiente del
entorno de trabajo y deberia poder usarse bajo
cualquier plataIorma. Ademas, es importante
poder deIinir las necesidades de adaptacion del
servicio desde los modelos iniciales del sistema.
En relacion con la personalizacion en entornos
SaaS, Stollberg et al. presentan una propuesta
dirigida por modelos |10|; sin embargo, no se
considera la opcion de mantener el codigo
relacionado con la personalizacion desacoplado
del codigo principal del servicio; punto primordial
a tener en cuenta para Iacilitar Iuturas
personalizaciones para diversos clientes.
Con respecto a las propuestas centradas en el
lado del servicio, en la aproximacion de Keidl et
al. |3| el contexto siempre se incluye en la
cabecera del mensaje tanto del cliente como del
servicio, los cuales ademas han de acceder a un
framework especiIico para actualizar el contexto.
Esto implica por una parte, que tanto el servicio
como el cliente han de procesar la cabecera, sin
embargo no especiIica que hace el cliente con la
inIormacion de contexto recibida; por otra, que la
aplicacion se vuelve especiIica de plataIorma y
(1) public aspect Adapting_Operation1{
(2) pointcut p_Operation1() : execution(* Class1.Operation1();
(3) Info_Base around() {
(4) contextType context= MyHandlerClass.getContextType();
(5) Info_Extended tmp = (Info_Extended) proceed();
(6) if (context==contextType.CLDC){
(7) BookInfo_Base tmp2 = tmp.convertToBase();
(8) tmp=tmp2;}
(9) return tmp; } }
Figura 3. Codigo del aspecto que adapta la respuesta del servicio.

pierde la versatilidad propia de una aproximacion
mas generica. En nuestra propuesta, la respuesta
proporcionada por el servicio se encuentra ya
adaptada a las necesidades del cliente, el cual
puede procesar el resultado normalmente. Es mas,
en nuestra propuesta los servicios no necesitan ser
conscientes inicialmente del procesado del
contexto, ya que esto se puede incluir en tiempo
de compilacion mediante el uso de aspectos.
6. Conclusiones y trabajo futuro
En este articulo hemos motivado la necesidad de
adaptar los servicios Web en multiples escenarios
y hemos descrito como las aproximaciones
actuales enIocan dicha adaptacion principalmente
mediante la modiIicacion de la implementacion
del cliente. Nosotros proponemos que la
adaptacion se lleve a cabo en el lado del servicio,
ahorrando de este modo recursos en el cliente, asi
como permitiendo un mayor espectro de posibles
usuarios.
Nuestra propuesta consiste en un desarrollo
dirigido por modelos que nos permite identiIicar y
especiIicar la adaptacion requerida por el servicio
desde los modelos iniciales del sistema. Ademas,
el uso de codigo orientado a aspectos en la
implementacion de la adaptacion nos permitira
mantener el codigo original de la Iuncionalidad
principal del servicio completamente desacoplado
y separado del codigo de adaptacion, Iacilitando el
mantenimiento de Iuturos cambios en los
requerimientos de adaptacion, asi como
habilitando la posibilidad de proporcionar
adaptaciones dinamicas.
Asi pues, es parte de nuestro trabajo Iuturo
extender la metodologia para la adaptacion al
dispositivo que hemos desarrollado en trabajos
anteriores |6, 7, 8| para poder disIrutar de una
unica metodologia que englobe la adaptacion para
diversos tipos de escenarios adicionales.
Agradecimientos
Este trabajo esta Iinanciado por el Ministerio de
Ciencia e Innovacion (proyecto TIN2008-02985),
por Iondos FEDER y por la Universidad de
Extremadura y el Banco Santander (proyecto A7-
01 convocatoria 2009).
Referencias
|1| Alonso, G., Casati, F. Kuno, H. and
Machiraju, V., Web services- Concepts,
Architectures and Applications, Springer-
Verlag, 2004
|2| Elrad, T., Aksit, M., Kitzales, G., Lieberherr,
K. and Ossher, H.: Discussing Aspects oI
AOP. Communications oI the ACM, Vol.44,
No. 10, p 33-38, October 2001
|3| Keidl, M. and Kemper, A. Towards Context-
Aware Adaptable Web Services. Int. WWW
ConI. on Alternate, p 55-65. New York, 2004.
|4| Kolari, J., Laak, T., Hien, T., Ikonen V.,
Kulju, M., Suihkonen, R., Toiovonen, S. and
Virtannen T. Context-Aware Services Ior
Mobile Users (technology and User
Experiences). VTT InIormation Technology
Publications 539, Finland 2004.
|5| Ortiz, G., Bordbar, B. Aspect-Oriented
Quality oI Service Ior Web Services: a Model-
Driven Approach. IEEE I. ConI. on Web
Services. Los Angeles (USA), 2009.
|6| Ortiz, G. and Garcia de Prado, A. Mobile
Aware Web Services. I. ConI. on Mobile
Ubiquitous Computing, Systems, Services and
Technologies, p.65-70. Malta 2009.
|7| Ortiz, G.and Garcia de Prado, A. Improving
Device-Aware Web Services and their Mobile
Clients through an Aspect-Oriented, Model-
Driven Approach. InIormation and SoItware
Technology Journal (aceptado para su
publicacion).
|8| Ortiz, G. Hernandez, J. Aspect-oriented
techniques Ior Web services: a model-driven
approach. Int. J. Business Process Integration
and Management, Vol. 2, No. 2, 2007.
|9| Pauty, J., Preuveeners, D., Rigole, P., Berbers,
Y. Research Challenges in Mobile and
Context-Aware Service Development. W. on
Research Challenges in Mobile and Context-
Aware Service Development, Austria 2006
|10| Stollberg, M. and Muth, M. Service
Customization by Variability Modeling.
Workshop on Engineering Service-Oriented
Applications (WESOA). Sweeden, 2009.
|11| Vukovic, M., Context-Aware Service
Composition. Technical Report University oI
Cambridge, N. 700, United Kingdom, 2007.
|12| Model Driven Architecture.
http://www.omg.org/mda/.
Arquitectura orientada a servicios para proporcionar
accesibilidad
1
Marta Alvargonzalez

Barclays Bank Espaa,
Area de Tecnologia
Malvargonzalez.barclaysinredis.es
Esteban Etayo
Barclays Bank Espaa,
Area de Tecnologia
Eetayo.barclaysinredis.es
Jose Antonio
Gutierrez
Fundosa Technosite S.A.
jagutierreztechnosite.es
Jaisiel Madrid
Fundosa Technosite
S.A.
jmadridtechnosite.es

1
Este a rticulo ha s ido r ealizado e n e l c ontexto d e l a i nvestigacion l levada a c abo por e l proyecto CENIT INREDIS
(InterIaces de Relacion entre el Entorno y las Personas con Discapacidad), inscrito en la iniciativa del gobierno espaol
INGENIO 2010 y que es gestionada por el CDTI ( Centro de Desarrollo Tecnologico Industrial). Las aproximaciones
tecnicas expresadas en es te a rticulo no c oinciden n ecesariamente c on a quellas mantenidas en el c onsorcio INREDIS
|17|.
Resumen

Este ar ticulo i ntroduce u na ap licacion de l as
arquitecturas orientadas a s ervicios (SOA) para la
entrega d e co ntenidos acces ibles a l as p ersonas
con di scapacidad e n di versos e ntornos. M uchas
tareas en l a v ida co tidiana d e l as p ersonas co n
discapacidad p ueden s er s olventadas, o r esueltas
en g ran medida, u tilizando l as t ecnologias d e l a
inIormacion. S in e mbargo, e n l a a ctualidad l as
personas con discapacidad encuentran importantes
barreras en el acceso a los servicios de la Sociedad
de la InIormacion. Ademas, hoy en dia no existen
plataIormas p reparadas q ue p uedan l legar
totalmente a c ualquier us uario c on discapacidad.
En este articulo se pr opone una aproximacion de
alto n ivel q ue permite el acc eso a d iIerentes
servicios electronicos mediante el uso de SOA, de
manera s encilla y ubicua, mediante el e mpleo de
tecnologias es peciIicas d isponibles en la
actualidad. Como principal conclusion, el presente
trabajo p ermite av anzar en l a p ropuesta d e
arquitecturas o rientadas a s ervicios co mo medio
de en trega d e contenidos acces ibles,
aprovechando l as pr opiedades de m odularidad,
desacoplamiento, es calabilidad y I acil ex pansion
de este tipo de arquitecturas.
1. Introduccin
Las n uevas t ecnologias en g eneral y l as TIC
(Tecnologias d e l a I nIormacion y l as
Comunicaciones) en particular han r evolucionado
la Iorma de vida de una gran parte de la sociedad.
Han simpliIicado muchas tareas, y abierto muchas
posibilidades de i nteraccion de las pe rsonas c on
los servicios de la Sociedad de la InIormacion. Sin
embargo, es tas t ecnologias p resentan g randes
barreras d e acces o p ara aq uellos co lectivos en
riesgos de exclusion, como las personas mayores,
las p ersonas co n d iscapacidad o l os i nmigrantes.
Con objeto de avanzar hacia l a inclusion de es te
tipo de c olectivos y r educir l a de nominada
'brecha digital, cobra gran relevancia proceder al
diseo de nuevas t ecnologias t eniendo e n c uenta
la d iversidad d e cap acidades Iuncionales d e l as
personas, as i co mo l as car acteristicas es peciIicas
del co ntexto b ajo el cu al se es tablece l a
comunicacion.
La a rquitectura o rientada a s ervicios ( SOA)
Iacilita la implementacion de grandes aplicaciones
de una m anera di stribuida y c on un ba jo
acoplamiento entre cada uno de sus componentes.
Este ar ticulo p retende i ntroducir al l ector en una
utilizacion d e este modelo arquitectonico en e l
entorno de l a a ccesibilidad, incorporando l a
integracion de servicios de accesibilidad en Iorma
de productos de apoyo soItware.
El articulo se organiza en cinco secciones. En
la s egunda s eccion, s e i ntroduce I ormalmente el
concepto de producto de apoyo y se proIundiza en
las Iormas d e acceso d e l as p ersonas co n
discapacidad a es te t ipo d e s ervicios d e
accesibilidad. En la tercera seccion, se propone la
integracion d e l os s ervicios de acces ibilidad
anteriores en una ar quitectura S OA. A
continuacion, en l a cuarta seccion, se muestra un
caso d e u so co ncreto d e l a ap roximacion
propuesta; en concreto, se propone un caso de uso
relacionado co n el acces o a s ervicios d e e -
gobierno o g obierno e lectronico. Por u ltimo, s e
enumeran l as conclusiones p rincipales d e es te
articulo.
2. Servicios y herramientas de
accesibilidad y usuarios con
discapacidad
2.1. Productos de apoyo
En l a norma AENOR UNE -EN I SO 99 99:2007,
un pr oducto de apoyo se deIine como 'cualquier
producto ( incluyendo di spositivos, e quipos,
instrumentos, t ecnologias y s oItware) I abricado
especialmente o d isponible en el mercado, p ara
prevenir, c ompensar, c ontrolar, m itigar o
neutralizar d eIiciencias, l imitaciones en l a
actividad y r estricciones en l a p articipacion |2|.
Es decir, los productos de apoyo son instrumentos
hardware o s oItware que a yudan a l as pe rsonas
con discapacidad a poder realizar cualquier accion
que s in e llos le s s eria d iIicil e Iectuar; l os
productos de a poyo a ctuan c omo i ntermediarios
entre ellos y su entorno. Por ejemplo, un producto
de a poyo ha rdware pa ra u na pe rsona c on
discapacidad a uditiva s eria un a udiIono, y uno
soItware p ara d iscapacidad visual s eria u n l ector
de pantalla instalado en el sistema operativo de un
dispositivo de us uario de terminado. Este a rticulo
se centra en los productos de apoyo soItware.
Los productos de apoyo soItware plantean dos
problemas pr incipales e n s u us o, q ue s on
abordados por l a a proximacion i ntroducida en el
presente a rticulo: la in teroperabilidad y la
ubicuidad |1|.
Interoperabilidad. La p rimera barrera q ue
muchos pr oductos de a poyo s oItware
presentan en un amplio numero de casos es la
ausencia de interoperabilidad entre diIerentes
plataIormas o sistemas operativos, asi como,
en cas os mas d eterminados, entre d iIerentes
aplicaciones o en tre d iIerentes v ersiones d e
una misma aplicacion. Siguiendo el ejemplo
presentado an teriormente, l a i nstalacion d e
un lector de pantalla ayuda a un us uario con
discapacidad v isual a p oder u tilizar el
dispositivo en el q ue s e i nstala d icho
soItware. S in e mbargo, e ste pr oducto de
apoyo n o g arantiza el p leno acces o d e u n
usuario a todas las aplicaciones instaladas en
el t erminal, debido a pos ibles
incompatibilidades en tre l as plataIormas
soItware en l as q ue s e d esarrollan d ichas
aplicaciones y el soItware que g obierna l a
Iuncionalidad de l lector d e pantalla. C omo
consecuencia, se i mpide el ad ecuado
procesamiento de los contenidos de l a
interIaz de usuario |16|.
Ubicuidad. Las p ersonas co n discapacidad
pueden instalar un pr oducto de apoyo en s u
ordenador q ue l es p ermitira el acce so, en
mayor o menor medida, a un gran numero de
recursos y servicios a l os que antes no tenian
acceso. S in e mbargo, s i s e d esea acceder a
estos s ervicios d esde o tra u bicacion, p or
ejemplo desde el ordenador de un cibercaIe o
desde el dispositivo movil de un amigo, seria
necesaria la in stalacion del p roducto de
apoyo requerido en la nueva ubicacion. Este
proceso pr esenta m ultiples obs taculos, e n
unos c asos p or e l e levado c oste que s uelen
tener l as l icencias d e p roductos de a poyo
soItware |7|, y e n ot ros por r estricciones
impuestas de i nstalacion de pr ogramas, por
ejemplo en puestos de acceso publico como
cibercaIes; todo ello sumado a que para cada
tipo de dispositivo suele ser necesario un tipo
diIerente o una version distinta del producto
de apoyo soItware.

Como pr opuesta de s olucion a l a pr imera
limitacion, l a au sencia d e interoperabilidad, es
necesaria la deIinicion de una interIaz comun que
haga que l os d iIerentes s istemas o perativos,
distintas a plicaciones y l os pr oductos de a poyo
soItware ' hablen un m ismo l enguaje
estandarizado, de Iorma que se puedan comunicar
entre s i s in problemas. Tal y como ya apuntaban
los inIormes de INTECO |7| y el de la Comision
Europea 'Analysing and I ederating t he European
assistive t echnology I CT i ndustry |5| sobre e l
analisis del mercado de los productos de apoyo, se
observa e l c onsiderable num ero de e llos qu e
existen en el mercado, tanto comerciales como de
codigo a bierto. S in e mbargo, l a or ientacion de l
sector s e h a d irigido, generalmente, al desarrollo
de p roductos es peciIicos p ara l a p oblacion
usuaria. C omo co nsecuencia p rincipal del

Figura 1. Conexion de la plataIorma de accesibilidad con productos de apoyo y servicios externos.

mercado actual, los productos de apoyo son caros
para e l us uario, I altos de i nteroperabilidad,
compatibilidad y p ortabilidad. Debido a l a
deteccion de e stos pr oblemas, e n e stos ul timos
aos, h a surgido u na cl ara ap uesta i nternacional
por e l de sarrollo proyectos qu e g aranticen l a
interoperabilidad de l os pr oductos de a poyo
soItware, como s e i ntroduce en |9|. Por ej emplo,
ACCESIBLE |15|, u n pr oyecto e uropeo de l
Septimo P rograma M arco, t iene co mo o bjetivo
mejorar la accesibilidad de diIerentes dispositivos
por medio de l i mpulso e n e l us o de e standares,
ademas de desarrollar una herramienta de analisis
de acces ibilidad. T ambien COGAIN |17|,
proyecto d e l a r ed d e ex celencia eu ropea, bus ca
desarrollar u n s istema q ue p ueda u tilizarse co n
dispositivos de s eguimiento de l a mirada,
buscando t ambien l a es tandarizacion d e l as
librerias d e ap licaciones b asadas en d ispositivos
de seguimiento de la mirada, y la implementacion
de herramientas que la soporten.
Por otro lado, si se sigue un esquema SOA, y
si l os productos de apoyo soItware se di sean de
tal manera que pue dan s er a ccesibles de sde una
inIraestructura de e ste t ipo, e stos po dran s er
utilizados d e I orma ubicua, lo q ue p ermitiria
resolver l a s egunda l imitacion co mentada |11|.
Como s e d emuestra en el analisis d e l as
principales propuestas de investigacion nacionales
e i nternacionales r elacionadas c on l os pr oductos
de apoyo, como INREDIS |18|, NPII |19|, AEGIS
|16| o P IRaMIDE |20| entre o tras, s e p uede
observar q ue l as m as i nnovadoras d e es tas s e
centran en tratar de conseguir la ubicuidad de los
productos de a poyo, e n e l i mpulso de
estandarizacion t anto de l os as pectos d e
accesibilidad co mo d e l as i nterIaces d e acces o
(APIs) entre los productos de apoyo y su entorno
de ejecucion. Por ejemplo, NPII |19|, un proyecto
estadounidense del q ue s e h a el aborado l a
propuesta i nicial, t iene c omo o bjetivo pr incipal
desarrollar u n s istema d e entrega v irtual d e
productos de apoyo, segun l as necesidades de l os
usuarios. El gran i nconveniente de e ste pr oyecto
es que esta en Iase embrionaria. Por ot ro l ado, el
proyecto A EGIS |16|, un pr oyecto europeo del
Septimo P rograma M arco, b usca Iacilitar el
acceso a l as TIC, p ero, a d iIerencia d e n uestra
propuesta, s e cen tra en l a cr eacion d e n uevos
productos de apoyo y aplicaciones especiIicas que
sirvan para este Iin, pero no plantea el esquema de
acceso a estos productos de apoyo.
La aproximacion p ropuesta en este ar ticulo
establece u na s olucion S OA a a lto n ivel q ue
permite s olventar l os dos pr oblemas explicados,
mediante l a deIinicion de i nterIaces normalizadas
que permiten el acceso remoto a los productos de
apoyo soItware.
2.2. Anlisis del acceso a productos de apoyo
remotos y servicios externos
Como se h a d icho mas ar riba, l a ap roximacion
introducida en este articulo pr opone el di seo de
productos de a poyo c on i nterIaces c omunes que
Iaciliten su acceso y ejecucion a traves de una red.
Estas interIaces se analizaran en la seccion tercera
de es te ar ticulo, que t rata l as partes mas t ecnicas
de la propuesta. En este apartado se analizan otros
requisitos a dicionales que l a s olucion pr opuesta
debera i ncorporar p ara as egurar el acc eso a l os
productos de apoyo y servicios Iinales a los que se
quiere acced er. En l a Iigura 1 se p resenta de
manera esquematica la conexion de la arquitectura
propuesta con este tipo de productos y servicios.
Para que una persona con discapacidad pueda
acceder al servicio Iinal que busca, primero t iene
que acceder a l a red. Para ello, el usuario utilizara
un dispositivo de acceso que se conectara a dicha
inIraestructura. En este acceso, se identiIican, por
tanto, dos interIaces. La primera entre el usuario y
el d ispositivo d e acces o, y l a s egunda en tre es te
ultimo y la red.
La primera i nterIaz, r epresentada en l a Iigura
1 con l as si glas I U ( acronimo de InterIaz d e
Usuario), de Iine c omo ha de c omunicarse e l
usuario con su dispositivo de acceso. Esta interIaz
ha de s er acces ible al usuario, y adaptarse s egun
las car acteristicas d e e ste. E n es te articulo s e
propone una s olucion de a ccesibilidad de a lto
nivel b asada en l as p ropiedades d e co nectividad
de l as ar quitecturas o rientadas a s ervicios, n o
siendo el objeto de esta contribucion pr oIundizar
en aspectos de modelado de usuario y adaptacion
automatica de interIaces.
La segunda i nterIaz es l a q ue h ay en tre el
dispositivo de acceso y l a red. Como se ha di cho
en el apartado 2.1, los productos de apoyo deberan
veriIicar l as pr opiedades de i nteroperabilidad y
ubicuidad, pr opiedades q ue s on contempladas a
traves de l a s olucion S OA pr opuesta e n e ste
articulo. Se ex plicaran en s ecciones s ucesivas
como s e g arantizara el cu mplimento d e es tos
requisitos en nuestra plataIorma.
Adicionalmente, h ay una s erie de r equisitos
que la aproximacion propuesta debe respetar, y un
conjunto de problemas que debe intentar resolver.
En co ncreto, u na p lataIorma de acces ibilidad
orientada a s ervicios n ecesita t ener u nas
caracteristicas b ien d eIinidas, co mo l a
transparencia al u suario y l a es calabilidad; t odo
ello u nido a l as dos ba rreras que q ueremos
solventar y que presentan los productos de apoyo,
la interoperabilidad y la ubicuidad.
Transparencia al usuario. Una car acteristica
muy importante que permitiria incrementar la
accesibilidad de l a a proximacion pr opuesta
es l a ad aptabilidad de l as i nterIaces d e
usuario, de Iorma transparente al mismo. Un
usuario s e co necta a l a r ed s olicitando un
servicio cu alquiera, o s implemente el
servicio de un pr oducto de a poyo. L a r ed
debe t rabajar i nternamente co n el r esto d e
nodos, si le son necesarios, con el objetivo de
devolver al usuario una respuesta o elemento
util. Se debe abstraer la arquitectura de la red
al u suario I inal, es te d ebe v er l a r ed co mo
una 'caja negra a la cual solicita un servicio
o inIormacion que esta le devuelve de Iorma
accesible, a daptandolo s egun s us
caracteristicas. C omo r eIerencia en l a l inea
de t rabajo de ad aptacion d e interIaces y
modelado de us uario, c onviene c itar e l
articulo desarrollado e n e l c ontexto del
proyecto INREDIS |18|.
Escalabilidad. Otro r equisito que de beria
cumplir la solucion d e acces ibilidad
propuesta es l a es calabilidad. La p lataIorma
de accesibilidad d ebe p oder a mpliar su
inIraestructura d e u na m anera s encilla,
pudiendo a adir n uevos s ervicios t anto de
nuevos pr oductos de a poyo, c omo de ot ras
aplicaciones inclusivas.
3. Integracin de productos de apoyo en
una arquitectura SOA
3.1. Justificacin del uso de SOA
En es te ap artado s e an alizan l as p ropiedades d el
modelo de arquitectura SOA |21|, el egido para l a
nuestra plataIorma, y como se r elacionan con l os
requisitos de la solucion de accesibilidad extraidos
en la seccion anterior.
La i nteroperabilidad e s uno de l os pr incipios
mas i mportantes d e S OA, ya q ue s e p ermite s u
ejecucion e n m ultiples e ntornos s oItware y
hardware. Por parte de los usuarios, casi todos los
dispositivos que e stos p ueden ut ilizar pa ra e l
acceso a l a p lataIorma i mplementan p rotocolos
que permiten conectar a servicios SOA, pudiendo
conectarse a l a plataIorma Iacilmente y por t anto
acceder a s ervicios de pr oductos de a poyo que
necesite el u suario en cad a m omento. D e es ta
Iorma, e l r equisito de interoperabilidad se
cumplira.
La arquitectura SOA garantiza la ubicuidad de
la p lataIorma d e a ccesibilidad, y a q ue l os
servicios que l a componen pueden estar ubicados
en l ugares di Ierentes, pudi endo s er c onsumidos
entre el los o por otros servicios externos. Gracias

Figura 2. Esquema de Iuncionamiento simpliIicado

a esto, en la solucion propuesta, el usuario accede
a l os s ervicios ex ternos oIertados en l a r ed
mediante la plataIorma de accesibilidad.
Por o tro lado, l a p lataIorma d e accesibilidad
puede s er diseada de I orma q ue s e g arantiza l a
transparencia, g racias a q ue l os s ervicios d entro
de l a ar quitectura S OA, poseen un c ontrato q ue
contiene inIormacion mediante la cual pueden ser
consumidos, a bstrayendo a l c onsumidor de l
servicio de detalles internos de este.
Finalmente, en cuanto a la escalabilidad, una
de las principales caracteristicas que tiene SOA es
que es al tamente es calable, cubriendo as i uno de
los r equisitos preIerentes id entiIicados e n la
seccion anterior.
Por t odo l o e xpuesto, s e pr opone e n e ste
articulo l a el eccion d e u na s olucion S OA co mo
opcion r ecomendable pa ra e l de sarrollo de
plataIormas d e a ccesibilidad, ya q ue h abilita
mecanismos e Iectivos q ue p ermiten s olventar l as
limitaciones expuestas en la seccion anterior.
3.2. Arquitectura de la solucin y acceso a los
productos de apoyo
Como s e ha i ntroducido a nteriormente, e n e ste
apartado s e pr opone una aproximacion de a lto
nivel q ue p ermite s olventar la s lim itaciones d e
accesibilidad identiIicadas en apartados anteriores.
Supongamos q ue el s ervicio q ue o Irece l a
plataIorma de a ccesibilidad dispone de l os
servicios de N pr oductos de apoyo; y ut iliza
cuando s on ne cesarios t anto e stos, c omo ot ros
servicios Iinales. Dado que la interIaz entre la red
y l os pr oductos de a poyo s iguen e l e squema de
una ar quitectura SOA, se propone el acceso a l os
mismos como u n r ecurso al q ue l a p lataIorma
podra acceder.
En l a I igura 2 s e p resenta el es quema d e
Iuncionamiento de alto ni vel de la pl ataIorma de
accesibilidad propuesta en este articulo.
Se propone seguir con el ejemplo planteado en
la s egunda s eccion, segun el cual un usuario con
discapacidad visual realiza una peticion de uso de
un l ector d e p antalla. E l u suario co munica es ta
necesidad a su dispositivo de acceso o este ultimo
detecta es ta n ecesidad, si e s que c onoce
previamente al u suario d e o tras i nteracciones
(Iuncionamiento pr oactivo). E l d ispositivo d e
acceso solicitara el s ervicio de un pr oducto d e
apoyo a la plataIorma de accesibilidad (paso 1 de
la Iigura 2). La plataIorma propuesta detectara las
caracteristicas es peciIicas d el u suario an alizando
su pe ticion, y c onIigurara un l ector de pa ntalla
basandose en todos l os r ecursos a l os que t iene
acceso y en l as preIerencias de uso marcadas por
el u suario (paso 2) . En cas o n ecesario, l a
plataIorma tambien acc edera a o tros s ervicios
Iinales (paso 3 ). El o bjetivo I inal e s d evolver a l
usuario los servicios del lector de pantalla acorde
a s us ne cesidades, por e jemplo, a t raves de un
archivo de audio (paso 4). Gracias a la Ilexibilidad
del esquema pr opuesto, el usuario t ambien podra
solicitar el uso de cualquier otro servicio SOA, en
cuyo caso se introduciria como obligatorio el paso
3, l a cr onologia d e p asos s eria l a m isma o s e
intercambiarian los pasos 2 y 3.
En l a I igura 3 s e p resenta el d iagrama de
componentes, en el cu al podemos apreciar l os
modulos internos que tendra nuestra plataIorma de
accesibilidad.

Figura 3. Componentes internos de la plataIorma
La entrada y salida a la plataIorma y su propia
gestion sera realizada por el nucleo, haciendo uso
del r esto d e s ervicios o gestores i nternos de l a
plataIorma. C ontamos c on l os siguientes
componentes:
Ncleo plataforma de accesibilidad. Es la
pieza p rincipal de l a p lataIorma. S e
encargarga de co ntrolar y manejar l as
peticiones, r edirigiendolas a lo s s ervicios o
gestores ap ropiados en cad a cas o. S era
pasarela en tre l as p eticiones y l os s ervicios
internos o externos a la plataIorma.
Gestor de productos de apoyo. Es e l
encargado de devolver al nucleo, cuando este
lo s olicite, un l istado de pos ibles pr oductos
de apoyo adaptados a las necesidades de cada
caso de us o, s egun el perIil del usuario que
quiera hacer uso de la plataIorma y segun de
las e speciIicaciones de s u di spositivo de
acceso. El p erIil p ermitira conocer l os
productos de a poyo y l a c onIiguracion q ue
mas s e adecua a cada i ndividuo,
consiguiendo u n s ervicio pe rsonalizado po r
usuario.
Servicio de autenticacin y autorizacin.
Este servicio, interno de la plataIorma, utiliza
el pr ocedimiento de autenticacion S SO
(Single S ign O n), que sera ex plicado m as
adelante en el ap artado 3.4. T ambien se
encarga de gestionar la autorizacion de uso a
cada uno de l os s ervicios, e valuando l os
credenciales de cada usuario.
Gestor de usuarios. Este ge stor es el
encargado d e ad ministrar l a i nIormacion d e
identiIicacion y conIiguracion de cada uno de
los usuarios. Su objetivo es devolver, cuando
el nucleo de la plataIorma lo solicite, el perIil
asociado a un us uario de terminado, que
contiene las cap acidades y p reIerencias d e
conIiguracion del mismo.

Seria t ambien i nteresante es tudiar l a
posibilidad de guardar el hi storial de l os recursos
utilizados por cada usuario, por supuesto, siempre
respetando las preIerencias de privacidad de este.
De es ta Iorma, s e t endria cada vez un perIil mas
rico de los usuarios y los servicios que oIrezca la
plataIorma e starian cad a vez mas al ineados con
las n ecesidades y p reIerencias r eales d e l os
usuarios. Asimismo, haciendo us o de l a
experiencia de i nteraccion del us uario con l a
plataIorma, se conseguiria optimizar este proceso.
3.3. Implementacin de la plataforma de
accesibilidad
En l a a ctualidad pa ra pode r i mplementar una
plataIorma SOA a gran escala, como la plataIorma
de acces ibilidad p ropuesta, s e suele utilizar una
tecnologia d e i nIraestructura conocida como
Enterprise S ervice Bu s (E SB). E SB e sta
Iuertemente b asado en XML y l os es tandares d e
Web S ervices; Iacilita la g estion de I lujos, l a
integracion de n uevos c omponentes, l a
transIormacion de mensajes y s oporta m ultiples
protocolos de entrada y salida.
La i mplementacion mas utilizada del estandar
ESB es el propuesto por SUN en su JSR 208 |14|.
Se de Iinen l os c omponentes basicos pa ra l a
implementacion de un ESB, pudiendose clasiIicar
en dos t ipos pr incipales: B inding C omponents
(BC) y S ervice E ngines (S E). Los BC s on los
encargados d e i nterconectar el E SB co n las
tecnologias e xistentes y lo s SE s on l os s ervicios
encargados de procesar l a i nIormacion de manera
interna en un ESB.
En el caso de la aproximacion propuesta, para
la i mplementacion de l a plataIorma se ha el egido
la di stribucion O penESB, de sarrollado c omo un
proyecto O penSource y l igado I uertemente al
servidor de aplicaciones GlassFish.
La i mplementacion s e r ealizara utilizando la
tecnologia Business Process Execution Language
(BPEL) co mo B usiness Process M anagement
(BPM) para gestionar y manejar cada una de l as
peticiones. D e es ta I orma s e ap rovechara el
potencial que pr oporcionan los B inding
Components (BC) y los Service E ngines ( SE)
como co nectores a diIerentes h erramientas o a
diIerentes s ervicios d e n egocio. El o bjetivo I inal
es poder contar con una aplicacion distribuible a
traves de un Service Assembly.
3.4. Seguridad de la plataforma
La s eguridad es s iempre u n I actor a t ener e n
cuenta en el diseo d e una i nIraestructura d e
servicios. Para el cas o d e la pr opuesta planteada
en este articulo, en vista de que trata datos sobre la
discapacidad de las personas que la utilizan, es de
vital i mportancia cu idar su s eguridad. La LOPD
(Ley O rganica d e P roteccion d e D atos) |8|
considera c omo da tos que d eben s er
especialmente p rotegidos 'l os d atos d e car acter
personal que hagan r eIerencia (.) a l a salud de
las p ersonas. Por el lo, es m uy i mportante
mantener la privacidad de los usuarios, no solo de
los da tos q ue pr oporcionan, y d e la i nIormacion
que devuelven los servicios a los que se accede, si
no t ambien la propia pe ticion de s olicitar lo s
servicios de un pr oducto de a poyo u ot ro (de
donde se podria inIerir el tipo de discapacidad que
tiene la persona). En este apartado se explican, en
lineas generales, los protocolos y esquemas que se
van a seguir p ara garantizar l a s eguridad de l a
arquitectura propuesta.
Las d istintas a proximaciones existentes en
torno a la seguridad en la invocacion de servicios
Iijan gran importancia e n c omo s e di stribuye l a
inIormacion de autenticacion, o autorizacion |10|.
Con el objetivo de gestionar la autorizacion de
cada s ervicio d e u na manera eIiciente, s e h a
elegido el protocolo SSO ( Single Sign On) como
metodo de i dentidades I ederadas v itales en es te
tipo de pl ataIormas di stribuidas. Esta s olucion
basa s u I uncionamiento en cr ear u n al macen
comun de inIormacion, con un grado de seguridad
maximo, de modo que l as e mpresas comparten
inIormacion s in c ompartir tecnologias de
directorio, seguridad y autenticacion. La identidad
Iederada permite, de una Iorma segura, abordar la
gestion de us uarios, l a s incronizacion de da tos
identiIicativos, la g estion de a ccesos y t odos l os
servicios r elacionados co n la g estion de
inIormacion critica. En concreto, l a s eguridad en
la p lataIorma d e ac cesibilidad u tilizara esta
tecnologia m ediante l os pr ocedimientos de
autenticacion y au torizacion d e acces o u nico o
SSO. De todo este proceso se encargara el modulo
de l a p lataIorma d e acc esibilidad l lamado
'Servicio de Autenticacion y Autorizacion.
Todos los servicios harian uso del SSO, con la
Iinalidad de que los usuarios Iinales proporcionen
sus datos de identiIicacion una sola vez, y queden
identiIicados en el resto de servicios integrados en
el sistema, sin necesidad de volver a proporcionar
las cr edenciales, sin que se ve a aIectada l a
seguridad.

Figura 4. Todos los servicios hacen uso de los
servidores de seguridad a traves de SSO.
Como se aprecia en la Iigura 4, los recursos y
aplicaciones pr otegidos, estan controlados por un
agente de politicas, que intercepta las peticiones y
crea un canal de comunicacion constante con SSO
para validar l as autenticaciones o autorizaciones.
Tambien c uenta c on un s ervidor de r emediacion
en caso de la existencia de alguna incidencia.
4. Caso de uso: acceso a e-gobierno de
forma accesible
En esta seccion se expone un caso de uso concreto
de la solucion de acces ibilidad propuesta en es te
articulo. E n co ncreto, el ej emplo explica la
interaccion de una pe rsona c on di scapacidad
visual c on u n s ervicio de e -gobierno o g obierno
electronico.
4.1. Qu es e-gobierno?
La t endencia act ual d e l a mayoria d e s ectores y
entidades coincide en el u so creciente d e las
nuevas tecnologias. En esta linea, los gobiernos de
muchos paises t ambien se estan apuntando a esta
tendencia, co mo I orma d e acer carse a l os
ciudadanos y e mpresas. E stan i ntentando
revitalizar su ad ministracion p ublica y h acerla
mas proactiva, eIiciente, t ransparente y sobretodo
mas orientada a s ervicios |13|. Por ejemplo, para
Iavorecer este p roceso d e t ransIormacion, c ada

Figura 5. Caso de uso: un usuario con discapacidad visual accede a un servicio de e-gobierno

Figura 6. Diagrama de secuencia del acceso a un servicio de e-gobierno a traves de la plataIorma de accesibilidad.

vez mas t ramites s e p ueden h acer d e Iorma
remota, u tilizando la s te cnologias d e la
inIormacion, s in t ener q ue pr esentarse
personalmente a l e diIicio Iisico d el m inisterio
correspondiente. A es te u so co ncreto d e l as
nuevas t ecnologias s e l e s uele d enominar e-
gobierno o gobierno electronico.
Una deIinicion mas Iormal de e-gobierno dada
por Delloite Research es la siguiente: 'es el uso de
la t ecnologia para r ealzar y mejorar el acces o y
entrega de servicios de gobierno o administracion
a los ciudadanos, empresarios y empleados |4|.
4.2. E-gobierno y SOA
Una I orma d e implementar Iacilmente una
solucion de e-gobierno es a t raves d e u na
arquitectura S OA. E stos ul timos a os s e h a
desarrollado m ucho es ta l inea de i nvestigacion.
Hay e n multiples p aises, diversos pr oyectos y
conIerencias t ratando el t ema del acces o al e -
gobierno a t raves d e S OA |12| |23| |3|, y
empresas que oIrecen estos servicios |22||6|.
Un e jemplo e s la multinacional HP ( Hewlett
Packard), que e n 2006 l anzo una not a de pr ensa
oIreciendo s oluciones de e-gobierno a traves d e
una ar quitectura S OA |6|. O tro e jemplo, e n
Espaa, es el proyecto presentado por Xisco Tous,
Felip Salas y Antoni Reus, de la Fundacion IBIT,
que quiere dar servicios de e-gobierno basados en
SOA, p rincipalmente en l a ad ministracion de l as
islas Baleares |23|.
Por todo lo dicho, se demuestra que el uso de
e-gobierno a t raves de una ar quitectura SOA esta
siendo muy promocionado en los ultimos aos. A
continuacion s e explicara propiamente el cas o de
uso abordado en este articulo.
4.3. Acceso a e-gobierno a travs de la
plataforma de accesibilidad
En este apartado se detalla la secuencia de pasos
requeridos en el acc eso d e usuario c on
discapacidad visual a un servicio de e-gobierno a
traves d e l a s olucion d e acces ibilidad S OA
propuesta. Para simpliIicar la explicacion del caso
de uso, se parte de la suposicion de que el usuario
ya co noce l os s ervicios d e acc esibilidad d e l a
plataIorma or ientada a servicios, por l o t iene una
cuenta d e u suario cr eada en l a plataIorma y h a
accedido a el la anteriormente, d e es ta Iorma, l a
plataIorma conoce su perIil de usuario, y sabe las
capacidades que tiene el usuario.
Un us uario c on d iscapacidad visual qui ere
hacer uso de un s ervicio de e -gobierno desde un
ordenador c ualquiera, por e jemplo de sde e l
ordenador de un a migo. L os siguientes pa sos
describen el p roceso d esde q ue el usuario s e
conecta a l a p lataIorma h asta q ue r ecibe l a
inIormacion s olicitada, como po demos ve r e n l a
Iigura 5 con una representacion mas esquematica,
y en el diagrama de la Iigura 6 de una Iorma mas
detallada.
Paso 1. La persona que quiere hacer uso de la
plataIorma ac cede al s ervicio p roporcionado
por l a pl ataIorma pr opuesta a t raves de un
navegador d e Internet, y s e i dentiIica co mo
usuario. U na v ez i dentiIicado e l us uario, l a
plataIorma o btiene s u perIil q ue mas t arde
utilizara p ara v eriIicar, l as c apacidades d el
usuario. E n es te p aso l a p lataIorma t ambien
obtiene la s c aracteristicas d el d ispositivo de
acceso u tilizado p ara acced er a l s ervicio e -
gobierno. S abiendo l as cap acidades d el
usuario y l as pr opiedades de l d ispositivo, la
plataIorma d e acce sibilidad s olicita al g estor
de pr oductos de a poyo un l istado de l os
productos de apoyo acordes con el usuario y el
dispositivo d isponibles y que pue den s er
usados. Asimismo, en este paso se abrira una
sesion para el usuario, donde poder gestionar
sus t ransacciones y al macenar l a i nIormacion
de i dentiIicacion y c onIiguracion. El us uario
ademas r ecibira l as cr edenciales q ue l e
Iacilitaran el acces o a l a p lataIorma en
sucesivas pe ticiones. El pr imer paso e ngloba
todas l as p eticiones y pr ocesos que e s
necesario r ealizar p ara p oder empezar a u sar
la plataIorma.
Paso 2. En el siguiente paso, el usuario hace
la pe ticion de uso de u n s ervicio de e -
gobierno, p or e jemplo, s e qui ere a puntar a
unas op osiciones. La p eticion se r eenvia al
servicio e-gobierno y se obtiene una respuesta
del mismo; o, en caso de que esto no sea aun
posible, s e obt ienen las car acteristicas d e l a
inIormacion a m ostrar p ara v eriIicar d e q ue
Iorma permite ser mostrada al usuario.
Paso 3. En es ta nueva I ase, l a plataIorma de
accesibilidad, con l os da tos pr oporcionados
por el servicio e-gobierno en el paso anterior,
selecciona d e l a l ista d e productos d e ap oyo
obtenida e n e l pa so 1 e l pr oducto de a poyo
apropiado pa ra m ostrar l a i nIormacion
solicitada al usuario (en este caso de uso seria
un l ector d e p antalla). D espues d e es to, l a
plataIorma d e accesibilidad en via l a
inIormacion a mostrar al producto de apoyo, y
este le devuelve la inIormacion adaptada a las
caracteristicas d el u suario. E n nuestro cas o,
nos devuelve un archivo mp3 con el audio de
la inIormacion a mostrar.
Paso 4. Finalmente l a p lataIorma d e
accesibilidad l e d evuelve al u suario l a
inIormacion accesible obtenida del servicio de
e-gobierno.

El p aso 1 s olo s e d ebera r ealizar cu ando el
usuario acced e a l a p lataIorma de acces ibilidad.
Sin embargo l os pasos 2, 3 y 4 de beran r epetirse
cada v ez q ue s e d esee mostrar u na i nIormacion.
Es d ecir, cuando la persona con d iscapacidad
visual na vega por una pa gina w eb, p ara cad a
elemento de l a p agina sobre e l que s e pos icione
(por e jemplo, u na e tiqueta e n un I ormulario),
debera s olicitar a l a p lataIorma de acce sibilidad,
su descripcion o su contenido de Iorma adaptada.
Se dara la opcion al usuario de cerrar la sesion
cuando l o desee, por haber t erminado de t rabajar
con l a plataIorma d e acces ibilidad, m ediante el
metodo logOut(). Sin embargo, por cuestiones de
seguridad p rincipalmente, s i durante un ci erto
periodo de t iempo el usuario permanece i nactivo,
saltara u n timeOut que pr ovocara
automaticamente el cierre de sesion.
Una vez explicado el caso de uso, cabe sealar
que, c omo c ontemplaba uno d e l os r equisitos
analizados en l a S eccion 2 , l a p lataIorma de
accesibilidad sera t ransparente al usuario dur ante
la interaccion con la Iuncionalidad del servicio de
e-gobierno.
5. Conclusiones
La aproximacion a alto nivel que se ha presentado
en este articulo permite avanzar en la propuesta de
arquitecturas o rientadas a s ervicios ( SOA) q ue
incorporen opc iones de accesibilidad, pa ra asi
Iacilitar la a daptacion d e lo s s ervicios d e la
Sociedad de l a I nIormacion a l as pe rsonas c on
discapacidad. E n c oncreto, e n es te ar ticulo
aprovecha l as pr opiedades de c onectividad d e
SOA para r ealizar l a en trega de pr oductos de
apoyo s oItware. E s una pr opuesta nov edosa, y a
que varios proyectos, co mo s e h a ido
mencionando a l o l argo d el ar ticulo, b uscan
promocionar es tandares d e acces ibilidad, o
desarrollar pr oductos de a poyo aplicaciones
especiIicas que Iaciliten el acceso de las TIC; pero
ningun p royecto act ualmente en ej ecucion o
Iinalizado plantea una solucion tan global como la
expuesta en este articulo.
Las v entajas i nherentes a SOA, co mo s on:
modularidad, desacoplamiento, e scalabilidad y
Iacil e xpansion, i ncorporan g randes be neIicios
para l a ap roximacion q ue s e propone en es te
articulo. En concreto, s e dan pautas que I acilitan
hacer l as l lamadas a l os d iIerentes p roductos d e
apoyo y s ervicios de ac cesibilidad, de I orma que
todo este proceso sea transparente para el usuario.
En es te ar ticulo t ambien s e ha presentado un
posible caso de uso de la aproximacion analizada
relacionado co n el acces o a s ervicios d e e -
gobierno.
Como I uturas lineas d e a ctuacion n ecesarias
para i ncrementar l as propiedades de accesibilidad
de l os e ntornos de a plicacion or ientados a
servicios, s e d ebe a vanzar en l as t ecnologias d e
modelado de us uario y adaptacion automatica de
contenidos, asi como en la interoperabilidad de los
productos de a poyo y di Ierentes p lataIormas
soItware |9|.
Referencias
|1| A.A.V.V., 'Master en Tecnologias a ccesibles
para l os s ervicios de l a s ociedad d e l a
inIormacion, UOC, 2009.
|2| AENOR UNE-EN ISO 9999:2007, 'Productos
de a poyo pa ra pe rsonas c on discapacidad.
ClasiIicacion y terminologia, 2007.
|3| ConIerencia 'N inth S ervice-Oriented
Architecture Ior E -Government ConIerence,
McLean, Virginia, 2010.
|4| Deloitte R esearch, ' At t he Dawn o I e-
Government: T he C itizen as C ustomer,
Public Sector Institute, 2000.
|5| European C ommission, ' Analysing a nd
Iederating t he E uropean as sistive t echnology
ICT industry, 2009.
|6| Hewlett P ackard, 'H P I ntroduces I ndustry-
speciIic Service-oriented Architectures, Palo
Alto ( CA), E stados U nidos de A merica,
pagina web consultada el 10 de abril de 2010:
www.hp.com/hpinIo/newsroom/press/2006/06
0411b.html, 2006.
|7| INTECO ( Instituto N acional de T ecnologias
de l a C omunicacion), ' Estudio s obre l as
Tecnologias d e Accesibilidad en E spaa
2008. Leon, 2008.
|8| Ley Organica 15/1999 de Proteccion de Datos
de Caracter Personal, 1999.
|9| Martinez U sero, J . A . Presentacion 'T he
Accessible Technology Ecosystem and Why it
is Critical, 2009.
|10| Menze, M., Wolter, C., y Meinel, C., 'Access
control Ior Cross Organizational Web Service
Composition, 2007.
|11| Michele F., K omazec S .,Guglielmina C .,
Gusmeroli, 'S. COIN: PlatIorm and Services
Ior S aaS i n E nterprise I nteroperability a nd
Enterprise Collaboration, IEEE, 2009.
|12| Nanping, Z ., Y uan, L ., ' Study a nd
Application oI t he SOA Based E-government
System, I nternational C onIerence o n
InIormation M anagement, I nnovation
Management and Industrial Engineering (ICIII
'08), 2008.
|13| ONU, ' 2008 Global E-Government S urvey.
From E -Government t o C onnected
Governance, 2008.
|14| Oracle Corporation, 'JSR 208: Java Business
Integration (JBI), 2005.
|15| Proyecto ACCESSIBLE (Accessibility
Assessment Simulation Environment Ior New
Applications D esign a nd D evelopment),
pagina web consultada el 4 de junio de 2010:
www.accessible-project.eu, 2008-2011.
|16| Proyecto A EGIS ( Open A ccessibility
EveryWhere: Groundwork, I nIrastructure,
Standards), pagina w eb co nsultada el 4 de
junio de 2010: www.aegis-project.eu, 2008.
|17| Proyecto COGAIN (Communication by Gaze
Interaction), pagina w eb c onsultada e l 4 de
junio de 2010: www.cogain.org/, 2004-2009.
|18| Proyecto INREDIS (INterIaces de RElacion
entre e l E ntorno y l as pe rsonas c on
DIScapacidad), proyecto C ENIT ge stionado
CDTI, pagina web consultada el 4 de junio de
2010: www.inredis.es, 2007-2010.
|19| Proyecto N PII ( National Public I nclusive
InIrastructure), pagina web consultada el 4 de
junio de 2010: http://npii.org/, Iechas n o
disponibles, y a q ue act ualmente s e es ta
desarrollando la propuesta del proyecto.
|20| Proyecto P IRAmIDE ( Personalizable
Interactions with Resources o n AmI-Enabled
Mobile D ynamic E nviroments), documentos
en ab ierto d el proyecto, pagina w eb
consultada e l 4 de j unio de 2 010:
http://www.slideshare.net/piramidepse, 2008-
2011.
|21| SOA S ystems I nc, 'S OA P rinciples. An
Introduction to th e Service-Orientation
Paradigm. p agina w eb co nsultada el 1 0 d e
abril de 2010: www.soaprinciples.com/.
|22| SoItware AG, 'E -Government. M odernize
your ag ency t o i ncrease l evels o I s ervice,
pagina web consultada el 10 de abril de 2010:
www.soItwareag.com/latam/Solutions/govern
ment/e-Government/deIault.asp.
|23| Tous Llull, X., Salas Suau, F., Reus Darder,
A., 'M odelo d e eG overnment i nteroperable
basado en S OA, J ornadas C ientiIico-
Tecnicas en S ervicios W eb y S OA
(JSWEB2006), 2006.

<
60 10 60
10
Una Arquitectura para el Diseo de Soluciones de Integracin de
Aplicaciones Empresariales con Soporte para Tolerancia a Fallos
*
Rafael Z. Frantz Rafael Corchuelo Carlos Molina-Jimnez
Dep. de Tecnologa Dep. de Lenguajes y Sist. Informticos School of Computing Science
Universidad UNIJU Universidad de Sevilla University of Newcastle, UK
So Francisco, 501 Avda. Reina Mercedes s/n NE1 7RU
Iju 98700-000 RS, Brasil 41012 Sevilla, Espaa Newcastle upon Tyne, UK
rzfrantz@unijui.edu.br corchu@us.es carlos.molina@ncl.ac.uk
Resumen
Las soluciones de integracin de apli-
caciones empresariales (EAI) suelen estar
basadas en workows de mensajes gracias a
los cuales es posible conseguir que dos o ms
aplicaciones cooperen para proporcionar un
nuevo servicio o que mantengan sus datos sin-
cronizados. La bibliografa proporciona resul-
tados sobre dos modelos de ejecucin difer-
entes: el basado en procesos y el basado en
tareas. En cualquiera de los dos es comn
tener que tratar con fallos, debido a que
las aplicaciones integradas suelen estar total-
mente distribuidas y en rara ocasin fueron
diseadas teniendo en cuenta que deberan
ser integradas posteriormente. En este artcu-
lo, presentamos una arquitectura para pro-
porcionar tolerancia a fallos en soluciones in-
tegracin de aplicaciones empresariales que
*
Se proporciona material adicional en la di-
reccin http://www.tdg-seville.info/rzfrantz/JSS-2010:
una implementacin del sistema, cdigo fuente, do-
cumentacin y videos con demostraciones. El primer
autor llev a cabo parte de su trabajo en la Uni-
versidad de Newcastle (Reino Unido), durante una
estancia de investigacin. Su trabajo fue nanciado
por el Evangelischer Entwicklungsdienst e.V. (EED).
El segundo y el primer autor han sido parcialmente
nanciados por la Comisin Europea (FEDER), los
programas de I+D+I del MEC Espaol y la Jun-
ta de Andaluca (proyectos TIN2007-64119, P07-
TIC-2602, P08-TIC-4100, y TIN2008-04718-E) y por
el programa de investigacin de la Universidad de
Sevilla. El tercer autor fue nanciado parcialmente
por el Gobierno de Reino Unido, a travs del proyec-
to EPSRC No. EP/D037743/1.
utilizan el modelo de ejecucin basado en tar-
eas.
1. Introduccin
En las empresas actuales es habitual en-
contrar un conjunto bastante heterogneo de
aplicaciones (conocido como ecosistema soft-
ware [20]) que regularmente incluye aplica-
ciones desarrolladas dentro de la empresa
para solucionar un problema especco y apli-
caciones compradas a varios proveedores. Las
ltimas incluyen aplicaciones relativamente
nuevas y aplicaciones completamente desac-
tualizadas.
Ejemplos de estas aplicaciones son los sis-
temas para procesamiento de nminas y sis-
temas de venta. Con frecuencia, en estos am-
bientes surge la necesidad de integrar las apli-
caciones del ecosistema software para man-
tener sincronizados los datos que ellas manip-
ulan o bien para crear nuevos servicios a par-
tir de los servicios que las aplicaciones del eco-
sistema ofrecen [13]. Este campo de investi-
gacin es conocido como Integracin de Apli-
caciones Empresariales (EAI). El reto de las
soluciones EAI consiste en disear e imple-
mentar un conjunto de procesos de wrapping
que se encargan de interactuar con las apli-
caciones (un wrapper para cada aplicacin) y
un conjunto de procesos de integracin, que
se encargan de gestionar el ujo de mensajes
entre las aplicaciones.
Una buena alternativa para soportar el dis-
eo de los procesos de integracin son los Sis-
temas de Soporte a Procesos (PSS): un mid-
dleware que, entre otras facilidades, ofrece
recursos para disear procesos distribuidos
(e.g., soluciones EAI) y para monitorizar su
ejecucin [12]. Ejemplos representativos de
PSSs son los sistemas de workow tradi-
cionales [12, 1]. En [26] se estudian los PSSs
basados en BPEL [23]. Ejemplos de PSSs en-
focados a soluciones EAI son BizTalk [8], Tib-
co [25], Camel [10] y Mule [22].
Una metodologa muy conocida en el dis-
eo de soluciones EAI consiste en usar una
base de datos para almacenar los mensajes
entrantes (mensajes procedentes de las apli-
caciones individuales y dirigidos hacia el pro-
ceso de integracin) uno por uno hasta que
todos los mensajes necesarios para activar el
proceso de integracin hayan llegado. En ese
momento se solicita y activa un hilo (thread)
solo que comienza a ejecutar, de forma sn-
crona, todas las tareas del proceso. Este mod-
elo de ejecucin se conoce como el basado
en procesos. Se debe observar que, si en al-
gn momento una tarea enva un mensaje al
wrapper de una aplicacin, el hilo queda blo-
queado hasta que la aplicacin responde. Con
el propsito de minimizar interferencias, es
frecuente que en entornos de integracin de
aplicaciones, las aplicaciones den poca priori-
dad a los mensajes que reciben de los procesos
de integracin. Es comn tambin que para
responder a un mensaje, la aplicacin necesite
de la intervencin de una persona. En otros
casos, la aplicacin que recibe el mensaje no
es una aplicacin simple, sino que tambin es
una solucin de integracin. Debido a estas
posibilidades, la respuesta puede demorarse
horas o incluso das [12]. Consecuentemente,
uno de los riesgos del modelo de ejecucin
basado en procesos es que el hilo asignado
puede permanecer largos perodos inactivo y
consumiendo vanamente recursos.
Para intentar paliar este problema, algunos
autores han propuesto tcnicas de deshidrat-
acin/rehidratacin de hilos [8, 26] que con-
sisten en serializar y guardar en disco los pro-
cesos que al estar en espera de mensajes de
respuestas, mantienen bloqueados hilos du-
rante mucho tiempo. Cuando las respuestas
llegan, el proceso se recupera, se deserializa y
se ejecuta en cuanto hay un hilo disponible.
El inconveniente de esta estrategia, es el coste
de la deshidratacin/rehidratacin.
Otra alternativa es usar un modelo de eje-
cucin basado en tareas. En este modelo, los
hilos no se asignan a los procesos, sino a
las tareas que procesan los mensajes. Al dis-
minuir el nivel de granularidad, se consigue
mayor concurrencia y aprovechamiento de re-
cursos [15, 11]. Por ejemplo, los mensajes
comienzan a procesarse (algunos concurrente-
mente) en cuanto son recibidos; de su cor-
relacin se encargan tareas especcas dentro
de los procesos de integracin.
Merece la pena recordar que las soluciones
EAI son intrnsecamente distribuidas y por
lo tanto son susceptibles a una amplia gama
de fallos [12, 24]. Esto se debe a que las EAI
involucran varias aplicaciones comunicadas a
travs de una red y a que tanto las apli-
caciones como la red son susceptibles a fal-
los. La red por ejemplo, puede imprevisible-
mente retrasar, corromper e incluso perder
mensajes. Para ser de utilidad prctica, las
soluciones EAI deben incluir mecanismos de
tolerancia a fallos [4].
La tolerancia a fallos en el contexto de
los PSS no es un tema completamente nue-
vo; varios autores ya han estudiado el proble-
ma, pero nicamente dentro del contexto del
modelo de ejecucin basado en procesos que
hemos descrito anteriormente y considerando
la existencia de un proceso solo; es decir, han
dejado fuera de sus anlisis todas las solu-
ciones EAI que se componen de varios pro-
cesos de integracin y de wrapping. Con el
propsito de aportar una solucin a este prob-
lema, en este artculo presentamos una arqui-
tectura para proporcionar tolerancia a fallos
a soluciones EAI, que utilizan el modelo de
ejecucin basado en tareas. La arquitectura
funciona bajo dos condiciones alcanzables en
la prctica: a) que podemos enriquecer los
mensajes producidos por los procesos de inte-
gracin y wrapping con informacin obtenida
de los mensajes usados para producirlos. b)
que el monitor que usamos para detectar fa-
llos (Figura 3) est exento de fallos; este tema
queda fuera del alcance del presente trabajo;
nos limitamos a mencionar que este requisito
se puede cubrir con la ayuda de tcnicas de
implementacin con versiones mltiples [3].
El artculo se organiza de la siguiente man-
era: en la Seccin 2 analizamos trabajos rela-
cionados con el tema; la Seccin 3, intro-
duce los conceptos necesarios para compren-
der el tema. La arquitectura que proponemos
se presenta en la Seccin 4; la Seccin 5, de-
scribe el estudio y solucin a un problema
real que ayuda a entender la propuesta; nal-
izamos presentando nuestras conclusiones en
la Seccin 6.
2. Trabajos Relacionados
Nuestro estudio sobre la tolerancia a fal-
los en soluciones EAI est directamente rela-
cionada con el concepto de transacciones de
larga duracin introducido en [21]. Este tra-
bajo de investigacin inspir y foment otros
trabajos dirigidos a proveer los PSS con
mecanismos de tolerancia a fallos. El traba-
jo original ha dado lugar a varias ideas para
solucionar el problema, que si omitimos los
detalles, podemos clasicar en dos grupos: las
que se basan en algoritmos para reaccionar
a fallos de forma automtica y las que se
basan en reglas, en donde los fallos son trata-
dos por las reglas denidas por el diseador.
En [6] se estudia un modelo abstracto para
workows con tolerancia a fallos; este artcu-
lo tambin proporciona una buena revisin de
las metodologas que existen para enfrentar
el problema. En [4] se presenta un algorit-
mo para implementar transacciones en apli-
caciones distribuidas, donde las aplicaciones
participantes cooperan entre ellas para imple-
mentar un protocolo distribuido.
En [16] se presenta un algoritmo para la
ejecucin de procesos BPEL con transac-
ciones relajadas, donde se relaja la propiedad
de atomicidad. En [17] los autores mejo-
ran sus resultados anteriores introducien-
do un lenguaje basado en reglas que per-
mite la denicin de reglas especcas de
recuperacin de fallos. La solucin descri-
ta en [7] propone disear y gestionar proce-
sos especiales para aportar tolerancia a fal-
los a un workow orquestado con BPEL.
En dicha propuesta, los procesos del work-
ow que pueden fallar llevan asociados a el-
los un proceso especial con la lgica para la
recuperacin en caso de que ocurra un fallo.
Cuando el sistema detecta un fallo en alguno
de los procesos del workow, activa el proceso
especial correspondiente. En [12] se propone
un algoritmo para el tratamiento de fallos en
aplicaciones integradas por medio de sistemas
de workow y tratables con acciones de com-
pensacin o con el protocolo de commit en
dos fases. [18] presenta un mecanismo para
el tratamiento de fallos en aplicaciones en las
que las acciones de compensacin son difciles
o imposibles de llevar a la prctica.
En [5] se propone una arquitectura para
implementar tolerancia a fallos por medio de
workows ad-hoc. Por ejemplo, utilizando un
servidor web como front-end, un servidor de
aplicaciones, una base de datos y un sistema
de log. Los autores asumen que un workow
se activa siempre que le llega un mensaje de
peticin que uir a travs de los compo-
nentes del workow; por lo tanto, su mecan-
ismo de recuperacin de fallos se basa en el
seguimiento de todos los mensajes a travs
del sistema. De forma parecida, en nuestra
propuesta nosotros hacemos un seguimiento
de mensajes para conocer toda la traza de un
mensaje durante su ejecucin en el workow
de integracin.
En [19] el autor presenta ideas para propor-
cionar tolerancia a fallos a procesos de work-
ow que manejan peticiones asncronas. Tam-
bin presenta una buena discusin respecto al
modelo de comunicacin asncrono entre pro-
cesos. Dicha propuesta se centra en el modelo
de ejecucin basado en procesos y por con-
siguiente, padece de las desventajas que expli-
camos en la Seccin 1; adems, asume que la
interface de comunicacin entre los procesos
es un mecanismo que permite implementar
una cola de mensajes. En la arquitectura que
estamos presentando, nosotros consideramos
un modelo de ejecucin basado en tareas y
sin asumir ninguna implementacin espec-
ca del mecanismo de comunicacin de los pro-
cesos. Dicho mecanismo puede ser una inter-
face grca, una API de programacin, una
cola u otro. El autor tambin comenta que
con ese mecanismo de comunicacin basado
en colas, adems del uso de las tcnicas de
replicacin y balanceo de carga para los pro-
cesos, se puede aportar tolerancia a fallos a
procesos de workow.
En [1] los autores proponen el uso del
mecanismo de manejo de excepciones para
aadir tolerancia a fallos a soluciones de
workow, pero combinada con el uso de es-
trategias de replicacin para aumentar la
disponibilidad de las soluciones. En [9] se
describe una arquitectura para la tolerancia
a fallos basada en una mquina de estados
nitos (diagramas de secuencia de mensajes)
y que reconoce secuencias vlidas de men-
sajes en los workows. Las acciones de recu-
peracin se activan cuando se encuentra un
mensaje invlido o el tiempo de ejecucin de
la maquina de estados se agota.
En [15] y [11] se presentan una solucin
para proporcionar tolerancia a fallos en pro-
cesos basados en redes de Petri. El contro-
lador original se incorpora sin ningn cam-
bio en un nuevo controlador que conserva
la estructura del controlador original pero
enriquecido con lugares adicionales, transi-
ciones y chas, con el objetivo de detectar
los fallos.
Despus de estudiar los trabajos citados
anteriormente, llegamos a la conclusin de
que coinciden en varios puntos: Prctica-
mente todos atacan el problema de la tol-
erancia a fallos considerando que las solu-
ciones EAI estn compuestas por proceso
solo, con excepcin de [19], que se centra
en la comunicacin asncrona entre proce-
sos. Adems, dichas propuestas asumen que
los procesos ejecutan un conjunto de men-
sajes previamente correlacionados; los pro-
cesos de la propuesta [5] tampoco funcio-
nan con mltiples mensajes entrantes. Esto es
una deciencia importante pues las soluciones
EAI normalmente suelen componerse de var-
ios procesos de integracin y de wrapping;
tambin, la incapacidad para hacer frente a
mltiples mensajes entrantes es importante
puesto que hay muchos casos en que un pro-
ceso de integracin se debe iniciar con mlti-
ples mensajes procedentes de distintas aplica-
ciones. Otra limitacin comn entre los tra-
bajos que hemos revisado es que, exceptuan-
do [11, 15], todos estn pensados para el mod-
elo de ejecucin basado en procesos. Adems,
los trabajos presentados en [11, 15] estn en-
focados a procesos de control industrial repre-
sentados como redes de Petri, naturalmente,
no consideran los problemas causados por la
naturaleza distribuida de las soluciones EAI,
ni los que introducen los ecosistemas soft-
ware, ni otros problemas intrnsecos de las
soluciones EAI.
3. Conceptos fundamentales
En esta seccin presentamos los concep-
tos fundamentales del contexto de integracin
de aplicaciones empresariales en que traba-
jamos, adems introducimos la semntica de
fallos atacada por nuestra propuesta.
3.1. Soluciones EAI
La Figura 1 muestra una solucin tpica
de EAI que contiene tres aplicaciones (App1,
App2 y App3) y dos procesos de integracin
que implementan la lgica de negocio de la in-
tegracin. Consecuentemente, contiene tam-
bin tres procesos de wrapping que se usan
para comunicar la solucin con las tres aplica-
ciones por un lado y con dos procesos de inte-
gracin por el otro. Los dos procesos de inte-
gracin usan puertos conectados por canales
de comunicacin para comunicarse entre ellos
y con las aplicaciones. Los puertos encapsu-
lan tareas que se encargan de recibir, hac-
er peticiones, enviar y de otras actividades
similares. La encapsulacin en los puertos ab-
strae y esconde los detalles del mecanismo de
comunicacin. Detrs de la abstraccin po-
dra haber desde un protocolo basado en RPC
funcionando sobre HTTP hasta un protocolo
basado en documentos e implementado sobre
un sistema de gestin de base de datos.
Figura 1: Capas de una solucin EAI tpica.
3.2. Semntica de fallos
De manera informal, se dice que un sistema
es conable si sus usuarios (humanos u otros
sistemas) se fan del servicio que el sistema
ofrece. La tolerancia a fallos es un requisi-
to fundamental para ofrecer conabilidad. Su
estudio se basa en tres conceptos bsicos: de-
fectos, errores y fallos. Estos conceptos los ex-
plican ampliamente en [14, 2], sin embargo,
los explicaremos aqu brevemente. Un defec-
to es un dao (desperfecto) que existe en un
sistema, por ejemplo, una lnea de cdigo in-
correcta y que tarde o temprano puede ser ac-
tivado. Cuando un defecto es activado, causa
un error. Un error es la manifestacin de un
defecto y se percibe dentro del sistema como
una desviacin de su comportamiento nor-
mal. Si no es tratado, un error puede causar
otros errores y propagarse hasta alcanzar la
interface del usuario. Cuando la alcanza, el
usuario dice que el sistema ha fallado o que
a su sistema le ha ocurrido un fallo. Es de-
cir, un fallo es la percepcin por parte del
usuario de un comportamiento incorrecto del
sistema.
Regresando al tema de las soluciones EAI,
vale la pena no perder de vista que estas son
sistemas compuestos de otros sistemas. Por
lo tanto, el diseador debe de tomar en cuen-
ta que tanto la solucin EAI como las apli-
caciones que componen el ecosistema soft-
ware pueden, tarde o temprano, fallar. Vul-
nerables a fallos son los procesos, puertos y
canales de comunicacin. Para ofrecer solu-
ciones EAI con mecanismos de tolerancia a
fallos, el diseador necesita primero identi-
car la semntica de los fallos de los compo-
nentes. Brevemente, la semntica de fallos es
la enumeracin de los comportamientos anor-
males del sistema, que el diseador conoce y
espera que tarde o temprano alcancen la in-
terface del usuario. Despus de identicar la
semntica de fallos, el diseador debe estipu-
lar que tipos de errores la solucin EAI debe
de tolerar. Los errores se toleran evitando que
estos lleguen hasta la interface del usuario. La
tcnica mas conocida consiste en: 1) detectar
el error durante la ejecucin y 2) ejecutar una
accin de compensacin para, de ser posible,
revertir el efecto del error y regresar al sis-
tema a un estado normal. Nuestra arquitec-
tura considera los siguientes tipos de fallos: de
omisin, de respuesta, de tiempo y de proce-
samiento de mensajes.
Fallos de Omisin (OMF): Asumimos
que una vez que una operacin de comuni-
cacin se inicia por un puerto, sta termi-
na dentro de un intervalo de tiempo estricta-
mente denidos y reporta una de dos: xito o
fracaso. Los fallos de omisin modelan situa-
ciones en donde problemas de red, de aplica-
ciones y de canales de comunicacin, impiden
que los puertos enven o reciban un dato den-
tro del intervalo de tiempo denido.
Fallos de Respuesta (REF): Ocurren
cuando una aplicacin o canal de comuni-
cacin enva mensajes incorrectos a la solu-
cin. Esta los detecta aplicando un examen
de validacin (e.g., a la cabecera y cuerpo del
mensaje) cuyo resultado es una de dos: xito
o fallo. Si el resultado es fallo, el mensaje no
es procesado.
Fallos de Tiempo (TMF): Suelen ocur-
rir cuando un mensaje tiene un plazo para lle-
gar al nal del ujo. La vericacin del plazo
la hacen los puertos al analizar el mensaje.
Un puerto notica xito cuando el plazo no
se ha vencido y fallo en caso contrario. En
gran parte, los TMF dependen de los fallos
que ocurren dentro de la solucin y de los
que ocurren dentro del ecosistema software.
Fallos de Procesamiento de Mensajes
(MPF): Los puertos y procesos notican
MPF cuando algo les impide completar el
procesamiento de un mensaje; de lo contrario,
notican xito.
Vale la pena aclarar que los OMF y REF
son fallos debido a errores que ocurren dentro
de las aplicaciones o en el medio de comu-
nicacin entre las aplicaciones y el proceso
de integracin. El diseador asume que es-
tos errores no son tratados (ni dentro de la
aplicacin, ni en la lnea de comunicacin, re-
spectivamente) y que alcanzaran la interface
entre la aplicacin y el proceso de integracin
de la solucin EAI. El objetivo de tratarlos,
es evitar que estos fallos se propaguen has-
ta las aplicaciones. Los fallos TMF y MPF
ocurren dentro del proceso de solucin EAI.
4. Arquitectura propuesta
Se introduce en la Figura 2, por medio
de un metamodelo, la arquitectura que pro-
ponemos para ofrecer soluciones EAI con to-
lerancia a fallos. Este metamodelo contiene
los componentes que se necesitan para la con-
struccin de las reglas, patrones de intercam-
bio y mecanismos para la deteccin y recu-
peracin de fallos, o dicho de otra manera,
para restablecer el sistema cuando es afectado
por un fallo. De acuerdo con este metamod-
elo, una EAISolution puede denir mltiples
ExchangePatterns (MEPs) y Rules. Los Events
son noticaciones para el monitor y son gen-
erados por los Sources dentro de la solucin
EAI, que de acuerdo con nuestra semntica
cuenta con EventTriggerMessageType para no-
ticar xito o fallo durante el proceso de eje-
cucin del workow. Una fuente puede ser un
Port o un Process. Cada MEP dene un con-
junto de puertos fuente entrantes y salientes
de los que se reportan eventos. De forma re-
sumida, el MEP representa el comportamien-
to que se espera de la solucin EAI, es de-
cir, cuando solucin EAI tiene xito a la ho-
ra de procesar un conjunto de mensajes cor-
relacionados. Una regla esta compuesta por
una Condition y una Action. Una condicin
puede ser SimpleCondition que es representa-
da por un slo evento, o CompositeCondition
que contiene dos condiciones conectadas por
un LogicalOperator. Cuando la condicin es
true, Action ejecuta el correspondiente bloque
de accin de recuperacin denido por la
regla. El Monitor observa una o ms solu-
ciones EAI para detectar posibles fallos y ac-
tivar los mecanismos necesarios para tratar-
los. Como se puede ver en la Figura 3, el mon-
itor est compuesto por un Log, un Session-
Correlator, un ExchangeEngine, un RuleEngine,
un EntryPort y varios ExitPorts. Se debe ob-
servar que la arquitectura propuesta se cen-
tra en proporcionar tolerancia a fallos a las
soluciones EAI y no incluye dicho soporte a
propio mecanismo de tolerancia a fallos, es
decir, al monitor.
name : String
Rule
negated : boolean
<<abstract>>
Condition
OR AND
<<abstract>>
LogicalOperator
{disjoint, incomplete}
Monitor
1..*
1
timeout : long
name : String
ExchangePattern
name : String
<<abstract>>
Source
SimpleCondition CompositeCondition
inboundPorts
1..*
1
{disjoint, complete}
2
1
<<abstract>>
EventTriggerMessageType
OmissionFailure ResponseFailure
SuccessMessageType
{disjoint, incomplete}
FailureMessageType
<<abstract>>
TimingFailure MessageProcessingFailure
Event
destination : ExitPort
Action
1
0..*
1
EntryPort
eventPort
1
ExitPort
errorRecoveryPorts
1..*
Log
1
MonitoringSystem
<<analyses>>
date : long
time : long
LogEntry
0..*
0..*
1
outboundPorts
1..*
1
1
type
1
1
<<abstract>>
Message
1
ExchangeEngine
SessionCorrelator
RuleEngine
1
<<works on>>
1
1
Process Port
type
1
1
<<works on>>
<<works on>>
EAISolution
Figura 2: Metamodelo de una solucin EAI con tolerancia a fallos.
4.1. El Sistema de Log
El sistema de log est representado por el
elemento Log, donde se almacenan permanen-
temente todos los eventos de xito y fallos re-
portados por las fuentes dentro de la solucin
EAI. El monitor recibe los eventos a travs
de un puerto de entrada y los almacena en
el log; ah permanecen disponibles para los
dems componentes del monitor. En trminos
generales, el log est compuesto de varias Lo-
gEntries que contienen informacin sobre los
eventos, tales como, el nombre completo de
la fuente del evento, fecha y hora que ocur-
rencia y una copia del mensaje que se estaba
procesando en el momento de la ocurrencia
del evento. Por nombre completo de la fuente
debemos entender, el nombre de la solucin
EAI que origin el evento, seguido por el
nombre nico de la fuente dentro de la solu-
cin. La unicidad del nombre de las fuentes
de los eventos permite que el monitor observe
una o ms soluciones EAI simultneamente.
El log es compartido por el SessionCorrela-
tor, el ExchangeEngine, y el RuleEngine. El
log tambin puede proporcionar informacin
a un MonitoringSystem, interesado en evaluar
el estado de la solucin EAI.
4.2. El Session Correlator
El Session Correlator busca en el log men-
sajes que estn correlacionadas dentro de la
misma sesin de workow. Su salida es uti-
Figura 3: Vista abstracta del monitor.
lizada por el Exchange Engine para determi-
nar el estado de las instancias de los MEPs
y para desencadenar acciones de compen-
sacin. Dado que en nuestra arquitectura una
tarea dentro de un proceso puede tomar var-
ios mensajes de entrada y producir varios
mensajes de salida, no es trivial determinar
qu mensajes pertenecen a las diferentes se-
siones de workow. Para resolver el proble-
ma, enriquecemos los mensajes con informa-
cin acerca de los mensajes originales utiliza-
dos para crearlos; despus establecemos una
relacin padre-hijo entre mensajes para bus-
car su correlacin dentro de la sesin: dos
mensajes cualquiera m
a
y m
b
estn correla-
cionados dentro de la misma sesin si m
a
es el
padre de m
b
o m
b
es el padre de m
a
. Asimis-
mo, tres mensajes m
a
, m
b
y m
c
estn correla-
cionados dentro de la misma sesin si m
c
es
un predecesor de ambos m
a
y m
b
. Adems,
un mensaje siempre esta correlacionado con
el mismo.
4.3. El Exchange Engine
El Exchange Engine se encarga de ges-
tionar los MEPs. Un MEP representa una
secuencia de intercambio de mensajes entre
las aplicaciones participantes. En la Figu-
ra 4 ilustramos la notacin textual que us-
amos para especicar MEPs. Una solucin
EAI puede tener uno o ms MEPs, por lo tan-
to, diferentes workows de mensajes pueden
ocurrir dentro de una solucin EAI.
Los MEPs consideran slo mensajes de
xito recibidos desde los puertos monitoriza-
dos en los conjuntos Inbound y Outbound,
por lo tanto no hace falta que se especique
explcitamente los tipos. Cuando el Exchange
Engine encuentra en el log dos o ms men-
sajes que estn correlacionados dentro de la
misma sesin y que han venido de distintos
puertos de un MEP, se crea una instancia
de ese MEP y se le atribuye un max-time-
to-live; max-time-to-live es un parmetro
global y especica un plazo lmite para que
la ejecucin de una instancia termine. Los
mensajes correlacionados dentro de la misma
sesin pueden encajar en uno o ms MEPs, si
esto ocurre se crea una instancia de cada uno
de los MEPs. Inbound tiene un conjunto de
nombres completos de puertos, desde los que
se originan los mensajes entrantes. De igual
forma, Outbound tiene un conjunto de nom-
bres de puertos a los que se envan mensajes
de salida. La sintaxis para nombres comple-
tos es la siguiente: eai_solution_name::
process_name::port_name, en que
eai_solution_name por defecto corresponde
a EAISolution.
Figura 4: Sintaxis de los Exchange Patterns y Reglas.
El Exchange Engine se encarga de detectar
en las soluciones EAI los MEPs concluidos,
los activos y los incompletos; tambin es ca-
paz de detectar los mensajes que se encuen-
tran en el log durante mucho tiempo y que
no han sido tomados en cuenta para ningn
MEP. A estos mensajes se conocen como odd
messages. Un MEP concluido indica que se ha
procesado con xito en la solucin EAI var-
ios mensajes entrantes correlacionados dentro
del plazo establecido en max-time-to-live. El
Exchange Engine busca y detecta en el log
todos los mensajes de salida que estn cor-
relacionados dentro de la misma sesin para
una instancia de MEP. Una instancia de MEP
activa contiene dos o ms mensajes correla-
cionados (que no necesariamente son de sali-
da) en el log; tiene un plazo establecido por
max-time-to-live vigente y esta en espera de
ms mensajes para poder continuar su ejecu-
cin. Un MEP activo se considera incompleto
cuando se vence el tiempo de su instancia. Las
instancias de los MEPs pueden no completar
debido a los fallos que pueden ocurrir durante
la ejecucin de la solucin EAI. Cuando esto
pasa, se activa el Rule Engine que cuando sea
necesario, activa la ejecucin de un bloque de
accin de recuperacin (mirar Figura 5).
Es posible que una instancia incompleta de
MEP se complete despus del vencimiento del
plazo y despus de la ejecucin de un bloque
de accin de recuperacin. Estas situaciones
son detectadas y noticadas por el Monitor-
ing System.
4.4. El Rule Engine
El Rule Engine se encarga de gestionar las
reglas de Evento-Condicin-Accin (ECA) de
una solucin EAI. Por ejemplo, cuando la
condicin de una regla arroja true, el Rule
Engine crea un mensaje de recuperacin y ac-
tiva un bloque de accin de recuperacin por
medio de un puerto de salida. El bloque de
accin de recuperacin contiene lgica para
tratar el error. Los bloques de accin de re-
cuperacin son externos al monitor y aunque
han sido diseados especialmente para fun-
cionar con una aplicacin y canal de comuni-
cacin particular, se pueden reciclar en otros
ambientes.
Las reglas reaccionan tanto a los eventos
de xito como a los de fallos. Los eventos
se producen tanto en los puertos como
en los procesos, y llevan el nombre de la
fuente y del tipo de evento, cf. Figura 2.
La sintaxis general de nombres es la siguiente:
eai_solution_name::source_name:event_type.
Cuando el origen es un Puerto, es necesario
incluir el nombre del proceso al que el puerto
pertenece, cf. Figura 5.
5. Caso de Estudio
Para demostrar nuestra propuesta, presen-
tamos en la Figura 5 una solucin EAI (im-
plementada con la tecnologa Java) para una
empresa cticia. En esta solucin se integran
cinco aplicaciones ya existentes en la empre-
sa que funcionan de forma independiente y
que no fueron diseadas para ser integradas.
Figura 5: Ejemplo de una solucin EAI con tolerancia a fallos.
La solucin EAI tiene un solo proceso de in-
tegracin y cinco procesos de wrapping, uno
para cada aplicacin. La funcin de esta solu-
cin es obtener facturas del Billing System
(BS), mezclarlas con sus ordenes de pedidos
correspondientes y proporcionadas por el In-
ventory System (IS), y producir un mensaje
nico con toda la informacin. Una copia de
este mensaje se enva al CRM System (CS) y
otra copia al Notication System (NS), que se
encarga de noticar al cliente sobre su com-
pra. Finalmente, se enva otra copia del men-
saje al Purchase System (PS), que se encarga
de registrar las compras. Una factura puede
estar relacionada con varios pedidos; cuando
esto ocurre se utiliza el nmero del pedido
para hacer una correlacin local.
Para ayudar a entender mejor algunas de
las caractersticas de la arquitectura que pro-
ponemos, asumimos que la solucin EAI nos
impone tres restricciones. 1) Los mensajes
que se van a mezclar se deben enviar con xi-
to al CS y al PS por medio de los puertos Port
3 y Port 4, respectivamente. Cualquier fallo
que impida a una de las aplicaciones recibir
el mensaje que est correlacionado dentro de
la misma sesin, activa la ejecucin de un
bloque de accin de recuperacin para la apli-
cacin en la que se ha tenido xito. 2) Los
mensajes entrantes se consideran procesados
correctamente por la solucin en los sigu-
ientes casos: cuando todas las aplicaciones de
destino (CS, PS y NS) reciben el mensaje que
est correlacionado dentro de la misma sesin
o cuando al menos CS y PS lo reciben.
Los fallos en Port 5 no invalidan la eje-
cucin de la solucin, solamente activan un
bloque de accin de recuperacin cuyo efecto
es crear un registro que indica que el cliente
no pudo ser noticado. El diseo de los blo-
ques de accin de recuperacin no es uno de
los objetivos de este artculo. 3) La tercera re-
striccin que asumimos en esta solucin EAI
es que la informacin de las facturas y de los
pedidos debe llegar a las aplicaciones de des-
tino a mas tardar en 24 horas.
Con el objetivo de cumplir con estas re-
stricciones, hemos aadido a la solucin EAI
dos MEPs y tres reglas, cf. Figura 5. El
primer MEP dene dos puertos de entrada
y dos de salida. Esto implica que una instan-
cia del MEP se considera completa cuando se
encuentra en el log el mensaje que est cor-
relacionado dentro de la misma sesin para
todos estos puertos. En segundo MEP tam-
bin involucra el Port 5 en la lista de puer-
tos de salida; esto da lugar a otra alternativa
para que la solucin EAI se complete con x-
ito. Siempre que el Exchange Engine detecta
un MEP incompleto, el Rule Engine evala
las reglas y activa los bloques de acciones de
compensacin correspondientes.
6. Conclusiones
En este artculo hemos presentado una
propuesta de arquitectura para soluciones
EAI basadas en sistemas de soporte a pro-
cesos, con tolerancia a fallos. Comenzamos
explicando que las soluciones que otros au-
tores ofrecen se centran en el modelo de ejecu-
cin basado en procesos y, consecuentemente,
suelen consumir recursos intilmente. Argu-
mentamos tambin que desde esta perspecti-
va, el modelo de ejecucin basado en tareas
es una alternativa ms eciente y lo hemos
explorado. Hemos presentado nuestra prop-
uesta de arquitectura para tolerancia a fallos
por medio de su metamodelo, que incluye un
monitor para detectar los fallos y activar blo-
ques de accin de recuperacin. Hemos pre-
sentado una semntica de fallos que incluye
tres de los fallos ms importantes en las solu-
ciones EAI y los hemos tratado. Hemos ex-
plicado tambin, aunque brevemente, como
congurar los Message Exchange Patterns y
reglas por medio de un lenguaje basado en
Evento-Condicin-Accin. Los MEPs incom-
pletos provocan la activacin de reglas para
ejecutar acciones de recuperacin. Para ex-
plorar la viabilidad de nuestras ideas hemos
usado un ejemplo (caso de estudio) de solu-
cin EAI con soporte a tolerancia a fallos,
para una empresa cticia.
Referencias
[1] G. Alonso, C. Hagen, D. Divyakant,
A. El Abbadi, and C. Mohan. Enhanc-
ing the fault tolerance of workow man-
agement systems. IEEE Concurrency,
8(3):7481, 2000.
[2] A. Avizienis, J.-C. Laprie, and B. Ran-
dell. Fundamental concepts of depend-
ability. Technical Report CS-TR739,
Newcastle University, UK, 2001.
[3] Algirdas Avizienis. IEEE Transac-
tions on Software Engineering, SE-I
1(12):14911501, December 1985.
[4] R.H. Campbell and B. Randell. Error
recovery in asynchronous systems. IEEE
Trans. Soft. Eng., 12(8):811826, 1986.
[5] M.Y. Chen, A. Accardi, E. Kiciman,
J. Lloyd, D. Patterson, A. Fox, and
E. Brewer. Path-based faliure and evo-
lution management. In Proc. Intl Symp.
Netw. Syst. Des. and Impl., page 23,
2004.
[6] D. Chiu, Q. Li, and K. Karlapalem.
A meta modelng approach to workow
management systems supporting excep-
tion handling. Inf. Syst., 24(2):159184,
1999.
[7] G. Dobson. Using ws-bpel to implement
software fault tolerance for web services.
In EUROMICRO 06: Proceedings of the
32nd EUROMICRO Conference on Soft-
ware Engineering and Advanced Appli-
cations, pages 126133. IEEE Computer
Society, 2006.
[8] G. Dunphy and A. Metwally. Pro
BizTalk 2006. Apress, 2006.
[9] V. Ermagan, I. Kruger, and M. Menari-
ni. A fault tolerance approach for enter-
prise applications. In Proc. IEEE Intl
Conf. Serv. Comput., volume 2, pages
6372, 2008.
[10] Apache Foundation. Apache Camel:
Book In One Page, 2008.
[11] C.N. Hadjicostis and Verghese G.C.
Monitoring discrete event systems using
petri net embeddings. In Proc. 20th Intl
Conf. Appl. and Theory of Petri Nets,
pages 188207, 1999.
[12] C. Hagen and G. Alonso. Exception han-
dling in workow management systems.
IEEE Trans. Softw. Eng., 26(10):943
958, 2000.
[13] G. Hohpe and B. Woolf. Enterprise
Integration Patterns - Designing, Build-
ing, and Deploying Messaging Solutions.
Addison-Wesley, 2003.
[14] J.-C. Laprie. Dependability - its at-
tributes, impairments and means. In
Predicting Dependable Computing Sys-
tems, pages 324. 1995.
[15] L. Li, C.N. Hadjicostis, and R.S. Sreeni-
vas. Designs of bisimilar petri net con-
trollers with fault tolerance capabilities.
IEEE Trans. Syst. Man Cybern. Part A:
Syst. Humans,, 38(1):207217, 2008.
[16] A. Liu, L. Huang, Q. Li, and M. Xiao.
Fault-tolerant orchestration of transac-
tional web services. In Proc. Intl Conf.
Web Inf. Syst. Eng., pages 90101, 2006.
[17] A. Liu, Q. Li, L. Huang, and M. Xiao.
A declarative approach to enhancing the
reliability of bpel processes. In Proc.
IEEE Intl Conf. Web Services, pages
272279, 2007.
[18] C. Liu, M.E. Orlowska, X. Lin, and
X. Zhou. Improving backward recovery
in workow systems. In Proc. 7th Intl
Conf. Database Syst. Adv. Appl., page
276, 2001.
[19] Duncan Mackenzie. Building distribut-
ed applications: Architectural options
for asynchronous workow , revised
03/jun/2010, 2001.
[20] D. Messerschmitt and C. Szyperski.
Software Ecosystem: Understanding an
Indispensable Technology and Industry.
MIT Press, 2003.
[21] H.G. Molina and K. Salem. Sagas. SIG-
MOD Rec., 16(3):249259, 1987.
[22] MuleSource. Mule 2.x User Guide, 2008.
[23] OASIS. Web Services Business Process
Execution Language Version 2.0 Speci-
cation, 2007.
[24] C. Peltz. Web services orchestra-
tion: a review of emerging technologies,
tools, and standards. Technical report,
Hewlett-Packard Company, 2003.
[25] TIBCO. Tibco application integration
software, Jun 2009.
[26] M. Wright and A. Reynolds. Oracle SOA
Suite Developers Guide. Packt Publish-
ing, 2009.

RATIS: Proposal for a Reference Architecture for Traceability
Information Systems
David Quesada
Atos Research & Innovation
Atos Origin
Diagonal 200
08018 Barcelona
Spain
David.quesada@atosresearch.eu
Michele Puccio
Research & Development Laboratory
ENGINEERING Ingegneria Informatica S.p.A.
Viale Regione Siciliana, 7275
90100 - Palermo
Italy
puccio@eng.it

Abstract

The subject focus in the development of a
reference model relying in services concepts to be
used in the area of traceability information
systems (TIS) and, in general, in supply chain
management systems (SCM).
RATIS is one of the results of FP6 EC
TRACEBACK project, a 4 year integrated project
supported by the FP6 of the European
Commission developing an innovative system to
prevent food chain crises (such as those evidenced
in recent years), and therefore will allow the
consumers to make more informed choices
regarding the producers of the goods on their
supermarket shelves. This, in turn, can
significantly hinder the flow of inferior food and
encourage quality and competitiveness throughout
the European sector.
The main reason to define a reference architecture
is to solve a problem (traceability) in general and
define a set/family of solutions for such a problem
by providing how each specific solution (i.e.
concrete architecture) and its components should
look like, guidelines and best practices for
defining specific solutions, and others experience
to exploit. The side effect (and at the same time a
good motivation) for defining a reference
architecture is to have most of the general issues
already solved.

Acknowledgement. This publication is financially
supported by the European Commission in the
Communities 6th Framework Programme, Project
Traceback (FOOD-CT-036300), and Coordinated
by Tecnoalimenti. It reflects the author's views
and the Community is not liable for any use that
may be made of the information contained in this
publication.
1. TRACEBACK
1.1. Project overview
The European food and drink industry is an
important pillar of the European economy, serving
approximately 500 million consumers with a vast
variety of safe and high quality products. It is the
largest manufacturing sector in Europe, with a
turnover of ! 913 billion a year, and provides
employment to over 4 million people (CIAA,
2008). As such, difficulties in traceability
procedures can have severe consequences,
including lack of consumer confidence in food
safety. Additionally, many of the existing
implementations of the traceability process,
especially in SME, should be improved to
increase their competitiveness. However, given
the costs structure in this sector, the impact of this
redesign has to be minimized in terms of budget.
Assuring traceability of food and feed along
the whole chain from production to consumption
is a cornerstone of EU policy on the quality and
safety of food. This is a complex procedure
involving identification, detection and processing
of a vast amount of information. Moreover, any
traceability technology to be applied to the food
sector requires a high reliable and low cost
system.
TRACEBACK is a 4 year integrated project
supported by the FP6 of the European
Commission developing an innovative system to
prevent food chain crises (such as those evidenced
in recent years), and therefore will allow the
consumers to make more informed choices
regarding the producers of the goods on their

supermarket shelves. This, in turn, can
significantly hinder the flow of inferior food and
encourage quality and competitiveness throughout
the European sector.
By amalgamating emerging and existing
technologies into a single framework, the
TRACEBACK project aims to create the ideal
system in which to establish an information link
from a products raw material stage to its eventual
sale.

Figura 4. The industry is the customer of TRACEBACK
1.2. Project outcomes
An integrated cost-effective traceability
system connecting product flow and
information along the entire food chain;
Innovative reference architecture for
traceability information systems, including
software and specifications;
Automatic acquisition, processing and
transmission of data form multiple sources;
Development, testing and evaluation of two
full pilot traceability systems for the
feed/dairy and tomato food chains.
2. Traceback and Services: RATIS
Managing and supporting supply chain
traceability processes involve complex tasks from
an ICT point of view. Actors within the same
supply chain can manage traceability issues is
different ways according to sector specific legal
requirements, company quality management
policies, predefined target market and so on;
moreover the level of process automation and the
adoption of IT tools in use to guarantee
traceability can be very different within the same
supply chain: they can change from paper based
system to very advanced IT solution integrating
traceability with production and logistics
processes. As a consequence an ICT system
supporting the idea of supply chain traceability
should address a very streaked context where
several ICT systems coexist and where actors
requirements and needs are different and in some
cases could be in contrast.
One of the key results of Traceback project is the
Reference Architecture for Traceability
Information Systems (RATIS), which is a set of

specifications to develop service-oriented
traceability systems. The approach of Traceback is
to build a definition of a general framework (i.e.
RATIS Technology Suite), instead of a
traceability system. Indeed the assumption is that
a universal traceability system (though limited to a
family of food products) is not possible due to
several both technical and business reasons.
The main reason to define a reference architecture
is to solve a problem (traceability) in general and
define a set/family of solutions for such a problem
by providing how each specific solution (i.e.
concrete architecture) and its components should
look like, guidelines and best practices for
defining specific solutions, and others experience
to exploit. The side effect (and at the same time a
good motivation) for defining a reference
architecture is to have most of the general issues
already solved.
3. RATIS and RATIS Framework
3.1. Introduction
The Reference Architecture for Traceability
Information Systems (RATIS) is the specification
of a service network, by defining and describing
what services can be considered as logical
building blocks of a traceability system, how they
are supposed to interact, which functionalities are
supposed to use or provide, which information are
supposed to exchange and share, and so forth.
Therefore, RATIS aims at supporting and guiding
the development of collaborative service-oriented
information systems enabling traceability-related
processes and functions.
The definition of a common infrastructure
plays a dual role with respect to the
implementation of a software system:
it generalizes and extracts common functions
and configurations;
it provides a semantic and technological base
for instantiating (i.e. developing on the basis
of the reference architecture) target end
systems that use such a common base more
reliably and cost effectively.
The main reason to define a reference
architecture is to solve a problem (traceability) in
general and define a set/family of solutions for
such a problem by providing how each specific
solution (i.e. concrete architecture) and its
components should look like, guidelines and best
practices for defining specific solutions, and
others experience to exploit. The side effect (and
at the same time a good motivation) for defining a
reference architecture is to have most of the
general issues already solved when addressing the
development of concrete architectures.
The key issue in traceability systems is to
have a continuous flow of information among
parties along the supply chain, in order to create
and manage the links between all relevant entities
(i.e. trade items, production lot, logistic units, etc).
Therefore, RATIS aims at providing an asset base
for collaborative and distributed service-oriented
traceability information systems, covering some
required aspects that every traceability
information system should cope with. These
aspects are:
creation, acquisition, and recording of
relevant traceability data along the entire
supply chain. This includes the creation and
the acquisition of new data and information as
a result of laboratory analysis using devices
developed in WP5 or other existing devices.
Data creation and acquisition operations will
be as automatic as possible, by using
automatic identification and data capture
(AIDC) devices, tools and technologies, even
though non-automatic or manual data
acquisition will be considered as well. In this
phase, collected data could be temporarily
recorded while waiting for the actual
permanent storage;
storage of traceability data in distributed and
(semantically) interoperating repositories.
That is, regardless how supply chain partners
store traceability information (i.e. where, with
which structure, etc.), it will be made
available by using specialized data
management services;
semantically-sound exchange and sharing of
traceability information among parties (and
then among their own information systems
and ICT infrastructures) within
collaborative supply chains, in which
information flow anticipates or is parallel to
the flow of goods. This is achieved by means
of specialized data management services that
provide several facilities to retrieve and
synchronize traceability information;

exploitation, browsing and querying of
traceability information, in order to provide
users (e.g. food players, end consumers, and
other external stakeholders) with relevant
information about food flow, quality,
transportation and storage conditions, etc. On
the basis of such information, many
applications and added-value services can be
foreseen, ranging from querying traceability
data to exploiting such data to manage crisis
or assess risks related to traceability, to
performing high-level data analysis or
providing relevant information to regulators or
auditors, for certifications, and so forth.
With the aim of delivering practical tools to
develop traceability systems and not only a
documented reference architecture, RATIS comes
with a corresponding reference implementation
(i.e. the RATIS Framework), which is designed
and developed taking into account existing and
emerging technologies and standards for both
service interoperability and automatic
identification & data acquisition. The idea
underlying the RATIS Framework is to help
software developers of concrete traceability
architectures in easily and timely developing new
implementations by using and reusing the
facilities and ideas provided with RATIS.
3.2. Architecture of RATIS
According to the MDA approach, RATIS services
are specified by well-defined models, which are
graphically represented by UML diagrams. The
elements of such diagrams (e.g. entities, services,
concepts, interactions, processes) are further
described and documented by additional
descriptions in both formal and informal/textual
languages. Thus RATIS specifications are
provided at the three MDA levels (CIM, PIM, and
PSM) and focussing on both services providing
functionalities and information used by services:
RATIS Business Service Specifications (BSS)
the CIM of RATIS include business
services, which are identified and defined,
starting from requirements, in terms of
families of functionalities that users wish from
traceability systems. Therefore business
services are strictly related to requirements
and represent for the users the desired
solutions fulfilling their requirements, goals,
and needs. In RATIS, business services are
represented by UML package diagrams and
described in more details by using the RATIS
Business Service Description template.
RATIS Logical Service Specifications (LSS)
are the core of RATIS, as they are supposed to
represent services independently from the
adopted platform and technologies. Therefore
LSS is supposed to be the PIM of RATIS,
where services are the result of a
mapping/transformation of the business
services defined in BSS. Logical services are
represented by classes in UML class
diagrams, where classes are the services and
operations are the functionalities offered by
those services. The services are further
described by the Logical Service Description
template, by which their semantics and
functionalities are specified and documented
in details.
RATIS Web Service Specifications (WSS),
which are the platform specific models (PSM)
of services, in which a technology has been
chosen, i.e. Web services. Thus, in this layer,
logical services are mapped/transformed into
Web services and represented as such. This
mapping/transformation mainly concerns with
the adaptation/specialization of the services
define in the LSS, taking into account the
constraints, the specifications, the
architectural patterns introduced by the
selected technology. Therefore, one logical
service might be mapped into one or more
Web service, whereas many logical services
might be mapped into one Web services. The
same holds for operations, which could be
merged or split during such a mapping.

Figura 5. Architecture of RATIS
It is worth remarking that MDA approach is
not fully applied to the definition of RATIS.
Indeed, MDA models (CIM, PIM, and PSM) are
considered, whereas the problem of mapping
between the models is not fully supported, as
stated above. Thus, while the three levels of MDA
provide a useful framework for the definition of
RATIS specifications, the problem of model
mapping is a complex software architecture issue
and it has not been fully covered within the
TRACEBACK.
3.3. The specifications
Business Services
As explained in the previous section, we identified
a set of business services starting from the supply
chain and requirements analysis.

Figura 6. RATIS Business Services Model
Within the family of Traceability Data
Management services, Traceability Data Capture
Services aim to support the capture and
acquisition of traceability data along the whole
supply chain. Traceability data can be captured in
several ways: manual input from human operators,
interaction with a AICD devices, interaction with
sensors and/or lab-on-chip devices, interaction
with existing ICT systems installed within a food
player or a stakeholder (an analysis laboratory
should provide test results trough one of these
services). Traceability Data Analysis Services
provide capabilities to carry out analysis on
traceability data aiming at guaranteeing quick and
right problem detection, at improving supply
chain processes and at reducing their costs.
Traceability Data Storage Services are
responsible to implement and manage a suitable,
efficient and reliable storage policy for the
traceability data captured among supply chain
processes. Instead the goal of Traceability Data
Retrieval Services is to provide facilities to
retrieve the traceability data previously stored.
Another important family of business service
is Traceability, which include services for:
Alerting the right food player according to the
incoming event and the supply chain
responsibility configuration set up; Product
History to provide information about the product
origin (raw materials used, manufacturing
practices and composition) and its journey
through the food chain so far, what tests have
been done, temperature its been kept at,
processing its gone through, ingredients added
during processing, etc; Product Status to retrieve
information about the status of a traceable unit,
e.g. the last recorded location and the last
recorded values of the monitored parameters; Log
to register actions undertaken by food players in
order to manage an alert event; Auditing to
provide capabilities to improve and facilitate audit
checks, by regularly monitoring the correctness of
data and alignment of master data; and Supply
Chain Information to provide food players with all
the information needed to well understand the
supply chain where they operate.
Among Security services, Data Access
Control provide facilities to configure data access
control, data sharing level, etc. in order to supply
data to food players/customers that the owner of
the data want to reveal to. Profiling services
provide capabilities to profile food players
according to their role within the supply chain,
while Digital Signature services will ensure that
the information has not been altered since it was
sent and enable the verification of the signer's
digital identity. Moreover Authentication and
Authorization services provide capabilities to
authenticate the user who accesses the system and
to authorize him. Finally Backup and Recovery
services provide a data backup to ensure the
traceability information.
Presentation Services are about Data Filtering
to provide capabilities to filter huge amount of
data according to some user-defined rules or some
user- profile, Multi-channel and Multi-device to
present information and interact with users
according to the devices (e.g. PDA, laptop, mobile
phone etc), Browsing of the information held and
managed by the RATIS-based Systems.
System configuration services aim at
providing food players with all the facilities to
customize the system in terms of traceability
management configuration (Supply Chain
Configuration ) and enabling them to calibrate and
configure AIDC and micro-devices (Device
Configuration).
Furthermore, the family of Support services
provides High-level Data Analysis capabilities to
carry out market and business analysis on the data
gathered from the system, but not strictly related
to traceability processes. Training services (to
quickly learn about RATIS-Based System and
devices and everything needed to take advantage
from a RATIS based system) and Help services
(to assist users during the interaction with a
RATIS-based system) are also included in the
Support services
Services for external Stakeholders include
capabilities to help Accreditation and Certification
Authorities (and others external bodies) in their
procedures against the supply chain adopting the
RATIS-based System (Accreditation and
Certification Services) and .to interact with
Regulators Authorities (Regulators Interaction
Services).
Finally, Administration and Monitoring
services provide capabilities to administer and
monitor the overall system, while Mapping and
Transformation services provide capabilities to
map and/or transform data format coming from
several sources like devices, legacy systems or
external applications, into a unique and possible

standard (almost within the context of RATIS)
format.

Logical Services
Logical Service Specifications (LSS) is the
platform independent viewpoint of RATIS, which
focuses on the services and operations of
traceability systems while hiding the details
necessary for a particular platform and
technologies.
An abstract service represents an
implementation independent version of a service,
where high-level functionality has been defined
but as yet not implemented. Concrete services are
ones that are executable
1
. In our context it means
that an abstract service can be realized by several
concrete services, by adopting different
technologies, programming languages, and so
forth.
Thus, RATIS LSS represent that part of the
complete specifications that do not change from
one platform to another (i.e. Web Services, local
services, etc.). However LSS relies on the
assumption that RATIS-based traceability systems
are service-oriented architectures, where the
concept of service is central.
Within the RATIS LSS, the Logical
Information Model (LIM) plays the role of
defining the architecture and the structure of the
information used by the services defined and
specified in the Logical Services Model.

1
SeCSE Project, http://secse.eng.it/, Specification
Language Definition, final (Document Number:
A1.D2.3).
The presented model has been designed as an
extensible model so as to be able to be adapted
in order to take into account all the concepts that
will be identified and defined during the
development of the actual RATIS-based system.
Logical services defined within RATIS are
organized in packages as reported in Fig. 4, the
figure shows also dependences among packages
according to the UML semantics.
The Traceability Data Management package
includes all the services related to store, share,
retrieve and analyse traceability data. Within the
RATIS context traceability data are mainly events
and all the other data associated to a specific
event; so this package includes services for the
creation of traceability event and their storage.
The package includes also services dealing with
the retrieval of traceability data: thus services
providing capabilities to retrieve traceability
events according to different criteria are defined
within this package. The last group of services
included in the Traceability Data Management
package is the one dealing with the analysis of
traceability data. This package depends on the
Traceability Data Acquisition services to obtain
the data to be associated to a specific event and on
Supply Chain Configuration services in order to
obtain configuration information about a specific
Food Player within a supply chain.

Figura 4. Architecture of RATIS Logical Information Model
Logical services defined within RATIS are
organized in packages as reported in Fig. 4, the
figure shows also dependences among packages
according to the UML semantics.
Food Player within a supply chain.

Figura 5. RATIS Logical Services Model
Food Player within a supply chain. The
Traceability Data Acquisition package includes
services dealing with the acquisition of
traceability data from devices and legacy systems.
It clearly depends on Mapping and
Transformation package that includes services to
map and/or transform data from different
languages and ontologies.
Supply Chain Configuration package includes
services providing capabilities to each Food
Player to configure its own profile and role within
the supply chain; using services within this
package, other services are able to offer their

functionalities according to the specific needs of
each Food Player. Thus the Alerting package,
including services to manage alerts coming from
analysis of traceability data or from external
sources, depends on the Supply Chain
Configuration package in order to obtain
information about the alerting procedure defined
by a specific player. The Alerting package
depends also on the Log package in order to keep
logged each action undertaken.
The Security package includes services
dealing with the security assurance of the whole
traceability system; thus this package contains
services to guard against improper information
modification or destruction, to ensure information
no repudiation and authenticity, to preserve
authorized restrictions on access and disclosure,
and to ensure timely and reliable access to and use
of information. As a consequence, several
packages depend on security services to
accomplish their role.
The Traceability Information Retrieval
package includes services to obtain traceability
information on a specific Traceable Unit; one of
the main goals of these services is to elaborate raw
traceability data stored and provide end user with
a set of information easy to use and to understand.

Web Services
RATIS Web Service Specification (WSS) is the
platform specific model (PSM) of services, in
which Web Service has been chosen as
technological reference for the services
realization. So, within this layer, the models
presented in the previous section have been
transformed according to the constraints forced by
the selected technology.
Starting from the Logical Information Model
defined at the upper level (PIM), a Data Transfer
Object (DTO) model was defined. The DTO
model manages the same set of essential
information captured by the logical model; but its
focus is on the information exchange and on the
usage of Web Services technology. Focusing on
the information exchange makes possible to
simplify the model: e.g. if two actors need to
exchange information about a Food Player it is
possible to exchange just the identification code
(GLN) instead of the whole set of information;
each actor, starting from the identification code,
will get all the information from its own system or
asking a dedicated service.
The information contained within the DTO
model is equivalent to the information contained
within the logical model but it is organized in a
different way according to the specific scope of
the DTO model.
3.4. The RATIS Framework
The idea underlying the RATIS Framework is to
help software developers realizing concrete
traceability information systems by using and
reusing the facilities and ideas provided with
RATIS. So the RATIS Framework provides a well
defined set of Free and Open Source Software
ready to be used, a set of defined libraries and a
set of default service implementations to realize
and run a traceability information system saving
time, costs and efforts. Specifically RATIS
Framework includes the following elements:
RATIS middleware, which is the runtime
infrastructure where RATIS services and
applications can be deployed and executed;
RATIS Service Development Kit (SDK),
which is a set of Application Programming
Interfaces (APIs) supporting, making easier
and faster the development of
implementations of RATIS services, and the
supported applications according to the
technologies adopted in the RATIS
Framework;
the implementation of some services as
defined within RATIS;
some built-in components to be reused in
RATIS-based applications.

Figura 6. The architecture of RATIS Framework
3.5. RATIS in action
In the context of the TRACEBACK project we

Figura 8. An example of interface of the pilot system
4. Conclusions
Application of traceability is foreseen as one of
the key aspects to ensure quality and safety in
food. On the one hand, a quick, instant access to
the traceability information allows that a recall
procedure may be executed in a surgical way,
decreasing social impact as well as costs. On the
other hand, easy access to origin and quality
information certifies that the product matches with
the expectations created in the consumer. The
proposed results fully support these issues, in an
integrated and extensible way.
In a connected world, where people is
accessing contents at real time from any place, it
is foreseen that the food information, including
origin and quality aspects is going to be demanded
more and more often. Not only from final
consumers, but even more from companies in a
SCM, in order to better organize their production
chain. Especially for SMEs in the food sector,
they should have the opportunity to improve their
information systems possibly based in paper with
small and flexible solutions based on TBK.
Public authorities should initiate a process to
spread use of common and standard traceability
models in order to ease the cohesion among the
food chains. These reference models should be
based in open standards to allow that the entire
food sector and the food services providers sector
could be involved
In this process, the role of the proposed
reference architecture is crucial, given that it sets
open and standard mechanisms to ease and
improve the interoperability among the
traceability information systems of the food
supply chain actors maintaining, at same time, the
previous procedures, investments and practices.

RATIS and RATIS framework are basic
pieces and tools that allow the development of
new advanced traceability systems
Basic and common interchange of information
is solved with the RATIS approach, focusing the
development in the specific business of the
costumer
Commercial Traceability Information System
adopting RATIS approach will improve their
interconnection and information interchange
capabilities. This is important for costumers that
will benefit of the enhanced cohesion of the SCM
The necessary investment when moving from
paper based traceability to IT is reduced by
following the Software as a Service paradigm.
This means a business model based in pay as you
use concept instead of buying hardware, licenses,
specific software, maintenance licenses, etc
As a result of the project, there is the plan of
producing some deep impact in the society and
economics:
Support public authorities in implementing
food safety legislation;

Underpin the safety and quality of the food
chain at a cost of only 1-2 % to producers and
processors;
Help enterprises to comply with legislation;
Open new market opportunities in high-tech
and food products, specially for SMEs;
Enable faster reaction to outbreaks of food
contamination, minimizing the consequent
economic and health risks;
Reduce the gap between the industries and the
scientific research;
Promote quality agro-food products
competitiveness around Europe.
References
[1] Institute of Electrical and Electronics
Engineers. IEEE Standard Computer
Dictionary: A Compilation of IEEE Standard
Computer Glossaries. New York, NY: 1990
[2] OASIS Service Oriented Architecture TC:
Reference Model for Service Oriented
Architecture 1.0,
http://www.oasisopen.org/committees/tc_hom
e.php?wg_abbrev=soarm
[3] ATHENA Project, Working Document WKD
5.1 Perspectives in ServiceOriented
Architectures and their Application in
Environments that Require Solutions to be
Planned and Customisable. March 2004.
[4] Project SOA4All. http://www.soa4all.eu/
[5] Project ORCHESTRA http://www.eu-
orchestra.org
[7] Project TRACEBACK http://www.traceback-
ip.eu/
[6] INTEROP Project, Deliverable DAP1b
(D9.1.v2.0) State of the art for
Interoperability architecture approaches,
www.interopnoe.org.
[7] Peristeras, V. and K. Tarabanis: The
connection, communication, consolidation,
collaboration interoperability framework
(C4IF) for information system
interoperability International journal of
Interoperability in Business Information
System Issue 1: 6172, 2006.
[8] Foody, D.: SOA and ESB Are More Than
Different Answers to the Same Problem
ComputerWorld September 2005,
http://www.computerworld.com/managementt
opics/management/story/0,10801,104285,00.h
tml


U
S
E
R
Init
regist ered?
Regist rat ion
request
Login
Receive
accept ance
not if icat ion
accept ed?
Aut hent icat ion
creat ed
Aut hent icat ion
prepared
Aut hent icat ion
prepared
Aut hent icat ion
done
S
Y
S
T
E
M
Receive request
log request ?
Log user
Check user inf o
inf o OK?
Regist er user
Not if y user
Request
creat ed
Request
done
Request
accept ed
Request
denied
Regist rat ionInf o
creat ed
n
o
Request
y
e
s
n
o
n
o
y
e
s
y
e
s
yes
no
Regist rat ionInf o
Request

Our Proposal
Sadiq et al.
[22]
Ryndina et
al. [21]
Awad et al.
[4]
Insufficient input data -
Insufficient output data
C
o
n
t
e
n
t

o
f

d
a
t
a

Prohibited data
Data rule violation +
Conditional leads to violation +
Conditional precedes rule
violation
+
R
e
l
a
t
i
o
n

b
e
t
w
e
e
n

d
a
t
a

s
t
a
t
e
s

a
n
d

a
c
t
i
v
i
t
i
e
s

Segregation of duty
Data object life cycle
conformance
+
E
v
o
l
u
t
i
o
n

o
f

d
a
t
a

o
b
j
e
c
t
s

Data object life cycle coverage +
+ Implemented - Not implemented

!"#$%#&
'"#'$"#&
$!!#'%#& &#()#&
*#(%
!"#$%#&
$!!#'%#& &#()#&
&*(#
U
S
E
R
Init
regist ered?
Regist rat ion
request
Login
Receive
accept ance
not if icat ion
accept ed?
Aut hent icat ion
creat ed
Aut hent icat ion
prepared
Aut hent icat ion
accept ed
Aut hent icat ion
sent
Aut hent icat ion
denied
S
Y
S
T
E
M
Receive request
log request ?
Log user
Check user inf o
inf o OK?
Regist er user
Not if y user
Request
creat ed
Request
done
Request
accept ed
Request
denied
Regist rat ionInf o
creat ed
Request
done
Request
accept ed
n
o
Request
y
e
s
n
o
n
o
y
e
s
y
e
s
yes
no
Request
Integracin de SOD-M y DENEB: un marco para la ejecucin de
modelos de procesos de negocio
Valeria de Castro
Departamento de
Lenguajes y Sistemas
InIormaticos, Universidad
Rey Juan Carlos
25933 Mostoles Madrid
valeria.decastrourjc.es

Javier Fabra
Departamento de
InIormatica e Ingenieria de
Sistemas, Universidad de
Zaragoza
50018 Zaragoza
jIabraunizar.es
Pedro Alvarez
Departamento de
InIormatica e Ingenieria de
Sistemas, Universidad de
Zaragoza
50018 Zaragoza
alvaperunizar.es

Esperanza Marcos
Departamento de
Lenguajes y Sistemas
InIormaticos, Universidad
Rey Juan Carlos
25933 Mostoles Madrid
esperanza.marcosurjc.es

Resumen

La gestion de procesos de negocio intenta deIinir
un marco para que las organizaciones puedan
aIrontar de manera eIiciente los cambios
Irecuentes en sus procesos. Uno de los mayores
desaIios en este entorno sigue siendo la brecha
que existe entre los procesos de negocios de alto
nivel y quienes lo gestionan, y las tecnologias de
inIormacion que dan soporte a los primeros. La
Ingenieria del SoItware Dirigida por Modelos
(ISDM) proporciona herramientas que pueden
ayudar en la alineacion de modelos de procesos de
alto nivel con sus implementaciones
correspondientes. La posibilidad de ejecutar
modelos de procesos de negocio es uno de los
principales beneIicios de la ISDM. Este trabajo se
centra en este aspecto y presenta una propuesta
para el analisis, desarrollo y ejecucion de modelos
de procesos de negocio en el que se integran dos
propuestas anteriores SOD-M y DENEB. La
primera deIine una aproximacion basada en
modelos para el desarrollo orientado a servicios de
Sistemas de InIormacion que permite obtener
modelos de procesos a partir de modelos de
negocios de alto nivel; la segunda proporciona una
plataIorma basada en redes de Petri para la
ejecucion de tales modelos de proceso. Para que la
integracion sea posible es necesario llevar a cabo
la transIormacion de modelos que se describe en
este trabajo y se ilustra por medio de un caso de
estudio que se ha desarrollado.
1. Introduccin
La rapida evolucion de las tecnologias de
servicios Web y del paradigma de Computacion
Orientado a Servicios (Service-Oriented
Computing - SOC) en los ultimos aos ha
motivado el interes en ambos en el ambito de la
gestion de los procesos de negocios o Business
Process Management (BPM) |27|. BPM se deIine
como un conjunto de tecnologias y estandares
para el diseo, ejecucion, administracion y
supervision de los procesos de negocio, y como
una Iorma de ayudar a la gestion de los Irecuentes
cambios en los negocios y en las cadenas de valor
de las organizaciones |11|,|27|. Conceptualmente,
un proceso de negocio puede verse como un Ilujo
de las actividades que se realizan con el Iin de
cumplir un objetivo de negocio. Una actividad, en
terminologia de BPM, puede ser el trabajo
realizado directamente por una persona o una
interaccion con un sistema interno, un servicio
proporcionado por una entidad externa o un
proceso que realiza una organizacion asociada.
Esta nueva area de trabajo, unida a la
proliIeracion de las Arquitecturas Orientadas a
Servicios (SOA) y al desarrollo basado en
servicios, ha impulsado la aparicion de nuevos
lenguajes para el diseo y la implementacion de
procesos de negocios basados en servicios Web,
tales como el Business Process Execution
Language (BPEL) |1|, que se ha convertido en el
estandar de facto para la descripcion de procesos
de negocios ejecutables. Sin embargo, BPEL y, en
general, la mayoria de los lenguajes para la
implementacion de procesos de negocios
presentan problemas importantes tales como sus
limitaciones a la hora de ser utilizados en etapas
tempranas del proceso de desarrollo de soItware
|26|, su dependencia de una tecnologia concreta
(obligar a la utilizacion de servicios Web), o la
carencia de una semantica Iormal por parte de los
procesos resultantes que impide el analisis y la
veriIicacion de los mismos. Estos problemas
incrementan la brecha existente entre los analistas
de negocio (y las herramientas que estos utilizan)

y los desarrolladores de soItware, lo que
representa una de las principales limitaciones en el
area de BPM.
La Ingenieria de SoItware Dirigida por
Modelos (ISDM) constituye hoy en dia una de las
principales herramientas con las que se cuenta a la
hora de tratar con el problema de la alineacion
entre el punto de vista de los procesos de negocios
de alto nivel y las tecnologias de la inIormacion
que implementan tales procesos. La ISDM o
Model Driven Engineering (MDE) es un enIoque
evolutivo y prometedor para el desarrollo de
soItware |22|. La ISDM y, mas concretamente, la
especiIicacion MDA (Model Driven Approach)
propuesta por OMG |17|, constituyen una
importante herramienta para conseguir la
alineacion descrita anteriormente. Esto se debe a
que MDA proporciona una estructura conceptual
que se extiende desde los modelos utilizados por
los analistas de negocio hasta los diversos
modelos utilizados por los desarrolladores de
soItware, organizandolos de manera tal que unos
puedan ser transIormados (de Iorma
semiautomatica o automatica) en otros mas
detallados o derivados a partir de ellos,
permitiendo ademas llegar a la generacion de
codigo.
Sin embargo es evidente que tras varios aos
desde la aparicion de MDA y varias propuestas
que utilizan los principios de la ISDM, la utilidad
de esta aproximacion para el desarrollo de
soItware sigue siendo cuestionable. La principal
controversia en este tema se relaciona con la Ialta
de un soporte tecnologico que permita explotar de
Iorma completa los beneIicios de la generacion
automatica de codigo a partir de modelos |23|.
Ademas, la habilidad para generar codigo abriria
nuevas posibilidades a este tipo de soluciones. Por
ejemplo, podria ser usada como base para la
veriIicacion de procesos de negocio (cumple los
requisitos de negocio de partida?) y su analisis de
propiedades. Asi, la generacion a partir de
modelos de codigo ejecutable se convierte en uno
de los retos clave para potenciar la utilizacion de
los principios de la ISBM en el desarrollo de
soItware.
Este trabajo pretende centrarse en este ultimo
aspecto, es decir, en aprovechar los beneIicios que
la ISBM puede aportar a la hora de desarrollar
soItware y presenta un marco de trabajo para el
analisis, desarrollo y ejecucion de modelos de
procesos de negocio en el que se integran dos
propuestas anteriores, SOD-M y DENEB |5|,|7|.
SOD-M deIine una aproximacion basada en
modelos que sigue un enIoque orientado a
servicios para el desarrollo de soItware. Asi,
SOD-M deIine un proceso en el que, partiendo de
un modelo de negocio de alto nivel (nivel
independiente de computacion de la arquitectura
MDA), permite la obtencion a partir de
transIormaciones sucesivas de un modelo de
composicion de servicio (de nivel especiIico de
plataIorma de la arquitectura MDA) que puede ser
transIormado de manera automatica en un proceso
ejecutable. DENEB aparece asi como una
plataIorma basada en redes de Petri para la
ejecucion de procesos Ilexibles, capaz de ejecutar
directamente un modelo de workflow generado
como resultado de una transIormacion aplicada al
modelo de composicion de servicio.
La principal aportacion de esta propuesta
radica en la deIinicion de un marco completo de
analisis, desarrollo y ejecucion de procesos de
negocio que potencia uno de los principales
beneIicios de la ISBM y que, ademas, permite
acortar la brecha que existe entre los analistas de
negocio y desarrolladores de soItware, que es una
de las principales limitaciones a las que se
enIrentan en la actualidad las propuestas de BPM.
El resto del articulo se organiza de la siguiente
Iorma. En la seccion 2 se analizan algunas de las
principales propuestas relacionadas con este
trabajo. En la seccion 3 se introducen las dos
propuestas que sirven de base en este trabajo de
integracion, SOD-M y DENEB. El
proceso de transIormacion deIinido entre ambas
propuestas se presenta en detalle en la seccion 4,
describiendo la implementacion tanto de los
modelos utilizados como origen y destino asi
como de las transIormaciones que se llevan a cabo
entre ambos. La seccion 5 presenta un caso de
estudio con el se ha puesto a prueba el proceso
deIinido. Finalmente, la seccion 6 concluye el
trabajo destacando sus principales aportaciones y
las lineas de trabajo para el Iuturo.
2. Estado del Arte
La Ingenieria de Servicios (Service Engineering,
SE) trata de combinar los beneIicios de las
arquitecturas SOA con BPM. De esta Iorma se
consigue una alineacion entre los procesos de
negocio y los recursos de la IT que Iacilita el
desarrollo rapido de procesos agiles, capaces de

responder a los cambios en los requisitos. Pese a
que BPM y SOA representan dos iniciativas
diIerentes, con el tiempo se han convertido en las
dos caras de una misma moneda |8|. SOA
contribuye a la proliIeracion de BPM, permitiendo
que los procesos modelados mediante
herramientas BPM se puedan implementar
rapidamente utilizando la inIraestructura
debilmente acoplada que propone el enIoque
SOA. Por otro lado, BPM Iacilita la alineacion
cerrado entre negocios e IT en SOA. La
combinacion de estas dos iniciativas, por tanto,
reduce los costes de inversion, de desarrollo y de
mantenimiento de aplicaciones tanto internas
como externas en una plataIorma tecnologica
distribuida |23|.
Recientemente, la convergencia entre SE y
MDE ha puesto de maniIiesto como la utilizacion
de MDA Iacilita aun mas el desarrollo de procesos
y servicios basados en SOA a traves de modelos
|4|,|19|,|17|,|27|. La aplicacion de los estandares
de BPM a estas estrategias basadas en MDA son
el motor que aIianza esta relacion. MDA propone
la utilizacion de diIerentes niveles para
representar los diIerentes puntos de vista de un
sistema, desde el mayor nivel de abstraccion hasta
un nivel tecnologico concreto: nivel independiente
de computacion (CIM), nivel independiente de
plataIorma (PIM) y nivel especiIico de plataIorma
(PSM), respectivamente |17|. Existen diIerentes
propuestas que asocian estandares de BPM a estos
niveles |15|,|21|.
En el nivel CIM destaca la notacion Business
Process Modelling Notation, BPMN |18|. BPMN
permite modelar diagramas de procesos mediante
Ilujos, eventos, actividades y resultados, ademas
de permitir modelar subprocesos. Esta notacion
distingue entre los actores involucrados en el
proceso (pools) y las unidades organizacionales
(lanes). En el nivel PIM, la mayoria de los
trabajos apuestan por el Business Process
Definition Metamodel, BPDM, que normalmente
se utiliza junto con UML |15|. Finalmente, en el
nivel PSM el estandar de facto es el Business
Process Modelling Language, BPEL |1|. BPEL
permite describir la logica de ejecucion de
procesos de negocio deIiniendo sus Ilujos de
control y mediante mecanismos de interaccion,
generando como resultado soluciones
interoperables y robustas basadas en SOA. Resulta
importante destacar que, pese a que en muchos
trabajos se comparan BPEL y BPMN como dos
iniciativas similares, normalmente el primero es
utilizado por programadores y tecnicos, mientras
que los analistas de negocio usan el segundo.
Partiendo de la descripcion de procesos de
negocio basados en estandares, resulta clave la
generacion automatica o semiautomatica del
codigo Iuente correspondiente a su
implementacion. Pese a que la utilizacion de los
estandares deberia Iacilitar esta tarea, la realidad
es todo lo contrario: resultan complicados y
tediosos de utilizar por los analistas de negocio en
las primeras etapas de desarrollo soItware |26|.
Los principales problemas son que estos
estandares apuntan a soluciones basadas casi
exclusivamente en servicios Web, no incluyen una
plataIorma para realizar un diseo top-down y no
aportan herramientas para realizar el analisis
posterior de los procesos. Por tanto, la
transIormacion de un modelo de alto nivel a un
lenguaje de composicion que implemente el
proceso no resulta trivial.
Son varios los trabajos que han propuesto la
transIormacion de BPMN a BPEL. En |28|, los
autores proponen una transIormacion entre las
estructuras de graIo de BPMN (flow elements) y
los bloques BPEL (sequence element). Sin
embargo, no muestran una metodologia Iirme ni
una herramienta que implemente la
transIormacion. El Oracle Business Process
Analvsis Suite si aporta una implementacion de la
transIormacion entre estos estandares |6|, aunque
existen diIerencias semanticas entre el modelo
inicial y el Iinal, por lo que esta solucion solo es
viable para modelos tecnicos basados en servicios
y no se recomienda para escenarios complejos. En
|20|, los autores integran el XML Process
DeIinition Language, XPDL, con BPMN y BPEL
para generar el codigo BPEL Iinal
automaticamente. Sin embargo, esta
transIormacion se limita al intercambio de datos, y
las Iormas mas complejas de interaccion quedan
Iuera del objetivo del trabajo. Otra serie de
trabajos proponen la utilizacion de WebML|2|,
UML |5|,|2|, o xUML UML ejecutable - |10|
para generar esqueletos de codigo como resultado
de la transIormacion. Resulta evidente que la
generacion completa de codigo depende, pues, de
una intervencion humana posterior.
La Iinalidad de MDA como puente de union
entre BPM y SOA es la automatizacion de estos
procesos de transIormacion. Sin embargo, las
diIerentes alternativas presentadas evidencian

serias carencias y limitaciones. En este trabajo
abordaremos la posibilidad de integrar dos
soluciones a diIerentes niveles para proporcionar
un enIoque completo, valido y Ilexible que
resuelva los problemas expuestos.
3. Propuestas previas
La principal contribucion de este trabajo es la
deIinicion de un marco que utiliza los principios
de la ISDM para el analisis, desarrollo y ejecucion
de modelos de procesos de negocio.
Dicho marco es el resultado de la integracion
de dos propuestas previas que, unidas mediante un
procesos de transIormacion de modelos, permite
cubrir las etapas que van desde el desarrollo de
modelo de procesos de negocios de alto nivel
hasta la obtencion de modelos de procesos de bajo
nivel y la ejecucion de los mismos.
Las propuestas previas de la que se parte en
este trabajo se describen en este apartado. Por un
lado, se parte de un metodo para el desarrollo
orientado a servicios de Sistemas de InIormacion
(SI) llamado SOD-M, que deIine un proceso
basado en modelos en el que partiendo de un
modelo negocio de alto nivel permite obtener
mediante transIormaciones sucesivas un modelo
de composicion de servicios. Por otro lado, se
utiliza el entorno DENEB como marco para la
ejecucion del modelo de composicion obtenido,
para el cual es necesario llevar a cabo una
transIormacion de modelo que se describe en la
seccion 4 de este trabajo.
3.1. SOD-M: Mtodo para el desarrollo orientado
a servicios de SI
SOD-M (Service-Oriented Development Method)
|5| es un metodo basado en MDA para el
desarrollo orientado a servicios de SI. Una de las
principales caracteristicas de SOD-M es que
proporciona guias para la construccion de SI
basados exclusivamente en servicios y los
considera como objetos de primera clase para todo
el proceso de desarrollo. Este enIoque Iacilita el
desarrollo de aplicaciones orientadas a servicios y
su implementacion con tecnologias actuales, como
pueden ser los Servicios Web |4|.
SOD-M utiliza los principios de la ISDM
proponiendo un conjunto de modelos distribuidos
desde el nivel CIM, el nivel mas alto de
abstraccion de MDA, pasando por el nivel PIM
hasta el nivel PSM. Ademas, mediante reglas de
transIormacion entre modelos, provee el beneIicio
de la alineacion de los procesos de negocios de
alto nivel con la implementacion de los mismos
con las tecnologias actuales para el desarrollo
orientado a servicio.
SOD-M, que se enIoca en el desarrollo del
comportamiento del SI deIiniendo guias para la
construccion de modelos de comportamiento a
partir del modelado de negocio de alto nivel, es
parte de un marco de desarrollo mayor que integra
otros aspectos como Interface y Contenido para
generar un SI orientado a servicios completo
llamado MIDAS |3|,|25|.
En SOD-M, los conceptos de la metodologia y
los modelos en los que se representan estos
conceptos son analizados desde dos puntos de
vista: por un lado la vista del negocio, que se
centra en las caracteristicas y requisitos del
negocio para el cual se construira el sistema de
inIormacion, y por otro, la vista del sistema de
informacion, que se centra en las Iuncionalidades
y procesos que se deben implementar en el SI para
satisIacer los requisitos del negocio.
La Iigura 1 muestra el proceso de modelado
de SOD-M. Dicho proceso incluye modelos que
estan en correspondencia con: a) los tres niveles
diIerentes de abstraccion considerados por MDA:
CIM, PIM y PSM; y b) las vistas de SOD-M: de
negocio y de sistemas de informacion.
Como se muestra en la Iigura 1, el proceso
comienza con la construccion de los modelos de
valor y de proceso y, a traves de un proceso de
transIormaciones de modelos, permite obtener
como resultado un modelo de composicion de
servicios. Este proceso esta parcialmente
implementado en una herramienta MDA que se ha
desarrollado utilizando la herramienta Eclipse
Modeling Framework |24|.
Por motivos de espacio, en este trabajo solo
nos centraremos en describir el modelo de
composicion de servicios (remarcado en la Iigura
1) que se describira en detalle en la seccion 4. Una
descripcion detallada del resto de los modelos de
SOD-M puede consultarse en |5|.
El modelo de composicion de servicios es el
modelo que toma como entrada el proceso de
transIormacion de modelos deIinido y que permite
generar un modelo de workflow que servira como
entrada para la ejecucion del proceso en el marco
de DENEB.

Figura 1. Marco de desarrollo de SOD-M
3.2. DENEB: un modelo de procesos basado en
la aproximacin conversacional
DENEB es un entorno para el desarrollo y
ejecucion de procesos de negocio Ilexibles |7|. En
DENEB, un proceso de negocio esta compuesto
por un conjunto de tareas que deben ser ejecutadas
en base a determinadas restricciones de orden. La
descripcion de estas tareas y sus correspondientes
restricciones constituyen la logica de negocio del
proceso. Por otro lado, la ejecucion de una tarea
concreta puede representar la invocacion a un
proveedor externo (un servicio Web, otro proceso
de negocio, etc.) o un sistema interno (una base de
datos, un recurso hardware, etc.). Una invocacion
puede ser tan sencilla como realizar una peticion y
recibir una respuesta o puede involucrar un
intercambio de mensajes mas complejo. En
cualquier caso, las interacciones en el marco de
una invocacion son representadas en DENEB en
base a protocolos de interaccion y constituyen la
logica de interaccion del proceso. Dos conceptos
importantes son deIinidos en torno a la idea a
protocolo: roles y conversaciones. Un protocolo
de interaccion consta de un conjunto de roles, mas
concretamente, uno por cada participante en la
interaccion. Un rol representa los mensajes
intercambiados por un participante concreto. Por
otro lado, en un protocolo pueden existir distintas
secuencias de mensajes validas y alternativas (en
un protocolo de compra-venta, en un momento
concreto el comprador puede decidir aceptar un
presupuesto o cancelar el proceso de compra, por
ejemplo). Cada una de estas secuencias recibe el
nombre de conversacion.
La Iigura 2 representa una abstraccion de un
proceso DENEB. El proceso consta de un
workflow que implementa la logica de negocio. La
tarea t3 requiere interaccionar con un proveedor
externo que, en este caso, publica un servicio
Web. Previamente, el proceso habra accedido a la
descripcion del protocolo que necesita ejecutar
para interaccionar con este servicio (por ejemplo,
via un registro de servicios). Este protocolo
constara de dos roles: el interpretado por el
proceso que invoca al servicio y el interpretado
por el servicio invocado. Los mensajes enviados y
recibidos (representados con una S y una R,
respectivamente) en el contexto de la interaccion
son encapsulados como parte de la tarea t3. Por
tanto, este modelo de procesos establece una
separacion explicita entre la logica de negocio y
de interaccion de un proceso. Esta metodologia de
diseo recibe el nombre de enfoque
conversacional y tiene una ventaja relevante: la
misma logica de negocio podria ejecutar distintas
logicas de interaccion (por ejemplo, en Iuncion de
los proveedores disponibles con los que decida
colaborar). Esta decision puede ser tomada en
tiempo de ejecucion, obteniendo procesos
conIigurables, altamente Ilexibles y dinamicos.

Figura 2. Abstraccion de un proceso en DENEB
COMPORTAMIENTO INTERFACE CONTENIDO
Modelado de Dominio
Modelos
Independientes
de Computacin
Modelos
Independientes
de Plataforma
Modelos
Especficos de
Plataforma
Modelo de
Caso de Uso
Modelo de Casos de
Uso Extendido
SOD-M
Modelo de
Proceso de Servicios
Modelo de
Composicin de Servicios
Perspectiva
de Negocio
Perspectiva de
Sistema de
Informacin
Modelado de
Negocio
Modelo de Valor

3.3. DENEB: un entorno para el desarrollo y
ejecucin de procesos de negocio
El entorno de ejecucion de DENEB esta basado en
la arquitectura SOA y en el enIoque
conversacional. La Iigura 3 presenta la
arquitectura de alto nivel de DENEB. El nucleo de
DENEB consta de tres componentes clave: el
interprete de workflows, el interprete de
conversaciones y el broker de mensafes. Los dos
primeros componentes son responsables de la
ejecucion de la logica de negocio (workflows) y de
la logica de interaccion (roles) de los procesos,
respectivamente. El broker de mensajes tiene un
doble papel. Por un lado, desacopla la
implementacion de los dos interpretes de DENEB,
Iacilitando la comunicacion y coordinacion entre
ambos (por ejemplo, un workflow envia a un rol
los parametros de una invocacion y,
posteriormente, interacciona con este para recibir
los resultado obtenidos). Esta comunicacion se
produce a traves del repositorio de mensajes del
broker, por medio del intercambio de mensajes de
control y sincronizacion. Por otro lado, el broker
es el responsable de gestionar la comunicacion
con los proveedores externos (servicios Web,
procesos de negocio, etc.). Esta ultima
responsabilidad requiere una exposicion mas
detallada.
En DENEB, los mensajes intercambiados por
los roles son descritos utilizando una notacion que
es independiente de los Iormatos de codiIicacion y
de las tecnologias de comunicacion concretas
(HTTP, SOAP, RPC, etc.) empleadas en su envio
y/o recepcion. Internamente, cuando un rol
requiere el envio de un mensaje, lo escribe en el
repositorio de mensajes del broker. A
continuacion, un mediador lee el mensaje escrito,
lo codiIica en base a un Iormato especiIico y lo
envia utilizando una tecnologia de comunicacion
concreta. De la misma manera, un mediador puede
recibir un mensaje destinado a un rol. En este
caso, el mediador decodiIica el mensaje y lo
escribe en el repositorio para que acceda a el el
correspondiente rol destinatario. Por tanto, los
mediadores aislan los procesos de negocio de los
Iormatos de codiIicacion de mensajes y de las
tecnologias de comunicacion concretas.
Los mediadores tambien pueden ser
reutilizados para extender la Iuncionalidad de
DENEB sin necesidad de modiIicar el nucleo del
entorno de ejecucion. En este sentido se han
desarrollado e integrado mediadores para dar
soporte a la toma de decisiones (integrando
interpretes de reglas de negocio), para permitir
comunicaciones seguras basadas en
inIraestructuras de clave publica (PKI) o para
integrar en los procesos tareas ejecutables por
personas.

Figura 3. Arquitectura de DENEB
Finalmente, desde un punto de vista de
implementacion, en DENEB tanto los workflows
como los roles y todos los componentes de la
arquitectura han sido programados usando redes
de referencia |16|, una subclase de redes de Petri
perteneciente al paradigma de las redes-en-redes.
Esta decision Iacilita la integracion natural del
entorno con el modelo de procesos que ejecuta.
3.4. Por qu integrar SOD-M y DENEB?
SOD-M y DENEB oIrecen a nivel individual
contribuciones relevantes desde el punto de vista
del ciclo de vida del desarrollo de soItware.
Fundamentalmente, SOD-M integra la vision de
los analistas de negocio con la vision de los
desarrolladores de soItware. Esta integracion
permite que los analistas capturen y representen
en SOD-M sus objetivos de negocio.
Posteriormente, estos objetivos pueden ser
reIinados en una coleccion de diagramas de diseo
que representan los diIerentes niveles de
abstraccion del sistema objetivo. Por otro lado,
DENEB oIrece un entorno de ejecucion de
procesos de negocio Ilexibles. Estos procesos

pueden decidir en tiempo de ejecucion con quien
interactuan (un servicio, un proceso de negocio,
un sistema GRID, etc.) y como interactuan
(Iormatos de codiIicacion de los mensajes,
protocolos de transporte y comunicacion, etc.).
Nuestra propuesta pretende integrar SOD-M y
DENEB con el Iin de oIrecer una solucion
completa para el analisis, diseo, desarrollo,
despliegue y ejecucion de procesos de negocio.
Esta integracion esta basada en la idea de generar
automaticamente procesos de negocio
directamente ejecutables por DENEB a partir de
los modelos de SOD-M (mas concretamente, a
partir del modelo de composicion de servicios).
Desde el punto de vista de otras propuestas
similares, nuestra contribucion reside en dos
hechos: primero, el proceso de generacion de
codigo es automatico y, segundo, los procesos que
se obtienen como resultado son directamente
ejecutables (es decir, no son esqueletos de
procesos o Iragmentos de codigo que requieren un
trabajo extra por parte de los programadores).
Por otro lado, las propuestas ya existentes
estan basadas Iundamentalmente en lenguajes
estandar de especiIicacion de procesos (por
ejemplo, BPEL). Estos lenguajes estan
Iuertemente acoplados con las tecnologias de
servicios Web (BPEL es un buen ejemplo de este
hecho). En este sentido, nuestra propuesta es mas
Ilexible gracias a las caracteristicas de DENEB.
Un proceso no solo puede integrar servicios Web,
sino cualquier otro tipo de proveedor accesible a
traves de la Red (por ejemplo, un sistema GRID).
Simplemente se requiere un mediador que Iacilite
esta interaccion y que SOD-M represente en sus
modelos la ejecucion de una tarea por parte de
este tipo de proveedor.
Por tanto, la integracion de ambas propuestas
oIrece una solucion completa con contribuciones
relevantes desde un punto de vista comun.
4. Proceso de Transformacin de
Modelos
En esta seccion se describe la transIormacion de
modelos propuesta. En concreto, dicha
transIormacion especiIica la Iorma en que se
obtiene el modelo destino que se ejecutara en la
plataIorma DENEB a partir de un modelo origen
obtenido como resultado del proceso de SOD-M.
Es importante remarcar que aunque la
transIormacion se centra en la generacion de un
modelo de workflow de DENEB a partir de un
modelo de composicion de servicio de SOD-M,
este ultimo no es el punto de partida para la
ejecucion de los procesos de negocio sino que se
parte de modelos de mas alto nivel siguiendo el
metodo propuesto por SOD-M |5|.
En el marco de la ISDM un modelo siempre
guarda correspondencia con un metamodelo, el
cual es, en si mismo, un modelo. Existen varias
propuestas de metamodelado tales como el Meta
Obfect Facilities (MOF) deIinido por OMG o la
posibilidad de crear un metamodelo sobre un
Iichero con extension Ecore como promueve el
Eclipse Modeling Framework (EMF) |24|. EMF
es un marco de modelado y una herramienta de
generacion de codigo para la construccion de
herramientas basadas en modelos de datos
estructurados. Estos modelos se especiIican en
Iormato Ecore, que es un metamodelo EMF para
describir los modelos.
El proceso de transIormacion de modelos que
se lleva a cabo en este trabajo se ha desarrollado
sobre EMF por lo que ha sido necesaria la
deIinicion de los metamodelos de los modelos
utilizados en el proceso de transIormacion, la
generacion de los editores del mismo, de modo
que se puedan crear modelos conIormes a los
metamodelos deIinidos, y la codiIicacion de la
transIormacion en si misma.
Para automatizar la transIormacion se han
especiIicado las reglas de transIormacion
utilizando el ATLAS Transformation Language,
ATL |14|. ATL es un lenguaje de transIormacion
de modelos y una herramienta desarrollada por el
ATLAS Group (INRIA & LINA). Un programa
ATL es basicamente un conjunto de reglas que
indican como los elementos de un modelo origen
se identiIican y se navegan para crear e inicializar
los elementos del modelo destino. ATL utiliza
EMF para manejar los modelos: para serializarlos
y deserializarlos, para navegar y para
modiIicarlos. De esta Iorma, ATL trabaja
perIectamente con los modelos deIinidos
utilizando editores EMF.
La Iigura 4 muestra el proceso de
transIormacion de modelos propuesto en este
trabajo. Como puede apreciarse en la Iigura, se ha
deIinido un conjunto de plug-ins sobre EMF para
la representacion tanto del modelo de
composicion de servicio (origen) como para el
modelo de workflow (destino). En el caso del

modelo de composicion de servicio se ha deIinido
ademas una herramienta de edicion graIica del
modelo utilizando la propuesta del Graphical
Modeling Framework (GMF).
Una vez se han generado los plug-ins de los
modelos, se han identiIicado las reglas necesarias
para transIormar un modelo, las cuales se
codiIican utilizando ATL
(ServiceCompModel2WorkflowModel.atl).
Tambien se ha generado el plug-in para llevar a
cabo la transIormacion. Como puede verse en la
Iigura 4, el programa ATL se utiliza para generar
una instancia del modelo de workflow a partir de
un modelo de composicion de servicio particular.
El modelo resultante consta del workflow del
proceso de negocio y de los correspondientes roles
necesarios para implementar las interacciones del
proceso. Este modelo puede ser directamente
ejecutado sobre la plataIorma DENEB, sin
necesidad de una labor previa por parte de los
desarrolladores de soItware.

Figura 4. Proceso de transIormacion propuesto.
4.1. Implementacin de modelos
Los modelos son un elemento de primer orden a la
hora de aplicar la ISBM. Los modelos se deIinen
acorde a la semantica de un modelo de modelos,
esto es, su metamodelo.
La Iigura 5 muestra el metamodelo
composicion de servicios propuesto por SOD-M y
su relacion con un modelo concreto de
composicion de servicios. Como puede verse en la
Iigura, el modelo de composicion de servicios
representa el Ilujo necesario para llevar a cabo un
servicio del negocio mediante un diagrama de
actividad UML extendido. Por tanto, incluye
varios de los elementos tipicos para el modelado
de actividad como ActivitvNodes, InitialNodes,
FinalNodes, DesicionNodes, etc, asi como nuevos
elementos deIinidos por SOD-M como
Collaborators, ServiceActivities y WebServices.
El modelo de composicion de servicio (ver la
parte inIerior de la Iigura 5) permite identiIicar las
entidades que colaboran en la realizacion de los
procesos de negocio, llamadas Collaborators, y
las actividades que son necesarias para llevar a
cabo los servicios de negocio representadas como
un nodo ejecutable (ExecutableNode). Los
colaboradores (Collaborators) se muestran en el
diagrama como una particion. Un colaborador
puede, ademas, ser interno o externo al sistema
que esta siendo modelado. Si se trata de este
ultimo caso, el colaborador se estereoptipa como
external~~. Cada ExecutableNode identiIicado
en el modelo describe una unidad de
comportamiento basica que representa una
transIormacion o proceso en el sistema que se esta
modelando. Dichos elementos pueden ser dos
tipos: WebService (en la Iigura aparece
remarcado), que representa aquellas actividades
que van a ser implementadas (o ya lo estan) con la
tecnologia de servicios Web; o bien una operacion
simple (no implementada como servicio Web). El
elemento WebService contiene una serie de
valores etiquetados que indican las operaciones
que realiza, asi como la inIormacion requerida
para llevar a cabo la invocacion al servicio
(Endpoint, OperationName, Input/Ouput
parameters). Un elemento ServiceActivitv es una
actividad que Iorma parte de un servicio y que se
compone de varios nodos ejecutables que pueden
ser de tipo WebService o AOp (esta ultima
representa una operacion simple).
La Iigura 6 muestra el metamodelo workflow
de DENEB y su relacion con un modelo de
workflow concreto. Como todos los modelos, el
modelo de workflow se compone una serie de
elementos de modelado que se ajustan a la

!"#$%&"'()*
+",-)(."/0"&(#"
1(#23/(4
+",-)(."/0"&(#"
!"##$%&'
()*&$%'
!+,-)'
()*&$%'
!"#$%&"'()*+(,"- .-/0%1
5.%,(#
2(#34-(5+(,"-
.-//"0$-%1" !23 ,- 4526!
!"#$%&'$ (& )$(&*+($,
()"1"7+/0" 2898:
!-./$#.$ (& -0&%1%23.,
6 6 6 6 6 6
6 6 6 6 6 6
1(#23/(4
+",-)(."/0"&(#"
'(63(#)78( '(63(#)78(
!"#$%&"'()*+(."/
91(#23/(4+(."/0-,/
!+.4,
!"#$%&"'()*+(."/
!:;<'5
!:;<'5
8=<>58
!%$##&'5$.(2.6,
1(#23/(4+(."/
!"#$%&"'()*
+",-)(."/0"&(#"
?#(,(&(/
%)*/")"6,-,%(6
1(#23/(4
%)*/")"6,-,%(6
1(#23/(4-6. *#(,(&(/ "6@%6"7
8%1+/%+ ,-
2898:
!"#$%&"'()*91(#23/(4 */A@%6

terminologia de redes de reIerencias tales como:
places, transitions, arcs y sus correspondientes
inscriptions. La Iigura 6 tambien muestra de una
manera graIica como se realiza la Iorma de
representacion de estos elementos de modelado en
un modelo de workflow.

!-1"0+,-)+ ,- ;+0#+'$<$=% ,-
4-/>$<$+
!+,-)+ ,- ;+0#+'$<$=% ,- 4-/>$<$+
;+%7+/0- "
7&/+ #&*+/2$.'

Figura 5. Metamodelo y modelo de Compsocion de Servicio y sus relaciones
!-1"0+,-)+ ,- ?+/7)+? ,- 2898:
!+,-)+ ,- ?+/@7)+? ,- 2898:
7&/+ #&*+/2$.'
;+%7+/0- "

Figura 6. Metamodelo y modelo de workIlow de DENEB
4.2. Implementacin de las reglas de
transformacin
En el ambito de la ISBM, la transIormacion de
modelos tiene como objetivo proporcionar una
manera de producir de Iorma automatica uno o
varios modelos de destino (en nuestro caso, el
modelo de workflow de DENEB) a partir de uno o
varios modelos de origen (en nuestro caso el
modelo de composicion de servicios de SOD-M).
Con el Iin de automatizar tales
transIormaciones, en este trabajo recurrimos al
lenguaje ATL. Como se ha dicho antes, un
programa ATL es, en esencia, un conjunto de
reglas que determina como navegar e identiIicar
elementos en un modelo origen y como
transIormarlos en elementos del modelo destino.
La Iigura 7 ilustra el proceso y los elementos
necesarios para transIormar un modelo de
composicion de servicios en un modelo de
workflow. Como puede verse en la Iigura, una vez
hemos identiIicado las reglas de trasIormacion
para transIormar un modelo de composicion de
servicio en un modelo de workflow en un
programa ATL (ServComp2Workflow.atl), este
programa se utiliza para generar un modelo de
workflow a partir del modelo particular de
composicion de servicio tomado como entrada.
Asi, el motor de ATL intenta establecer
correspondencias entre los elementos
identiIicados en este modelo origen y el modelo
que recibe y genera a partir de dichas
correspondencias los elementos del modelo de
destino. Finalmente, el modelo de destino
obtenido se puede ejecutar sobre la plataIorma
DENEB directamente, sin ninguna transIormacion
adicional.

Figura 7. Proceso de transIormacion en ATL
Para llegar a la deIinicion del programa ATL
que permite llevar a cabo la transIormacion de
modelos se han seguido los siguientes pasos:
DeIinir las transIormaciones (mappings) entre
los modelos mediante el lenguaje natural.
Estructurar las transIormaciones en Iormato
de reglas de transIormacion, describiendolas
primero en lenguaje natural.
Implementar las reglas de transIormacion en
alguno de los marcos existentes para la
transIormacion de modelos. En nuestro caso,
esta implementacion se ha realizado con ATL.
En la tabla 1 se presentan las reglas de
transIormacion deIinidas en leguaje natural para
transIormar un modelo de composicion de
servicios en un modelo de workflow. Estas reglas
se ilustran en la siguiente seccion a traves de un
caso de estudio.
Tabla 1. Reglas de TransIormacion de SOD-M a
DENEB
O
r
i
g
e
n

Elementos
del modelo
de origen
Descripcin de la regla
Elementos del
modelo de
destino
D
e
s
t
i
n
o

M
o
d
e
l
o

d
e

C
o
m
p
o
s
i
c
i
n

d
e

S
e
r
v
i
c
i
o

Para cada
ServiceActivity del
modelo de origen se
genera un bloque en el
modelo de destino que
contiene un lugar de
entrada y uno de salida

M
o
d
e
l
o

d
e

w
o
r
k
f
l
o
w

Para cada
ServiceActivity marcada
como inicial, se genera
un lugar marcado unido
al lugar de entrada al
bloque.

Para cada
ServiceActivity
marcada como final,
se identifica una
transicin y un lugar
finales unidos al lugar
de salida del bloque.
Por cada nodo de
decisin en el modelo
de origen se genera
una bifurcacin con
una condicin de
guarda en el modelo
destino.

Por cada nodo de
unin de decisin en el
origen se genera una
unin en el destino.

Por cada nodo de
unin en el origen se
genera una estructura
de unin en el destino.

Por cada nodo de
bifurcacin en el
origen se genera una
estructura de
bifurcacin en el
destino que habilita
ramas de ejecucin
paralelas.


Por cada nodo
ejecutable en el origen
se genera un protocolo
en DENEB y la
estructura necesaria
en el workflow para
instanciarlo y ponerlo
en ejecucin. Esta
estructura se
construye usando los
valores etiquetados
como enpoint,
operations, etc.,
normalmente de
acuerdo a un esquema
genrico.

5. Ejemplo de Aplicacin
En esta seccion se ilustra el proceso de
transIormacion descrito en el apartado anterior,
utilizando como caso de estudio el sistema
GesIMED |9|. GesIMED es un sistema Web para
la gestion y el procesamiento de imagenes
medicas via Web que se ha desarrollado en
colaboracion con el grupo GTEBIM de la
Universidad Rey Juan Carlos |12|. GesIMED
permite gestionar la inIormacion reIerente a la
creacion y mantenimiento de estudios cientiIicos
para la investigacion en neurociencias. El sistema
ha sido diseado para ser utilizado,
principalmente, por investigadores en
neurociencias tales como neurologos,
neuropsicologos, neurorradiologos y diversos
medicos que realizan investigaciones en esa area.
Ademas, el sistema tambien es utilizado por los
investigadores del Laboratorio de Analisis de
Imagenes Medicas de la Universidad Rey Juan
Carlos (en adelante, LAIM).
El objetivo del sistema es oIrecer a los
investigadores en neurociencias una base de datos
de imagenes medicas disponible a traves de la
Web, sobre la que sea posible realizar todo tipo de
consultas, y una serie de procedimientos
normalizados. Esto permite a dichos
investigadores realizar el procesamiento y analisis
de las imagenes almacenadas, y cuyos resultados
son tambien almacenados en la misma base de
datos, de modo que puedan ser utilizados en
estudios Iuturos. Este sistema oIrece a los
investigadores en neurociencias tres servicios
concretos:
Servicio de almacenamiento v consulta de
imagenes medica, que permite a los
investigadores realizar consultas sobre las
imagenes, pudiendo consultar por estudio, por
modalidad de obtencion de las imagenes, por
patologia, etc.
Servicio de procesamiento de imagenes
medicas, que permite a los investigadores el
envio de imagenes o una seleccion de la base
de datos de imagenes para la realizacion de
diversos tipos de procesamiento, como la
medicion de parametros Iisicos y Iisiologicos
o la segmentacion de imagenes.
Servicio de visuali:aciones de imagenes
medicas, que oIrece a los investigadores en
neurociencias la posibilidad de realizar
procesos de visualizacion sobre las imagenes
medicas como la creacion de imagenes 3D a
partir de varias imagenes 2D.
Para acceder a cada uno de estos servicios, los
investigadores en neurociencias pagan una cierta
cantidad de dinero establecido por el LAIM.
Ademas, normalmente, son los investigadores en
neurociencias quienes proporcionan al LAIM las
imagenes sobre las que desean realizar los
procesamientos o visualizaciones.
Este sistema se ha desarrollado de Iorma
completa utilizando los modelos propuestos por
SOD-M en trabajos previos |5|. En este articulo
nos vamos a centrar solo en uno de los modelos de
composicion de servicios construidos, y vamos a
mostrar el modelo de workflow generado como
resultado del proceso de transIormacion.
La Iigura 8 muestra el modelo de composicion
de servicio construido para el servicio de
procesamiento de imagenes (Obtain processed
images). Para llegar a la construccion de este
modelo, SOD-M deIine un conjunto de
transIormaciones que toman como elementos de
entrada elementos del modelo de valor y del
modelo de procesos de servicio. La actividad
JalidateCreditCard se representa como un
servicio Web en este modelo, puesto que es un
servicio estandar oIrecido por varias
organizaciones. Tambien las Iuncionalidades
oIrecidas por los servicios de procesamiento de
imagenes medicas (SPim) y almacenamiento y
consulta de imagenes medicas (SACim) se han
identiIicado como servicios Web, dado que este
comportamiento se oIrece como resultado de una
invocacion del servidor central de la aplicacion a
los servicios correspondientes.
Una parte del modelo obtenido como
resultado de la transIormacion aplicada al modelo
de la Iigura 8 se muestra en la Iigura 9. Esta Iigura
representa la parte del workflow del proceso

DENEB resultante que comprende la actividad de
registro del pago (RegisterPav) y el servicio Web
de validacion de tarjeta de credito (JalidateCredit
Card). Debemos aclarar que el modelo de
worklfow obtenido como resultado de la
transIormacion ATL tiene una estructura de arbol.
Sin embargo, para mejorar la comprension del
caso de estudio analizado, en la Iigura 9 dicho
modelo se muestra con el editor de modelo de la
herramienta DENEB, lo que permite visualizarlo
graIicamente como una red de reIerencia.

Figura 8. Modelo de composicion de servicios para el servicio Obtain Processed Images

Figura 9. Modelo de workflow correspondiente al servicio Obtain Processed Images y generado mediante la
transIormacion
El modelo de la Iigura 9 se ha obtenido de
Iorma automatica a partir de la implementacion de
las reglas recogidas en la tabla 1. Centrandonos en
la Iigura 9, podemos ver que el pago por el
procesamiento de la imagen se ha transIormado en
un bloque etiquetado como AOp~~
RegisterPav (el estereotipo AOp se utiliza para
indicar que es una operacion y no un servicio
Web). Por otro lado, el servicio Web de
validacion de tarjetas de credito se ha
transIormado en un bloque etiquetado como
WS~~ JalidateCreditCard. Ambos bloques se
encuentran incluidos en un bloque de nivel
superior que se ha etiquetado como SAc~~
PavProcessingFee y que tambien se puede ver en
la Iigura 8 agrupando las dos actividades. Las
inscripciones y elementos que Iorman parte de los
bloques se obtienen como se explica en la tabla 1,
usando los valores etiquetados como endpoint,
operations, etc. de las actividades y de acuerdo a
un esquema generico predeIinido.
Por razones de espacio no podemos mostrar
los protocolos generados ni describir en este
trabajo como se lleva a cabo la ejecucion de
modelo de workflow obtenido sobre la plataIorma
DENEB. Los detalles de dicha ejecucion pueden
consultarse en |7|.
6. Conclusiones y Trabajo Futuro
En este articulo se ha presentado la integracion de
SOD-M y DENEB. El resultado es un marco
basado en modelos para el analisis, desarrollo y
ejecucion de procesos de negocio. Este marco
integra la vision de los analistas del negocio
(objetivos y requisitos) con la vision de los
desarrolladores de soItware (codigo ejecutable).
Esto es posible gracias a la generacion automatica
de codigo ejecutable por DENEB a partir de los
modelos de SOD-M. En relacion a otras
propuestas similares, las principales
contribuciones de nuestra solucion son: el codigo
resultante implementa el proceso de negocio
completo (en vez de Iragmentos o esqueletos del
proceso que deben ser completados por los
desarrolladores), la generacion de este codigo es
automatica y, por ultimo, los procesos
implementados pueden integrar servicios o
aplicaciones programadas en tecnologias
heterogeneas (no solo programados en base a
servicios Web, como es el caso de la mayoria de
los lenguajes de procesos como, por ejemplo,
BPEL).
Por otro lado, el codigo generado durante el
proceso de transIormacion tiene una semantica
Iormal. Esta caracteristica abre una nueva via de
trabajo Iuturo: la veriIicacion y analisis previo a
su ejecucion de los procesos de negocio
resultantes. En |13| se propuso una metodologia
para veriIicar y analizar propiedades de
comportamiento de procesos de negocio
representados con el mismo Iormalismo. Los
resultados de este trabajo podrian ser Iacilmente
adaptados para ser aplicados sobre los procesos
obtenidos a partir de los modelos de SOD-M.
Posteriormente, esta metodologia de analisis y sus
correspondientes herramientas podrian ser
integradas en el marco objeto en este trabajo.
Agradecimientos
Este trabajo se ha llevado a cabo en el marco de
los proyectos MODEL CAOS (ReI. TIN2008-
03582) y TIN 2010-17905, Iinanciados por el
Ministerio de Ciencia y Tecnologia de Espaa.
Agradecemos a Angel Cortes Maya su
colaboracion en las tareas de implementacion de
este trabajo.
Referencias
|1| BPEL 2.0 speciIication - OASIS, Available
at http://docs.oasisopen.org/wsbpel/.
|2| Brambilla, M., Generation oI WebML web
application models Irom business process
speciIications, Proceedings oI the 6th
international conIerence on Web
engineering, July 11-14, 2006, Palo Alto,
CaliIornia, USA.
|3| Caceres, V. de Castro, J. M. Vara, E.
Marcos, Model transIormations Ior hypertext
modeling on web inIormation systems, in:
SAC '06: Proceedings oI the 2006 ACM
symposium on Applied computing, ACM,
New York, NY, USA, 2006, pp. 1232-1239.
|4| De Castro, V., Marcos, E., Lopez-Sanz M.,
2006. A Model Driven Method Ior Service
Composition Modelling: A Case Study. Int.
Journal oI Web Engineering and Technology,
Vol. 2, N 4, 335-353.
|5| De Castro, V., Marcos, E., Wieringa, R.,
2009. Towards a Service-oriented MDA-
Based Approach to the Alignment oI
Business Processes with it Systems: From the

Business Model to a Web Service
Composition Model. International Journal on
Cooperative Systems 18(2): pp.225-260.
|6| Dikmans, L., TransIorming BPMN into
BPEL: Why and How. Oracle Technology
network, September 2008.
|7| Fabra, J., Alvarez, P., Baares, J.A.,
Ezpeleta, J.. Runtime Protocol Binding:
Flexible Service Integration by Means oI
Flexible Service Interactions. In 2008 IEEE
International ConIerence on Services
Computing SCC'08, pages 291-298, 2008.
|8| Frye, C., BPM inside the belly oI the SOA
whale, Web Services News (2006), 1-3.
|9| GesIMED System (2008),
http://ariadna.escet.urjc.es/gesimed/
|10| GuelIi, N., Mammar, A., "A Iormal
Iramework to generate XPDL speciIications
Irom UML activity diagrams", Proceedings
oI the 2006 ACM symposium on Applied
computing, 2006.
|11| Havey, M., Essential Business Process
Modeling, O'Reilly Media, Inc., 2005.
|12| Hernandez, J.A., Acua, C., de Castro, V.,
Marcos, E., Lopez, M., Malpica, N., A WEB-
PACS Ior Multi-center Clinical Trials, IEEE
Transactions on Information Technologv in
Biomedicina 11,1 (2007) 8793.
|13| Ibaez, M.J., Alvarez, P., Ezpeleta, J., RDF
Model Checking: A Technique to VeriIy
Behavioral Properties in Semantically
Annotated Business Processes, in: Third
IEEE International ConIerence on Semantic
Computing (ICSC09), 2009, pp. 245-252.
|14| Jouault, F., Kurtev, I., 2006. TransIorming
Models with ATL. Satellite Events at the
MoDELS 2005 ConIerence, pp. 128-138.
|15| Ko, R.K., Lee, S.S., Lee, E.W., Business
process management (BPM) standards: A
survey, Business Process Management
journal 15 (5), 2009.
|16| Kummer, O., Introduction to Petri nets and
reIerence nets, Sozionik Aktuell, No. 1,
2001, pp. 1-9.
|17| Miller, J., Mukerji, J., MDA Guide Version
1.0.1` Document number omg/2003-06-01,
Available at: http://www.omg.com/mda,
2003.
|18| OMG BPMN 1.1 - OMG Final Adopted
SpeciIication:
http://www.omg.org/docs/Iormal/08-01-7.pdI
|19| OMG MDA standars, www.omg.org
|20| Palmer, N., Understanding the BPMN-
XPDL-BPEL Value Chain. Business
Integration Journal, No.
November/December 2006, pp. 54-55.
|21| Roser, S., Bauer, B., A categorization oI
collaborative business process modeling
techniques, Proceedings oI the Seventh IEEE
International ConIerence on E-Commerce
Technology Workshops, IEEE Computer
Society, Washington, DC, USA, 2005, pp.
43-54.
|22| Selic, B., 2003. The pragmatics oI Model-
Driven development. IEEE SoItware Vol. 20,
N 5, pp. 19-25.
|23| Selic, B., 2008. MDA ManiIestations.
Upgrade, The European Journal Ior the
InIormatics ProIesional, V. N2, pp.12-16.
|24| Steinberg, D., Budinsky, F., Paternostro, M.,
Merkset, E., 2008. Eclipse Modeling
Framework (2nd. Ed.). Addison-Wesley
ProIessional, 2008.
|25| Vara, J.M., Vela, B., Bollati, V., Marcos, E.,
Supporting model-driven development oI
object-relational database schemas: A case
study, in Proceedings oI the 2nd International
ConIerence on Theory and Practice oI Model
TransIormations, Springer-Verlag, Berlin,
Heidelberg, 2009, pp. 181-196.
|26| Verner, L. 'BPM The Promise and the
Challenge. Queue of ACM, Vol. 2 (4), pp.
82-91, 2004.
|27| Watson, A., 2008. A, BrieI History oI MDA.
Upgrade, The European Journal Ior the
InIormatics ProIesional, V. N2, pp.7-11.
|28| White, S., Using BPMN to Model a BPEL
Process. IBM Corp., United States.

An Innovative Integrated Approach to Services Composition
RaIael
Gonzalez-Cabero
Technosite
Albasanz, 16
28038 Madrid
rgonzaleztechnosite.es
Yosu Gorronogoitia
Mateusz Radzimski
ATOS Research
Albarracin, 25
28038 Madrid
jesus.gorronogoitiaatosresearch.eu
atosresearch.eu

Freddy Lecue
The University oI Manchester
Booth Street East
Manchester, UK
Ireddy.lecuemanchester.ac.uk
Matteo Villa
TXT e-Solutions
Via Frigia, 27
20126 Milan, Italy
matteo.villatxt.it

Abstract

Automated Web service composition has been
tackled Irom diIIeren t directions and with
diIIerent purpo ses. More over, most oI these
approaches address the composition problem with
underspeciIied requir ements, returning
compositions models that d o not necessar ily
satisIy and IulIi ll end-users ob jectives. Sat isIying
thse obj ectives is a d iIIicult u nd es pecially in
cases where the servic e is bui lt Irom scratch . I n
this work we present the work that we are carrying
out in the context oI the SOA4All
1
project. In this
project we un dertake th is task proposing an
innovative and multiIacet approach, which
consists in i) an au tomatic t emplate proc ess
generator, that is able to generate abstract process
templates and their hi erarchy Iorm pa st
executions; ii) a novel and scalable appro ach to
parametric-design techniques usi ng a m ulti agent
approach to conIigure and adapt s ervices
processes, hea vily rely ing on the l atter se t o I
abstract proc ess tem plates; i ii) an optim ization
process that maximizes the overall quality oI Iinal
compositions. AIter descri bing in a theoret ical
manner our approach, we d escribe th e Iir st
implementation that we have perIormed,
comparing th e s oItware cha racteristcs oI its
components alongside some experiments.
1. Introduction
A key to th e s uccess oI a dis tributed business
service model r elies in the possibilit y oI r eusing
the we alth oI existing servi ces, r eusing t he
services descriptions alongside the experience that
emanates Irom their pas t use, into the elabor ation

1
http://www.soa4all.eu/
oI new on es. These new compositions may
provide nov el and complex Iun ctionalities, ev en
with bet ter ov erall qu alities (e .g., in terms oI
QoS). However, given the requirements Ior a new
service, the t ask oI identiI ying t he set oI existin g
ones useIul to its realization, the righ t
combination, and the optim ization oI its result is
extremely demanding and time-consuming Ior a
human operator. In addition , composing services
Irom scratch is a com plex task that m ay Ia il t o
satisIy the end-users` object ives. Ther eIore, th e
development oI support tools in this respect is
necessary to e nact a dis tributed s ervice v iew.
Ideally, such tools should be able to automatically
generate an optimal composed service, starting not
only just Iro m properly I ormulated user
requirements (such as preIerences and constraints,
overall goal) b ut also with u se oI pred eIined
template (or sche ma ge nerally speaking) based
composition in order to assi st the end-user.
However, up to now, the s earch Ior s uch a Hol y
Grail has been unsuccessIul. This is mainly due to
the Ia ct that most oI com position appro aches
make composition requi rements and goals
underspeciIied and even not co nsidered in some
cases, considering compositions Irom scratch an d
with Iew constraints, wh ich is ver y diIIicult.
Towards suc h issue s some te mplate ba sed
composition ap proaches ( e.g. |26|) have been
proposed in the literature , then com ing up with
some pre-existi ng and pr edeIined com position
templates read y to be instan tiate. Howeve r, th e
latter templates are required beIore starting
the com position process, and i n addition their
results tend to be Iar Irom optimal.
Consequently, automated co mputation oI
optimal com position with support oI on-the-I ly
compositions t emplates is n ot consider ed in
literature. This means that, in o rder to obta in a n
end-to-end architectur e that gener ates

compositions te mplates, inst antiate them with
concrete service and then optimize them, we need
to chain and integrate diIIer ent, phase-speciI ic
techniques.
Since the sel ection oI initi al te mplate b y the
end-users has high impact on th e relevance oI the
Iinal r esult, p hases high in the ch ain m ust
eIIectively prov ide appropriate s peciIications oI
compositions templates so that phases lower in the
chain can Iocus on concretize them in an op timal
Iashion. This c alls Ior a car eIul adapt ation a nd
integration. Our contribu tion in this work is a n
architecture des igned and r ealized within th e
context oI th e SOA4All project, perIorming end -
to-end template gen eration and optimal
composition by seamlessly int egrating a tem plate
generator, a service composer and optimizer. This
integration poses serious ch allenges, in particular
at the interIace oI the t emplate gen erator and
composer, where a high-l evel com position
speciIication (or tem plate) m ust be pick ed Irom
the av ailable o nes to as sist the end-us er in the
composition an d optimizat ion process. For the
individual com ponents, we u tilize and ad apt
appropriate state-oI-the-ar t techniques, except Ior
composition where we provide a novel, advanced
and Ilexible technique, able to divide a complex
modeling problem into many domain-speciIic sub-
problems that can be tackled by multi-agents with
specialized knowledge.
The current ins tantiation oI ou r arch itecture
adopts two well-known de scription Irameworks,
the WSMO |28 | ontology, and BPEL4SWS |23 |
Ior describeing Iormally services and
compositions re spectively. This ele ction m akes
our archit ecture im mediately us able in
conjunction with standard Web services engines
such as Activ e BP EL, as wi tnessed b y our
experiments on an E-Commerce scenario.

Figure 1 SOA4All Service Composition Architecture
2. SOA4All Service Composition
Architecture
In Figure 1 we provide a gen eral view oI the
SOA4All s ervice com position arhic tecure. The
rationale oI our service composition approach is
that us ers handle an abs tract and eas y to u se
processes representation, that one the on hand will
ease enormously i ts us age; and on the oth er wi ll
be Ilexible eno ugh to allow its later context-
dependent custo mization. The user will hand le
coarse-grained goals, and the system will car ry
out int elligently the transIormation in t o concrete
and ex ecutable processes th at the s ystem w ill
tailor to the concrete exe cution context and th e
current state oI aIIairs.
The transIormation process is carried out
using a knowledge-in tensive conIigur ation
process, more precisely a parametric design
process. As we shall see, in ord er to incre ase the
scalability oI this process, we will ext end th e
classical approach to this s ynthesis task b y using
an opportunistic approach, b ased on blackboard -
based multi-agent system. Nevertheless, the hearth

oI this system, as in cl assical approaches, is a set
oI reusable process templates that capture patterns
oI Iunction ality oI the s ystem. Usually on ly
knowledge-experts are mean to create th ese
templates, but we will provid e an autom atic
template generator s ystem that will ease experts`
task, and in so me cases, will allow end-users to
obtain their ow n templates based on prev ious
processes enactments.
Finally, wh en the s ystem has generated an
executable process we will perIorm , upon use r
request, an optimization pro cess on it, as the
opportunistic.
In the Iollowing sections we will describe the
components that realize the aIore-descr ibed
activities, the Template Gener ator that ex tracts
process tem plates Irom pas t executions (s ection
2.1 Templates Generato r); the De sign-Time
Composer that perIorms the parametric desig n
(section 2.2 Design-Time Composer); and last but
not l east, th e Com positions Optim izer th at
optimizes the generated executable proces ses
(section 2.3 Service Composition Optimizer).
2.1. Templates Generator
Designing complex processes, composed oI
several services invocation, can be a diIIicult task
Ior end-users. O n the o ther hand, the av ailability
oI pre-deIined process template can ease this task.
Anyway, how to deIine such templates may als o
be a diIIicult or expensive task, especially in those
situations wher e eith er an a- priori m odel i s
unknown or the eIIort to cr eate the model is to o
complex. Proces s Mining techniques |8| |27| ai m
at autom atically discovering a process model,
based on data g athered during its past execution s
(logs). Most oI existin g state-oI- the-art
approaches is devoted to ident iIy a s ingle process
Iormalisation, oIten resul ting in parti cularly
complicated t emplates and n ot ver y a ccurate
(single template Ior all possible execut ions). The
resulting template, even iI Io rmally complete and
adequate to support a process execution, turns out
to provide little help to let end-users understan d
what the hidden process template.
Several appro aches have been undertaken to
solve thes e kin ds oI problem s. The Template
Generator adopts the methodolog y proposed b y
|11|, aiming at discovering not a single template,
but rath er an hi erarchy oI pos sible t emplates, a t
diIIerent abstraction levels, where leaves represent
a disjoin t set oI possible executions, and h igher
level pres ent a more abs tract vi ew, as s hown i n
Figure 2.

Figure 2. Mining approach oI the Template Generator.
The Tem plate Generator wi ll then present
users with such graphical representations, and le t
them the Ireedom to choose the template that best
Iits their goals.
While this approach is Iound to be very useIul
in intr a-company s cenarios, where proc ess
executions log s are t ypically g enerated b y
enterprise legacy systems, new challenges emerge
when trying to adopt such technologies to address
the In ternet oI servic es, du e to the ver y open
nature oI the Web. First oI all, it should be noticed
that th e problem oI deriving r elevant and us eIul
process templates out oI their services executio n
logs is still rel evant: in Iact users could be
actually Io llowing some process while invokin g
services in a lo gical sequence, or they may b e
actually par ticipating in som e collabora tive
process with other Intern et users, without ev en
being awar e oI this Iact, or without hav ing th e
process structure Iormalized somewhere.
The Iirst challenge encountered is linked with
the diIIiculty Ior a user to understand the meaning
oI the services Iorming the proposed templates: it
is obvious that service names (operations) do not
necessarily reveal what`s a service is about in an
intuitive way, and in any case this may be subject
to diIIeren t int erpretations. This situation woul d
not happen in intra-company environments, where
a common taxonomy is usually well established.
To addres s thi s chall enge, the Tem plate
Generator ex ploits se mantic techno logies,

including semantic el ements as sociated with
services in the templates presented to the user , so
that a better un derstanding oI the service scop e
could be ach ieved. I t should be noticed th at the
Template Gene rator doesn`t requir e the
availability oI sem antic annotations on services,
but it can ex ploit them whenever th ese a re
available.
The second challenge arises w hen tr ying to
decide upon which logs should be analy zed as
input, due to the expected large amount oI users
and services invoked over the Internet, and due to
the Iact that these belong to diIIerent contexts: just
taking all logs together would result in non -sense
templates.
Due to such reasons it is necessary to Iollow a
contextual-driven Iiltering approach to input logs,
so that onl y contextually coherent logs will b e
processed together b y the Te mplate Gene rator
component. UnI ortunately this problem does n ot
have a simple so lution: it is not possible to deI ine
an a-prior i Iix ed template oI s uch cont ext, as it
should describe potentiall y an y situation, and it
would even tually turn to b e oI li ttle he lp in
speciIic s ituations. According to a ' context
Iramework, where cont extual inIorm ation i s
structured along a number oI aspects or
dimensions, app lications hav e to play an activ e
role in indicating the modelling resource used Ior
capturing con textual inIormation as well as
directing th e wa y this inIorm ation is kept an d
managed. The Template Generator will then allow
users to d ynamically conI igure and cus tomize
such Iramework based on more speciIic 'vertical
scenarios, in a graphical and intuitive way.
The output oI the Template Generator is the
template selected by the end-users. As explained,
such tem plate c an inc lude on e or more abstract
activities, and includ e s emantic des criptions
associated with each proc ess ac tivities. The too l
allows exporting such template to other Iormats,
so that end-users have the possibilit y to change or
reIine it in some graphical editor.

2.2. Design-Time Composer
The design-time composer development has been
driven b y some modeling prin ciples: i) i terative,
incremental, eas y to us e, s emi-assisted
compositions modeling , ii) coarse-grained go al
based act ivity-centric descript ion oI compositions
models, as opposed to th e ser vice-centric SOA
composition approach, iii) semantically annotated
activity descriptions (goals), iv ) intensiv e r euse
and customization oI preexistin g domain speciI ic
process templates and Iragments, v) context-aware
model composition and adaptation. In this picture,
the c omposer assists ite ratively human modelers
to complete the composition model, by IulIilling
required model gaps leIt by human modelers, with
inIormation extracted Irom diII erent knowledg e
sources.
The com poser acc epts an incom plete
composition model, which comprises a set oI
activities, logi cally linked by a d raIt wo rkIlow,
coarse-grained described b y their requir ements
(goals) and expressed as a set oI annotations th at
reIerence sem antic con cepts deIined with in a
shared ontolog y. The composer returns a mor e
elaborated composition model which has resolved
some oI its inIormati on gaps: activities are bound
to con crete W eb services, or expand ed with
compositions templates or Iragments, data Ilow is
populated with connector s mediating between
Input/Output pa rameters, sem antic com patibility
between subsequent the latter pa rameters i s
checked, etc. The composition approach increases
the level oI concreteness oI composition models;
closer to executable as opposed to abstract and
adaptable (Figure 3).
This ad aptable concretization tr ansIormation
is implemented using a kno wledge-intensive
conIiguration process, more precisely ' a
parametric d esign procedur e |29|. In order to
increase the sc alability oI th is procedure, w e
extend the clas sical approach to its synthesis task
by using an o pportunistic approach, b ased on
'blackboard-based multi-agent system |9|. Multi-
agent architecture allows also Ior extra Ilex ibility
with regard to manage ment oI knowledgebase
used b y the composer, b y allowing Ior hot-
plugging or u pdating knowledge while th e
composer is operating . This can be eith er adding
new ontologies, services and templates
capabilities or r egistering completely new agents
as well.

Figure 3. Adaptable concretization oI compositions.

From a high level design model oI a
composition given by an end-us er, the composer
converts the composition modeling probl em in a
parametric d esign problem | 22|. In such a
mapping, the parameter set is mapped to the set oI
unbound activities, whose valu es range is either
the range oI available ser vices or process
templates. The potential design model solution s
are requ ested to satisI y some constraints,
requirements and preIerences parameters (used to
express limitations and desires on the requ ested
Iunctionality). T hen th ey ar e all cl assiIied along
properties oI com pleteness, adm issibility a nd
suitability |22|, but not in term oI overall quality
(e.g., QoS).
The com poser im plements t his s ynthesis
phase oI parametric design procedure with a
blackboard-based m ulti-agent s ystem.
Autonomous and specialized agents share a
common backboard upon which they post new
design models, which are modiIied versions oI
previously posted ones, aIter apply ing ch anges
driven by some speciIic knowledge.
Some agents, n amed as Design ModiIication
Agents (DMA) , are specialized to introduce
changes in the models, while other agents , named
as Design Analysis Agents validate those changes.
All oI the DMAs semantically m atch th e
composition activities with a service or a template
by considering sem antic sa tisIiability oI the
(semantic) int ersection oI their Iunctional
descriptions (i.e., deIin ed b y input, ou tput,
Iunctional cl assiIication, re quirement, and
preIerence). P reconditions, eI Iects im ply logical
expressions we don`t support, event we cannot
expect end- users to express such
Preconditions/EIIects logical expressions.

In our approach, Iour DMAs have been designed:
A Domain SpeciIic Languag e |21| DMA,
which explo its descriptions oI services and
process tem plates accord ing to concret e
compositions require ments. A possible
domain languag e used to descr ibe available
knowledge about known services and
composition templates ar e s hown below,
where th e Iun ctional c lassiIications s imply
reIer to a concept in a hier archy oI domains
(see WSMO-Lite deIinition |28|).
A Service Discover y |4| DMA, which binds
activities to con crete s ervices. The dis covery
process acts on Iunctional classiIication, input,
output, preconditions and eIIects parameters.
The resul t oI c andidate servi ces is Iilter ed
based on the matching quality oI the input and
output parameters oI their operations.
A Semantic ser vice description DMA, which
exploits domain speciIic d escriptions oI
services and g oals, a ccording to concr ete
composition requirements. In contrast to
Service Discovery DMA, this DMA is
enhancing design process b y taking into
account addi tional inIormation to narrow the
target oI candidate servic es: do main speciI ic
knowledge, global annotations and contex t oI
compositions.
A Semantic Link Design Operator |16| DMA ,
which establ ishes dataIlow in th e models. In
other words thi s DM A checks the s emantic
compatibility b etween the inp ut and ou tput
parameters oI connected compositions bound
activities and creates suitable connections,
constituting the com position data Ilow. The
latter com patibility is valu ed by diII erent
standard match ing ty pe between semantic
descriptions oI output and input parameters oI
services, by order oI semantic quality: Exact
(i.e., same con cept to descr ibe output and
input par ameters), Pl ugIn (i.e., the output
parameter is m ore spec iIic th an th e inpu t
parameter), S ubsume (i.e., the outpu t
parameter is m ore gen eral than the inpu t
parameter) |24| and In tersection (i.e., some
properties are in common) |19|. Such a DMA
acts on m odels that ar e alr eady complete in
terms oI parametric design pr ocess, which
means that all s ervices are bou nd and m odel

contains all necessar y inIormation to st art
dataIlow mapping.
The aim oI the blackbo ard is to control and
coordinates the autonomous and independ ent
agents. At th e beginning oI composition
procedure, the b lackboard is see d with an init ial
design plan, whose assignm ent set is em pty. At
the end oI the procedure none or several Iound
solutions are returned (completed assignment set).
The procedure Iinalizes either when the r equested
number oI solutions are Iound or when the DMAs
can not post new design models.
The main advantage oI th e blackboard-based
multi-agent par ametric d esign approach is to
divide a complex composition p roblem into many
domain-speciIic sub-problems that can b e tackled
by agents with specialized knowledge. Th is
approach also is quite Ilex ible, s ince every agent
can be implemented usi ng diII erent technolog ies
depending on the specialized knowledge. Another
advantage is that we onl y requ ire t hat
compositions are annotated with semantic model
reIerences (a la sawsdl, e,g., BPEL4SWS) but not
with com plex sem antic axioms, logic al
expressions.
2.3. Service Composition Optimizer
Since th e des ign-time com poser aim s at on ly
computing com positions that s atisIy a spec iIic
goal and does not consider glob al optimization oI
a composition, a step oI optimization is requi red.
Mostly due to perIormance opti mization, context
adaptation or s peciIic user preIeren ces an d
constraints, it is necessar y to optim ize the
completed compositions. While the input to th e
composer is generally a rather goal-heavy process
speciIication, the optimizer only accepts complete
process models Ior which it seeks a better glob al
cost Iunction ( in term oI Iun ctional and non
Iunctional qual ities oI services ). The optim izer
transparently tra nsIorms compositions into thei r
optimal version s b y r eplacing service bindin gs
and modiIying the dataIlow but without changing
the workIlow (i.e., its structure, see Figure 4).

Figure 4. Process optimization by recombining services.
The opt imizer receives a complete proc ess
model and tries to repl ace current bound services
with other Web services that make b etter glob al
cost Iunction ( e.g., better glo bal perIorman ce).
The cost Iunction oI our optimization appro ach
uses a combination oI Iun ctional and no n-
Iunctional co nsiderations. The Iunc tional
perspective comprises a se t oI metrics re lated to
how well the I unctionalities oI the consti tuent
services Iit together. The semantic quality is such
a core m etric, measuring the d egree oI s emantic
similarity b etween th e outpu ts produced b y
constituent services and the in puts required by
their peers. Such a qualit y is one oI the m easures
oI the over all Iunctional quality Ior the
composition, in dicating the 'goodness oI Iit
between the I unctionalities o I the constituent
services. To m easure th e deg ree oI s emantic
similarity, we u se the con cept oI sem antic l ink
(also used b y the composer), and so a semantic
reasoning component which evaluate subsumption
oI concep t-based para meters. We b se rvice
compositions could t hus be optimi zed and ranked
using not only nonIunctional p arameters such as
the well-known QoS |5| , but also using semantic
quality as a cor e indicator oI I unctional quality
|16|. In the same way as |18|, we suggest to uniIy
both types oI criteria, allowing u s to estimate an d
optimize the quality oI service compositions.
In addition ru les Ior aggregating quality
values oI services and seman tic links in th e
composition are required . Th e approach Io r
computing semantic quali ty oI compositions is
adapted Irom the appli cation-driven heuristics oI
|16|, while the computation oI its non-Iunctional

QoS is sim ilar to |6| . For inst ance, th e ov erall
price oI a sequence-based composition oI services
is valued b y th eir av erage whereas its response
time is valued by their sum.
Optimizing the qualit y oI sem antic links
between services and QoS a ims at not only
consider non Iunctional properties such as price or
availability rate but also the quality oI semantic Iit
along non-trivial data Ilow, wher e the inIormation
required and provided by services does not match
perIectly in ever y dataIl ow, using semantic-based
description oI services. B y addr essing non-trivial
data Ilow in composition, we aimed at limiting the
costs oI (semantic h eterogeneity) data in tegration
between services b y considering appropr iate
quality oI semantic links.
Optimizing the quality oI service composition
using this m odel is essenti ally a m ulti-objective
optimization pr oblem |1| with constraints an d
preIerences on the qual ity oI s ervices and thei r
semantic links. Such a problem is known to be
NP-hard |25| , thus putting in to quest ion th e
practical applicability oI such optim ization I or
compositions oI real istic s cale. To s peed up the
application oI the proposed optimization model in
a context oI realistic scale, we adapt the approach
based-Gas oI |5| in order to consider no n-
Iunctional pro perties oI ser vices and no n-
Iunctional qua lities oI se mantic links between
services. In addition we extend the latter model by
revisiting th e Ii tness Iunct ion i n order to avo id
local optim al solution (i. e. com positions
disobeying constraints are considered).
Roughly speaking, the execution oI the GA
consists in th e Iollowing steps: i) deI ining the
initial population (as a set oI concr ete
compositions), and computing the cost Iunctio n
(used as an evalu ation criterion) Ior e ach
composition; ii) evolving th e population b y
applying mutation and cro ssover oI compositions
(this step simp ly binds new services in the
composition b y discover y close service in th e
service repository); iii) selecting compositions; iv)
evaluating compositions oI the p opulation; v) and
back to step ( ii) iI the stoppin g criterion is n ot
satisIied in th e GA evolution. I n case no soluti on
exists, users are requested to relax constraints oI
the opt imization problem in order to compute
alternative solut ions still provid ing a reasonab le
quality oI composition (at both QoS and semantic
levels).
The optimization process changed the service
binding oI the process returned by the Composer
by discovering services with better non Iunctional
qualities and also with highe r semantic quality oI
the links b etween servic es, th e whole im pacting
the overall quality oI the composition as well.
In case oI conIlicts e.g., the value oI the non-
Iunctional qua lity is th e be st Ior a Iirst
composition bu t worse regard ing the semantic
quality, we com pare a weigh ted averag e (with a
weight oI 1/2) oI their normalized values.
3. Acknowledgements
The work pr esented in this p aper has been
Iully Iunded by the European Commission under
the project SOA4All (FP7- 215219).
References
|1| Ardagna D., Pernici B .. Adaptiv e servi ce
composition in Ilexible processes. IEEE
Trans. SoItware Eng., 33(6):369384, 2007.
|2| Agrawal R., Gunopulos D., Ley mann F.,
Mining process models Irom workIlow logs,
in: P roceedings oI the S ixth Internat ional
ConIerence on Extendin g Database
Technology, 1998, pp. 469483.
|3| Arpinar, I.B ., Zhang, R ., Alem an-Meza,
B.,Maduko, A.: Ontolog y-driven Web
services composition platIo rm. InI. S yst. E-
Business Management 3(2), 175199 (2005).
|4| Benatallah B. , H acid M ., Leger A ., Re y C. ,
Toumani F.: On autom ating Web services
discovery. VLDB J. 14(1): 84-96 (2005)
|5| CanIora G ., Di Penta M., Esp osito R., and
Villani M. L.. An approach I or qos-aware
service composition based on genetic
algorithms. In GECCO, pages 10691075,
2005.
|6| Cardoso J., Sheth A. P., Miller J. A., Arnold J.,
and Kochut K.. Quality oI service Ior
workIlows and web service processes. J. We b
Sem., 1(3):281308, 2004.
|7| Cook J.E., W olI A.L., SoItware process
validation: qu antitatively m easuring the
correspondence oI a process to a model, ACM
Transactions on SoItware Engineering and
Methodology 8 (2) (1999) 147176
|8| Cook J.E. and WolI A.L.. Automating process
discovery through event-data analy sis. In

Proc.17th Int. ConI. on SoItwar e Engineering
(ICSE`95), pages 7382, 1995.
|9| Erman L. D., Hayes-Roth F., Lesser V. R., and
Reddy D . R.. The Hearsay -II speech-
understanding s ystem: In tegrating knowledge
to resolve un certainty. Computing Survey s,
12(2):213253, June 1980
|10| Gold E.M., Complexity oI autom ation
identiIication Ir om given data, InIormation
and Control 37 (3) (1978) 302320.
|11| Greco G., Guzzo A., and Pontieri L., Mining
hierarchies oI models: From abstract views to
concrete speciIications. In BPM, pages 32--
47, 2005
|12| Hakimpour F., Sell D., Cabral L., Domingue
J., Motta E .: Sem antic W eb Service
Composition in IRS-III: The Structured
Approach. CEC 2005: 484-487
|13| Teije, A. t. van Harm elen, F . W ielinga, B.
ConIiguration oI Web Services as Parametric
Design. Lectur e Notes in Computer Science.
Springer Verlag. ISSU 3257, pages 321-336.
2004
|14| Hassine A. B., Matsubara S., and Ishida T., A
constraint-based approach to web s ervice
composition. In ISWC, pages 130143, 2006.
|15| Lecue F ., Opti mizing QoS -Aware S emantic
Web Service Composition. In P roceedings oI
the eigh th In ternational Se mantic W eb
ConIerence (I SWC 2009), pages ??-??,
October 25-29, WestIields ConIerence Center
(near Washington, DC). Lecture Notes in
Computer Science 4273 Springer 2009, ISBN
978-3-642-04929-3.
|16| Lecue F ., a nd Le ger A., (2006), A
Iormal model Io r semantic Web service
composition`, in IS WC 2 006, pp. 3 85
398
|17| Lecue F ., De lteil A., and Leger A. .
Optimizing c ausal li nk b ased Web service
composition. In ECAI, pages 4549, 2008.
|18| Lecue F., Mehandjiev N.: Towards
Scalability oI Q uality Driv en Semantic Web
Service Composition. ICWS 2009: 469-476
|19| Li L., Horrocks I., A soItware Iramework Ior
matchmaking based on semantic Web
technology. In WWW, pages 331339, 2003.
|20| Marconi A ., Pistore M. : Sy nthesis a nd
Composition oI Web Services. SFM 2009: 89-
157
|21| Mernik M., H eering J., and Sloane A. M .,
When and how to dev elop do main-speciIic
languages, ACM Computing Survies, vol. 37 ,
no. 4, pp. 316344, 2005
|22| Motta E., (1999 ) Reusable Components For
Knowledge Modelling Case Studies In
Parametric Design Problem Solving,IOS Press
(Netherlands)
|23| Nitzsche, J., Norton, B.: Ontology-based data
mediation in BPEL. In: BPM Workshops.
(2008) 523534
|24| Paolucci M., Kawamura T., P ayne T.R., and
Sycara K., (2002) Semantic matching oI Web
services capabilities. In ISWC, pages 333347
|25| Christos H. Papadi mtriou an d Kenneth
Steiglitz. Com binatorial Optim ization:
Algorithms and Com plexity. Prentice-Hall,
1982.
|26| Sirin E. , H endler J ., P arsia B., S emi-
automatic composition oI Web services using
semantic d escriptions, in : W eb Servic es:
Modeling, Architecture and InIrastructure
workshop in conjunction with ICEIS2003,
2002
|27| van der Aal st W.M .P., Hi rnschall A.,
and Verbeek H.M.W.. An alternative way
to analyze workIlow graphs. In Proc. 14th
Int. C onI. o n A dvanced InI ormation
Systems Engi neering, pa ges 53 4552,
2002.
|28| Vitvar T., Kopecky J., Viskova J., Fensel D.
(2008) WSMO-Lite Annotatio ns Ior Web
Services. ESWC 2008: 674-689.
|29| Wielinga B. J ., Akkermans J. M., Schreiber
A. Th., A Formal Analy sis oI Parametric
Design P roblem S olving, In P roceedings oI
the 9 th BanI I Knowledge Acquisition
Workshop (KAW-95)
|30| Yu, T., Lin, K .-J.: S ervice s election
algorithms Ior composing complex services
with m ultiple qos constraints. In: ICSOC
2005. LNCS, vol. 3826, pp. 130143.
|31| Zeng L., Benatallah B. , Anne H. H. Ngu,
Dumas M., Kalagnanam J., an d Chang H..
Qos-aware m iddleware Ior web s ervices
composition. I EEE Tr ans. S oItware Eng .,
30(5):311327, 2004.

Model-Driven Aspect-Oriented Quality of Service for Web
Services
Guadalupe Ortiz
Quercus SoItware Engineering Group
University oI Estremadura
1
, Spain
gobellotunex.es
Behzad Bordbar
School oI Computer Science
University oI Birmingham, U. K.
B.Bordbarcs.bham.ac.uk

Abstract
2

Implementing and maintaining non-Iunctional
properties related to the monitoring oI Quality oI
Service (QoS) can be expensive and complex task.
In this paper, we present a model-driven approach
Ior the implementation oI QoS monitors. Besides,
QoS constraints are implemented Iollowing the
Aspect-Oriented Programming paradigm; aspects
are weaved into the system implementation.
1. Introduction
Ensuring Quality oI Service (QoS) in distributed
systems is generally considered as a challenging
task |5|. Besides, in the case oI Web services, it is
crucial to maintain the loosely coupling oI the
system whilst integrating QoS components in a
Ilexible way, to avoid diIIiculties related to
maintenance and evolution |2|.
In this regard, we deal with the complexity oI
designing QoS-aware Web services. For this
purpose, existing model-driven development
techniques Ior the implementation oI Web
services |1, 4| are extended to deal with QoS.
Firstly, QoS characteristics oI the system are
modeled in a platIorm-independent way. Then, the
presented approach makes use oI two model
transIormations: Iirstly transIormations to models
describing the main system Iunctionality and
secondly those speciIying QoS, which are
transIormed in order to produce QoS monitors.
This results in the creation oI platIorm-speciIic
models Ior both system and QoS elements and
subsequently two sets oI implementations: the
speciIic system implementation and the QoS
monitor code. In this regard, the paper extends the
method developed by the Iirst author |3, 4| to deal
with the implementation oI QoS characteristics in
Web services. Our method results in the QoS code
being created as aspects, which will be weaved
into the main system Iunctionality by using
Aspect-Oriented Programming techniques.
Acknowledgements
The Iirst author acknowledges the support Irom
Ministerio de Ciencia e Innovacion (TIN2008-
02985) and Irom Fondo Europeo de Desarrollo
Regional (FEDER).
Referencias
|1| Bordbar, B. and Staikopoulos, A. On
Behavioural Model TransIormation in Web
Services Conceptual Modelling Ior Advanced
Application Domain, Proc. eCOMO, 2004.
|2| Cauldwell, P., Chawla, R., Chopra, V.,
Damschen, G., Dix, et al.: XML Web
Services. Wrox Press, 2001.
|3| Ortiz G. Integrating Extra-Functional
Properties in Model-Driven Web Service
Development. PhD Thesis, University oI
Extremadura, April 2007.
|4| Ortiz, G. Hernandez, J. Service-Oriented
Model-Driven Development: Filling the
Extra-Functional Property Gap. I. C. on
Service Oriented Computing, 2006.
|5| Putman, J. R. Architecting with RM-ODP,
Prentice Hall, 2001.

Tabla 3.
1
Currently affiliated to University of Cdiz.
2
This extended abstract summarizes the paper entitled
Aspect-Oriented Quality of Service for Web Services: a
Model-Driven Approach published at the International
Conference on Web Services 2009 and can be found at
http://www.computer.org/portal/web/csdl/doi/10.1109/I
CWS.2009.20.

Demostraciones

Herramienta de Administracin Avanzada de la Plataforma de
la Interoperabilidad de la Junta de Andaluca (PLATINA)

Manuel Toscano Ferrera
Consejeria de Economa , Innovacion y Ciencia
Junta de Andalucia
manuel.toscano.ferrera@juntadeandalucia.es
Juan Sebastian Ojeda Prez
Consejeria de Economa , Innovacion y Ciencia
Junta de Andalucia
manuel.toscano.ferrera@juntadeandalucia.es

Resumen

La herramienta ADAEMO nace con el objetivo de
cubrir las necesidades que la plataforma platina
requiere de ADministracin, Auditora,
Estadsticas y MOnitorizacin.

Esta herramienta proporciona a un usuario con un
perfil funcional la capacidad de gestionar los
servicios que proporciona la organizacin local o
externamente a PLATINA, adems de poder
organizar los servicios consumidores.

En esta herramienta se gestiona la informacin de
los servicios desde un punto de vista de
Administracin y Operacin y se complementa
con el mdulo del catalogo que gestiona la
informacin de los servicios desde un punto de
vista de divulgacin y descubrimiento para
desarrolladores.

Es una herramienta avanzada ya que permite que
los desarrolladores/integradores puedan definir
una serie de metadatos a travs de los cuales
exista trazabilidad a nivel funcional de los
mensajes que circulan a travs de la plataforma.

Por otro lado permite la configuracin de los
posibles errores de los servicios integrados y en
base a los mismos puede gestionar alertas que
permitan la notificacin de las mismas cuando se
produzca un error.

Finalmente dispone de un mdulo de
monitorizacin que permite analizar los mensajes
que circulan a travs de la plataforma adems de
un mdulo de informes que permite extraer
estadsticas de forma flexible sobre la
configuracin de sus componentes y el gobierno
de la plataforma.

[100..1000] [1..5]
= /
19
[( = 20) ( [100..1000])
( [1..5]) ( = / )]

th
th
iServe: a Linked Services Publishing Platform

Carlos Pedrinaci Dong Liu Maria Maleshkova
David Lambert Jacek Kopeck John Domingue
Knowledge Media Institute, The Open University
Walton Hall, Milton Keynes, MK7 6AA, UK
c.pedrinaci@open.ac.uk
Abstract
Despite the potential of service-orientation
and the eorts devoted so far, we are still to
witness a signicant uptake of service tech-
nologies outside of enterprise environments. A
core reason for this limited uptake is the lack
of appropriate publishing platforms able to
deal with the existing heterogeneity in the ser-
vice technologies landscape and able to provide
expressive yet simple and ecient discovery
mechanisms. We will present iServe, a novel
and open platform for publishing semantic an-
notations of services better supporting their
discovery and use. iServe is based on a direct
application of linked data principles to pub-
lish service annotations expressed in terms of
a simple vocabulary for describing services of
dierent kinds (e.g., WSDL and Web APIs)
with annotations in diverse formalisms (e.g.,
OWL-S, WSMO-Lite). More concretely, iServe
is driven by the following conclusions drawn
from previous research on service repositories
and the progress made by the Web of Data:
Semantics are essential to reach a mini-
mum level of automation during the life-
cycle of services;
The annotation of services should be sim-
plied in as much as possible;
This extended abstract summarizes the pa-

per entitled iServe: a Linked Services Publishing
Platform published at the International Workshop
ORES10 - Ontology Repositories and Editors
for the Semantic Web, which can be found at
http://kmi.open.ac.uk/people/carlos/publications/iserve-
ORES2010.pdf
On the Web, lightweight ontologies to-
gether with the possibility to provide cus-
tom extensions prevail against more com-
plex models;
Any solution to deploying services that
aspires to be widely adopted should build
upon the various approaches and stan-
dards used on the Web, including Web
APIs, RDF, and SPARQL;
Linked data principles are an appropriate
means for publishing large amounts of se-
mantic data, both for human and machine
consumption;
Links between publicly available datasets
are essential for the scalability and the
value of the data exposed.
1 Introduction
Web services are software systems oered over
the Internet via platform and programming-
language independent interfaces dened on the
basis of a set of open standards such as WSDL,
SOAP, and further WS-* specications [1].
The fundamental advantage of Web service
technology lies in the support it brings to de-
veloping highly complex distributed systems
that maximise reuse of loosely coupled compo-
nents. A key constituent of Service-Oriented
Architectures is the service repository, which
enables programmatic recording of service de-
scriptions and their subsequent use in the dis-
covery of suitable services. Service publication
has therefore been at the core of research and
development in this area since the very begin-
ning. However, despite substantial eorts, Web
services are not published on the Web in sig-
nicant numbers, and in practice, lighter and
less structured approaches such as Web APIs
are currently preferred [2].
One of the main reasons for the paucity
of service repositories to date has been the
fact that, although they are relatively complex,
they do not support expressive queries, limit-
ing their usefulness [3]. Semantic Web Services
(SWS) [4] research has devoted considerable
eorts to overcoming Web services limitations
by enriching them with semantic annotations
to better support their discovery, composition
and execution. So far, the impact of SWS on
the Web has been minimal. In fact, although
SWS technologies have already demonstrated
benets, research in the area has glossed over
the additional eort demanded of users, and
the extra complexity they introduce to the al-
ready intricate services technology stack.
Before any signicant uptake of services can
take place on the Web, better mechanisms for
creating, publishing and discovering services
must be in place. In particular, service publi-
cation must be able to deal with service hetero-
geneity (e.g., dealing with both WSDL services
and Web APIs), it must be based on the use of
lightweight semantics able to support relatively
advanced yet ecient discovery, and it must
be combined with an appropriate set of tools
able to support users in the annotation and
publication of services.
iServe is dened as a platform for the seam-
less publication and discovery of services de-
veloped in the context of the EU project
SOA4All. iServe addresses the publication
of services from a novel perspective based on
lessons learned from the evolution of the Web
of Data [5]. iServe transforms service anno-
tations expressed in a variety of formats into
what we refer to as Linked Serviceslinked
data describing servicesthat can directly be
interpreted by state of the art Semantic Web
technologies for their discovery and further pro-
cessing. The iServe platform is complemented
with editors that assist users in creating and
publishing service annotations using existing
semantic search engines like Watson [6] for
searching the Web for reusable ontologies. The
decisions adopted for iServe include a number
of principles that are of particular relevance for
the development of other kinds of repositories
for the Web, since they highlight the impor-
tance that ontology repositories or systems like
Watson may have when it comes to creating
Semantic Web applications.
Acknowledgements This work was partly
funded by the EU project SOA4All (FP7-
215219). We thank all the members of the
SOA4All project and the Conceptual Models
for Services Working Group of STI Interna-
tional. We also thank Pierre Grenon for his
insightful comments and Alex Simov for the
development of SOWER.
References
[1] Erl, T.: SOA Principles of Service Design.
The Prentice Hall Service-Oriented Com-
puting Series. Prentice Hall (July 2007)
[2] Davies, J., Domingue, J., Pedrinaci, C.,
Fensel, D., Gonzalez-Cabero, R., Potter,
M., Richardson, M., Stincic, S.: Towards
the open service web. BT Technology Jour-
nal 26(2) (2009)
[3] Pilioura, T., Tsalgatidou, A.: Unied pub-
lication and discovery of semantic web ser-
vices. ACM Trans. Web 3(3) (2009) 144
[4] McIlraith, S., Son, T., Zeng, H.: Seman-
tic web services. IEEE Intelligent Systems
16(2) (March 2001) 4653
[5] Bizer, C., Heath, T., Berners-Lee, T.:
Linked data - the story so far. International
Journal on Semantic Web and Information
Systems (IJSWIS) (2009)
[6] dAquin, M., Motta, E., Sabou, M., An-
geletou, S., Gridinoc, L., Lopez, V., Guidi,
D.: Toward a new generation of semantic
web applications. IEEE Intelligent Systems
23(3) (2008) 2028
NDICE DE AUTORES

ActasJSWEB2010 Rev

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ActasJSWEB2010 Rev

Uploaded by

Copyright:

Available Formats

Actas de las

VI Jornadas Cientfico-Tcnicas en Servicios Web y

90 VI Jornadas Cientfico-Tcnicas en Servicios Web y SOA

VI Jornadas Cientfico-Tcnicas en Servicios Web y SOA 93

94 VI Jornadas Cientfico-Tcnicas en Servicios Web y SOA

VI Jornadas Cientfico-Tcnicas en Servicios Web y SOA 95

96 VI Jornadas Cientfico-Tcnicas en Servicios Web y SOA

134 VI Jornadas Cientfico-Tcnicas en Servicios Web y SOA

136 VI Jornadas Cientfico-Tcnicas en Servicios Web y SOA

This extended abstract summarizes the pa-

You might also like