Maestría en Ingeniería de Sistemas

Desarrollo e Integración de Sistemas
Maestría en Ingeniería de Sistemas
SOA
Escuela de Postgrado
Introducción a SOA
La Flexibilidad del Negocio Depende de la Flexibilidad de TI
La Arquitectura de TI actual es el principal obstáculo
 Complejidad
 Aplicaciones Monolíticas y con

perspectiva de Silos
 Fuentes de Información Inconsistentes
 Conexiones “alambradas”  “La Arquitectura de TI actual, tan

misteriosa como puede ser, es el
 No diseñadas para el cambio principal obstáculo que las
empresas enfrentan cuando
pretenden hacer movimientos
estratégicos.” McKinsey “Flexible IT, Better
Strategy”
3
Retos del Negocio
Productividad Agilidad y cumplimiento
Facilidad para manejo de cambios Una sola fuente de información
Colaboración Experiencia con clientes
Accesos basados en roles Tareas provistas por otros
Capacidad de respuesta y servicio Nuevas oportunidades
Expandir el acceso a las aplicaciones y

Reduccion de tiempos de transacción
sistemas
4
El Reto de TI:
Lograr que las Personas, Procesos e Información trabajen juntos, formando un
todo indivisible y se encuentre alineado a los objetivos de negocios
5
¿Por dónde empezar?
6
SOA: “Cambiando las reglas de juego”
Tal como el concepto de Internet, SOA tiene el potencial para alterar la manera en que se
desarrollan las empresas en el mercado, ya sea en competencia o colaboración.
7
Evolución de las Arquitecturas de TI
Incrementando Modularidad para Lograr Flexibilidad
Servicios
(SOA) Qué viene luego?
Gestión de
Procesos del
Negocio
EAI
FLEXIBILIDAD
Procesamiento
basado en
Mensajes
Invocación de
Subrutinas
Objetos
&
Remotos
Llamadas a
Procedimientos
Remotos
Arquitecturas
Monolíticas
Pre 50’s 70’s - 80’s - Mitad 90’s a

mitad 90’s Inicios 00’s Finales 90’s Actualmente Futuro
- 60’s mitad 80’s
8
Conceptos Clave de SOA - ¿Qué es …..
… un servicio? … orientación a
servicios?
Una tarea de negocio Una manera de integrar
repetible - ej. verificar el su negocio como
crédito del cliente; abrir servicios relacionados
una nueva cuenta y los resultados que
proveen
… Arquitectura … una Aplicación

Orientada a Servicios Compuesta?
(SOA)?
Un conjunto de servicios
Un estilo de relacionados e
arquitectura de TI que integrados que soportan
soporta la orientación a un proceso de negocio
servicios sobre SOA
9
“Mitología” SOA
 SOA no es una Revolución  SOA = Servicios Reutilizables
 SOA no es un solo producto de  Consumidores <-> Proveedores de
Software Servicios
 No hay tal cosa como  Interfaz vs. Implementación
‘Conformidad SOA’
 SOA no es acoplar servicios a una
aplicación o plataforma
específica
 SOA ≠ EAI
 SOA ≠ Servicios Web
 SOA ≠ ESB
 SOA ≠ BPEL
10
Separación de Preocupaciones
¿Qué es una aplicación?
11
¿Qué es una aplicación? Lógica Interacción
Usuario
12
Usuario
Lógica
Datos
13
Usuario
Lógica
Datos
Lógica
Integración
14
Usuario
Lógica
Datos
Lógica
Integración
Lógica
Procesos
15
Usuario
Lógica
Datos
Lógica
Integración
Lógica
Procesos
Reglas
Negocio
16
Usuario
Lógica
Datos
Lógica
Integración
Lógica
Procesos
Reglas
Negocio
Lógica
Monitoreo &
Gestión
17
Los Cimientos de SOA
Lógica
Interacción Lógica Lógica Lógica Reglas Lógica Servicios
Usuario Datos Integración Procesos Negocio Seguridad Negocio
Servicios Innovación & Optimización Negocio
Servicios TI
Servicios Interacción Servicios Proceso
Desarrollo
Servicios Información
Servicios
Gestión
Bus Servicios Empresariales
Servicios Asociados Servicios App Negocio Servicios Acceso
Servicios Infraestructura
23
Lógica Lógica Lógica Reglas Lógica Servicios
Datos Integración Procesos Negocio Seguridad Negocio
Servicios TI
Desarrollo
Servicios
Gestión
Lógica
Interacción
Usuario
24
Lógica Lógica Reglas Lógica Servicios
Integración Procesos Negocio Seguridad Negocio
Servicios TI
Desarrollo
Servicios
Gestión
Lógica
Lógica
Interacción
Datos
Usuario
25
Lógica Reglas Lógica Servicios
Procesos Negocio Seguridad Negocio
Servicios TI
Desarrollo
Servicios
Gestión
Lógica
Lógica
Interacción
Datos
Usuario
Bus Servicios Empresariales Lógica

Integración

Lógica
Integración
26
Reglas Lógica Servicios
Negocio Seguridad Negocio
Servicios TI
Desarrollo
Servicios
Gestión
Lógica
Lógica Lógica
Interacción
Procesos Datos
Usuario

Integración

Lógica
Integración
27
Lógica Servicios
Seguridad Negocio
Servicios TI
Desarrollo
Servicios
Gestión
Lógica
Reglas Lógica Lógica
Interacción
Negocio Procesos Datos
Usuario

Integración

Lógica
Integración
28
Servicios
Negocio
Servicios TI
Desarrollo
Servicios
Gestión
Lógica
Interacción
Usuario

Integración

Lógica
Integración
Servicios Infraestructura Lógica

Seguridad
29
Servicios TI
Desarrollo
Servicios
Gestión
Lógica
Interacción
Usuario

Integración

Lógica Servicios Servicios
Integración Negocio Negocio

Seguridad
30
Servicios TI
Desarrollo
Servicios
Gestión
Lógica
Interacción
Usuario

Integración

Servicios Servicios Negocio
Lógica Negocio - Transformar
Integración Crear Nuevos Activos
Activos Existentes

Seguridad
31
Modelador Negocio
Servicios TI
Desarrollo
Servicios
Gestión
Lógica
Interacción
Usuario

Integración

Activos Existentes

Seguridad
32
Modelador Negocio Tableros de Control

Servicios TI
Desarrollo
Servicios
Gestión
Lógica
Interacción
Usuario

Integración

Activos Existentes

Seguridad
33

Servicios TI
Desarrollo
Servicios
Gestión
Lógica
Interacción
Usuario

Integración
Desarrollo

Activos Existentes

Seguridad
34

Servicios TI
Desarrollo
Servicios
Gestión
Lógica
Interacción
Usuario

Integración
Desarrollo

Activos Existentes

Seguridad
35

Servicios TI
Desarrollo
Servicios
Gestión
Lógica
Interacción
Usuario

Integración
Desarrollo
Servicios Asociados Servicios App Negocio Servicios Acceso Monitoreo TI

Activos Existentes

Seguridad
36
Cada uno de los productos juega un rol clave para entregar la plataforma …
Capacidades “Middleware” Robusto Conectado de una Manera Abierta y Flexible
Servicios TI
Desarrollo
Servicios
Gestión
37
SOA en Acción – es Todo sobre el Negocio
División
38
Cliente
División
Cambio: Captura de la Orden

por el Cliente
39
Cliente
División
Servicios
Compartidos
Cambio: Servicios Compartidos – Mercadotecnia,

Facturación, Cuentas por Cobrar
40
Cliente
División
Servicios
Compartidos
Proveedor
Cambio: Proveedor Maneja Inventario (VMI)

41
Cliente
División
Servicios
Compartidos
Proveedor
Tercerizado
Cambio: Envíos por FedEx, DHL o UPS

42
Cliente
División
Servicios
Compartidos
Proveedor
Tercerizado
Cambio: Cobranza Tercerizada

43
Cliente
División
Servicios
Compartidos
Proveedor
Tercerizado
Cambio: Optimización de Proceso

44
Tres Elementos Claves de SOA
Componetización
Convertir las aplicaciones
empresariales y la información
en componentes reusables
Valor: extensión del ROI, más
preciso modelado de las
Consumidor
Consumer
funciones del negocio Arquitectura Procesos Negocio
Estandarización
Usas estándares abiertos de la
industria para comunicar y
coordinar entre componentes
Valor: Independencia de la Service Architecture
Arquitectura Servicios
Implantación, Flexibilidad del

Proveedor
Proveedor
Provider
Gestión Procesos del Negocio
Orquestar componentes de
negocio estándar (servicios) en
procesos de negocio Arquitectura Componentes
A
Valor: Correspondencia uno-a-
uno con el negocio, TI se
convierte en el habilitador del
cambio
46
Fases del Ciclo de Vida de SOA
Ensamblar los
componentes necesarios
Especialista
de Integración
para soportar los procesos
optimizados Administrador
de Sistemas
Desplegar los
procesos
optimizados en su
Analista de entorno operativo
Negocio
Modelar y analizar
los procesos de
negocio de
principio a fin Operador de
Sistemas
Gestionar los
procesos
Controlar los
desplegados
procesos para
alinear TI con el Operador
Centro de del Negocio
negocio
Excelencia
48
Los Puntos de Entrada a SOA Definen la Forma de Empezar
Ya sea Centrado en el Negocio u Orientado a TI
 Habilitar la interacción
humana y de procesos con
 Entregar información
confiable en el
1 niveles de servicio consistentes
contexto del negocio

para permitir la 2
 Lograr mayor eficiencia
innovación
3 y efectividad a través
de innovación del
modelo de negocio
 Proteger la inversión  Potenciar activos

habilitando servicios existentes para
a partir de activos 5 mejorar la agilidad del
base existentes 4 negocio
50
¿Por qué importa la Gobernabilidad en SOA?
Sin Gobernabilidad Con Gobernabilidad
Un montón de servicios La promesa de SOA
51
Resumen
 SOA es un deporte de equipo:

 La gente de Negocio y la de TI deben trabajar
codo con codo
 Los Cimientos para SOA son críticos:
 Establezca una infraestructura y arquitectura
empresarial, basado en los principios definidos
para permitir su viaje SOA
 Establecer un Proyecto como punto de entrada a
SOA es importante
 Evite el modelo “Big Bang”
 La Gobernabilidad es obligada para el éxito de este
viaje SOA
52
Fundamentos SOA
• Objetivos y beneficios estratégicos.
• Terminología y conceptos.
• Ciclo de vida de los servicios.
Objetivos y Beneficios Estratégicos
Los siete objetivos estratégicos de SOA
• Incrementar la interoperabilidad.
• Incrementar la federación.
• Incrementar las opciones de diversificación de fabricantes y

vendedores de software.
• Incrementar el alineamiento entre negocio y tecnología.
• Incrementar el ROI.
• Incrementar la agilidad de la organización.
• Reducir la carga de TI.
Los siete objetivos y beneficios estratégicos SOA
Objetivos estratégicos y objetivos tácticos
• Todos los objetivos son estratégicos debido a que proveen beneficios a largo
plazo para la TI de la empresa.
• De otro lado, los objetivos tácticos están enfocados en cumplir requerimientos

