Este documento presenta una introducción a la arquitectura orientada a servicios (SOA). Explica los conceptos básicos de SOA desde las perspectivas tecnológica y empresarial, e identifica los elementos clave como servicios, contratos, endpoints y mensajes. También describe cómo SOA puede ayudar a alinear las estrategias de TI con las necesidades del negocio al exponer funcionalidades como servicios reutilizables.

1. SOA Workshop: Introducción a SOA Ing. Diego Campodónico [email_address]

2. Entender que significa SOA. Comprender los conceptos básicos de SOA desde el punto de vista tecnológico y de negocio. Relación entre SOA, la estrategias de IT, las estrategias de negocio y la compañía. Identificar los elementos que forman y estructuran una arquitectura SOA. Objetivos

3. ¿Qué es SOA? Inicios de SOA y SOA hoy. SOA y el negocio. Arquitectura SOA Servicios Contrato Endpoint Mensaje Políticas Principios Arquitectura de referencia Agenda

4. EAI ESB BPM BPEL BAM CEP Canonical Model Portal SOA Governance Register Agenda

5. SOA = Service Oriented Ambiguity? http://www.martinfowler.com/bliki/ServiceOrientedAmbiguity.html SOA = Web Services? SOA es exponer servicios usando web services? Usar Web Services no significa estar usando SOA. Se puede implementar SOA sin utilizar Web Services. ¿Qué es SOA?

6. Es un componente de software que puede ser accedida a través de un protocolo estándar y abierto, usando XML. Conecta sistemas heterogéneos en plataforma, tecnología y lenguaje. Expone una interface bien definida y descripta. Estándares: HTTP, HTTPS, FTP: Protocolo de transporte. XML: Mensajería SOAP: Descripción del mensaje WSDL: Descripción del servicio UDDI: Registración y organización de los servicios WS-* Web Services

7. SOA = Integración? Con SOA puedo llevar adelante la implementación de una arquitectura de integración. Pero SOA no es solo integración de sistemas. Significa cosas diferentes para diferentes personas. ¿Qué es SOA?

8. SOA es un estilo de arquitectura que enfatiza el uso de servicios de red, seguros, compartibles, de grano fino y desacoplados para incrementar la flexibilidad del negocio de una manera interoperable agnóstica tecnológicamente. SOA es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio. http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios SOA es un paradigma arquitectural que favorece la creación de aplicaciones via la orquestación de los servicios que interactúan a través de una variedad de interfaces basados en estándares. ¿Qué es SOA?

9. Como arquitectura: Basada en estándares (XML, HTTP, SOAP, WSDL, RPC, Rest, etc.) Facilita: Interoperabilidad Reutilización Integración Agilidad. Acerca IT al negocio Service-orientation: Bajo acoplamiento Composición y orquestación Encapsulación Contrato Statelessnes ¿Qué es SOA?

10. Como estrategia de IT: Organiza las funciones contenidas en aplicaciones empresariales convirtiéndolas en servicios. Se aproxima a la estrategia de negocio de la empresa Reduce costos Aumenta el ROI Disminuye el Time-To-Market Mejora el aprovechamiento de recursos y la productividad Como estrategia de negocio: Compromiso organizacional que permita adoptar las premisas de dicho paradigma y enmarcarlas dentro de la estrategia de la empresa. Implica un cambio de mentalidad tanto desde las líneas directivas como de las áreas operativas de la empresa. ¿Qué es SOA?

11. Integración punto a punto Dependencia entre sistemas Dificultad de mantenimiento Alto acoplamiento Responsabilidades poco claras

12. Service Oriented Architecture

13. El termino SOA fue usado por primera vez por Gartner en 1996. Hacia foco en la interacción entre módulos (consumidor y proveedor) usando comunicación request/response. Fue una evolución a RPC. En 2003 logra ingresar al mercado por medio de los web services. Estandarización Flexibilidad Firewall friendly Diversas empresas (IBM, Microsoft, Sun, Oracle, etc.) SOA en sus inicios.

14. Hoy en día SOA se ve como Una estrategia de IT Una estrategia de negocio Un estilo de Arquitectura de software Una arquitectura empresarial Un nuevo paradigma Una filosofía de trabajo SOA hoy.

15. Microsoft IBM Tibco Oracle Software AG SAP Sonic Software Etc. Proveedores de SOA

16. IT juega un rol fundamental en la estrategia de negocio de una empresa. Sin embargo, la estrategia de IT no es vista como “socia” de la estrategia de negocio. Frecuentemente es percibida como lenta y no se mueve con la velocidad que el negocio requiere Esto genera un gap entre las necesidades del negocio y la ejecución de IT. SOA, el negocio y las empresas Business GAP

