1. Capítulo 1
Introducción a los Sistemas
Distribuidos
José Raúl Pérez Cázares
Instituto Tecnológico y de Estudios Superiores de Monterrey (ITESM), México
1.1 Introducción
La industria de la informática se mueve inexorablemente hacia las aplicaciones
distribuidas. Una de las razones estratégicas que impulsan este movimiento es la
migración de la plataforma de cómputo basada en el macro-computador1 hacia las
poderosas redes de estaciones de trabajo. El pleno potencial de esta nueva plataforma
sólo puede alcanzarse si las aplicaciones cooperan entre sí. La heterogeneidad de las
plataformas distribuidas dificulta enormemente esta tarea. Mucho del esfuerzo de
programación se dedica a resolver cuestiones de comunicaciones.
La lógica de mediación2 es la capa de programas que oculta a los desarrolladores de
aplicaciones distribuidas los detalles de la plataforma física incluyendo su
heterogeneidad. Gracias a ella, el entorno de ejecución aparenta ser un sistema uniforme.
Los desarrolladores pueden concentrarse en los aspectos relevantes de la aplicación, la
cual puede ser implantada en cualquier plataforma sobre la que se instale la lógica de
mediación.
En el presente capítulo se presenta un panorama de la lógica de mediación comentando
las diferentes tecnologías que existen, sus ventajas y desventajas. Se hace especial
énfasis en la tecnología orientada a objetos, en particular CORBA, cuya integración con
Java produce la tecnología de base de las plataformas de desarrollo de aplicaciones
distribuidas del futuro.
La primera etapa de la utilización comercial de los computadores estuvo marcada por los
gigantescos macro-computadores que mimetizaban el modelo de desarrollo centralizado
1
mainframe.
2
middleware.

2. CAP. 1: INTRODUCCIÓN A L O S S I S T E MA S D I S T R I B U I D O S
que se practicaba en los negocios. Los sistemas de cómputo tendían a ser homogéneos,
dependientes de un solo proveedor, el cual tenía mucha influencia sobre la empresa.
Todas las herramientas de desarrollo eran proporcionadas por el mismo proveedor ya
que los macro-computadores de diferentes marcas no eran compatibles entre sí. La única
ventaja de esta plataforma homogénea era que facilitaba la comunicación entre usuarios
y hacía posible compartir dispositivos (Figura 1-1).
Macro-Computador
Datos
Aplicación
Almacenamiento
en disco
Terminales
Figura 1-1. Procesamiento centralizado
Estas máquinas eran muy caras y sólo las grandes empresas podían tenerlas. Un
computador no podía ser asignado a un solo usuario, ni siquiera a un departamento. Era
imperativo compartir su uso. Surgen entonces los sistemas operativos multitarea de
tiempo compartido, que permitían repartir el computador entre varios usuarios.
Cada programador fue dotado de una máquina virtual que podía ser tan grande como se
quisiera, dentro de los límites de la máquina real. Cuando la máquina se saturaba, se
autorizaba la compra de una más grande, el siguiente modelo en orden ascendente de
capacidad del catálogo del mismo fabricante.
Era común que los diferentes departamentos de la misma empresa compartieran el costo
y uso de los equipos. Desgraciadamente no pasaba lo mismo con los programas; lo
mejor que podía lograrse era compartir el costo de las herramientas de desarrollo que se
adquirían tales como compiladores, bases de datos, etc. Cada departamento desarrollaba
sus propias aplicaciones. Incluso en el caso en que dos aplicaciones tuvieran varias
funciones en común, éstas se trataban separadamente, produciendo duplicidad de
funciones. Esto se debía a que la racionalización del gasto se concentraba en los equipos
y su costo. El costo de los programas no se consideraba significativo.
1-2

