SOA

Arquitecturas orientadas a servicios

Antoni Oller Arcas

PID_00187408
CC-BY-SA • PID_00187408 SOA

Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia de
Reconocimiento-Compartir igual (BY-SA) v.3.0 España de Creative Commons. Se puede modificar la obra, reproducirla, distribuirla
o comunicarla públicamente siempre que se cite el autor y la fuente (FUOC. Fundació per a la Universitat Oberta de Catalunya), y
siempre que la obra derivada quede sujeta a la misma licencia que el material original. La licencia completa se puede consultar en:
http://creativecommons.org/licenses/by-sa/3.0/es/legalcode.ca
CC-BY-SA • PID_00187408 SOA

Índice

Introducción............................................................................................... 5

Objetivos....................................................................................................... 6

1. Introducción a las arquitecturas orientadas a servicios......... 7

1.1. Evolución histórica de los servicios en Internet ......................... 7
1.2. Web 2.0 ....................................................................................... 7
1.3. Web semántica ............................................................................ 9

2. El concepto SOA: arquitecturas orientadas a servicios............ 11

2.1. Metodología SOA ........................................................................ 12
2.2. Implementación de servicios SOA .............................................. 13
2.2.1. Invocación a procedimientos remotos .......................... 13
2.3. Ejemplo de SOA .......................................................................... 14

3. Servicios web....................................................................................... 15
3.1. Servicios web basados en SOAP (WS-*) ....................................... 15
3.1.1. Arquitectura de los servicios .......................................... 16
3.1.2. Composición de servicios .............................................. 17
3.2. Servicios web basados en REST ................................................... 22
3.2.1. El concepto recurso.......................................................... 23
3.2.2. Formatos para representar los recursos ......................... 24
3.3. Diferencias entre servicios web basados en REST y en SOAP
(WS-*) .......................................................................................... 25

4. Diseño de aplicaciones orientadas a servicios con UML........... 27

4.1. Perfil UML para aplicaciones orientadas a servicios ................... 27
4.2. Ejemplo ........................................................................................ 29

Resumen....................................................................................................... 34

Actividades.................................................................................................. 35

Ejercicios de autoevaluación.................................................................. 35

Solucionario................................................................................................ 36

Glosario........................................................................................................ 37

Bibliografía................................................................................................. 38
CC-BY-SA • PID_00187408 5 SOA

Introducción

Todos los módulos explicados previamente se han basado en especificar y rea-

lizar una descripción arquitectónica de sistemas distribuidos abiertos median-
te puntos de vista independientes, con un nivel de abstracción respecto a la
tecnología en que se implementarán. Sucesivos módulos presentaban diversas
tecnologías para la construcción de sistemas distribuidos.

En el módulo "Java RMI" se describía el concepto de invocación a procedimien-

tos remotos y se explicaban las características y funcionamiento de RMI (del
inglés remote method invocation). En el módulo "Java EE" se proponía una es-
trategia para la construcción de sistemas distribuidos empresariales basada en
la plataforma Java EE (del inglés Java enterprise edition). Esta plataforma ofrece
una completa serie de especificaciones para la construcción de aplicaciones,
que habitualmente se ofrecen al usuario con una interfaz (Web). Este tipo de
aplicaciones se denominan B2C (del inglés business-to-consumer), ya que se tra-
ta de sistemas que relacionan la empresa (y su negocio, por medio de sus ser-
vicios) directamente con los clientes (usuarios). Existe otro tipo de sistemas,
denominados B2B (del inglés business-to-business), que establecen relación de
empresa a empresa. Este tipo de sistemas (B2B) están basados en servicios a
los que acceden terceras partes (y son reutilizados por estas) y se suelen im-
plementar siguiendo una SOA (arquitectura�orientada�a�servicios, del inglés
service oriented architecture).

Por otra parte, aparece la necesidad de construir aplicaciones más complejas,

basadas en la�composición�de�servicios (ya existentes). Las aplicaciones se
construyen mediante la orquestación�o�la�coreografía�de�servicios que son
ofrecidos por terceras partes. Este modelo favorece la reutilización de los ser-
vicios y aumenta la productividad en la construcción de las aplicaciones.

Este módulo tratará de explicar todos estos conceptos y presentará estrategias

tecnológicas basadas en servicios�web (ligeros y pesados) para construir apli-
caciones que siguen un paradigma de arquitectura orientada a servicios.

Por último, se mostrará una posible manera de realizar un diseño de aplicacio-

nes orientadas a servicios con UML, con un ejemplo de perfil UML para servi-
cios web, y se darán algunas recomendaciones para pasar de la especificación
a la implementación del sistema.
CC-BY-SA • PID_00187408 6 SOA

Objetivos

El objetivo básico del módulo es presentar varias técnicas para la implementa-

ción de aplicaciones�orientadas�a�servicios. Los objetivos más concretos son:

1. Analizar la evolución histórica de Internet y entender cómo se han trans-

formado los paradigmas de computación.

2. Entender el concepto SOA (arquitectura orientada a servicios).

3. Conocer los conceptos de servicio y servicios web.

4. Conocer los conceptos de recurso y arquitectura orientada a recursos.

5. Estudiar las diversas estrategias de implementación de servicios web: ser-

vicios web pesados y servicios web ligeros.

6. Conocer las técnicas de composición de servicios: orquestación y coreo-

grafía.

7. Ver una posible forma de diseñar una aplicación orientada a servicios, a

partir de la especificación independiente de la tecnología obtenida (tal
como se ha explicado en módulos previos).
CC-BY-SA • PID_00187408 7 SOA

1. Introducción a las arquitecturas orientadas a

servicios

En este apartado, se hará una descripción del concepto de arquitectura orien-

tada a servicios y las claves para el desarrollo de servicios que utilicen este es-
tilo arquitectónico. En primer lugar, se describe la evolución histórica de los
servicios sobre Internet; posteriormente, se describe el concepto SOA y algu-
nos elementos que pueden participar en la arquitectura orientada a servicios,
las tecnologías de servicios web, la orquestación y la coreografía.

1.1. Evolución histórica de los servicios en Internet

El origen de Internet se remonta a los años sesenta en un proyecto de inves- ArpaNet

tigación en comunicación de redes en un área militar. Esta investigación pro-
Además del equipamiento, Ar-
dujo una red experimental de cuatro nodos (ArpaNet), que transmitió infor- paNet fue ofreciendo servicios,
mación fiable a través de una red en condiciones hostiles como fallos y caídas como el correo (1972), el pro-
tocolo TCP/IP (1974) y otros
de nodos. Aparece un nuevo paradigma de computación; hasta entonces los como FTP, grupos de noticias
(news) y la World Wide Web
sistemas se diseñaban e implementaban de manera totalmente centralizada, (WWW), que ha sido el servicio
que, finalmente, ha populari-
y con la aparición de la red se permite descentralizar o distribuir las aplicacio- zado Internet.
nes en un esquema cliente-servidor.

El auge de la Web marca la consolidación de Internet sobre todo por su evolu- HTTP

ción. En la Web�1.0, las aplicaciones están limitadas a un servidor que ofrece HTTP es un protocolo de apli-
unos servicios y contenidos, y a un usuario con un rol pasivo de consumidor cación basado en un paradig-
ma de petición-respuesta. Ha-
de servicios. En cambio, en la Web�2.0, los usuarios actúan como generado- bitualmente, funciona sobre
el puerto 80 y suele tener faci-
res de contenidos utilizando aplicaciones dinámicas y se convierten en parti- lidad para atravesar entornos
hostiles (cortafuegos, NAT).
cipantes activos. La consolidación de protocolos como HTTP facilita la crea-
ción de aplicaciones y servicios sobre la Web. En un principio, estos servicios
se construyen sin unas especificaciones estándares que definan las interfaces,
reglas de codificación de parámetros y resultados, o el mecanismo de invoca-
ción. Posteriormente, se crearán especificaciones y nuevas propuestas de esti-
los arquitectónicos para evolucionar la construcción de servicios sobre la Web.