inmediatos en el corto plazo.
• La naturaleza estratégica de la computación orientada a servicios es una de sus

características distintivas.
• Esto contrasta con la naturaleza más táctica del desarrollo de aplicaciones

tradicional basado en silos.
Incrementar la interoperabilidad
• La interoperabilidad representa la habilidad que tienen los programas de

software para interactuar e intercambiar datos.
• La integración representa el esfuerzo necesario para conseguir interoperabilidad

entre programas de software.
• Un esfuerzo de integración es usualmente necesario cuando los programas de

software no son compatibles y por lo tanto no son interoperables.
Incremento de la interoperabilidad
• Un objetivo de SOA es establecer interoperabilidad nativa o intrínseca entre

servicios para reducir la necesidad de integración.
• Esto significa que los servicios deben ser diseñados para ser compatibles e
interoperables, independientemente de cuando y por quien fueron desarrollados.
• Como resultado, la integración como un concepto empieza a debilitarse cuando

la orientación a servicios es ampliamente aplicada.
Incrementar la interoperabilidad
Incrementar la federación
• La federación se refiere a la unión de entornos diferentes manteniendo una gestión

independiente.
• SOA conduce al establecimiento de una perspectiva federada en una organización a través
del despliegue de servicios estandarizados y ensamblables.
• Cada servicio establece una interface técnica estandarizada o endpoint que representa un
segmento de la empresa expresada de una manera consistente.
• SOA fomenta el establecer una perspectiva federada de la empresa a través de los servicios
compuestos (ofrecen un interfaz estándar hacia el cliente uniendo servicios de diferente
tecnología y sistemas).
• Lo importante aquí es que este servicio compuesto es totalmente estándar y no depende de
la casuística de los sistemas que tiene por debajo y de los que depende. Por ejemplo, no
utiliza la nomenclatura de campos específica el backend al que accede.
Incremento de la Federación
Incrementar las opciones de diversificación de
fabricantes y vendedores de software
• La diversificación de fabricantes y vendedores de software representa la opción

de remplazar o extender la empresa con nuevas tecnologías.
• Esto puede conseguirse por diseñar SOA de manera alineada pero también
neutral a fabricantes y vendedores de software, definiendo los servicios con
niveles adecuados de abstracción.
• La diversificación de fabricantes y vendedores de software no es necesariamente

lo mas recomendable.
Incrementar las opciones de diversificación de
fabricantes y vendedores de software
Incrementar el alineamiento entre negocio y
tecnología
• Desde el punto de vista de negocios se debe ver el software de la empresa como

un conjunto de servicios de alto nivel que responden a una necesidad concreta
de negocio como “dar de alta cliente” o “calcular tarifa del producto X”.
• Estos servicios se podrán combinar para dar lugar a nuevos servicios, apoyar a
un proceso de negocio, etc.
• Desde el punto de vista de tecnología, los servicios son la encapsulación de
cierta lógica de negocios en un sistema concreto. Una abstracción de un
concepto de negocio.
• Con estos servicios de negocio, con un contrato bien definido y lo más
desacoplado posible del resto de servicios se podrá responder con agilidad a los
continuas peticiones de negocio.
Incrementar el alineamiento entre negocio y
tecnología
• Uno de los medios fundamentales de posibilitar el alineamiento de negocios y

tecnología es a través de la definición y creación de servicios de negocio.
• Al aplicar las prácticas de análisis y diseño orientado a servicios, la lógica de

negocios puede ser dividida en servicios de negocio flexibles que pueden ser
repetidamente mejorados y combinados para responder continuamente a los
cambios de negocio.
Incrementar el alineamiento entre negocio y tecnología
Incrementar el ROI
• El ROI representa la recuperación del dinero invertido en la adopción de SOA, ya

sea como nuevas ganancias, como ahorro de costes o las dos cosas a la vez.
• Esto se logra en primer lugar con lo reutilización de los servicios. Si hacemos un

servicio y lo usamos n veces, estaremos reduciendo significativamente el coste
total.
Incrementar el ROI
Incrementar la agilidad de la organización
• La agilidad en implementar nuevos servicios y soluciones de

negocio, ya que la empresa podrá poner el producto más
rápido en el mercado minimizando el coste de oportunidad de
estar meses esperando por un desarrollo de software y que se
adelante la competencia.
• También representa la capacidad de cambiar una solución TI

rápidamente, por ejemplo, cambiar un módulo de gestión de
clientes por otro. Sin el desacoplamiento que proclama SOA,
esto seria imposible, y al cabo de los años tendríamos una TI
atrofiada, incapaz de hacer ningún cambio.
Incrementar la agilidad de la organización
Reducir la carga de TI
La aplicación consistente de SOA resulta en una TI con:
• Mínimo desperdicio y redundancia.
• Menor tamaño y costo operacional.
• Reducido overhead asociado con su gobierno y evolución.
Una TI con estas características puede beneficiar a una organización a través del
incremento en la rapidez de respuesta y efectividad en costos.
Esto tiene varias vertientes: reducir el gasto y la redundancia de programas y
aplicaciones, reducción del coste operacional. En definitiva, hacer del desarrollo de
software algo más racional y eficiente.
Reducir la carga de TI
Terminología y Conceptos
SOA
• La arquitectura orientada a servicios representa un modelo arquitectural que

tiene como objetivo mejorar la agilidad y efectividad en costos de una empresa
mientras reduce la carga de TI.
• Esto se cumple mediante el posicionamiento de los servicios como medio

principal a través del que la lógica de negocios es representada.
• SOA soporta orientación a servicios en la realización de los objetivos

estratégicos asociados con la computación orientada a servicios.
SOA
Otra definición:
SOA es un modelo de arquitectura tecnológica distribuida con diversas
características que soportan la realización de orientación a servicios.
Las características fundamentales de SOA son:
• Es conducida por el negocio
• Es neutral a los fabricantes y vendedores de software
• Es centrada en la empresa
• Es centrada en la composición
Impulsada por el negocio
• Las arquitecturas tecnológicas tradicionales son

frecuentemente desarrolladas en alineamiento con el estado
actual de un negocio, pero no son capaces de mantenerse
alineados con la forma como los negocios se desarrollan.
• Cuanto más desincronizados están el negocio y la tecnología,

mas disminuye el cumplimiento de los requerimientos de
negocio.
• A veces esto llega al punto de requerir una nueva arquitectura

tecnológica.
Impulsada por el negocio
Neutral a los fabricantes y vendedores de
software
Las arquitecturas tecnológicas
basadas en fabricantes están
generalmente limitadas a la
hoja de ruta de su plataforma.
Esto reduce las opciones de

aprovechar las nuevas
tecnologías liberadas en
plataformas de otros
fabricantes y puede llevar a la
necesidad de remplazar la
implementación.
Centrada en el negocio
• Una arquitectura tecnológica orientada a servicios debe ser

centrada en el negocio brindando soporte de servicios que son
reusados participando en la automatización de diferentes
tareas y procesos de negocios.
Centrada en el negocio
Centrada en la composición
• Una arquitectura tecnológica orientada a servicios debe ser
centrada en la composición en soporte de servicios que
puedan ser usados en una variedad de diferentes
composiciones.
• A diferencia de paradigmas previos de computación

distribuida, SOA enfatiza el diseño de programas de software
no sólo como recursos reusables sino como recursos flexibles
que formen parte de diferentes estructuras de soluciones
orientadas a servicios
Centrada en la Composición
Tipos de Arquitectura Orientada a Servicios
Orientación a Servicios
La orientación a servicios es un paradigma de diseño que
conduce a la creación de unidades de lógica de solución que
son individualmente formados de manera que puedan ser
colectivamente y repetidamente utilizadas en apoyo del
cumplimiento de un conjunto específico de objetivos
estratégicos y beneficios asociados con SOA y computación
orientada a servicios.
La lógica de solución diseñada en conformidad con orientación a

servicios puede ser calificada como orientada a servicios y las
unidades de lógica de solución orientada a servicios son
conocidos como servicios.
Servicios
• Un servicio es la unidad fundamental de lógica orientada a

servicios.
• Una unidad de lógica de solución es clasificada como un

servicio cuando la orientación a servicios ha sido aplicada en
una medida significativa.
• Las soluciones orientadas a servicios son generalmente

comprendidas de múltiples servicios que forman una
composición de servicios.
Servicios
• Los servicios son los bloques de construcción básicos de una
plataforma de computación orientada a servicios.
• Los servicios son diseñados de una manera muy específica,

según el enfoque de diseño de orientación a servicios.
• Los servicios son entregados de acuerdo a un ciclo de vida

específico llamado «Ciclo de Vida del servicio de entrega»
(Service Delivery Lifecycle).
• Debido a la naturaleza centrada en el negocio de la

orientación a servicios y SOA, los servicios pueden ser
clasificados como recursos del negocio.
Servicios
Entre las principales características de los servicios se pueden indicar
las siguientes:
• Granularidad.
• Diseño de contratos.
• Diseño agnóstico vs. diseño no agnóstico.
• Encapsulamiento de sistemas heredados.
• Seguridad.
• Gobierno.
Contratos de Servicio
• Un contrato de servicio expresa meta información de un

servicio y establece los términos del mismo (los
requerimientos para la invocación e interacción con el
servicio).
• Para que un consumidor de servicios pueda acceder e

interactuar con un servicio, este debe cumplir con los
requerimientos del contrato de servicio.
• La parte fundamental de un contrato de servicio es su

interface técnica, la que constituye el «Contrato de servicio
técnico» (Technical service contract).
• Un contrato de servicio puede estar además constituido por un
«Acuerdo de niveles de servicio» (Service Level Agreement o
SLA) que describe características adicionales de calidad del
servicio, comportamiento y limitaciones.
• La manera en que los servicios son diseñados y como existen

físicamente depende de la tecnología de implementación
usada para construir el servicio.
• Para la orientación a servicios, el diseño y estandarización del
contrato de servicio es de suma importancia, al punto que
existe un principio de diseño dedicado a la definición
estandarizada de contratos llamado «Estandarización de
Contratos de Servicio».
• La creación de contratos de servicio estandarizados es un

requerimiento clave para lograr las metas estratégicas de
incremento de la federación e incremento de la
interoperabilidad intrínseca.
Consumidores de Servicio
• Cuando un programa invoca e interactúa con un servicio es
calificado como consumidor de servicio.
• Este termino se refiere al rol temporal en tiempo de ejecución

asumido por un programa en el momento en que este está
participando en un intercambio de datos con un servicio.
• Un consumidor de servicio puede o no ser otro servicio.
• La habilidad de un servicio de invocar (consumir) a otro

servicio forma la base de la composición de servicios.
Consumidores de Servicio
Cualquier programa de software capaz de invocar e interactuar con un
servicio puede ser considerado un consumidor de servicio.
Capacidades de Servicio
• Un servicio puede tener una o más capacidades.
• Las capacidades de un servicio pueden ser expresadas en un

contrato de servicio.
• Un consumidor de servicio frecuentemente invocará una capacidad

