1

Sistemas Distribuidos - Middleware

Luis ngel Benavides Mora
Universidad Autnoma del Caribe
luisbenavides25@outlook.com

Resumen En este documento se va a desplegar la

informacin sobre los sistemas distribuidos de tipo Middleware y
sus diferentes componentes tales como los sockets, RMI, Web
Service, RCP, entre otros. Tambin veremos cmo ha avanzado
en la actualidad desde su comienzo y los avances ms
importantes que este tiene.
Palabras Claves Web, Cliente, Servidor, RPC, Java, RMI,
HTTP, XML, Sockets.

I.

INTRODUCCIN

Los sistemas distribuidos de tiempo real son cada vez ms

importantes para la sociedad. Su demanda aumenta y se
depende de los servicios que proporcionan. Los sistemas de
alta integridad constituyen un subconjunto de gran
importancia. Se caracterizan por que un fallo en su
funcionamiento puede causar la prdidas de vidas humanas,
daos en el medio ambiente o cuantiosas prdidas econmicas.
La necesidad de satisfacer requisitos temporales estrictos, hace
ms complejo su desarrollo. Mientras que los sistemas
empotrados se expandan en nuestra sociedad, es necesario
garantizar un coste de desarrollo ajustado mediante el uso
tcnicas adecuadas en su diseo, mantenimiento y
certificacin. En concreto, se requiere una tecnologa flexible
e independiente del hardware.
Middleware o lgica de intercambio de informacin entre
aplicaciones ("interlogical") es un software que asiste a una
aplicacin para interactuar o comunicarse con otras
aplicaciones, o paquetes de programas, redes, hardware y/o
sistemas operativos. ste simplifica el trabajo de los
programadores en la compleja tarea de generar las conexiones
y sincronizaciones que son necesarias en los sistemas
distribuidos. De esta forma, se provee una solucin que
mejora la calidad de servicio, as como la seguridad, el envo
de mensajes, la actualizacin del directorio de servicio, etc.
De todas maneras el trmino ha sido usado desde 1968.
Tambin facilitaba el procesamiento distribuido: conexin de
mltiples aplicaciones para crear una aplicacin ms grande,
generalmente sobre una red.

II. MIDDLEWARE
El origen de la palabra middleware se remonta al ao 1968,
en donde la palabra fue usada durante la '1968 NATO
Software Engineering Conference',2 siendo una idea de cmo
conectar el nuevo software con sistemas ms antiguos.
Durante las dcadas previas a los 90s, fue solamente descrito
como un software para la gestin de conexin en redes, pero
para cuando las tecnologas en redes alcanzaron una
penetracin y visibilidad suficiente, el software middleware'
haba evolucionado en un conjunto de paradigmas y servicios.
De esta forma se estaba ofreciendo una manera ms fcil,
robusta y controlable, para construir aplicaciones distribuidas.
El tipo de integracin que incluyen posee la capacidad de
unirse con sistemas heterogneos. Cada middleware posee
diferentes protocolos de comunicacin o formas de operar en
diferente software. Los tipos de integracin se pueden ver
como:

Orientados a procedimiento o procesos: Los

middleware que son orientados a procesos, utilizan una
comunicacin sincronizada (como por ejemplo el
telfono). Una de las caractersticas de estos, es que
utilizan el client stub y el server skeleton.

Orientados a objetos: Soportan pedidos de objetos

distribuidos. La comunicacin entre los objetos puede ser
sincronizada, sincronizada diferida o no sincronizada.
Soportan mltiples pedidos similares realizados por
mltiples clientes en una transaccin. La forma de operar
es:
1.
2.
3.
4.
5.

El objeto cliente llama a un mtodo lgico para obtener un

objeto remoto.
Un ORB Proxy (tambin conocido como stub) pone en
orden la informacin y la transmite a travs del agente
(broker).
El agente acta como punto medio y contacta con diversas
fuentes de informacin, obtiene sus referentes IDs,
recolecta informacin y, en ocasiones, la reorganiza.
El proxy remoto (tambin conocido como skeleton)
desordena la informacin que le llega del agente y se la
pasa al objeto servidor.
El objeto servidor procesa la informacin y genera un
resultado que es devuelto al cliente siguiendo los pasos
inversos.