En este contexto, los servicios evolucionan hacia una arquitectura orientada a

servicios (SOA) y las aplicaciones son construidas como una nube de servicios
cooperados, en la que existen interfaces y se dan facilidades para reutilizar los
servicios que ofrecen terceras partes.

1.2. Web 2.0

(1)
Uno de los pasos más importantes en la evolución de la Web se da en el mo- Del inglés rich Internet applica-
tions.
mento en que se permite a los usuarios participar activamente en Internet (de-
mocratización�de�la�Web), y una de las maneras de un rol más activo es mejo-
rando la experiencia del usuario. Para mejorar dicha experiencia, en la Web 2.0
CC-BY-SA • PID_00187408 8 SOA

se utilizan aplicaciones RIA1, que permiten la creación de nuevas aplicaciones

y un modelo que pretende llevar las aplicaciones de escritorio a la Web. Hoy
en día, existen aplicaciones implementadas que integran componentes Adobe
Flash en lugar de una página web y que interactúan con los componentes de
servidor cuando sea necesario. En una misma línea, HTML5 establece nuevos
elementos y atributos que reflejan el típico uso moderno de los sitios web.

Sin embargo, la Web 2.0 no solo es un cambio de paradigma de uso de la HTML5

Web, también aparecen aportaciones tecnológicas significativas como el uso
Es la quinta revisión del len-
de�etiquetas�semánticas (utilizando XML). La extensibilidad de XML permi- guaje HTML. Proporciona nue-
te entender un documento creado por terceras partes y procesarlo. Aparecen vos elementos (canvas, audio,
video, device) para el lenguaje
abundantes especificaciones web 2.0 basadas en XML, como RSS, Atom, SOAP, HTML5 y nuevas funcionalida-
des: WebGL, sockets web (web
XHTML, HTML5. sockets), geolocalización, arras-
trar y soltar (drag&drop)...

Existe otra tecnología denominada AJAX2, que consiste en que el cliente realiza
(2)
peticiones y el servidor retorna documentos XML de manera asíncrona. En Del inglés asynchronous JavaS-
cript and XML.
el cliente, una pieza adicional (AJAX Engine) procesa la información de los
documentos XML y crea o complementa un archivo HTML. Este motor (AJAX
Ved también
Engine) determina si la petición es necesaria para cada acción del usuario. En
ocasiones este comportamiento, basado en XML, puede ser sustituido por unas En el apartado "Servicios web
basados en REST" de este mó-
estructuras basadas en JavaScript denominadas JSON. dulo veréis con más detalle el
mecanismo de codificación de
datos JSON.
Los nuevos navegadores como IExplorer, Firefox, Safari, Opera o Google Chro-
me (entre otros) incorporan estas tecnologías que no solo procesan HTML,
sino que también reproducen contenido audiovisual, como vídeos, archivos
Flash, AVI/DIVX. Todavía hay muchas funcionalidades que no son implemen-
tadas en los diferentes navegadores, lo que provoca incompatibilidades entre
estos, fruto del diseño específico de cada navegador para solucionar tales in-
compatibilidades. Estos problemas de compatibilidad entre navegadores difi-
cultan la introducción de las tecnologías web 2.0.

La participación�de�los�usuarios y la inteligencia�colectiva son conceptos

web 2.0 que proporcionan aplicaciones diferentes y revolucionarias en térmi-
nos de diseminación de la información. Un ejemplo de esto es la aparición de
los wikis (el 1995), que permiten nuevas entradas de información que pueden
ser añadidas por cualquier usuario y corregidas o modificadas por otros. En
otras aplicaciones, como los blogs (1993) y la sindicación, que están basados
en usuarios, o aplicaciones generadoras de contenidos (texto plano, imágenes
o archivos multimedia), cualquier usuario puede suscribirse a estos canales
(feed) actuando como seguidores (follower). RSS/Atom es un formato/estándar
que define la gestión de la suscripción de los seguidores para distribuir la in-
formación actualizada. Esta revolución afecta a las noticias en el mundo, y
abre un camino fácil y directo de diseminación de noticias. Además, el podcast
se une a este tipo de aplicaciones incluyendo contenido multimedia.
CC-BY-SA • PID_00187408 9 SOA

En el 2005 aparece otra forma de blogs: los microblogs. El contenido de los Twitter
microblogs es de pequeño tamaño y consiste en frases cortas (en Twitter, de
Una de las funcionalidades
ciento cuarenta caracteres), una imagen o un vídeo. Los microblogs tienen más interesantes de Twitter es
el potencial de convertirse en un medio informal de comunicación, especial- el análisis de las palabras más
populares o emergentes (tren-
mente para el trabajo cooperativo dentro de las organizaciones usado para el ding topic) en la red social de
microblogs, y además puede
marketing y las relaciones sociales (red social). El nuevo movimiento de las estructurar el contenido se-
mánticamente por medio de
redes sociales aparece permitiendo a los usuarios que estén conectados entre etiquetas (hashtags).
ellos y puedan compartir, en grupos, los contenidos que deseen, sus vidas y
sentimientos (mensajes, imágenes, vídeos). Estos efectos han sido magnifica-
dos en un contexto web 2.0, ya que las interconexiones entre usuarios se han
multiplicado en una línea en la que las individualidades se convierten en gru-
pos y sociedades de forma fácil y rápida.

Otras aplicaciones web 2.0 son:

(3)
• Las remezclas (mashup3), aplicaciones que permiten crear contenido me- La traducción literal de mashup
puede ser 'papilla'. Algunos ejem-
diante la combinación de contenidos de terceras partes. plos son: Amazon, eBay, Flickr,
Yahoo, YouTube, Google Maps...

• CMS4, aplicaciones que permiten crear y gestionar contenidos y su flujo (4)

Del inglés content management
de trabajo (workflow). system.

1.3. Web semántica

Las nuevas aplicaciones y el incremento y la participación de los usuarios han

aumentado la complejidad y los requerimientos de la Red. Actualmente, se
genera un gran volumen de información y aparecen nuevas necesidades que
hay que cubrir, como nuevos sistemas de clasificación y busca inteligente de
contenidos que tengan en cuenta nuevos parámetros: sensibilidad del contex-
to, localización, nomadismo, capacidades de los dispositivos, ubicuidad, mo-
vilidad, etc.

Una de las iniciativas consiste en tener sistemas de clasificación basados en

folksonomías, es decir, en la creación y la gestión colaborativa de palabras
clave o etiquetas para categorizar o identificar contenido. Las etiquetas (tags)
son palabras clave o términos asignados a piezas de información por parte de
un usuario o un autor. La definición etimológica del término describe este con-
cepto como "clasificación gestionada por la gente". Por este motivo, las folkso-
nomías habitualmente están vinculadas a entornos sociales, donde los usua-
rios colaboran en la descripción de una misma pieza de información. Existen
dos tipos de folksonomías: las primeras, en las que el creador del contenido
no tiene ninguna influencia sobre las etiquetas asociadas al contenido. En este
caso, los usuarios son los únicos que etiquetan el contenido. En el segundo
tipo de folksonomías, solo el creador del contenido o un pequeño grupo de
personas está habilitado para etiquetar el contenido.
CC-BY-SA • PID_00187408 10 SOA

Sin embargo, la falta de un control sobre la terminología provoca problemas:

por ejemplo, diferentes etiquetas (sinónimos) con el mismo significado, la mis-
ma etiqueta con significados diferentes (homónimos) o la misma etiqueta con
diferentes significados relacionados entre sí (polisemia). La idea de añadir me-
tainformación a la World Wide Web nos conduce, mediante el uso de lengua-
jes de descripción semántica, a la Web semántica y al nuevo concepto de fu-
tura Web.