3. TECNOLOGÍAS PARA LA DISTRIBUCIÓN DE LA INFORMACIÓN Y EL PROCESAMIENTO:
INTERNET Y CORBA
El desarrollar las aplicaciones de manera individual ocasionó uno de los principales
problemas que tiene ahora la computación: las aplicaciones tendían a ser monolíticas, es
decir, no ofrecían acceso a los datos y a la funcionalidad interna. Eran sistemas cerrados
que realizaban únicamente su función principal y de los cuales no se podían aprovechar
componentes para ser utilizados en otras aplicaciones similares [GuM95].
1.2 La computación distribuida
Con el progreso de la electrónica, el tamaño y costo de los computadores fue
reduciéndose. Se hizo factible que en algunas aplicaciones, como por ejemplo la
generación de gráficas, se asignara un computador para uso exclusivo de una sola
persona. La velocidad de respuesta ya no dependía del número de usuarios conectados y
se podía disponer de poderosas interfaces gráficas gracias a la potencia de cómputo de
que disponía el usuario en su propia estación de trabajo. La tendencia de reducción del
tamaño de los equipos continuó. Muy pronto fue económicamente posible asignar un
computador a cada usuario. La necesidad de compartir información y dispositivos
periféricos caros, tal como se hacía en la época del macro-computador, motivó la
interconexión de los computadores mediante redes de comunicaciones (Figura 1-2). Las
redes no se utilizaban para compartir funcionalidad sino únicamente dispositivos.
Desgraciadamente, los programas se siguieron desarrollando de manera monolítica.
Terminales
Computadores
Personales
Red de
Área Local
Macro-computador
Servidor de
archivos LAN
Servidor de
impresión
Figura 1-2. Compartiendo dispositivos mediante una red local
Aparecieron, en cambio, múltiples proveedores de equipos para la red y surgieron
estándares para los equipos (redes, interfaces, etc.) buscando garantizar la
compatibilidad. Cualquier pieza de equipo, incluyendo los computadores personales o
estaciones de trabajo, podía ser remplazada por otra pieza similar de otro fabricante. Por
primera vez fue posible construir sistemas heterogéneos. Surge la visión de compartir
también la funcionalidad de las aplicaciones [BeA95], colocando la funcionalidad
1-3

4. CAP. 1: INTRODUCCIÓN A L O S S I S T E MA S D I S T R I B U I D O S
común a varias aplicaciones (clientes) en un sistema servidor. Se crea entonces el
modelo Cliente-Servidor (C/S).
Una aplicación típica consta de los siguientes componentes:
− Lógica de presentación: Es la parte de la aplicación que interactúa con el usuario.
para permitirle leer y escribir información
− Lógica de negocio: Es la parte de la aplicación que procesa los datos para realizar las
tareas del negocio.
− Gestión de datos: Es la parte de la aplicación que manipula el acceso en lectura y
escritura a la base de datos.
Una de las principales decisiones de diseño en un sistema Cliente-Servidor es la
ubicación en el cliente o en el servidor de cada uno de estos componentes (Figura 1-3).
Lógica de Lógica de Gestión de
presentación negocio datos
Figura 1-3. Componentes de una aplicación Cliente-Servidor
La decisión que se tome respecto a la distribución de componentes da origen a varios
estilos de procesamiento cooperativo. La Figura 1-4 muestra la clasificación más
comúnmente utilizada; en ella se puede observar que no necesariamente se asigna una
clase completa de componentes en una sola plataforma sino que, por ejemplo, en el
modelo de presentación distribuida, las funciones de presentación se realizan
parcialmente en el cliente y parcialmente en el servidor. Existen, por supuesto, otras
combinaciones posibles. Los programas necesarios para realizar las comunicaciones no
se representan en ninguna de estas figuras.
1.3 Lógica de mediación
Es una capa de programas ubicada entre el cliente y el servidor (Figura 1-5) que permite
aislar las interacciones cliente-servidor de los mecanismos básicos de comunicación
inter-procesos y de los protocolos de red, mediante un conjunto de interfaces y
facilidades en tiempo de ejecución. Esta capa puede ofrecer servicios tales como
directorio, comunicaciones, seguridad y administración de transacciones.
1-4

5. TECNOLOGÍAS PARA LA DISTRIBUCIÓN DE LA INFORMACIÓN Y EL PROCESAMIENTO:
INTERNET Y CORBA
Componentes de la aplicación
Lógica de Lógica de Gestión de
presentación negocio datos
Cliente
Presentación
Servidor Distribuida
Cliente
Presentación
Servidor Remota
Cliente
Lógica
Servidor Distribuida
Cliente
Gestión de datos
Servidor Remota
Cliente Gestión de datos
Servidor Distribuida
Figura 1-4. Puntos de distribución de las aplicaciones
C C C C
Lógica de Mediación
S S
Figura 1-5. La lógica de mediación
Entre las ventajas que aporta la lógica de mediación se pueden citar:
− Todas las aplicaciones acceden a la red de manera consistente.
− Una aplicación desarrollada para una plataforma puede ser fácilmente portada hacia
plataformas distintas que utilicen la misma interfaz. No se requiere mantener una
versión del programa para cada plataforma existente.
− Simplifica el desarrollo de aplicaciones ya que reduce la cantidad de código a
desarrollar. Los desarrolladores pueden concentrarse en los aspectos primordiales de
la aplicación.
1-5

