SISTEMAS DISTRIBUIDOS CON COMPONENTES

Jess T. Quintana Rodrguez*

I. INTRODUCCIN
Desde que se utiliz la computadora en el mbito del proceso de datos, ha existido
la necesidad latente o reconocida de desarrollar sistemas de informacin robustos
(que no fallen), escalables (que puedan crecer) y de fcil mantenimiento (que se
puedan modificar). El estado actual de las comunicaciones electrnicas, el incremento en el poder de hardware, nuevas tecnologas en el desarrollo de software,
nuevos manejadores de bases de datos y diferentes arquitecturas en el acomodo
de las aplicaciones dentro de la red, han hecho posible crear sistemas que se
acerquen cada da ms, a tener esas caractersticas deseadas.
La tecnologa Cliente Servidor propiciada por la aparicin de las computadoras personales y la tecnologa de redes, estableci una revolucin en la forma
en que se desarrollan las aplicaciones. No bien empez esta revolucin, aparece
otra, la tecnologa de componentes, la cual consiste en partir una aplicacin en
objetos inteligentes que, distribuidos en diferentes computadoras en una red, funcionan juntos y transparentemente para los usuarios, proporcionando una mxima
flexibilidad, un mejor desempeo y generalmente un menor costo.
Preponderantemente existen dos estndares que norman la construccin
de componentes: uno es CORBA (Component Request Broquer Arquitecture) elaborado y promovido por el Object Management Group y el otro es DCOM elaborado y promovido por Microsoft.
En el sector pblico de nuestro pas, es difcil encontrar sistemas de informacin eficientes, robustos y de gran alcance parecidos a los que existen en el
sector privado. En el presente trabajo, resultado de la metodologa en vas de instrumentacin en la Secretara de Educacin y Cultura del Estado de Veracruz para
el desarrollo de sus sistemas de informacin, se intenta justificar las ventajas de
aplicar las nuevas tecnologas en el sector pblico con el fin de utilizar mas eficientemente los recursos de cmputo y para facilitar la implantacin de sistemas y la
utilizacin de los mismos. Se describen los conceptos necesarios para la construccin de una aplicacin con la tecnologa cliente - servidor y la utilizacin de componentes distribuidos en varias capas (tiers). Se sugiere el estndar DCOM de
Microsoft por las razones que se exponen en el apartado correspondiente.

Investigador del IIESCA

IIESCA

Ensayos

II. VISIN GENERAL

En la seccin de antecedentes, explicamos el contexto de la institucin pblica en
donde se han instrumentado sistemas con las tecnologas descritas. En el segundo captulo se revisa la evolucin de las arquitecturas para el despliegue de los
sistemas y se mencionan los problemas que se intentaron resolver con cada una
de ellas; el paradigma cliente servidor y su evolucin a n capas (tiers), En el tercer captulo se explica el concepto de componentes y se explican los objetivos de
CORBA y DCOM y la existencia de Monitores de Transacciones de Objetos (Object Transaction Monitors - OTM).
En el cuarto captulo se explica con algunas justificaciones la utilizacin de
DCOM para la elaboracin de aplicaciones en el sector pblico y en cualquier mbito en general
III. ANTECEDENTES
La Secretara de Educacin y Cultura del Estado de Veracruz
La Secretara de Educacin y Cultura del Estado de Veracruz (SEC) en la actualidad, es el resultado de los programas de desconcentracin y descentralizacin de
la administracin pblica, llevados a cabo durante el final de la dcada de los aos
70, principios de los aos 80 y principios de los 90. Al inicio, la hoy llamada SEC
operaba como una delegacin administrativa de la Secretara de Educacin Pblica (SEP). Conforme a lo previsto en dichos programas, a la delegacin de la SEP
en el estado de Veracruz le fueron gradualmente transferidas mayores responsabilidades, funciones, autonoma, obligaciones, controles, etc. hasta convertirse en la
Secretara de Gobierno ms grande, con el mayor presupuesto de gasto autorizado y con el mayor nmero de empleados de todo el gobierno estatal.
Algunas cifras
Cuando se integr la SEC, tal y como hoy se conoce, hered de la SEP la administracin de recursos federales de aproximadamente 25,000 escuelas y diversos
institutos, 2,000,000 de alumnos, 70,000 empleados y 105,000 plazas de trabajo.
Actualmente, la SEC ha incorporado a su administracin todos los recursos de
origen netamente estatal destinados a la educacin, incrementando su planta instalada en un 40%. En total la SEC aglutina poco ms de 100,000 empleados,
150,000 plazas de empleo, 33,000 centros de trabajo (escuelas, institutos, oficinas) y ms de 2,500,000 alumnos.
Servicios informticos
Se considera como servicio informtico, cualquier apoyo que por medio de un programa o aplicacin de cmputo reciba el personal de la SEC para el desempeo
de sus actividades cotidianas y en general, cualquier proceso de datos masivo que
requiera el uso de computadoras.
9

Sistemas distribuidos con componentes.

El desarrollo de los servicios informticos en la SEC, como es natural, ha

venido creciendo y adaptndose segn los requerimientos: De la institucin, del
usuario y de la tecnologa empleada. El hecho anterior por si mismo ha sido bueno
y necesario, sin embargo, tal desarrollo, en unas ocasiones por la tecnologa disponible y en otras debido a visiones de corto plazo y alcance, no ha sido todo lo
estructurado, ordenado y planeado que se hubiera deseado. Por el contrario, los
servicios informticos en la SEC se han desarrollado de manera aislada, con alcances limitados, usando tecnologa heterognea y concebidos para el corto plazo.
Lo anterior refleja una constante en los servicios informticos del sector pblico: falta de planeacin adecuada, peticiones de servicios a destiempo y sin orden, cambio de instrucciones intempestivamente, servicios aceptados por ensayo
y error; Etc.
Para poder cumplir con estos servicios, a veces anrquicos, una de las alternativas que se utiliza es la de invertir grandes sumas en equipo para poder prevenir cualquier eventualidad, pero dado los avances en software y otras tecnologas (objetos, cliente servidor, componentes, comunicaciones, manejadores de
bases de datos) es posible combinar estos ltimos con equipo de menor costo y
obtener resultados adecuados
En la SEC se ha empezado a obtener algunos resultados que auguran resolver los problemas de servicios informticos satisfactoriamente. En el resto del
trabajo expondremos las ventajas de este enfoque.
IV.