específica, lo que significa que el consumidor sólo invocará un
subconjunto de la funcionalidad que un servicio ofrece
• El término capacidad de servicio es comúnmente usado en la etapa

de modelado de servicios.
• La funcionalidad asociada con una capacidad determinada puede

variar en su alcance.
Capacidades de Servicio
• Para mantener el rendimiento del servicio lo mejor posible,
tenemos que evaluar la capacidad del servicio en términos de
alta disponibilidad, rendimiento y consumo de recursos.
• Por otra parte, cuando los servicios evolucionan y se
expanden, también tenemos que definir la capacidad de la
plataforma, incluido el bus de servicios empresariales, la
mensajería del bus, y otras plataformas de apoyo como la
base de datos.
• La planificación de la capacidad de un sistema basado en
SOA es un paso obligatorio para mantener el sistema
funcionando de la mejor forma. Se trata de dos actividades
principales que son la planificación de la capacidad de los
servicios, y la planificación de la capacidad de la plataforma.
Composición de Servicios
• Una composición de servicios es un conjunto de servicios
colectivamente integrados para automatizar una particular
tarea o proceso de negocios.
• Para ser considerada una composición, es necesario contar al

menos con dos servicios participantes más un iniciador de la
composición. De no ser así la interacción de los servicios sólo
representa un intercambio punto a punto.
• La composición de servicios es muy importante para el éxito
de una iniciativa SOA porque los beneficios estratégicos de
incremento del ROI e incremento de la agilidad de la
organización dependen de la habilidad para componer y
recomponer servicios.
• Para lograr estos objetivos se requiere que los servicios sean

diseñados con la habilidad inherente de ser miembros
efectivos de composición. Mucha de la orientación a servicios
es dirigida hacia lograr este objetivo de diseño.
• Service Composition (composición de servicios) es un término
que describe la manera de como enlazar servicios. El término
también se denomina Web Service Composition.
• Se distinguen dos maneras de combinar servicios: orquestación y
coreografía.
• Una composición de servicios puede contener los dos tipos. Estas
dos son formas estáticas de componer servicios, porque la
secuencia de la ejecución está determinada en algún archivo.
• Existe también la idea de componer servicios de forma dinámica
sin determinar toda la ejecución antes. Si la descripción de los
servicios contiene su semántica en forma procesable para
máquinas, un proceso podría decidir cual servicio invoca después
de que haya empezado.
Entre los puntos comunes de diseño de composición de servicios
tenemos:
• Manejo de estado de actividad en tiempo de ejecución
• Transacciones cross-servicios
• Intercambio confiable de datos
• Requerimientos de seguridad
• Evitar la transformación
• Demandas de performance
Inventario de Servicios
• Un inventario de servicios es una colección de servicios
complementarios independientemente estandarizados y
gobernados dentro de un límite que representa una empresa
en su totalidad o bien un segmento significativo de una
empresa.
• Cuando una organización tiene múltiples inventarios de

servicios, cada inventario recibe el nombre de inventario de
servicios de dominio.
• Idealmente todos los servicios son creados como parte del
mismo inventario de servicios de la empresa.
• En grandes organizaciones, la estandarización a lo largo de

toda la empresa puede ser muy difícil de obtener. En este
caso puede ser necesario construir inventarios de servicios de
dominio.
• Modelos de inventarios de servicio son generalmente definidos

anticipadamente al inicio de la fase de análisis
• Parte de esta fase de análisis es enfocada en evitar la

redundancia de lógica entre servicios de un inventario en un
esfuerzo por obtener la normalización de servicios.
Inventario de Servicios de Dominio
Múltiples inventarios de
servicios pueden ser creados
para una empresa.
El alcance de cada uno

representa un bien definido
dominio de la empresa
frecuentemente asociado a un
dominio de negocio.
Dentro de cada dominio, los

inventarios de servicios se
estandarizan y gobiernan
independientemente.
El diseño de un inventario de servicios comúnmente incluye:
• Ámbito y límites
• Estandarización de servicios
• Escalabilidad
• Plataformas de ejecución
• Infraestructura
• Gobierno
• Los objetivos estratégicos y beneficios de la computación orientada a
servicios son realizados dentro de los límites de un inventario de
servicios.
• La dinámica fundamental que un inventario de servicios debe

soportar es la composición y recomposición de servicios.
• Para conseguir esto el inventario mismo debe ser soportado por

tecnologías, plataformas e infraestructuras adecuadas.
Computación Orientada a Servicios
• La emergencia de la Computación Orientada a Servicios (del
inglés Service - Oriented Computing) como un nuevo
paradigma de computación sitúa a los servicios como
componentes de software fundamentales, expuestos a través
de interfaces en red, neutrales a plataformas y lenguajes de
programación, y que permiten la composición de aplicaciones
distribuidas, posiblemente complejas, a partir de componentes
débilmente acoplados.
• La Computación Orientada a Servicios conlleva la promesa
visionaria de reducir la complejidad y los costes del software,
acelerar el time-to-market, mejorar la fiabilidad y aumentar la
accesibilidad de los usuarios a los servicios ofrecidos por la
empresa y el gobierno.
• Para hacer realidad la promesa SOC se requiere del diseño
de Arquitecturas Orientadas a Servicios (SOA) y del desarrollo
del correspondiente middleware que permita el desarrollo de
aplicaciones distribuidas más sencillas y baratas para soportar
prácticamente cualquier proceso de negocio en cualquier
estructura organizativa o contexto de usuario.
• Los últimos avances en Cloud Computing han mostrado el
potencial de desarrollar la orientación a servicios hasta límites
insospechados. Con una tecnología de servicios y de
plataforma cada vez más poderosa y sofisticada, las
soluciones orientadas a servicios pueden alojarse,
virtualizarse, distribuirse y escalarse a niveles sin
precedentes.
La computación orientada a servicios esencialmente representa un tipo
especializado de computación distribuida.
Ciclo de vida de la entrega de servicios
(Service Delivery Lifecycle)
Delivery de Proyectos SOA
Previo al comienzo de una iniciativa SOA, un enfoque de
delivery del proyecto necesita ser elegido para organizar mejor
todo el ciclo de vida.
Existen tres enfoques comunes:

• Top-down
• Bottom-up
• Agile (o meet-in-the-middle)
En estos, alguna medida de enfoque top-down es usualmente

requerido para poder incorporar niveles significativos de
análisis de servicios y de inventarios de servicios.
Fases Principales del Ciclo de Vida de Delivery
de Servicios
• Análisis Orientado a Servicios
• Modelado de Servicios
• Diseño Orientado a Servicios
• Desarrollo de Servicios
• Implementación de Servicios
Posteriormente a estas fases continúan las propias al gobierno

de servicios.
Ciclo de Análisis de Inventario de Servicios
El análisis del inventario
de servicios como parte
del enfoque top-down
consiste de un ciclo
iterativo durante el cual
el modelo de inventario
de servicio es
incrementalmente
definido como resultado
de sucesivas iteraciones
de pasos que incluyen el
análisis orientado a
servicios.
Análisis Orientado a Servicios
• SOA hace énfasis en una relación directa entre el análisis
de inteligencia de negocios y los servicios que finalmente
representan e implementan la lógica de negocios.
• Esto resulta en el requerimiento de una única forma de

análisis que necesita ser completada antes del diseño de
servicios individuales.
• El análisis orientado a servicios establece un proceso a

través del cual la orientación a servicios es aplicada a la
lógica de la automatización de negocios y a los
requerimientos.
Modelado de Servicios
• El modelado de
servicios es la parte de
la fase de análisis en la
que los servicios y sus
capacidades son
conceptualizados
previamente a su
definición y desarrollo
físico real.
• Los servicios
conceptualizados son
llamados servicios
candidatos
Enfoque Centrado en el Negocio
• Gran parte del modelado de servicio está enfocado en la
encapsulación y abstracción de la lógica de negocios.
• El concepto de servicio de negocios necesita ser entendido

y requiere de colaboración cercana entre los profesionales
de tecnología y negocios.
• La naturaleza iterativa del análisis orientado a servicios

permite que los servicios de negocio candidatos sean
continuamente refinados antes de la fase de diseño.
• Quienes participan en el modelado de servicios con

frecuencia terminan involucrados en el eventual gobierno de
servicios.
Proceso de Diseño Orientado a Servicios
• El diseño orientado a servicios continúa desde el punto

donde el análisis orientado a servicios termina.
• Existe un proceso de diseño orientado a servicios para cada
modelo de servicios.
• Los servicios candidatos son el punto de entrada para estos
procesos.
Diseño – Primero el Contrato
• La orientación a servicios pone

énfasis en estandarizar y
desacoplar el contrato técnico de
cada servicio.
• El diseño por lo tanto es basado en
un enfoque de primero el
contrato evitando los
desarrolladores el uso
herramientas de auto generación.
Evitando la transformación
• Uno de los objetivos principales del diseño orientado a servicios. Es el
evitar el uso de tecnologías de transformación en soporte del fomento
de la interoperabilidad por defecto.
• Esto se apoya fuertemente en la estandarización de los contratos de

servicio.
Gobierno del Inventario de Servicios
El gobierno puede incluir muchas cosas, sin embargo desde una
perspectiva de delivery, la eventual carga que requiere la fase de
gobierno de servicios es una consideración primaria.
Como una regla general, aplica lo siguiente:
• El análisis inicial como parte de un esfuerzo top-down, está

enfocado en la creación de un inventario de servicios
estandarizados, resultando en una reducción de la carga en la fase
de gobierno.
• El enfoque bottom-up resulta en menos impacto inicial, pues no se

realiza un análisis de inventario, en cambio posterga la carga e
impacto a la fase de gobierno.
Gobierno del Inventario de Servicios
• Cada estrategia
tiene sus ventajas
y desventajas.
• La clave es
siempre tomar en
cuenta la carga de
gobierno cuando
se elige un
enfoque.
Conceptos de
tecnología SOA
XML – Una Breve Historia
• El Extensible Markup Languaje (XML) ganó popularidad

durante el auge del eBusiness a finales de la década de los
90, cuando los lenguajes de guiones (scripts) hicieron viable
los negocios vía internet.
• A través del uso de XML los desarrolladores fueron capaces
de adjuntar significado y contexto a cualquier pieza de
información transmitida a través de los protocolos de internet.
• XML no sólo es usado para representar los datos de una
forma estandarizada, el lenguaje en si mismo se convirtió en la
base de una serie de especificaciones adicionales.
XML – Introducción
• La estandarización de la representación de los datos usando

XML permite la creación de una arquitectura de representación
de datos en XML.
• Es la forma más común de arquitectura de representación de

datos en SOA .
• Esto establece una capa base sobre la cual se construye la

capa de servicios.
• La capa de servicios está comúnmente comprendida de

endpoints establecidos por contratos de servicio.
XML – Introducción
• XML es metadata.
• Un documento XML
contiene datos
reales y la
metadata XML que
describe los datos.
XML – Conceptos Básicos
• Al igual que HTML, XML fue desarrollado por el World Wide Web
Consortium (W3C).
• Como con HTML, XML es formado usando elementos.
• A diferencia de HTML, los elementos no son predefinidos.
• Como consecuencia los elementos pueden ser personalizados.
• Los elementos representan metadata y son usados para asociar la