17. SOA, el negocio y las empresas Las compañías y empresas desarrollan las estrategias de negocio por un lado y luego intentan implementarlas a través de una estrategia de IT separada. Las estrategias son consideradas desde puntos de vista diferentes. Business strategy: Considera la empresa en su conjunto a largo plazo IT strategy: Se considera a corto plazo para atender las necesidades puntuales de una línea de negocio. El resultado es un programa IT en silos que no es compatible con la empresa en su conjunto.

18. SOA, el negocio y las empresas La realidad es que existen procesos “cross” que involucran más de un aspecto del negocio y que estos suelen ser los de mayor valor para la empresa. Ventas Producto Logística Almacenes Ventas: Desde el cliente hasta la entrega Realizar Campañas

19. Desafíos: IT soporte el negocio y responsa rápidamente a necesidades de cambios. Aumentar la productividad. Minimizar el gap entre las necesidades de negocio y la ejecución de IT. Esto requiere cambios fundamentales y fundacionales para alineas ambas estrategias. SOA Program SOA, el negocio y las empresas

20. SOA, el negocio y las empresas Ventas Producto Logística Almacenes Ventas: Desde el cliente hasta la entrega Realizar Campañas Las aplicaciones existentes no suelen soportar bien la dinámica de cambio en los procesos “cross-organizational” App Ventas (Vendor A) App Prod. (Vendor B) Logistica (Excel) Ordenes (Custom) SOA Business y IT son socios

21. SOA, el negocio y las empresas Lógica de negocio Lógica de aplicación Modelo del negocio y lógica de los dominios (altamente acoplados)

22. SOA, el negocio y las empresas Lógica de negocio Lógica de aplicación Modelo del negocio, modelo de servicios y lógica de los dominios (Los servicios se interponen entre las aplicaciones y la lógica del negocio) Aplicación A Aplicación B Aplicación C Servicios

23. SOA, el negocio y las empresas Lógica de negocio Lógica de aplicación Modelo del negocio, modelo de servicios y lógica de los dominios (Los servicios abstraen la conectividad de las aplicaciones y sus entornos) Aplicación A Aplicación B Aplicación C Servicios Los servicios hacen convergente al negocio con la lógica de las aplicaciones

24. SOA requiere cambios en la cultura de una organización. La manera en que las personas trabajan En como piensan En como lograr entregar funcionalidad al negocio Un programa SOA es una forma. Promueve compartir y entender la estrategia de negocio global. Define el roadmap a seguir. Define la arquitectura (dinámica y basada en estándares) Identifica y optimiza los procesos de negocio. Determina las prioridades para el desarrollo de servicios. Establece el governance para asegurar que los procesos, políticas y estándares sean seguidos. SOA Program

25. Estilo de arquitectura que permite construir sistemas basados en la interacción de componentes autónomos de granularidad gruesa llamados servicios . Cada servicio expone procesos y comportamiento a través de contratos. Arquitectura SOA

26. “ una facilidad para suministrar alguna demanda pública” Merriam Webster “ un mecanismo para acceder a una o mas capacidades, donde el acceso es provisto por medio de una interface prescripta y se ejerce de conformidad con restricciones y políticas tal cual se especifica en la descripción del servicio” OASIS Es una unidad bien definida de funcionalidad que es accesible vía un protocolo estándar y puede ser invocada por medio de una interface bien definida. Dentro de una arquitectura SOA el servicio sigue un conjunto de principios y puede estar monitoreado y manejado. Servicio

27. Cada recurso de IT, ya sea una aplicación, sistema, partner, puede ser accedido por medio de un servicio. Mediante la composición de servicios se logran crear nuevos servicios que implementan nueva lógica de negocios. Rápida respuesta a los cambios del negocio. Reducción de costos. Reduce la complejidad. Servicio

28. El contrato es la colección de todos los mensajes que puede soportar el servicio. El contrato es unilateral. El contrato puede ser considerado como la interface del servicio. El endpoint es la dirección (URI) donde el servicio puede ser encontrado y consumido. Un contrato especifico puede ser expuesto en un endpoint especifico. Contrato y endpoint

29. La unidad comunicacional de SOA es el mensaje. Un mensaje tiene: Header: Información genérica. Puede ser entendido por componentes de infrastructura o frameworks. Por ejemplo: Seguridad, Ruteo de mensajes, etc. Body: Información particular del mensaje Mensaje

30. Las políticas separan la especificación dinámica de la estática/semántica. Una política representa condiciones para la especificación semántica para los consumidores del servicio. Los aspectos de una política pueden ser actualizados en runtime y son externos a la lógica de negocio. Ejemplo: SLA Auditoria Seguridad Políticas

