Ingeniería de Sistemas - EPE
Sistemas Distribuidos
Servicios (Principios)
Parte 3
Ing. Javier Lacherre
Ing. Joel Moreno
¿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
Agenda
OBJETIVO
Service Stateless
Service Composability
Conclusiones
UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos
5
04/10/2015
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
Principios
Diseñar
Diseño con
características
particulares
Agenda
Objetivo
Service Stateless
Service Composability
Conclusiones
UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos
8
04/10/2015
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 ”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
UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos
11
04/10/2015
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
1.
2.
Incrementar la escalabilidad de los
servicios.
Soportar el diseño de lógica de servicios
agnóstica y permitir mayor reusabilidad.
Perfil del principio: Servicios sin estado
Caracterí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 estado
Requerimientos
de
Implementación
1.
2.
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
Tipos de Estado
UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos
15
04/10/2015
Tipos de Estado
1.
2.
3.
Active and Passive
Stateless and Stateful
Session and Context Data
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.
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.
UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos
18
04/10/2015
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
19
04/10/2015
Impacto de statelessness en el diseño de los
servicios
Instancias
de
Servicios
Statelessness
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 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
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.
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.
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.
Agenda
Objetivo
Service Stateless
Service Composability
CONCLUSIONES
UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos
28
04/10/2015
Es una composición?
Consumidor
(Instancia)
(Instancia)
Consumidor
Controlador
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
1.
Servicios altamente reusables.
Perfil del principio: Servicios sin estado
Características
de Diseño.
1.
Participantes en la Composición
1.
2.
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
Perfil del principio: Servicios sin estado
Características
de Diseño.
1.
Controladora de la Composición
1.
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 estado
Requerimientos 1.
de
Implementación
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
Granularidad
Composibility
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
Agenda
Objetivo
Service Stateless
Service Composability
Conclusiones
UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos
43
04/10/2015
Descargar

Fundamentos de RUP