Arquitecturas Orientadas a Servicios (SOA) TEMA III: Arquitecturas Orientadas a Servicios

Transcripción

1 Master Oficial en Sistemas Telemáticos e Informáticos Arquitecturas Orientadas a Servicios (SOA) TEMA III: Arquitecturas Orientadas a Servicios Tema 3 Concepto y Estándares 1

2 Una Arquitectura Orientada a Servicios ( Service-oriented Architecture - SOA) proporciona métodos, integración, infraestructura para desarrollar aplicaciones inter-operables basadas en servicios (Web) y en procesos de negocio. 2

3 Las piezas básicas b son los servicios Servicio: función n en la red bien definida que consta de una interfaz procesable y cuya implementación n es reemplazable Para buscar un servicio con el cual conectarse, se puede consultar a otro servicio bien conocido que contiene interfaces Los protocolos de acceso a los servicios usan protocolos abiertos y estandarizados (HTTP, TCP/IP) como transporte (para servicios de Internet) Mejora el modelo cliente-servidor en sistemas distribuidos para facilitar la interoperabilidad 3

4 4

5 Pila de servicios Web Source: [Ferguson] WS-Security WS-ReliableMessaging WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity 5

6 Principios de diseño técnico de SOA Cada servicio implementa una función de negocio discreta Los servicios y sus implementaciones deben ser reutilizables Los servicios comparten un contrato formal: interfaz de servicio (SLA) Los servicios están poco acoplados entre ellos Composición: se pueden ensamblar servicios para obtener otros más complejos Autónomos: cada servicio debe ser capaz de funcionar de forma independiente Sin estado: el uso de un servicio no debe depender de usos previos Transparentes de localización: funcionan independientemente de quién y dónde los usan 6

7 Definición de Arquitectura Orientada a Servicios Entorno de aplicaciones capaz de descomponer aplicaciones comunes de negocio y dividirlas en funciones individuales y procesos servicios. SOA permite construir, desplegar e integrar estos servicios independientemente de las aplicaciones y plataformas sobre las que se ejecutan. IBM Enfoque de organizar la tecnología de información en el que los datos, lógica y recursos de infraestructura se acceden mediante mensajes entre interfaces de red. MS Conjunto de componentes que pueden ser invocados, cuyos descripciones de interfaces pueden publicarse y descubrirse. W3C 7

8 Atributos de calidad para SOA Interoperabilidad: Web-Services Interoperability Organization WS-I Fiabilidad: WS-Reliability, WS-ReliableMessaging Disponibilidad: Service Level Agreement (SLA) Usabilidad Seguridad: WS-Trust, WS-Federation Rendimiento Escalabilidad: distribución de carga en servidores Extensibilidad: añadir servicios adicionales Adaptabilidad: diferentes configuraciones Contabilidad Facilidad de operación y despliegue: automatización de operaciones 8

9 Arquitectura corporativa SOA Nivel de infraestructura de servicios: funciones de uso general Nivel de servicios de negocio: workflow Composiciones de servicios: tareas de negocio en pasos simples Nivel de orquestación o nivel de procesos de negocio: BPEL Registro de servicios Nivel de mensajería: ESB, soporte para mensajes Gestión de servicios: políticas de carga, seguridad, rendimiento 9

10 SOA Genérico Fuente: JavaWorld 10

11 11

12 De BPM y EA a SOAD Los métodos clásicos (BPM, EA, OOAD) no son suficientes para modelar: Servicios,Flujos, Componentes realizando servicios. BPM carece de semántica (no como BPEL). EA clásicos (TOGAF) no proporcionan vista de procesos y/o servicios. 12

13 OOAD versus SOAD El nivel de granularidad es distinto en OOAD (nivel de clase) y SOAD (nivel de servicio). La herencia OO crea dependencias muy fuertes comparadas con el bajo acoplamiento de los servicios Web. No hay soporte para herencia a través de plataformas. 13