31. Bajo acoplamiento: La relación entre los servicios minimiza las dependencias Definición de un contrato de servicio: Los servicios adhieren a un acuerdo de comunicación definido en los descriptores de servicios Autonomía: Los servicios tiene control total sobre la lógica que encapsulan Abstracción: Fuera de lo que se describe en los contratos de servicio los mismos ocultan su lógica al mundo exterior. Reusabilidad: La lógica se distribuye en los servicios con la intención de reusabilidad. Principios

32. Composición: Se combinarán colecciones de servicios coordinándolos y ensamblándolos de manera que se formen servicios compuestos Sin estado Los servicios minimizarán la retención de información específica de una actividad Descubrimiento Los servicios son diseñados de manera que sea posible describirlos para que puedan ser encontrados y accedidos vía mecanismos de descubrimiento. Principios

33. Principios

34. Una arquitectura de referencia refiere a la definición de una arquitectura para un dominio en particular. Describe en alto nivel los elementos involucrados y sus interacciones en un software en un dominio. Los elementos son diseñados intencionalmente en alto nivel para poder aplicar a un gran número de sistemas para ese dominio. Una arquitectura de referencia SOA es la definición de SOA dentro de un dominio. Es un framework que ayuda a guiar la implementación de SOA, y debe ser tomado como un canal de comunicación de las especificaciones de arquitectura. Arquitectura de referencia

35. Arquitectura de referencia

36. Surgió como intento para resolver la integración de sistemas empresariales ( enteprise integration spaghetti ). Logro el objetivo de conectar aplicaciones y transferir datos entre estas en una forma no-estándar (o semi-estándar). Enterprise Application Integration

37. Arquitectura Hub and spoke (o bus) Pero ha fallado en: No estándar Conectores y adaptadores propietarios. Centrado en datos y aplicaciones pero no en procesos ni servicios. No puede seguir el ritmo de los procesos de negocio. Son complejas técnicamente. Por lo general dependen de un vendor. Costosas. Son centralizados. No existe abstracción. Enterprise Application Integration

38. “ Infraestructura software que posibilita SOA, al actuar como una capa de middleware de intermediación a través del cual se puede acceder a un conjunto de servicios de negocio reutilizables” Mike Gilpin, Forrester Research, Agosto 2004 Es el componente encargado de conectar a todos los participantes en un SOA. Permite una abstracción a nivel de servicios. Es un elemento fundamental para la implementación de SOA. Enterprise Service Bus

39. Incorpora diferentes tecnologías: MOM Web Services REST Legacy connectors Hace un intensivo uso de estándares (XML, WS, WSLD, HTTP). Implementa o lleva a la implementación de patrones de integración. Enterprise Integration Patterns (Gregor Hohpe) Enterprise Service Bus

40. Características: Conectividad : Suministra interconexión de los participantes en una SOA. Servicios y aplicaciones (front-end) pueden invocar funcionalidad de otros servicios. Soporte a tecnologías heterogéneas : Suministra compatibilidad con estándares y tecnologías, protocolos y plataformas propietarias. Soporte a paradigmas de comunicación : Da soporte a comunicación sincroniza y asincrónica, así como también a capacidades de integración: transformación y enrutamiento de mensajes, auditoria, logging, transacciones, seguridad, etc. Beneficios: Bajo acoplamiento. Location Transparency Service orquestation Enterprise Service Bus

41. Enterprise Service Bus 

42. EAI vs ESB EAI ESB Dependen del vendor Soporta estandares Centralizado Distribuido Integra aplicaciones Integra servicios Hub and Spoke Bus Baja escalabilidad Modelo federado Alto costo Costo flexible

43. Un proceso de negocio es un conjunto de actividades que generan un valor para la empresa. Un proceso de negocio es un conjunto de tareas relacionadas lógicamente llevadas a cabo para lograr un resultado de negocio definido. La orientación SOA permite modelar un proceso como una “orquestación” de servicios. Ejemplo: Otorgar un crédito (banco). Activar una línea (Telco). Presentar una DDJJ (Gubernamental). Proceso de negocio

44. Un proceso de negocio se compone de: Actividades: Son las tareas (humanas o automatizadas) dentro del proceso. Roles y usuarios: Son los responsables de ejecutar las tareas. Objetivo de negocio. Flujos: Secuencia que se define entre las actividades. Decisiones: Criterios para tomar distintas direcciones en un flujo. Subprocesos Proceso de negocio