(5)
Con este propósito, W3C5 ha fomentado el desarrollo de OWL6, que consiste Sigla del World Wide Web Con-
sortium.
en una familia de lenguajes de representación del conocimiento para la crea-
ción de ontologías. El concepto de ontología corresponde a una representa- (6)
Del inglés ontology web langua-
ción formal del conocimiento como un conjunto de conceptos dentro de un ge.
dominio. Las ontologías proporcionan un vocabulario compartido que puede
describir un dominio y las interrelaciones dentro de él.
CC-BY-SA • PID_00187408 11 SOA

2. El concepto SOA: arquitecturas orientadas a

servicios

(7)
La arquitectura orientada a servicios (SOA7) es un concepto de arquitectura Del inglés service-oriented archi-
tecture.
de software que describe el uso de servicios para proporcionar soluciones a
requerimientos de negocio.

Se define SOA como un paradigma para la organización y la utilización

de capacidades distribuidas que puede estar ofrecido sobre diferentes
dominios. Proporciona una manera normalizada de descubrir, ofrecer e
interactuar con un servicio para obtener los efectos deseados y definidos
por sus precondiciones/poscondiciones.

SOA crea una arquitectura flexible y habilita la implementación de comple-

jas arquitecturas que reflejen la organización. Además, proporciona un mapa
bien definido para la invocación de servicios que habilita la interacción entre
diferentes sistemas (por ejemplo, sistemas propietarios) y servicios externos
(third party services).

Los beneficios del uso del paradigma de la arquitectura orientada a servicios

son los siguientes:

• Mejora del tiempo para realizar cambios en procesos. Subcontratación

(outsourcing)

• Capacidad para desarrollar lógicas de negocio basadas en la subcontrata- La subcontratación es una téc-
ción (outsourcing). nica que utilizan las empresas
y que se basa en la externaliza-
ción de ciertas tareas a empre-
sas especializadas para reducir
• Capacidad para dirigir modelos de negocio con otras entidades (socios, costes.
proveedores).

• Capacidad para reemplazar elementos de una capa de una aplicación SOA

sin provocar trastornos en los procesos de negocio.

• Simplicidad para integrar tecnologías diversas.

Cuando se diseña un sistema distribuido siguiendo un paradigma SOA, se de-

be tener en cuenta la metodología de diseño basada en SOA y los diferentes
perfiles tecnológicos disponibles.
CC-BY-SA • PID_00187408 12 SOA

2.1. Metodología SOA

SOA proporciona una metodología y un marco de trabajo (framework) para

describir las lógicas de negocio y proporciona la integración y la consolidación
de las actividades. Se debe tener en cuenta que:

• Las aplicaciones son básicas y están basadas en sistemas implementados

bajo cualquier arquitectura o tecnología, ubicados geográficamente dis-
persos y en diferentes dominios (y propietarios).

• Las capacidades son expuestas como servicios, por lo general servicios web,
pero no exclusivamente.

• Se habilita el intercambio de información entre los elementos internos y

las lógicas de negocio colaborativas.

• Se definen los procesos en términos de lógicas de negocio y sus necesida-

des.

• Los servicios son desplegados para los usuarios finales en una determinada
ubicación (punto de entrada).

• El modelo está orientado a servicios como una función sin estado, que
acepta invocaciones y devuelve respuestas a través de una interfaz conoci-
da. Los servicios no dependen del estado de sus funciones y procesos, y la
tecnología específica usada para proporcionar el servicio no es una parte
de su definición. Se permite el uso de servicios asíncronos.

• Un servicio sin estado no depende de una condición preexistente. En la

SOA, un servicio no es dependiente de ningún otro. Los servicios obtienen
la información que necesitan para responder a la petición. Los servicios sin
estado pueden ser secuenciados en un esquema basado en bus o tuberías
(pipeline), u orquestados, para ofrecer una lógica de negocio compleja.

• Los proveedores son los responsables de proporcionar un servicio en res-

puesta a una petición de un cliente.

• El cliente es un componente responsable de consumir el resultado de un

servicio proporcionado por un proveedor.

• La orquestación coordina, organiza, arbitra servicios y proporciona lógicas

adicionales para procesar información, sin incluir información de presen-
tación. La metodología de modelado de SOA se denomina análisis y dise-
ño orientado a servicios. La arquitectura orientada a servicios es al mismo
tiempo un framework para el desarrollo de software y un framework para la
fase de implementación.
CC-BY-SA • PID_00187408 13 SOA

2.2. Implementación de servicios SOA

Cuando describimos la arquitectura orientada a servicios, por lo general nos

referimos a un conjunto de servicios que se despliegan sobre Internet o intra-
net utilizando servicios web.

Existen diferentes estándares asociados a los servicios web como XML, HTTP,
SOAP, WSDL, UDDI o REST, XML y JSON, aunque SOA no se limita solo a estas
especificaciones. Se puede diseñar un sistema que siga un paradigma orienta-
do a servicios y aplicar un perfil tecnológico diferente del habitual uso de es-
tándares.

Protocolos asociados a
En un entorno SOA, los nodos de una red publican sus recursos dis- servicios web
ponibles a otros participantes como servicios independientes que son
Existen multitud de protocolos
accesibles de una manera estandarizada. Muchas definiciones de SOA asociados a los servicios�web
basados en SOAP: WS-addres-
identifican SOA con el uso de servicios web basados en SOAP (WS-*) y sing, WS-notification, WS-even-
WSDL en su implementación, pero es posible implementar SOA usando ting, WS-policy, WS-discovery,
etc. Se abreviará mediante el
cualquier�tecnología basada en servicios. término WS-* cuando se haga
referencia a todos estos proto-
colos.

Hay varios estilos para implementar servicios, y en estos materiales se pre-

sentarán dos familias de servicios web: los servicios web basados�en�SOAP�y Ved también
WSDL�(WS-*) y los servicios web basados�en�recursos (RESTful web services).
En el apartado siguiente vere-
mos estas dos familias de servi-
cios web con detalle.
2.2.1. Invocación a procedimientos remotos

(8)
El mecanismo de comunicación básico en una arquitectura orientada a servi- Del inglés remote procedure call.
8
cios es la invocación�a�procedimientos�remotos�(RPC). RPC es un paradig-
ma para implementar un modelo cliente-servidor para computación distribui- Ved también

da. Una llamada RPC es iniciada por un cliente que envía un mensaje de pe- En el módulo "Introducción a
tición a un servidor conocido con la intención de ejecutar un procedimiento las plataformas distribuidas"
hemos estudiado la invocación
especificado con unos parámetros. El desarrollador de aplicaciones distribui- de procedimientos remotos
RPC.
das basadas en RPC solo debe implementar un cliente sencillo que realiza una
invocación a un procedimiento como si estuviera en local y el servidor lleva a
cabo la implementación del procedimiento en cuestión. El mecanismo de RPC
se responsabilizará de construir la invocación (llamada y parámetros), gestión
de la capa de red (tanto en cliente como en servidor), invocación del procedi-
miento en cuestión y construcción de la respuesta.
CC-BY-SA • PID_00187408 14 SOA

(9)
Este modelo de RPC se propone en la década de los setenta; más adelante, el Del inglés common object request
broker architecture.
grupo de trabajo Object Management Group propone otro mecanismo basado
en CORBA9. RMI es un mecanismo ofrecido por el lenguaje de programación
CORBA
Java y, con el auge de Internet, aparecen varias evoluciones de este paradigma,
como XML-RPC y los servicios�web. El Object Management Group
propuso CORBA en los años
noventa, basado en el paradig-
ma de RPC, que funciona so-
2.3. Ejemplo de SOA bre objetos distribuidos, con
las características propias de
la orientación a objetos como
Un ejemplo de aplicación orientada a servicios podría ser una aplicación B2B encapsulación, polimorfismo y
herencia.
de una gran empresa de la automoción (fabricante de vehículos) que ofrece
sus productos con la información y las posibilidades de personalización de
cada uno. Ved también

Consultad el módulo "Intro-