14 Jerarquía y elementos SOAD Servicios diferentes colaborando (orquestration). SOAD proporciona procesos de negocio y notación para dichos procesos. SOAD proporciona roles (arquitecto, analista). SOAD proporciona principios y factores de calidad (flexibilidad, bajo acoplamiento, stateless). SOAD debe proporcionar servicios reutilizables. 14

15 Ejemplo de proceso de negocio (orden de trabajo en automoción) FLUJO DE TRABAJO SERVICIOS 15

16 SOMA (Service-oriented modeling and architecture) El modelo conceptual de la figura define la interacción entre 3 entidades: el proveedor de servicios, el consumidor del servicio y el broker del servicio el cual mantiene su registro. 16

17 SOMA (Service-oriented modeling and architecture) Los estilos arquitectónicos que definen una SOA se basan en bajo acoplamiento, servicios centrados en aspectos de negocio, flexibilidad, y separación entre descripción, implementación y biding. SOA es una arquitectura IT corporativa y escalable para soportar recursos bajo demanda que proporcionen valor de negocio. 17

18 SOMA (Service-oriented modeling and architecture) Arquitectura SOA en niveles para servicios compuestos y procesos de negocio. La relación entre servicios y componentes es tal que los componentes de negocio de grano grueso hacen que los servicios sean responsable de proporcionar tal funcionalidad y de mantener la calidad del servicio. La comunicación y la integración de la arquitectura se realiza mediante un Enterprise Service Bus (ESB) (Jazz.net, IBM) 18

19 SOMA (Service-oriented modeling and architecture) Identificación de servicios en componentes antiguos Decisiones de diseño arquitectónicas en cada nivel de la SOA deben reflejar el uso de servicios y su composición. Mayor funcionalidad para servicios compuestos y pequeña funcionalidad para servicios individuales. SOA es más estratégico y centrado en el negocio mientras que el uso de servicios Web es más táctico. 19

20 Método SOMA (Service-oriented modeling and architecture) Identificación de servicios: Identificar servicios de negocio en áreas funcionales, subsistemas y procesos (top-down), mientras que la solución bottom-up examina legacy assets como potenciales servicios candidatos. Clasificación de servicios: Los servicios identificados se organizan en una jerarquía para determinar servicios compuestos y en que nivel o capa actúa cada servicio. Asignación de servicios: Que servicios van a que subsistema y a cada capa de la arquitectura SOA. Realización de servicios: Implementación del servicio, wrapper de legacy, o externalización 20

21 Arquitectura de integración de Jazz (JIA) JIA define un conjunto de servicios denominados Jazz Foundation Services (JFS), herramientas para utilizarlos y para crear servicios propios y utilizando interfaz RESTful. JIA es una arquitectura de referencia, un API, servicios comunes y herramientas para componer elementos. A nivel de implementación, el núcleo de JIA es el Jazz Team Server (JST) el cual implementa los JFS descritos en JIA. Herramientas para exponer datos y servicios. Un API REST que proporciona: URLs estables para los recursos de datos, representaciones documentadas de los recursos de datos, un protocolo y operaciones basados en métodos del protocolo HTTP para manipular los datos. Servicios Web orientados a recursos mediante métodos POST y GET entre otros. 21

22 Arquitectura de integración de Jazz (JIA) Cada Jazz Team Server proporciona Foundation Services que permiten a un conjunto de herramientas trabajar de forma conjunta como si fueran un único servidor lógico. JTS utiliza servicios Web RESTful y las interacciones se realizan mediante el API REST. JIA permite a único JTS tener múltiples servidores trabajando con clientes, donde cada servidor es responsable de administrar sus propias URLs y responder a las peticiones de los clientes. 22

23 Arquitectura de integración de Jazz (JIA) Un único JTS puede consistir en uno o varios servidores que actúan de manera conjunta. Los JFS suelen alojarse en un único servidor. Las extensiones se suelen implementar como aplicaciones Web (ficheros WAR empaquetados) y posteriormente desplegados. Algunas extensiones JTS pueden requerir su propio servidor de manera separada (herramientas de Rational que añaden funcionalidad extra). 23

