Middleware

Recientemente, por motivos de trabajo, estoy investigando diferentes tipos de middleware. Middleware es:

un software de conectividad que ofrece un conjunto de servicios que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas

– wikipedia

Esta definición se parece mucho a lo que nosotros necesitamos en el trabajo, ya que necesitamos soportar no pocos sistemas operativos y plataformas diferentes.

Como este tema lo estoy realizando en mis ratos libres, he decidido dejar constancia en mi página web. Quien sabe: tal vez a alguien le puede resultar útil.

División

Voy a categorizar los middleware en tres grupos. Seguramente no sea la mejor división del mundo, pero creo que es una diferencia importante: RPCs, Sistemas de colas de mensajes y Sistemas genéricos.

Los RPCs son llamadas a procedimientos remotos. No suelen estar orientados a objetos, sino a funcionalidades específicas. El programa que lanza un RPC recibirá una respuesta de forma similar a como se invoca una función local.

Los sistemas genéricos, como he decidido bautizarlos, permiten una comunicación directa punto a punto (p2p) o bien multipunto. El escenario típico es que un programa crea un mensaje y lo pone en la red, y después otro (o varios) reciben este mensaje. Aunque permiten implementar servicios de colas de mensajes, en principio tienen una arquitectura clientes-servidores (no cliente-servidor, ya que puede haber muchos clientes y muchos servidores, todos interrelacionados). Suelen estar orientados a objetos.

Los sistemas de colas de mensajes son parecidos a los sistemas genéricos pero, además, tienen un sistema de almacenamiento interno. Permiten comunicaciones asíncronas, en las que los "servidores" pueden estar caídos y atender las peticiones cuando se levantan. Suelen proporcionar una serie de beneficios a costa de aumentar la latencia de los mensajes. Manejan dos conceptos distintos, como son los Topics o Temas y las Queues o Colas. A menudo se suele dividir a los programas en dos grupos: productores y consumidores, aunque el escenário más típico suele ser un compuesto de productor/consumidor, pero se suelen dividir en productores si primero envían mensajes y en consumidores si lo primero que hacen es recibir un mensaje.

Tanto los sistemas genéricos como los sistemas de colas de mensajes requieren un Broker que permita comunicar los programas. El esquema general es el siguiente: Un programa se conecta a un broker y comienza a enviar o recibir mensajes. No importa dónde se encuentre el programa que va a consumir/producir los mensajes: tan sólo importa dónde está el broker.

El broker puede realizar muchas operaciones más, a parte de encargarse del enrutamiento: puede facilitar la conexión entre distintos brokers, permitir un sistema de nombrado similar a cómo actúa un DNS, dividir el mensaje en fragmentos más pequeños y manejables, volver a juntarlos, patrón evictor, …

En los tres tipos se observará una cabecera y una carga. La cabecera contiene metainformación del mensaje, a menudo dirigida al broker, con el fin de poder dirigir el mensaje al destinatario deseado.

Los “sistemas genéricos” suelen implementar un IDL que facilita la especificación del protocolo de comunicaciones que van a utilizar para enviar los datos de un mensaje. Estos IDL son mucho menos comunes en los sistemas orientados a mensajes.

RPCs

El mayor problema de los RPCs es que suelen estar muy ligados al lenguaje de programación. Así, los RPCs de python no van a poder comunicarse, a priori, con los RPCs de Java. Cada uno utiliza su propio protocolo de comunicaciones y no es fácil encontrar nodos de unión.

Sistemas genéricos

CORBA

Una de sus ventajas es que tiene a más de 300 empresas detrás, como IBM, SUN o Microsoft. Esto obliga a CORBA a varias cosas: a soportar absolutamente todo, a ser compatible con todo y a retrasar terriblemente sus especificaciones. A demás, requieren hacer tantas cosas que, en ocasiones, no es posible.

El broker se llama ORB (Object Request Broker). CORBA es tan grande que no hay ningún ORB que soporte todos los servicios que se especifican en el estándar CORBA.

CORBA se ha ganado la fama de ser demasiado pesado, aunque se ha demostrado la posibilidad de embeberlo en dispositivos bastante pequeños. Esta dualidad grande-pequeño se debe al número de servicios de su ORB: si quisiéramos utilizarlos todos, sería enorme, mientras que si los eliminamos todos nos queda algo mucho más ligero.

Su IDL se llama, precisamente, IDL y permite especificar de forma sencilla cómo se va a realizar la comunicación entre programas.

Es libre y gratuíto: cualquiera puede usarlo -con un ORB apropiado- o realizar su propia implementación.