Orientados a mensajes (MOM, Message-oriented

middleware): Se pueden dividir en dos tipos, espera y
publicacin/suscripcin. El paso de espera se puede
dividir en mensaje y espera. El paso de mensaje inicia con
que la aplicacin enva un mensaje a uno o ms clientes,
con el MOM del cliente. El servidor MOM, recoge las
peticiones de la cola (Message Broker) en un orden o
sistema de espera predeterminado. Los actos del servidor
MOM son como un router y usualmente no interactan
con estas.

Cuando se implementan con el protocolo TCP, los sockets

tienen las siguientes propiedades:
Son orientados a la conexin.
Se garantiza la transmisin de todos los octetos sin
errores ni omisiones.
Se garantiza que todo octeto llegar a su destino en el
mismo orden en que se ha transmitido.

Orientados a componentes: En este caso, un

componente es un programa que realiza una funcin
especfica, diseada para operar e interactuar fcilmente
con otros componentes y aplicaciones. El middleware en
este caso en una configuracin de componentes. Los
puntos fuertes de este middleware es que es configurable
y reconfigurable. La reconfiguracin se puede realizar en
tiempo de ejecucin, lo que ofrece una gran flexibilidad
para satisfacer las necesidades de un gran nmero de
aplicaciones.

El protocolo UDP es un protocolo no orientado a la

conexin. Slo se garantiza que si un mensaje llega, llegue
bien. En ningn caso se garantiza que llegue o que lleguen
todos los mensajes en el mismo orden que se mandaron. Esto
lo hace adecuado para el envo de mensajes frecuentes pero no
demasiado importantes, como por ejemplo, un streaming de
audio.

Agentes: Los agentes son un tipo de middleware que

posee varios componentes:
1. Entidades: Pueden ser objetos o procesos.
2. Medios de comunicacin: Pueden ser canales,
tuberas, etc.
3. Leyes: Identifican la naturaleza interactiva de los
agentes. Pueden ser la sincronizacin o el tipo de
esquema.
Las ventajas de los middleware agentes son que la
capacidad de stos para realizar una gran cantidad de
tareas en nombre del usuario y para cubrir una amplia
gama de estrategias basadas en el entorno que les rodea.
Sin embargo su implementacin es complicada debido a
la complejidad y dificultades dadas por las operaciones
que manejan.
III. SOCKETS

Un socket, es un mtodo para la comunicacin entre un

programa del cliente y un programa del servidor en una red.
Un socket se define como el punto final en una conexin. Los
sockets se crean y se utilizan con un sistema de peticiones o de
llamadas de funcin a veces llamados interfaz de
programacin de aplicacin de sockets (API, application
programming interface).
Un socket es tambin una direccin de Internet,
combinando una direccin IP (la direccin numrica nica de
cuatro partes que identifica a un ordenador particular en
Internet) y un nmero de puerto (el nmero que identifica una
aplicacin de Internet particular, como FTP, Gopher, o
WWW).
Las propiedades de un socket dependen de las
caractersticas del protocolo en el que se implementan. El
protocolo ms utilizado es Transmission Control Protocol; una
alternativa comn a ste es User Datagram Protocol.

Estas propiedades son muy importantes para garantizar la

correccin de los programas que tratan la informacin.

En los orgenes de Internet, las primeras computadoras en

implementar sus protocolos fueron aquellas de la Universidad
de Berkeley. Dicha implementacin tuvo lugar en una variante
del sistema operativo Unix conocida como BSD Unix. Pronto
se hizo evidente que los programadores necesitaran un medio
sencillo y eficaz para escribir programas capaces de
intercomunicarse entre s.
Esta necesidad dio origen a la primera especificacin e
implementacin de sockets, tambin en Unix. Hoy da, los
sockets estn implementados como bibliotecas de
programacin para multitud de sistemas operativos,
simplificando la tarea de los programadores.
La interfaz socket se diferencia por los servicios distintos
que proporciona. Flujo, datagrama, y raw sockets cada uno de
ellos define un servicio distinto disponible para aplicaciones.