Por otro lado, un concesionario multimarca, que puede vender vehículos de ducción a las plataformas dis-
tribuidas" para tener más infor-
diferentes fabricantes o marcas, puede disponer de una aplicación web que mación de RMI y CORBA.
muestre a sus clientes (B2C), con la identidad corporativa del concesionario,
la información de los vehículos (de las diferentes marcas) con las opciones de
personalización. La aplicación del concesionario accederá a los servicios que
ofrece la aplicación B2B del fabricante (u otros fabricantes) para obtener la in-
formación de los vehículos, que posteriormente será presentada a los usuarios
con el valor añadido que ofrecen los concesionarios. La figura 1 muestra este
escenario.

Figura 1. Caso de uso de SOA

CC-BY-SA • PID_00187408 15 SOA

3. Servicios web

En este apartado describiremos primero el concepto básico y la arquitectura de

un servicio web basado en SOAP y las técnicas de composición de servicios, así
como varias estrategias para implementar este tipo de servicios web. Después
presentaremos los servicios web basados en REST.

3.1. Servicios web basados en SOAP (WS-*)

Un servicio� web� basado� en� SOAP es un sistema software identificado por

una URI, cuyas interfaces públicas y enlaces se definen y describen usando
XML. La definición puede ser descubierta por otros sistemas software, y estos
sistemas suelen interactuar con el servicio web de la manera prescrita por la
definición, usando mensajes basados en XML por medio de protocolos están-
dar de Internet. En definitiva, un servicio web expone su funcionalidad a po-
sibles consumidores en una URI y proporciona mecanismos para invocar sus
operaciones de manera remota (a través de Internet). El servicio web se puede
implementar en cualquier�lenguaje y en cualquier�plataforma. Los servicios
web utilizan una serie de especificaciones como SOAP, WSDL y UDDI, que se
describirán a continuación.

(10)
Del inglés simple object access
SOAP 10
es un protocolo que permite la interacción con servicios web protocol.

basado en XML. La especificación de SOAP incluye una sintaxis para

definir los mensajes, reglas de codificación y convenciones para repre-
sentar los RPC.

Las especificaciones de servicios se pueden hacer utilizando WSDL.

(11)
Del inglés web services descrip-
11
WSDL describe dónde se localiza un servicio, qué operaciones propor- tion language.

ciona, el formato de los mensajes que deben ser intercambiados y cómo

se invoca el servicio, además de proporcionar información adicional.

La proliferación de los servicios web hace necesaria la existencia de directorios

públicos que se pueden utilizar para el registro y la busca de servicios.

(12)
Del inglés universal description,
UDDI 12
proporciona un mecanismo para que los proveedores de servi- discovery and integration.

cios puedan especificar sus servicios de una manera normalizada, y los

clientes puedan consultar información de dichos servicios.
CC-BY-SA • PID_00187408 16 SOA

Las entradas de los UDDI consisten en páginas blancas (dirección, informa-

ción de contacto, etc.), páginas amarillas (características basadas en ontologías
estándares) o páginas verdes (referencias a especificaciones de servicios).

Los servicios web WS-* utilizan SOAP para codificar los mensajes XML que se WS-I y OASIS
transportan. Los mensajes deben ser capaces de interpretarse de manera auto-
WS-I es una organización que
matizada, tal como se describen las operaciones en WSDL. No es obligatorio propone buenas prácticas en el
que WSDL esté vinculado a un extremo SOAP, pero sí que es un prerrequisito uso de servicios web.
OASIS es una organiza-
para automatizar la generación de las clases auxiliares (stubs o skeletons) que ción/consorcio que trabaja so-
bre estándares abiertos en di-
se utilizan en diferentes plataformas. Algunas organizaciones (como WS-I y ferentes ámbitos, informática
OASIS) incluyen SOAP y WSDL en las definiciones de sus servicios web. en la nube (cloud computing),
SOA, servicios web, etc.

3.1.1. Arquitectura de los servicios

El esquema de funcionamiento de los servicios web basados en SOAP requiere

varios elementos fundamentales, que constituyen el esquema normal de SOA.
La figura 2 muestra el ciclo de vida de un servicio web.

Figura 2. Ciclo de vida de un servicio web

El modelo de funcionamiento se basa en un proveedor�del�servicio�web, que

es quien lo diseña, desarrolla e implementa y lo hace disponible para usarlo,
ya sea dentro de la misma organización o para el público en general. Las ope-
raciones de publicación involucran el anuncio del servicio como tal, lo cual
corresponde a la ubicación del servicio en un servidor específico, y el uso de
un servicio de descripción (UDDI), para que los clientes puedan saber qué fun-
ciones tiene disponibles el servicio web y qué información debe pasarse a tales
funciones para utilizarlas.
CC-BY-SA • PID_00187408 17 SOA

Por otro lado, un consumidor�del�servicio es quien accede al servicio web pa- Herramientas CASE
ra utilizar los servicios que este presta. Cuando un consumidor desea acceder
Existen herramientas CASE que
a un servicio web, puede utilizar un servidor de descubrimiento que permita simplifican mediante conecto-
conocer la ubicación exacta del servicio, es decir, debe contar con un directo- res (plugins) el proceso de ge-
neración de clientes a servicios
rio donde tenga listas las referencias a los servicios disponibles. Esto se logra web indicando únicamente la
URL donde se sitúa la descrip-
gracias a directorios UDDI. Una vez el consumidor de servicio dispone de la ción del servicio (WSDL).
especificación del servicio (WSDL), ya puede realizar el proceso de invocación
mediante el uso del protocolo SOAP.

3.1.2. Composición de servicios

Las arquitecturas orientadas a servicios (SOA) están basadas en pequeñas enti-

dades (servicios) que se pueden coordinar para desarrollar entidades mayores
o servicios complejos, utilizando protocolos públicos y servicios existentes de
manera similar a las piezas de un puzzle.

La composición de servicios puede ser vista, tal como muestra la figura 3, como
un modelo basado en capas en dos ejes, uno vertical y otro horizontal.

Figura 3. Composición de servicios

Composición de servicios vertical

El eje de composición vertical dispone de un nivel de infraestructura, la capa

intermediaria o middleware (o enterprise service bus), y un nivel de aplicación.
CC-BY-SA • PID_00187408 18 SOA

El nivel�de�infraestructura lo conforman todos los componentes de red, de Virtualización

computación, de almacenamiento de datos que se despliegan sobre los siste-
La virtualización es un tér-
mas de red, los nodos y los dispositivos de los usuarios. Estos elementos per- mino que se refiere a la abs-
mitirán la configuración y el despliegue de recursos sobre redes y servicios tracción de los recursos, que
puede ser aplicado sobre re-
reales o virtuales. cursos (por ejemplo, los nodos
o equipos), aplicaciones y re-
des, y trata de ofrecer una me-
jor utilización de los recursos.
El nivel�intermediario (middleware) puede estar basado en bus y resuelve pro-
blemas de conectividad e interoperabilidad entre los posibles componentes
que lo conforman: servidores de aplicaciones, sistemas de gestión de datos,
motores de orquestación, etc. Permitirá que cualquier aplicación del nivel de
aplicación pueda ser utilizada de manera transparente sobre la capa de recur-
sos, lo cual facilita el desarrollo y elimina detalles de bajo nivel.

El nivel�de�aplicación configura una nube de componentes como interfaces

de usuario, flujos de trabajo complejos (workflow), basados en composición
y coordinación de servicios, servicios web y modelos de datos distribuidos.
Todos estos componentes pueden estar desarrollados bajo diferentes perfiles
tecnológicos y usan la capa intermediaria en una composición vertical.

Composición de servicios horizontal

En un nivel de composición horizontal se pueden construir aplicaciones a par- M2M

tir de una nube de servicios que cooperan entre sí, basándose en las interfaces
M2M corresponde a la expre-
y la posibilidad de reutilizar los servicios de terceras partes (third parties). La sión machine-to-machine y ha-
figura 4 muestra un esquema de composición de servicios centralizado basado ce referencia al intercambio de
información entre máquinas (y
en la orquestación dirigida por un director de orquesta. En la figura 5 se pre- sensores).

