DISEÑO Y MANTENIMIENTO DE SERVICIOS

TEMA 4: IMPLEMENTACIÓN DE PATRONES SOA E

INTEGRACIÓN DE SERVICIOS.

PRINCIPIOS DE REST VS SERVICIOS WEB

REST: estilo arquitectónico para la web.
SERVICIO WEB (WS-*): estándares de interoperabilidad SOA Middleware.

¿Cómo se pueden comparar? Mediante

un Modelado de Decisiones
Arquitectónicas.
Las decisiones arquitectónicas capturan los
principales problemas de diseño y las razones
detrás de una solución técnica.
La elección entre REST frente al
Servicio Web es una decisión
arquitectónica importante para proyectos
de integración.
Además, las decisiones arquitectónicas
se afectan mutuamente.

Espacio de decisión.
Las decisiones nos ayudan a medir la complejidad implicada por la
elección de REST o WS-* Existen 21 decisiones y 64 alternativas,
clasificadas por su nivel de abstracción:
− 3 principios arquitectónicos.
− 9 decisiones conceptuales.
− 9 decisiones a nivel tecnológico

Principios arquitectónicos
1) Capas de protocolo.
a. HTTP = Protocolo de nivel de aplicación (REST)
b. HTTP = Protocolo de nivel de transporte (WS-*)
2) Lidiando con la heterogeneidad.
3) Acoplamiento suelto.

Protocolo de capas
− Las aplicaciones deben publicar sus datos en la Web (a través de la URL)
− Las aplicaciones tienen la oportunidad de interactuar, pero
permanecen “fuera de la Web”.
Lidiando con la heterogeneidad
− Aplicaciones Web: Google, Opera, Internet Explorer, jetty://….
− Informática empresarial: ORACLE, CICS IMS, IBM DB2….

Medición de complejidad: las decisiones arquitectónicas dan una medida cuantitativa de la

complejidad de un espacio de diseño arquitectónico.
− Número total de decisiones.
− Para cada decisión, número de opciones alternativas.
− Para cada decisión alternativa, calcular el esfuerzo.

Conclusión:
Hay que concentrarse en cualquier solución útil para hacer el trabajo e intentar evitar
arquitecturas o tecnologías específicas.
WS-* tiene fortalezas y debilidades y será muy adecuado para algunas aplicaciones y
positivamente terrible para otras, y lo mismo para con REST.
La decisión de cuál usar depende de los requisitos y restricciones de la aplicación.

REST: define el estilo arquitectónico de la WWW. Sus cuatro principios pueden explicar el
éxito y la escalabilidad del protocolo HTTP que los implementa.
1) Identificación de recursos a través de la URL.
2) Interfaz uniforme para todos los recursos:
a. GET: consulta el estado
b. POST: actualiza un recurso
c. PUT: transfiere el estado del recurso existente.
d. DELETE: eliminar un recurso
3) Representación de mensajes “autodescriptivos”.
4) Hipervínculos para definir relaciones entre recursos y transiciones de estado validas de
la interacción del servicio.

INTEGRACIÓN DE SERIVICIOS. CONCEPTOS.

1) COMPOSICIÓN DE SERVICIOS.
a. ORQUESTACIÓN: Proceso de negocio general en el que existe un
orquestador, un servicio especial, que es el que va invocando a los
diferentes servicios compuestos. El lenguaje que se utiliza para
automatizar es BPEL.
Describe la lógica de ejecución de aplicaciones basadas en servicios Web
mediante la definición de sus flujos de control (ejecución condicional,
secuencias, paralela o excepcional) y el establecimiento de reglas para gestionar
los datos de negocio no observables.

Ej.: el empleado de una empresa debe ser capaz de modificar la retención de

IRPF de su nómica ← Se permite al usuario interactuar con un servicio, que
hablará con diferentes servicios.

b. COREOGRAFÍA: Cada servicio tiene un fragmento del servicio de