metadata con los datos del documento.
• Los elementos son conocidos como “tags“ cuando son

implementados.
HTML
<b>Luis</b>
Sabemos que “Luis“ está en negrita debido al tag <b> pero
no sabemos que significado tiene la data
XML
<nombre>Luis</nombre>
Sabemos que “Luis“ representa un nombre debido al tag
<nombre>
El core de las tecnologías XML consiste de:
• El XML Schema Definition

Language (XML Schema)
• XML Style Sheet
Language
Transformations (XSLT)
• XML Query Language
(XQuery)
• XML Path Language
(Xpath)
XML Schema Definition
Language (XML Schema)
XML Schema – Introducción
• Un conjunto predefinido y relacionado de elementos XML representa

un vocabulario.
• Los vocabularios pueden ser creados para describir tipos específicos

de documentos de negocio, tales como ordenes de compra o
facturas.
• Los vocabularios pueden ser formalmente definidos usando un

lenguaje de definición de esquemas.
• Un lenguaje de esquemas esencialmente provee un medio de

expresar la definición de un modelo de datos para un vocabulario.
Los esquemas protegen la integridad de los datos de un

documento XML mediante la definición de:
• Estructuras.
• Reglas de
validación.
• Restricciones en
los tipos de datos
• Relaciones entre
los elementos.
• Los esquemas XML son comparables a modelos de datos de bases de
datos, y los documentos XML comparables a registros de bases de datos
• A diferencia de la
representación de
datos en BD
relacionales, los
documentos XML
necesitan estar
basados en un tipo
de estructura de
árbol o directorio
• Existen numerosos lenguajes de esquemas XML. Los dos más

comunes son:
• Document Type Definitions (DTD)

• XML Schema Definition Language
(XML Schema o XSD)
• El lenguaje XML Schema fue creado por la W3C y es de lejos

el más usado en las soluciones orientadas a servicios.
• XML es usado intrínsecamente por muchas especificaciones
de servicios web para definir los modelos de datos por los
correspondientes lenguajes de especificación.
• Los esquemas XML son usados también junto con WSDL para
establecer el modelo de datos para los contratos de los
servicios web basados en SOAP.
• Un esquema XML
usualmente existe
como un archivo
separado en el
cual el modelo de
datos para un tipo
específico
(vocabulario) de
documento XML
es definido.
• Múltiples documentos XML pueden enlazarse o apuntar a la
misma definición de esquema XML.
• Un documento XML puede apuntar a múltiples definiciones

de esquemas XML.
• Los esquemas XML pueden también estar embebidos dentro

de documentos XML.
• Por lo común, los esquemas XML existen como archivos

separados.
XML Schema – Tipos
• Una de las más importantes características de los esquemas

XML es su amplio rango de soporte para tipos de datos
neutrales a los vendors.
• Cuando se crea una arquitectura de representación de datos

para SOA, estos tipos de datos pueden cubrir diferentes
fuentes de datos con una capa de representación de datos
federada y estandarizada.
• Elementos definidos dentro de esquemas XML que contienen
elementos hijos o atributos tienen tipos complejos.
• Elementos que sólo contienen valores tienen tipos simples.
• Todos los atributos tienen tipos simples porque ellos sólo

contienen valores.
• Los tipos simples son usados para referenciar a los tipos

predefinidos de datos.
• Los tipos complejos son típicamente

Dirección
constructores o mini jerarquías de Calle
elementos que pueden representar un Nombre
gran conjunto de datos relacionados. Número
Ciudad
• Cuando se crean contratos de servicio, Estado
es usual que tipos complejos Código
representen la estructura completa de
mensajes de entrada y salida. Un constructor de tipo
complejo de Dirección
XML Schema – Namespaces
• Los namespaces son una parte importante de los lenguajes
basados en XML que esencialmente establecen un medio de
creación de identificadores únicos.
• Cada lenguaje XML (incluyendo XML Schema, WSDL, SOAP, WS-
Addressing, WS-BPEL, etc.) tiene un namespace predefinido
asociado con el.
• De esta manera, cuando estos elementos son mezclados unos con
otros en el mismo documento XML, el entorno de ejecución puede
determinar a cual lenguaje pertenece cada elemento.
• Como resultado, múltiples elementos dentro del mismo
documento XML pueden ser parseados y validados usando
diferentes procesadores.
• Una declaración de namespace establece un prefijo:

ABC = “123“
En este caso, ABC es un alias usado para representar el
namespace 123.
• El prefijo es asociado a los elementos de la siguiente manera:

ABC : factura
El elemento factura es asociado con el namespace 123 porque
tiene el prefijo ABC.
• Los esquemas XML también proveen soporte para namespaces que
permiten a los autores de los esquemas diferenciar entre vocabularios
XML similares.
• Los valores de namespaces son tradicionalmente URL’s, pero no tienen

que necesariamente serlo.
• Los namespaces son especialmente importantes cuando trabajan con

definiciones de WSDL porque estos documentos usualmente requieren
que coexistan elementos de WSDL, SOAP y esquemas XML, junto a
elementos adicionales de vocabularios XML a medida.
XML Schema – Conceptos Básicos
• Una definición de esquema XML es
capaz de contener múltiples
documentos de esquema.
• Esto permite la creación de

esquemas modulares que pueden
ser combinados.
• El uso de módulos de esquema

promueve el reuso y la creación de
esquemas estandarizados.
Cada esquema puede ser dinámicamente
extendido con constructores
suplementarios.
Partes de la definición de esquema pueden

ser redefinidos (overridden) por otras
definiciones de esquema.
Retos comunes con esquemas XML y SOA:
• Los esquemas XML son frecuentemente tareas, procesos, o

soluciones especificas.
• Algunas características avanzadas de los esquemas XML no

son soportados con WSDL.
• Los esquemas XML pueden ser complejos y verbosos.
• DTD’s están aún en uso sobre todo por sistemas heredados
XSLT, XQuery y XPath
XSLT
• Existe una frecuente necesidad de que la estructura (modelo de

datos) de un documento XML sea dinámicamente cambiado.
• El requerimiento más común para esto es cuando dos servicios o

aplicaciones necesitan intercambiar el mismo tipo de datos, pero
cada una usa un diferente esquema XML (modelo de datos).
• Para superar esta incompatibilidad, la data debe ser transformada.
XSLT
• Debido a que XML provee una separación de contenido y

estructura, la estructura de salida de un documento XML
puede ser separadamente controlada.
• Una tecnología basada en XML llamada XSL

Transformations (XSLT) es el principal medio de convertir
dinámicamente la estructura de documentos XML.
• El uso de XSLT facilita los requerimientos de transformación

de datos.
XSLT
• Lógica XSLT; llamada

XSLT Stylesheets; existe
dentro de los documentos
XML.
• Un mismo XSLT Stylesheet

puede ser usado por varios
documentos XML.
• XSLT es otro lenguaje

desarrollado por W3C
XSLT
• XSLT Stylesheets mapea una estructura de esquema hacia

otra.
• XSLT Stylesheet lleva a cabo esta lógica de mapeo en tiempo
de ejecución
para transformar
las estructuras
de datos.
• Esto permite a los
servicios superar la
disparidad de la
representación de
datos
XSLT
• El conjunto de características de XSLT facilitan la manipulación, el

ordenamiento y el filtrado de los datos de los documentos XML
para proveer vistas alternativas e informes para cualquier
escenario de transformación de documentos.
XSLT
• Aunque XSLT es una tecnología probada y establecida usada para
posibilitar la interoperabilidad, es una tecnología que tratamos de
evitar utilizar cuando diseñamos servicios para SOA.
• Las capas de transformación introducidas por XSLT Stylesheets

requieren esfuerzos de desarrollo, complejidad de diseño y
sobrecarga en la performance en tiempo de ejecución.
• Todo esto puede ser evitado por la estandarización de la

definición de los esquemas XML.
XQuery
• La especificación XQuery
establece un lenguaje de
consulta de datos
completo, diseñado
específicamente para
documentos XML.
• XQuery es a
documentos XML lo
que SQL es a bases de
datos relacionales.
• Alguna sintaxis XQuery
es derivada de SQL.
XPath
• Los elementos o valores de los elementos dentro de los documentos
pueden ser buscados y filtrados usando funciones XPath.
• XPath realiza el direccionamiento de los árboles de documentos, de

manera similar a como los paths file tradicionales hacen referencia
a estructuras de directorio o como path virtuales hacen referencia a
estructuras de Web sites internas.
• De esta manera, las direcciones XPath pueden ser relativas o

absolutas.
XPath
• Las sentencias XPath son

llamadas expresiones.
• Las expresiones XPath son

usualmente incrustadas
dentro de XSLT Stylesheets
y módulos XQuery.
• XPath es uno de las pocas

especificaciones no XML que
permanecen.
Servicios basados en Web y
Arquitectura Distribuida
Tradicional
Nomenclatura de Servicios basados en Web
• Tanto los servicios REST como los servicios Web basados en

SOAP son algunas veces colectivamente referidos como
servicios Web o servicios basados en Web.
• Los servicios REST son frecuentemente llamados servicios

RESTful.
• Para nuestro estudio los términos servicio Web y servicio

Web basado en SOAP son sinónimos y el término servicio
REST es usado en vez de servicios RESTful.
Servicios basados en Web y Arquitectura Distribuida
Tradicional
En las soluciones distribuidas tradicionales:
• La lógica de solución es descompuesta en componentes.
• Los componentes existen como unidades auto contenidas de

software capaces de ser compuestas.
• La tecnología de desarrollo de componentes es

generalmente propietaria.
• La tecnología de comunicación de componentes es

generalmente propietaria.
Servicios basados en Web y Arquitectura Distribuida Tradicional
• Al igual que los componentes, los servicios basados en Web
son unidades auto contenidas de lógica de solución capaces
de ser compuestas.
pueden ser desarrollados usando tecnología propietaria y la
lógica de solución subyacente puede o no ser basada en
componentes.
• A diferencia de los componentes, los servicios basados en
Web son frecuentemente diseñados para comunicarse con
tecnologías no propietarias basadas en estándares de la
industria
• Los componentes en aplicaciones distribuidas tradicionales pueden

residir en uno o más servidores físicos.
• Los componentes en el mismo servidor se comunican típicamente

usando API’s propietarias.
• Los componentes que necesitan comunicarse a través de diferentes

servidores lo hacen generalmente usando la tecnología de Remote
Procedure Call (RPC).
Los protocolos RPC posibilitan la comunicación remota de componentes a
través del uso de proxy stubs que representan componentes remotos en
servidores locales.
son capaces de comunicarse a través de los límites de los
servidores.
• A diferencia de los componentes, los servicios basados en
Web generalmente no usan API’s propietarias o tecnologías
RPC para comunicación remota.
• Los servicios
basados en
Web confían
en el
intercambio de
datos definido
por sus
contratos de
servicio.
Servicios basados en Web y SOA
• Una arquitectura orientada a servicios es una forma de

