1

Índice
1 Claves SOA

2 Conceptos SOA
 2

¿Qué cambia SOA frente al desarrollo tradicional?

¿SOA es más de lo mismo o aporta algo nuevo?

Dicen que SOA trata de la reutilización, pero hace ya mucho tiempo que
se están reutilizando objetos, rutinas, API’s, componentes, entonces que
es lo nuevo?

Dicen que SOA trata de la orientación al negocio y dialogo con el
negocio, pero hace ya mucho tiempo que hay BPM y orientación al
negocio, entonces que es lo que cambia?

Dicen que SOA necesita Gobierno, pero hace mucho tiempo que en IT se
necesita y se define Gobierno implícito o explicito

Dicen que SOA necesitan herramientas para desarrollar, conocer el
inventario de recursos, probar, monitorizar, operar, pero hace mucho
tiempo que hay herramientas de desarrollo, de monitorización, de
pruebas, entonces que cambia?

• ¿Por qué y en qué SOA es diferente?

España
 3

¿Qué cambia SOA frente al desarrollo tradicional?

Principios y conceptos utilizados en SOA:

Modularidad

Reutilización

Bajo acoplamiento

Separación de interfaz e implementación

Independencia de la implementación

Programación en base a contratos

Lógica por un lado, en los servicios (M); presentación por otro (V y C)

• Pero todo esto tampoco es nuevo ni diferente de otras

tecnologías y conceptos existentes (ORB, Corba, DCom, .Net,
RMI, RPC, modelo tres capas, etc 1.)

España
 4

CLAVES APORTACION SOA

CLAVE 1: Publicación/Invocación universal

SOA como Arquitectura Orientada a los Servicios es una abstracción

soportada por tecnologías y técnicas anteriores existentes, en particular la
de Web Services, pero no tiene que confundirse con ellas

Una de las diferencias clave de SOA frente a lo anterior ha sido la
utilización de los mecanismos de publicación y de invocación adoptados
de los Web Services para desacoplar y aislar las funciones de negocio
del resto de los sistemas de información. La diferencia es que SOA pone
el énfasis sobre las funciones de negocio, dado que los mecanismos de los
Web Services no tienen preferencia en si mismo sobre su uso para
funciones de negocio u otros puramente técnicos, por ejemplo

Esta publicación y esta invocación, al estar soportados en estándares
universales (UDDI, SOAP, XML, TCP/IP, WS.*, etc 9) utilizados en
Internet, hacen la diferencia con lo que pasaba con los estándares
anteriores (Corba, etc 9) que tenían una aceptación y un soporte parcial
por parte del mercado limitando la interoperabilidad y por lo tanto su uso.

España
 5

CLAVES APORTACION SOA (II)

CLAVE 2: Publicación/Invocación universal vs Ensamblaje (estático
o dinámico)

A diferencia de los ensamblajes de códigos tradicionales, el hecho de
poder separar el conocimiento de la existencia de una función y de poder
invocarla de manera conocida y estándar independientemente de su
implantación subyacente cambia radicalmente todo el ciclo de vida de
este software.

Al tener la posibilidad de conocer por consulta directa y sencilla de un
registro la existencia de un servicio (publicación) y que sea suficiente
para poder invocarlo, eso es lo que cambia las reglas del juego de la
distribución tradicional del software y de su uso al perder una gran parte
del control:
• Control de quien conoce la existencia de una función
• Control de quien puede utilizarla función

La universalidad impone un compromiso mucho mayor con el “mundo
entero” por parte del proveedor del servicio frente a la distribución
tradicional del software y de su puesta a disposición a los usuarios

España
 6

CLAVES APORTACION SOA (III)

CLAVE 2: Publicación/Invocación universal vs Ensamblaje (estático
o dinámico)

De la misma manera que el salto de una persona a la fama le cambia la
vida (guarda espalda, firmar autógrafos, persecución de los paparazis,
mantener imagen publica honorable compatible con su oficio, etc 9), el
“salto a la fama” de los servicios impone cambios en sus vidas y tiene
consecuencias y diferencias frente a los desarrollos tradicionales:
• Identificación de los servicios
• Diseño de los servicios Costes
• Implementación de los servicios
• Publicación de los servicios en sus Tiempo
diferentes fases del ciclo de vida
(repositorio/registro) Compromisos
• Mantenimiento y evolución de los servicios
(versionado) Organización
• Gobierno
Personal
• Compromiso de ejecución (Contrato y SLA)
especializado
• Modelo de Financiación
 7

CLAVES APORTACION SOA (IV)