45. Es el conjunto de servicios y herramientas que facilitan la administración de procesos de negocio. Por administración de procesos entendemos: análisis, definición, ejecución, monitoreo, y control de los procesos. Un BPM crear, modela, ejecuta y optimizar procesos de negocio. La adopción de SOA y BPM están muy relacionadas. Un reciente estudio de Forrester mostró que el 92% de los encuestados que estaban implementando SOA también consideraban que BPM es importante para el futuro de su organización. Business Process Management

46. Herramientas: Modelador: Diseñar procesos de negocio IDE: Desarrollar/integrar los servicios para implementar el proceso. Monitor Business Process Management

47. Business Process Management Ejemplo: Proceso de negocio: Aprobación de reintegros (Prepaga) a través de la web. Notación: BPMN

48. Business Process Management

49. Notaciones: BPMN: Intalio BPMS, TIBCO Business Studio BPEL: IBM WebSphere Business Modeler, Oracle BPEL Process Manager XPDL: TIBCO Business Studio, JBoss JBPM BPM se ejecuta: BPMN engine: Intalio BPMS, ActiveMatrix BPM BPEL engine: Intalio BPMS, IBM WebSphere Process Server, Oracle BPEL Process Manager Business Process Management

50. Business Process Management

51. Es una lenguaje estandarizado (por OASIS) para la composición y orquestación de Web Services. Es un lenguaje basado en XML para describir la lógica que orquesta la interacción entre web services en un proceso de negocio. Business Process Execution Language

52. Business Process Execution Language

53. Business Process Execution Language <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <process name=&quot;SynchronousSample&quot; targetNamespace=&quot;http://enterprise.netbeans.org/bpel/SynchronousSample2/SynchronousSample&quot; xmlns=&quot;http://docs.oasis-open.org/wsbpel/2.0/process/executable&quot; xmlns:xsd=&quot;http://www.w3.org/2001/XMLSchema&quot; xmlns:sxt=&quot;http://www.sun.com/wsbpel/2.0/process/executable/SUNExtension/Trace&quot; xmlns:sxed=&quot;http://www.sun.com/wsbpel/2.0/process/executable/SUNExtension/Editor&quot; xmlns:tns=&quot;http://enterprise.netbeans.org/bpel/SynchronousSample2/SynchronousSample&quot; xmlns:ns0=&quot;http://xml.netbeans.org/schema/SynchronousSample&quot;> <import namespace=&quot;http://j2ee.netbeans.org/wsdl/SynchronousSample&quot; location=&quot;SynchronousSample.wsdl&quot; importType=&quot;http://schemas.xmlsoap.org/wsdl/&quot;/> <partnerLinks> <partnerLink name=&quot;PartnerLink1&quot; xmlns:tns= http://j2ee.netbeans.org/wsdl/SynchronousSample partnerLinkType=&quot;tns:SynchronousSample&quot; myRole=&quot;SynchronousSamplePortTypeRole&quot;/> </partnerLinks> <variables> <variable name=&quot;outputVar&quot; xmlns:tns=&quot;http://j2ee.netbeans.org/wsdl/SynchronousSample&quot; messageType=&quot;tns:SynchronousSampleOperationResponse&quot;/> <variable name=&quot;inputVar&quot; xmlns:tns=&quot;http://j2ee.netbeans.org/wsdl/SynchronousSample&quot; messageType=&quot;tns:SynchronousSampleOperationRequest&quot;/> </variables> <sequence> <receive name=&quot;start&quot; createInstance=&quot;yes&quot; partnerLink=&quot;PartnerLink1&quot; operation=&quot;SynchronousSampleOperation“ xmlns:tns=&quot;http://j2ee.netbeans.org/wsdl/SynchronousSample&quot; portType=&quot;tns:SynchronousSamplePortType&quot; variable=&quot;inputVar&quot;/> <assign name=&quot;Assign1&quot;> <copy> <from>$inputVar.inputType/ns0:paramA</from> <to>$outputVar.resultType/ns0:paramA</to> </copy> </assign> <reply name=&quot;end&quot; partnerLink=&quot;PartnerLink1&quot; operation=&quot;SynchronousSampleOperation“ xmlns:tns=&quot;http://j2ee.netbeans.org/wsdl/SynchronousSample&quot; portType=&quot;tns:SynchronousSamplePortType&quot; variable=&quot;outputVar&quot;/> </sequence> </process>

54. Business Process Execution Language

55. El verdadero valor de SOA, y BPMS, es la visibilidad que se provee de la operaciones de negocio. Visualizar en tiempo real e histórica las actividades de los procesos. Monitorear la performance de los procesos de negocio, y su estado. Obtener indicadores de performance y SLA. BAM es una tecnología que muestra en tiempo real el estado y evolución de las actividades de negocio. Business Activity Monitoring