arquitectura distribuida en la que la lógica de solución es
expuesta a través de contratos de servicio estandarizados.
• Diferentes medios de implementación de servicios pueden
usar diferentes tecnologías o estándares de la industria para
definir contratos de servicios.
• Por ejemplo, los servicios Web basados en SOAP utilizan el
lenguaje WSDL para expresar contratos de servicio, por otro
lado los servicios REST confían en el uniform contract
provisto por HTTP.
Servicios basados en Web y SOA
• Los servicios basados en Web pueden ser diseñados para
usarse dentro de soluciones distribuidas tradicionales o como
extensiones de ellas.
• O pueden ser diseñados para usarse en soluciones
orientadas a servicios.
• Esta flexibilidad es una de las razones que han hecho tan
populares y tan usados a los servicios basados en Web.
• Esto también revela el hecho que el mero uso de
servicios basados en Web no resulta en soluciones
orientadas a servicios.
Servicios como Componentes
• SOA como un modelo arquitectural es neutral a cualquier
plataforma tecnológica.
• Esencialmente cualquier implementación tecnológica que
pueda ser usada para crear sistemas distribuidos puede ser
adecuada para orientación a servicios
• Medios de implementación comunes para construir servicios
son:
• Componentes
• Servicios Web (o servicios Web basados en SOAP)
• Servicios REST
• Incluso aunque no son basados en Web, los componentes

pueden ser diseñados como servicios.
• Para diseñar un componente como un servicio, el
componente es formado por la aplicación de principios de
diseño orientado a servicios en la mayor medida posible.
• Puede ser beneficioso desde una perspectiva de performance
tener servicios que existan como componentes; sin embargo
debido a que el contrato de servicio no se encuentra
desacoplado puede inhibir la aplicación de otros principios.
• Con componentes el contrato de servicio es físicamente acoplado a la lógica de solución.
• Con servicios Web basados en SOAP y servicios REST, el contrato es físicamente
desacoplado. Esto puede ser beneficioso para la aplicación de orientación a servicios.
Roles de los Servicios
• Un servicio es capaz de asumir diferentes roles, dependiendo

del contexto de ejecución en el que es utilizado.
• Por ejemplo, un servicio puede actuar como el iniciador,
intermediario o receptor de un mensaje.
• Por lo tanto un servicio no es etiquetado exclusivamente
como cliente o servidor, sino que es una unidad de software
capaz de alterar su rol.
• El rol de proveedor de servicio es asumido por un servicio

que ofrece sus capacidades a los consumidores de servicios.
• Un servicio es más comúnmente asociado con el rol de
proveedor, razón por la que este término no es generalmente
usado cuando se refiere a un servicio en un escenario de
ejecución.
• El rol de consumidor de servicio es asumido por cualquier
programa de software que invoca a un proveedor de servicio.
• Un servicio actúa temporalmente como un consumidor
cuando invoca a otro servicio.
• Un consumidor de servicios es también llamado un service
requestor (un término originado por W3C)
Un proveedor de servicios puede ser accedido por una variedad
de consumidores de servicios.
• A diferencia de los canales de conexión punto a punto, la comunicación en

la que participan servicios no está limitada a dos puntos.
• Un servicio puede recibir un mensaje y entonces enviarlo a otro servicio y

este a otro y así sucesivamente (lo que es mejor descrito como punto a *).
• Una cadena de servicios puede estar envuelta en el procesamiento de un

simple mensaje y como parte de una simple tarea.
• Un mensaje puede ser procesado por múltiples programas intermediarios de
ruteo y procesamiento antes de llegar a su destino final.
• La ruta que un mensaje toma es el message path.
• Un message path puede ser predeterminado o ser determinado dinámicamente
en tiempo de ejecución.
• Los intermediarios son programas que realizan tareas de procesamiento
intermedio.
• Existen dos tipos de intermediarios:
• Agentes de servicio
• Servicios intermediarios
Los agentes de servicio existen como programas ligeros conducidos por
eventos que automáticamente interceptan y procesan mensajes.
Los intermediarios
son servicios que
transitan entre los
roles de
proveedor de
servicios y
consumidor de
servicios.
Existen dos sub categorías para los intermediarios:

• Intermediario pasivo – Rutean mensajes sin modificarlos.
Los agentes de servicios son generalmente intermediarios
pasivos.
• Intermediario activo – Rutean, procesan y modifican

mensajes. Ambos, servicios y agentes de servicios pueden
actuar como intermediarios activos.
Roles adicionales existen para la posición de un servicio a lo

largo de un message path:
• Initial sender – Este rol es asignado al consumidor de
servicio que inicia la transmisión del mensaje (el punto de
inicio del message path).
• Ultimate receiver – Este rol es asignado al servicio que es el
último destino del mensaje (el último servicio a lo largo del
message path).
• Un Initial sender es
siempre un
consumidor de
servicios.
• Un ultimate receiver
es siempre un
proveedor de
servicios.
• Un intermediario
nunca es un initial
sender ni un ultimate
receiver.
Los roles de servicio representan clasificaciones

temporales basadas en la utilización de un servicio en
tiempo de ejecución, los modelos de servicio son
clasificaciones permanentes basadas en la naturaleza de la
lógica encapsulada por un servicio.
Visión General de Servicios Web
Servicios Web – Un poco de Historia
• En el año 2000, el W3C recibió una submisión por la

especificación Simple Object Access Protocol (SOAP).
• SOAP en esencia establece un formato estandarizado para

mensajes XML.
• SOAP fue originalmente diseñado para unificar (y en algunos

casos reemplazar) la comunicación RPC a través de XML y
HTTP.
• Después que SOAP estuvo en uso, la industria empezó a reconocer
el potencial del intercambio de datos estandarizado basado en Web.
• Esto condujo a la idea de crear un framework de comunicaciones

estándar, neutral a los vendors y basado en Web .
• Este concepto fue llamado servicio Web.
• Una de las primeras iniciativas en soporte de servicios Web fue el Web Service
Description Language (WSDL), también desarrollado por el W3C.
• WSDL estableció un medio estandarizado de expresar una interface técnica
basada en mensajería (o un contrato técnico) vía el lenguaje XML.
• Después que WSDL se desarrolló, la industria buscó un

formato estándar de mensajería para ser usado con las
interfaces WSDL.
• Aunque alternativas tales como XML-RPC fueron
consideradas, SOAP se impuso como la favorita de la
industria.
• La combinación de WSDL y SOAP estableció el core de un
framework de comunicaciones estándar de la industria.
• La especificación Universal Description, Discovery and Integration

(UDDI) también fue creada.
• Su propósito fue permitir a las organizaciones descubrir servicios Web

publicados por otros.
• UDDI fue diseñado en soporte de un amplio uso de servicios Web, pero

su uso no fue tan masivo como el de WSDL y SOAP.
La Primera Generación, El Framework de Servicios Web
• WSDL, SOAP y UDDI
establecieron la primera
generación del framework
de servicios Web basado
en SOAP.
• Aunque su comunicación
no propietaria hizo
fascinantes a los servicios
web basados en SOAP,
este framework fue
relativamente primitivo,
adoleciendo de
características esenciales
de QoS .
La capa de Servicios Web
Los servicios Web introducen contratos técnicos que están generalmente
basados en el uso de XML Schema
La capa de
servicios Web
por lo tanto es
construida sobre
la capa de
representación
XML de los datos
establecida por
los esquemas
XML.
Servicios Web basados en SOAP
• Un servicio Web basado en SOAP es una solución lógica que tiene una
definición de WSDL publicada y que intercambia mensajes que cumplen
con el protocolo SOAP.
• La lógica de solución puede ser parte de un gran sistema o puede existir

como un único componente con toda la lógica en él.
• La lógica puesta a disposición como un servicio no necesita ser

exclusivamente accedida vía un WSDL.
Servicios Web y Organizaciones de
Estándares
Servicios Web y Organizaciones de Estándares
• Las organizaciones de estándares son responsables por desarrollar
especificaciones dentro de los estándares de la industria.
• Las tres principales organizaciones de estándares que influencian el
framework de servicios Web son:
• W3C
• OASIS
• WS-I
• Estas organizaciones están formadas por miembros comprendidos
principalmente de representantes de proveedores.
World Wide Web Consortium (W3C)
• Establecida en el año 1994
• Cuenta con aproximadamente 400 miembros
• La meta en general es apoyar la evolución de la Web proveyendo de

estándares fundamentales que mejoren los negocios online y el intercambio de
información
• Entre sus contribuciones más destacadas están: XML, XML Schema, Xquery,
XML Encription, XML Signature, Xpath, XSLT, WSDL, SOAP, WS-CDL, WS-
Addressing, WSA
Organization for the Advancement of Structured Information Standards
(OASIS)
• Establecida en el año 1993 con el nombre de SGML Open, como OASIS en

1998.
• Cuenta con aproximadamente 600 miembros.
• La meta original fue promover el comercio online vía estándares especializados

para servicios Web.
• Entre sus contribuciones más destacadas están: WS-BPEL, WS-Security, UDDI,

ebXML, SAML.
The Web Services Interoperability Organization (WS-I)
• Establecida en el año 2002.
• Cuenta con aproximadamente 200 miembros.
• La meta general es fomentar la interoperabilidad de forma estandarizada,

mediante el uso de estándares para servicios Web.
• Entre sus contribuciones más destacadas están: Basic Profile, Basic

Security Profile.
Contratos de Servicios Web
• La descripción de su servicio es necesaria para que cualquier

servicio actúe como proveedor de servicios.
• Los principales documentos de descripción de los servicios

Web son el WSDL definition y el XML schema.
• Otros documentos de descripción de servicios existen como

el WS-Policy definition.
• Colectivamente, los documentos de descripción de servicios

forman un contrato de servicio (o contrato técnico de servicio).
• Un WSDL definition es un
documento XML.
• Un WSDL definition
consiste de una
descripción abstracta y
una descripción concreta.
• Esta separación permite

generar una definición de
interface neutral a la
implementación.
• Un documento WSDL define una serie de operaciones cada

una de las cuales representa una función que el servicio Web
es capaz de realizar.
• Cada operación es definida a través de un conjunto de

mensajes de entrada y/o salida.
• La existencia y secuencia de estos mensajes determina los

patrones de intercambio de mensajes de la operación.
Pueden hacerse algunas comparaciones entre servicios y

componentes:
• Una operación es comparable a un método de un

componente.
• Los mensajes de entrada y salida son comparables a los

parámetros de entrada y salida de un método.
• El WSDL es comparable a la clase interface del componente.
• Los WSDL’s confían en los XML schemas para definir los tipos usados por los
mensajes de entrada y salida.
• Los esquemas pueden estar incrustados en el WSDL o enlazados al WSDL.
• Esquemas XML centrados en la entidad pueden ser
diseñados para representar grupos de información específica
que corresponden a modelos de entidad de negocio.
• Los esquemas de entidad son generalmente usados junto con

servicios basados en el modelo de servicios de entidad.
• Idealmente los esquemas de entidad son estandarizados