24 Características de un ESB Comunicación mediante mensajes sobre el cual se define una capa de abstracción para integrar y proporcionar servicios Un ESB no es una SOA pero proporcionan características para implementarla Componente HTTP Herramientas de control de flujo BPEL (Business Process Execution Language) Scripting Herramientas de transformación XML XSLT (extensible Stylesheet Language Transformations) Integración con servidores J2EE 24

25 Integración de elementos en SOA 25

26 ESB 26

27 Middleware para SOA SAP NetWeaver BPM: Configuración SOA para invocar servicios Web que se publican en un Service Registry y simplificar la configuración y uso de WS. Los WS se importan dentro del SAP NetWear Developer Studio antes de ser registrados. 27

28 Middleware para SOA Ejemplo con SAP NetWeaver BPM 28

29 Middleware para SOA Oracle/SOA Service Oriented Architecture Application Server Enterprise (BPEL Process Manager, Business Activity Monitoring, XML Publisher, Service Registry, SOA Suite for Oracle Middleware) ORACLE SOA Suite Web Center (Oracle Web Logic Server, soporte BPEL for long-running processes, Capa intermedia con Oracle B2B, XML, Enterprise Service Bus, etc.) 29

30 Middleware para SOA ORACLE Composite Editor de un proyecto SOA 30

31 Middleware para SOA IBM WebSphere Application Server Soporte para: Java 2 EE 5 Servicios Web Web 2.0 BPEL WS-Security Enterprise Architect kit para SOA Enterprise service Bus para virtualizar servicios Conectividad a servicios de terceros Interoperabilidad con SOAP 31

32 Arquitecturas Cloud Es un paradigma que permite ofrecer servicios de computación en la red. A diferencia del Grid computing, más enfocado a compartir recursos, Cloud computing comparte servicios y en los que los recursos hardware se encuentran virtualizados. La virtualización de recursos físicos es uno de los puntos fuertes de la filosofía Cloud para ofrecer éstos bajo demanda. Puede existir un pago por uso de servicios. 32

33 Arquitecturas Cloud Tipos de Cloud (modelos de despliegue) Cloud público: Un proveedor de servicios ofrece recursos sobre Internet como por ejemplo aplicaciones y almacenamiento. Cloud privado: Es una infraestructura Cloud administrada por un organización pero los recursos pueden pertenecer a la propia organización o externos. Cloud comunitario: Comparten infraestructuras entre diferentes organizaciones pertenecientes a una comunidad específica y administradas Internamente o por un tercero. Cloud híbrido: Es una composición de dos o más Cloud de los tipos anteriores que constituyen una entidad única. 33

34 Arquitecturas Cloud Capas en Cloud 34

35 Arquitecturas Cloud Software para Cloud 35

36 Arquitecturas Cloud Capa 4 Capa 3 Capa 2 Capa 1 SOCCA (Service-oriented Cloud Computing Architecture) 36

37 Arquitecturas Cloud SCA: Service Component Architecture SCA es un modelo de programación para abstraer funciones de negocio como si fueran componentes y utilizarlos para ensamblar soluciones de negocio. Los componentes SCA ofrecen servicios y como interactúan entre si. Una aplicación SCA se construye con uno o varios componentes. Los componentes SCA se pueden programar en diferentes lenguajes. SCA fomenta la práctica de SOA para crear aplicaciones Cloud. Plataforma Apache Tuscany (OASIS Open SCA) 37

38 Arquitecturas Cloud 38

39 Arquitecturas Cloud El Service Component Definition Language (SCDL) es un fichero XML que define una composición SCA, a modo de fichero de configuración para describir los componentes y como se interrelacionan <composite name="examplecomposite"...> <component name="component1">... </component> <component name="component2">... </component> <component name="component3">... </component> </composite> 39