6. CAP. 1: INTRODUCCIÓN A L O S S I S T E MA S D I S T R I B U I D O S
Los aspectos de comunicaciones, que a veces ocupan hasta 70% del código de una
aplicación, son manejados por la lógica de mediación.
Existen dos modelos computacionales de la lógica de mediación, según la naturaleza de
las entidades a conectar:
a) La lógica de mediación distribuida, que permite comunicar un programa con otro. Se
utiliza en los estilos Cliente-Servidor de presentación distribuida, presentación
remota y lógica distribuida.
b) La lógica de mediación de acceso a datos, apropiada para los estilos Cliente-Servidor
de gestión de datos remota y gestión de datos distribuida.
1.4 Lógica de mediación orientada a datos
Es un mecanismo para pasar comandos del Lenguaje de Consulta Estructurado (SQL,
Structured Query Language) y sus datos asociados, desde un proceso cliente hasta un
servidor (no necesariamente relacional). La lógica de mediación transporta el comando y
lo traduce en el dialecto de la plataforma.
La Figura 1-6 ilustra el caso de una aplicación tratando de tener acceso a varias bases de
datos [OHE96a]. Se requiere una Interfaz para Programación de Aplicaciones (API,
Application Programming Interface) diferente para cada sistema de gestión de base de
datos y también se requiere instalar en el cliente el controlador propietario de cada base
de datos. A estos problemas se puede agregar la falta de interoperabilidad entre las bases
de datos, ya que el formato de los mensajes que viajan por la red es específico de cada
tipo de sistema de gestión. Además, existe la necesidad de contar con múltiples
herramientas de administración y desarrollo. A continuación se describen dos diferentes
estilos de solución a este problema: el uso de una interfaz común y la utilización de una
pasarela.
1.4.1 Solución mediante interfaz común
La primera aproximación hacia una plataforma de acceso uniforme a los datos consiste
en estandarizar una interfaz de acceso (Figura 1-7). El objetivo es crear una API SQL
común que pueda ser utilizada por todas las aplicaciones sin importar el servidor de base
de datos en que resida la información. Las diferencias entre los servidores son
manejadas directamente por el controlador específico de la base de datos. En la red se
siguen utilizando los protocolos individuales.
La transparencia solamente se ofrece al nivel de la interfaz presentada a la aplicación.
Obsérvese que no se trata de una lógica de mediación completa, pues no incluye las
comunicaciones. Esta solución requiere la instalación en el cliente de todos los
controladores de las bases de datos que requiera la aplicación.
1-6

7. TECNOLOGÍAS PARA LA DISTRIBUCIÓN DE LA INFORMACIÓN Y EL PROCESAMIENTO:
INTERNET Y CORBA
Aplicación
API SQL API SQL API SQL API SQL
Controlador Controlador Controlador Controlador
Oracle Progress Paradox SQL Server
FAP FAP FAP FAP
Oracle Progress Paradox SQL Server
SQL
Oracle Progress Paradox Server
FAP = Format And Protocols
Figura 1-6. El problema de las bases de datos múltiples
Aplicación
API SQL Común
Controlador Controlador Controlador Controlador
Oracle Progress Paradox SQL Server
FAP FAP FAP FAP
Oracle Progress Paradox SQL Server
SQL
Oracle Progress Paradox Server
Figura 1-7. Solución mediante interfaz común
El ejemplo más representativo de este tipo de solución es ODBC (Open Database
Connectivity) de Microsoft [Mic01].
1.4.2 Solución mediante pasarela SQL
Esta alternativa propone, además de una interfaz única, la utilización de un controlador
común para comunicarse con todos los servidores (Figura 1-8). Del lado del servidor se
1-7