separadamente de los contratos de servicios Web de manera
que ellos establecen una arquitectura de datos independiente.
Mensajería de Servicios Web
• Los servicios Web confían solamente en mensajes como medio de
intercambiar información.
• Hay una diferenciación respecto de la forma tradicional de los

componentes que usaban comunicación RPC binaria.
• La comunicación basada en mensajería ofrece flexibilidad incrementada

pero también retos de performance y confiabilidad.
• El estándar más aceptado para el intercambio de mensajes para

servicios Web es SOAP.
• Un mensaje SOAP es un documento XML que esencialmente
actúa como un contenedor estandarizado diseñado para
transportar data XML.
• Una definición WSDL abstracta está enlazada al protocolo

SOAP vía su definición concreta.
• La estructura
del contenido
del mensaje es
fijada por
definiciones de
XML schema.
• Un mensaje SOAP es
estructurado como un documento
sobre que contiene una sección
de cabecera opcional y una
sección requerida llamada
cuerpo.
• La data transportada por el

mensaje SOAP reside en la
sección del cuerpo y es
frecuentemente referida como el
message payload.
• La sección de cabecera puede ser usada para albergar

grupos de meta información llamadas header blocks o SOAP
headers.
• Un SOAP header clásico es un identificador de correlación.
• Otros tipos de metadata colocados en los header blocks

puede pertenecer a transacciones, seguridad, ruteo, etc.
• Los SOAP headers son

una parte fundamental
del mundo de los
servicios Web.
• Casi toda las

especificaciones WS-*
son implementa das
mediante SOAP
headers.
Descubrimiento de Servicios Web
• Un objetivo original de la iniciativa de servicios Web fue posibilitar el

descubrimiento de los servicios Web en tiempo de diseño y en tiempo de
ejecución.
• El descubrimiento en tiempo de diseño es bastante común, y el

descubrimiento dinámico en tiempo de ejecución es muy poco frecuente.
• Se espera que el interés en el descubrimiento en tiempo de ejecución vaya

en aumento en la medida en que WS-* y las tecnologías de Web semántica
lleguen a estar más maduras.
Los registros públicos permiten al dueño del proveedor de servicios registrar sus
servicios para ser descubiertos por otras organizaciones.
Los registros privados permiten a una organización establecer un repositorio central de
servicios para soportar el descubrimiento dentro de la empresa.
• UDDI (Universal Description, Discovery and Integration) es un bien

conocido modelo estándar de registro.
• UDDI fue originalmente posicionada como una tecnología core de servicios

Web pero ha perdido su prominencia con el paso del tiempo.
• Las organizaciones han buscado tecnologías de directorio alternativas para

crear registros de servicios.
• Los registros UDDI son documentos XML que esencialmente contienen meta
información descubrible acerca de los servicios.
Anatomía de Servicios Web
• Desde una perspectiva de implementación, un servicio Web consiste de
diferentes partes físicas que colectivamente cumplen los requerimientos
de procesamiento asociados con su rol.
• Estas tareas de procesamiento pueden ser separadas en dos categorías:
• Lógica de procesamiento de mensajes
• Lógica core del servicio
• La lógica de procesamiento de mensajes esta formada de

una combinación de servicios de sistema en tiempo de
ejecución, agentes de servicio y lógica de servicios
relacionados al procesamiento del mensaje SOAP y la
definición del WSDL.
• La lógica core del servicio es la parte del back end de un

servicio Web, que lleva a cabo las tareas asociadas con las
operaciones expresadas en el contrato de servicio.
• Una representación
física de un servicio Web
actuando como un
proveedor de
servicios.
• Nótense las capas de

lógica de procesamiento
de mensajes.
• Una representación
física de un servicio
Web actuando
como un
consumidor de
servicios.
• Nótese que el
proxy se refiere a
un proxy del
servicio.
Tecnologías WS-*
Introducción a WS-*
• El framework de servicios Web es cada vez mayor debido a los conceptos y

tecnologías introducidas por muchas especificaciones tecnológicas
adicionales de servicios Web.
• Estas especificaciones representan la plataforma de la segunda generación de

servicios Web y son colectivamente conocidas como WS-* (debido a que
muchos de sus nombres son prefijados como " WS- ").
• Aunque el framework de servicios Web es neutral a los proveedores sigue siendo

una iniciativa conducida por proveedores.
• Message Exchange Patterns
• Service Activities
• Coordination (WS-Coordination)
• Transaction (WS-AtomicTransaction & WS-BusinessActivities)
• Orchestration (WS-BPEL)
• Addressing (WS-Addressing)
• Reliable Messagging (WS-RM)
• Policies (WS-Policy)
• Security (WS-Security)
Actividades de Servicio
• La realización de tareas de negocio es una función de cualquier tipo de

solución, en soluciones orientadas a servicios cada tarea puede ser hecha
por uno o más servicios.
• Esto generalmente resulta en la formación de una composición de

servicios.
• La interacción de un grupo de servicios compuestos trabajando juntos para

completar una tarea puede ser referida como un actividad de servicios.
• Mientras que los MEP’s son patrones en tiempo de diseño, las actividades de
servicio representan escenarios en tiempo de ejecución .
• Una actividad de servicio puede ser considerada una instancia de un MEP.
• Al igual que los MEP’s, existen actividades de servicio primitivas y complejas.
• Una actividad primitiva es

realizada por un
consumidor y un
proveedor intercambiando
información (según un
estándar MEP).
• Un ejemplo de una tarea
con un ámbito limitado a
una actividad de servicio
primitiva es un intercambio
de datos punto a punto.
Las actividades complejas involucran más de dos servicios (y MEP’s) como
parte de una composición de servicios.
Estos tipos de actividades más elaborados frecuentemente requieren el uso
de extensiones WS-*, especialmente las asociadas con la administración de
actividades.
Las actividad
complejas son
bastante comunes
en soluciones
orientadas a
servicios y confían
en la habilidad de
los servicios Web
para actuar como
miembros
efectivos de
composiciones.
• La lógica de solución subyacente de cada servicio Web, ya sea que se trate

de un simple componente o de un sistema heredado completo, generalmente
no es mapeado como parte de la actividad de servicio.
• Las actividades de servicios representan solamente la interacción de los

servicios.
Coordinación
(WS-Coordination)
Coordinación (WS-Coordination)
• Cada actividad de servicio introduce una medida de información

específica a la actividad en el entorno de ejecución.
• Esta información es específica al contexto de una actividad y es por lo

tanto clasificada como información de contexto.
• Cuanto más compleja es una actividad, más información de contexto

tiende a llevar consigo.
Ejemplos de información de contexto:
• La cantidad de servicios que participan en la actividad.
• La duración de la actividad.
• La cantidad de instancias de la actividad que existen

concurrentemente.
• Las reglas asociadas con la actividad.
• WS-Coordination es una especificación que presenta un modelo de servicio
coordinador genérico.
• El servicio coordinador controla una composición de otros tres servicios de

sistema que juegan cada uno una parte específica en la gestión de la data de
contexto.
• Colectivamente, estos servicios gestionan la actividad de los servicios

participantes en una forma que constituye un estándar de la industria.
• La información de contexto es representada por cabeceras SOAP

estandarizadas.
• El servicio de activación provee

un contexto de coordinación
para el servicio de aplicación, el
cual lo comparte con otros
servicios como un medio de
invitación a participar en la
coordinación.
• Todos los participantes se

registran con el servicio de
registro el cual provee la
dirección del coordinador
Un servicio de
coordinación
gestiona la
interacción entre
el servicio de
aplicación y los
servicios
participantes.
Transacciones
(WS-AtomicTransaction y WS-
BusinessActivity)
Transacciones
(WS-AtomicTransaction y WS-BusinessActivity)
• En el pasado, la capacidad de ejecutar transacciones estaba limitada a lógica

dentro de los límites del servicio Web o construida sobre características
propietarias.
• Sin embargo la necesidad de soportar composiciones complejas requiere un

medio de ejecutar transacciones que atraviesan los límites del servicio.
• Por esta razón, los estándares WS-AtomicTransaction y WS-BusinessActivity

fueron desarrollados (contribuciones del comité técnico WS-TX).
Transacciones
• La especificación WS-AtomicTransaction provee protocolos estándar de la

industria (reglas) que emulan la funcionalidad ACID de las transacciones.
• Los protocolos son implementados mediante el framework de gestión del

contexto de WS-Coordination.
• Los servicios registrados por una transacción participan votando sobre el

resultado con el fin de determinar si se hace un commit o rollback sobre los
cambios.
• Si alguno de los participantes vota por abortar o si el voto de un servicio

participante no es recibido los cambios son abortados (roll back).
Transacciones
Las transacciones participantes votan sobre el resultado de la
transacción atómica pero un participante vota por abortar.
Transacciones
Debido a que un voto por abortar fue recibido, el servicio
coordinador aborta la transacción y notifica a todos los
participantes a hacer rollback a los cambios.
Transacciones
• WS-BusinessActivity provee protocolos de soporte de

actividades complejas de long-running, basados también en el
framework WS-Coordination.
• Las actividades de negocio llamadas de long-running pueden

durar horas, días o incluso semanas y puede incluir numerosos
pasos incluyendo tareas manuales.
• Las transacciones que fallan no son abortadas (roll back), en

lugar de ello se invoca un proceso de compensación separado.
Transacciones
Una actividad de
servicio manejada por
WS-BusinessActivity
puede encapsular
una o más
transacciones
atómicas.
Orquestación (WS-BPEL)
• La orquestación emergió desde la era de Enterprise
Application Integration (EAI) como una forma de
middleware.
• Su rol primario fue facilitar la conectividad entre sistemas

dispares mediante el establecimiento de un hub en el cual
la lógica de procesos de negocio es centralmente definida
y ejecutada.
• En el hub, servicios de brokerage, tales como

transformación de datos, pueden ser llevados a cabo
salvando la incompatibilidad de los sistemas.
Una arquitectura hub and spoke en la cual la plataforma de orquestación
establece un hub que se convierte en un punto de contacto primario para
aplicaciones dispares.
• La habilidad de las plataformas de orquestación para

abstraer y centralizar la lógica de proceso de negocio
puede beneficiar a SOA.
• Una capa padre de proceso de negocio puede ser

establecida como una locación para toda la lógica de
servicio no-agnóstica.
• Esto posibilita la creación de un inventario de servicio con

un alto porcentaje de servicios agnósticos.
• El Web Service Business Process Execution
Language (WS-BPEL) proporciona una forma de
expresar lógica de proceso de negocios siendo un
estándar de la industria.
• WS-BPEL es esencialmente un lenguaje de

composición de servicios Web.
• Su sintaxis hace posible la invocación e interacción de

servicios Web responsables de realizar la lógica de
procesos de negocio.
• La definición de los procesos WS-BPEL pueden también
ser encapsulados y expuestos como servicios Web.
• Estos servicios forman la base del modelo de servicio de

orquestación de tareas (también conocido como el
modelo de servicio de procesos) .
• Las definiciones de procesos WS-BPEL son generalmente