Interfaz socket de flujo (SOCK_STREAM): Define un

servicio orientado a conexin confiable (sobre TCP por
ejemplo). Los datos se envan sin errores o duplicacin y
se reciben en el mismo orden de cmo fueron enviados.
El control de flujo est integrado para evitar overruns.

Interfaz socket de datagrama (SOCK_DGRAM):

Define un servicio no orientado a conexin (sobre UDP
por ejemplo). Los datagramas se envan como paquetes
independientes. El servicio no proporciona garantas; los
datos se pueden perder o duplicar y los datagramas
pueden llegar fuera de orden.

Interfaz socket raw (SOCK_RAW): Permite acceso

directo a protocolos de capas ms bajas tales como IP e
ICMP. Esta interfaz se utiliza a menudo para comprobar
nuevas implementaciones de protocolos. Ejemplo de
aplicacin que use sockets raw es la orden ping.

3
IV. RMI.

RMI es el modelo de objetos distribuidos de Java que

permite invocar un mtodo de un objeto que ests obre otra
mquina virtual. Su principal propsito es permitir el
desarrollo de aplicaciones distribuidas con el mismo modelo
de programacin que en sistemas centralizados. RMI es una
infraestructura poderosa para la construccin de aplicaciones
distribuidas cliente - servidor. RMI emplea TCP / IP y
serializacin de objetos para serializar y deserializar los
argumentos y valor de retorno de los mtodos remotos.
Tambin utiliza los protocolos http y ftp para el intercambio
de clases.
El servidor crea un conjunto de objetos remotos, los hace
accesibles, y espera por los clientes. Normalmente, el cliente
recibe una o ms referencias remotas a los objetos en el
servidor mediante un registro que almacena par de referencia
remota - objeto remoto. Con las referencias el cliente llama a
los mtodos que se encuentran en el servidor. El cliente, el
servidor y el registro forman la aplicacin de objetos
distribuidos, y RMI es el middleware que proporciona
servicios para el desarrollo de aplicaciones de objetos
distribuidos.
RMI es adecuado para sistemas distribuidos de tiempo real
crtico dado que provee la funcionalidad requerida y puede ser
analizable. Java RMI presenta algunas limitaciones en
sistemas de tiempo real:

RMI no garantiza una calidad de servicio.

V. WEB SERVICE.

Un servicio web (en ingls, Web Service o Web services) es

una tecnologa que utiliza un conjunto de protocolos y
estndares que sirven para intercambiar datos entre
aplicaciones. Distintas aplicaciones de software desarrolladas
en lenguajes de programacin diferentes, y ejecutadas sobre
cualquier plataforma, pueden utilizar los servicios web para
intercambiar datos en redes de ordenadores como Internet. La
interoperabilidad se consigue mediante la adopcin de
estndares abiertos.
Las organizaciones OASIS y W3C son los comits
responsables de la arquitectura y reglamentacin de los
servicios Web. Para mejorar la interoperabilidad entre distintas
implementaciones de servicios Web se ha creado el organismo
WS-I, encargado de desarrollar diversos perfiles para definir
de manera ms exhaustiva estos estndares. Es una mquina
que atiende las peticiones de los clientes web y les enva los
recursos solicitados.
Ventajas.
Aportan interoperabilidad entre aplicaciones de
software independientemente de sus propiedades o de
las plataformas sobre las que se instalen.

El uso de tecnologas tales como: reflexin,

caractersticas OO y recursividad hacen que sea muy
difcil estimar el WCET y el uso de recursos.

Los servicios Web fomentan los estndares y

protocolos basados en texto, que hacen ms fcil
acceder a su contenido y entender su funcionamiento.

El modelo de memoria no es apropiado. Las hebras, las

conexiones, los objetos remotos, etc. se crean dentro del
montculo. Por lo tanto, la ejecucin de las invocaciones
remotas sufren los efectos del recolector de basura y los
objetos se crean de forma dinmica.