40 Arquitecturas Cloud Cada componente implementa una lógica que se expone como uno o más servicios. Un servicio (cheurón verde) ofrece una serie de operaciones que son accesibles por el cliente. Un componente puede usar servicios de otros componentes (cheurón morado) que pertenecen a su dominio o a otro y se denominan referencias. Una referencia es una interfaz a operaciones que el componente necesita. Un componente puede definir una o varias propiedades (cuadrado amarillo) que contienen un valor que debe ser leído por el componente desde el fichero SCDL. Los servicios y las referencias comunican un componente SCA con otro software (binding). Componente SCA Componente SCA Aplicación no SCA 40

41 Arquitecturas Cloud <composite xmlns=" targetnamespace=" xmlns:hw=" name="helloworldws"> <component name="helloworldservicecomponent"> <implementation.java class="helloworld.helloworldimpl" /> <reference name="compo1service" target="componentone" /> <reference name="compo2service" target="componenttwo" /> <service name="helloworldservice"> <interface.wsdl interface=" /> <binding.ws uri=" </service> </component> <component name="componentone"> <implementation.java class="helloworld.compo1impl"/> </component> <component name="componenttwo"> <implementation.java class="helloworld.compo2impl"/> </component> </composite> 41

42 OSGi OSGi Alliance: Consorcio para la interoperabilidad de aplicaciones y servicios basados en una plataforma de integración de componentes. OSGi (Open Services Gateway initiative) proporciona: Especificaciones Implementaciones de referencia Suites para testing Certificación La adopción de plataformas basadas en componentes reduce el time-to-market y los costes de desarrollo ya que permite la integración de módulos pre-construidos y pre-testeados. 42

43 OSGi OSGi Framework El OSGi framework se divide en niveles L0. Entorno de ejecución: Especificación en Java 2. L1: Módulos: Define las políticas de carga de clases sobre Java. Añade modularización y facilita el despliegue de sistemas. Seguridad Java 2 L2: Ciclo de vida: Añade wrappers que pueden ser instalados dinámicamente y manejar módulos en runtime. L3: Registro de servicios: Esta capa añade un registro de servicios para proporcionar cooperación entre los wrappers en ejecución. 43

44 OSGi Servicios del OSGi Framework Servicios estándar: Definidos encima del Framework OSGi Alliance soporta diversos servicios que se ofrecen mediante interfaces Java. La interfaz se puede describir con los wrappers ( bundles ) y registrar con el Service Registry. Este concepto es similar a las arquitecturas SOA, pero la diferencia principal es que los servicios Web requieren una capa de transporte que suele ser más lenta que las invocaciones directas en OSGi. Servicios del framework: Proporcionan servicios para administración y permisos, gestión de paquetes, inicialización y soporte para URL. Servicios del sistema: Proporcionan funcionalidad horizontal necesaria en cualquier sistema, como son: Logs, configuración, gestión de dispositivos, gestión de usuarios, componentes en ejecución, despliegue, etc. 44

45 OSGi Servicios del OSGi Framework Servicios de protocolos: Define un número de servicios que mapean a protocolos externos al OSGi service, como son: HTTP, Universal plug and play (UPnP) y DMT admin (Device Management Tree) para especificar la gestión de dispositivos móviles y proporcionada por el Open Mobile Alliance (OMA). Servicios misceláneos: Wire admin service: Conecta diferentes servicios definidos en ficheros de conf. XML parser service: compatible con JAXP Initial provisioning Foreign application access 45

46 OSGi Arquitectura OSGi Bundles: Componentes implementados por desarrolladores Services: Conecta los bundles dinámicamente y ofrece un modelo publish-find-bind para plain old Java objects (POJO) Life-Cycle: API para instalar y actualizar bundles Modules: Define como un bundle importa y exporta código Security: Soporta los aspectos de seguridad Execution Environment: Define los métodos y clases disponibles para una plataforma específica. 46

47 OSGi Software para OSGi Apache Felix (Implementa la plataforma de servicios OSGi R44) Eclipse Equinox: Knopflerfish OSGi (Plataforma OSS): AQute Snippets (Snippets: ejemplos de codigo OSGi): 47

48 Referencias Web Services Architecture NexOF-RA Cloud