obtenidas usando herramientas de modelamiento y
entonces ejecutada vía un motor de orquestación.
• WS-BPEL fue formalmente llamado BPEL4WS y tiene un

fuerte soporte de la industria.
Addressing
(WS-Addressing)
Addressing (WS-Addressing)
• La especificación WS-Addressing provee características
para el ruteo de mensajes basado en un estándar de la
industria vía un conjunto de cabeceras SOAP
predefinidas.
• Existen dos tipos de cabeceras SOAP introducidas por

WS-Addressing:
• Endpoint References (EPRs)
• Messaging Information (MI) Headers
• Las cabeceras MI también han sido recientemente

llamadas Message Addressing Properties (MAP).
Endpoints References (EPR’s) permite definir detalles adicionales
relativos al contrato del servicio Web (endpoint).
Un uso común
de EPR’s es
dirigir mensajes
a instancias de
servicio a través
del uso de
identifica dores
especiales.
• Las cabeceras MI son usadas para equipar mensajes con ruteo auto gobernado y
detalles de procesamiento (el cual puede incluir EPR’s).
• Las cabeceras MI brindan a la mensajería SOAP algo similar a lo que una hoja de
embarque brinda a los procesos de embarque.
Mensajería Confiable
(WS-RM)
Mensajería Confiable (WS-RM)
• WS-ReliableMessaging (WS-RM) establece un

framework que provee un medio de comunicación
estándar en la industria:
• Si un mensaje llegó satisfactoriamente a su destino

previsto.
• Si un mensaje no llegó y por lo tanto requiere una
retransmisión.
• Si una serie de mensajes llegaron en la secuencia en
la que fueran previstas.
• Existen dos especificaciones que implementan

mensajería confiable:
• WS-ReliableMessaging
• WS-Reliability
• Sus características se superponen y son consideradas

especificaciones competidoras.
• Ambas forman las bases para el subsecuente comité

técnico WS-RX.
• Reliable messaging agrupa los mensajes en una

secuencia.
• Notificaciones de confirmación positiva o negativa
son enviadas por el receptor de la secuencia,
dependiendo si los mensajes fueron entregados como
se esperaba.
• Las confirmaciones pueden también ser entregadas
antes que una secuencia sea completada.
• Confirmación de secuencia enviada luego de la

entrega exitosa de una secuencia de mensajes.
• Confirmación negativa enviada para indicar un fallo
en la entrega antes de la culminación de la secuencia
de mensajes.
Delivery assurance son reglas predefinidas que establecen patrones

de confiabilidad de la entrega:
• AtMostOnce Para que un mensaje sea entregado sólo una o cero

veces.
• AtLeastOnce Permite que un mensaje sea entregado una o varias
veces.
• ExactlyOnce Garantiza que un mensaje será entregado una vez.
El InOrder delivery
assurance es
usado para
garantizar que los
mensajes son
entregados en una
secuencia
específica.
Políticas
(WS-Policy)
Políticas (WS-Policy)
• El WS-Policy framework proporciona un conjunto de
especificaciones que definen el ensamble y estructura de los
documentos de descripción de políticas.
• El uso de políticas permite a un servicio expresar características

y preferencias más allá de su interface técnica.
• Esto evita que el servicio tenga que encargarse de implementar y

reforzar políticas de reglas y restricciones de una manera
personalizada.
• El documento de políticas es llamado policy definition. Las políticas

son representadas individualmente por policy assertions requeridas u
opcionales.
• Existen policy assertions basados en estándares de la industria, pero
pueden también ser definidas a medida.
• Los estándares de la industria que proveen policy assertions incluyen
WS-ReliableMessaging, WS-Addressing, WS-SecurityPolicy.
• Un ejemplo de una policy assertion a medida podría ser algo como
“Proveer un Log de Detalles“.
• Policy assertions pueden ser agrupadas en policy alternatives.
• Cada policy alternative representa una aceptable combinación de
policy assertions.
• Esto da a un proveedor de servicio la habilidad de ofrecer a los
consumidores opciones de políticas.
WS-Policy definitions pueden ser compartidas por diversas definiciones de
WSDL permitiendo la creación de policy assertions globales o específicas
a un dominio.
Seguridad
(WS-Security)
Seguridad (WS-Security)
• El framework WS-Security provee extensiones que pueden ser

usadas para implementar una capa de mensajes de seguridad.
• Esto permite que el contenido del mensaje este protegido durante el

transporte y durante el procesamiento de los servicios
intermediarios.
• WS-Security junto con otras tecnologías adicionales pueden

proporcionar controles de autenticación y autorización.
La seguridad en
la capa de
transporte es
frecuentemente
insuficiente
cuando existen
intermediarios
debido a que el
mensaje no está
protegido
mientras es
procesado por
intermediarios.
WS-security trabaja con los

estándares XML-Signature
y XML-Encryption para
garantizar la integridad de
los mensajes, la
autenticación y la
confidencialidad.
Enterprise Service Bus (ESB)
• Un enterprise service bus (ESB) es considerado un middleware que

establece una capa intermediaria de procesamiento con una variedad de
características de procesamiento de mensajes.
• Un ESB puede ayudar a resolver problemas comunes de diseño de
composición de servicios relacionados con confiablidad, escalabilidad,
compatibilidad y ruteo de mensajes.
• Diferentes proveedores ofrecen diferentes productos y plataformas ESB.
Un ESB comúnmente debe proporcionar:
• Encolamiento asíncrono
• Enrutamiento Intermedio
• Mensajería confiable
• Centralización de políticas
• Centralización de reglas
• Mensajería conducida por eventos
• Transformación de formatos de datos (Service Broker)
• Transformación de modelos de datos (Service Broker)
• Protocol bridging (Service Broker)
Los items de la lista anterior están relacionados a la funcionalidad del Service
Broker, pues ellos pueden llevar a cabo funciones de transformación y bridging.
Por ejemplo:
• Permiten a los servicios usar diferentes modelos de datos (que representan al

mismo documento de negocios) para comunicarse unos con otros.
Generalmente se usa XSLT.
• Permiten a los servicios usar diferentes protocolos de comunicación para
comunicarse entre ellos.
• Permiten a los servicios usar diferentes formatos de datos (tal como XML y
ASCII) para comunicarse unos con otros.
Estas funciones pueden ser usadas individualmente o al mismo tiempo para un

determinado intercambio de datos.
• Un mensaje pasando
por varios pasos de
procesa miento
ejecutados por un ESB.
• El mensaje es primero
transforma do por un
Service Broker y luego
es ruteado dinámica
mente y finalmente
grabado en una cola
antes de ser entregado.
Diseño y Arquitectura SOA
Los 8 principios de diseño SOA
1.- Contrato de Servicios Estandarizados
Cuando un servicio se implementa como un servicio web, se

debe adherir (proporcionar) un contrato de comunicaciones
explícitamente declarado y definido colectivamente por uno o
más descriptores del servicio, en el cual debe figurar
especificaciones como:
• Nombre del Servicio.

• Forma de accesos.
• Funcionalidades que ofrece.
• Descripción de los datos de entrada de cada funcionalidad
que ofrece.
• Descripción de los datos de salida de cada funcionalidad que
ofrece.
De este modo, todo consumidor de los servicios accederá mediante el
contrato, logrando la independencia entre el consumidor y la
implementación del propio servicio. Con esto se evita el manejo incorrecto
de los datos, se evita trabajo innecesario en la invocación entre estos
servicios y también se pone de manifiesto que la existencia de un modelo
de datos a nivel de servicio es una de las primeras necesidades que se
debe tener en cuenta.
2.- Bajo Acoplamiento
• Este principio hace referencia a que los

servicios tienen que ser independientes
los unos de los otros.
• Para lograr ese bajo acoplamiento, lo que

se hará es que cada vez que se vaya a
ejecutar un servicio, se accederá a él a
través del contrato, logrando así la
independencia entre el servicio que se va
a ejecutar y el que lo llama.
• Si conseguimos este bajo acoplamiento,

entonces los servicios podrán ser
totalmente reutilizables.
3.- Abstracción:
El principio de abstracción permite encapsular el servicio y reducir

el acoplamiento. El servicio debe ser una caja negra, únicamente
definido por su contrato, que a su vez es el mínimo acoplamiento
posible con el consumidor del mismo.
El uso de estándares permite definir interfaces uniformes que

esconden la lógica del servicio respecto del entorno que le rodea
(sistemas proveedores y consumidores).
Este nivel de abstracción permite centrarnos
exclusivamente en la especificación del servicio, sin incluir
información tecnológica ni de ninguna otra naturaleza, más
allá de la propia especificación estándar del servicio desde
el punto de vista del negocio al que sirve, que queda
recogida en su contrato.
4.- Reusabilidad:
• La reutilización es el principal principio de la arquitectura SOA, cada servicio

debe ser analizado, diseñado y construido de manera que su uso pueda ser
explotado al máximo, es decir, cada servicio debe ser de algún modo genérico
con el fin de que pueda usarse en diferentes contextos y satisfacer distintos
objetivos.
• De esta manera, los servicios podrán ser reusables dentro de la misma

aplicación, dentro del dominio de aplicaciones de la empresa o incluso dentro
del dominio público para su uso masivo.
• Por otro lado, estos servicios reutilizables deben estar diseñados de manera tal
que su solución lógica sea independiente de cualquier proceso de negocio o
tecnología en particular.
Con este principio se busca reducir las posibilidades de duplicación de
lógica. Si un servicio que ya existe en un contexto funcional se ajusta a la
nueva lógica reutilizable, en lugar de crear un nuevo servicio, dicha lógica
debe formar parte del servicio existente.
5.- Autonomía
Este principio nos dice que todo Servicio debe tener su propio entorno de ejecución.
De esta manera el servicio es totalmente independiente y nos podemos asegurar
que así podrá ser reutilizable desde el punto de vista de la plataforma de ejecución.
6.- No estado
Un servicio no debe guardar ningún tipo de información. El tratamiento de una gran
información de estado afectaría gravemente a la escalabilidad del servicio,
poniendo en riesgo su disponibilidad. Idealmente, todos los datos que necesita el
servicio para trabajar deben provenir directamente de los parámetros de entrada.
7.- Descubrimiento
• Todo servicio debe poder
ser descubierto de
alguna forma para que
pueda ser utilizado,
consiguiendo así evitar
la creación accidental de
servicios que
proporcionen las mismas
funcionalidades.
• En el caso de los
Servicios Web, el
descubrimiento se
logrará publicando los
interfaces de los
servicios en registros
UDDI.
8.- Composición
• Este principio nos dice que todo servicio debe estar construido de tal
manera que pueda ser utilizado para construir servicios genéricos de
mayor complejidad, el cual estará compuesto de servicios de menor nivel.
• En el caso de los Servicios Web, esto se logrará mediante el uso de los
protocolos para orquestación (WS-BPEL) y coreografía (WS-CDL).
• El concepto de desarrollo de software a partir de componentes existentes
independientemente fomenta el concepto de composición. Por ello el
concepto de composición es heredado por la orientación a servicios, por
lo que un proceso de negocio está automatizado mediante la
combinación de múltiples servicios.
• Sin embargo, dentro de la orientación a servicios es mayor el enfoque en
la creación de servicios que se pueden componer y recomponer dentro
de múltiples soluciones para proporcionar la agilidad prometida por la
SOA.
Como resultado de este énfasis, algunas pautas son requeridas para el desarrollo
de servicios que pueden ser efectivamente agregados en varias soluciones.
Modelos de referencia útiles para
adoptar SOA
Modelo conceptual o glosario
• Debido al frenesí que desde los primeros años 2000 ha habido sobre SOA
y WS-*, existen muchos puntos de confusión al respecto.
• Por ello, puede ser de utilidad elegir un modelo de conceptos