EVOLUCIN DE ARQUITECTURAS

Introduccin
En este captulo se hace una revisin histrica de los cambios que se han dado en
la manera de distribuir y acomodar tanto el hardware como el software utilizados
en la solucin de sistemas de informacin administrativos. Dado que en las empresas an persisten y conviven todas estas arquitecturas1, con la perspectiva actual es posible encontrar en cada una las partes cliente y servidor y concluir
como lo hacen muchos autores, que todas son arquitectura Cliente Servidor. No
obstante la presentacin que hacemos aqu es una presentacin cronolgica conforme a la evolucin que tuvieron con el fin de hacer patentes sus ventajas y desventajas y justificar la aparicin de cada una como la solucin de los problemas de
la anterior.

Consideramos que una arquitectura es un mecanismo para comunicar al equipo de desarrollo o a los usuarios en general,
cmo est construida una aplicacin. Explica la estructura de esta y lista sus piezas. Es parecido a decir: Una casa de
dos pisos con cuatro recmaras, sala recmara y comedor

10

IIESCA

Ensayos

Sistemas Multiusuario

Cara
ctere
s

Pr

es
io
ne
s

de

Te

cl
as

Durante los aos 60 y 70, las empresas que necesitaban tener gran poder de
cmputo utilizaban una arquitectura centralizada. Consista en una computadora
nica o mainframe a la cual, bajo el control de un sistema operativo multiusuario,
se conectaban terminales ahora llamadas tontas por carecer de un procesador
central. (Ver Fig. 1). La nica funcin de las terminales era transmitir a la computadora central, las
Arquitectura Centralizada con un Mainframe
seales
que
el
usuario
introduca
Lgica de la
con la presin de las
Aplicacin
Datos
teclas y presentar en
Servidor
la
pantalla
los
caracteres que el
computador central
enviaba de regreso.
Mainframe
Toda
la
inteligencia,
esto
es, las instrucciones
de los programas o
lgica
de
la
aplicacin, junto con
Clientes
sus datos, resida en
Figura 1
el mainframe, el que
generalmente con un
solo procesador central (CPU) atenda todos los requerimientos introducidos a travs de las terminales. No obstante que en esa poca no existan los conceptos de
cliente o de servidor, podemos ahora decir que se pueden distinguir un servidor en
el sentido de que hay un computador que proporciona servicios y varios clientes,
las terminales, que solicitan servicios.
Las arquitecturas de este tipo todava persisten y tienen como ventaja una
gran seguridad y una fcil administracin; pero en contra, es muy costosa y los
usuarios siempre lamentan la lentitud de los procesos. Adems de esto, su flexibilidad es muy poca o nula porque casi nada se puede hacer, a excepcin de incrementar memoria, para mejorar el desempeo. Nada se le puede modificar a la
aplicacin con respecto a su acomodo dentro del equipo. Esto es, si consideramos
que por lo general toda aplicacin est compuesta de tres partes funcionales, presentacin, lgica y datos, colocar alguna de estas partes en otro lugar que no sea
el computador central era y es imposible.
Servidor de Archivos
A finales de la dcada de los 70, aparecieron las computadoras personales y con
ellas, ya en la dcada de los 80, se hicieron evidentes sus grandes ventajas y
desventajas. Por un lado su facilidad de uso que propici que personas con pocos

11

Sistemas distribuidos con componentes.

conocimientos tcnicos las pudieran aprovechar. Tambin importante fue la competencia que se desencaden entre las empresas de cmputo, misma que trajo
consigo una explosin en el poder de cmputo y en la complejidad de los programas. Estos desarrollos acercaron an ms las computadoras a los usuarios finales.
Pero, en contraparte, la dispersin de la informacin hizo su aparicin. En
distintas computadoras haba la misma informacin, la seguridad de su acceso era
mnima; los informes emitidos en computadoras distintas no cuadraban; se perdan archivos; El obtener informes consolidados era difcil. Ante esto, hicieron su
aparicin las redes de rea local y la arquitectura de servidor de archivos (Ver Fig.
2). Esta arquitectura consiste en conectar varias computadoras personales o
workstations a una computadora central (o varias) la cual proporciona acceso a
recursos de cmputo como impresoras y discos duros.
Esta arquitectura trajo un
Arquitectura con Servidor de Archivos
cambio radical comparada
con la del mainframe. Como
Datos
se muestra en la Fig. 2, la
lgica o inteligencia de la
aplicacin reside ahora en
Servidor de Archivos
los clientes en lugar del
e
En
sd
v
ue
a
servidor. El servidor se
oq
l
B
b
o
Di loq
ita isc
sc u e
lic
D
o
o
encarga de enviar archivos
s
S
de
o grandes bloques de datos
conforme le son requeridos.
Entre las ventajas de
esta
arquitectura
se
Workstation 1
Workstation 2
Workstation 3
Workstation 4
Lgica de la
Lgica de la
Lgica de la
Lgica de la
encuentra un costo inicial
Aplicacin
Aplicacin
Aplicacin
Aplicacin
bajo y acomodo flexible; si
hacen falta mas clientes,
solamente se conectan y si sobran se desconectan. Entre las desventajas tenemos que el cliente ejecuta casi toda la aplicacin: interfase con el usuario y reglas
del negocio (se dice que es un cliente gordo), por lo cual se requiere que tenga
suficiente
deServidor
cmputo.
Si es
una un
aplicacin
Proceso depoder
SQL en un
de Archivos
Utilizando
DBF o MDB muy demandante de recursos
quiz sea imposible hacer crecer al cliente a un nivel satisfactorio. Adicionalmente,
* FROM
a largo plazo,SELECT
el costo
deEmpleados
la arquitectura se incrementa considerablemente.
WHERE NumEmp = '1850'
Otra desventaja, de gran importancia, radica
en la forma en que son enviaTabla DBF o
MDF con
dos los datos requeridos desde el servidor hacia el
cliente. Como puede apreciar30,000
registros
se en la Fig. 3, cuando un cliente necesita datos de una persona residentes en el
servidor, elabora un comando de SQL (Structured Query Language), el cual se
procesa todo en el cliente. El cliente lo que enva al servidor es un requerimiento
de la tabla completa. El servidor enva de regreso toda la tabla, la cual podra consistir de miles de registros, y es el cliente tambin quien se encarga de seleccionar
Cliente WS
Servidor de Archivos
los datos del empleado. Esta forma de operacin genera una sobrecarga de la red.
Comando SQL se
Una Elsituacin
como esta se tiene cuando se utiliza Novel en versiones anteriores
evalua del lado del
Figura 2