CLAVE 2: Publicación/Invocación universal vs Ensamblaje (estático
o dinámico): Ejemplo impacto sobre el gobierno de los servicios:
Conceptual Retirar un servicio (y estar a punto
de retirada) debería implicar una
análisis
notificación a los clientes
implicados (consumidores)
Perfilado

Atrasado o Descartado Decisión presupuestaria Pre requisitos del servicio

identificados
Los cambios de numero
Presupuestado mayor de version pueden
Especificaciones provocar una notificación de
Decisión eliminación cambios en curso
Planificado
Diseño detallado

Un cambio de numero mayor de

Amortizado Diseñado versión requiere notificación a
Construcción & Test los clientes

LEYENDA
Estado Anterior Servicio
Acción o Actividad
Nuevo Estado Servicio
Publicar en el
repositorio
Necesidad de revisión
Desarrollado
Test de aceptación El despliegue necesita hacer
Re-Versionado
los cambios correspondientes
en la Descripción del Servicio
Aprobado
(SD) para reflejar la dirección
Despliegue de la dirección de la Instancia
del Servicio (SI)
Operacional

Publicar en el
registro

España
 8

CLAVES APORTACION SOA (V)

CLAVE 2: Cambios entre una aplicación diseñada de manera
tradicional y la misma con servicios:

Estilo tradicional:  1 jefe de proyecto
 3 equipos de trabajo
 5 tests unitarios
Aplicación A  1 test de integración
Aplicación A
Aplicación A
 1 servidor de producción a
monitorizar
 1 aplicación a monitorizar
 1 conjunto de reglas de
seguridad por aplicación
 1 release por aplicación
Un servidor de aplicación  1 despliegue por release
(cluster)
 1 SLA por aplicación
 1 equipo de soporte
Equipos de trabajo A1  1 responsable de aplicación
Equipos de trabajo A2  1 propietario de negocio
Equipos de trabajo A3  9.
 9

CLAVES APORTACION SOA (VI)

CLAVE 2: Cambios entre una aplicación diseñada de manera
tradicional y la misma con servicios:  1 jefe de proyecto
 n+1 equipos de trabajo

Estilo servicios:
 1+x arquitectos de Servicios
 397 tests unitarios
Aplicación A  1+x tests de integración
 S servidores de producción a
ESB monitorizar
 397 políticas de seguridad + un
397 servicios

conjunto de políticas coherente para

la aplicación
 397 servicios a monitorizar
 1 ESB
Registro  1 Repositorio
 1 Registro
 +397 releases por aplicación
Equipos de trabajo E1  397 SLA’s +1 SLA por aplicación
Equipos de Servicios S1  E equipos de soporte
 R responsables de servicios
Equipos de Servicios Sn S servidores de servicios Repositorio  P propietarios de negocios
 9..
 10

CLAVES APORTACION SOA (VII)

CLAVE 3: Orientación al negocio

El salto a la fama de los servicios, al costar más caro que el desarrollo
tradicional tiene que dar más beneficios y aportar más valor. Es por eso
que SOA se centra solo en las funciones de negocio y su
implementación como servicios para garantizar la rentabilidad de la
inversión:
Número de Servicios publicados

Implantación
de SOA fallida

Situación típica

Valor para el negocio

España
 11
Índice
1 Claves SOA

2 Conceptos SOA
 12

CONCEPTOS SOA
Una definición de SOA:

SOA como Arquitectura Orientada a Servicios, define un marco
conceptual para organizar y permitir la (re-)utilización de medios
distribuidos que pueden pertenecer a diferentes dominios dentro o fuera
de una organización.

Organización A Organización B

El Modelo de Referencia de SOA hace referencia a los conceptos de

“requisitos/necesidades”, “medios”, “recursos” y “servicios”, donde SOA
proporciona un mecanismo, el servicio, para hacer corresponder los
requisitos de los consumidores de servicios con los medios ofrecidos por
los proveedores de servicios

España
 13

CONCEPTOS SOA
Una definición de SOA (II):

El concepto de Servicio es fundamental en el modelo de referencia: se define como
un mecanismo que permite tener acceso a uno o más medios donde el acceso se
proporciona mediante una interface de acuerdo a unas normativas y restricciones de
uso especificadas en la descripción del servicio: cuando eso ocurre, los medios se
transforman en recursos disponibles. Fundamental, también, es la diferencia entre
consumidor y proveedor del servicio: el servicio establece un vinculo entre ambos
pero uno tiene derechos concedidos, el otro compromisos adquiridos que asumir. El
contrato es la materialización de este vinculo.
Proveedor del servicio
Consumidor del servicio
Restricciones
Medios
Contrato
Recursos uso y
normativa