negocio que desea realizar. No existe un servicio concreto, hay roles
establecidos, con un elemento dentro de la composición de servicios que
dirige. El lenguaje estándar es WS-CDL.
Describen colaboraciones de servicios Web entre empresas mediante la
definición del comportamiento común observable. Los intercambios de
información se producen a través de los puntos de contacto compartidos cuando
las reglas de ordenación de mensajes se cumplen.
 c. COORDINACIÓN / TRANSACCIÓN: Traspaso de información con unas
propiedades determinadas. Se comienza mediante un BEGIN y se termina
con un COMMIT; y siguen las propiedades ACID: Ej.: acción de una cuenta
bancaria.
− ATOMICITY: la operación debe ser única. Se ejecuta por completo.
− CONSISTENCY: la base de datos debe tener un estado consistente, es
decir, o se hace, o no se hace.
o ROLLBACK: cuando una transacción falla, CONSISTENCY
hace que se deshagan todos los pasos hasta el principio.
− ISOLATION: aislamiento, no debe haber interferencias en la
ejecución de la transacción.
− DURABILITY: los resultados de la ejecución de la transacción no son
volátiles, tienen que ser persistentes en el tiempo.

Esfuerzos para conseguir interacciones transaccionales entre servicios.

WS-COORDINATION y WS-TRANSACTION complementan BPEL para
ofrecer mecanismos que definan protocolos específicos para sistemas de
procesamiento de transacciones o sistemas de flujos de trabajo.

d. ESTÁNDARES DE VALOR AÑADIDO: Soportan interacciones de negocio

complejas (embebidos en SOA). Con mecanismos de seguridad y autenticación,
autorización, confianza, privacidad, conversaciones seguras, gestión de
contratos, …. Ejemplos: WS-SECURITY, WS-POLICY, WS-
MANAGEMENT.

2) IMPLEMENTACIÓN DE ESTILOS ARQUITECTÓNICOS/ PATRONES DE

DISEÑO.
2.1. SERVICIOS AGNÓSTICOS: Buena solución es implementar fragmentos de
servicios que sirvan y den soporte al servicio de mi empresa. Ej.: (1) GPS; (2)
Servicio de papelería.

Implementación de funcionalidades (CAPABILITIES) que son comunes a varios

problemas de negocio.

VENTAJAS: reutilización y facilidad de composición.

2.2. DECLARACIONES DE SERVICIOS AGNÓSTICOS: Contar con un catálogo o

una descripción estándar de dichos servicios agnósticos.

Los servicios agnósticos deberían declarar explícitamente que son agnósticos

(soluciones genéricas) a través de sus interfaces.

VENTAJA: reusabilidad en futuros desarrollos y facilidad de composicioçon

2.3. TRANSACCIONES EN SERVICIOS ATÓMICOS: Patrones de implementación
de servicios: implementar cuestiones alrededor de los servicios.

Los servicios deberían ser capaces de implementar operaciones y acciones “reversibles”

o ser capaces de participar en composiciones transaccionales.
Ha de implementarse en un componente/ servicio de una capa superior.

VENTAJAS: SATELESSNESS / gestión del estado entre invocaciones.

 2.4. ENTERPRISE SERVICE BUS (ESB): Utilización de una capa de coordinación y
comunicación entre servicios.

Un ESB es un componente tecnológico que actúa de gestor de mensajes

(transformaciones de mensajes, enrutamiento e interconexión de mensajes) a través de
la implementación de protocolos de comunicación.

VENTAJAS: bajo acoplamiento, interoperabilidad, abstracción de puntos de conexión.

2.5. SERVICE FAÇADE:

Fachada: patrón de diseño de alto nivel, que describe la utilización de un elemento
intermedio que actúa entre intermediario entre la lógica de negocio implementada
por detrás y el consumidor, que va a ver el contrato (las condiciones bajo las que
utilizar el servicio). Ej.: Spotify free vs Spotify Premium.
→ No tiene lógica de negocio, funciona como pasarela de información.
→ Independiza el contrato de la implementación del servicio.

Implementación de un servicio intermedio que se sitúa entre el contrato de servicio que

