SOA y Web Services

Y… ¿Por qué tengo que pensar

en otro modelo de Arquitectura?
 Los negocios están
cambiando
De A
 Tamaño  Velocidad, movilidad

 Activos Físicos  Propiedad Intelectual

 Optimizar viejos métodos  Innovar con nuevas reglas

 Satisfacción del Cliente  Deleitar al Cliente

 Monolíticos  Especialización

 Estructuras Rígidas  Sociedades Flexibles

 Las Aplicaciones están
cambiando
De A
 Construidas para durar  Construidas para cambiar

 Guiadas por el TCO  Guiadas por el ROI

 Años de atraso  Construcción y puesta en

producción en 6 semanas

 ¿Dónde están los datos?  Flujo de los Datos

 Integración: Un costoso  Integración: Algo tácito

esfuerzo posterior
 La realidad del cambio
El éxito en los negocios es un blanco móvil
Expectativas de los
clientes
Tecnologías Competencia

Necesidades de los clientes

Requerimientos de los socios
Globalización 24x7 y Acceso Móvil Mercado
Fusiones, adquisiciones
canales, nuevas líneas

Macroeconomía Regulaciones

Agilidad es la métrica crítica de TI

Hoy en Día
Si invierte, entonces mañana
 Ninguna aplicación es una Isla
Payment Systems and Card Mgmt Treasury / Forex
3D Secure Trading / Back office

Wealth Management
Core Banking

Branch Banking

EAI Internet Banking

Business
Intelligence

Straight through
Processing CRM
Aggregation
Wireless
ATM / POS
 Ninguna compañía es una Isla

Partners Partners
Customers

Suppliers Employees

Customers Partners Suppliers

Employees Suppliers
 Impedimentos para generar Valor
Asuntos
Integración difícil, costosa
Infraestructura de computo bajo
ataque
Los recursos de TI son difíciles de
administrar
Gente, procesos e información
desconectada
Sostener las inversiones de TI
limita la generación de valor
Impacto en Negocios
Islas de procesos impiden
agilidad para responder y tomar
las oportunidades
Costoso, actualizaciones de
seguridad frecuentes
Demasiado trabajo de poco
valor, porcentaje de utilización
bajo
Se reduce el proceso de toma
de decisiones.
No se percibe el valor de
negocio de TI
Y … ¿como adopto una arquitectura
de TI que me de más agilidad?
 La arquitectura debe cambiar
De A
Altamente Acoplada  Poco Acoplada
Centrada en costos  Centrada en Valor
Una plataforma  Todas las plataformas
Centrada en la aplicación  Data manejable
Orientada a Objetos  Orientada a mensajes
Conocer cada detalle  Abstracción
Más Conexiones == más  Más Conexiones == más
costos valor
 La Arquitectura
… y el problema
ASB BLT

AFT TGI FRY

ECP
HDL
SWG
DRW MFP

WCP
QYD DLY SKD

DLY
XPS
WIU

KYF
XOI ZIS CUI WKD

WHR
ASB GEX
RMO JIA
HCO

BST VUH KFC AJT FQA DKE

 Reducir Dependencias
Reducir Acoplamiento
Ejemplo
Ejemplode
deuna
unasolución
soluciónsuavemente acoplada
altamente acoplada
Su
Usted socio
Lenguaje de Lenguaje de
Programación Programación

Base de Base de
Acuerdos Datos
Datos

Modelo de Modelo de
Objetos Objetos
Sistema Esquema Sistema
Operativo Operativo
Servidor de
Aplicaciones Servidor de
Aplicaciones
La Arquitectura
… y la Solución

Arquitectura
Basada en Servicios
Servicio Servicio Servicio

Bus

