SEPGLA 2007 Migración a Ambientes de Arquitectura Orientada a Servicios (SOA) Grace Lewis

2,318 views

Published on

SEPGLA 2007:
Migración a Ambientes de Arquitectura Orientada a Servicios (SOA)
Grace A. Lewis
Software Engineering Institute, USA
Noviembre 26, 2007
Fuente: CD Memorias SEGLA 2007

Published in: Education, Technology
2 Comments
1 Like
Statistics
Notes
No Downloads
Views
Total views
2,318
On SlideShare
0
From Embeds
0
Number of Embeds
26
Actions
Shares
0
Downloads
162
Comments
2
Likes
1
Embeds 0
No embeds

No notes for slide

SEPGLA 2007 Migración a Ambientes de Arquitectura Orientada a Servicios (SOA) Grace Lewis

  1. 1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×