8. CAP. 1: INTRODUCCIÓN A L O S S I S T E MA S D I S T R I B U I D O S
instala una aplicación (servidor-pasarela) que intercepta los mensajes que llegan con el
formato del protocolo del controlador y los traduce a invocaciones al SQL nativo del
servidor específico.
Aplicación
API SQL Común
Controlador Pasarela
FAP de la
Pasarela
Servidor Servidor Servidor Servidor
Pasarela Pasarela Pasarela Pasarela
SQL
Oracle Progress Paradox Server
Figura 1-8. Solución mediante pasarela SQL
Existen tres principales arquitecturas relacionadas con este concepto [OHE96a]:
− RDA (Remote Data Access) de ISO/SAG.
− DRDA (Distributed Relational Data Access) de IBM.
− EDA (Enterprise Data Access) de Information Builders Inc. (IBI).
1.5 Lógica de mediación distribuida
Es una comunicación de programa a programa. Puede ser soportada por varias técnicas
de procesamiento cooperativo, entre las que se pueden citar:
− Llamada a Procedimiento Remoto (RPC, Remote Procedure Call).
− Lógica de Mediación Orientada a Mensajes (MOM, Message Oriented Middleware)
− Monitor de Procesamiento de Transacciones (TP Monitor).
− Mediador de Peticiones a Objetos (ORB, Object Request Broker).
A continuación se describen brevemente estas categorías de la lógica de mediación.
1-8

9. TECNOLOGÍAS PARA LA DISTRIBUCIÓN DE LA INFORMACIÓN Y EL PROCESAMIENTO:
INTERNET Y CORBA
1.5.1 Llamada a Procedimiento Remoto
Es una extensión del paradigma orientado a procedimientos (estructurado) que consiste
en hacer transparente para el programador la ubicación de las funciones que invoca
(Figura 1-9 y Figura 1-10).
Programa principal
1 2 Procedimiento
3
5 4
flujo de
control
Figura 1-9. Flujo de control en una llamada a procedimiento local (LPC)
Programa principal flujo de
control
3
1 2 Procedimiento
c R R c
a P P a
b Red de b 4
C C
o comunicaciones o
7 6
5
Figura 1-10. Flujo de control en una llamada a procedimiento remoto (RPC)
El desarrollo de una aplicación distribuida comienza por la definición de la interfaz
utilizando un Lenguaje de Definición de Interfaces (IDL, Interface Definition
Language), a partir del cual el compilador se encarga de crear los cabos3 tanto en el
cliente como en el servidor. El cabo del cliente se comporta como si fuera el
procedimiento invocado, mientras que el cabo del lado del servidor es quien realiza la
3
stubs.
1-9

10. CAP. 1: INTRODUCCIÓN A L O S S I S T E MA S D I S T R I B U I D O S
invocación al procedimiento que realiza el servicio. Los servicios en tiempo de
ejecución son los que se encargan de los detalles de las comunicaciones (Figura 1-11).
Definición de la
Interfaz en IDL
Compilador
IDL
Procedimiento
Serv. Serv. remoto
Aplicación Cabo Cabo
RPC RPC
CLIENTE SERVIDOR
Figura 1-11. Proceso de desarrollo con RPC
La principal ventaja de RPC es la familiaridad de muchos programadores con el
paradigma orientado a procedimientos. Entre sus inconvenientes se puede mencionar la
necesidad de interactuar de manera sincrónica. La naturaleza sincrónica de las RPC
fuerza al cliente a esperar hasta que el procesamiento haya concluido para continuar con
la ejecución de la aplicación.
1.5.2 Lógica de Mediación Orientada a Mensajes
Muchos procesos de negocios pueden tolerar la recepción diferida de las respuestas a sus
peticiones. La aplicación que invoca el servicio no espera una respuesta inmediata;
simplemente envía un mensaje con los datos necesarios y más tarde obtiene la respuesta.
Este esquema aporta muchas ventajas; por ejemplo, se puede invocar un servicio aún si
en ese momento el servidor no está activo. Entre sus inconvenientes se puede citar que
es un nuevo paradigma a aprender por los desarrolladores, y su bajo desempeño.
1.5.3 Monitor de Procesamiento de Transacciones
Una transacción es un conjunto de acciones en las que se garantizan las propiedades
ACID: Atomicidad, Consistencia, aIslamiento y Durabilidad.
Los Monitores de Procesamiento de Transacciones se especializan en administrar
transacciones, y proveen un entorno robusto para aplicaciones de gran escala del tipo
OLTP (On Line Transaction Processing). Sus principales servicios son:
1-10