Permiten que servicios y software de diferentes

compaas ubicadas en diferentes lugares geogrficos
puedan ser combinados fcilmente para proveer
servicios integrados.

En las actuales implementaciones de RMI las

conexiones se generan de forma dinmica. Cuando un
cliente quiere enviar una invocacin, primero crea una
nueva conexin con el servidor. Es difcil estimar el
tiempo y los recursos son necesarios para establecer la
conexin.

Implementaciones de RMI (por ejemplo, GNU

Classpath) crean hebras dinmicamente, lo que no es
adecuado en sistemas de tiempo real crtico.

Uso de algoritmos de serializacin no predecibles.

El uso de recursos es completamente transparente, y por

lo tanto no es configurable. RMI no permite al
programador especificar los parmetros de red. En RMI
no se ha teniendo en cuenta los parmetros de tiempo
real.

Inconvenientes.
Para realizar transacciones no pueden compararse en
su grado de desarrollo con los estndares abiertos de
computacin distribuida como CORBA (Common
Object Request Broker Architecture).

Su rendimiento es bajo si se compara con otros

modelos de computacin distribuida, tales como RMI
(Remote Method Invocation), CORBA o DCOM
(Distributed Component Object Model). Es uno de
los inconvenientes derivados de adoptar un formato
basado en texto. Y es que entre los objetivos de XML
no se encuentra la concisin ni la eficacia de
procesamiento.

Al apoyarse en HTTP, pueden esquivar medidas de

seguridad basadas en firewall cuyas reglas tratan de
bloquear o auditar la comunicacin entre programas a
ambos lados de la barrera.

La principal razn para usar servicios Web es que se pueden

utilizar con HTTP sobre TCP (Transmission Control Protocol)
en el puerto 80.
Dado que las organizaciones protegen sus redes mediante
firewalls -que filtran y bloquean gran parte del trfico de
Internet-, cierran casi todos los puertos TCP salvo el 80, que
es, precisamente, el que usan los navegadores. Los servicios
Web utilizan este puerto, por la simple razn de que no
resultan bloqueados.
Otra razn es que, antes de que existiera SOAP, no haba
buenas interfaces para acceder a las funcionalidades de otros
ordenadores en red. Las que haba eran ad hoc y poco
conocidas, tales como EDI (Electronic Data Interchange),
RPC (Remote Procedure Call), u otras APIs.
Una tercera razn por la que los servicios Web son muy
prcticos es que pueden aportar gran independencia entre la
aplicacin que usa el servicio Web y el propio servicio. De
esta forma, los cambios a lo largo del tiempo en uno no deben
afectar al otro. Esta flexibilidad ser cada vez ms importante,
dado que la tendencia a construir grandes aplicaciones a partir
de componentes distribuidos ms pequeos es cada da ms
utilizada.
Se espera que para los prximos aos mejoren la calidad y
cantidad de servicios ofrecidos basados en los nuevos
estndares.
VI. RPC.
La Llamada a Procedimiento Remoto (del ingls, Remote
Procedure Call, RPC) es un protocolo de red que permite a un
programa de computadora ejecutar cdigo en otra mquina
remota sin tener que preocuparse por las comunicaciones entre
ambas. El protocolo es un gran avance sobre los sockets de
Internet usados hasta el momento. De esta manera el
programador no tena que estar pendiente de las
comunicaciones, estando estas encapsuladas dentro de las
RPC.
Las RPC son muy utilizadas dentro de la comunicacin
cliente-servidor. Siendo el cliente el que inicia el proceso
solicitando al servidor que ejecute cierto procedimiento o
funcin y enviando este de vuelta el resultado de dicha
operacin al cliente. Hoy en da se est utilizando el XML
como lenguaje para definir el IDL y el HTTP como protocolo
de red, dando lugar a lo que se conoce como servicios web.
Ejemplos de estos pueden ser SOAP o XML-RPC.
Tipos.
Hay distintos tipos de RPC, muchos de ellos estandarizados
como pueden ser el RPC de Sun denominado ONC RPC (RFC
1057), el RPC de Open Software Foundation (OSF)
denominado DCE/RPC y el "Modelo de Objetos de
Componentes Distribuidos de Microsoft" (Distributed
Component Object Model, DCOM), aunque ninguno de estos
es compatible entre s. La mayora de ellos utilizan un

