1 Maestría en Ingeniería Arquitectura de Software Sesión 10 Fernando Barraza A., Ms.C [email protected]

2 Sesión 10 Objetivo: Exponer los fundamentos básicos sobre la arquitectura de software orientadas a servicios - SOA Temas: –Que es SOA –Web Services y SOA –Escenarios de Aplicación –Clasificación de Servicios para SOA –Integración de Aplicaciones a SOA

3

4 Service Oriented Computing A system that is designed using a Service Oriented Architecture is called a Service Oriented System. The practice of using Service Oriented Systems is called Service Oriented Computing. For developers Truly reusable components Simplified system integration Extensible Systems For users Available systems Secure data Plug and Play Zero-administration Accessibility of services Key benefits of Service-Oriented Computing* *Introduction to Service-Oriented Programming Guy Bieber, Lead Architect, Motorola ISD and Jeff Carpenter, Software Engineer, Motorola ISD

5 5 Service Oriented Computing The Marketing Message What is SOA? SOA enables flexible connectivity of applications or resources by: representing every application or resource as a service with a standard interface enabling them to exchange structured information. Why do you care? SOA helps introduce flexibility in a technology environment. There is growing acceptance of SOA as an approach to integration and to structure collections of interacting applications. Business Flexibility IT Simplification Horizontal Process Partner Integration Infrastructure Management The flexibility to treat business processes and the underlying infrastructure as defined components that can be mixed and matched at will

6 6 Attributes of a Services Oriented Architecture Design  Services are discoverable and dynamically bound.  Services are self-contained and modular.  Services stress interoperability.  Services are loosely coupled.  Services have a network-addressable interface.  Services have coarse-grained interfaces.  Services are location-transparent.  Services are composable.  Service-oriented architecture supports self-healing. -Sun Microsystems, Jini Technology Architectural Overview 2001

7 SOA: What is a service? Services … Expose a well defined interface Hide their implementation details Are callable through open standards mechanisms Can be coarse grained, fine grained, or somewhere in the middle. A coarse grained service is one that exposes a very high level business function that, when invoked, calls many other internal services. (think of this as a main program that calls subroutines for example) A fined grained service is one that implements a very specific function and only that function (think of this as a atomic subroutine with a specific purpose) Exhibit either request/response or “fire and forget” behavior.

8 Servicios y SOA Estandar y Facilidad de implementación Flexibilidad en cambios del negocio (orquestación) Necesidad de plataformas robustas de gestión de SOA

9 Escenarios de Aplicación Integración de Aplicaciones de Negocio (EAI) B2B Mejorar y extender procesos de negocio Aprovechar capacidad computacional distribuida

10 Escenario típico

11 Escenario SOA

12 Evolución de SOA

13 13 SOA: Valor de los Servicios de Información Ocultar la complejidad al acceder, agregar y replicar en fuentes de datos dispares Servicios de Aplicaciones de Negocio Servicios de Conectividad Servicios con Partners Servicios de Procesos Servicios de Interacción Servicios de Información Activos de Aplicación e Información

14 14 SOA: Connectividad – Permitir a los servicios interactuar Request/Response Coarse Grained Fire and Forget Fine Grained Request/Response Fine Grained Request/Response Coarse Grained Servicio A MQSeries Servicio B SOAP/HTTP Servicio C SOAP/JMS Servicio D HTTPS Consideraciones: Protocolo de comunicaicón, formato de datos, ruteo, caracteristicas de transporte, etc

15 SOA: Connectividad – Separación de Preocupaciones Request/Response Coarse Grained Fire and forget Fine Grained Request/Response Fine Grained Request/Response Coarse Grained Servicio A MQSeries Servicio B SOAP/HTTP Servicio C SOAP/JMS Servicio D HTTPS Separar la preocupación de conectividad e implementarlos en una capa superior de abstracción: Servicios de Conectividad - ESB Servicios de Transporte Assured delivery Secure delivery Transactional delivery Manageable delivery Delivery replay Modifiable qualities of transport. Servicios Mediación Routing Transport switching Programming model switching Content augmentation Customized communications. Basado en Estándares MQSeries, JMS, JAX-RPC, SOAP HTTP/HTTPS Web Services Servicios de Conectividad Servicios Eventos Event detection Event triggering Event distribution Complex Event Processing (CEP)

16 16 SOA: Elementos de Control (Proceso) – Separación de Preocupaciones Request/Response Coarse Grained Fire and Forget Fine Grained Request/Response Fine Grained Request/Response Coarse Grained Servicio A MQSeries Servicio B SOAP/HTTP Servicio C SOAP/JMS Servicio D HTTPS Separar la preocupación de los detalles del proceso empresarial y colocarlos en la infraestructura 1 2 3 4 Notese que el proceso también es un servicio que puede ser llamado mediante los Servicios de Conectividad