Servicio

Interface Interface

España
 14

CONCEPTOS SOA
Proveedor
SOA en imágenes: Interface Interna
110V, toma americana,
SERVICIO 60Hz, Max 20A
Consumidor

Conversión
Contrato
voltaje y
Contadores
frecuencia
corriente
Interface Publicada Medios
220V, toma europea
con tierra, 50Hz Conversión
enchufe

Necesidad/Requisito ESB
Corriente alterna 220V , 50Hz, Max 10A

España
 15

CONCEPTOS SOA
Consecuencias:

El concepto de Servicio como intermediario y facilitador entre consumidores y
proveedores, necesita una infraestructura y organización para poder hacerlo efectivo
independientemente de los medios que se comparten que siguen teniendo su
existencia aparte.

Es una capa de virtualización que hay que añadir al ciclo de vida tradicional, no es
una sustitución

Esta virtualización necesita poder:
• Identificar los servicios
• Diseñarlos (metodología, normativa)
• Implementarlos
• Publicarlos servicios en sus diferentes fases del ciclo de vida
(repositorio/registro)
• Mantenerlos y permitir su evolución (versionado)
• Gobernarlos (Control, recursos)
• Garantizar el compromiso de ejecución (Contrato y SLA)
• Eventualmente, cambiar el modelo de financiación (cobro por uso en vez de
inversión por desarrollo)
 16

Conceptos SOA (según IBM)

Esquema general:
 17

Conceptos SOA (IBM)

Si eso no es una pipa 

 eso tampoco es SOA

La interpretación es clave: este esquema

puede interpretarse de varias maneras según
las organizaciones y los actores involucrados
¡El mapa no es el territorio! haciendo que SOA es diferentes según el
(Alfred Korzybski: General Semantics) punto de vista.
 18

CONCEPTOS SOA (IBM)

SOA: diferentes cosas para diferentes puntos de vista:

SOA reconoce la diferencia entre consumidor y proveedor del servicio,

principalmente para conseguir el desacoplamiento y la separación de
responsabilidades

Por otra parte, SOA también enfatiza la importancia del alineamiento con el
negocio para aportar valor pero no se puede olvidar tampoco la
implementación técnica y tecnológica para realizar este servicio

Eso lleva a dos puntos de vista diferentes para considerar los servicios y
lleva consecuencia para la gestión de la capa de virtualización llamada
“servicio”:
• Negocio: el foco está sobre la función de negocio, lo que significa que solo le
importa los cambios significativos de esta función y quiere poder ignorar los
detalles técnicos de su implementación: lo importante para el negocio es la
noción de “comportamiento”
• Técnico: el foco está sobre la implementación de esta función de negocio y
puede que determinados cambios técnicos impliquen cambios en la función de
negocio
 19

CONCEPTOS SOA (IBM)

Puntos de vista del proveedor del servicio:

Lo que ve y tiene que gestionar el proveedor del servicio es lo siguiente:

Model Assemble Deploy

Service
Service Assembly
Requirements Service Service Service Service Service
QoS Measurement
Design Specification Specification Specification Instance Description Contract
Service Provider Abstractions

Service Manage
Assessment
 20

CONCEPTOS SOA (IBM)

Puntos de vista del proveedor del servicio (II):

Eso se complica todavía más si se incluye el modelo de versionado:
Service
Contract
Service Service
Consumer Provider
T&C Public

Service Service
Internal
Requirements Description

Service
Design Service Instance

+?
Service Variability Measurement QoS Design Implementation Target Custom
Specification Specification Specification Specification Models Identifier Identifier Identifier
Configuration
Identifier
Deployed
B I
Behavior Interface
Specification Specification

Service Assembly
 21

CONCEPTOS SOA (IBM)

Puntos de vista del consumidor del servicio:

Para el consumidor, lo único, en principio, que necesita saber para utilizar
el servicio es la interface de llamada y una dirección (URL) para saber
donde está el servicio.
Consumer/provider pair

SD Public SD Private (SD: Service Description)

Consumer Connectivity Service

Instance Infrastructure Instance

Cuando la infraestructura de conexión es Public

simple y que no hay diferentes SLA’s por
consumidores, un único SD puede servir tanto Consumer Service
Instance Instance
para el consumidor como para el proveedor.
Sino, en general son diferentes
 22

CONCEPTOS SOA (IBM)

Puntos de vista del consumidor del servicio (II):