56. El objetivo de BAM proveer información en tiempo real acerca del estado y resultados de diversas operaciones, procesos y transacciones. La mayor aportación es permitir a la organización tomar decisiones en base a información más completa y real, identificar rápidamente las causas y poder reorientar las organizaciones para sacar ventaja de las oportunidades. Tablero de control o dashboard. Business Activity Monitoring

57. Es una técnica para el procesamiento de gran cantidad de eventos (flujos de mensajes) y descubrir patrones complejos entre múltiples flujos de datos. CEP se nutre de la información asociada a los eventos que ocurren en la organización, a partir de los propios procesos ya sean de BPM o internos de un sistema. Un CEP recoge los eventos en tiempo real, los correlaciona con el histórico y extrae conclusiones para lanzar acciones o asistir al directivo en decisiones que le permitan adaptar la organización al mercado. Complex Event Processing

58. Beneficios: Visibilidad: Sistemas, aplicaciones Predicción Inferir comportamientos Información en tiempo real Ejemplos: Detección de fraudes Gestión de SLAs. Logística y operación de vuelos. Análisis de acciones en el mercado financiero. Complex Event Processing

59. Sirve de interface homogénea y única para las aplicaciones SOA y BPM. Provee una visualización única de todas las herramientas y aplicaciones que un usuario final requiere para ejecutar su trabajo. El objetivo es lograr reutilización y customización a nivel de presentación (portlets). Mejora la administración de recursos. Portal

60. Dentro de una organización tendremos: cientos o miles de servicios en donde cada servicio expone un contrato bien definido. cientos de entidades de negocio que es necesario modelar. Los servicios implementan lógica de negocio… Los servicios de negocio usen las entidades de negocio. Las entidades de negocio serán parte de la entrada o la salida de cada servicio. Si cada servicio utiliza un modelo de datos particular para representar una entidad de negocio… Transformaciones entre modelos de datos Incrementa el desarrollo Diseño complejo Overhead en runtime Canonical Model

61. Un modelo de datos canónico define de manera estandarizada a las entidades de negocio de la organización. Los servicios, en su contrato, usan este modelo estándar Evitando así transformaciones. Desacoplando a nivel de mensaje los sistemas. Existirán servicios que no pueden aplicar el modelo canónico Habrá transformaciones pero siempre entre el tipo particular y el modelo canónico. Los mensajes dentro del ESB siempre tendrán la forma canónica. Canonical Model

62. SOA: Cambia la forma de pensar basada en aplicaciones a una perspectiva que abarque toda la empresa. Es necesario poder controlar la forma en la que se cumple con los flujos de trabajo y la forma en la que se desarrollan, implementan y gestionan los servicios durante todo su ciclo de vida para así cumplir los objetivos de negocios de la empresa. Los servicios desarrollados en un área deben poder ser reutilizados por procesos a lo largo de la organización. El gobierno (o gobernabilidad) SOA ofrece a las organizaciones la capacidad de definir, promover y contabilizar las mejores prácticas SOA, estándares y alineación de las necesidades de negocio con TI y los servicios generados. Governance

63. “ El conjunto de normas, prácticas, funciones, responsabilidades y acuerdos (tanto formales como informales) que controlan la forma en la que trabajamos” IBM El Governance es la tecnología que permite no sólo tener visibilidad sobre la arquitectura SOA completa, sus servicios y rendimiento, sino también gobernar la plataforma en su día a día y su evolución con un enfoque “end-to-end” donde las interrelaciones entre servicios, proveedores y consumidores sean visibles. Governance

64. Define: Que se debe hacer: Definiendo un plan/estrategia global (SOA Roadmap o SOA Program). Como se debe hacer: Definiendo procesos, normal, estándares, políticas, best practices, productos y herramientas, etc. Quien lo debe hacer: Grupos de trabajos (SOA Office, EA Office, etc.) Como medir: Métricas para medir el éxito. Governance

65. Es una herramienta de governance que permite: Gestión única, centralizada y escalable de los servicios. Publicación y descubrimiento de servicios. Visibilidad: El analista de negocio necesita determinar que servicios estan disponibles para automatizar procesos de negocio. El desarrollador necesita conocer los servicios disponibles para determinar el reuso. El arquitecto necesita conocer el versionado y dependencias de servicios. Gestión operativa necesita saber como administrar los servicios. Promueve el reuso: Aumenta el ROI Composición Registro

66. Material SOA-Introducción.pdf SOA-MaterialAdicional.pdf Encuesta. Gracias por su atención!!!! Cierre

67. Preguntas finales