senta otro esquema de coordinación basada en la coreografía.

CC-BY-SA • PID_00187408 19 SOA

Figura 4. Orquestación

Para hacer posible la composición de servicios se dispone de protocolos de WS-BPEL y WS-

orquestación (WS-BPEL) y coreografía (WS-Choreography), que describimos a Choreography.

continuación. WS-BPEL y WS-Choreography

son protocolos de la familia
WS-*.
CC-BY-SA • PID_00187408 20 SOA

Figura 5. Coreografía/orquestación

La diferencia entre la orquestación y la coreografía se puede explicar mediante

analogías. La orquestación se refiere a un control central del comportamien-
to por un sistema distribuido: la orquesta con los músicos; la coreografía se
refiere a un sistema distribuido (los bailarines) que opera de acuerdo con unas
reglas, pero sin un control centralizado. De este modo, es importante destacar
que la orquestación se controla de una manera centralizada, mientras que la
coreografía se controla de manera distribuida.

La orquestación difiere de la coreografía en que describe un flujo de

procesos entre servicios, controlados por un director de orquesta (single
party). De naturaleza más colaborativa, la coreografía sigue la secuencia
de mensajes involucrados en múltiples participantes, y las dos técnicas
pueden ser usadas en diferentes casuísticas.

Existen diferentes lenguajes de composición, aunque no hay una solución uni-

versal. En los subapartados siguientes se describirán y compararán diferentes
lenguajes de composición.

Orquestación: WS-BPEL

BPEL ha sido diseñado específicamente como un lenguaje para la definición

de procesos de negocio y está basado en un documento XML y servicios web,
incluyendo SOAP, WSDL, UDDI, WS-Reliable Messaging, WS-Addressing, WS-
Coordination y WS-Transaction. Un proceso BPEL especifica los servicios web
CC-BY-SA • PID_00187408 21 SOA

involucrados en la composición, el orden de ejecución y las estructuras de

control de flujo algorítmicas, entre las diferentes actividades del servicio com-
puesto.

Con BPEL se puede especificar una secuencia de operaciones, o algún proceso

en paralelo, y además se puede expresar comportamiento condicional, como
por ejemplo cuando una invocación a un servicio web depende del valor de
una invocación previa. También se pueden definir iteraciones, declarar varia-
bles, copiar y asignar valores, definir gestores asociados a eventos (por ejemplo,
errores). A continuación se presenta un ejemplo de una correduría de seguros.

Un usuario accede a un portal de una correduría de seguros que trabaja con múltiples
compañías y proporciona al usuario la mejor oferta que se ajuste a las condiciones par-
ticulares del usuario.

Figura 6. Ejemplo de correduría de seguros

La combinación de estas estructuras puede definir nuevos servicios complejos

compuestos y, de este modo, BPEL es comparable a un lenguaje de propósito
general como Java, aunque no tan potente. Por otro lado, WS-BPEL es más
simple y más adecuado para la definición de procesos, aunque no se puede
reemplazar, sino que debe ser utilizado como complemento a otros lenguajes
modernos. A continuación, se presenta un ejemplo (HelloWorld) sencillo de
definición de proceso de negocio con BPEL. Habitualmente se modela me-
diante una interfaz gráfica la composición del servicio y el entorno genera el
código WS-BPEL.
CC-BY-SA • PID_00187408 22 SOA

Figura 7. Ejemplo WS-BPEL de un "Hola, mundo" y de orquestación en BPEL.

Coreografía: WS-Choreography

WSCI es un lenguaje de descripción de lenguajes que describe un flujo de men- WSCI

sajes intercambiados por un servicio web que interactúa con otros servicios
WSCI es un acrónimo de WS-
web. WSCI describe el comportamiento del servicio web, que se describe en choreography interface; se tra-
términos de dependencias temporales y lógicas, mensajes intercambiados, re- ta de una especificación de
W3C basada en el modelado
glas, correlación, gestión de excepciones y transacciones. WSCI, además, des- de procesos con XML. Los ser-
vicios web actúan como igua-
cribe el intercambio colectivo de mensajes, con lo que proporciona una vista les en un esquema de colabo-
ración.
global de las interacciones.

WSCI no relaciona la definición y la implementación interna de los procesos

que finalmente conducen al intercambio de mensajes; el objetivo de WSCI es
describir el comportamiento del servicio web por medio de una interfaz basada
en el flujo de mensajes. Esta descripción permite a desarrolladores, arquitectos
y herramientas una vista general del intercambio dinámico de mensajes, así
como entender las interacciones con el servicio web.

3.2. Servicios web basados en REST

(13)
Los servicios�web�basados�en�REST (RESTful web services) son servicios dise- Del inglés representational state
13 transfer.
ñados para funcionar de manera más eficiente sobre la Web. REST es un esti-
lo arquitectónico que especifica restricciones, como por ejemplo una interfaz
CC-BY-SA • PID_00187408 23 SOA

uniforme (basada en identificadores para los recursos), que si se aplica a un REST

servicio web infiere propiedades como el rendimiento o la escalabilidad, que
REST hace referencia a un es-
hacen posibles servicios más eficientes, simples y de un alto rendimiento. REST tilo arquitectónico orientado
se basa en una arquitectura web denominada arquitectura orientada a recur- a recursos (ROA). Fue introdu-
cido en el año 2000 por Roy
sos (ROA), que se basa en acciones sobre recursos para permitir la interacción Fielding en su tesis doctoral.

entre cliente y servidor, mediante el uso de los métodos get, post, put y delete
inherentes de HTTP (y relacionados, como operaciones CRUD) e implemen-
Ved también
tado en navegadores, que no requieren mensajes SOAP/XML o descripciones
WDSL. Esto hace que esta estrategia resulte mucho más ligera. En las asignaturas de bases de
datos se explican con detalle
las operaciones CRUD (create,
read, update, delete).

En REST, los datos y la funcionalidad son considerados como recursos,

y a estos recursos se accede mediante identificadores (URI), por medio
de un conjunto de operaciones sencillas y bien definidas. El estilo ar-
quitectónico REST se basa en una arquitectura cliente-servidor, y está
diseñado para que clientes y servidores intercambien información me-
diante una interfaz estandarizada, simple y mediante el uso de un pro-
tocolo de comunicación sin estado, por lo general, de HTTP.

(14)
REST o los servicios web RESTful14 se están utilizando de manera regular, sobre Un servicio�web�RESTful es un
servicio simple basado en HTTP y
todo y especialmente, en dispositivos de escasos recursos y en un contexto web un estilo REST.
2.0. Un desarrollo basado en servicios�web (llamado Web API) también puede
realizarse con un estilo de comunicaciones REST. Web API permite la combi- Entity Bean
nación de múltiples servicios web en nuevas aplicaciones llamadas mashups.
En Java EE, un Entity Bean o un
POJO tiene un comportamien-
to similar a un recurso, ofrece
A continuación, se describirá el concepto de recurso, los estilos y los formatos
un mecanismo de acceso a la
de los datos (POX, JSON) y, finalmente, un mecanismo de especificación de información.
Un session bean puede ver-
servicios web basados en REST (WADL). se como un controlador que
proporciona unas operaciones
(servicio).
3.2.1. El concepto recurso

Un recurso puede ser definido como un artefacto de software asociado a in- Ved también

formación específica (datos). Los recursos se definen mediante nombres, que

En el subapartado "Web 2.0"
describen la información que proporciona el recurso y las operaciones CRUD se puede ver con más detalle
el concepto de mashups.
predefinidas en una interfaz semántica.

La semántica en REST está basada en un conjunto de operaciones HTTP: DBMS

Si WS-* puede verse como el

• Crear recurso: crea un nuevo recurso y el identificador único (put). mecanismo de RPC de Inter-
net, REST puede verse como el
• Obtener la representación del recurso (get). DBMS (database management
system) de Internet.
• Borrar un recurso (delete).
• Modificar un recurso (post).
• Obtener metainformación sobre un recurso (head).
CC-BY-SA • PID_00187408 24 SOA