SOA, al crear la abstracción del servicio pretende desacoplar la función de
negocio de su implementación. Sin embargo, si el consumidor tiene que
conocer la dirección física del servicio, se vuelve a crear un acoplamiento
fuerte entre consumidor y proveedor dado que cada cambio de servidor o
de directorio donde está ubicado el servicio provocaría un cambio para el
consumidor.

Para evitar esto, se ha introducido la noción de registro donde se mantiene
el nombre del servicio y su correspondiente dirección (similar al DNS para
las URL’s de Internet)

Aunque esta medida permite preservar el desacoplamiento entre el servicio
y su instancia, el registro no termina de resolver completamente el
problema del desacoplamiento y de la virtualización del servicio por las
variantes del lado del proveedor que no tienen por qué afectar al
consumidor.
 23

CONCEPTOS SOA (IBM)

Puntos de vista del consumidor del servicio (III):

Ejemplos de variantes que no deberían afectar al consumidor:
• SLA’s diferentes para diferentes consumidores pueden obligar al proveedor del
servicio a poner varias instancias del servicio en diferentes servidores o
diferentes tecnologías para cada caso: la separación de los flujos dependiendo
de quien llama y no del objeto llamada no se puede asumir por el registro sino
por una decisión en tiempo de ejecución por una mediación que termina de
resolver donde está el servicio para este consumidor
• Versiones menores de un servicio pueden necesitar también una separación
que depende del consumidor llamante. Lo mismo con cambios de versiones
mayores donde se recomienda hacer un piloto antes de liberar la versión para
todos los consumidores
• Separación del servicio en función de políticas de seguridad, etc 9

De manera general, cualquier cambio en la implementación por parte del
proveedor que no afecte a la interface y a su comportamiento no debería
impactar al consumidor y debería haber un mecanismo que le aísle de
estos detalles : este mecanismo es el ESB: Enterprise Service Bus
 24

CONCEPTOS SOA (IBM)

Puntos de vista del consumidor del servicio (IV):

Virtualización del servicio con el ESB:
Consumer instance/intermediary instance pair Intermediary instance/service instance pair

Public Private Internal/Public Internal/Private

Consumer Connectivity Mediation Connectivity Service

Instance Infrastructure Instance Infrastructure Instance

Aquí también, aunque en principio la situación entre consumidor y

proveedor parezca simétrica, no lo es: es importante entender que la
mediación está del lado del proveedor y es responsabilidad suya:
Consumer Domain Provider Domain

Public

Consumer Mediation Service

Instance Instance Service
Instance
Service
Instance
Instance
 25

CONCEPTOS SOA (IBM)

Puntos de vista del consumidor del servicio (V):

El ESB tiene un rol importante, tanto o más que el registro, dado que
permite la virtualización del servicio desde el primer momento y en
particular cuando se empieza a versionar el servicio. Sin embargo, no tiene
que desvirtuarse al meter lógica de negocio. Solo debe efectuar
mediaciones sencillas de tipo:
• Enrutamientos
• Resoluciones de versiones
• Transformaciones de mensajes
• Conversiones de protocolos de comunicación
• Ejecución de políticas
• Seguridad

Al estar entre el consumidor y el proveedor, la tentación puede ser grande
de añadir funciones elaboradas en el ESB por la facilidad de interceptación
del mensaje pero no hay que olvidar el coste a nivel rendimiento, en
particular en la composición de servicios.
IT SOA Vision 26
Service Consumers (Composition & Orchestration)

Portals Applications/Services BPM (Workflow) EAI

Ajax, RIA, MS Biztalk
TIBCO iProcess TIBCO BW
WSRP,etc.

SOA
Governance Service Mediation Management

Business Activity Monitoring (BAM)

Runtime
Version Test
Repository Routing Transformation Policy Admin
Resolution Browser
Enforcement

Policy Monitoring
Enforcement

Alerts
ESB

Registry General Components

Security QoS Transaction Error Handling Others Logging
Life-Cycle
Management
Auditing
SLAs Messaging
Reporting
Multi-Protocol Communication Infrastructure
Billing

Reporting

Service Service Service Service

- Clustering
- Virtualization
- Grid
Service Providers

España
 27

CONCEPTOS SOA (IBM)

Implicaciones de SOA sobre la seguridad:

El uso de intercambio de mensajes y la reutilización imponen nuevos niveles de
seguridad y una reorganización de en qué sitios se tienen que hacer qué controles
de seguridad: por ejemplo en caso de composición de servicios, no tendría sentido
repetir los mismos controles en cada servicio. Sin embargo, si se utiliza solo un
servicio, tiene todo el sentido.
 28

CONCEPTOS SOA (IBM)

Consideraciones de seguridad en SOA:

 Entidades/Identidades – Usuarios, servicios

