Más contenido relacionado Similar a SEPGLA 2007 Migración a Ambientes de Arquitectura Orientada a Servicios (SOA) Grace Lewis (20) Más de Nelson Piedra (18) SEPGLA 2007 Migración a Ambientes de Arquitectura Orientada a Servicios (SOA) Grace Lewis1. Migración a Ambientes de
Arquitectura Orientada a
Servicios (SOA)
Grace A. Lewis
Software Engineering Institute, USA
Noviembre 26, 2007
© 2007 Carnegie Mellon University
Contenido
Introducción a SOA
Desde los 50,000 Pies de Altura
•
Desde los 10,000 Pies de Altura
•
Desde los 1,000 Pies de Altura
•
Pilares del Desarrollo de Sistemas Basados en SOA
Técnica para la Migración y Reutilización de Servicios (SMART)
Implicaciones para los Procesos de Desarrollo de Sistemas
Conclusiones
Conceptos Básicos
2
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
1 2. ¿Qué es SOA?
Arquitectura orientada a servicios es una manera de
diseñar, desarrollar, desplegar y administrar sistemas en la
cual
Servicios proveen funcionalidad reutilizable.
•
Las definiciones de interfaces de servicios son artefactos
•
de primera clase.
Una infraestructura SOA posibilita el descubrimiento,
•
composición e invocación de servicios.
Protocolos son en su mayoría, pero no exclusivamente,
•
intercambios de documentos basados en mensaje.
Consumidores de servicios son construidos utilizando la
•
funcionalidad brindada por los servicios disponibles.
Conceptos Básicos
3
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Servicios
Servicios son componentes reutilizables que representan
tareas del negocio.
Consulta de clientes
•
Validación de tarjeta de crédito
•
Consulta del estado del tiempo
•
Reservación de hotel
•
Servicios pueden
Estar distribuidos globalmente en múltiples organizaciones
•
Reconfigurados en nuevos procesos de negocio
•
Las definiciones de interfaces de servicios son artefactos de
primera clase, bien definidos e idealmente disponibles en un
registro de servicios
Conceptos Básicos
4
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
2 3. Infraestructura SOA
Conjunto de tecnologías que conectan consumidores de servicios a
servicios
Productos, estándares y protocolos que soportan la comunicación—
•
Típicamente intercambio de documentos basado en mensajes
Web Services (HTTP, SOAP, WSDL)
—
Message-oriented middleware (i.e. IBM Websphere MQ)
—
Publish/subscribe (i.e. Java Messaging Service — JMS)
—
CORBA …
—
Servicios de infraestructura disponibles para proveedores y/o consumidores
•
de servicios
Seguridad, descubrimiento, transformación de datos, …
—
Herramientas y guías para desarrollo, despliegue y administración
•
Conceptos Básicos
5
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Consumidores de Servicios
Clientes de la funcionalidad brindada por los servicios
Aplicaciones de usuario final
•
Sistemas internos
•
Sistemas externos
•
Servicios compuestos
•
Consumidores se conectan de forma programática a
servicios.
Conceptos Básicos
6
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
3 4. Componentes de un Sistema Basado en SOA
Aplicación Consumidor
Sistema
Usuario Portal
Externo
Interno
Final
Consumidores de
Servicios
Infraestructura SOA Internet
Herramientas
Seguridad Descubrimiento
de Desarrollo
Infraestructura
Servicio Servicio Servicio Servicio
A B C D
Interfaces de
Servicios
Sistema de
Código Nuevo o Sistema
Información
Implementación de
Existente Externo
Gerencial Servicios
Usuarios Internos
Conceptos Básicos
7
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
En Resumen …
SOA es una manera de desarrollar sistemas en la cual
Servicios contienen funcionalidad reutilizable con interfaces bien definidas.
•
Una infraestructura SOA permite el descubrimiento, composición e
•
invocación de servicios.
Consumidores de servicios son construidos utilizando funcionalidad de los
•
servicios disponibles.
Si es manejado bien, la adopción de SOA puede llevar a
Eficiencia de costos
•
Agilidad de negocios
•
Adaptabilidad
•
Aprovechamiento de la inversión en sistemas existentes
•
Conceptos Básicos
8
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
4 5. Contenido
Introducción a SOA
Desde los 50,000 Pies de Altura
•
Desde los 10,000 Pies de Altura
•
Operaciones Básicas
—
OASIS SOA Reference Model (SOA RM)
—
Web Services
—
Desde los 1,000 Pies de Altura
•
Pilares del Desarrollo de Sistemas Basados en SOA
Técnica para la Migración y Reutilización de Servicios (SMART)
Implicaciones para los Procesos de Desarrollo de Sistemas
Conclusiones
Desde los 10,000 Pies
9
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Contexto Operacional de un Sistema Basado en
SOA
Nuevas aplicaciones pueden ser creadas Organización 2
reutilizando funcionalidad existente
Organización 1 Sistema de
Infraestructura SOA
Validación de
Aplicación
Tarjetas de Crédito
de Gestión
Sistema de
de Clientes
Gestión de
FedEx
Pedidos Aplicaciones
pueden
Sistema
Aplicación
de Envíos
de Proceso interactuar
Internet
Sistema de Pedidos
con sistemas
UPS
Financiero
de diferentes
Firewall
Sistema organizaciones
de Envíos
Aplicaciones a través de
pueden interfaces
DHL
interactuar con Organizaciones estándar
Organización
sistemas externas Sistema
Cliente de Envíos
internos a través pueden acceder
Aplicación de
de interfaces a funcionalidad Pedidos
Aplicaciones pueden automatizar sus
estándar interna
procesos utilizando funcionalidad externa
Operaciones Básicas
10
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
5 6. Tres Operaciones Básicas Para Soportar
Sistemas Basados en SOA
Descubrimiento de Servicios
Repositorios de servicios son consultados buscando servicios con ciertas
•
características.
Composición de Servicios
Aplicaciones/Consumidores de servicios son construidos mediante la
•
integración de funcionalidad brindada por servicios.
Invocación de Servicios
Los consumidores invocan los servicios necesarios y el código
•
correspondiente a la implementación de los servicios es ejecutado.
Operaciones Básicas
11
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Estático vs. Dinámico
Estático—Con la tecnología actual, el descubrimiento y la composición de
servicios se hace durante diseño del sistema.
El desarrollador descubre servicios y obtiene sus direcciones.
•
El desarrollador escribe código para invocar los servicios localizados en estas
•
direcciones.
Dinámico—Hay una gran cantidad de investigación en el área de descubrimiento
y composición de servicios en tiempo de ejecución.
La aplicación descubre servicios y obtiene direcciones.
•
La aplicación contiene código para invocar el servicio descubierto y “sabe” que
•
información es necesaria para la ejecución del servicio.
Hay muchas técnicas Intermedias.
La aplicación descubre los servicios, pero se requiere intervención del usuario para
•
seleccionar servicios y proveer la información requerida.
“Portals” son configurados del tal manera que sus “portlets” corresponden a servicios.
•
Operaciones Básicas
12
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
6 7. Descubrimiento de Servicios
Mayores retos: Descripción de servicios y
Desarrolladores de
mantenimiento del repositorio
consumidores de
servicios consultan el
registro buscando Hay algún servicio que
Aplicación
Aplicación
servicios que pueda devolver toda la
de
de Proceso
contengan una Facturación información de un cliente
de Pedidos
funcionalidad deseada. dado un código de cliente?
Servicios son
Infraestructura SOA Descubrimiento
registrados en un
Registro de
Herramientas
Registro de Servicios
Seguridad Servicios
de Desarrollo
que es parte de la
infraestructura SOA.
El Sistema de Gestión de
Sistema de Sistema Sistema de Clientes registra sus dos
Gestión de Financiero Gestión de servicios
Pedidos Clientes - Búsqueda de Clientes
- Directorio de Clientes
Operaciones Básicas
13
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Composición de Servicios
Mayores retos: La aplicación de proceso de pedidos
necesita producir un reporte impreso
Incompatibilidad de Aplicación
que para un cliente contenga
de Proceso
procesos/datos y manejo de de Pedidos información del cliente, estado
transacciones financiero y pedidos pendientes.
Infraestructura SOA Descubrimiento
Registro de
Herramientas
Seguridad Servicios
de Desarrollo
El servicio de
Búsqueda de
Clientes es
El servicio de
utilizado para
Sistema Sistema de
Sistema de
Pedidos
obtener la
Financiero Gestión de
Gestión
Pendientes es
información del
Clientes
Pedidos
invocado para
cliente.
obtener los
El servicio de Estado Financiero
pedidos
Cliente es invocado para obtener
pendientes.
el saldo del cliente.
Operaciones Básicas
14
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
7 8. Invocación de Servicios
1
Service Request
Mayor reto:
Service Response
Trabajar con
servicios que
2
Consumidor de Servicios
Service Query
pueden no estar
Discovery
disponibles
Service Location
Service Request
Service Response
Servicio
3
Service Query
Service
Service Location
Broker
Service Location
Service Query
Discovery
Discovery
Discovery
Service Request
Service Response
Operaciones Básicas
15
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
¿Entonces Qué Es Diferente?
Conceptualmente no hay nada nuevo, pero, finalmente se han integrado
tecnologías y prácticas existentes en una manera que realmente funciona.
Mayor alineamiento entre TI y el negocio
•
Servicios representan tareas/actividades del negocio
—
Gran apoyo por parte de la industria
•
Basado en estándares
•
Mayor rigor en la especificación de interfaces
•
Verdadero acoplamiento débil entre servicios y consumidores
•
Consumidores no tiene que instalar componentes específicos
—
Independencia de la plataforma de implementación
—
Lo que está detrás de la interface es irrelevante para el consumidor
o
del servicio
Operaciones Básicas
16
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
8 9. ¿Entonces Cuál Es El Reto? ¡Crear Buenos
Servicios!
Representan tareas comunes de múltiples casos de uso o procesos del
negocio
Tienen (o pueden tener) múltiples consumidores
Posibilitan la integración programática entre consumidores y servicios
Corresponden a funcionalidad que no requiere mantener un estado (el
servicio no conserva información acerca de pasadas invocaciones o el
orden en que debe ser invocado)
Las entradas y salidas de sus operaciones no requieren la construcción
de consumidores muy complejos
Miremos una definición
Son de naturaleza “request-response” más formal de SOA …
Aunque SOA 2.0 introduce el manejo de eventos
•
Operaciones Básicas
17
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
OASIS SOA RM
Modelo de referencia para SOA
Objetivo es “definir la esencia de la arquitectura orientada servicios, y
construir un vocabulario y un entendimiento común acerca de SOA.”
Independiente de la tecnología de implementación
Versión 1.0 (Octubre 2006) disponible en
http://www.oasis-open.org/specs/index.php#soa-rmv1.0
Fuente: OASIS SOA RM v1.0
OASIS SOA RM
18
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
9 10. Definiciones Básicas
“Arquitectura Orientada a Servicios es un paradigma para organizar y
utilizar capacidades distribuidas que pueden estar bajo el control de
diferentes dueños. Brinda una manera uniforme de ofrecer, descubrir,
interactuar y utilizar capacidades para producir efectos deseados que
son consistentes con precondiciones y expectativas medibles.”
“Un servicio es la manera mediante la cual las necesidades de un
consumidor son reunidas con las capacidades de un proveedor.”
Fuente: OASIS SOA RM v1.0
OASIS SOA RM
19
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Características de Sistemas Basados en SOA
Tienen entidades que pueden ser identificadas como
servicios de acuerdo con la definición del modelo
Permiten identificar cómo se establece visibilidad entre
proveedores y consumidores de servicios
Ahora miremos
Permiten identificar cómo es mediada la interacción
Web Services
Permiten identificar el efecto de utilizar servicios como una
implementación
Tienen descripciones asociadas a servicios
específica de SOA
Permiten la identificación del contexto de ejecución …
requerido para soportar la interacción
Puede ser posible identificar cómo son manejadas las
políticas y cómo los contratos pueden ser modelados y
obligar su cumplimiento
Fuente: OASIS SOA RM v1.0
OASIS SOA RM
20
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
10 11. Web Services
Web Services es un mecanismo para la implementación de sistemas
basados en SOA.
Interfaces de servicios son descritas utilizando Web Services Description
•
Language (WSDL).
Datos son transmitidos utilizando SOAP sobre HTTP.
•
UDDI es opcionalmente utilizado como el servicio de directorio.
•
Debido a que es el mecanismo más común, con frecuencia Web Services
es utilizado como un equivalente de SOA.
Web Services
21
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Stack de Protocolos de Web Services
• Los estándares en verde
Orchestration and
son los más utilizados y
Choreography
más estables, los
WSCL, WSCI, BPEL,
amarillos están
WS-Coordination
emergiendo como
BPML, BPSS
estándares de
Quality of Service
Discovery
Management
Transactions
preferencia, y los rojos
UDDI
Security
están desapareciendo.
Description
• La mayoría de estándares
WSDL
para Web Services están
Message Format
emergiendo y algunos
Base
SOAP, REST
Stack
incluso compiten.
Encoding
• Seguridad, QoS,
XML
Transacciones y
Transport Administración tienen que
HTTP
manejarse en todos los
Adapted from “XML and Web Services Unleashed”, SAMS Publishing
niveles.
Web Services
22
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
11 12. Web Services en Tiempo de Diseño—Estático
Bob (proveedor Alice Alice utiliza el Alice adiciona
de servicios) (consumidor de documento código a su
expone servicios) WSDL como aplicación que
funcionalidad en obtiene el entrada para ejecuta el código
su sistema como documento herramientas de construcción
un Web Service WSDL que que generan de mensajes
(o crea un Web corresponde al todo el código para conectarse
Service Web Service de para al Web Service
específico) y Bob (e.g. busca construcción de de Bob y código
coloca un en el repositorio mensajes (e.g. adicional que
documento UDDI). WSDL2Java). utiliza la
WSDL en un respuesta del
“lugar accesible” Web Service de
(e.g. repositorio Bob.
UDDI).
Web Services
23
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Web Services en Tiempo de Diseño—Dinámico
Bob (proveedor Alice Alice escribe Alice escribe
de servicios) crea (consumidor de código en su código en su
un Web Service, servicios) aplicación que aplicación que
lo describe escribe código selecciona un invoca el
utilizando WSDL, en su aplicación servicio de la servicio
y lo registra en un que consulta el lista retornada seleccionado
repositorio de repositorio de por la consulta. con los
servicios (e.g. servicios en parámetros
UDDI). tiempo de apropiados.
ejecución.
Para que esto sea completamente transparente, Alice y Bob tienen que
compartir una ontología utilizada para describir la semántica del servicio.
Web Services
24
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
12 13. Web Services en Tiempo de Ejecución
HTTP
Request Call
Return
HTTP
Usuario de la Servidor HTTP Sistema de Bob
Response
Aplicación de
Alice
1. Usuario ejecuta 3. Cuando el servidor
5. El sistema de Bob
la aplicación de HTTP de Bob ve un
ejecuta la operación
Alice. mensaje SOAP, lo
invocada.
envía al SOAP
2. Aplicación
engine. 6. El sistema de Bob
construye un
retorna los
mensaje SOAP 4. El SOAP engine
resultados de la
y lo envía al interpreta el mensaje y
operación.
servicio de Bob construye el llamado al
vía HTTP. sistema de Bob.
8. La aplicación de 7. El SOAP engine
Alice interpreta construye el mensaje
la respuesta y de respuesta y lo
muestra retorna vía HTTP.
resultados al
usuario.
Web Services
25
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
En Resumen …
• Ambientes SOA tienen que soportar tres operaciones básicas.
Descubrimiento de servicios
•
Composición de servicios
•
Invocación de servicios
•
• Conceptualmente, no hay nada diferente en SOA
Lo que pasa es que las tecnologías y las prácticas que soportan la
•
integración de sistemas se están utilizando en una manera que funciona.
• El OASIS SOA RM presenta una definición muy abstracta de SOA,
servicio y sistema basado en SOA que está abierta a múltiples
interpretaciones
• Web Services es el mecanismo más utilizado para la implementación de
SOA—pero no el único
Desde los 10,000 Pies
26
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
13 14. Contenido
Introducción a SOA
Desde los 50,000 Pies de Altura
•
Desde los 10,000 Pies de Altura
•
Desde los 1,000 Pies de Altura
•
Pilares del Desarrollo de Sistemas Basados en SOA
Técnica para la Migración y Reutilización de Servicios (SMART)
Implicaciones para los Procesos de Desarrollo de Sistemas
Conclusiones
Desde los 1,000 Pies de Altura
27
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Un Potencial Problema
Si servicios, consumidores de servicios e infraestructura SOA son
desarrollados por la misma organización, los retos son menores.
La comunicación es más simple entre desarrolladores (o quizás son los
•
mismos desarrolladores)
Sin embargo, es cada vez más común encontrar que los tres tipos de
componentes son desarrollados por diferentes organizaciones de manera
independiente—es un nuevo modelo de negocios.
Las decisiones tomadas localmente por cada uno de estos grupos de
•
desarrollo puede tener un efecto sobre los demás grupos.
Desde los 1,000 Pies de Altura
28
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
14 15. Consumidores de Servicios 4. Diseñar la aplicación de tal
manera que pueda fácilmente
acomodar cambios en los servicios
2. Entender la infraestructura y las
Organización 2
interfaces de servicios en términos de
funcionalidad y calidad de servicios
Sistema de
Organización 1
Validación de
Infraestructura SOA
Tarjetas de Crédito
Aplicación
de Gestión
Sistema de
de Clientes
FedEx
Gestión de
Pedidos Sistema
de Envíos
Aplicación
Internet
de Proceso 1. Identificar
Sistema de Pedidos servicios
UPS
Financiero apropiados
Firewall
Sistema (internos y
de Envíos
3. Crear la nueva externos) que
aplicación utilizando puedan ser
tantos servicios Organización DHL reutilizados
como sea posible
Cliente Sistema
Un consumidor de servicios de Envíos
Aplicación de
necesita crear una nueva aplicación Pedidos
5. ¡¡Pruebas!!
basada en SOA.
Desde los 1,000 Pies de Altura
29
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Retos para Consumidores de Servicios
Servicios disponibles pueden no satisfacer requerimientos funcionales y
no funcionales.
Servicios pueden cambiar o desaparecer sin notificación.
Herramientas y programas que hacen parte de la infraestructura pueden
ser incompatibles con el ambiente de desarrollo.
Servicios pueden ser semánticamente incompatibles desde el punto de
vista del consumidor.
Servicios provenientes de diferentes organizaciones pueden ser
inconsistentes.
La prueba total del sistema requiere que instancias de prueba de todos los
servicios estén disponibles.
Desde los 1,000 Pies de Altura
30
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
15 16. Desarrolladores de Servicios
3. Anticipar requerimientos de futuros
consumidores Organización 2
Organización 1 Sistema de
Infraestructura SOA
Validación de
Aplicación Tarjetas de
de Gestión
Sistema de Crédito
de Clientes
Gestión de
FedEx
Pedidos
Sistema
Aplicación
de Envíos
de Proceso
Internet
Sistema de Pedidos
Financiero UPS
Sistema
de Envíos
2. Analizar
1. Identificar 4. Diseñar, crear y requerimientos de la
funcionalidad de DHL
publicar servicios infraestructura,
negocios que pueda para consumidores interfaces, Sistema
ser expuesta como internos y/o de Envíos
funcionalidad y QoS de
un servicio externos consumidores
Desde los 1,000 Pies de Altura
31
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Retos para Desarrolladores de Servicios
Si requerimientos de consumidores no son entendidos, los servicios
podrían nunca ser utilizados.
El esfuerzo de transformación de tipos de datos podría ser mayor de lo
esperado.
En ambientes SOA propietarios podrían existir
Múltiples restricciones sobre los servicios desarrollados
•
Dependencias en herramientas y programas de la infraestructura que están
•
en conflicto con el ambiente de desarrollo
Aún no existen guías claras para el desarrollo de Acuerdos de Nivel de
Servicios (SLAs).
Desde los 1,000 Pies de Altura
32
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
16 17. Desarrolladores de Infraestructura
Herramientas para
Selección de
desarrolladores de
productos y
servicios y consumidores
Organización 2
estándares
Organización 1 Sistema de
Infraestructura SOA
Validación de
Aplicación
Tarjetas de
Seguridad de Gestión
Sistema de Crédito
de Clientes
Gestión de
FedEx
Herramientas
Pedidos de Desarrollo
Sistema
Aplicación
de Envíos
de Proceso
Sistema Descubrimiento Internet
de Pedidos
Financiero
UPS
Registro de
Servicios
Sistema
de Envíos
Servicios de
Mecanismos de DHL
Infraestructura Documentación conexión
Sistema
y soporte
de Envíos
Desde los 1,000 Pies de Altura
33
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Retos para Desarrolladores de Infraestructura
Minimizar el efecto de cambios en estándares y productos utilizados por la
infraestructura sobre sus usuarios.
Especialmente estándares emergentes
•
Estimar correctamente el esfuerzo para el desarrollo, soporte y
entrenamiento a usuarios.
Desde los 1,000 Pies de Altura
34
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
17 18. Granularidad de Servicios 1
La granularidad de las interfaces de servicio puede afectar desempeño
porque los servicios son ejecutados como el intercambio de una petición
de servicio y una respuesta del servicio a través de una red.
Si las interfaces de servicio son de alta granularidad, sus consumidores van a
•
recibir más datos de los necesarios en el mensaje de respuesta.
Si las interfaces de servicio son de baja granularidad, sus consumidores van
•
a tener que hacer múltiples viajes al servicio para obtener los datos
necesarios.
Desde los 1,000 Pies de Altura
35
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Granularidad de Servicios 2
… o el servicio puede ser más granular y
tener tres operaciones diferentes para los
tres tipos de información
InfoCliente getInfoBasica( IdCliente )
Sistema de
Gestión de HistPedidos getHistoriaPedidos( IdCliente)
Pedidos Pedido[] getPedidosPendientes( IdCliente )
[Info Básica, Historia Pedidos, Pedidos Pendientes]
getInfoCliente( IdCliente )
El Sistema de Gestión de Pedidos puede exponer
la funcionalidad de obtener toda la información
de un cliente como una sola operación …
Desde los 1,000 Pies de Altura
36
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
18 19. Manejo de Transacciones 1
La decisión de asignación de responsabilidad del manejo de
transacciones tiene un efecto sobre el desarrollo de sistemas basados en
SOA.
Escenario
La Aplicación de Proceso de Pedidos necesita colocar un pedido.
•
Tres sistemas están involucrados
•
El Sistema de Gestión de Pedidos controla la creación del pedido.
—
El Sistema Financiero contiene la información financiera del cliente.
—
El Sistema de Inventarios contiene información sobre partes y cantidad
—
en inventario.
Un pedido se considera completo después de verificar el estado financiero
•
del cliente y las partes en inventario son marcadas para envío.
Desde los 1,000 Pies de Altura
37
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Manejo de Transacciones 2
Responsabilidad: Proveedor de Servicios NOTA: El
proveedor de
1. Aplicación servicio podría
invoca el decidir hacer
2. Infraestructura Aplicación
6. Aplicación
servicio llamados directos
de Proceso
localiza el servicio recibe el estado de
colocarPedido. en vez de utilizar
de Pedidos
colocarPedido. la operación.
las interfaces de
↓ colocarPedido
servicio
Infraestructura SOA
↓ colocarPedido ↓ marcarInventario ↓ getInfoFinanciera
Sistema de Sistema
Sistema
Gestión de de
Financiero
Pedidos Inventario 4. Sistema de Gestión de
Pedidos invoca
5. Sistema de Gestión de getInfoFinancera.
3. Sistema de Gestión
Pedidos invoca
de Pedidos inicia
marcarInventario.
transacción
Desde los 1,000 Pies de Altura
38
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
19 20. Manejo de Transacciones 3
Responsabilidad: Infraestructura NOTA:
Dependiendo de
2. Infraestructura
la
1. Aplicación invoca
sabe que es una
implementación,
el servicio
operación Aplicación
6. Aplicación las operaciones
colocarPedido.
transaccional e de Proceso
recibe el estado de
podrían requerir
inicia transacción. de Pedidos
la operación. operaciones
↓ colocarPedido compensatorias.
Infraestructura SOA
↓ crearPedido ↓ marcarInventario ↓ getInfoFinanciera
Sistema de Sistema
Sistema 3. Infraestructura invoca
Gestión de de
Financiero getInfoFinanciera.
Pedidos Inventario
4. Infraestructura invoca
5. Infraestructura
marcarInventario.
invoca crearPedido.
Desde los 1,000 Pies de Altura
39
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Manejo de Transacciones 4
Responsabilidad: Consumidor de Servicios NOTA:
Dependiendo de
la
implementación,
2. Aplicación las operaciones
Aplicación
invoca los tres podrían requerir
de Proceso
1. Aplicación inicia servicios. operaciones
de Pedidos
transacción. compensatorias.
↓ getInfoFinanciera
↓ marcarInventario
↓ crearPedido
Infraestructura SOA
↓ crearPedido ↓ marcarInventario ↓ getInfoFinanciera
Sistema de Sistema
Sistema
Gestión de de
Financiero
Pedidos Inventario
Desde los 1,000 Pies de Altura
40
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
20 21. En Resumen …
Hay tres grupos de desarrollo en un sistema basado en SOA.
Desarrollo de consumidores de servicios
•
Desarrollo de proveedores de servicios
•
Desarrollo de la infraestructura
•
Entre más distribuidos estos grupos de desarrollo, mayores los retos del
desarrollo de sistemas basados en SOA.
Desde los 1,000 Pies de Altura
41
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Contenido
Introducción a SOA
Pilares del Desarrollo de Sistemas Basados en SOA
Técnica para la Migración y Reutilización de Servicios (SMART)
Implicaciones para los Procesos de Desarrollo de Sistemas
Conclusiones
Pilares
42
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
21 22. Pilares del Desarrollo de Sistemas Basados en
SOA
Desarrollo de Sistemas
Basados en SOA
Evaluación de
Alineamiento
Governance
Estratégico
Mentalidad
Tecnología
Cambio de
SOA
Principios de Diseño para SOA
Pilares
43
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Alineamiento con Objetivos del Negocio
Cualquier estrategia SOA exitosa tiene que estar alineada con los
objetivos del negocio.
Ejemplos
Reducir tiempo de mercado para aplicaciones
•
Incrementar información disponible a clientes
•
Integrar partners de negocio
•
Reducir costo de desarrollo mediante reutilización
•
Reducir costo de mantenimiento
•
Mejorar servicio al cliente
•
Mejorar procesos internos
•
Pilares: Alineamiento Estratégico
44
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
22 23. Diferentes Necesidades y Objetivos de Negocio
Requieren Diferentes Estrategias SOA
Necesidades y Objetivos Estrategia SOA
del Negocio
Incrementar información Portals intuitivos
•
disponible para los clientes Creación de servicios relacionados con
•
del negocio información de interés para clientes
Integrar partners de negocio Interoperabilidad heterogénea
•
Integración de sistemas internos
•
Identificación de reglas del negocio
•
Mejorar procesos de negocio Identificación de procesos clave
•
Eliminación de redundancia
•
Consistencia entre procesos
•
Servicios que utilizan sistemas
•
existentes
Pilares: Alineamiento Estratégico
45
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Relación entre Procesos de Negocio y
Servicios
1. Identificar procesos de negocio que apoyan los objetivos del
negocio.
2. Identificar candidatos para servicios.
De arriba hacia abajo (Top-Down)
•
Pasos comunes entre procesos de negocio se convierten en
—
candidatos para servicios.
De abajo hacia arriba (Bottom-Up)
•
Hacer un inventario de los sistemas existentes.
—
Sistemas con funcionalidad que apoya los procesos de negocio
—
se convierten en candidatos para migración a servicios.
3. Servicios son seleccionados y priorizados con base en su
relación con los objetivos del negocio.
Pilares: Alineamiento Estratégico
46
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
23 24. Adopción Disciplinada de SOA
Adaptado de “Meeting the Challenges of SOA Adoption,” keynote de Roy Schulte en la SOA In Action Virtual Conference,
Noviembre 2006.
Pilares: Alineamiento Estratégico
47
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Falta de Governance Inhibe la Adopción de
SOA
Una encuesta de Infoworld llamada 2007 SOA Trend Survey indica
que la falta de governance es el inhibidor principal de la adopción
de SOA (50%).
En la encuesta del 2006 era 43%.
•
Mayor que otros inhibidores que parecen más obvios
Dificultad para construir un SOA roadmap (40%)
•
Desempeño y confiabilidad (39%)
•
Estándares incompletos e inmaduros (39%)
•
Pilares: SOA Governance
48
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
24 25. SOA Governance
SOA governance es el conjunto de políticas, reglas y mecanismos
de cumplimiento para el desarrollo, utilización y evolución de
elementos de un sistema basado en SOA y el para el análisis de
su valor para el negocio.
Políticas y procedimientos
•
Roles y responsabilidades
•
Governance en tiempo de diseño
•
Governance en tiempo de ejecución
•
Fuente: Integration and SOA: Concepts, Technologies and Best Practices. Beth Gold-Bernstein & Gary So.
Pilares: SOA Governance
49
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Governance en Tiempo de Diseño
Conjunto de reglas y procedimientos que buscan alineamiento
estratégico y consistencia en el diseño y despliegue de servicios
Identificación de servicios
•
Procesos de desarrollo (ciclo de vida completo)
•
Diseño para medición y monitoreo
•
Uso de estándares
•
Acceso a la infraestructura
•
Migración de componentes
•
Evaluación y selección de tecnología
•
Gestión de acuerdos de nivel de servicio (SLAs)
•
Pilares: SOA Governance
50
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
25 26. Governance en Tiempo de Ejecución
Reglas que buscan el cumplimiento de políticas
Ejecución de servicios en maneras legales
•
Seguridad
•
Reemplazo de servicios
•
Consistencia en interacción con la infraestructura
•
Colección de métricas
Validación de cumplimiento de SLAs
•
Identificación de problemas
—
Métricas, colección de datos, reportes y recuperación
•
Frecuencia de uso
—
Identificación de excepciones a las reglas
—
Identificación de áreas problemáticas
—
Manejo de problemas
Pilares: SOA Governance
51
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Beneficios de SOA Governance
Mayor alineamiento con los objetivos del negocio
Mayor control sobre la creación, despliegue y utilización de servicios
Centralización de políticas y reglas
Incrementa la posibilidad de automatización
•
Posibilidad de incluir mecanismos de cumplimiento con reglamentación
gubernamental o industrial
Sarbanes-Oxley, HIPAA, GLBA
•
Pilares: SOA Governance
52
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
26 27. Retos para la Implementación de SOA
Governance
Parece “al revés”
¿Si SOA es acoplamiento débil y flexibilidad, por qué tanto
•
control? ¡Automatización es clave! ¡ Registro es crucial!
Múltiples organizaciones
¿ Cómo crear governance para proveedores de servicio,
•
proveedores de infraestructura y consumidores de servicios?
¿Qué pasa si las políticas están en conflicto?
Manejo de excepciones
¿Cómo registrar y manejar excepciones a las reglas que son
•
necesarias?
Obligación de cumplimiento
¿Cómo hacer para asegurar que políticas y procedimientos se
•
cumplan en tiempo de diseño y de ejecución? ¿Cuáles son los
incentivos para el cumplimiento?
Pilares: SOA Governance
53
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Encontrar la Tecnología Adecuada para el
Problema
Se necesita un verdadero entendimiento de lo que diferentes
tecnologías pueden hacer en un dominio específico.
¿Cómo entender y mantenerse al tanto de la “sopa de letras”?
¿XML, SOAP, WSDL, UDDI, WS-Security?
•
¿Cómo determinar cuáles estándares y tecnologías
implementar en situaciones específicas?
¿Cómo construir sistemas que aguanten cambios en
estándares y los productos comerciales que los implementan?
¿Cómo determinar si tecnologías seleccionada van a satisfacer
requerimientos de calidad de servicio? ¿Seguridad?
¿Disponibilidad? ¿Desempeño?
Todas estas preguntas sugieran la necesidad de experimentación contextual
Pilares: Evaluación de Tecnología
54
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
27 28. T-CheckSM
Context
Experimento con el objetivo de verificar el
comportamiento de una tecnología en un Develop
contexto específico Hypotheses
Pasos Develop
Criteria
1. Formular hipótesis acerca de la tecnología
2. Examinar estas hipótesis contra criterios Design and
Implement Solution
muy específicos mediante experimentación
Extremadamente eficiente Evaluate Solution
Against Criteria
La idea es implementar el experimento más
•
simple posible que permita validar o [Hypotheses Sustained] [Hypotheses Refuted]
contradecir la hipótesis
El principio es que si el experimento falla en
•
lo simple, va a fallar en lo complejo
Pilares: Evaluación de Tecnología
55
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Ejemplo de T-Check: Contexto
Organización migrando un conjunto de aplicaciones y bases de
datos de imágenes a una solución basada en Web Services
Objetivo: Establecer factibilidad de
Adaptar sistemas actuales
•
Mantener (o mejorar) tiempo de respuesta actual
•
Transferir imágenes
•
Tener un punto único de autenticación (single sign-on)
•
Pilares: Evaluación de Tecnología
56
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
28 29. Ejemplo de T-Check: Hipótesis y Criterios de
Evaluación
Hipótesis Criterios de Evaluación
75% o más de las 1. Hay librerías SOAP que pueden ser fácilmente
aplicaciones pueden ser integradas a 75% o más aplicaciones.
adaptadas a tecnologías
2. Sino, existe un mapeo claro entre tipos de datos
de Web Services.
nativos y tipos de datos de XML Schema que facilite
la construcción e interpretación manual de mensajes
SOAP.
El tiempo de respuesta El tiempo de respuesta utilizando Web Services será del
no será degradado mismo orden de magnitud que los tiempos de respuesta
debido al uso de Web actuales de aplicaciones representativas.
Services.
Imágenes pueden ser Una imagen puede ser solicitada utilizando Web
transmitidas como parte Services y visualizada en una aplicación cliente.
de mensajes SOAP.
Es posible tener single Un usuario hace login una vez y pude obtener
sign-on utilizando Web información de tres Web Services diferentes en tres
Services. máquinas diferentes.
Pilares: Evaluación de Tecnología
57
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
El Desarrollo de Sistemas Basados en SOA
Requiere un Enfoque Diferente
Desarrollo de Sistemas Desarrollo de Sistemas Basados
Tradicionales en SOA
Acoplamiento fuerte entre Acoplamiento débil entre
componentes del sistema consumidores y servicios
Semántica compartida Tecnologías permiten compartir
explícitamente en tiempo de semántica sin mayor comunicación
desarrollo entre servicios y consumidores– en el
futuro incluso en tiempo de ejecución
Conjunto conocido de usuarios y Conjunto potencialmente
patrones de uso desconocido de usuarios de servicios
y patrones de uso
Componentes del sistema Componentes del sistema
pertenecen a la misma potencialmente pertenecen a
organización múltiples organizaciones
Pilares: Cambio de Mentalidad
58
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
29 30. Menos Control
Requiere abandonar la idea de control completo—no es fácil
La ventaja es agilidad del negocio
•
Automatización de governance es clave
•
Hay que anticipar las objeciones y entender su validez
Seguridad
•
Desempeño
•
Control
•
Mayores retos proviene de
Puede no existir una única organización que sea dueña del sistema completo
•
Servicios pueden potencialmente ser utilizados de manera desconocida por
•
usuarios desconocidos
Se necesita educación y entrenamiento en esta nueva mentalidad.
Pilares: Cambio de Mentalidad
59
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Contenido
Introducción a SOA
Pilares del Desarrollo de Sistemas Basados en SOA
Técnica para la Migración y Reutilización de Servicios (SMART)
Implicaciones para los Procesos de Desarrollo de Sistemas
Conclusiones
SMART
60
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
30 31. Reutilización en el Contexto SOA
Reutilización a un más alto nivel
Reutilización de funcionalidad de negocio
•
Encapsulación de detalles técnicos
•
Reutilización entre organizaciones
Nuevo modelo de negocios
•
Organizaciones pueden “vender” sus capacidades como servicios
—
Funcionalidad puede ser adquirida en vez de desarrollada—potencial ahorro
•
Opción para mantener la inversión en sistemas existentes
En muchos casos, componentes pueden ser expuestos como servicios,
•
independiente del proveedor, plataforma y tecnología
SMART: Introducción
61
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Aspectos Que Pueden Complicar la Migración
Comunidad de usuarios
Pequeña vs. grande
•
Conocida vs. desconocida
•
Requerimientos tecnológicos del ambiente
Estándar vs. propietario
•
Requerimientos de calidad de servicio
•
Características de los sistemas existentes
Pobre modularización de código (separation of concerns)
•
Disponibilidad de herramientas
•
Incompatibilidad entre arquitecturas (architectural mismatch)
•
Incompatibilidad operacional (operational mismatch)
•
Dependencias en productos comerciales
•
SMART: Introducción
62
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
31 32. Service Migration and Reuse Technique (SMART)
SMART analiza la factibilidad de reutilizar componentes como la base
para servicios mediante la búsqueda de respuestas a las siguientes
preguntas:
¿Tiene sentido migrar el sistema a servicios?
•
¿Qué servicios son apropiados?
•
¿Qué componentes tienen la funcionalidad para satisfacer estos servicios?
•
¿Qué cambios hay que hacer para la migración?
•
¿Qué estrategias de migración son las más apropiadas?
•
¿Cuáles son las estimaciones preliminares de costo y riesgo?
•
SMART: Introducción
63
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Tres Elementos de SMART
Cuestionario para la
Proceso Migración a Artefactos
Servicios (SMIG)
Recoge información Guía la discusión en las Lista de Stakeholders
•
acerca de actividades iniciales de Lista de Características
•
SMART
• Objetivos y expectativas
Lista de Riesgos de
•
de la migración
Migración
• Servicios candidatos
Mapeo entre Procesos de
•
• Sistemas /componentes a
Negocio y Servicios
migrar
Tabla de Servicios
•
• Ambiente SOA
Tabla de Componentes
Analiza el gap entre el •
sistema existente y el Arquitectura de Alto Nivel del
•
ambiente SOA Sistema SOA
Alternativas Servicio-
•
Componentes
Estrategia de Migración
•
SMART: Elementos
64
Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
32