cliente

Solicitud de Tabla

Enva Tabla solicitada

va I/O
Aqu se procesa el
Query

Tabla con 30,000 registros

Figure 3

12

IIESCA

Ensayos

como sistema operativo de red y a fox o access como el manejador de base de

datos en el servidor.
Los modelos de servidor de archivos todava estn en uso y son ideales en aplicaciones donde se comparten archivos, por ejemplo para crear depsitos compartidos de documentos, imgenes o planos de ingeniera

Cliente Servidor (CS) de dos capas (tiers)

Una manera de eliminar las desventajas de la arquitectura de servidor de archivos,
es la arquitectura cliente- servidor. Uno de los objetivos de este modelo es el de
prorratear lo mas eficientemente posible las cargas del proceso entre todas las
computadoras. El modelo cliente - servidor es un paradigma en el cual los elementos de un sistema de computacin requieren servicios desde otro sistema para
completar una tarea. El que requiere el servicio se denomina cliente y el que lo
proporciona es el servidor. En este modelo los papeles de cliente y servidor no son
necesariamente fijos, un servidor por ejemplo podra solicitar un servicio a otro
servidor con el fin de satisfacer la peticin de su cliente, actuando por lo tanto en
ese momento a su vez como cliente. Por ejemplo una PC cliente puede solicitar a
un servidor de impresin la impresin de un trabajo y el servidor de impresin, a
su vez, le solicita a la impresora llevar a cabo la tarea. El modelo no define que
papeles juegan cada componente en un sistema ni tampoco impone restricciones
acerca del tipo de hardware o software que se debe utilizar, as que caractersticas
importantes son las siguientes:

Es una relacin de servicio entre procesos. El proceso servidor es un

proveedor de servicios y el cliente es un consumidor de servicios

Los servidores pueden conectarse a uno o a ms de un cliente

Los clientes pueden comunicarse con mltiples servidores

Es posible una comunicacin cliente a cliente y una comunicacin servidor a servidor

Los clientes siempre inician el dilogo al requerir un servicio. Los servidores esperan pasivamente requerimientos de sus clientes. La interaccin se logra mediante un intercambio de mensajes

Los elementos cliente - servidor pueden existir en diferentes computadoras a travs de la red o en una sola computadora. El software CS oculta
a los clientes la localizacin de los servidores

El software CS ideal debe ser independiente de plataformas de hardware y software

13

Sistemas distribuidos con componentes.

El servidor debe ser un especialista. Un mensaje le indica el servicio requerido y el solo determina como satisfacerlo. Puede mejorarse el desempeo y funciones de un servidor pero no se pude modificar la interfase de comunicacin (interfase publicada)

Los sistemas CS se pueden escalar (hacer crecer) horizontal y verticalmente. El escalamiento horizontal se da cuando aumentamos mas
clientes quiz disminuyendo ligeramente el desempeo del sistema. El
escalamiento vertical quiere decir cambiar el servidor o distribuir la carga en varios servidores
No obstante lo anterior una manera comn de visualizar el modelo (y que es
la que nos ocupar) es asociarlo con una computadora llamada servidor que tiene
recursos que se necesitan compartir, tales como la base de datos de una empresa, y al cliente con una PC que se encarga de manejar la interfase de la aplicacin.
Como se dijo, las aplicaciones CS ms comunes hoy en da se encuentran
alrededor de un manejador de base de datos. Estas aplicaciones conocidas como
back ends, proveen el soporte para el almacenamiento, manipulacin y recuperacin de los datos de la empresa. Estos sistemas utilizan SQL (structured query
language), el lenguaje estndar de acceso a bases de datos, como la herramienta
para enviar las peticiones al servidor desde el cliente.
Es ilustrativo entender mas especficamente algunas diferencias entre las
arquitecturas CS y servidor de archivos. Como vimos antes, en la Figura 3 se
ejemplifica una arquitectura con servidor de archivos y una computadora personal
que le hace peticiones. Suponemos que en el servidor existen archivos tipo dbf o
mdb manejados con dbase o fox o access y se desea encontrar los datos de un
empleado. Cuando se realiza un query (consulta) al servidor, este es evaluado y
procesado en el cliente y nunca se enva al servidor; lo que se enva es una requisicin de un archivo. El servidor enva al cliente bloques de informacin que, una
vez en el cliente y en el espacio de este, son procesados para encontrar la informacin solicitada de los datos del empleado. Muy poca actividad lgica se desarrolla en el servidor. El cliente es el encargado de desarrollarla casi completamente
ya que se ocupa, adems, de la interfase con el usuario y de la ejecucin de la
lgica correspondiente
a
las
reglas
del
Proceso de SQL en un sistema Cliente - Servidor usando un DBMS C/S
negocio, es decir, del
SELECT * FROM Empleados
cdigo que por ejemplo
WHERE NumEmp = '1850'
valida la aprobacin de
Oracle o SQL
Server con
un nuevo crdito o la
30,000
registros
inclusin
de
un
empleado a la nmina.
Adicionalmente
la
carga sobre la red es
muy fuerte.
Cliente WS
Servidor de Archivos
En contraste, en la FiSe enva el comando
Comando SQL
SQL
gura 4 se trata de
Se procesa el Query
del lado del servidor
Se recibe el
resultado