Los servicios tienen identidades

Las identidades y/o los credenciales se propagan de un servicio al otro

Los usuarios y los servicios se tienen que someter a los mismos controles de seguridad

 Limites de la organización y de la empresa

El perímetro es oscuro

Las identidades se gestionan de un frontera a la otra

Es necesario establecer relaciones de confianza que crucen las fronteras

 Composición

Es necesario garantizar que los controles de seguridad apropiados se ejecutan para cada servicio individual y
cuando se utilizan en combinaciones

 Mayor foco sobre os datos/información:

Protección de los datos en transito y al reposo

Aplicar medidas de protección consistentes

El acceso al los datos solo se puede hacer a través de aplicaciones o servicios

 Gobierno, Riesgo y Conformidad

Auditoría : por ejemplo, identificación de la entidad para determinadas transacciones
 29

CONCEPTOS SOA (IBM)

Ejemplo de propagación de Identidad de un servicio a
otro:
Customer ibm_23

jdoe
Division (s) z42

Shared
Services divb-jon mgr

Supplier ibm_empl

Outsourced jon@ibm.com
 30

CONCEPTOS SOA (IBM)

Necesidad de un Framework de Seguridad:

Para poder gestionar correctamente la seguridad en SOA en necesario
utilizar un framework que describa como se resuelven los diferentes
aspectos de la seguridad “end to end”
DMZ Application Backend Zone
Zone
HTTPS SSL
Siebel Portal
Server WS-Security
Username
Application
Token
HTTPS HTTPS (J2EE)
only WebSphere
TAM WebSphere Portal
Security Layer 1

Security Layer 2

Security Layer 4
Browser Process
WebSEAL Server
Server
CICS
Application

Web Service SSL

DataPower XS-40 WebSphere Message Broker (ESB)
Consumer
SSL
WS-Security Databases
WS-Security Username
SAML Security Assertion Token
Signing and Encryption LDAPS
only
WSRR WS-Trust
WS-Trust

WS-Trust

Security Layer 3

Security Management Zone

Tivoli Directory TFIM TAM Policy Tivoli Identity

Server Server Server Manager
 31

CONCEPTOS SOA (IBM)

Gestión del ciclo de vida:

Al añadir capas de gestión, tipos de información, actores ligados al servicio,
muy diferentes de lo que es habitual para las aplicaciones, no queda más
remedio que hacer cambios en la organización, la metodología de
desarrollo y producción para poder asimilar y gestionar los servicios.

Al gobierno tradicional de IT, se le modifica para dar cabida al gobierno
SOA.

IBM recomienda la creación de nuevos roles y la modificación de los
tradicionales para adaptarse a la vida de los servicios:

En particular, se plantea la creación de un CoE (Centro de Excelencia)
encargado de gestionar todo lo relativo a los servicios.
 32

CONCEPTOS SOA (IBM)

New Role
Existing Role
Roles nuevos y modificados: Enhanced Role
SOA Executive Sponsor
Control

Governance Leader Business Services Application Integration

Data Director
(or PMO Lead) Champion Director Director

SOA Executive Steering Committee

Manage Service Architect Program Service Registrar

Management
Center of Excellence
(CoE)

BAs Infrastructure & Software

Architects
Integration Development
Business
Service Process
Architects Service
Service Infra
Architects Service
Service Architects
Solution Architect ServiceArchitects
Designer
Analyst Developer
Service Architects Service Security Service
Business Service Analyst Service Architects
Security Architect
Service Architects ServiceArchitects
Developer
Design
Service Architects
Business Process Architect Business
Service Monitoring
Architects Service Architects
Service Tester
Developer
 33

CONCEPTOS SOA (IBM)

SOA CoE Structure - Summary  Key touch points to/from LOBs
Role Summaries  Communicates business
needs, priorities
 Sets SOA vision, principles,
policies
 Prioritizes SOA efforts; allocates  Sets SOA standards,
Executive Steering SOA funding policies
Committee  Resolves exception requests  Defines all SOA
architecture elements
Core CoE Team (Tech., application,
 Sets business data, security9)
 Provides thought
direction and Business leadership
priorities Relationshi  Harvests assets
 Authorizes funding SOA p Directors  Supports SOA
 Enforces SOA Board development and
mandate operations
 Resolves disputes Architectur  (Permanent roles)
(final) e Office

Project
 Pool of skilled CoE Sub-
resources
Teams
Teams (Project
 Executes day-to-day
SOA functions Team
 (Rotational) roles Authority)
 Develops applications using SOA
assets, guidance of the CoE
=SOA Architecture Review Board
 Ensures project-level compliance