17 Servicios de Conectividad Servicios de Procesos Recibir Orden Verificar Crédito Confirmar Orden Reservar Inventario Determinar Transporte Empaquetar y enviar Enviar Recibo Ejemplo de Proceso Servicios de Coreografía Flujo determinado por reglas de negocio externas Reglas pueden ser cambiadas separadamente Servicios de Transacciones de Negocio Compensación de transacciones Servicios de Estado de Proceso Actividades de larga duración Servicios de Staff Asignación de personas determinada por reglas de negocio Puede involucrar personas a aplicaciones SOA: Elementos de Control (Proceso) – Separación de Preocupaciones Servicios Aplicación de Negocio Servicios con Partner Activosde Aplicación e Información

18 BPMy SOA

19 SOA: Elementos de Control (Interacción Usuario) Request/Response Coarse Grained Request Fine Grained Request/Response Fine Grained Request/Response Coarse Grained Servicio A MQSeries Servicio B SOAP/HTTP Servicio C SOAP/JMS Servicio D HTTPS Consideraciones: Interfases gráficas de usuario dispares (por ejemplo 3270, Web, Cliente pesado, etc) Lógica requerida en servicios para manejar dispositivos específicos Usuarios deben entender complejidad de todas las interfases Etc.

20 SOA: Elementos de Control (Interacción Usuario) – Separación de Preocupaciones Request/Response Coarse Grained Request Fine Grained Request/Response Fine Grained Request/Response Coarse Grained Servicio A MQSeries Servicio B SOAP/HTTP Servicio C SOAP/JMS Servicio D HTTPS Separar la preocupación de los detalles de la interacción de usuario y colocarlos en la infraestructura Tradicional Pervasive

21 SOA: Elementos de Control (Servicios de Interacción) – Separación de Preocupaciones Request/Response Coarse Grained Request Fine Grained Request/Response Fine Grained Request/Response Coarse Grained Servicio A MQSeries Servicio B SOAP/HTTP Servicio C SOAP/JMS Servicio D HTTPS 1 2 3 4 Notese que un servicio de interacción de usuario puede tanto llamar como ser llamado desde un proceso mediante los servicios de conectividad. Asi es como los procesos interactuan con laspersonas y como las personas inician procesos.

22 SOA: Elementos de Control (Información) Request/Response Coarse Grained Servicio A MQSeries Texto DB2 Oracle Excel Ejemplo, para lograr unafunción de datos de negocio, el servicio A debe acceder a cuatro fuentes de datos y combinar los resultados. Consideraciones: Mecanismos de acceso dispares (por ejemplo lectura/grabacación de archivos de texto, diferentes sabores de SQL, etc.) El programador debe añadir lógica para trabajar con cualquier fuente de datos a la cual se quiere conectar Cualquier federación o replicación de datos esta en manos del programador

23 SOA: Elementos de Control (Servicios de Información) – Separación de Preocupaciones Request/Response Coarse Grained Servicio A MQSeries Texto DB2 Oracle Excel Con Servicios de Información, el Servicio A puede obtener la misma información mediante una base de datos federada. Esto oculta la complejidad de las fuentes de datos del servicio A, añadiendo mayor flexibilidad. La base de datos federada es un servicio que puede ser llamado mediante los servicios de conectividad Nota: Replicación de datos distribuida y administración de contenido son otras capacidades provistas por los servicios de información Data Wrappers

24 SOA: Adaptando Servicios de Negocio Existentes ¿Puede la aplicación ser cambiada? Si no, queremos cambiarla o dejarla como esta (as- is)? ¿Soporta la aplicación cualquiera de los protocolos nativos del ESB (por ejemplo JMS, MQSeries, Web Services, HTTP(S), etc.)? ¿Que nivel de granularidad queremos exponer? Si una aplicación no soporta nativamente los estándares abiertos, se debe “adaptar” al ESB … Considerar lo siguiente: Crear interfase abierta estándar Conecta directamente al ESB No Si ¿Interfase estándar open nativa? ¿Cambiar Aplicación? Adaptar aplicación Usando interfases existentes No Si

25 SOA: Adaptar aplicaciones existentes usando interfases existentes Los adaptadores son componentes que permiten la conexión de interfases de aplicación no estándares al ESB basado en estándares. Transacción CICS Servicio A (parámetro, return) VSAM DB2 Request/Response Coarse Grained MQSeries Componente específico de aplicación Adapter Framework Interfase Estándar Open SAP Servicio D (parámetro, return) Request/Response Coarse Grained DB2 HTTPS Componente específico de aplicación Adapter Framework Interfase Estándar Open XML COBOL Copybook IDOC XML Agente Object Discover Detección de Eventos

26 SOA: Adaptar aplicaciones existentes usando interfases existentes Los adaptadores deben ser manejados por eventos, bi-direccionales y basados en un framework. Categorías de adaptadores: 1)Adaptadores de aplicación  Adaptadores que conectan a paquetes populares tales como SAP, i2, Peoplesoft, Siebel, etc. 2)Adaptadores de tecnología  Adaptadores que conectan a arquitecturas de aplicación comunes tales como bases de datos, email, CORBA, basados en archivos, etc. 3)Adapter framework  Consiste de plantillas para crear adaptadores a aplicaciones específicas

27 Créditos Essential Software Architecture. Ian Gorton. Describing Software Architectures. Gert Florijn. Workshop de Arquitectura I/T, Bogotá 2005. Carlos Bittrich. IBM.