firma el consumidor y el servicio que implementa dicho contrato.
Sirve para eliminar o reducir el acoplamiento entre el servicio y su contrato.
La idea es ser capaz de reducir el impacto de un cambio bien en el contrato o bien en el
servicio.
Un mismo servicio puede tener varias fachadas para dar soporte a varios tipos de
contratos.

VENTAJA: bajo acoplamiento.

PATRONES ASOCIADOS A LA SEGURIDAD ↓

2.6. GESTOR DE AUTENTICACIÓN: El acceso a aplicaciones y servicios a través de

internet necesitan confidencialidad y reputación. Mediante la autenticación
(TOKEN de autenticación) autenticamos el servicio, y que los mensajes son de
quien deben ser.

Servicio cuya responsabilidad única es la de actuar de “autenticador” de consumidores

de acceso a un servicio.
Normalmente a los consumidores autenticados se les da un “TOKEN” de autorización
para acceder al servicio.

VENTAJA: facilidad de composición.

2.7. AUTENTICACIÓN DE MENSAJES DE ORIGEN: Utilizar certificados para la

autenticación de los clientes.

VENTAJA: facilidad de composición.

2.8. ANÁLISIS DE MENSAJES: Implementación de un servicio de análisis de mensajes

enviados a un servicio para evitar mensajes malintencionados.

VENTAJAS: reutilización y facilidad de composición.

3) TECNOLOGÍAS MIDDLEWARE PARA INTEGRACIÓN. PRINCIPIOS DE

INTEGRACIÓN DE SERVICIOS.
3.1. ORQUESTACIÓN: Una forma fácil de organizar los servicios que existen, es
poner un servicio que orqueste la invocación de todos ellos.

Componer diferentes servicios de grano fino existentes para conseguir un servicio

compuesto de alto nivel.
→ Conseguir la granularidad adecuada.
→ Promover la reusabilidad y la facilidad de gestión de los componentes compuestos.
3.2. TRANSFORMACIÓN: Cuando se piensa en integración, se necesita que la
información sea coherente, que se pueda pasar a un lenguaje común →
HOMOGENEIZACIÓN. Lo más sencillo es utilizar XML para datos
estructurados, y utilizar estrategias diferentes para los no estructurados o semi.
Los formatos de los datos intercambiados se transforman cuando son procesados por
elementos de gestión de información intermedios (ESB).
→ Ej.: CSV, SOAP/ XML, JSON, ….
→ La solución pasa por utilizar formatos estándar o canónicos.

3.3. TRANSPORTE: Como se conocen los servicios, la forma de comunicar por parte
de los servicios.

Es importante conocer los protocolos de negociación y transporte de información y el

impacto que éstos tienen en la implementación de la solución integrada.
→ Ej.: HTTP, JMS, JDBC.
→ Convertir los gestores de protocolos en servicios facilita la integración.

3.4. MEDIACIÓN: Plataforma MIDDLEWARE.

Proveer múltiples interfaces para conseguir:
a) Soportar múltiples versiones de un servicio para tener compatibilidad hacia atrás.
b) Permitir múltiples canales de comunicación con el mismo servicio de base.
→ Interfaces para un mismo componente: interfaz nativa e interfaz compatible con el
estándar.

3.5. CONSISTENCIA NO FUNCIONAL: Usabilidad, accesibilidad, seguridad,

mantenibilidad, tiempo de respuesta…. Se trata de que funcione BIEN.

Administrar aspectos no funcionales en la integración tales como seguridad y

rendimiento y mantener e implementar políticas de monitorización.

→ Otros aspectos importantes son la escalabilidad y la disponibilidad (redundancia para

tolerancia a fallos).

4) ESB:
DEFINICIONES:
(1) : Middleware, o elemento intermedio que me da u ofrece ciertas propiedades.

(2) : Estilo de arquitectura / producto software / conjunto de productos software

que proporciona servicios fundamentales para arquitecturas de servicios
complejas a través de un sistema de mensajes (el bus) basado en normas y que
responde a eventos.

