Diseño de aplicaciones telemáticas
Middleware
Introducción
Middleware
●
Algún ejemplo de las responsabilidades del middleware:
–
La API de sockets BSD no maneja la problemática asociada a la
representación de datos transmitidos por la red:
●
Big Endian/Little Endian de las máquinas
●
El tamaño de la palabra de la arquitectura (32 o 64 bit)
●
La forma de estructuras de datos complejas, con diferencias en
padding y alineamiento según la máquina
–
Falta de gestión de mensajes de control que permitieran por ejemplo
mandar cierta tarea a una rutina en el equipo remoto
–
Necesario proceso de serialización
●
Empaquetar los datos en forma adecuada para su transmisión por la red
●
Marshaling: equivalente a serialización aplicada a objetos con estado
Middleware
●
Middleware es cualquier capa que se encuentra entre sistema
operativo y aplicaciones:
–
–
–
Abstrae conceptos como el paso de mensajes a bajo nivel entre las redes de
ordenadores
●
Implementa serialización y marshaling de objetos
●
Reintentos, colas de peticiones, transaccionalidad y serialización de operaciones
●
Paneles de control, gestión de errores, garantías de ejecución
Oculta “detalles” de implementación
●
Por ejemplo el problema de la heterogeneidad de redes y máquinas
●
Abstracción del entorno de ejecución: arquitectura, endianness
Favorece la reutilización (modelo de facilities)
●
Por ejemplo, FTP y HTTP transfieren ficheros
–
¿Porqué no reutilizar esa parte?
Middleware
●
En todas las capas
1-N Máquinas
Middleware
Aplicación
Aplicación
Aplicación
Middleware
Middleware
socket
Sistema operativo y hardware
Middleware
Middleware
●
Facilidades típicas de un middleware:
–
Servicio de nombres: identificación de servicios
–
Ejecución remota
–
Acceso a datos distribuidos
–
Persistencia de datos
–
Transacciones: múltiples operación de manera atómica
–
Seguridad: encriptación y autenticación
Middleware
●
Desventajas
–
Pérdida de la eficiencia en la transmisión de datos
●
●
–
Mayor carga de señalización (cabeceras de protocolos y paquetes
de control)
Transferencias masivas de datos se deben implementar
directamente sobre el API de sockets BSD (HTTP, FTP, etc.) en
lugar de usar middleware si se quieren hacer de forma eficiente
Pérdida de control
●
Sobre los paquetes transmitidos por la red y la información
intercambiada
Middleware
●
En todas las capas
Modelos de Middleware
Modelos de Middleware
●
Tipos:
–
Llamada a procedimientos remotos (RPC)
–
Objetos distribuidos (ROI, CORBA, RMI)
–
Comunicación orientada a mensajes (MOC)
–
Comunicación orientada a streams (streaming, logs de
eventos)
Remote Procedure Call (RPC)
Remote Procedure Call (RPC)
●
Está formado por dos partes asimétricas
–
Permite llamar a procedimientos (líneas de código)
localizados y ejecutados en otra máquina
–
La máquina A llama a un procedimiento en la máquina B
●
El proceso llamante en A es suspendido.
●
Tiene lugar la ejecución del procedimiento en B.
●
Los resultados retornan a A.
Remote Procedure Call (RPC)
●
Paso de parámetros
–
–
Mismo convenio de formatos y representación de datos:
●
Independiente de la máquina
●
Unificación Big Endian y Little Endian.
Punteros o parámetros por referencia:
●
●
Se pasa copia de la zona de memoria al servidor
Se copia el resultado de nuevo en la misma zona original del
cliente.
Remote Procedure Call (RPC)
●
¿Como se definen?
–
–
Los procedimientos (funciones, servicios) disponibles
●
Se especifican mediante Interface Definition Language (IDL)
●
Se utiliza en tiempo de compilación.
Existe la posibilidad de RPC asíncrono
●
En ellos se suele enviar la petición
●
se espera a la aprovación de la operación
●
Se sigue el procesado en el cilente
●
Tarde o temprano se recibe el resultado
Remote Procedure Call (RPC)
●
Implementaciones
–
DCE
●
OpenSource
●
Portado a multitud plataformas
●
●
–
Casi todo implementado a nivel de usuario menos el sistema de ficheros que
funciona a nivel de núcleo.
Funcionalidades:
–
Ejecución remota de procedimientos
–
Servicio de ficheros distribuidos
–
Servicios de directorio (Búsqueda de recursos)
–
Servicio de seguridad
–
Sincronización de relojes
SUN RPC
Remote Object/Method Invocation (ROI/RMI)
Remote Object/Method Invocation (ROI/RMI)
●
Aplicar la idea de los RPC a los objetos
–
Los objetos encapsulan:
●
Estado
●
Métodos
–
Los métodos se ofrecen a través de dicho interfaz.
–
El objeto esta en un lugar y los métodos en otro
●
El objeto podría tener el estado distribuido entre varias
máquinas.
Remote Object/Method Invocation (ROI/RMI)
●
Aplicar la idea de los RPC a los objetos
–
Hay un equivalente al STUB de los RPCs
●
–
Una interfaz permite la compilación y la definición de las
llamadas.
–
Proxy pogramado en el cliente (define los metodos pero no los implementa)
–
Skeleton programado en el servidor (Aqui se implementan los métodos)
Para el envío del estado hacia quien tiene implementado
el método se emplea marshalling o serialización
Remote Object/Method Invocation (ROI/RMI)
●
Aplicar la idea de los RPC a los objetos
–
–
La referencia a un objeto incluye:
●
IP servidor
●
Puerto del servidor
●
Identificador de objeto
Distintas estrategias en la creación de objetos:
●
Creación en tiempo de compilación
–
●
Creación en tiempo de ejecución
–
–
El lengaje de todo el sistema es el mismo
Permite objetos multilenguaje
Distinto tipo de objeto según su persistencia:
●
Persistentes: Se almacenan en almacenamientos secundarios
●
Transitorios: Solo existen mientras exista el servidor
Remote Object/Method Invocation (ROI/RMI)
●
OJO esto presenta inconvenientes:
–
Normalmente, el objetivo de todas las implementaciones es
ocultar la red al desarrollado, esto es, ocultar el problema de
la programación distribuida
●
●
●
Los procesos en remoto pueden fallar por problemas de conectividad,
a diferencia de la ejecución en local
Así que el problema sigue estando ahí
Hacer como si no tuviesemos ejecución distribuida no es una buena
solución:
–
–
HACER EXPLÍCITO LO IMPLICITO
Ejemplo fallido: CORBA
Web Services
Web Services
●
La web se ha llenado de aplicaciones.
●
La web está pensada para interacción con humanos.
●
●
Queremos hacer la web accesible a otros ordenadores y
aplicaciones.
–
Un nuevo middleware!
–
Acceso directo, no mediante la simulación de un cliente
Ventajas:
–
Protocolos conocidos (HTTP)
–
HTTP es el tráfico que se permite normalmente en las redes (a diferencia de
otros servicios en otros puertos)
–
Permite reutilizar infraestructura existente (servidor web)
Web Services
●
●
¿Qué es un servicio Web?
–
Identificada por un URI
–
Uso mediante mediante artefactos XML.
–
Preparado para ser automatizable.
–
El interfaz define una colección de operaciones que son
accesibles de forma remota usando mensajes XML mediante
protocolos estándar de Internet.
Consiste en una colección de operaciones que
pueden ser usadas por un cliente a través de Internet.
Web Services
●
Ejemplo de combinación de Web Services
–
Web de agencias de viajes hace uso de interfaces web
services que proveen los proveedores de servicio final
–
Agregadores de contenido
SOAP
SOAP
●
●
●
Es un protocolo basado en XML:
–
intercambio de información
–
forma descentralizada
–
entornos distribuidos.
Define un mecanismo:
–
para el paso de instrucciones (comandos)
–
parámetros entre clientes y servidores (RPCs).
Totalmente independiente:
–
de la plataforma
–
del modelo de datos
–
Del lenguaje de programación usado.
●
Se transporta normalmente sobre HTTP.
●
Utiliza:
–
SOAP con XML como payload.
–
HTTP como transporte.
SOAP
●
XML (eXtensible Markup Language)
–
XML define el formato textual para representar datos estructurados.
<etiqueta atributo=“valor”>contenido</etiqueta>
–
Forma sencilla de describir estructuras de datos complejas y
jerárquicas (serializaciones).
–
Separa la definición de estructuras de la presentación de las mismas.
–
Características:
●
Flexibilidad
●
Facilidad de procesado
●
Independencia de plataformas/arquitecturas
SOAP
●
XML Ejemplo:
<?xml version="1.0"?>
<catalogo>
<libro ISBN=“1-861003-11-0”>
<titulo>Professional XML</titulo>
<autor>Didier Martin et al.</autor>
<editorial>Wrox</editorial>
<anyo>2000</anyo>
</libro>
<libro ISBN=“0-07-212646-9”>
<titulo>XML Developer’s Guide</titulo>
<autor>Fabio Arciniegas</autor>
<editorial>McGraw-Hill</editorial>
<anyo>2001</anyo>
</libro>
</catalogo>
SOAP
●
●
WSDL (Web Services Description Language)
–
XML
–
descripción de servicios web
–
detalles de la conexión
WSDL definirá:
–
Operaciones que puede realizar
–
Dónde está
–
Cómo se invoca
SOAP
●
UDDI (Universal Description Discovery and Integration)
–
Estructura de Datos estándar
–
Basado en XML
–
Es un servicio Web
–
Soporta:
●
–
●
Gestión de taxonomía para ayudar las búsquedas
Búsquedas por personas y máquinas
Los usuarios buscan en este servicio:
–
Reciben un puntero al documento WDSL que caracteriza el servicio
SOAP
●
Componentes
SOAP
●
Componentes
Otros interfaces a servicios web
Otros interfaces a servicios web
●
XML-RPC
–
●
REST (REpresentational State Tranfer)
–
–
●
Mediante métodos POST HTTP peticiones y respuestas XML que imitan una
funcionalidad RPC sobre la web
Patrón de diseño
●
Peticiones mediante métodos GET/HTTP
●
Respuestas XML/JSON
●
Imitan una funcionalidad RPC sobre la web
Se codifica la petición en la URL
●
Simplifica la depuración
●
Válido para peticiones de tamaño pequeño
AJAX (Asynchronous JavaScript and XML)
Comunicación orientada a mensajes
(MOC)
Comunicación orientada a mensajes
(MOC)
●
En este sistema:
–
–
La comunicación se basa en tickets
●
En determinados entornos se pueden almacenar
●
Útil en sistemas con comunicación intermitente
Las comunicaciones puede ser:
●
Sincronas/Asincronas
–
●
El que envia el mensaje sigue procesando su programa despues del envío de este.
Persistente/Transitorio
–
Si es necesario que el servidor que realiza la tarea esté activo a la hora de enviar el mensaje.
●
Transitorios
●
Basados en recibo
●
Basados en envío
●
Basados en respuesta
Comunicación orientada a mensajes
(MOC)
●
Message Queue (MQs):
–
Message passing Interface (MPI)
●
Estandar para nodos corriendo aplicación paralelizada
–
Mare Nostrum
●
Libreria disponible en casi todos los lenguajes de programación.
●
No soporta:
●
–
caida de procesos
–
Caida de la red
La comunicación se realiza entre un grupo de procesos identificados por:
–
GroupID
–
ProcessID
Comunicación orientada a streams
(streaming)
Comunicación orientada a streams
●
Stream: información continua con requerimientos temporales y de ordenación en los datos
encapsulados.
–
●
Ejemplo: señal PCM voz 8bits 8KHz -> 64Kbps
Tipos de transmisión:
–
Síncrona: los datos se envían a la máxima tasa para que lleguen al destino antes de cuando sean requeridos.
●
–
Isosíncrona: los datos lleguen al destino a determinada tasa dentro de ciertos umbrales, de manera que el
buffer en recepción es menor.
●
●
Ej: voz sobre IP (paquetes de 200bytes cada 20ms).
Un stream puede ser complejo y estar compuesto por varios substreams.
–
●
Ej: predescarga de contenidos pregrabados.
Ej: pista video y audio.
La dependencia temporal exige recursos de calidad de servicio (QoS) en la red:
–
Tasa
–
Retardo
–
Jitter.
Sistemas de actores
Sistemas de actores
●
●
Actor: objetos que encapsulan estado y comportamiento y se comunican
exclusivamente usando una cola de mensajes, en un bucle:
–
Leer mensaje
–
Procesar mensaje: cambiar estado y/o enviar mensajes a otros actores
Por defecto no es un modelo de petición/respuesta
–
●
●
Se implementa y controla en la aplicación, si es necesario
Concurrencia: Como máximo un hilo puede ejecutar un actor al mismo tiempo
–
Modelo simple y muy eficiente, de petición/respuesta
–
Modelo generalmente asíncrono
–
Nativamente distribuido: Escalable pero más complejo
–
No hay muchas implementaciones y no todas al mismo nivel de madurez
Ejemplos: Erlang, Akka Actors