11. TECNOLOGÍAS PARA LA DISTRIBUCIÓN DE LA INFORMACIÓN Y EL PROCESAMIENTO:
INTERNET Y CORBA
− Administración de procesos: Inicia procesos en el servidor, concentra las solicitudes
de trabajo y balancea la carga de los servidores.
− Administración de transacciones: Garantiza las propiedades ACID de las
transacciones.
La Figura 1-12 ilustra un ejemplo de un sistema Cliente-Servidor de tres capas donde el
Monitor de Procesamiento de Transacciones se encarga de controlar los accesos entre
los clientes, las aplicaciones y los datos. Por ejemplo, es posible hacer que varios
clientes compartan una sola conexión con un servidor de base de datos concentrando así
las solicitudes en una sola conexión.
Aplicaciones
RPC DBMS
MOM
… TP Monitor
DBMS
Figura 1-12. Monitor de Procesamiento de Transacciones (TP Monitor)
1.5.4 Mediador de Peticiones a Objetos
Un ORB es una lógica de mediación orientada a objetos. Las tres principales
plataformas existentes en esta tecnología son:
− CORBA (Common Object Request Architecture), del Grupo de Gestión de Objetos
(OMG, Object Management Group).
− DCOM (Distributed Common Object Model) (también COM+), de Microsoft.
− RMI (Remote Method Invocation), de Sun Microsystems
DCOM es la propuesta de Microsoft hacia un modelo de componentes que soporte la
reutilización y facilite la evolución de las aplicaciones existentes, enfocada por supuesto
a la plataforma Windows [Mic02].
RMI es una Interfaz para Programación de Aplicaciones que permite que un objeto que
reside en una máquina virtual de Java pueda invocar un método de un objeto servidor
que reside en otra máquina virtual. Se orienta específicamente a aplicaciones escritas
totalmente en Java [Sun01].
1-11

12. CAP. 1: INTRODUCCIÓN A L O S S I S T E MA S D I S T R I B U I D O S
CORBA por su parte propone una solución a la vez independiente del lenguaje de
programación y de la plataforma de ejecución. En la siguiente sección se describe el
estándar CORBA.
1.6 CORBA
La interoperabilidad entre sistemas y aplicaciones heterogéneos es una meta
contemplada por todas las plataformas distribuidas. Esta meta ha sido generalmente
alcanzada a nivel del sistema operativo pero continúa siendo inalcanzable a nivel de la
aplicación. Los principales obstáculos son la complejidad de las aplicaciones
distribuidas y la falta de interfaces estándar entre aplicaciones [MoZ95]. El OMG
[OMG02] plantea que la tecnología orientada a objetos puede ofrecer una solución al
problema de la interoperabilidad entre aplicaciones, y propone para ello una arquitectura
de referencia en la que se incluyen componentes estándar y un bus de interconexión. Las
siguientes secciones describen la arquitectura propuesta por el OMG, especialmente el
bus de interconexión conocido como CORBA.
1.6.1 Arquitectura para la Gestión de Objetos
La Arquitectura para la Gestión de Objetos (OMA, Object Management Architecture) es
la visión del OMG sobre la interoperabilidad. OMA incluye un servicio de la lógica de
mediación denominado Mediador de Peticiones a Objetos (ORB, Object Request
Broker), que reduce la complejidad del desarrollo de las aplicaciones, y un conjunto de
interfaces estándar que simplifican su integración (Figura 1-13). Los componentes de
OMA son:
− ORB. Es el corazón de la OMA. Se trata básicamente de un bus lógico que
interconecta los componentes. La primera propuesta concreta para un ORB estándar
se denominó CORBA (Common Object Request Broker Architecture). CORBA es
ahora tan popular que es común referirse con este nombre a toda la arquitectura
OMA.
− Servicios de Objetos (Object Services). Son servicios básicos que se prestan
directamente sobre los objetos y están presentes en casi toda aplicación distribuida.
Ejemplos de estos servicios son:
• Servicio de Ciclo de Vida.
• Servicio de Persistencia.
• Servicio de Nombrado.
• Servicio de Eventos.
• Servicio de Concurrencia.
1-12

