ingeniería de sistemas - epe ing. javier lacherre ing. joel moreno sistemas distribuidos servicios...
TRANSCRIPT
Ingeniería de Sistemas - EPEIngeniería de Sistemas - EPE
Ing. Javier Lacherre
Ing. Joel Moreno
Sistemas DistribuidosSistemas DistribuidosServicios (Principios)
Parte 3
¿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
¿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é.
¿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
AgendaAgenda
UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 21/04/235
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é.
¿Principio de Diseño?
Regla, ley, suposición aplicada al diseño
DiseñarPrincipiosDiseño con características particulares
AgendaAgenda
UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 21/04/238
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
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.
Los servicios deberían ser…..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 21/04/2311
http://thomasrischbeck.blogspot.com/2009/05/stateful-vs-stateless-services.html
Perfil del principio: Servicios sin estadoDefinició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 1. Incrementar la escalabilidad de los servicios.
2. Soportar el diseño de lógica de servicios agnóstica y permitir mayor reusabilidad.
Perfil del principio: Servicios sin estadoCaracterísticas de Diseño.
Ejemplos
1. Mientras más agnóstica (reusable) es la lógica de un servicio entonces tiende a conservar menos su estado
2. Aumento de la cantidad de rutinas de programación dedicadas a manejar estados
Perfil del principio: Servicios sin estadoRequerimientos de Implementación
1. El ambiente de ejecución debe permitir la transición de un estado en stand by (idle) a un estado activo de modo eficiente.
2. Se requieren analizadores XML de alto rendimiento
Tipos de Estado
UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 21/04/2315
Tipos de Estado
1. Active and Passive
2. Stateless and Stateful
3. Session and Context Data
1. Active and PassiveActive and Passive
Un programa de software puede pasar por varios estados durante su ciclo de vida.Un servicio puede tener dos estados primarios:
ActivePassive
Active. Representa cuando un servicio es invocado o ejecutado.Passive. Representa el periodo en el cual el servicio no está en uso.
2. Stateless and Stateful2. 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.
UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 21/04/2318
3. 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.
UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 21/04/2319
Impacto de statelessness en el diseño de los servicios
Statelessness
Instancias de
Servicios
Granularidad
Modelo
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.
Instancia de Servicios
Granularidad
Cuando se necesita manejar estados se ve afectada inevitablemente la granularidad de los servicios.
Modelos de Servicios
ENTITY SERVICESComo 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
Modelos de Servicios
UTILITY SERVICESEstos 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.
Modelos de Servicios
TASK SERVICESSon generalmente composiciones con un grado significativo de composición, por lo que deben manejar data de contexto para poder alternar entre los servicios.
Modelos de Servicios
ORCHESTRATED TASK SERVICESSon 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.
AgendaAgenda
UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 21/04/2328
Es una composición?
ControladorConsumidor
Consumidor
(Instancia)
(Instancia)
Perfil del principio: Service ComposabilityDefinició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 1. Servicios altamente reusables.
Perfil del principio: Servicios sin estadoCaracterísticas de Diseño.
1. Participantes en la Composición1. Los servicios necesitan un entorno de
ejecución eficiente
2. Los contratos de los servicios necesitan ser flexibles de forma tal que permitan intercambiar diferentes tipos de datos para similar funciones
Perfil del principio: Servicios sin estadoCaracterísticas de Diseño.
1. Controladora de la Composición1. La lógica encapsulada por un controlador
debe estar limitada a una única tarea del negocio
2. Las controladoras pueden ser reusables pero que sea reusable no es una prioridad
Perfil del principio: Servicios sin estadoRequerimientos de Implementación
1. Se requiere un entorno de ejecución tan escalable y fiable como sea posible
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
Revisemos un caso….
Revisemos un caso….
Tipos de Composición
Simple: usualmente conformada por un iniciador, uno o dos intermediarios y un “ultimate service”
Complejas: orquestaciones de servicios con BPEL
Impacto en el diseño de los servicios
Composibility
Granularidad
Modelo
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
Impacto en el Modelo
El candidato ideal para una composición es un servicio de tipo task service aunque no de forma exclusiva
Impacto en el Modelo
Un servicio de tipo entidad puede controlar a otras entidades
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
AgendaAgenda
UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 21/04/2343