Se devuelve un registro

Figura 4

14

IIESCA

Ensayos

ejemplificar qu ocurre si se utiliza una arquitectura cliente servidor. El query se

enva al servidor y este se encarga de interpretarlo mediante las aplicaciones que
residen en l. Por esta razn solamente se envan los resultados al cliente, esto
es, solo los datos del empleado viajan a travs de la red en vez de una tabla de
30,000 registros o ms.
Algunos autores consideran el servidor de archivos como una arquitectura CS con
un servidor "flaco".
Arquitectura Cliente - Servidor de tres y n capas (tiers)
Es una realidad que el objetivo de las aplicaciones modernas no es solo procesar
transacciones y generar reportes, sino el de que sean sistemas de informacin
robustos y que puedan cambiar conforme cambien las necesidades de la empresa
o institucin. Mientras las aplicaciones se utilicen en el mbito y edificio de una
empresa de regular tamao, el modelo de dos capas (el que ya describimos: una
capa es el servidor y otra los clientes) es el adecuado porque adems es muy fcil
de controlar y desarrollar. Pero cuando la aplicacin rebasa los lmites fsicos de
un edificio y se vuelve estatal o mundial, con numerosos clientes distribuidos en
cualquier parte, o cuando la aplicacin es complicada, el modelo de dos capas se
hace insuficiente.
Una respuesta a estos retos y a las aplicaciones de la Web, es un enfoque
con arquitecturas CS de tres y n capas. Para entender la necesidad de ampliar el
nmero de capas desde dos, a tres y ms capas, se necesita revisar con mayor
profundidad el modelo de dos capas.
El modelo de dos capas se encuentra ligado fuertemente a la implantacin
fsica, esto es, una computadora personal operando como el cliente y un servidor
en la red conteniendo la base de datos de la empresa y la maquinaria de software
(engine) para operar aquella. La lgica de la aplicacin (o lo que es lo mismo, todos los ifs, dos, fors, etc.) se encuentra repartida en las dos capas; en el
cliente, quiz elaborada con una herramienta grfica RAD (rapid aplication development) y en el servidor instrumentada mediante procedimientos almacenados y
triggers que son instrucciones precompiladas de SQL.
En este ambiente de trabajo, si varios programadores realizan aplicaciones
contra la misma base de datos, se vuelve complicada la administracin del cdigo
con el fin de poder reutilizarlo. Adems este cdigo es generalmente exclusivo de
cada fabricante de manejadores de bases de datos lo que obliga a depender de
ellos.
Por otro lado, si se desea modificar la aplicacin cliente, y esta se encuentra replicada digamos en 50 computadoras personales, es necesario reinstalar la
aplicacin en las 50 computadoras para mantener actualizadas las reglas del negocio. Una solucin a este problema es aumentar las capas.
El concepto de n capas ha cambiado con el tiempo, puede referirse tanto a
hardware como a software. La ms clara definicin se refiere al hardware, donde
una arquitectura ser de n capas si esta repartida en n computadoras. As, una
arquitectura de hardware de tres capas incluye tres clases de computadoras: el
15

Sistemas distribuidos con componentes.

cliente que usualmente es una PC; la capa de en medio que podran ser una estacin de trabajo como servidor o una minicomputadora y en la tercera capa usualmente una minicomputadora o un mainframe para el manejo de los datos. Una
arquitectura CS con hardware en dos capas generalmente incluye solo el cliente y
ya sea un servidor de mediano tamao o un mainframe.
Desde el punto de vista de software, y que tambin es la visin que se plantea en este trabajo, la arquitectura cliente servidor de tres capas est dada por los
tres elementos funcionales bsicos que generalmente tiene una aplicacin, ya sea
CS o no: presentacin, lgica y datos. Cada aplicacin que interacciona con un
usuario necesita una seccin de software que se encargue de establecer la interfase hombre mquina. As mismo, si la aplicacin quiere mantener resultados a
travs del tiempo, se requiere una seccin que maneje los datos y por ltimo, el
proceso de esos resultados requiere una seccin de lgica o una serie de ifs y
dos. Pueden existir algunas excepciones, por ejemplo una aplicacin que consista de una calculadora podra no necesitar almacenar datos y una aplicacin incluida en otra podra no tener una seccin de presentacin; sin embargo, es difcil
concebir una aplicacin, por muy trivial que sea, sin una parte lgica.
Por lo anterior, en un medio ambiente CS tpico (Ver Figura 5), una computadora personal manejara la interfase, un servidor de mediano tamao ejecutara
la lgica del negocio y una minicomputadora contendra la base de datos.
Es posible que dos o ms elementos funcionales se ejecuten en la misma
mquina. Por ejemplo en la Figura 6 tenemos una configuracin que fsicamente
es de dos capas pero lgicamente es de tres capas, porque la presentacin y la

Presentacin

Lgica

Datos

Figura 5

lgica corren en una computadora personal y la base de datos reside en el servidor.

Algunos sistemas parten las aplicaciones an ms y dividen una o ms de
las capas (tiers) a travs de la red. Por ejemplo la base de datos de la empresa se
puede repartir en varios servidores (an con distintas plataformas) presentando
una vista nica
de la misma a la
parte de lgica
de la aplicacin
que necesita ac-

16

Presentacin y Lgica
Figura 6

Datos

IIESCA

Ensayos

ceder a la base de datos. De igual manera es posible dividir la lgica de la aplicacin (quiz la parte que conforma las reglas del negocio) en mltiples computadoras. De esta manera, la aplicacin puede correr en cuatro, cinco o an ms equipos recibiendo el nombre de n capas (ntiers). En la figura 7 se muestra una arquitectura lgica de tres capas en una arquitectura fsica de cuatro capas.
Con un acomodo de este tipo se tendra una mayor flexibilidad y se resolveran los problemas que generaba el modelo de dos capas. Cuando hubiera necesidad de modificar la lgica de la aplicacin no tendra que hacerse en cada cliente
sino solamente en el servidor en el cual est depositada (servidor de negocios) al
cual accederan todos los clientes. De igual manera, si tenemos una base de datos
distribuida en varias computadoras an en diferentes plataformas, podra utilizarse