Servicio Servicio Servicio

 Diseñar un servicio no es fácil (1)
 Un mensaje no es una llamada de función

 Características de los mensajes:

 Atraviesa fronteras de procesos y sistemas
 Son asíncronos
 Pueden ser procesados después
 Se entregan cero o más veces
 La entrega inmediata no puede ser garantizada
 Pueden ser reenviados por el cliente
 Pueden ser entregados fuera de secuencia
 Diseñar un servicio no es fácil (2)
 Los mensajes no tienen concepto de sesión
 El Servicio puede tener que restablecer el contexto de la conversación
 El mensaje podría tener que llevar este contexto
 Necesidad de seguridad a nivel de mensaje
 Si no se controla el transporte desde principio a fin

 El manejo de excepciones es difícil

 Los procesos se distribuyen en el espacio y el tiempo
 Incertidumbre entre el envío del mensaje y la recepción de la
respuesta

 Si usted no desea tener que manejar estos aspectos, entonces quizás un

componente es adecuado — pero entonces no podrá:
 Manejarlos independientemente
 Distribuirlos independientemente
 Comunicarse con otras tecnologías
 Escalar Horizontalmente (Scale Out)
 Servicios de Infraestructura
 Pero …

Yo necesito que mis servicios mantengan las

mismas capacidades empresariales que he tenido …

 Seguridad
 Transacciones
 Confiabilidad
 Escalabilidad
 Etc.
Service-Oriented Architecture

Clients and Agents

 Capacidades Requeridas …
los problemas
 Seguridad
 Autenticación, Autorización, Confidencialidad, no
repudiación.

 Enrutamiento
 Base para la escalabilidad y la tolerancia a fallas.

 Transacciones
 Necesidad de soportar transacciones de negocio mas
allá de las fronteras de confianza (Transacciones
ACID).
 Capacidades Requeridas …
las soluciones (1)
 Seguridad
 Usar SSL con SOAP
 (XML Signatures, XML Encryption)

 Enrutamiento
 Enrutar mensajes a través de nodos SOAP
intermediarios.
 Útil para:
 Balanceo de Cargas
 Cache
 ―Virtualizar‖ los servicios

 Transacciones ACID …
 Atomic (Atómicas)
 Consistent (Consistentes)
 Isolated (Aisladas)
 Durable (Durables/Persistentes) …
 Capacidades Requeridas …
las soluciones (2)
 Transacciones ACID
 Implícitamente asumen
 Ambiente altamente acoplado (Llamadas sincrónicas)
 Actividades de corta duración (Debe ser posible poder tener
recursos bloqueados por períodos de tiempo)

 En consecuencia , no trabajan bien en

 ¡Ambientes suavemente acoplados!
 ¡Actividades de larga duración!

 ¿Qué hacer? – e.g. Microsoft usa WS-Transactions:

 Atomic Transactions
 Corta duración
 Basadas en el modelo 2-Phase-Commit
 Para uso dentro de una organización
 Business Activities
 Larga duración
¿Conceptos de una Arquitectura
Orientada a Servicios?
 Servicios
Un vehiculo mediante el cual, los requerimientos
de un consumidor se satisfacen de acuerdo a un
contrato negociado (Implícito o explicito) el cual
incluye acuerdos de servicio, funcionalidad etc.
(CBDI).

La orientación a servicios encapsulara procesos y

sistemas

Ayuda a administrar la complejidad

Permite cambios controlados
Soporta mejoramiento continuo
 Arquitectura Orientada a
Servicios
Una aproximación para construir sistemas usando
servicios los cuales se adhieren a 4 pilares:

 Los limites son explícitos

 Los servicios son Autónomos
 Los servicios comparten esquemas y contratos,
no clases
 La compatibilidad de los servicios, se
determina basados en las políticas
 Arquitectura Orientada a
Servicios

Servicio Servicio Servicio

Comunicación

Acuerdos / Esquemas
Bus
Acuerdos / Esquemas

Comunicación

Servicio Servicio Servicio

 Beneficios de la Arquitectura
Orientada a Servicios
 Proveer servicios a los consumidores vía interfaces estándares,
publicadas y de fácil ubicación
 Soluciones basadas en protocolos estándares no en