lenguaje de descripcin de interfaz (Interface description

language o IDL) que define los mtodos exportados por el
servidor.

ONC RPC: ONC RPC, abreviacin del ingls Open

Network Computing Remote Procedure Call, es un
protocolo de llamada a procedimiento remoto (RPC)
desarrollado por el grupo ONC de Sun Microsystems
como parte del proyecto de su sistema de archivos de Red
NFS, algunas veces se lo denomina Sun ONC o Sun RPC.
Trabaja sobre los protocolos TCP y UDP.

OSF (DCE/RPC): DCE Remote Procedure Call o bien

DCE RPC es un sistema de llamada a procedimiento
remoto del conjunto de software OSF DCE. DCE / RPC,
la abreviatura de "Distributed Computing Environment /
Remote Procedure Calls ", es el sistema de llamada a
procedimiento remoto desarrollado para el entorno de la
informtica distribuida (DCE). Este sistema permite a los
programadores escribir software distribuido como si fuera
todos los que trabajan en el mismo equipo, sin tener que
preocuparse por el cdigo de red subyacente.

DCOM: El Modelo de Objetos de Componentes

Distribuidos (Distributed Component Object Model,
DCOM) es una tecnologa propietaria de Microsoft para
desarrollar componentes de software distribuidos sobre
varias computadoras y que se comunican entre s.
Extiende el modelo Component Object Model (COM) de
Microsoft y proporciona el sustrato de comunicacin
entre la infraestructura del servidor de aplicaciones
COM+ de Microsoft.

Tipos de semntica.

VII. CONCLUSIONES.
Este trabajo identifica la necesidad de un middleware que
permita a la tecnologa Java desarrollar sistemas distribuidos
de tiempo real crtico. RMI proporciona esta funcionalidad y
permite la evaluacin esttica de los tiempos de respuesta de
extremo a extremo. Las contribuciones ms destacadas:

Separacin de la asignacin de los recursos de la

ejecucin: Se separa la asignacin de los recursos de
la ejecucin para mejorar. En una fase de
inicializacin, todos los recursos necesarios para la
siguiente fase se crean y todas las operaciones no
deterministas (como la creacin de conexiones) se
llevan a cabo. En la fase de misin, las invocaciones
remotas se realizan con los recursos asignados.

Referencia remotas asociadas a recursos y

parmetros: Cada referencia se asocia a un conjunto
especfico de recursos (objetos panificables,
memoria, red).
Invocaciones sncronas y asncronas: Gestiona el
modo de invocacin sncrona y asncrona. La
aplicacin puede elegir si el cliente tiene que esperar
por una respuesta o no.
Independencia del protocolo de red: Se asla la
parte dependiente de la red. Se define una interfaz
clara que permite al middleware operar sin conocer
detalles del protocolo subyacente.
Serializacion predecible: Los objetos
transformados en un modo predecible.
VIII. REFERENCIAS.

Definicin de Middleware
http://www.alegsa.com.ar/Dic/middleware.php

son

Middleware
-https://es.wikipedia.org/wiki/Middleware
El Middleware https://iarmenta.wordpress.com/2009/08/24/elmiddleware/#_Toc231023775
Qu es un socket? https://www.masadelante.com/faqs/socket
Diferencias de Sockets http://www.ibiblio.org/pub/linux/docs/LuCaS/Tutoria
les/PROG-SOCKETS/prog-sockets/x31.html
Java Remote Method Invocation https://es.wikipedia.org/wiki/Java_Remote_Method_I
nvocation
Remote Method Invocation Home http://www.oracle.com/technetwork/articles/javaee/in
dex-jsp-136424.html
Web Service http://searchsoa.techtarget.com/definition/Webservices
Llamada a Procedimiento Remoto https://es.wikipedia.org/wiki/Llamada_a_Procedimie
nto_Remoto