ingeniería de sistemas - epe ing. javier lacherre ing. joel moreno sistemas distribuidos servicios...

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


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é.


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


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”


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


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.


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.


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


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.


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.


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


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.


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


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….

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


ingeniería de sistemas - epe ing. javier lacherre ing. joel moreno sistemas distribuidos servicios...

Documents