productos

 Eleva el nivel de abstracción para reutilización del código

 Solventando problemas de heterogeneidad

 Provee de un modelo claro para integrar sistemas de software

 Dentro de a empresa
 Mas allá de las fronteras organizacionales

 Provee de la bases para aplicaciones conectadas de clase

mundial
 El valor de negocio de las aplicaciones aisladas es limitado
 “Scales Away”
SOA: Beneficios de TI spans organizations
and geographies

“Scales Out”
by adding
Escalabilidad de Servicios machines

“Scales Up”
on large
systems

“Scales In”
on a machine

“Scales Down”
to devices
 Confusión acerca de SOA

How do I get started building

a SOA?
What are the design issues
for SOA implementation?
How do I manage a SOA
environment?
Where are the best practices
for SOA implementation?
How do I aggregate services
What does a successful SOA
to create business processes?
look like?

What are the critical success

Thisfactors for –SOA?
is all fluff where
are the bits???
 Qué es un Web Service?

Web
Protocolos
Service
Internet
Abiertos Lógica de aplicación encapsulada como un
componente en la Web para ser usada por
otros programas
Involucra:
 Poder preguntar por descripciones de
UDDI
los WS que ofrece un sitio
 Definir formatos y ordenamientos de los WSDL
mensajes Contract Language
 Formatos para enviar y recibir datos SOAP
usando XML

 Todo lo anterior posible usando XML,

protocolos de internet abiertos HTTP, HTTPS
 Servicios Web
E-mail WWW Servicios Web

Conecta
Conecta Personas a Conecta
Personas Información Aplicaciones
 Servicios Web

Aplicación SOAP Aplicación

TCP/IP - HTTP
 Base para los Web Services

Publicar, hallar, usar servicios: UDDI

Interacciones de servicio: SOAP

Formato universal de datos: XML

Comunicación ubicua: Internet

Simples, abiertos, amplio soporte

 Interoperatividad basada en
servicios Web XML
 Los Servicios Web XML han establecido una
mecanismo para permitir que sistemas corriendo
en plataformas completamente diferentes
interoperen de una forma estándar.

 Las aplicaciones se pueden comunicar de una

manera basada en estándares y agnóstica a la
plataforma

 ¿Cómo cambia esto la arquitectura de la

aplicación?
¿Como incorporo servicios en
mis aplicaciones?

Componentes de Interfaz de Usuario

Interfaz de Servicios

Componentes de Negocio

Componentes de
Agentes de Servicios
Acceso a Datos

Fuente de datos Servicio

 Fachadas … La clave

Interfaz Web Usuario

Base de Datos Lógica del

Negocio

Fachada Mensaje
de
Servicios
Arquitectura de los Web Services
 Arquitectura WS

Roles
Artefactos

Operaciones
 Principales Términos
 Protocolo de transporte (Transportarlos)
 HTTP/HTTPS: Principalmente
 Codificación de datos y mensajes (Invocarlos)
 SOAP: Simple Object Access Protocol
 Descripción del servicio (Describirlos)
 WSDL: Web Service Description Language
 Búsqueda y localización de servicios (Descubrirlos)
 UDDI: Universal Discovery, Description and Integration

Otra definición: Programas accesibles en Internet que exponen su

funcionalidad recibiendo/enviando mensajes SOAP a través de
HTTP(s) y describen su interfaz en WSDL
 Ciclo de vida de los WS
 Construcción (Build)
 Diseño, desarrollo y test del servicio
 Definición de la descripción de la interfaz
 Despliegue (Deploy)
 Publicación y registro del servicio
 Despliegue de los ejecutables en la Web
 Ejecución (Run)
 El servicio está operativo y accesible
 Gestión (Manage)
 Gestión y administración del servicio
 SOAP
 Simple Object Access Protocol es el estándar de-
facto para interconexión

 Permite el intercambio de información estructurada y

con tipos entre entidades (peers) descentralizados

 Codificación y empaquetamiento basado en XML