13. TECNOLOGÍAS PARA LA DISTRIBUCIÓN DE LA INFORMACIÓN Y EL PROCESAMIENTO:
INTERNET Y CORBA
− Facilidades Comunes (Common Facilities). Son aplicaciones genéricas, más
cercanas al usuario final, que pueden ser utilizadas en cualquier dominio de
aplicación (facilidades horizontales). Las facilidades especificadas son:
• Facilidades de Internacionalización y Tiempo.
• Facilidad de Agentes Móviles.
• Facilidad de Impresión.
− Interfaces de Dominio (Domain Interfaces). Son aplicaciones genéricas orientadas
a dominios específicos de aplicación tales como:
• Telecomunicaciones.
• Medicina.
• Finanzas.
• Manufactura.
− Objetos de la Aplicación (Application Objects). Los objetos de la aplicación no se
estandarizan ya que son específicos de la aplicación que se esté realizando. Una
nueva aplicación se puede integrar mediante objetos específicos, facilidades
comunes, interfaces de dominio y servicios de objetos. Todos estos componentes
estarían enlazados por el bus CORBA.
Objetos de la Interfaces Facilidades
Aplicación de Dominio Comunes
Mediador de Peticiones a Objetos (ORB)
Servicios de Objetos
Figura 1-13. Arquitectura para la Gestión de Objetos
1.6.2 Componentes de CORBA
La Figura 1-14 ilustra los principales componentes de CORBA, los cuales se describen
brevemente a continuación.
1-13

14. CAP. 1: INTRODUCCIÓN A L O S S I S T E MA S D I S T R I B U I D O S
Cliente Implementación del Objeto
Esqueleto de la Adaptador
Invocación Cabo del Interfaz Implementación de Objetos
Dinámica Cliente ORB
Núcleo del ORB
Figura 1-14. Componentes de CORBA
Cabo del Cliente (Client Stub). Cada cabo representa una operación sobre un objeto
invocada por un cliente. El cliente está ligado al cabo de manera estática. Mediante esta
interfaz el cliente invoca los servicios de los objetos conocidos en tiempo de
compilación. La invocación se hace sobre un objeto local ya que el cabo es un delegado4
del servidor remoto.
Esqueleto de la Implementación (Implementation Skeleton). Cada esqueleto
proporciona una interfaz dependiente del lenguaje de la implementación del objeto,
mediante la cual el ORB invoca las operaciones ofrecidas por dicho objeto. Equivale al
cabo del lado del servidor.
Invocación Dinámica (Dynamic Invocation). Es una interfaz mediante la cual un cliente
puede construir e invocar dinámicamente operaciones sobre los objetos. Cuando los
objetos invocados no se conocen en tiempo de compilación, es posible en tiempo de
ejecución localizar el servicio deseado y construir la invocación pasando los parámetros
requeridos.
Adaptador de Objetos (Object Adapter). Atiende la gestión de los recursos específicos
del servidor. Facilita a las implementaciones de los objetos el acceso a los servicios del
ORB, como la generación de referencias, y así mismo al ORB la realización de acciones
sobre los objetos, como activación y desactivación, invocación de operaciones, etc.
Interfaz del ORB (ORB Interface). Es la interfaz para las operaciones del ORB
comunes a todos los objetos. Por ejemplo, una referencia hacia un objeto puede ser
convertida en una cadena de caracteres y viceversa.
La Figura 1-15 ilustra el desarrollo de aplicaciones utilizando CORBA. El proceso
empieza por la definición de las clases servidoras mediante el IDL, que es específico
para CORBA y por tanto diferente al que se usa con RPC. El compilador IDL genera el
4
proxy.
1-14