ICE

Son las siglas de Internet Comunication Engine. Según sus propios autores, una de sus ventajas es que no tiene 300 empresas detrás, sino sólo una: ZeroC.

Es muy similar a CORBA en muchos aspectos, pero mejorado: muchísimo más ligero y completamente orientado al programador. Siguen una filosofía por la que prefieren hacerlo incompatible hacia atrás antes que complicarle la vida al programador.

Su IDL se llama slice.

Ofrece servicios como persistencia (freeze), evictors, firewall (glaciar), mensajes multipunto (storm), nombrado, …

Soporta numerosos lenguajes: C++, Java, .Net, Python, …

Es libre para los que quieran realizar aplicaciones libres, pero no para los que quieran aplicaciones privativas.

Web Services

Es un término bastante confuso y que da lugar a bastantes malentendidos. No es un protocolo, sino un conjunto de protocolos y estándares de comunicación entre aplicaciones.

Teóricamente son multiplataforma y multilenguaje, pero resultan muy pesados ya que requieren el uso de XML. Este uso de XML le confiere unas características de versatilidad intrínsecas que otros no tienen.

Su IDL se denomina WSDL.

Sistemas de colas de mensajes

Dadas las características de lo que buscamos, me he centrado en éstos, por lo que veréis que son los que están más desarrollados. Sin embargo, el objetivo de este artículo es dar una visión general de los middlewares y pretendo englobar la mayor cantidad de middleware posible.

ActiveMQ

Implementado por Apache, basado en Java pero con interfaces C++ (CMS) y .Net (NMS). También soporta lenguajes de script y C mediante la implementación del protocolo STOMP.

Soporta mensajes persistentes, temporales, enrutado, servidores de aplicaciones (jetty), consola de mantenimiento, …

Ofrece un servicio llamado “camel” que permite implementar los patrones de Enterprise Integration Patterns.

Licencia Apache.

Para más información, consultar la web de ActiveMQ.

Spring

Implementado por SpringSource, basado en Java.

Licencia Apache.

Para más información, consultar la web de [Spring]

Glashfish Message Queue

Acceso desde Java o C. Muy completa, soporta muchos sistemas operativos.

Guarda los datos en una base de datos, soportando Oracle, mysql y alguna más.

Tiene puente JMS y STOMP.

Licencia: Totalmente privativa. Su uso implica contratar a SUN.

Para más información, consultar la web de Glashfish

OpenMQ

Proyecto libre similar a Glashfish MQ.

Puente JMS y STOMP, broker embebido, acceso desde C.

Licencia: dual, CDDL y GPLv2 con la excepción ClassPath.

Para más información, consultar la web de OpenMQ.

Glosario

• Broker: Canal lógico de comunicaciones. Se encarga de la transmisión de los mensajes, aunque puede tener muchas funcionalidades -o servicios- más.
• Cola de mensajes: Ver Queue.
• Evictor: Es un patrón mediante el cual los servidores pueden dormirse cuando no se utilizan, levantándose automáticamente cuando alguien les solicita una operación. Esta característica otorga mayor sencillez al programador y mejora la utilización de los recursos.
• IDL: Interface Definition Language, es un lenguaje que permite definir la interfaz entre un cliente y un servidor.
• Marshall: Ver Serialización.
• Multipunto: Un programa envía un dato y varios lo reciben.
• P2p: Ver Punto a punto.
• Punto a punto: Una comunicación de un programa a otro de manera que lo que se envía se obtiene en el otro lado.
• Queue: Cola de un mensaje. Los mensajes siguen un patrón uno a uno, de manera que alguien los produce y sólo uno los consume. Sólo habrá una instancia del mensaje en toda la comunicación. Es similar al correo habitual.
• RPC: Remote Procedure Call o llamada a procedimiento remoto, permite realizar una operación remota de forma similar a una operación local.
• Serialización: Tomar un grupo de objetos o variables y convertirlas en un vector de bytes con significado, de manera que, en el otro lado de las comunicaciones, alguien pueda deserializarlo otorgándole un contexto.
• Tema: Ver Topic.
• Topic: Cola de mensajes en la que éstos siguen un patrón uno a muchos mediante la replicación del mensaje. Se creará un mensaje por cada subscriptor al Topic. Es similar a la subscripción a una revista, donde el broker haría de imprenta.

Fin

Este artículo no está cerrado. Espero poder completarlo a medida que vaya adquiriendo más conocimientos y sacando más tiempo para ir redactándolo.