PDF de programación - Tecnologías de Desarrollo de Sistemas Distribuidos basados en Objetos

Notas

Tecnologías de Desarrollo de Sistemas
Distribuidos basados en Objetos

Resumen

Debido al auge que se ha venido dando últimamen-
te en el uso de las redes, se ha incrementado el creci-
miento de los entornos distribuidos y heterogéneos. El
desarrollo de aplicaciones distribuidas enfrenta diferen-
cias de arquitectura, tales como: el hardware, el siste-
ma operativo, el ambiente de desarrollo, el lenguaje de
programación e incluso el paradigma de programación,
por todo esto ha sido necesario utilizar diferentes tec-
nologías y mecanismos de desarrollo. La programación
distribuida hace uso de distintas tecnologías e incluso
puede mezclarlas para generar nuevas. Este artículo
presenta tres tecnologías para la programación distri-
buida, las denominadas Tecnologías de Desarrollo de
Sistemas Distribuidos basados en Objetos.

Palabras clave: Aplicaciones distribuidas, CORBA,

COM /DCOM/ActiveX, JavaBeans.

1. Introducción

El presente artículo presentará tres de las tecnolo-
gías utilizadas para el desarrollo de aplicaciones distri-
buidas, las cuales han generado un nuevo paradigma
en el desarrollo de aplicaciones distribuidas, denomi-
nado, aplicaciones basadas en “Plataformas de Compo-
nentes Distribuidos”. Primeramente se hablará de
CORBA (Common Object Request Broker Architectu-
re), que es una tecnología de integración que define
un marco estándar para interoperabilidad entre obje-
tos con independencia del lenguaje y de forma trans-
parente al programador. Posteriormente se describirá
COM/DCOM/ActiveX, que son mecanismos de comu-
nicación entre procesos diseñados principalmente para
los sistemas Windows. Y por último se hablará de los
JavaBeans, que son un modelo de componentes que

favorece la reutilización y que son visualizados en un
entorno Java.

2. CORBA

CORBA (Common Object Request Broker Architec-
ture), es una arquitectura de objetos distribuidos, que
con el patrocinio del grupo OMG (Object Managament
Group) compuesto por compañías como American Air-
lines, Canon, Data General, HP, Philips Telecomunica-
ciones, Sun, 3Com, Microsoft y Unisys entre otros; se
ha convertido en un estándar y gracias a ello permite a
aplicaciones de software implementadas incluso en di-
ferentes lenguajes comunicarse entre sí, a través de sis-
temas de cómputo, que a su vez pueden estar
conformados por hardware, sistemas operativos distin-
tos y que forman parte de alguna red. Además, la eje-
cución de objetos remotos se puede lograr sin la
necesidad de un servidor Web.[6]

CORBA al ser un estándar cuenta con un conjunto
de especificaciones, sobre las cuales los vendedores de
implementaciones de CORBA, conocidas como Object
Request Broker (ORB) se apegan, para facilitar la co-
municación con la implementación de otro vendedor.[9]
CORBA cuenta con tres elementos principales en
los cuales se basa: El lenguaje de definición de interfa-
ces IDL (Interface Definition Language), el ORB (Ob-
ject Request Broker) y el protocolo GIOP (General
Inter-ORB Protocol).[5]

En cuanto al modelado de los objetos, CORBA hace
uso del modelo cliente/servidor para el manejo de los
mensajes y así establecer la comunicación entre ellos,
cuando un objeto en una aplicación cliente requiere
ejecutar los métodos de un objeto remoto en una apli-
cación servidor, hace uso del ORB que es específico
para el lenguaje y la plataforma de cada aplicación, el

TEMAS DE CIENCIA Y TECNOLOGÍA vol.10 número 30 septiembre-diciembre 2006 pp 57 - 61
TEMAS | septiembre- diciembre 2006

57

cual traduce la llamada del cliente a un formato neu-
tro, totalmente independiente, que puede transportar-
se sobre cualquier medio para el cual exista un
protocolo de comunicación.[9]

Un esquema conceptual de la arquitectura de COR-

BA se muestra en la figura 1.

FIGURA 1: ESQUEMA DE CORBA

Como se observa en la figura 1, se tienen tres ele-
mentos importantes: El Cliente Stub, un Servidor Ske-
leton y el ORB .

El Cliente Stub es una entidad de programa que in-
voca una operación sobre la implementación de un ob-
jeto remoto a través de un Stub cuyo propósito es lograr
que la petición de un cliente llegue hasta el ORB Core.
Logrando el acoplamiento entre el lenguaje de progra-
mación en que se escribe el cliente y el ORB Core. El
stub crea y expide las solicitudes del cliente.

Un Servidor Skeleton es la implementación de un
objeto CORBA en algún lenguaje de programación, y
define las operaciones que soporta una interface IDL
CORBA. Puede escribirse en una gran variedad de len-
guajes como C, C++, Java, Ada o Smalltalk. Y a través
del skeleton entrega las solicitudes procedentes del
ORB a la implementación del objeto CORBA.