para intercambiar datos, mensajes, RPCs

 SOAP proporciona principalmente:

 La construcción ―envelope‖,
 Un conjunto de reglas de codificación,
 La representación de RPCs (convenciones)
 Ejemplo SOAP

Respuesta

Petición
 WSDL
 SOAP permite expresar invocaciones y
respuestas sueltas

 Pero también es necesario describir los servicios,

como colecciones de operaciones y respuestas

 Web Service Description Language fue

desarrollado por Microsoft e IBM para describir
servicios Web

 Independiente del método de transporte o

método de codificación final
Estructura WSDL
 UDDI
 Universal Description, Discovery and
Integration
 Desarrollado por IBM, Microsoft y Ariba

 Permite mantener un registro global de

Web Services
 Con operaciones para: publicar (publish), ojear
(browse) y retirar (un-publish) Web Services
 Registro replicado (y consistente!)
 Operado por IBM, Microsoft y HP
 Cualquier aplicación (incluidos Search engines)
pueden consultarlo para descubrir servicios
 Estructura UDDI
 Utiliza taxonomías estándares para clasificar
servicios (NAICS, UNSPSC,...)

 Almacena tres tipos de información

 White pages
 Nombre del negocio, informaciones de contacto, etc.
 Yellow Pages
 Clasificación de la compañía y el servicio (taxonomías)
 Green Pages
 Información técnica sobre los servicios, su descripción, y
cómo invocarlos
Funcionamiento UDDI
Comparación de Web Services con
Objetos y Componentes
Origen de los WS
 COTS: Commercial-Off-The-Shelf
 El Software: ¿producto o servicio?

 ¿Me interesa vender mis componentes?

 ¿Si tengo un componente bueno, quiero vendérselo
a la competencia?
 ¿Lo vendo o lo licencio?
 ¿Me interesa mantenerlo? ¿Y la formación?
 ¿Qué vende mi compañía, productos o servicios?
 ¿Qué pasa con la calidad?
 ¿Legalmente a qué me comprometo?
CORBA vs SOAP
 CORBA vs SOAP

 La arquitectura de los Web Services

 Es más simple
 Usa Internet y sus tecnologías asociadas
 Está menos optimizada
 No dispone de POA, servicios comunes o
simples, etc.

 En ambos casos existen herramientas

paraautomatizar la creación de los
listeners,proxies, stubs, skeletons, etc.
 Objetos, Componentes y
Servicios Web
Objetos Componentes Servicios Web

Perspectiva Elementos internos Elementos internos de un Elementos que se ven desde

arquitectónica de un componente sistema fuera del sistema

Modelo de Junto con la aplicación Despliegue ―físico‖ El software ―existe‖ en algún

despliegue o el componente (install-and-use) lado
(connect-and-use)
Niveles de Mayoritariamente Mayoritariamente dentro Mayoritariamente entre
intercambio de dentro de un de la empresa varias empresas
información componente software

Niveles de Fuerte Débil Muy débil

acoplamiento
Comunicación Directa Middleware Web-based
(eg. IIOP) (SOAP/XML sobre http)
Granularidad Pequeña Media-grande Media-grande
 Referencias
 Vallecillo, Antonio. El Futuro de los Servicios Web. Universidad
de Málaga
 Naranjo, Julio. Arquitectura Basada en Servicios, Microsoft.
 Álvarez, José Mauricio. EL Valor de Negocio de Arquitecturas
Orientadas a Servicios. Microsoft.
 NET Architecture Center: Service Oriented Architecture
http://msdn.microsoft.com/architecture/soa/
 Understanding Service-Oriented Architecture
http://msdn.microsoft.com/architecture/soa/default.aspx?pull=/
library/en-us/dnmaj/html/aj1soa.asp
 Patterns & Practices
http://www.microsoft.com/resources/practices
 FTPOnline: SPECIAL REPORT: Service-Oriented Architecture
http://www.ftponline.com/special/soa/
 MetaGroup – Disruptive SOA Trends - Transcript 2034
¿ Preguntas y Respuestas ?