3.2.2. Formatos para representar los recursos

REST recomienda el uso de estándares establecidos, como por ejemplo URL

para el direccionamiento, los métodos HTTP para la comunicación; y tipos
MIME con diferentes tipos de datos: XML, JSON, XHTML, HTML, PNG y otros
estilos de formatos de información. A continuación se describirán los métodos
más usados para el proceso de serialización (marshalling) de la información:
POX y JSON.

POX

(15)
POX15 es un término que se ha inspirado en otros términos como POJO16 y, Del inglés plain old XML.

conceptualmente, sigue la misma filosofía en referencia a la relación entre los

(16)
datos y la forma abstracta de organizarlos. En el caso de un POJO, el conte- Del inglés plain old Java object.

nedor sobre el que se organiza la información es una clase Java, y en el caso

de un POX, la información se estructura jerárquicamente, utilizando un do-
cumento XML.

JSON

(17)
Además de utilizar XML (POX) para serializar la información que se transmite Del inglés JavaScript object nota-
tion.
tanto en la petición como en la respuesta, existen otras estrategias como el uso
17
de JSON . JSON se emplea cuando el tamaño del flujo de datos es de vital
importancia. La simplicidad de JSON ha dado lugar a la generalización de su
uso, por la facilidad de desarrollo y rendimiento. El único inconveniente es
que penaliza la validación de la información que envía el cliente.

JSON es un formato ligero de intercambio de datos. Es fácil de leer y es-

cribir para los seres humanos, y de analizar y generar para las máquinas.

Se basa en un subconjunto del lenguaje de programación JavaScript. Está ba-

sado en dos estructuras:

1) Una colección de pares nombre/valor. En varios idiomas, esto se hace como

un diccionario.

2) Una lista ordenada de valores.

Estas son estructuras de datos universales y, prácticamente, todos los lengua- Lenguajes de
jes de programación modernos lo implementan de una manera u otra. En el programación

ejemplo que se presenta a continuación, se muestra una entidad Persona con Los lenguajes de programa-
los atributos nombre, fecha de nacimiento, nickname y una lista de números de ción ActionScript, C, C++, C#,
ColdFusion, Common Lisp,
teléfono: móvil, fijo y el del trabajo. Delphi, E, Eiffel, Java, JavaS-
cript, Perl, PHP y Python im-
plementan una API para anali-
{ zar y generar JSON.
"class": "Person",
"name": "William Shakespeare",
CC-BY-SA • PID_00187408 25 SOA

"birthday": -12802392000000,
"nickname": "Bill"
"phoneNumbers": [
{
"class": "Phone",
"name": "cell";
"number": "555-123-4567",
},
{
"class": "Phone",
"name": "hombre",
"number": "555-987-6543"
},
{
"class": "Phone",
"name": "work",
"number": "555-678-3542"
}
}
}

WADL

(18)
Una forma de especificar una interfaz de un servicio basado en REST es utilizar Del inglés web application des-
18 cription language.
un lenguaje de descripción denominado WADL . WADL es un documento
XML que proporciona una descripción legible de aplicaciones web basadas (19)
Del inglés web services descrip-
en HTTP. El propósito de WADL es permitir que los servicios en Internet se tion language.
describan de una manera procesable por una máquina, para que sea más fácil
para crear aplicaciones web 2.0, así como una forma dinámica de creación
y configuración de servicios. Sin una especificación del servicio, es necesario
hacer ingeniería inversa y construir la aplicación de una manera primitiva.
WADL puede considerarse como el equivalente de WSDL19.

Figura 8. Ejemplo de especificación basada en WADL

3.3. Diferencias entre servicios web basados en REST y en SOAP

(WS-*)

Una de las diferencias fundamentales entre las dos estrategias de implementa-

ción de servicios web estudiadas (RESTful WS y basados en SOAP) es la filosofía
intrínseca de las dos opciones. Buscando una analogía, podemos acordar que
las aplicaciones basadas en REST se organizan en recursos (nombres), mientras
que las aplicaciones basadas en servicios web (WS-*) se organizan en acciones
(verbos).

La tabla siguiente muestra una comparativa entre las dos estrategias para la
construcción de servicios web y presenta las ventajas e inconvenientes sobre
cada una.
CC-BY-SA • PID_00187408 26 SOA

Tabla comparativa de servicios web basados en REST y WS-*

Servicios web Características Ventajas Problemas

Modelo�REST • Arquitectura cliente-servidor. • Mecanismo ligero. • Integración con aplicaciones B2B.

• Orientado a recursos. • Aumento de escalabilidad. • Falta de estándares.
• Identificador único de recursos • Aumento de rendimiento.
basado en URI.
• Protocolo HTTP: get, post, put, de-
lete.
• No tiene estado.
• Mensajes autodescriptivos.

WS-* • Independiente del lenguaje y pla- • Especificaciones W3C. • Capacidad de computación para
taforma. • Permite utilizar otros protocolos el procesado de los XML.
• No ligado a ningún protocolo. de transporte. • Rendimiento.
• Puede utilizar un registro UDDI. • Ancho de banda alto.
• Basado en XML.
• Especificación de servicios basada
en WSDL.

La figura 9 muestra un ejemplo de una petición y respuesta en una invocación POX

a un servicio web que efectúa la suma de dos números. En este caso, la codifi-
POX (plain old XML) es un con-
cación de los datos en un esquema REST se realiza mediante un documento cepto análogo de POJO que
XML (POX). pretende relacionar y serializar
(marshalling) una entidad de
información a XML.
Podéis ver con más detalle el
concepto POJO (plain old Java
object) en el módulo "Java EE"
de este material didáctico.

Figura 9. Ejemplo de petición SOAP - REST/POX

Se aprecia una diferencia de peso (tamaño) en la opción basada en servicios

web pesados (SOAP), en comparación con la opción basada en servicios web
basados en REST/POX. En este último caso (REST), tanto las peticiones como
las respuestas son relativamente pequeñas respecto al tamaño de los mensajes
SOAP. El motivo fundamental es que SOAP requiere una codificación basada
en XML para las peticiones y las respuestas que incrementa el tamaño del
mensaje. En el caso de REST se puede minimizar el peso de los mensajes con
alternativas como JSON.
CC-BY-SA • PID_00187408 27 SOA

4. Diseño de aplicaciones orientadas a servicios con

UML

En módulos anteriores hemos visto cómo se utiliza RM-ODP para definir la Ved también
arquitectura en términos de componentes arquitectónicos y conectores en-
Consultad los módulos "Diseño
tre estos y cómo, posteriormente, se refina esta especificación en términos de de aplicaciones distribuidas",
un conjunto de componentes de software que los implementan teniendo en "Arquitectura del software" y
"Desarrollo de software basado
cuenta que antes han estado especificados de manera independiente de la tec- en componentes" de este ma-
terial didáctico.
nología.

Una vez se ha hecho la elección tecnológica (en este caso, servicios web basa-
dos en SOAP y RESTful) es necesario realizar una fase previa de diseño para
evitar errores y disminuir la distancia entre la especificación y la implementa-
ción concreta, utilizando diagramas UML para representar estas decisiones.

Esta fase partirá de una representación de los componentes que forman la apli-
cación independientemente de la tecnología y finalizará con una representa-
ción de dichos componentes con el perfil SOA.

Dentro del amplio conjunto de diagramas que especifica UML 2.0, nos centra-
remos en cómo se representa el sistema concreto con los diagramas de com-
ponentes y despliegue. Para mostrarlo nos basaremos en un ejemplo sencillo
que ilustre los pasos que deben darse y en algunas de las consideraciones que
hay que tener en cuenta.

4.1. Perfil UML para aplicaciones orientadas a servicios

En el supuesto que nos ocupa, se han elegido los servicios�web como tecnolo-
gía de implementación, que presenta algunas particularidades que hacen ne-
cesaria una extensión de UML para poder representar todos los elementos.