Presentacin

Lgica

Lgica

Datos

Figura 7

un servidor para hacerles transparente a los clientes esta diversidad y hacerles

concebir una vista uniforme de los datos. Este servidor se encargara de interpretar los requerimientos y canalizarlos a la computadora con los datos requeridos.
Entre las ventajas de la arquitectura de tres capas con respecto a la de dos
capas mencionamos las siguientes:

Administracin menos compleja porque en los servidores de cada capa se

descarga el grueso de la administracin

La seguridad se incrementa porque se pueden establecer controles finos en

cada capa y, adems por ejemplo, en vez de actuar con los datos directamente, el cliente tiene contacto con las reglas del negocio y nada ms. Los
datos y las reglas quedan encapsulados.

Mayor facilidad de escalamiento (crecimiento), intrnseca en el modelo

Soporte para bases de datos heterogneas

Mucho mayor flexibilidad de distribucin de las funciones de la aplicacin

V. SOLUCIONES POR COMPONENTES

Introduccin

17

Sistemas distribuidos con componentes.

En este captulo se explican las razones del porqu es necesario ir ms all del
modelo CS de n capas hasta utilizar componentes. Se habla de la necesidad de un
midleware que los controle y de la necesidad de estndares para lograr una comunicacin entre diferentes plataformas. Se describen los dos estndares dominantes en la industria.
Objetos Distribuidos
Como se vio, con el modelo CS de n capas es posible separar o distribuir una aplicacin de acuerdo a sus funciones resolviendo as los problemas existentes en el
modelo de dos capas. No obstante, algunas limitantes persisten. Por ejemplo, la
aplicacin cliente debe conocer como estn los datos en el servidor. Si se desea
cambiar la ubicacin de las aplicaciones en los servidores sera necesario modificar al cliente para advertirle de los cambios. Debe darse un paso ms para obtener sistemas acordes con los tiempos actuales en los que millones de computadoras se entrelazan intercambiando informacin.
Un nuevo modelo est cambiando la forma de acomodar las aplicaciones y
est revolucionando el desarrollo de las mismas: las aplicaciones Cliente Servidor con Objetos Distribuidos. Esta nueva tecnologa promete la construccin de
aplicaciones eficientes, robustas, escalables y mantenibles. Ser posible con
ella, instalar sistemas de informacin complejos simplemente ensamblando y/o
extendiendo las capacidades de componentes de software reutilizables que trabajan juntos, independientemente del tipo de computadoras, redes, lenguajes y sistemas operativos. Cualquiera de estos componentes de software puede ser modificado o reemplazado sin afectar al resto de los componentes en el sistema y sin
modificar la forma en que interactan.
Componentes
Los componentes son una extensin de los objetos descritos en la programacin
orientada a objetos. Como tales son una fusin de cdigo y datos que funcionan
como una unidad y funcionan tambin como objetos en el sentido de que tienen
herencia por interfase, polimorfismo y encapsulacin. Por el contrario, a diferencia
de los objetos tradicionales, los componentes pueden interoperar entre ellos independientemente de lenguajes, herramientas, sistemas operativos y redes y pueden extenderse utilizando herencia por implementacin.
Un objeto tpico construido con C++ o Java, como dijimos es un programa
inteligente que encapsula cdigo y datos pero, aunque permite una reutilizacin de
cdigo mediante la herencia y la encapsulacin, solo vive dentro de un programa,
solo el compilador que los crea conoce su existencia. El mundo exterior al programa y al compilador no sabe que existe este objeto y no tiene manera de acceder a
l.
En contraste, un componente (objeto distribuido), es un programa inteligente que puede vivir en cualquier lugar en la red. Se empacan como piezas independientes e inteligentes de cdigo, a los cuales pueden acceder clientes remotos va
invocaciones de sus mtodos. El lenguaje y el compilador que se utilizaron para
crearlos (los componentes servidores) no son importantes para los componentes
18

IIESCA

Ensayos

clientes. Adicionalmente los componentes clientes no necesitan conocer en donde

se encuentran los componentes servidores o que sistema operativo los controla
para poder tener acceso a ellos.
Una caracterstica importante de los componentes es que tienen separada
su intefase de su implementacin, esto es, una cosa es el objeto con funcionalidad
propia y que se encarga de hacer el trabajo para lo que fue creado y otra cosa es
el cdigo que permite la comunicacin del componente con otros componentes.
Esta interfase est constituida por mtodos, propiedades y eventos que son llamados por otros componentes. Lo anterior significa que se pueden construir interfases que funcionen como envolturas de las aplicaciones existentes en la empresa hacindolas que parezcan componentes comunes. La ventaja es enorme porque no habra que desechar las viejas aplicaciones probadas y funcionales como
tendra que hacerse en un modelo de dos capas Ver Figura 8 tomada del libro de
Orfali en la siguiente pgina.
Funciones mnimas de los componentes
Las siguientes son las funciones mnimas que segn Orfali (ver referencia 5), debe
tener un componente. (Esta definicin incluye tanto lo que ofrece CORBA como lo
que ofrece DCOM)
Un componente es una pieza empacada de software funcional en si misma
que se puede comprar en un mercado de cmputo abierto

Un componente puede combinarse con otros componentes para formar una

aplicacin completa. Est diseado para desempear un conjunto limitado
de tareas dentro del dominio de una aplicacin. Los componentes pueden
ser objetos finamente granulados tales como un objeto en C++; objetos
medianamente granulados tales como un control en una interfase grfica o
objetos gruesamente granulados tales como una aplicacin antigua completa.

19

Sistemas distribuidos con componentes.

Los Componentes:
A) Se pueden ensamblar