15. TECNOLOGÍAS PARA LA DISTRIBUCIÓN DE LA INFORMACIÓN Y EL PROCESAMIENTO:
INTERNET Y CORBA
cabo del lado del cliente y el esqueleto del lado del servidor. Esto puede hacerse en
cualquier lenguaje soportado por el compilador, y además el cliente y el servidor no
están obligados a utilizar el mismo lenguaje de programación. Finalmente, se agrega el
código del servidor, es decir, el código correspondiente a la interfaz definida en IDL
[OHE96b].
Especificación en IDL
Compilador IDL
Archivo cabecera Archivo cabecera
Implementación
Cliente Cabo ORB Esqueleto de la
Operación
Figura 1-15. Desarrollo de aplicaciones con CORBA
1.7 Comparación entre CORBA y otras lógicas de mediación
En esta sección se compara CORBA con las tecnologías de lógica de mediación más
utilizadas o con mayores perspectivas a corto plazo.
1.7.1 CORBA vs. RPC
Las principales diferencias entre CORBA y RPC se derivan de sus respectivos modelos
de programación. RPC provee un modelo orientado a procedimientos mientras que
CORBA es orientado a objetos. Con RPC se invoca una función específica y los datos
están separados. En el caso de CORBA se invoca un método en un objeto específico, el
cual contiene sus propios datos; diferentes clases de objetos pueden responder a la
misma invocación de manera diferente gracias al polimorfismo; la invocación llega a un
objeto específico, con datos específicos y la función es específica de la clase a la que
pertenece el objeto.
El IDL de CORBA es más general e independiente de los lenguajes de programación
que el IDL de las plataformas de RPC. Esto facilita la interoperabilidad entre
aplicaciones escritas en diferentes lenguajes de programación.
1-15

16. CAP. 1: INTRODUCCIÓN A L O S S I S T E MA S D I S T R I B U I D O S
Una consecuencia del énfasis en la independencia del lenguaje es que el sistema de tipos
en CORBA es simple pero más restrictivo que el de las RPC y no permite el uso de
algunas estructuras tales como los arreglos de tamaño variable.
Por otra parte, muchos servicios como el de seguridad o el de multi-hilos es ofrecido
como servicio básico en algunos ambientes de RPC (por ejemplo DCE), mientras que en
CORBA sólo se ofrece como parte de los Servicios de Objetos.
1.7.2 CORBA vs. MOM
MOM es asíncrono, muy simple y generalmente no ofrece servicios adicionales a los de
las comunicaciones (directorio, seguridad, etc.); es no-orientado a conexión y, en la
actualidad, una solución de bajo nivel. Con el desarrollo de ambientes basados en MOM
que ofrezcan mayor variedad de servicios, la comparación con CORBA tendrá cada vez
más sentido.
1.7.3 CORBA vs. TP Monitor
CORBA y los Monitores de Procesamiento de Transacciones son dos tecnologías que se
pueden complementar una a la otra. El principal papel de los segundos es el de coordinar
la ejecución de diversos procesos respetando reglas de integridad de los datos. Este
papel es muy valioso sobre todo en el futuro ya que se prevé un incremento significativo
en el número transacciones en línea, involucrando cada vez más procesos de manera
simultánea.
CORBA puede aportar la facilidad de comunicarse con las aplicaciones vía una lógica
de mediación estándar. CORBA ofrece el manejo de transacciones como un Servicio de
Objetos (OTS, Object Transaction Service), en cuya definición estuvieron involucrados
varios proveedores de Monitores de Procesamiento de Transacciones.
1.7.4 CORBA vs. Java/RMI
El impacto de Java en la industria de la computación es impresionante. La portabilidad
de Java, la posibilidad de enviar código por la red y su fuerte integración con la
tecnología Web lo convierten en el lenguaje ideal para el desarrollo de aplicaciones
basadas en Internet. RMI se puede describir como un ORB no compatible con CORBA.
RMI es una extensión al lenguaje Java, y es la solución más simple para la lógica de
mediación si toda la aplicación esta escrita en este lenguaje. Pero a pesar del enorme
éxito de Java, hay que considerar la enorme inversión existente en aplicaciones escritas
en otros lenguajes. Muchas aplicaciones se desarrollan en lenguajes apropiados al
dominio, por ejemplo por razones de desempeño, y probablemente lo seguirán haciendo.
1-16