Algunas variaciones o particularidades de los servicios web respecto a los con-

ceptos generales que define UML son las siguientes:

• Dependiendo del tipo de componente: cliente SOAP, servicio web, WDSL.

• Descriptores de despliegue.
• Formatos estándar de empaquetado.

A falta de una definición estándar para el perfil de los servicios� web, para Web recomendada
redactar estas anotaciones nos basaremos en el perfil web services, que aparece
El documento Superestructu-
como ejemplo en el documento Superestructura de UML 2.0, y añadiremos los ra de UML 2.x está disponible
elementos que necesitaremos para modelar los aspectos más relevantes de las en http://www.omg.org/spec/
uml .
aplicaciones basadas en servicios web.
CC-BY-SA • PID_00187408 28 SOA

La tabla siguiente muestra algunos de los estereotipos que definen el docu-

mento Superestructura de UML 2.0 y otros que hemos definido en estas anota-
ciones para ilustrar los servicios web.

Estereotipo Tipo�de�elemento Descripción

<<WebService>> Componente El componente que representa el servicio web.

<<wdsdl>> Interfaz Contrato o interfaz del servicio web.

<<asynchronousClient>> Componente Componente que actúa como cliente asíncrono.

<<wsStaticClient >> Componente Componente que actúa como cliente y utiliza los stubs generados.

<<wsDynamicClient >> Componente Componente que actúa como cliente y que realiza invocaciones dinámicas sobre el
servicio web.

<<WebServiceProvider>> Componente Proveedor del servicio web.

<<WebMethod>> Método Método de un servicio web.

<<RequestWrapper>> Componente Envoltorio de una petición.

<<ResponseWrapper>> Componente Envoltorio de una respuesta.

<<AsyncHandler> Componente Gestor asíncrono.

<<handlerChain>> Componente Cadena de gestores.

<<uddi>> Componente Componente que actúa como un servidor de directorio.

<<soapmessage>> Componente Mensaje SOAP.

<aar> Artefacto Fichero en formato AAR (archivo axis).

En el caso de servicios web basados en REST, podemos proponer otra tabla con
los elementos siguientes:

Estereotipo Tipo�de�elemento Descripción

<<WebResource>> Componente RESTful web service.

<<HttpMethod>> Método Método del servicio web.

<<wadl>> Interfaz Contrato o especificación del servicio.

<<Produces>> Componente Componente que actúa como consumidor.

<<Consumes>> Componente Componente que actúa como consumidor.

<<Context>> Componente Contexto del servicio.

<<text_xml>> MediaType Tipo de datos.

<<application_json>> MediaType Tipo de datos.

<<application_xml>> MediaType Tipo de datos.

<<application_form_urlencoded>> MediaType Tipo de datos.

CC-BY-SA • PID_00187408 29 SOA

Estereotipo Tipo�de�elemento Descripción

<<ApplicationPath>> Componente Raíz de los recursos REST.

El objetivo de este subapartado no es definir un perfil completo SOA, sino

mostrar la importancia que tiene disponer de un perfil para la tecnología con-
creta y cómo nos ayudará para especificar la fase de diseño.

4.2. Ejemplo

Para ver cómo se aplican algunas de las decisiones de diseño que hemos co-
mentado en el apartado anterior y cómo se van refinando los diagramas de
componentes hasta deducir casi la implementación, vamos a trabajar sobre el
componente que permite a los clientes del banco en línea hacer operaciones
con sus cuentas.

Tal como se presentó en el módulo "Java EE" de este material didáctico, este Ved también
componente se podría representar como se muestra la figura 10, en el nivel
Encontraréis el diseño de la
más alto de abstracción. aplicación en el módulo "Java
EE" de esta asignatura.

Ved también

El módulo "Java EE" de este

material didáctico muestra to-
do el proceso de diseño del
Figura 9. Componente independiente de la tecnología componente OperacionesBási-
cas.
Después de realizar (en el módulo "Java EE" de este material didáctico) todo el
proceso de refinamiento, se analizaron uno por uno todos los componentes
y se tomó una decisión de despliegue basada en desplegar toda la parte web
en una máquina que actúa como contenedor web y la parte de negocio y per-
sistencia en otra máquina con un contenedor EJB. El diagrama de despliegue
quedó como muestra la figura 10.
CC-BY-SA • PID_00187408 30 SOA

Figura 10. Diagrama de despliegue

Ahora supondremos que el banco en línea es una parte dentro de un conglo-

merado de un gran grupo bancario resultado de una fusión de bancos y cajas;
y toda la gestión de cuentas bancarias se realiza mediante la interacción entre
los propios bancos que forman el grupo fusionado.

(20)
El sistema debe permitir que un usuario pueda acceder por medio de cualquier Del inglés enterprise application
integration.
oficina del grupo fusionado, a pesar de que la información de sus cuentas
corrientes esté en los sistemas de otro banco. La estrategia de integración de (21)
API es la sigla de application pro-
sistemas que se propone en el grupo fusionado consiste en una solución basada gram interface.
en un EAI20 y una arquitectura orientada a servicios. De este modo, cuando un
usuario interactúa con una oficina de un banco, ya sea con el móvil, la Web
o presencialmente, y no es el que posee la cuenta corriente, este debe acceder
mediante las API21 que le proporcionan otros bancos, a toda la información
(productos y servicios) que se ofrecen al usuario.

La figura 11 presenta un esquema que muestra todo el escenario descrito.

Figura 11. Grupo bancario

CC-BY-SA • PID_00187408 31 SOA

Con este escenario, el funcionamiento consiste en usuarios que acceden por

medio de una aplicación ad hoc en el móvil, un navegador o accediendo pre-
sencialmente a una oficina bancaria a los servicios contratados. Cada banco,
cuando tiene que ofrecer servicios a un usuario con cuentas corrientes no ges-
tionadas directamente por él, interactúa con el banco correspondiente en un
modelo de negocio B2B.

Con este escenario la situación quedaría como se presenta en la figura 12.

Figura 12. Ejemplo del banco en línea

En la figura 12 se pueden apreciar dos nodos: por un lado, un primer nodo, el Ved también
banco en línea (banco A), que es el componente original Java EE descrito en el
Este módulo no tiene en con-
módulo "Java EE" de estos materiales didácticos, al que no�se�ha�implemen- sideración aspectos de segu-
tado�ninguna�funcionalidad�adicional respecto al que se ha descrito ante- ridad, que se describen en la
asignatura Seguridad en redes
riormente. Y por otro lado, tenemos un segundo banco (banco B), que ofrece de computadores.

operaciones con cuentas que son gestionadas por el propio banco, y en este
caso tendríamos un comportamiento similar a las funcionalidades ofrecidas
por nuestro banco en línea pero que pueden estar desarrolladas en platafor-
mas y perfiles tecnológicos diferentes. El banco en línea exporta y ofrece una
API sobre las operaciones con cuentas especificadas y diseñadas anteriormente
hacia otros bancos para que puedan interactuar utilizando, en este caso, ser-
vicios web WS-* basados en un esquema B2B.

De este modo, cuando un usuario accede de manera presencial o mediante un

dispositivo móvil o navegador a una oficina del grupo para realizar una ope-
ración�básica de su cuenta corriente que este banco no gestiona directamente,
se accederá al banco originario mediante un servicio que proporciona dicho
banco y ofrecerá de manera transparente las operaciones básicas de la cuenta.
La figura 13 muestra la interacción de componentes y el paso de mensajes
cuando un usuario intenta acceder al saldo de su cuenta corriente.
CC-BY-SA • PID_00187408 32 SOA

Figura 13. Diagrama de secuencia de una consulta de cuenta

Por último, solo queda determinar qué ha sido necesario añadir en el módulo
Java EE original para ofrecer en un servicio web las operaciones organizadas en
forma de API, que permitirán que terceras partes, en este caso otras oficinas,
puedan hacer uso de ellas. El refinamiento de la capa de negocio queda tal
como se muestra en la figura 14.