B) Operan entre si

C) Se pueden portar y mover

D) Coexisten

E) Se autoadministran

Figura 8

20

IIESCA

Ensayos

Igual que los objetos del mundo real, un componente puede ser utilizado en
maneras totalmente impredecibles por su desarrollador. Tpicamente pueden combinarse con otros componentes de la misma familia - llamada suit usando mecanismos de "enchufar y funcionar " (plug-and-play)
Igual que cualquier objeto, un componente solo puede manipularse a travs
de su interfase. Sin embargo, la interfase de un componente est separada
de su implementacin. La interfase es el "contrato" que el componente expone al mundo, Cmo instrumentar interiormente este contrato es asunto
del componente. Se puede instrumentar un componente utilizando objetos,
cdigo procedural2 o mediante la encapsulacin de cdigo existente.
CORBA y COM proveen un Lenguaje de Definicin de la Interfase (IDL), independiente de cualquier otro lenguaje de desarrollo, que se puede utilizar
para especificar las interfases de los componentes. Java soporta interfases
como parte del lenguaje

Para enfatizar y facilitar su utilizacin, los componentes deben poderse

agrupar en cajas o paletas de herramientas grficas desde donde puedan
ser utilizados y personalizados. La paleta es un contenedor de componentes. Adems, la mayora de las herramientas proveen lienzos (formas o
ventanas) que se pueden utilizar para ensamblar los componentes utilizando tcnicas de arrastrar y soltar (drag and drop) y otras tcnicas visuales.
Las formas funcionan tambin como contenedores visuales de componentes.

Un componente debe ser capaz de avisarle al mundo cuando le sucede a l

alguna cosa de inters. El componente realiza esto sealando un evento.
Otros componentes que tienen inters en este evento pueden suscribirse al
mismo. Estos otros componentes recibirn una notificacin cuando el evento se dispara. Este tipo de acoplamiento es ideal para unir componentes
mediante una herramienta visual.

Los componentes tienen estado. Las propiedades pueden identificar y sacar

a la superficie esta informacin; definen las caractersticas de un componente. Una propiedad es un atributo discreto con nombre que se puede utilizar, tpicamente utilizando un editor dentro de una herramienta grfica, para leer y modificar el estado de un componente.

Un componente debe permitir que su interfase se pueda controlar con un

lenguaje (scripting).

Un componente debe proveer, cuando se le requiera, informacin sobre s

mismo. Esto incluye una descripcin de sus interfases, propiedades, eventos, calidad de servicio y las suites que soporta.

Un componente puede invocarse como un objeto a travs de espacios de

direcciones, redes, lenguajes, sistemas operativos y herramientas. Es una

Procedural significa que se tiene que indicar al computador como hacer las cosas en lugar de decirle que es lo que se
desea

21

Sistemas distribuidos con componentes.

entidad de software independiente de cualquier sistema o aplicacin. Ver

siguiente figura tomada del libro de Orfali.

La Declaracin de Independencia de los Componentes

Y yo digo
poder a los
componentes
Correccin

Libertad!

Liberacin
de los
componentes

Un componente debe proveer un nmero limitado de operaciones para

promover su utilizacin. En otras palabras el nivel de abstraccin debe ser
tan alto como sea posible para invitar a que el componente sea reutilizado.

Object Request Brokers (ORB)

Para que el esquema de componentes distribuidos trabaje, debe existir algn mecanismo para conocer el lugar en que se encuentran y para encaminar los requerimientos de los componentes cliente y las respuestas de los componentes servidor. Algunas personas le llaman a estos mecanismos software buses y actualmente son conocidos como Object Request Brokers (ORB) en ingls y en espaol,
vendr a ser algo as como un intermediario o gestor de componentes.

22

IIESCA

Ensayos

Un object request broker es el software que reside en la parte media o

middleware3 del esquema Cliente - Servidor y que se encarga de comunicar componentes cliente con componentes servidor. El cliente invoca un mtodo de un
componente remoto, el ORB localiza un ejemplar de la clase de ese componente,
invoca el mtodo solicitado que hace que el componente trabaje y regresa el resultado al objeto cliente.
Obviamente, si cada fabricante se dedicara a elaborar componentes sin el
seguimiento de algn estndar, la comunicacin entre los mismos sera imposible.
En el presente existen dos tecnologas o estndares importantes para el manejo
de los componentes: CORBA y COM. Estos dos estndares, junto con otras infraestructuras tales como los Object Transaction Monitors (OTM), herramientas
visuales para crear componentes y metodologas unificadas de anlisis y diseo,
han permitido que una tecnologa que tiene mas de 20 aos de existir logre consolidarse y hacerse til. A la fecha existen varios ORBs comerciales que siguen el
estndar CORBA. Como ejemplo estn: Orbix, VisiBroker, JavaIDL, ObjectBorker
y PowerBroker entre otros. Por el otro estndar que es patrocinado por Microsoft,
solo existe un ORB llamado DCOM.
El estndar CORBA4
CORBA son las siglas de Common Object Request Broker Arquitecture. Estas siglas designan a un conjunto de estndares que forman un marco de referencia
para establecer la interaccin de los componentes. Fue elaborado por el OMG
(Object Management Group), una institucin formada por la mayora de las compaas (unos autores dicen que 100 y otros que 800 segn les guste o no el estndar) ms importantes de hardware y software del mundo, que tiene por objetivo
promover asuntos de orientacin a objetos y la promocin de estndares abiertos
para sistemas orientados a objetos. CORBA no es un producto sino solo un estndar. Las especificaciones se escriben en un lenguaje de definicin neutral (Interfase Definition Language - IDL) que define la frontera de un componente, es decir,
su interfase con clientes potenciales.
CORBA fue diseado desde su origen para resolver el problema de intercomunicar mquinas es entonces una arquitectura ad hoc para manejar componentes remotos o distribuidos. La especificacin CORBA establece una infraestructura para que exista una comunicacin entre procesos dentro de la misma mquina o entre diferentes mquinas.
El empaquetamiento de componentes no fue el primer objetivo durante las
primeras fases del desarrollo de CORBA; sin embargo, provee una interoperacin
entre lenguajes, plataformas y vendedores. Debido a que se ha instrumentado en
un rango amplio de plataformas y vendedores (mainframe, Unix, Windows),
CORBA es la arquitectura dominante en la distribucin de objetos remotos.
3