17. TECNOLOGÍAS PARA LA DISTRIBUCIÓN DE LA INFORMACIÓN Y EL PROCESAMIENTO:
INTERNET Y CORBA
Java no es el primer lenguaje de la historia de la computación y seguramente no será el
último. Hasta las mejores tecnologías tarde o temprano se vuelven obsoletas.
1.8 Una plataforma basada en CORBA, Java y la Web
Java/RMI es una tecnología de programación. CORBA en cambio es una tecnología de
integración, diseñada específicamente como plataforma de integración de tecnologías
muy diversas. Cuando un cliente en Java se comunica con un objeto en C++, el ORB le
presenta al cliente Java un cabo con una interfaz en Java y al programador de C++ le
presenta un esqueleto con una interfaz en C++. La clave de la interoperabilidad está en
la utilización del IDL como lenguaje común de definición de interfaces. El ORB
resuelve las demás cuestiones.
Java facilita la creación de objetos portables y su distribución. CORBA permite
conectarlos entre sí e integrarlos con el resto del sistema, ya sea con bases de datos, o
sistemas escritos en otros lenguajes.
CORBA ofrece todo un ambiente de soporte a las aplicaciones distribuidas. Aparte de
las comunicaciones, las aplicaciones necesitan servicios como seguridad, administración
de los objetos existentes, localización, etc. En cierta forma, Java empieza donde
CORBA termina [OHE98]. La Figura 1-16 es un ejemplo de una plataforma Web
aumentada por Java y CORBA.
1.9 Conclusión
La industria de la informática está frente a un cambio de paradigma. Las plataformas
distribuidas son el entorno usual de ejecución y las aplicaciones utilizan arquitecturas
distribuidas y abiertas para adaptarse a dicho entorno. Las aplicaciones monolíticas que
caracterizaron la era de los macro-computadores e inclusive los primeros computadores
personales están llegando a su fin. El esquema Cliente/Servidor en sus múltiples
variaciones es utilizado en todas las nuevas aplicaciones.
La lógica de mediación es una capa de software en medio de los clientes y los
servidores. Su función es soportar las interacciones entre estas entidades. Existen
muchos tipos de lógica de mediación, correspondientes a diversos paradigmas de
programación. El paradigma orientado a objetos ha demostrado ser de gran utilidad en
entornos distribuidos. CORBA es el proyecto más ambicioso de lógica de mediación que
ha visto la industria. CORBA utiliza los objetos como la metáfora de integración de las
aplicaciones. La visión detrás de CORBA es la creación de un bus lógico que permita
interoperar objetos y componentes entre sí, creando así un marco abierto para el
mercado de componentes.
1-17

18. CAP. 1: INTRODUCCIÓN A L O S S I S T E MA S D I S T R I B U I D O S
Servidor
CORBA
ORB
ORBlet ORB
LAN/WAN
Navegador
Web
CGI
Applet
Navegador Servidor
Web HTTP
Figura 1-16. CORBA, Java y la Web
El lenguaje Java ha venido también a revolucionar las aplicaciones distribuidas con su
aportación de código transportable. Java se asocia perfectamente con la Web logrando
una gran sinergia. CORBA puede complementar estas tecnologías aportando la
capacidad de hacer interoperar componentes escritos en diferentes lenguajes de
programación e instalados sobre plataformas heterogéneas. CORBA puede aumentar así
las opciones para construir las arquitecturas distribuidas abriendo la vía del futuro.
1.10 Referencias
[BeA95] Alex Berson, George Anderson. “SYBASE and Client/Server Computing”.
Mc Graw-Hill, 1995.
[GuM95] Michael Guttman, Jason R. Matthews. “The Object Technology
Revolution”. John Wiley and Sons, 1995.
[Mic01] Microsoft. “Microsoft ODBC”. 2001. http://www.microsoft.com/data/odbc.
[Mic02] Microsoft. “Distributed Component Object Model (DCOM)”. 2002.
http://www.microsoft.com/com/tech/dcom.asp.
[MoZ95] Thomas J. Mowbray, Ron Zahavi. “The Essential CORBA, Systems
Integration Using Distributed Objects”. John Wiley and Sons, 1995.
[OHE96a] Robert Orfali, Dan Harkey, Jeri Edwards. “The Essential Client/Server
Survival Guide”. 2 Ed. John Wiley and Sons, 1996.
1-18

19. TECNOLOGÍAS PARA LA DISTRIBUCIÓN DE LA INFORMACIÓN Y EL PROCESAMIENTO:
INTERNET Y CORBA
[OHE96b] Robert Orfali, Dan Harkey, Jeri Edwards. “The Essential Distributed Objects
Survival Guide”. John Wiley and Sons, 1996.
[OHE98] Robert Orfali, Dan Harkey, Jeri Edwards. “Client/Server Programming with
Java and CORBA”. John Wiley and Sons, 1998.
[OMG02] Object Management Group. 2002. http://www.omg.org.
[Sun01] Sun Microsystems. “Java Remote Method Invocation (RMI)”. 2001.
http://java.sun.com/products/jdk/rmi/.
1-19