Sistemas Distribuidos

Presentación del tema: "Sistemas Distribuidos"— Transcripción de la presentación:

1 Sistemas Distribuidos
Servicios (Principios) Parte 3

2 ¿Qué debo saber hasta la clase de hoy?
Qué es SOA, Servicio, Inventario de Servicios, Objetivos, Beneficios, Escenarios de Adopción de SOA Qué es Servicios Web, WSDL, SOAP, UDDI, crear un servicio web simple a partir de una clase java en JDeveloper, probar un servicio web y crear una aplicación cliente para un servicio Web

3 ¿Qué debo saber hasta la clase de hoy?
Explicar los principios (nombre, metas, impacto de la aplicación del principio y requerimientos de implementación): estandarización de los contratos del servicio, bajo acoplamiento entre los principios, reusabilidad de los servicios y abstracción. Reconocer en un caso de estudio qué principios se han aplicado y por qué.

4 ¿Qué debo saber hasta la clase de hoy?
Explicar qué es BPEL y el rol que juega esta tecnología en una Arquitectura Orientada a Servicios. Explicar las diferencias entre una llamada síncrona y una asíncrona Construir un servicio compuesto básico con BPEL

5 Agenda UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos
OBJETIVO Service Stateless Service Composability Conclusiones UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 14/04/2017

6 Objetivos Explicar los principios (nombre, metas, impacto de la aplicación del principio y requerimientos de implementación): Service Stateless y Service Composability. Reconocer en un caso de estudio qué principios se han aplicado y por qué.

7 ¿Principio de Diseño? Regla, ley, suposición aplicada al diseño
Diseñar Diseño con características particulares Principios

8 Agenda UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos
Objetivo Service Stateless Service Composability Conclusiones UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 14/04/2017

9 Estado de un programa Estado se refiere a una condición general de algo. Un programa de software tiene y pasa por diferentes estados. Cada estado es representado y descrito por los datos. Un programa cambia de estado cuando termina de realizar tarea Estado: Estacionado Estado: Movimiento En POO: Estado de un objeto: los valores de los atributos de un objeto que cambian durante el ciclo de vida de un objeto Valores de los atributos de sus objetos, tablas, archivos xml, ini, etc. Un estado cambia cuando uno actúa con el programa En servicio: Se cambia de estado cuando se le invoca Porque Stateless En términos de Rendimiento: En un servicio escalado en varios servidores SOA, para ello sería necesario que se REPLIQUE su estado en todos, por si se cae uno, se perdería el ESTADO, por lo que afecta el Rendimiento y la Escalabilidad No se puede tener un servicio sin Estado, pero debe tener poco estado o debe ser simple

10 Stateless vs Stateful A servicio se considera “stateless” si trata cada operación como una transacción independiente sin importar las solicitudes previas. Si para utilizar un servicio es necesario invocar las operaciones en un orden determinado entonces el servicio se considera “stateful”. En este caso el servicio necesita conservar su estado entre las invocaciones para responder adecuadamente al consumidor.

11 Los servicios deberían ser…..
Los servicios deberían ser ”stateless” Los servicios deberían ser independientes del contexto o estado de otros servicios Un consumidor de servicios requiere conservar su estado entre las invocaciones a los servicios pero los servicios deben permanecer “stateless” UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 14/04/2017

12 Perfil del principio: Servicios sin estado
Definición corta Los servicios minimizan el manejo de estados Definición larga Los servicios reducen el consumo de recursos usando la administración de estados solo cuando es realmente necesario. Metas Incrementar la escalabilidad de los servicios. Soportar el diseño de lógica de servicios agnóstica y permitir mayor reusabilidad. Statefulness. Posibilidad que ofrece un servicio de cómo informar de cómo está su situación interior, su estado. Stateless. Aplicación de la que se desconoce su estado (situación de la aplicación en un momento dado).

13 Perfil del principio: Servicios sin estado
Características de Diseño. Ejemplos Mientras más agnóstica (reusable) es la lógica de un servicio entonces tiende a conservar menos su estado Aumento de la cantidad de rutinas de programación dedicadas a manejar estados

14 Perfil del principio: Servicios sin estado
Requerimientos de Implementación El ambiente de ejecución debe permitir la transición de un estado en stand by (idle) a un estado activo de modo eficiente. Se requieren analizadores XML de alto rendimiento

15 Tipos de Estado UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 14/04/2017

16 Tipos de Estado Active and Passive Stateless and Stateful
Session and Context Data

17 1. Active and Passive Un programa de software puede pasar por varios estados durante su ciclo de vida. Un servicio puede tener dos estados primarios: Active Passive Active. Representa cuando un servicio es invocado o ejecutado. Passive. Representa el periodo en el cual el servicio no está en uso. Esto sucede porque se crea la lógica de acuerdo al contrato previamente definido.

18 2. Stateless and Stateful
Cuando el estado de un servicio es activo, existen estados adicionales que representan diversas condiciones. Existen dos condiciones primarias: Stateless Stateful. Stateless. Un servicio puede estar activo pero no necesita mantener el estado de la data. (Ej. Protocolo HTTP) Stateful. Un servicio puede estar activo y retiene el estado de la data. When automating a particular task, the service is required to process data specific to that task. We can refer to this information as state data. UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 14/04/2017