Figura 14. Refinamiento de la capa de negocio

Si aplicamos el perfil tecnológico SOA para servicios web basados en WS-*

obtenemos el diagrama de componentes que muestra la figura 15, donde se
puede apreciar la interfaz con los métodos del servicio� web, y la forma de
implementación del servicio exportando las operaciones de la EJB de Session.
CC-BY-SA • PID_00187408 33 SOA

Figura 15. Aplicación del perfil SOA

CC-BY-SA • PID_00187408 34 SOA

Resumen

Este módulo ha dado una visión general de la evolución de los servicios dis-
tribuidos, en paralelo con la evolución de Internet. A medida que se iban am-
pliando las posibilidades del medio y los usos por parte de los usuarios, se han
producido cambios de paradigma y nuevas arquitecturas. En este caso, este
módulo se ha centrado en la definición de la arquitectura�orientada�a�servi-
cios y las formas más comunes de la implementación de servicios distribuidos.

A lo largo del módulo se han definido el concepto SOA y las características

de este modelo arquitectónico, y se han presentado esquemas de negocio B2C
(negocio orientado al usuario) y B2B (orientado de negocio a negocio) que
tienen sinergias entre estos esquemas de negocio y la arquitectura�orientada
a�servicios. Se han explicado dos estrategias de implementación: servicios web
pesados (basados en HTTP/SOAP) y servicios web ligeros (RESTful web services);
y finalmente, se propone como forma de construcción de servicios complejos
la reutilización y la composición�de�servicios, basadas en la orquestación o
la coreografía.

El último apartado del módulo ha servido para presentar las bases del diseño
de�aplicaciones�SOA, con toda una serie de recomendaciones y aspectos que
hay que tener en cuenta.
CC-BY-SA • PID_00187408 35 SOA

Actividades
1. Dados los siguientes tipos de software por diseñar, indicad en cada caso si es aconsejable el
uso de una arquitectura orientada a servicios (SOA). En caso afirmativo, describid brevemente
el escenario:

a) Una empresa que comercializa muebles y trabaja con diferentes fábricas. Se quiere ofrecer
al usuario una plataforma única para comercializar los productos.

b) Un sistema de voto electrónico, para mejorar la democracia directa y facilitar la consulta

y los referéndums a los ciudadanos que pueda funcionar a escala local, autonómica, estatal
y europea.

c) Un sistema de compartición de archivos en la nube, al que se pueda acceder mediante

dispositivos móviles y ordenadores personales.

d) Una red social orientada a salud que quiere ofrecer una API para que terceras partes desa-
rrollen aplicaciones.

e) Un sistema de vídeo bajo demanda.

2. Implementad la calculadora especificada en el módulo "Java RMI" utilizando servicios web

basados en SOAP.

3. Implementad la calculadora especificada en el módulo "Java RMI" utilizando servicios web

basados en REST.

4. Utilizando un monitor de SOAP o un analizador de protocolos, presentad los mensajes

generados en la petición y respuesta del ejercicio anterior (SOAP y REST).

5. Buscad y analizad orquestadores (basados en WS-BPEL) comerciales y no comerciales que

haya en el mercado.

Ejercicios de autoevaluación
1. ¿Es cierto que los servicios web solo pueden funcionar por HTTP?

2. Explicad en qué consiste UDDI y cuál es su función.

3. Explicad la forma en que los servicios en una arquitectura SOA están desacoplados.

4. Describid la característica de la�encapsulación�de�los�datos en un esquema SOA.

5. ¿Cuál es la tecnología inherente a SOA?

6. ¿Cómo se implementan las operaciones CRUD (create, read, update, delete) cuando se utiliza
REST?
CC-BY-SA • PID_00187408 36 SOA

Solucionario
Ejercicios de autoevaluación

1. Falso, no existe tal limitación; los servicios web pueden funcionar sobre multitud de pro-
tocolos de comunicación. Por ejemplo, HTTP, TCP, UDP, etc.

2. UDDI es un registro de servicios SOA que tiene como función principal actuar como índice
de los servicios desplegados. Contiene la información básica (interfaz) de los servicios: punto
de entrada (endpoint), operaciones, formado de los parámetros e información adicional. Debe
tener todo lo necesario para utilizar un servicio en un nuevo entorno.

3. La única interrelación entre dos servicios o piezas de software es la interfaz (definida por
WDSL si utilizamos servicios web basados en SOAP) o contrato del servicio.

4. La encapsulación de los datos consiste en que los datos pertenecen al servicio que los
gestiona, es decir, que nadie fuera del servicio puede modificarlos o verlos sin pasar por el
servicio.

5. SOA es neutra respecto al punto de vista tecnológico. Solo ofrece una arquitectura o para-
digma de computación que permite que cualquier tecnología pueda ejecutar componentes
de manera remota (paradigma RPC) indicando un contrato del servicio.

6. REST implementa las operaciones CRUD adaptando las operaciones HTTP (get, post, put
y delete).
CC-BY-SA • PID_00187408 37 SOA

Glosario
coreografía  f  Coordinación de un grupo de servicios sin un controlador central.

JSON (JavaScript object notation)  m  Formato o estilo de codificación de la información

inspirado en el lenguaje JavaScript.

orquestación  f  Coordinación por parte de un director de orquesta de varios servicios de

manera centralizada.

REST (representational state transfer)  m  Estilo o arquitectura orientada a recursos que

son accesibles por medio de URL.

RESTful web services   f  Tecnología que implementa servicios ligeros basados en REST.

servicio  m  Pieza de software que ofrece una interfaz (contrato) basada en unas operaciones
con unos parámetros de entrada/salida especificados.

servicio web (WS-*)  m  Tecnología que implementa servicios basados en SOAP.

SOAP (simple object access protocol)  m  Protocolo que especifica el mecanismo de se-
rialización de los elementos que intervienen en la petición o respuesta.

UDDI (universal description, discovery and integration)  m  Directorio o registro de

servicios web basado en XML.
CC-BY-SA • PID_00187408 38 SOA

Bibliografía
Bibliografía básica

Snell, J.; Tidwell, D.; Kulchenko, P. (2001). Programming Web Services with SOAP. O'Reilly
Media.

Woods, D.; Mattern, T. (2006). Enterprise SOA. O'Reilly Media.

Bibliografía complementaria

Arkin, A.; Askary, S.; Fordin, S.; Jekeli, W.; Kawaguchi, K.; Orchard, D.; Pogliani,
S.; Riemer, K.; Struble, S.; Takacsi-Nagy, P.; Trickovic, I.; Zimek, S. (2002, agosto).
Web Service Choreography Interface (WSCI) 1.0. W3C Note 8.

Besemer, D.; Butterworth, P.; Clément, L.; Green, J.; Ramachandra, H.; Schnei-
der, J.; Vandervoort, H. (2008). "An Implementor's Guide to Service Oriented Architectu-
re: Getting It Right". Composite Software.

Peltz, C. (2003, junio). "Web Services Orchestration and Choreography". SOA World Maga-
zine.

Reuther, B.; Müller, P. (2008). "Future Internet Architecture - A Service Oriented Ap-
proach". Information Technology Jahrgang 50 Heft 6 (págs. 383-389). Múnich: Oldenbourg Ver-
lag.

Richardson, L.; Ruby, S. (2007). RESTful Web Services. O'Reilly.

Van Than, D. (2003). Web Service Orchestration: An open and standardized approach for creating
advanced services. Eurescom.

Referencias bibliográficas

OASIS. OASIS Commitees by Category: SOA. [Fecha de consulta: junio del 2010] Disponible
en http://www.oasis-open.org/committees/tc_cat.php?cat=soa .

Wollrath, A.; Riggs, R.; Waldo, J. (2009). A Distributed Object Model for the Java System.
[Fecha de consulta: diciembre del 2010] Disponible en http://pdos.csail.mit.edu/6.824/pa-
pers/waldo-rmi.pdf .