Middleware es un trmino genrico no muy preciso, que se utiliza para describir el software necesario para permitir la
interaccin entre clientes y servidores.

Cuando nos referimos a un estndar, no queremos decir que es una norma de aplicacin universal, sino unas reglas de
operacin aplicables en cierto contexto

23

Sistemas distribuidos con componentes.

El Estndar DCOM
A principios de los aos 90, Microsoft realiz un gran esfuerzo en promover OLE
en sus siglas en ingls que se podra traducir como incrustacin y vinculacin de
objetos. La necesidad de hacer esto naci del deseo de los usuarios de computadoras personales de elaborar documentos que incluyeran tanto texto como grficas y tablas. Dado que cada programa es especialista en alguna tarea, por ejemplo un procesador de texto sirve para manejar texto, los programas de hojas de
clculo sirven para el manejo de tablas y nmeros y los de diseo para grficas,
etc.; era difcil incrustar los resultados de uno en otro.
Rpidamente Microsoft reconoci la necesidad de un mecanismo estndar
de empaquetamiento de componentes si quera que OLE fuera exitoso. Era crucial
que estos componentes fueran independientes de lenguajes para que se pudieran
desarrollar con cualquier lenguaje e incrustarse en otro componente escrito en otro
lenguaje tal vez.
Microsoft cre COM (Component Object Model) modelo de objetos componentes, que es un estndar para la creacin y comunicacin entre componentes
pero dentro de la misma mquina. Al final de 1996, Microsoft introdujo DCOM (La
D es de distribuido) un conjunto de extensiones a COM que permite distribuir a los
objetos COM en varias computadoras en la red,. Ha existido una lentitud en que
aparezca COM en plataformas diferentes a Windows, debido a esto, regularmente
se identifica a COM como una arquitectura de componentes en lugar de una arquitectura de componentes remotos o distribuidos; sin embargo, COM tiene mucho
que ofrecer en este sentido, especialmente cuando se trabaja en ambientes Windows. Segn Jason Pritchard (Ver ref 9) COM es indudablemente la arquitectura
de componentes mas madura y prolfica actualmente en uso debido al predominio
de Microsoft en las computadoras de escritorio
Object Transaction Monitors (OTM)
Se mencion ya, que el ORB (Object Request Broker) es el mecanismo encargado
de realizar la comunicacin entre los componentes. Encuentra al componente requerido por el cliente, acciona los mtodos de aquel y devuelve a este el resultado; es simplemente un bus de comunicacin entre componentes.
Sin embargo, un ORB no facilita del todo las cosas. Queda pendiente una
administracin efectiva y eficiente de los millones de componentes a los que los
clientes pueden acceder.
Ejemplos de aspectos pendientes seran por ejemplo los aspectos de seguridad, permisos, ciclo de vida de los componentes, cuando y como llamar a todos
los servicios del ORB, Etc. Una alternativa de solucin es cargar a los componentes con kilos de cdigo para que ellos mismos realicen estas funciones. Esta
solucin convertira a los componentes en piezas difciles de manejar y requerira
programadores con mucha experiencia en un ORB en particular, adicionalmente,
los componentes serviran o estaran optimizados para un ORB pero para otros
no, lo cual dificultara la comunicacin entre brokers.

24

IIESCA

Ensayos

La solucin que se ha encontrado es emplear un OTM (Object Transaction

Manager) o gestionador de las transacciones de los componentes. Un OTM es el
software que se encarga de crear un medio ambiente organizado para manejar y
controlar los componentes del lado del servidor. Permite definir y administrar los
componentes tpicamente en un medio ambiente grfico. El OTM establece un
pool de componentes, distribuye sus cargas y coordina las transacciones entre
componentes. El usuario escribe la lgica y a tiempo de ejecucin, el OTM intercepta todas las llamadas a componentes, invoca los componentes requeridos y le
pasa una conexin del componente al cliente haciendo las veces de un orquestador. El resultado es un manejo automtico de los componentes del lado del servidor hacindolos robustos, persistentes, seguros y eficientes.
Cuando se utiliza un OTM se logra que los componentes adquieran caractersticas adicionales en su funcionamiento como las que se mencionan enseguida:
Seguridad: Un componente puede protegerse as mismo y a sus recursos, desde
el medio ambiente. Puede identificarse a sus clientes y viceversa, provee controles
de acceso y conserva estadsticas de su utilizacin.
Permisos: Puede establecer polticas de permisos
Versiones: El componente provee una forma de control de versiones para asegurar que sus clientes utilizan la versin correcta.
Manejo del ciclo de vida: Se puede manejar la creacin, destruccin, almacenamiento, publicacin del contenido y el traslado de un lugar a otro de los componentes.
Persistencia: El componente puede salvar su estado y posteriormente restablecerlo
Creacin de colecciones (suits) de componentes dentro de contenedores que facilitan una relacin mas estrecha, dinmica y eficiente entre componentes propios
de un tema o dominio (Por ejemplo Hotelera, las finanzas, Etc.).
Auto Instalacin: El componente se puede auto instalar y automticamente tambin registrarse en el sistema operativo o el registry.
Varias compaas han desarrollado OTMs. Entre las que siguen el estndar
de la OMG estn los siguientes: M3 de BEA, Application Server 4.0 de Oracle,
PowerTier de Persistence, NetDynamics de Sun, Jaguar CTS de Sybase, Etc. Por
otra parte, el OTM de Microsoft se llama Microsoft Transaction Server (MTS).
Objetos de negocios
Solo falta una cosa para hacer completa una aplicacin Cliente Servidor moderna:
Los componentes de negocios.
La ltima meta es crear componentes que se comporten como objetos de
negocios del mundo real Son objetos que modelan el comportamiento del mundo
en algn tema o dominio. Realizan funciones caractersticas del objeto que representan, esto es, un cliente, un coche, un hotel, Etc. Estos objetos se agrupan en
colecciones que semejan lugares reales y es posible presentarlos en el monitor de
la computadora.
25