19 3. Tipos de estados de datos cuando es stateful
Session Data. Representa la información asociada con la conexión entre un consumidor y el servicio cliente durante una intercambio de mensajes . (Ej. Identificador único de sesión entre un browser y su servidor web) Ejemplo: la conversación que se establece instancias de un proceso en BPEL con sus servicios Context Data. Se refiere al estado de la información que pasa entre los servicios dentro de una composición de servicios. Business Data. Representa la información que es relevante para un business task que se está ejecutando. Ejemplo: los datos persistentes recuperados de un repositorio como una base de datos. Proceso BPEL: para la conexiones asincrónicas, tiene un correlation id. Ese es un estado Contexto: Estado dentro del proceso BPEL, variables se deben tener en lo minimo posible Business data: lo registrado en la BD UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 19 14/04/2017 19

20 Impacto de statelessness en el diseño de los servicios
Instancias de Servicios Granularidad Statelessness Modelo

21 Instancia de Servicios
A pesar de querer servicios sin estados (stateless), siempre se debe tener algun servicio que maneje estados (stateful) y a veces por periodos prolongados. Esto ocasiona que múltiples instancias del mismo servicio se ejecuten concurrentemente y sea necesario poder identificarlas. La especificación WS-Addressing permite identificar instancias de servicios.

22 Instancia de Servicios

23 Granularidad Cuando se necesita manejar estados se ve afectada inevitablemente la granularidad de los servicios.

24 Modelos de Servicios ENTITY SERVICES
Como participan en la automatización de procesos de negocio o pueden ser miembros de composiciones es necesario estandarizar la administración de estados entre todas sus capacidades

25 Modelos de Servicios UTILITY SERVICES
Estos servicios a veces son intencionalmente diseñados para violar este principio. Por ejemplo, la creación de utility services que son responsables por el manejo de estados en nombre de otros servicios. Son normalmente stateful por la infraestructura.

26 Modelos de Servicios TASK SERVICES
Son generalmente composiciones con un grado significativo de composición, por lo que deben manejar data de contexto para poder alternar entre los servicios.

27 Modelos de Servicios ORCHESTRATED TASK SERVICES
Son siempre de tipo stateful. La naturaleza de la tecnología de orquestación es administrar una actividad durante todo su ciclo de vida. Si la duración de la inactividad del proceso excede el máximo permitido, entonces el estado de la data es almacenado en una base de datos para que luego sea reactivado.

28 Agenda UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos
Objetivo Service Stateless Service Composability CONCLUSIONES UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 14/04/2017

29 Es una composición? Controlador (Instancia) (Instancia) Consumidor
Ningun servicio contiene a otro, uno invoca a otros Hay servicios miembro y hay controladoras de la composiciòn Un servicio tiene capacidades que participan como miembros de la composicion y otras que controlan otros servicio Actividad del Servicio: Es la secuencia de invocaciones y respuesta que un servicios hace con otros

30 Perfil del principio: Service Composability
Definición corta Los servicios tiene la capacidad de participar en composiciones (composable) Definición larga Los servicios han sido diseñados para participar de forma efectiva en las composiciones, sin importar las dimensiones y la complejidad de la composición . Metas Servicios altamente reusables. Statefulness. Posibilidad que ofrece un servicio de cómo informar de cómo está su situación interior, su estado. Stateless. Aplicación de la que se desconoce su estado (situación de la aplicación en un momento dado).

31 Perfil del principio: Servicios sin estado
Características de Diseño. Participantes en la Composición Los servicios necesitan un entorno de ejecución eficiente Los contratos de los servicios necesitan ser flexibles de forma tal que permitan intercambiar diferentes tipos de datos para similar funciones

32 Perfil del principio: Servicios sin estado
Características de Diseño. Controladora de la Composición La lógica encapsulada por un controlador debe estar limitada a una única tarea del negocio Las controladoras pueden ser reusables pero que sea reusable no es una prioridad

33 Perfil del principio: Servicios sin estado
Requerimientos de Implementación Se requiere un entorno de ejecución tan escalable y fiable como sea posible

34 Términos importantes Miembros de la composición
Controlador de la composición Subcontrolador de la composición Actividad de servicio Iniciador de la composición Instancia de composición de servicios Capacidades de miembro de una composición Capacidades de controlador de composición Las task son las controladoras por excelencia

35 Revisemos un caso….

36 Revisemos un caso….

37 Tipos de Composición Simple: usualmente conformada por un iniciador, uno o dos intermediarios y un “ultimate service” Complejas: orquestaciones de servicios con BPEL

38 Impacto en el diseño de los servicios
Granularidad Composibility Modelo

39 Granularidad Granularidad del Servicio - mientras más servicios granulares (muy específicos) hay en un inventario de servicios entonces más servicios necesitan ser invocados en una composición promedio Granularidad de la Capacidad - Si un servicio esta formado por capacidades con alta granularidad (más específicas) entonces probablemente más capacidades estarán involucradas en una composición

40 Impacto en el Modelo Los tasks son los candidatos para ser composiciones El candidato ideal para una composición es un servicio de tipo task service aunque no de forma exclusiva

41 Un servicio de tipo entidad puede controlar a otras entidades
Impacto en el Modelo Un servicio de tipo entidad puede controlar a otras entidades

42 Riesgos asociados a la aplicación de este principio
Los miembros de la composición se constituyen en único punto de falla Los miembros de la composición se constituyen en un cuello de botella Mayor complejidad en el Gobierno

43 Agenda UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 43
Objetivo Service Stateless Service Composability Conclusiones UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 43 14/04/2017 43