fundamentales que proporcione el vocabulario básico a utilizar, clarificando
esas dudas y facilitando una comunicación efectiva.
• Existe un modelo de referencia estándar de OASIS y es una base a

considerar. No obstante, a menudo es suficiente con un simple glosario de
términos.
Arquitectura de referencia
• Se trata de una plantilla de la infraestructura tecnológica que describa las

capacidades que esta debe desempeñar, permitiendo decidir si cada una
aplica a un caso concreto o no, y ayudar a seleccionar la mejor forma de
implementarla.
• Debe ser en lo posible independiente de productos concretos, de modo

que deje libertad de elegir esta implementación.
• Si cumple estas características y es completa, es de gran utilidad a la hora

de diseñar una infraestructura tecnológica, pues sirve como checklist a
revisar y guía para seleccionar productos y otros elementos con los que
hacerlo.
• A fecha de hoy, OASIS ha publicado un borrador de una arquitectura de
referencia. Por su parte, todos los vendedores de infraestructura tecnológica
tienen su propia arquitectura de referencia, que a menudo coincide con su
oferta, por lo que se aconseja estudiar varios de ellos.
• Más adelante se presenta un ejemplo. En particular , el autor aconseja

mucha precaución a la hora de utilizar un ESB (Enterprise Service Bus)
como centro de la infraestructura.
• Es conveniente diferenciar y tener muy claras las características del patrón

arquitectónico ESB, que es muy útil para SOA cuyo principal objetivo es la
integración de sistemas, pero que resulta tanto menos conveniente cuanto
más se alejan de esta función.
Arquitectura de referencia
Marco de referencia de gobierno SOA
• Lo mismo que existen plantillas que ayudan mucho en el diseño de la

infraestructura tecnológica, para los elementos del gobierno de la SOA
también se pueden encontrar esquemas que describan las normas,
políticas, procedimientos, procesos, roles, órganos, tecnología y otros
elementos que pueden ser necesarios en una organización a fin de
conseguir un gobierno SOA efectivo: un marco de referencia de gobierno.
• A fecha de hoy no existe un estándar específico de SOA, aunque existen

otros más genéricos, que ofrecen una buena parte de lo necesario.
Además, diversas compañías de consultoría y productos informáticos
ofrecen sus propias recomendaciones para SOA
Marco de referencia de gobierno SOA
Razones para adoptar SOA
Los beneficios que puede obtener una organización que adopte SOA son:
• Mejora en los tiempos de realización de cambios en procesos.
• Facilidad para evolucionar a modelos de negocios basados en

tercerización.
• Facilidad para abordar modelos de negocios basados en colaboración con

otros entes (socios, proveedores): facilita la integración de sistemas y
aplicaciones diferentes, lo cual mejora la comunicación y la capacidad de
respuesta con sistemas externos.
• Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción

en el proceso de negocio.
• Facilidad para la integración de tecnologías disímiles

• Mejora en la toma de decisiones: la organización dispone de mayor
información y más actualizada, lo que le permite una respuesta rápida y eficaz
cuando surgen problemas o cambios.
• Aplicaciones flexibles: la orientación a servicios permite desarrollar

aplicaciones con independencia de las plataformas y lenguajes de programación
que realizan los procesos.
• Aplicaciones reutilizables y adaptables: permite que las aplicaciones

existentes para ser reutilizadas y adaptadas a nuevos entornos con facilidad. Así
conseguimos optimizar los recursos empleados en su desarrollo.
• Reducción de costes: el coste de ampliar o crear nuevos servicios se reduce

considerablemente tanto en aplicaciones nuevas como ya existentes.
• Riesgo de migración: al adaptar SOA a partir de una tecnología existente se

siguen utilizando los componentes existentes, por lo que se reduce el riesgo de
introducir fallos.
Patrones de Intercambio de
Mensajes
Patrones de Intercambio de Mensajes
• Cada tarea automatizada por un servicio Web puede diferir en:
• La naturaleza de la lógica que es ejecutada
• El rol del servicio en la ejecución general de la tarea de

negocio
• Independientemente de cuan compleja es una tarea casi todas

requieren la transmisión de múltiples mensajes.
• Message exchange patterns (MEPs) representan un conjunto
de plantillas que proporcionan secuencias ya trazadas para el
intercambio de mensajes.
• Existen dos tipos de patrones de intercambio de mensajes:
• MEPs primitivos que gobiernan intercambios de mensaje

simples
• MEPs complejos los cuales son generalmente formados por

múltiples MEPs primitivos
• El MEP primitivo más popular es el patrón request-response.
• Este patrón síncrono requiere que tras la entrega de un mensaje desde el

consumidor al proveedor, el proveedor responda con un mensaje al
consumidor.
• Otro MEP primitivo bastante común es el patrón one-way donde un simple

mensaje es enviado desde el consumidor al proveedor sin esperar respuesta.
• Los patrones request-response y one-way son considerados MEPs inbound.
• La versión 1.1 de la especificación WSDL soporta dos MEPs

adicionales (solicit-response y notification) que son considerados
outbound.
• Los MEPs outbound fueron pensados para proveer

funcionalidad de retorno, pero no fueron adoptadas por la
industria y no son recomendadas por el WS-I.
• WSDL 2.0 agrega un nuevo MEP y no soporta MEPs outbound.
Servicios REST
Servicios REST
• REST (Representational State Transfer) originado en una disertación de Roy
Fielding en el año 2000.
• Los servicios REST no tienen contratos de servicio individuales, sino que

comparten un contrato uniforme mediante el protocolo HTTP.
• Los servicios REST se comunican usando métodos HTTP, tales como GET, PUT,
POST, DELETE, HEAD, OPTIONS.
• No obstante cada servicio REST puede ser diseñado para soportar sólo un
subconjunto de los métodos HTTP disponibles.
Servicios REST
• Los servicios REST aprovechan la arquitectura subyacente del World

Wide Web.
• Los servicios REST hacen posible el direccionamiento a los recursos

mediante URLs y URIs.
• Cuando un servicio REST es invocado, el URL o URI indica que recurso

será accedido y que método HTTP será usado para procesar el recurso.
• Una solución comprendida de servicios REST es vista como una red de

recursos linkeados.
Servicios REST
• Cuando los servicios REST intercambian datos, las cabeceras
HTTP pueden ser usadas para llevar meta información, tal como
tokens de autenticación, códigos de respuesta, información de
errores.
• Los recursos pueden ser representados usando diferentes

formatos y protocolos, tales como XML, POX (Plain Old XML), o
JSON (JavaScript Object Notation).
• Los datos intercambiados por servicios REST pueden ser

definidos usando XML Schema.
Servicios REST
• Los servicios REST pueden aprovechar características de
caching provistas por HTTP a fin de diferir y hacer persistente
alguna forma de datos de estado.
• Los servicios REST pueden ser diseñados para soportar

intercambio de datos en múltiples o alternativos formatos de
datos tales como PDF.
• Los servicios REST que necesitan ser reubicados pueden

aprovechar las características de redireccionamiento de
aplicación y de transporte a fin de preservar la conectividad de
consumidor a servicio.
Servicios REST
• Existen diseños candidatos de patrones de diseño SOA
actualmente en desarrollo:
• Alternative Format
• Entity Linking
• Layered Redirect
• Transport Caching
• Uniform Contract
• Idempotent Capability

Maestría en Ingeniería de Sistemas

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Maestría en Ingeniería de Sistemas

Caricato da

Copyright:

Formati disponibili

Desarrollo e Integración de Sistemas

Maestría en Ingeniería de Sistemas

 Aplicaciones Monolíticas y con

 Fuentes de Información Inconsistentes

 Conexiones “alambradas”  “La Arquitectura de TI actual, tan

Productividad Agilidad y cumplimiento

Facilidad para manejo de cambios Una sola fuente de información

Colaboración Experiencia con clientes

Accesos basados en roles Tareas provistas por otros

Capacidad de respuesta y servicio Nuevas oportunidades

Expandir el acceso a las aplicaciones y

Pre 50’s 70’s - 80’s - Mitad 90’s a

… Arquitectura … una Aplicación

Servicios Innovación & Optimización Negocio

Servicios Asociados Servicios App Negocio Servicios Acceso

Servicios Innovación & Optimización Negocio

Bus Servicios Empresariales

Servicios Asociados Servicios App Negocio Servicios Acceso

Servicios Innovación & Optimización Negocio

Bus Servicios Empresariales

Servicios Asociados Servicios App Negocio Servicios Acceso

Servicios Innovación & Optimización Negocio

Bus Servicios Empresariales Lógica

Servicios Asociados Servicios App Negocio Servicios Acceso

Servicios Innovación & Optimización Negocio

Bus Servicios Empresariales Lógica

Servicios Asociados Servicios App Negocio Servicios Acceso

Servicios Innovación & Optimización Negocio

Bus Servicios Empresariales Lógica

Servicios Asociados Servicios App Negocio Servicios Acceso

Servicios Innovación & Optimización Negocio

Bus Servicios Empresariales Lógica

Servicios Asociados Servicios App Negocio Servicios Acceso

Servicios Infraestructura Lógica

Servicios Innovación & Optimización Negocio

Bus Servicios Empresariales Lógica

Servicios Asociados Servicios App Negocio Servicios Acceso

Servicios Infraestructura Lógica

Servicios Innovación & Optimización Negocio

Bus Servicios Empresariales Lógica

Servicios Asociados Servicios App Negocio Servicios Acceso

Servicios Infraestructura Lógica

Servicios Innovación & Optimización Negocio

Bus Servicios Empresariales Lógica

Servicios Asociados Servicios App Negocio Servicios Acceso

Servicios Infraestructura Lógica

Modelador Negocio Tableros de Control

Bus Servicios Empresariales Lógica

Servicios Asociados Servicios App Negocio Servicios Acceso

Servicios Infraestructura Lógica

Modelador Negocio Tableros de Control

Bus Servicios Empresariales Lógica

Servicios Asociados Servicios App Negocio Servicios Acceso

Servicios Infraestructura Lógica

Modelador Negocio Tableros de Control

Bus Servicios Empresariales Lógica

Servicios Asociados Servicios App Negocio Servicios Acceso

Servicios Infraestructura Lógica

Modelador Negocio Tableros de Control

Bus Servicios Empresariales Lógica

Servicios Asociados Servicios App Negocio Servicios Acceso Monitoreo TI

Servicios Infraestructura Lógica

Capacidades “Middleware” Robusto Conectado de una Manera Abierta y Flexible