1
© 2007 Carnegie Mellon University
Migración a Ambientes de Arquitectura Orientada a Servicios (SOA)
Grace A. LewisSoftware Engineering Institute, USANoviembre 26, 2007
2Versión 1.5 (SEPG-LA 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
3Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
¿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
4Versió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
3
5Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
6Versió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
4
7Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Componentes de un Sistema Basado en SOA
Aplicación Usuario
Final
Servicio A
Infraestructura SOA
Sistema de Información
Gerencial
Portal
Internet
Sistema Externo
Servicio B
Servicio C
Servicio D
Usuarios Internos
DescubrimientoSeguridadHerramientas de Desarrollo
Código Nuevo o Existente
Sistema Interno
Consumidores de Servicios
Infraestructura
Implementación de Servicios
Interfaces de Servicios
Consumidor Externo
Conceptos Básicos
8Versió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
5
9Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
10Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Contexto Operacional de un Sistema Basado en SOA
Sistema de Gestión de
Pedidos
Sistema Financiero
Organización 1Organización 2
Sistema de Validación de
Tarjetas de Crédito
Infra
estru
ctu
ra S
OA
Aplicación de Proceso de Pedidos
Aplicación de Gestión de Clientes
Sistema de Envíos
FedEx
Sistema de Envíos
UPS
Sistema de Envíos
DHL
Aplicación de Pedidos
Organización Cliente
Aplicaciones pueden
interactuar con sistemas de diferentes organizaciones a través de interfaces estándar
Aplicaciones pueden
interactuar con sistemas
internos a través de interfaces estándar
Organizaciones externas
pueden acceder a funcionalidad
internaAplicaciones pueden automatizar sus
procesos utilizando funcionalidad externa
Nuevas aplicaciones pueden ser creadas reutilizando funcionalidad existente
Fire
wa
ll
Internet
Operaciones Básicas
6
11Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
12Versió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
7
13Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Descubrimiento de Servicios
Sistema Financiero
Aplicación de Proceso de Pedidos
Aplicación de
Facturación
Sistema de Gestión de
Pedidos
Sistema de Gestión de
Clientes
Servicios son registrados en un
Registro de Servicios que es parte de la infraestructura SOA.
El Sistema de Gestión de Clientes registra sus dos servicios- Búsqueda de Clientes- Directorio de Clientes
Desarrolladores de consumidores de servicios consultan el registro buscando servicios que contengan una funcionalidad deseada.
Hay algún servicio que pueda devolver toda la información de un cliente dado un código de cliente?
Infraestructura SOA Descubrimiento
SeguridadHerramientas de Desarrollo
Registro de Servicios
Operaciones Básicas
Mayores retos: Descripción de servicios y mantenimiento del repositorio
14Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Composición de Servicios
Sistema Financiero
Aplicación de Proceso de Pedidos
Sistema de Gestión Pedidos
Sistema de Gestión de
Clientes
La aplicación de proceso de pedidos necesita producir un reporte impreso que para un cliente contenga información del cliente, estado financiero y pedidos pendientes.
Infraestructura SOA Descubrimiento
SeguridadHerramientas de Desarrollo
Registro de Servicios
El servicio de Estado Financiero Cliente es invocado para obtener el saldo del cliente.
El servicio de Búsqueda de Clientes es utilizado para obtener la información del cliente.
El servicio de Pedidos Pendientes es invocado para obtener los pedidos pendientes.
Operaciones Básicas
Mayores retos: Incompatibilidad de procesos/datos y manejo de transacciones
8
15Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
DiscoveryDiscovery
Invocación de Servicios
Co
ns
um
ido
r d
e S
erv
icio
sService Request
Service Response
1
Service Request
Service Response
2
Service Query
Service Location
Service Request
Service Response
3
Service Query
Service Location
Service Query
Service Location
Servicio
Discovery
Discovery
Service Broker
Operaciones Básicas
Mayor reto: Trabajar con servicios que pueden no estar disponibles
16Versió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
o Lo que está detrás de la interface es irrelevante para el consumidor del servicio
Operaciones Básicas
9
17Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
¿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
Son de naturaleza “request-response”
• Aunque SOA 2.0 introduce el manejo de eventos
Miremos una definición más formal de SOA …
Operaciones Básicas
18Versió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
10
19Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
20Versió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
Permiten identificar cómo es mediada la interacción
Permiten identificar el efecto de utilizar servicios
Tienen descripciones asociadas a servicios
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
Ahora miremos Web Services como una implementación específica de SOA …
11
21Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
22Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Stack de Protocolos de Web Services
• Los estándares en verde son los más utilizados y más estables, los amarillos están emergiendo como estándares de preferencia, y los rojos están desapareciendo.
• La mayoría de estándares para Web Services están emergiendo y algunos incluso compiten.
• Seguridad, QoS, Transacciones y Administración tienen que manejarse en todos los niveles.
DiscoveryUDDI
DescriptionWSDL
Message FormatSOAP, REST
EncodingXML
TransportHTTP
Security
Man
age
me
nt
Tra
nsactio
ns
Qu
ality
of S
erv
ice
Orchestration and
ChoreographyWSCL, WSCI, BPEL,
WS-Coordination
BPML, BPSS
Base
Stack
Adapted from “XML and Web Services Unleashed”, SAMS Publishing
Web Services
12
23Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Web Services en Tiempo de Diseño—Estático
Alice (consumidor de
servicios) obtiene el documento WSDL que
corresponde al Web Service de Bob (e.g. busca en el repositorio
UDDI).
Alice utiliza el documento
WSDL como entrada para herramientas que generan
todo el código para
construcción de mensajes (e.g. WSDL2Java).
Bob (proveedor de servicios)
expone funcionalidad en su sistema como un Web Service (o crea un Web
Service específico) y
coloca un documento
WSDL en un “lugar accesible” (e.g. repositorio
UDDI).
Alice adiciona código a su
aplicación que ejecuta el código de construcción
de mensajes para conectarse al Web Service de Bob y código
adicional que utiliza la
respuesta del Web Service de
Bob.
Web Services
24Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Web Services en Tiempo de Diseño—Dinámico
Alice (consumidor de
servicios) escribe código
en su aplicación que consulta el repositorio de servicios en tiempo de ejecución.
Alice escribe código en su
aplicación que selecciona un servicio de la lista retornada por la consulta.
Bob (proveedor de servicios) crea un Web Service,
lo describe utilizando WSDL, y lo registra en un
repositorio de servicios (e.g.
UDDI).
Alice escribe código en su
aplicación que invoca el servicio
seleccionado con los
parámetros apropiados.
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
13
25Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Web Services en Tiempo de Ejecución
1. Usuario ejecuta la aplicación de Alice.
3. Cuando el servidor HTTP de Bob ve un mensaje SOAP, lo envía al SOAP engine.
2. Aplicación construye un mensaje SOAP y lo envía al servicio de Bob vía HTTP.
4. El SOAP engine interpreta el mensaje y construye el llamado al sistema de Bob.
5. El sistema de Bob ejecuta la operación invocada.
6. El sistema de Bob retorna los resultados de la operación.
HTTPRequest Call
ReturnHTTPResponse
7. El SOAP engine construye el mensaje de respuesta y lo retorna vía HTTP.
Servidor HTTP Sistema de BobUsuario de la Aplicación de
Alice
8. La aplicación de Alice interpreta la respuesta y muestra resultados al usuario.
Web Services
26Versió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
14
27Versión 1.5 (SEPG-LA 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
Desde los 1,000 Pies de Altura
28Versió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
15
29Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Consumidores de Servicios
1. Identificar servicios apropiados (internos y
externos) que puedan ser reutilizados
Sistema de Gestión de
Pedidos
Sistema Financiero
Organización 1
Organización 2
Sistema de Validación de
Tarjetas de Crédito
Infra
estru
ctu
ra S
OA
Aplicación de Proceso de Pedidos
Aplicación de Gestión de Clientes
Sistema de Envíos
FedEx
Sistema de Envíos
UPS
Sistema de Envíos
DHL
Aplicación de Pedidos
Organización Cliente
2. Entender la infraestructura y las interfaces de servicios en términos de funcionalidad y calidad de servicios
Un consumidor de servicios necesita crear una nueva aplicación
basada en SOA.
3. Crear la nueva aplicación utilizando tantos servicios como sea posible
4. Diseñar la aplicación de tal manera que pueda fácilmente
acomodar cambios en los servicios
Fire
wa
ll
5. ¡¡Pruebas!!
Internet
Desde los 1,000 Pies de Altura
30Versió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
16
31Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Desarrolladores de Servicios
Sistema de Gestión de
Pedidos
Sistema Financiero
Organización 1
Organización 2
Sistema de Validación de
Tarjetas de Crédito
Infra
estru
ctu
ra S
OA
Aplicación de Proceso de Pedidos
Aplicación de Gestión de Clientes
Sistema de Envíos
FedEx
Sistema de Envíos
UPS
Sistema de Envíos
DHL4. Diseñar, crear y publicar servicios para consumidores
internos y/o externos
3. Anticipar requerimientos de futuros consumidores
2. Analizar requerimientos de la
infraestructura, interfaces,
funcionalidad y QoS de consumidores
1. Identificar funcionalidad de
negocios que pueda ser expuesta como
un servicio
Internet
Desde los 1,000 Pies de Altura
32Versió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
17
33Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Desarrolladores de Infraestructura
Sistema de Gestión de
Pedidos
Sistema Financiero
Organización 1Organización 2
Sistema de Validación de
Tarjetas de Crédito
Infra
estru
ctu
ra S
OA
Aplicación de Proceso de Pedidos
Aplicación de Gestión de Clientes
Sistema de Envíos
FedEx
Sistema de Envíos
UPS
Sistema de Envíos
DHLServicios de
Infraestructura
Descubrimiento
Seguridad
Herramientas de Desarrollo
Registro de Servicios
Selección de productos y estándares
Mecanismos de conexión
Herramientas para desarrolladores de
servicios y consumidores
Documentación y soporte
Internet
Desde los 1,000 Pies de Altura
34Versió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
18
35Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
36Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Granularidad de Servicios 2
Sistema de Gestión de
Pedidos
[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 …
HistPedidos getHistoriaPedidos( IdCliente)
InfoCliente getInfoBasica( IdCliente )
Pedido[] getPedidosPendientes( IdCliente )
… o el servicio puede ser más granular y tener tres operaciones diferentes para los
tres tipos de información
Desde los 1,000 Pies de Altura
19
37Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
38Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Manejo de Transacciones 2
Sistema de Gestión de
Pedidos
↓↓↓↓ colocarPedido
���� Responsabilidad: Proveedor de Servicios
Infraestructura SOA
Aplicación de Proceso de Pedidos
Sistema de
Inventario
Sistema Financiero
↓↓↓↓ colocarPedido
↓↓↓↓ marcarInventario ↓↓↓↓ getInfoFinanciera
1. Aplicación invoca el servicio
colocarPedido.
4. Sistema de Gestión de Pedidos invoca
getInfoFinancera.
2. Infraestructura localiza el servicio colocarPedido.
3. Sistema de Gestión de Pedidos inicia
transacción
5. Sistema de Gestión de Pedidos invoca
marcarInventario.
6. Aplicación recibe el estado de
la operación.
NOTA: El proveedor de servicio podría decidir hacer
llamados directos en vez de utilizar las interfaces de
servicio
Desde los 1,000 Pies de Altura
20
39Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Manejo de Transacciones 3
Sistema de Gestión de
Pedidos
↓↓↓↓ crearPedido
���� Responsabilidad: Infraestructura
Infraestructura SOA
Aplicación de Proceso de Pedidos
Sistema de
Inventario
Sistema Financiero
↓↓↓↓ colocarPedido
↓↓↓↓ marcarInventario ↓↓↓↓ getInfoFinanciera
1. Aplicación invoca el servicio
colocarPedido.
3. Infraestructura invoca getInfoFinanciera.
2. Infraestructura sabe que es una
operación transaccional e
inicia transacción.
5. Infraestructura invoca crearPedido.
4. Infraestructura invoca marcarInventario.
6. Aplicación recibe el estado de
la operación.
NOTA: Dependiendo de
la implementación, las operaciones podrían requerir operaciones
compensatorias.
Desde los 1,000 Pies de Altura
40Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Manejo de Transacciones 4
Sistema de Gestión de
Pedidos
↓↓↓↓ crearPedido
���� Responsabilidad: Consumidor de Servicios
Infraestructura SOA
Aplicación de Proceso de Pedidos
Sistema de
Inventario
Sistema Financiero
↓↓↓↓ getInfoFinanciera
↓↓↓↓ marcarInventario
↓↓↓↓ crearPedido
↓↓↓↓ marcarInventario ↓↓↓↓ getInfoFinanciera
2. Aplicación invoca los tres
servicios.1. Aplicación inicia transacción.
Desde los 1,000 Pies de Altura
NOTA: Dependiendo de
la implementación, las operaciones podrían requerir operaciones
compensatorias.
21
41Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
42Versió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
22
43Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Pilares del Desarrollo de Sistemas Basados en SOA
Alin
ea
mie
nto
E
stra
tég
ico
Principios de Diseño para SOA
Desarrollo de Sistemas Basados en SOA
Eva
lua
ció
n d
e
Te
cn
olo
gía
SO
A
Go
ve
rna
nc
e
Ca
mb
io d
e
Me
nta
lida
d
Pilares
44Versió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
23
45Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Diferentes Necesidades y Objetivos de Negocio Requieren Diferentes Estrategias SOA
Necesidades y Objetivos del Negocio
Estrategia SOA
Incrementar información disponible para los clientes del negocio
• Portals intuitivos
• Creación de servicios relacionados con 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
46Versió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
24
47Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
48Versió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
25
49Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
50Versió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
26
51Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
52Versió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
27
53Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
54Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Todas estas preguntas sugieran la necesidad de experimentación contextual
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?
Pilares: Evaluación de Tecnología
28
55Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
T-CheckSM
Experimento con el objetivo de verificar el comportamiento de una tecnología en un contexto específico
Pasos
1. Formular hipótesis acerca de la tecnología
2. Examinar estas hipótesis contra criterios muy específicos mediante experimentación
Extremadamente eficiente
• La idea es implementar el experimento más simple posible que permita validar o contradecir la hipótesis
• El principio es que si el experimento falla en lo simple, va a fallar en lo complejo
Develop
Hypotheses
Develop
Criteria
Design and
Implement Solution
Evaluate Solution
Against Criteria
[Hypotheses Sustained] [Hypotheses Refuted]
Context
Pilares: Evaluación de Tecnología
56Versió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
29
57Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Ejemplo de T-Check: Hipótesis y Criterios de Evaluación
Hipótesis Criterios de Evaluación
75% o más de las aplicaciones pueden ser adaptadas a tecnologías de Web Services.
1. Hay librerías SOAP que pueden ser fácilmente integradas a 75% o más aplicaciones.
2. Sino, existe un mapeo claro entre tipos de datos nativos y tipos de datos de XML Schema que facilite la construcción e interpretación manual de mensajes SOAP.
El tiempo de respuesta no será degradado debido al uso de Web Services.
El tiempo de respuesta utilizando Web Services será del mismo orden de magnitud que los tiempos de respuesta actuales de aplicaciones representativas.
Imágenes pueden ser transmitidas como parte de mensajes SOAP.
Una imagen puede ser solicitada utilizando Web Services y visualizada en una aplicación cliente.
Es posible tener single sign-on utilizando Web Services.
Un usuario hace login una vez y pude obtener información de tres Web Services diferentes en tres máquinas diferentes.
Pilares: Evaluación de Tecnología
58Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
El Desarrollo de Sistemas Basados en SOA Requiere un Enfoque Diferente
Desarrollo de Sistemas Tradicionales
Desarrollo de Sistemas Basados en SOA
Acoplamiento fuerte entre componentes del sistema
Acoplamiento débil entre consumidores y servicios
Semántica compartida explícitamente en tiempo de desarrollo
Tecnologías permiten compartir semántica sin mayor comunicación entre servicios y consumidores– en el futuro incluso en tiempo de ejecución
Conjunto conocido de usuarios y patrones de uso
Conjunto potencialmente desconocido de usuarios de servicios y patrones de uso
Componentes del sistema pertenecen a la misma organización
Componentes del sistema potencialmente pertenecen a múltiples organizaciones
Pilares: Cambio de Mentalidad
30
59Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
60Versió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
31
61Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
62Versió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
32
63Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
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
64Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Tres Elementos de SMART
ProcesoCuestionario para la
Migración a Servicios (SMIG)
Artefactos
Recoge información acerca de
• Objetivos y expectativas de la migración
• Servicios candidatos
• Sistemas /componentes a migrar
• Ambiente SOA
Analiza el gap entre el sistema existente y el ambiente SOA
Guía la discusión en las actividades iniciales de SMART
• Lista de Stakeholders
• Lista de Características
• Lista de Riesgos de Migración
• Mapeo entre Procesos de Negocio y Servicios
• Tabla de Servicios
• Tabla de Componentes
• Arquitectura de Alto Nivel del Sistema SOA
• Alternativas Servicio-Componentes
• Estrategia de Migración
SMART: Elementos
33
65Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Actividades de Proceso de SMART
SMART: Actividades de Proceso
Establish
Migration
Context
Describe
Existing
Capability
Describe
Target SOA
Environment
Analyze the
Gap
Develop
Migration
Strategy
Migration
Feasible?No
Define
Candidate
Services
YesYes
66Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Cuestionario para la Migración a Servicios (SMIG)
62 categorías de preguntas que buscan recolectar información acerca del contexto de migración, sistemas existentes, servicios candidatos y el ambiente SOA
SMART: SMIG
El objetivo es asegurar un cubrimiento amplio y consistente de los factores que influencian el costo, esfuerzo y riesgo de la migración a servicios.
Guía la recolección de información en el primer conjunto de actividades
Establish
Migration
Context
Describe
Existing
Capability
Describe
Target SOA
Environment
Analyze the
Gap
Develop
Migration
Strategy
Migration
Feasible?No
Define
Candidate
Services
YesYes
34
67Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Artefactos SMART
Establecer Contexto de Migración
Definir Servicios
Candidatos
Describir Capacidad Existente
Describir Ambiente
SOA
Analizar el Gap
Desarrollar Estrategia de
Migración
Lista de Stakeholders
Crear Actualizar Actualizar Actualizar Actualizar Actualizar
Lista de Características
Crear Actualizar Actualizar Actualizar Actualizar Actualizar
Lista de Riesgos de Migración
Crear Actualizar Actualizar Actualizar Actualizar Actualizar
Mapeo Procesos de Negocio-Servicios
Crear Actualizar Actualizar Actualizar Actualizar Actualizar
Tabla de Servicios Crear Actualizar Actualizar Actualizar Actualizar
Tabla de Componentes
Crear Actualizar Actualizar Actualizar
Arquitectura Alto Nivel Sistema SOA
Crear Actualizar Actualizar
Alternativas Servicio-
ComponentesCrear Actualizar
Estrategia de Migración
Crear
SMART: Artefactos
68Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Contexto de Caso de Estudio: Sistema de Información de Laboratorios (LIS)
Paciente
Clínica(Ambulatorio)
Visita Médica
Hospital (Interno)
Admisión Hospital
Sistema de Información de Laboratorios
Orden Examen
Orden Examen
Cobros
Compañía de
Seguros
Datos Agregados para Información y
Análisis
Centro de Investigación /
Centro de Salud Pública
Resultados
Portal de Pacientes
Datos Paciente
Datos Paciente
Resultados
Resultados
Caso SMART: Contexto
35
69Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Contexto de Caso de Estudio: Diagrama de Contexto de LIS
Información de laboratorio compartida entre varios sistemas
Necesidad de migrar a un ambiente SOA para incrementar la reutilización de tareas de laboratorio comunes
Preguntas clave
1. ¿Qué servicios deben ser creados?
2. ¿En qué orden?
3. ¿Es mejor reemplazar algunos componentes por componentes nuevos?
LIS
Sistemas Pacientes
Ambulatorios
Sistemas Pacientes Internos
Sistemas de Investigación y Salud Pública
Sistema En Línea de
Información de Pacientes
Sistemas de
Seguros
Alcance de la Aplicación de SMART
Caso SMART: Contexto
70Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Establecer Contexto de Migración
• Entender el contexto de negocio y el contexto técnico de la migración
• Identificar stakeholders
• Entender el sistema existente y el ambiente SOA a un alto nivel
• Identificar un conjunto de servicios candidatos para migración
SMART: Establecer Contexto de Migración
Establish
Migration
Context
Describe
Existing
Capability
Describe
Target SOA
Environment
Analyze the
Gap
Develop Migration
Strategy
Migration
Feasible?No
Define
Candidate
Services
YesYes
36
71Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
LIS: Objetivos de la Migración
Mejorar el cuidado a pacientes
• Tener acceso a información de laboratorio desde cualquier sistema clínico en tiempo real (acceso actual es en su mayoría batch)
• Proveer acceso vía Web a información de laboratorio a pacientes a través del portal de pacientes
Reducir costos de TI
• Crear servicios comunes y reutilizables
• Reducir múltiples interfaces punto a punto entre sistemas
• Reducir costos de mantenimiento y actualización de sistemas
Caso SMART: Establecer Contexto de Migración
72Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
LIS: Descripción de Alto Nivel del Sistema
Sistema de Información de Laboratorios (LIS)
• 800,000 líneas de código
• Seis módulos principales—~2500 clases C++ y ~1500 clases Java
— El módulo de Catálogo de Exámenes de Laboratorio está escrito en Java pero realmente es un wrapper a un sistema escrito en COBOL
• Algunos componentes corren en Windows y otros en Linux OS
Interacción con sistemas externos es punto-a-punto a través de sockets dedicados
• Algunas transferencias de datos de hacen en modo batch en la noche (i.e., resultados de exámenes)
• No toda la información intercambiada utiliza la misma versión de HL7 (V3 vs. V2.X)
Dependencias en varios productos comerciales
• Oracle Database
• Weblogic Application Server
Caso SMART: Establecer Contexto de Migración
37
73Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
LIS: Ambiente SOA a un Alto Nivel
Evaluando varios productos Enterprise Service Bus (ESB) para el soporte de Web Services
• Un ESB es un producto de middleware que conecta y media toda la comunicación e interacción entre consumidores de servicios y servicios, usualmente basado en estándares
• Funcionalidad típica (Fuente: Wikipedia)
Categoría Funciones
Invocación Soporte para protocolos de transporte síncronos y asíncronos
Enrutamiento Manejo de direcciones, enrutamiento basado en contenido (itinerary routing)
Mediación Adaptadores, traducción de protocolos, transformación de datos
Orquestación de Procesos
Definición de procesos de negocio
Procesamiento de Eventos Complejos
Interpretación de eventos, correlación, pattern matching y publish/subscribe
Calidad de Servicio Seguridad (encripción y firmas), entrega garantizada y transacciones
Management Monitoreo, auditoría, logging, medición, consola de administración y monitoreo de actividades de negocio (BAM)
Caso SMART: Establecer Contexto de Migración
74Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Establecer Contexto de Migración: Ejemplos del SMIG
Tema de Discusión
Preguntas Relacionadas Potenciales Riesgos de Migración
Objetivos y Expectativas
• ¿Cuál es la motivación de negocio y técnica del esfuerzo de migración?
• ¿Cuáles son los objetivos a corto y a largo plazo?
• No hay estrategia para la adopción de SOA
• Objetivos de la migración no son claros
Entendimiento de Alto Nivel del Sistema Existente
• ¿Cuál es la funcionalidad principal del sistema?
• ¿Cuál es la arquitectura de alto nivel del sistema?
• ¿Cómo es la interface de usuario del sistema?
• Conocimiento del sistema no está disponible
• Incompatibilidad con ambiente SOA• Complejidad de la interface de
usuario difícil de replicar en consumidores de servicios
Entendimiento de Alto Nivel del Ambiente SOA
• ¿Cuáles son los principales componentes del ambiente SOA?
• ¿Es este el primer proyecto de desarrollo de servicios en este ambiente?
• Ambiente SOA no ha sido identificado
• Conocimiento del ambiente SOA no está disponible en casa
Potenciales Consumidores de Servicios
• ¿Quiénes son los potenciales consumidores de servicios?
• Consumidores de servicios no han sido identificados
SMART: Establecer Contexto de Migración
38
75Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Propósito del SMIG
Identificación de riesgos potenciales de migración
Identificación de áreas que van a requerir esfuerzo o costo extra
Información de características que tienen que ser recolectadas de cada componente
Lista de Características
Se traduce en
Capturadas en
SMART: Establecer Contexto de Migración
76Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
LIS: Lista de Características
Descripción
Servicios
Lenguaje
Dependencia Producto COTS
Tamaño
Número Versión y Release
Plataforma
Complejidad
Java
C++
Perl
Alta
Media
Baja
Muy Alta
Componente Wrapper
Características básicas pre-definidas
Características específicas al contexto del sistema
…
Caso SMART: Establecer Contexto de Migración
39
77Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
LIS: Lista Inicial de Riesgos de Migración
Descripción: Todos los consumidores de servicios no piensan moverse a la versión XML (v3) de HL7.Tipo: Técnico Impacto: Medio
Descripción: Algunos componentes están diseñados sólo para operaciones batch; se necesitan cambios fundamentales en estos componentes.Tipo: Proceso Impacto: Alto
Caso SMART: Establecer Contexto de Migración
78Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Punto de Chequeo para Factibilidad de Migración
Se debe tomar la decisión de continuar o no con el proceso.
Las posibilidades son
• La migración es inicialmente factible.
• La migración tiene potencial pero requiere información adicional para poder tomar una decisión.
• La migración no es factible.
Describe
Existing
Capability
Describe
Target SOA
Environment
Analyze the
Gap
Develop
Migration
Strategy
Migration
Feasible?No
Define
Candidate
Services
YesYes
Establish Migration
Context
SMART: Punto de Chequeo para Factibilidad de Migración
40
79Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Definir Servicios Candidatos
Seleccionar un número pequeño de servicios, usualmente 3-4, de la lista inicial de servicios candidatos.
Para los servicios seleccionados, el objetivo es definir completamente sus entradas y salidas.
SMART: Definir Servicios Candidatos
Define
Candidate
Services
Describe
Existing
Capability
Describe
Target SOA
Environment
Analyze the
Gap
Develop
Migration
Strategy
YesYes
Establish
Migration
Context
Migration
Feasible?No
80Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
LIS: Mapeo Inicial entre Procesos de Negocio y Servicios
Proceso de Negocios Servicios Candidatos
Buscar en Catálogo de Exámenes de Laboratorio
Obtener Catálogo Exámenes, Obtener Detalles Examen
Ordenar/Re-Ordenar Examen Obtener Catálogo Exámenes, Obtener InformaciónPaciente, Obtener Detalles Examen, Crear Orden Examen
Obtener Estado de Exámenes Obtener Información Paciente, Obtener Detalles Examen
Proveer Información de Cobros
Obtener Información Paciente, Obtener Detalles Examen
Revisar y Reportar Resultados de Exámenes
Obtener Información Paciente, Obtener Detalles Examen,Obtener Resultados Examen
Análisis de Tendencias Obtener Resultados Examen, Obtener ResultadosAgregados Examen
Caso SMART: Definir Servicios Candidatos
41
81Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
LIS: Tabla de Servicios Inicial
NOTA: Al final de este proceso iterativo, entradas y salidas deben tener un tipo de dato asociado.
Servicio Descripción TipoConsumidores
Potenciales
Obtener Resultados Examen
Obtiene resultados detallados de examen(es) para un paciente(s) o para todos los pacientes que se hicieron exámenes en un día específico en una sede específica
Negocio Sistemas Cínicos
Obtener Catálogo ExámenesObtiene el catálogo de exámenes disponibles en un laboratorio Negocio Sistemas Clínicos
Servicio Formato DatosFormatea mensaje de acuerdo con una versión específica de HL7 Infraestructura Servicios internos y
aplicaciones
… … … …
Servicio Entradas SalidasAtributos de Calidad
Claves…
Obtener Resultados Examen
ID Paciente (s)ID ExamenID SedeFecha
Detalles Resultados Examen Seguridad
Obtener Catálogo Exámenes Tipo(s) Examen Catálogo de Pruebas Configurabilidad
Servicio Formato Datos Datos, Versión HL7 Datos Formateados HL7 Interoperabilidad
… … … … …
Caso SMART: Definir Servicios Candidatos
82Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Describir Capacidad Existente
SMART: Describir Capacidad Existente
Describe
Existing
Capability
Define
Candidate
Services
Describe
Target SOA
Environment
Analyze the
Gap
Develop
Migration
Strategy
Establish
Migration
Context
Migration
Feasible?No
Yes
Obtener información descriptiva acerca de los componentes a migrar
• Nombre, función, tamaño, plataforma, edad, versión, etc.
Cuestionar personal técnico acerca de
• Arquitectura y paradigmas de diseño
• Complejidad, acoplamiento, interfaces
• Calidad de documentación
• Dependencias entre componentes/productos
Recolectar información acerca de
• Calidad, madurez, problemas
• Historia de cambios
• Satisfacción de usuarios
42
83Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Describir Capacidad Existente: Ejemplos del SMIG
Tema Preguntas Relacionadas Potenciales Riesgos
Características del Sistema Existente
• ¿Cuál es la historia de sistema? • ¿Es un prototipo, sistema en desarrollo, sistema
en pruebas, sistema en producción?• ¿Qué documentación del sistema hay?• ¿El sistema tiene interfaces con otros sistemas? • ¿Se perciben problemas de locking, persistencia
o de manejo de transacciones si el sistema es accedido por múltiples usuarios cuando se migre a servicios?
• Desarrollo en paralelo con esfuerzo de migración
• Documentación limitada del sistema• Interfaces a otros sistemas van a abrir
puertas para consumidores• Sistema mono-usuario puede presentar
problemas en un ambiente multi-usuario
Arquitectura del Sistema Existente
• ¿Qué perspectivas de la arquitectura existen? • ¿Cuáles son los módulos principales del sistema
y la dependencia entre ellos?• ¿El código de interface de usuario está separado
del código de lógica del negocio? • ¿Hay paradigmas de diseño implementados en
el sistema? • ¿Qué atributos de calidad están implementados
en la arquitectura actual del sistema?
• Falta de documentación de la arquitectura puede llevar a estimaciones incorrectas de complejidad
• Acoplamiento fuerte entre código de interface de usuario y lógica del negocio incrementa esfuerzo de migración
• Violaciones indocumentadas de patrones de diseño pueden causar problemas
• Atributos de calidad claves pueden no mantenerse en un ambiente de servicios
Características del Código
• ¿Cómo está la documentación del código?• ¿Se siguen estándares de programación?
• Prácticas de programación pobres incrementan el esfuerzo de migración
SMART: Describir Capacidad Existente
84Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
LIS: Tabla de Componentes
Componente Descripción Servicios Lenguaje PlataformaTamaño (SLOC)
CatalogoExamenes
Maneja el catálogo de todos los exámenes de laboratorio disponibles
Obtener Catalogo Exámenes, Obtener Detalles Examen, Crear Orden Examen
Java Linux 1,000
ProcesadorResultados
Contiene reglas del negocio para procesar resultados y comunicarlos a sistemas externos
Obtener Resultados Examen, Obtener Resultados Agregados Examen
C++, Java, Perl
Unix, Windows
XP8,000
Componente Complejidad VersiónNivel de
Documentación Ultimo Release
CatalogoExamenes Media 5.6 Alto 02/10/2005
ProcesadorResultados Muy Alta 8.2 Medio 06/01/2005
ComponenteComponente
WrapperDependencia Productos COTS
Llamados Directos UI
Políticas y Reglas en Código
CatalogoExamenes Si Librerías de terceros, HL7 v2.3 No No
ProcesadorResultados NoOracle Database, Weblogic Application Server
Si Si
Nuevo
Caso SMART: Describir Capacidad Existente
43
85Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
LIS: Perspectiva Modular
Procesamiento de Ordenes
Catálogo de Exámenes de Laboratorio
Archivo(Exámenes,
Ordenes)
Gestión de Exámenes y
Muestras
Reporte y Procesamiento de Resultados de Exámenes
Procesamiento de Cobros
SistemasPacientes
Ambulatorios
Sistemas Pacientes
Interno
Sistemas de Investigación y Salud Pública
Sistema En Línea de
Información de Pacientes
Sistemas de
Seguro
Sistema de Información de Laboratorios
C++ Java Implementación de interface diferente para cada sistema
Diferentes versiones de HL7 (no todas basadas
en XML)
Realizado a diario en modo batch
Comunicación con sistemas externos a través de sockets
dedicados
Caso SMART: Describir Capacidad Existente
86Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
LIS: Riesgos de Migración Adicionales
Descripción: Todos los consumidores de servicios no piensan moverse a la versión XML (v3) de HL7.
Descripción: Algunos componentes están diseñados solo para operaciones batch …
Descripción: Algunos componentes hacen llamados directos entre código de lógica del negocio y código de interface de usuario.Tipo: Técnico Impacto: Medio
Descripción: Diferentes políticas de filtrado son aplicadas al mismo conjunto de datos dependiendo del sistema externo. Tipo: Organizacional, Políticas Impacto: Alto
Nuevo
Nuevo
Caso SMART: Describir Capacidad Existente
44
87Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Describir Ambiente SOA
Describe
Target SOA
Environment
Define
Candidate
Services
Describe
Existing
Capability
Analyze the
Gap
Develop
Migration
Strategy
Establish Migration
Context
Migration
Feasible?No
Yes
• Identificar el impacto de tecnologías, estándares y guías específicas para la implementación de servicios
• Determinar el estado del ambiente SOA
• Identificar cómo los servicios deben interactuar con el ambiente SOA
• Determinar expectativas de calidad de servicio y del ambiente de ejecución para servicios
SMART: Describir Ambiente SOA
88Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Describir Ambiente SOA: Ejemplos del SMIG
Tema de Discusión
Preguntas Relacionadas Potenciales Riesgos de Migración
Características del Ambiente SOA
• ¿Cuál es el estado del ambiente SOA?• ¿Cuáles son los principales componentes de la
infraestructura SOA ?• ¿Existen servicios de infraestructura en el
ambiente SOA (i.e., comunicaciones, descubrimiento, seguridad, transformación de datos)?
• ¿Cuál es el modelo de comunicaciones? • ¿Qué restricciones coloca la infraestructura sobre
servicios? • ¿Hay algún comportamiento en el sistema que sea
incompatible con el ambiente SOA?• ¿Dónde van a correr los servicios?
• Ambiente SOA indefinido• Redundancia/conflictos entre servicios
de infraestructura y código existente• Falta de herramientas para el apoyo de
la migración• Cumplir con las restricciones de la
infraestructura requiere esfuerzo adicional
• Incompatibilidad entre arquitectura del sistema existente y el ambiente SOA
• No se ha pensado en el despliegue y ejecución de servicios
Soporte • ¿Se deben proveer scripts de pruebas para los servicios?
• ¿Cómo se va a manejar el reporte de problemas por parte de consumidores?
• ¿Cómo se van a reportar a consumidores los cambios de interface o tiempos de indisponibilidad debido a problemas o actualizaciones de servicios?
• Estimación incorrecta del esfuerzo para soportar consumidores de servicios
• Desconocimiento de los requerimientos de soporte a servicios
SMART: Describir Ambiente SOA
45
89Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
LIS: Restricciones del Ambiente SOA
Servicios necesitan soportar diferentes versiones del estándar HL7.
• Portal de Pacientes va a utilizar la nueva versión (v3) de HL7 basada en XML.
• Sistemas Clínicos (Ambulatorio, Interno) piensan moverse a HL7 v3 en el corto plazo mientras que los demás sistemas no tienen planes para ello.
Servicios necesitan tener en cuenta las diferentes políticas para el manejo del mismo conjunto de datos.
• Datos de pacientes para organizaciones de investigación deben ser completamente anónimos.
• Datos de pacientes para sistemas clínicos deben estar ser completamente identificables.
Caso SMART: Describir Ambiente SOA
90Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
LIS: Arquitectura de Alto Nivel del Sistema Basado en SOA
Sistemas de Investigación y Salud Pública
Servicio Crear Orden
Examen
Servicio de
Seguridad
Servicio Obtener
Resultados Examen
Servicio Obtener
Resultados Agregados
Examen
Enterprise Service Bus (ESB)
Procesamiento de Ordenes
Reporte y Procesamiento de
Resultados Exámenes
Sistemas de Pacientes Internos
Sistemas de Pacientes
Ambulatorios
Sistemas de Seguros
Servicio de
Formato de Datos
Portal de Pacientes
Policy Manager
…
Caso SMART: Describir Ambiente SOA
Servicio de Transferencia
de Datos
46
91Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Analizar el Gap
• Definir el esfuerzo, riesgo y costo de habilitar componentes existentes como servicios, dados los requerimientos de servicios y las características del ambiente SOA
• Determinar la necesidad de análisis adicionalesAnalyze the
Gap
Define
Candidate
Services
Describe
Existing
Capability
Describe
Target SOA
Environment
Develop
Migration
Strategy
Establish
Migration
Context
Migration
Feasible?No
Yes
SMART: Analizar el Gap
92Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
LIS: Tabla de Componentes Actualizada
Componente … …Método
de Migración
Resumen de Cambios RequeridosEsfuerzo (Persona/Semana)
CostoNivel de
Dificultad
Nivel de
Riesgo
CatalogoExamenes
Wrapping 1. Crear una interface con los métodos necesarios para buscar en el catálogo con los múltiples criterios de búsqueda definidos.
2. Reutilizar la lógica presente en CatalogoExamenes mediante el llamado a los métodos existentes.
3 Bajo Bajo
ProcesadorResultados
Extracción + Nuevo
1. Crear una interface con los métodos para obtener resultados de exámenes con los múltiples criterios de búsqueda definidos.
2. Reutilizar las reglas de negocio en ProcesadorResultados, adicionando modificaciones para acomodarse a la nueva interface de servicio.
3. Crear código para los métodos que no se encuentran en ProcesadorResultados.
4. Adicionar código para validación de entradas.
5. Adicionar elementos a la estructura de datos ResultadosExamen para guardar información requerida por la nueva interface de servicio.
6. …
15 Medio Medio
Caso SMART: Analizar el Gap
47
93Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Desarrollar Estrategia de Migración
Desarrollar una o más estrategias de migración que pueden incluir
• Orden en el cual crear servicios
• Guías para la creación de servicios
• Arquitecturas de referencia
• Fuentes del código de servicios—sistemas existentes, COTS, servicios externos, etc.
• Mecanismo—wrapping, reescribir, extracción, nuevo
• Caminos específicos para la migración—e.g., wrapping primero y reescribir luego)
• Necesidades de entrenamiento, evaluación de tecnología, investigación de mercados, etc.
Develop
Migration
Strategy
Define Candidate
Services
Describe Existing
Capability
Describe Target SOA
Environment
Analyze the
Gap
Establish
Migration
Context
Migration
Feasible?No
Yes
SMART: Desarrollar Estrategia de Migración
94Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Proceso Revisitado …
Información colectada durante Establecer Contexto de Migración, Definir
Servicios Candidatos, Describir Capacidades Existentes y Describir
Ambiente SOA
Riesgos de Migración
Genera
Mitigados en
Provee la base para
Colocan restricciones sobre
Estimaciones de Costo y Esfuerzo
Estrategia de Migración
SMART: Desarrollar Estrategia de Migración
48
95Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Estrategia de Migración para LIS 1
1. Reunión de Trabajo con Stakeholders
• Compartir planes de migración para LIS
• Llegar a un acuerdo sobre los tiempo de release de servicios y la suspensión de interfaces actuales
• Obtener necesidades de consumidores de servicios
• Discutir soporte a ser brindado para la utilización de servicios LIS
2. Selección Inicial de un ESB
• Hacer una selección preliminar basada en resultados de evaluación existentes
• Trabajar con el proveedor para obtener una licencia de evaluación de corto plazo
• Implementar la infraestructura SOA inicial
Caso SMART: Desarrollar Estrategia de Migración
96Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Estrategia de Migración para LIS 2
3. Implementar el servicio Obtener Catálogo Exámenes como un proyecto piloto
• Servicio que puede ser fácilmente expuesto a sistemas externos para que puedan empezar a hacer pruebas
• Va a suministrar datos para ajustar las estimaciones
• También va a determinar si el “doble-wrapper” va a presentar problemas de desempeño
4. Validar Requerimientos de Seguridad y Privacidad
• T-Checks pueden determinar si los requerimientos de seguridad y privacidad son satisfechos por el ESB seleccionado
• Si requerimientos no son satisfechos, T-Checks pueden proveer información para determinar si es necesario adicionar elementos a la infraestructura
Caso SMART: Desarrollar Estrategia de Migración
49
97Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Estrategia de Migración para LIS 3
5. Entender el Policy Manager del ESB
• T-Checks pueden utilizar las políticas de información de LIS como contexto para la experimentación
• Si requerimientos no son satisfechos, T-Checks pueden proveer información para determinar si es necesario adicionar elementos a la infraestructura
6. Evaluar Infraestructura SOA Inicial
• Identificar requerimientos que no son satisfechos por la infraestructura, restricciones sobre servicios, problemas con calidad de servicios, incompatibilidades con código existente
• Podría incluso determinarse que la selección inicial de ESB no es apropiada
Caso SMART: Desarrollar Estrategia de Migración
98Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Estrategia de Migración para LIS 4
7. Implementar Infraestructura SOA Final
• Definir responsabilidades de los componentes de la infraestructura
• Definir e implementar SLAs y mecanismos para cumplimiento en tiempo de ejecución
• Identificar áreas en las cuáles se necesita soporte del proveedor del ESB
8. Documentar Guías de Implementación
• Diseño de interfaces de servicio
• Listas de chequeo para desarrollo
• Arquitectura de referencia para servicios
• Procedimientos de prueba y despliegue
• …
Service Interface Layer
Performs transformations between messages from
service consumers and LIS code
LIS Code Layer
Contains existing LIS code plus new code that had to be
developed to meet service requirements
Data Access Layer
Contains code to access internal and
external data sources
Policy Layer
Contains code to
access Policy
Manager
Caso SMART: Desarrollar Estrategia de Migración
50
99Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Estrategia de Migración para LIS 5
9. Ajustar Estimaciones y Crear Plan de Migración
• Finalizar entradas/salidas de servicios basados en los requerimientos de consumidores
• Ajustar estimaciones de esfuerzo para la migración que incluyan requerimientos de la infraestructura SOA y cualquier cambio en entradas/salidas
• Priorizar servicios candidatos
• Definir necesidades de entrenamiento y proveer el entrenamiento
10. Implementar Plan de Migración
• Asegurarse que haya retroalimentación entre iteraciones—incorporar lecciones aprendidas y evaluar cambios en tecnología
Caso SMART: Desarrollar Estrategia de Migración
100Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
En Resumen …
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
51
101Versió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
Implicaciones Actividades de Desarrollo
102Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Implicaciones Generales
Procesos deben reflejar el enfoque estratégico
Procesos deben ser iterativos
• Iteraciones cortas para poder responder a las necesidades del negocio
Procesos de governance deben aplicar al ciclo de vida completo
• Énfasis en áreas problemáticas
• Automatización en lo mayor posible
Diferenciación entre integración con servicios internos e integración con servicios externos
Diferenciación entre procesos para proveedores de servicios, consumidores de servicios y proveedores de infraestructura
Evaluación de tecnología se convierte en parte integralImplicaciones Actividades de Desarrollo
52
103Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Algunas Implicaciones sobre Actividades de Requerimientos
Requiere un enfoque basado en gerencia de procesos de negocio (BPM)
Debe manejar un mayor número de stakeholders
Primer paso es revisar el inventario de procesos y el inventario de servicios
• Negociación y adaptación con el fin de incrementar reutilización
• Puede causar un “refactoring” de servicios
• Un “registry” de alta calidad facilita el proceso
En el caso de proveedores de servicios, se requiere trabajar con requerimientos potenciales
• Tal como lo hacen los vendedores de productos comerciales
Implicaciones Actividades de Desarrollo
104Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Algunas Implicaciones sobre Actividades de Arquitectura y Diseño
Decisiones sobre responsabilidades de cada componente del sistema—consumidores, servicios e infraestructura
Constante evaluación de tecnología
Evaluación de calidad de servicio (QoS) esperada
• Tradeoff analysis
• Experimentación contextual
• Implicaciones debidas a consumidores o servicios externos
Decisiones deben promover la reutilización
Implicaciones Actividades de Desarrollo
53
105Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Algunas Implicaciones sobre Actividades de Implementación
El ambiente de desarrollo debe ser similar/igual al ambiente de producción—como en cualquier sistema distribuido
• En algunos casos puede ser necesaria la simulación del ambiente de producción
El estado emergente de las tecnologías para implementación de SOA causa inestabilidad en los procesos de implementación
Requiere el establecimiento de procesos para implementación de interfaces de servicio y de componentes de la infraestructura
• Los procesos tradicionales aplican a la implementación de servicios.
Implicaciones Actividades de Desarrollo
106Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Algunas Implicaciones sobre Actividades de Pruebas
La prueba completa de un sistema consumidor de servicios requiere que todos los servicios (o instancias de prueba) estén en línea
• Desde el punto de vista del consumidor, un servicio es una “caja negra”
Se requiere un mayor y más diverso manejo de excepciones
• Por ejemplo, qué pasa si el servicio no está disponible?
Pruebas de regresión deben evaluar contra requerimientos y contra acuerdo de nivel de servicio (SLAs)
Implicaciones Actividades de Desarrollo
54
107Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Algunas Implicaciones Sobre Actividades de Mantenimiento
El análisis del impacto de cambios afecta a un mayor número de usuarios
• Internos y externos
• Usuarios del servicio y usuarios del sistema que implementa el servicio
La gestión de configuraciones se vuelve más complicada
• Qué artefactos se colocan bajo gestión de configuraciones? Consumidores? Servicios? Infraestructura?
Mayor coordinación de ciclos de “release”
• Entre servicios y consumidores
• Entre infraestructura y servicios/consumidores
Implicaciones Actividades de Desarrollo
108Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
En Resumen …
Las actividades del proceso de desarrollo de sistemas orientados a servicios se ven afectadas por
• Enfoque estratégico necesario para adopción de SOA
• Distribución de componentes
• Nivel de control sobre componentes
Cualquier actividad de procesos que tiene como objetivo controlar o guiar el desarrollo en ambientes SOA debe convertirse en parte de SOA
Governance.
Implicaciones Actividades de Desarrollo
55
109Versió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
Conclusiones
110Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Conclusiones 1
SOA ofrece el potencial para
• Aprovechar inversiones en sistemas existentes mediante interfaces modernas a capacidades existentes
• Exponer funcionalidad a un mayor número de usuarios
Esto es posible mediante
• Construcción de consumidores a partir de servicios existentes
• Independencia de plataforma y lenguaje
• Acoplamiento débil entre consumidores de servicios y servicios
• Fácil actualización de servicios debido a la separación de la interface de servicio de la implementación del servicio
Conclusiones
56
111Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Conclusiones 2
El desarrollo exitoso de sistemas basados en SOA requiere
• Alineamiento estratégico
• SOA governance
• Evaluación contextual de tecnología
• Cambio de mentalidad
Reutilización de servicios es más complejo que la reutilización de módulos o componentes
• El diseño de servicios reutilizables requiere un enfoque, habilidades y mentalidad diferente
• La comunidad de stakeholders es más grande porque los servicios son típicamente reutilizados a nivel organizacional o departamental
Conclusiones
112Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Conclusiones 3
Reutilización en el mundo de servicios requiere
• Identificación de requerimientos del ambiente SOA en el cual van a operar los servicios
• Clara distinción entre las necesidades que pueden ser satisfechas por sistemas existentes y aquellas que no pueden ser satisfechas
• Análisis sistemático de los cambios necesarios para operar dentro del ambiente SOA
Un método como SMART permite analizar la posibilidad de reutilizar componentes existentes como la base para la implementación de servicios.
Conclusiones
57
113Versión 1.5 (SEPG-LA 2007)
© 2007 Carnegie Mellon University
Bibliografía
SMART: The Service Migration and Reuse Technique
• http://www.sei.cmu.edu/publications/documents/05.reports/05tn029.html
• SMART: Analyzing the Reuse Potential of Legacy Components in a Service-Oriented Architecture Environment. Proceedings of the 2007 AIAA Infotech@Aerospace Conference.
T-Check
• Proceso: http://www.sei.cmu.edu/publications/documents/05.reports/05tn025.html
• Aplicaciones:
— Web Services: http://www.sei.cmu.edu/publications/documents/06.reports/06tn021.html
— OWL-S (OWL Web Ontology Language for Services): http://www.sei.cmu.edu/publications/documents/06.reports/06tn018.html
— MDA (Model-Driven Architecture): http://www.sei.cmu.edu/publications/documents/05.reports/05tn022.html
Bibliografía