Es un servicio más, un elemento más dentro de mi solución SOA, que me da soporte

auxiliar a la funcionalidad que quiero implementar. Puede ser un ejecutable sobre el
cual desplegar mi servicio, por lo que es algo que hace de intermediario.

Proporciona servicios auxiliares, capacidades fundamentales para el resto de los

servicios: seguridad, monitorización, capacidades de actualización,….

(3) : Es “cualquier cosa” que permita o soporte el envío de SOAP con capacidades de
direccionamiento.
FUNCIONES de un ESB:
CARACTERÍSTICAS de un ESB:
− Agnosticismo general respecto a sistemas operativos y lenguajes de
programación; por ejemplo, proporcionar interoperabilidad entre aplicaciones
Java y .NET.
− Uso general de XML como lenguaje de comunicación normalizado.
− Soporte para estándares de servicios web.
− Soporte para varios MEP (Patrones de Intercambio de Mensajes).
o Petición / respuesta síncrona o asíncrona.
o Send-and-forget.
o Publicación / suscripc
− Adaptadores para permitir la integración con sistemas de compatibilidad,
posiblemente basados en normas como la JCA
(Java_EE_Connector_Architecture)
− Un modelo de seguridad normalizado para autorizar, autenticar y auditar el uso
del ESB.

VENTAJAS de un ESB:
− Acomodación de sistemas existentes más rápida y barata.
− Mayor flexibilidad: más fácil de cambiar si hay nuevos requisitos.
− Basado en normas.
− Posibilidad de escalar desde soluciones puntuales hasta implementaciones de
empresa (bus distribuido).
− Tipos de servicios listos para funcionar predefinidos.
− Mayor configuración en vez de tener que codificar la integración.
− Sin motor de normas central, sin divisor central.
− Parches incrementales con tiempo de apagado instantáneo; la empresa se hace
“refactorizable”.

DESVENTAJAS de un ESB:

− Normalmente requiere un Modelo de Mensajes de Empresa, lo cual exige una

administración adicional.
− Requiere una administración constante de versiones de mensajes para asegurar
el pretendido beneficio de un emparejamiento flexible.
− Normalmente precisa más hardware que para un simple sistema de mensajes
P2P.
− Se precisan conocimientos en el análisis de middleware para configurar,
administrar y operar un ESB.
− Mayor latencia general causada por los mensajes que atraviesan la capa extra
del ESB, especialmente si se compara con las comunicaciones P2P.
− Mayor latencia también originada por un procesamiento de XML extra.
− El ESB se convierte en un elemento único de fallo.
− Aunque los sistemas de ESB pueden requerir un esfuerzo significativo para ser
implementados, no producen un valor comercial sin el consiguiente desarrollo
de servicios SOA para el ESB.

Soluciones comerciales:
− Mule ESB
− OpenESB (Java)
− Oracle ESB
− Oracle Service Bus
− Microsoft BizTalk Server
− Windows Azure ServiceBus
− IBM WebSphere ESB
− JBoss ESB
− Spring Integration
− Phoenix Service Bus (C#)
 5) METODOLOGÍAS Y MODELOS DE INTEGRACIÓN.
SIAM:
− SIAM es una adaptación de ITIL que se centra en gestionar la prestación de
servicios prestados por múltiples proveedores.
− NO es un PROCESO.
− Es una capacidad de servicio y un conjunto de prácticas en un modelo y
enfoque que se basa, elabora y complementa cada parte de las prácticas de
ITIL.
− El enfoque principal de SIAM es proporcionar el gobierno, la garantía y la
gestión coherentes necesarios de estos múltiples proveedores y servicios, ya
sean internos, externos o una combinación de ambos.

La integración, automatización y gestión de servicios es el concepto por el que los distintos

servicios de diferentes proveedores se alinean de tal manera que se perciben como si
provinieran de un solo proveedor. También consiste en controlar, gestionar y mejorar las
competencias y la sostenibilidad.
Está enfocado en la integración de los servicios de proveedores y en el área de contacto
entre clientes y proveedores.