Sistemas distribuidos con componentes.

De esta manera se intenta crear componentes muy inteligentes que colaboren al nivel semntico entre s para realizar un trabajo. As podramos tener
colecciones de componentes para hotelera, medicina, finanzas, Etc.
Los objetos de negocios son perfectos para crear aplicaciones de tres y
ms capas ya que intrnsicamente estn partidos. En la primera capa se colocan
los componente visuales que tienen que ver con el usuario para el manejo de la
aplicacin. Por lo general estarn en el cliente. En la(s) capa(s) de en medio se
colocan los componentes servidores del negocio que contienen las reglas del negocio y por ltimo, en la tercera capa se encontrarn tpicamente las bases de datos, las aplicaciones viejas. Adems como la colocacin de los componentes es
muy dinmica, a tiempo de ejecucin es posible decidir una nueva localidad para
ellos quiz por razones de un mejor desempeo o alguna otra.
Los componentes de las capas de en medio interactan con sus clientes.
Estos a su vez, pueden obtener sus datos desde mltiples fuentes, por ejemplo
bases de datos SQL, archivos planos de aplicaciones viejas, archivos HTML, Etc.
Estos componentes servidores presentas a sus clientes una visin integrada y uniforme, de tal manera que el cliente no se entera ni se preocupa de donde estn los
datos, a los cuales nunca tiene acceso directamente lo que hace mayor la seguridad. Estas fuentes de datos son totalmente ocultadas a los clientes pudindose
inclusive, partir en varios equipos o cambiar de lugar toda la base de datos.
VI.

RECOMENDACIN DE UNA SOLUCIN

Cul estndar se debe seleccionar?. Tanto CORBA como DCOM renen los requisitos para crear componentes reutilizables. En la industria del software los dos
estndares tienen su grupo de seguidores los cuales defienden los mritos de su
eleccin. Existen foros de discusin en Internet con discusiones que llegan al fanatismo, parecidas a las suscitadas con el debate PC contra Mac.
La decisin de elegir DCOM para la Secretara de Educacin de Veracruz
se bas en consideraciones internas a la Secretara, de la regin y del contexto
mundial en la tecnologa de cmputo, a saber:
El nmero de personas capacitadas o susceptibles de capacitarse. No creo
mentir al decir que a la fecha existe poco personal capacitado en la elaboracin de
sistemas distribuidos con componentes, al menos en el estado de Veracruz. Sin el
conocimiento y dominio de la tecnologa es casi imposible desarrollar sistemas
exitosos. Esta falta de capacitacin es an ms acentuada en el sector pblico. El
saber con cuantas personas, ya capacitadas o susceptibles de, se cuenta para
iniciar una migracin de sistemas tradicionales a sistemas distribuidos es fundamental. Estas personas debern ser otras de las dedicadas a la operacin normal
porque la operacin no se puede detener. Hay que considerar que el separar a los
tcnicos entre los que desarrollan lo nuevo y los que operan lo viejo genera
problemas porque al personal de informtica casi siempre le gusta incursionar en
las novedades
Popularidad de la tecnologa, Quiz dentro de las preguntas importantes que
deberan tener una respuesta estara la siguiente: Mantendr Microsoft el incre26

IIESCA

Ensayos

mento de su dominio?. No siempre lo ms popular es lo mejor pero tiene algunas

ventajas: Abundan los libros y revistas sobre el tema; existen innumerables foros
de discusin en Internet; se tiene un bajo costo de capacitacin porque el costo de
los cursos es relativamente bajo y hasta hay cursos por correspondencia y por
Internet; hay una gran facilidad de encontrar colegas con afinidad, lo que permite
el contraste de ideas, Etc. Por ltimo es casi seguro que cualquier informtico haya escuchado o ledo la palabra DCOM pero es mas difcil haber escuchado
CORBA
Facilidad de adquisicin de los implementos. El entorno mismo de la institucin
en donde se desarrollan los sistemas determina que tan fcil es adquirir nuevo
software. Algunos funcionarios de los que toman las decisiones no consideran importante adquirir novedades casi siempre por desconocimiento. El estndar DCOM
viene incluido en Windows que generalmente lo tienen todas las computadoras
personales
Costo. Las herramientas para construir componentes vienen incluidas sin costo en
el software de Microsoft, son parte del sistema operativo (Windows NT y Windows
2000 en Windows 98 se necesita un parche sin costo -) El servidor de transacciones si tiene un costo pero mnimo comparado con CORBA
Por ltimo, para tranquilidad de los que participaron en la eleccin de un estndar
u otro (CORBA o DCOM) el riesgo se disminuye dado que existe software que
permite la comunicacin entre objetos creados con el estndar CORBA y componentes creados con el estndar de Microsoft
Bibliografa
1. Yen Ping Shan y Ralph H. Earle Enterprise Computing with Objects 1998 Addison Wesley
2. Doug Lowe Client Server Computing for Dummies Third Edition 1999 IDG Books
3. John Schettino y Lis OHara Corba for Dummies 1998 IDG Books
4. Ash Rofail y Tony Martin Building N Tier Applications with COM an Visual Basic 6.0 1999
Wiley
5. Robert Orfali, Dan Harkey y Jeri Edwards Client / Server Survival Guide Third Edition 1999
Wiley and Sons
6. Noel Jerke, Gerge Szabo, David Jung & Don Kiely Visual Basic 6 Client / Server How To
1999 SAMS Publishing
7. Dan Appleman Developing COM / ActiveX Components with Visual Basic 6 1999 SAMS Publishing
8. Jeremy Rosenberger Teach yourself Corba in 14 days 1998 SAMS Publishing
9. Jason Pritchard COM y CORBA side by side 1999 Addison Wesley

27