La función del ORB consiste en conectar las dos par-
tes: cliente y servidor. Presumiblemente estas partes se
ejecutan sobre plataformas distintas y funcionan con
diferentes sistemas operativos. Esto significa que pue-
den existir diferencias en tipos de datos, el orden de

los parámetros en una llamada, el orden de los bytes
en una palabra según el tipo de procesador, etc. Es mi-
sión del ORB efectuar los procesos conocidos como
marshaling y unmarshaling. En caso de que el método
invocado devuelva un valor de retorno, la función de
los ORB del cliente y servidor se invierte. Éste realiza
el marshaling de dicho valor y lo envía al ORB del clien-
te, que será el que realice el unmarshaling y finalmen-
te facilite el valor en formato nativo.[12]

Existe una gran variedad de implementaciones CORBA.

En las siguientes páginas web:
• http://www.puder.org/corba/matrix/
• http://adams.patriot.net/~tvalesky/freecorba.html
se encuentran implementaciones basadas en CORBA
y se describen sus características, algunas son propie-
tarias y otras más son libres.

3. COM/DCOM/Activex

COM (Component Object Model) es un estándar
que permite la creación de objetos que ejecuten ta-
reas que resuelven problemas específicos pero comu-
nes a varias aplicaciones que puedan desear hacer uso
de ellos. Estos pueden ser invocados por diferentes
programas que los requieran, tanto OLE como ActiveX
están basados en esta tecnología.

La idea es tener un mundo de objetos independien-
tes de un lenguaje de programación. Por ello COM pro-
porciona un estándar para las comunicaciones entre
componentes, de tal forma, que una aplicación puede
utilizar características de cualquier otro objeto de la apli-
cación, o del sistema operativo, y permite actualizar el
software de un componente sin afectar a la operación
de la solución global.[1]

COM soporta comunicación entre objetos de equi-
pos de cómputo distintos, en una LAN, WAN, o incluso
en Internet.

DCOM extiende el estándar COM de objetos remo-
tos, para su utilización en redes. Inicialmente se desa-
rrolló para Windows NT 4.0, y posteriormente para
Solaris 2.x y Macintosh, así como para diferentes ver-
siones UNIX.

Se encarga de manejar los detalles muy bajos de
protocolos de red, por lo que el desarrollador se pue-
de centrar en la realidad de los negocios, proporcionan-
do así mejores soluciones a los clientes.

La arquitectura define cómo los componentes y sus
clientes interactúan entre sí. Esta interacción es definida

58

TEMAS | septiembre- diciembre 2006

Notas

de tal manera que el cliente y el componente puede
conectarse sin la necesidad de un sistema intermedio.
El cliente llama a los métodos del componente sin tener
que preocuparse de niveles más complejos.

DCOM olvida completamente la localización de los
componentes, no importando que estén en el mismo
proceso que el cliente o en una máquina en cualquier
lugar del mundo. En cualquier caso, la forma en la que
el cliente se conecta a un componente y llama a los
métodos de éste, es idéntica. No es sólo que no nece-
site cambios en el código fuente, sino que además no
necesita que el programa sea recompilado. Una simple
reconfiguración cambia la forma en la que los compo-
nentes se conectan entre sí.

La independencia de localización en DCOM simpli-
fica enormemente las tareas de los componentes de
aplicaciones distribuidas para alcanzar un nivel de fun-
cionamiento óptimo. Supongamos, por ejemplo, que
cierto componente debe ser localizado en una máqui-
na específica en un lugar determinado. Si la aplicación
tiene numerosos componentes pequeños, se puede
reducir la carga de la red situándolos en la misma LAN,
en la misma máquina, o incluso en el mismo proceso.
Si la aplicación está compuesta por un pequeño núme-
ro de grandes componentes, la carga de red es menor
y no es un problema, por tanto se pueden poner en las
máquinas más rápidas disponibles independientemen-
te de donde estén situadas.

Es completamente independiente del lenguaje. Casi
cualquier lenguaje puede ser utilizado para crear com-
ponentes COM, y estos componentes puede ser utili-
zado por muchos más lenguajes y herramientas. Java,
Microsoft Visual C++, Microsoft Visual Basic, Delphi,
PowerBuilder, y Micro Focus COBOL interactúan per-
fectamente con DCOM.

Puede utilizar cualquier protocolo de transporte,
como TCP/IP, UDP, IPX/SPX y NetBIOS, y proporciona
un marco de seguridad a todos estos protocolos.

Los desarrolladores pueden utilizar las característi-
cas proporcionadas por DCOM y asegurar que sus apli-
caciones son completamente independientes del
protocolo.[11]

DCOM está pensado para que el sistema pueda fun-
cionar bajo cualquier tipo de red, ya sea LAN, WAN o
Internet, de forma que se solucionen los múltiples pro-
blemas que añaden estos entornos.

La denominada tecnología ActiveX desarrollada por
Microsoft hizo su aparición en Internet con el navega-
dor Internet Explorer 3.0. Su objetivo es similar al de
los plug-ins, insertar objetos de diferente tipo en una
página Web, aunque va mucho más allá al añadir ma-
yores posibi