• Introducción

A los nuevos servicios de las empresas, le corresponden nuevas funciones de aplicación. Esas
modificaciones de aplicación deben poder hacerse rápido, sin tener que reescribir todo.
Corría la segunda mitad de la década de los 80’, cuando comienzan a generalizarse en m últiples
aplicaciones los sistemas de gestión de bases de datos orientadas al objeto (OODBMS), los cuales
toman las ventajas del enfoque orientado al objeto, ya probados y los sistemas de gestión de bases de
datos, siendo su principal virtud el ofrecer un muy buen desempeño en la gestión de datos complejos y
multimediales.
Desde el punto de vista del desarrollador las ventajas están dadas en ganancias de productividad, dado
su modelamiento más simple que facilita el desarrollo de aplicaciones. El modelamiento de aplicaciones
es mucho más sencillo gracias al concepto de objetos complejos y el modelo obtenido es fácilmente
comprensible para el usuario. Este modelo puede ser validado directamente por el cliente de la
aplicación. El enfoque Orientado al Objeto favorece la reutilización, porque gracias a la encapsulación y
la herencia, es fácil especializar un componente existente para responder a las necesidades particulares
de la aplicación.

Desde el punto de vista del usuario final de los OODBMS, el mayor aporte es la calidad en términos de
ergonomía, fiabilidad, evolución y desempeño. La mayor parte de los productos disponibles en el
mercado, son productos cerrados, difícilmente adaptables a las especificaciones de la empresa: la
ergonomía de la aplicación es fija, las reglas de cálculo son difícilmente modificables, etc. la tecnología
objeto, gracias en particular a la encapsulación y la herencia, da productos desarrollos con un OODBMS
más abierto y f ácilmente adaptables. El usuario puede obtener un costo menor de las modificaciones de
sus procedimientos, que van a integrar más fácilmente su medio ambiente (entorno).
Un poco de historia
La primera aparición del concepto data de 1984 con la proposición de David Maier y George Copeland
de construir un DBMS desde Smalltalk, Copeland et al. (1984) [5].
Se pueden citar dos grandes proyectos desde 1985, el proyecto ORION de MCC en Austín, Texas y en
1986 el proyecto Altair, en Rocquencowt, Francia. En 1988, la primera generación apareció, seguida por
una segunda generación en 1990.


Después de esta intensa actividad, pareciera necesario definir de una manera precisa el concepto de
OODBMS (Sistemas de Gestión de Bases de Datos Orientadas al Objeto). En efecto, contrariamente al
caso de los sistemas relacionales que primero fueron definidos formalmente en el artículo original de
Codd, después se generaron prototipos y finalmente transformados en producto, no hubo un principio
de especificaci ón precisa de lo que debía ser un OODBMS.
En 1989, el paper "The Object-Oriented Database System Manifesto"[1] aunque con un enfoque
demasiado limitado en temas de administraci ón, Stonebraker et al. (1990), propone una definición
compuesta de tres tipos de reglas que deben respetar un OODBMS:
l Reglas Obligatorias: Las cuales el sistema debe imperativamente seguir para merecer la calidad
de OODBMS.
l Reglas Facultativas: Lineamientos suplementarios del sistema, pero que no son indispensables.
l Reglas Abiertas: Propiedades alternativas del sistema que puede ejercer.
El conjunto de reglas es rápidamente admitido por la comunidad científica y comercial como un
consenso mínimo.
A principios de la década de los 90’, la comercialización efectiva de sistemas progresó rápidamente y
fueron desarrolladas varias aplicaciones.
En 1992, los principales distribuidores se juntan para definir un est ándar que asegure la portabilidad de
las aplicaciones de un sistema a otro, y en Octubre de 1993 es publicado el estándar del ODMG (Grupo
de Administraci ón de Bases de Datos Orientadas al Objeto), Catell et al. (1993) [4]. Se cuenta con una
tecnología madura y adaptada al mercado, una oferta rica y diversificada, una demanda para este tipo
de producto y un estándar realista (ODMG-93 es un estándar para bases de datos al objeto puras, en
contraste con el estándar SQL3 nacido para bases de datos relaciones extendidas basadas en objetos,
siendo ésta compatible con el modelo relacional clásico).
El estándar ODMG-93: Un estándar para bases de datos orientadas al objeto puras
Es el resultado de trabajos que duraron 18 meses por los 5 principales distribuidores de OODBMS. Su
objetivo fue asegurar la portabilidad de las aplicaciones de un sistema a otro. En este objetivo son
definidas tres interfaz:
1) ODL (Lenguaje de Definición de Objetos)
El lenguaje de definición del objeto permite definir el modelo de datos. Es compatible con IDL, el
lenguaje del OMG (Grupo de Administraci ón de Objetos). Permite la definición de objetos complejos, de
relación entre esos objetos y de métodos asociados a dichos objetos.
2) OQL (Lenguaje de Consulta al Objeto)
El lenguaje de requerimientos permite consultar los objetos de estructuras complejas, de enviar
mensajes a objetos, efectuar join y otras operaciones de tipo asociativo. Su sintaxis es del tipo SQL.
3) Conexión vía C++ y Smalltalk.
Esta interfaz ("bindings", enlazamientos), especifica como se debe hacer la programación en C++ o
Smalltalk de una aplicaci ón sobre una base de datos que ha sido declarada en ODL. La conexión es
basada sobre la noción de "puntero inteligente" que permite manejar los objetos persistentes como
objetos ordinarios vía punteros persistentes.


Definiendo las OODBMS
Un OODBMS ofrece todas la funcionalidad de un sistema de gestión de bases de datos, al igual que
todas las de un sistema objeto.
Conceptos DBMS
La tecnología de gestión de bases de datos (DBMS), nació a fines de los años 60. Las tecnologías de
implementación de esos sistemas han evolucionado, su arquitectura ha emigrado hacia una arquitectura
Cliente/Servidor, pero los servicios ofrecidos (En particular a su nivel f ísico) son los mismos. La figura 1
muestra un DBMS tradicional considerando sus aspectos más característicos.
Un DBMS ofrece facilidades de almacenamiento, de acceso, manipulación y de compartimento de
grandes volúmenes de datos. Esos datos pueden ser muy abultados, ellos no están ni en memoria
principal ni en memoria virtual. Es el DBMS quien asegura la gestión de diferentes niveles de jerarqu ía
de memoria, el programador no hace la diferencia entre un dato en memoria y un dato en disco. La
gestión del disco asegurada por el DBMS debe ser transparente y ofrece buenos desempeños. Ella debe
ofrecer mecanismos tales como gestión oculta de indexación, reagrupamiento de objetos sobre los
discos (debe proveer una forma adecuada de reagrupar los objetos de un nivel físico, a un nivel
superior ), etc.

Figura .1: DBMS Tradicional, Manola (1994) [6].

El DBMS garantiza igualmente la coherencia de los datos en casos de actualización simultánea por
varios usuarios (mecanismo de transacciones), su integridad en caso de operaciones incorrectas por un
programa o un usuario, su fiabilidad en caso de rollback o commit y su confidencialidad en caso de
accesos mal hechos o accidentales (mecanismos de seguridad).
Los lenguajes de consultas nacieron con las DBMS Relacionales, permitiendo simplemente interrogar a
la base de datos sin tener que escribir un programa específico. Un lenguaje de consulta es un elemento
indispensable que uno debe encontrar en todo SGDB.

• Los conceptos de Objetos

El objeto reagrupa en una misma entidad una parte estática: los datos del objeto y una parte dinámica:
el conjunto de operaciones, también llamados métodos, que pueden ser aplicados a cada objeto y son
conocidos en el mundo exterior a través de una interfaz pública (ver figura 2) constituida por algunas
operaciones (métodos). La parte estática así como la implementación de operaciones están ocultos; es
un principio conocido como "encapsulación". Este mecanismo garantiza la independencia entre la vista
externa de un objeto (su parte pública) y su vista interna (su implementación). La encapsulación
impone un buen nivel de modularidad.

Figura 2: Composición de un Objeto.

La parte estática del objeto puede reagrupar informaciones alfanuméricas, gráficas, textuales, sonoras,
etc. Ella puede ser atómica (los objetos atómicos son del tipo de base del sistema: enteros, reales,
caracteres, strings, booleanos) o compleja (constituida a partir de otros objetos, atómicos o complejos).
La parte dinámica del objeto puede estar constituida de funciones de archivos, cálculos, de búsqueda de
información, etc. Contrariamente a lo que existe en la programación clásica, las operaciones son
subordinadas a los objetos; el objeto no es solamente caracterizado por lo que es, sino también por lo
que hace, ocultando la estructura interna de un objeto y la implementación de las operaciones.
Cada objeto tiene una identidad propia (ver figura 3), independiente de su valor. Podemos actualizar el
valor de un objeto sin alterar su identidad. El sistema maneja su identidad, atribuyendo a cada objeto
un identificador que asegura unicidad.

 

Figura 3: La identidad objeto.



La noción de identidad de objeto guarda relación con la composición del objeto, diferenciándose de
otros objetos.
Conceptos como la herencia permiten definir una clase (la clase define una estructura y un
comportamiento común, a varios objetos) de objetos a partir de una clase ya existente (herencia
simple) o de varias otras clases (herencia múltiple). La clase creada recupera no solamente su
estructura sino además sus métodos de su(s) clase(s) padre(s). La herencia trae una descripción
compacta bien estructurada del esquema de aplicación. Es una técnica de clasificación de objetos que
evita la duplicación de código facilitando la reutilización de propiedades de estructuras y
comportamientos ya definidas.
Los objetos se comunican entre ellos por envío de mensajes, lo que se quiere decir, es que transmiten
órdenes a otros objetos. Cuando se recibe un mensaje por un objeto, éste lo ejecuta. Él puede crear
nuevos objetos y enviar nuevos mensajes.
Los métodos asociados a clases diferentes, pueden tener el mismo nombre: la elecci ón del método que
sea efectivamente llamado es aplazada hasta el momento de la ejecución (enlazamiento dinámico),
dependiendo de la persistencia de la clase del objeto del cual el m étodo es llamado en tiempo de
ejecución. Ese mecanismo de enlace dinámico aumenta la independencia entre los m étodos y los
objetos y permite sumar nuevas clases sin modificar ni recompilar los programas existentes, Por
ejemplo, la aplicaci ón de gestión de pago maneja diferentes tipos de contratos, cada uno con su
método de cálculo de sueldo, basta con crear una nueva subclase de la clase "contrato" con un método
de cálculo de sueldo correspondiente a ese algoritmo. Esos nuevos contratos son entonces
inmediatamente tomados en cuenta por los programas existentes, sin modificación particular del
código.
La herencia y el enlazamiento dinámico permiten alivianar los programas y el trabajo del programador
(por efecto de la reutilizaci ón) cuando se activan los m ódulos de la aplicación.
Se hace notar que el modelamiento de objetos se puede realizar bajo una forma gr áfica, pudiendo tener
ciclos.

• Conceptos espec íficos de OODBMS

La noción de objetos complejos optimiza la representación de las estructuras complejas y acortando la
distancia que separa el modelamiento de un escenario del mundo real y su implementación. Los objetos
complejos permiten así, un modelamiento más intuitivo de datos de una aplicaci ón, su presentación en
la base de datos está mas cerca de la realidad. La estructura compleja de los objetos es manejada por
punteros lógicos. Esos punteros reemplazan la utilización de uniones relacionales, e inducen así una
ganancia de desempeño, particularmente cuando la cantidad de datos es importante. La siguiente figura
muestra un esquema típico de una OODBMS:



Figura 4: Una OODBMS tradicional, Manola (1994) [6].

El concepto de identidad de objeto, tiene repercusiones particularmente interesantes en el contexto de
un DBMS. La distribución de objetos permite limitar la tabla de la base de datos. Permite una mejor
gestión de actualización, y es más rápida, ya que tiene menos objetos que modificar. Ofrece igualmente
una gestión automática de integridad referencial (desaparición de referencias a objetos destruidos),
problema crucial de las bases de datos.
Con las generaciones previas de DBMS, los desarrolladores tuvieron un nivel bajo de productividad.
Esto es en particular dado por un problema de funcionalidad entre aquellas DBMS y los lenguajes de
programación utilizados. En efecto, los tipos de datos de esas categorías de herramientas son
incompatibles, el programador debe asegurarse por si mismo de la conversión de datos entre la base de
datos y el lenguaje: Esto impone el desarrollo suplementario que hay que realizar para mantener la
consistencia de la aplicación en su ejecución.
La falta de coincidencia entre lenguajes orientados a tablas, tales como SQL, y los lenguajes comunes,
significa que se necesita un lenguaje separador para la manipulación de datos (DML), existiendo
impedimentos de acoplar estilos declarativos y basados en procedimientos entre los tipos de sistemas
del lenguaje de aplicación y de bases de datos, dando lugar a una perdida de información en la interfaz,
y obstaculizando la comprobación automática de tipos.
Para solucionar este problema los OODBMS ofrecen el concepto de completitud; que es la percepción de
escribir completamente una aplicación utilizando el DBMS como un único lenguaje (tal como los
lenguajes estándar según la norma ODMG; C++, Smalltalk o Java), sin tener que recurrir a los recursos
de los lenguajes externos. Este concepto suprime el problema de funcionalidad, ya que los datos son
manipulados de la misma manera en la base de datos que por el lenguaje de programación. En efecto,
es el mismo modelo de datos, que es soportado por el lenguaje objeto de desarrollo de la aplicación y
por el OODBMS. Los OODBMS ofrecen todo un lenguaje de programación completo integrando los
accesos a las bases de datos.
Características de las ODBMS
l Un completo modelo de bases de datos, con rasgos tales como; la manipulación fija y el acceso
de asociación.
l Un modelo orientado al objeto que respalda objetos complejos, identidad del objeto,


encapsulamiento, clases, caracteres, extensibilidad e integridad computacional.
l Un DDL (Data Definition languaje, define tipos de objetos, y además el usuario puede declarar
procedimientos y variables asociadas con los tipos de objetos) real con rasgos de manipulación de
esquemas.
l La capacidad de almacenar y manipular tanto los datos (objetos) como los metadatos (clases y
métodos) en el propio sistemas.
l Un DML (Data Manipulation Languaje, por lo general contiene un lenguaje de consultas y un
componente de lenguaje de programación ), a través de un lenguaje de consulta completo,
declarativo.
l Independencia de datos lógica y física (esto es, un DDL físico y uno lógico y la capacidad para
modificar el esquema físico sin cambiar la aplicación).
l La capacidad de manipular cantidades de datos enormes.
l La capacidad de desarrollar aplicaciones completas en un medio único.
Los Desempeños
El problema de los desempeños es esencial para los DBMS. El mercado de sistemas orientados al objeto
se desarrolla porque esos sistemas ofrecen desempeños mejorados con respecto a los sistemas
relacionales. Existen tres tipos de benchmarking ("pruebas de rendimiento") que permiten medir estos
sistemas.
l Bechmarking 001, Rubenstein et al. (1987) [7], Catell et al. (1992) [3], está orientado a
aplicaciones que tienen por objetivo describir la aplicación en cuanto a su tipo de concepción
(refiriéndose a su forma de generación, formación). Manipula los objetos complejos entre el
servidor y una estación de trabajo.
l Bechmarking de Hypermodel, fue hecho por un grupo de navegadores de conceptos en sistemas.
Se basa sobre la aplicación del tipo hipertexto y mide el tiempo de acceso a los objetos.
l Bechmarking 007, Carey et al. (1993) [2], hecho en 1992 para las limitaciones del Bechmarking
001, abarcando un gran número de operaciones, transacciones, requerimientos y el control de
versiones. El 007 denota tres diferentes tamaños:
¡ Pequeño: La base de datos en memoria principal.
¡ Mediano: La base de datos está contenida en memoria virtual y una parte en la memoria
principal.
¡ Grande: La base de datos está en memoria virtual.



Figura 5: Comparación Arquitectura OODBMS vs RDBMS, Manola (1994, pág. 3,19) [6].


Los OODBMS dominan en desempeño con respecto a los sistemas relacionales sobre las aplicaciones
manipulando objetos complejos. Esto es por una sencilla razón; que los sistemas relacionales fueron
hechos y diseñados para efectuar algunas operaciones simples (selección, proyección, etc.), y los



OODBMS tienen por finalidad manipular objetos estructurados y complejos. En cuanto a una
comparaci ón arquitectónica entre el modelo relacional y el modelo objeto aplicado a DBMS, la figura 5
muestra su correspondiente composición habitual.
Los aportes a la tecnología
Los OODBMS permiten llegar a nuevos dominios para los cuales las bases de datos tradicionales son
renuentes a ser aceptadas.
Su fuerte es en ambientes donde hay una necesidad de datos no estándar, es decir, de aquellos que
uno manipula textos estructurados o no estructurados, im ágenes, gráficos, sonidos, videos,
documentos o programas. Se trata entonces de ambientes donde la estructura de los datos es tan
compleja que representarla en un modelo tradicional es ineficaz.
Se trata de dominios o tipos de datos que al usarlos no permanecen fijos desde el inicio y son variables
en el tiempo.
Son dominios comunes, por ejemplo:
l CAD
l Gestión de datos técnicos
l Cartografía
l Multimedia.
l Sistemas distribuidos y cliente/servidor.
l Bases de datos multimedia.
l Correo por voz.
l GIS
En todos estos dominios, la tecnología de OODBMS aporta los desempeños mejores y un desarrollo más
eficaz de aplicaciones.
Los OODBMS disminuyen los costos lógicos de desarrollo.
Esta baja de costos es obtenida en opinión de connotadas figuras ligadas a DBMS (Por citar algunos:
Atkinson et al.[1], Bancilhon, Graham), por un acortamiento del ciclo de análisis, concepción,
codificación, depuración, testeo, mantenci ón y evolución. Mejoramiento obtenido por:
l La reutilización del componente l ógico.
l La disminución de código.
l La capacidad de modelamiento directo de información compleja.
l La mejor integración a los lenguajes de programación.
l Desarrollo rápido de prototipos de aplicaciones.
l Utilización de medio ambiente gráfico de desarrollo.
l Utilización de herramientas de generación de interfaz gráfica de realización.
Los OODBMS permiten producir aplicaciones gráficas de mejor calidad.
Las aplicaciones son mejoradas en dos puntos esenciales:
l Los desempeños en el caso de la manipulación de datos complejos.
l La calidad "industrial" de aplicaciones para la facilidad de mantenci ón, su capacidad de
crecimiento y posibilidad de ser personalizadas en dominios específicos.


Los OODBMS permiten recuperar y mejorar las aplicaciones existentes.
Para los sistemas que disponen de una interfaz C++ estándar, el mecanismo consiste en tomar una
aplicación existente en la cual la persistencia es asegurada por un sistema de archivos que al migrarlos
al OODBMS se reemplaza el acceso a los archivos por el almacenamiento en el OODBMS. Así, el costo
de migración es m ínimo y la aplicación es bastante mejorada. En efecto, resultando en:
l Una simplificación de código (el acceso a los objetos de la base de datos es inmediata y sin
traducción).
l La capacidad de fiabilidad y compatibilidad de los datos.
Los Mercados
1. Aplicación en Sistemas de información geográficos.
Para los sistemas de información geográficos o para toda aplicación en la cual hay una dimensión
espacial o geográfica (la cartografía de una región, la topología de una zona o el plano de un edificio),
los desarrolladores de estas aplicaciones necesitan la tecnología de objetos; ella ofrece un mayor
desarrollo y mejores desempeños.
2. Gestión de datos técnicos.
Porque permiten almacenar los datos de naturaleza variada y de tipo extensible, los OODBMS son
elegibles como sistemas de almacenamiento para este tipo de aplicaciones, que incluyen la gestión de
datos científicos experimentales, la gestión de datos asistidos por computador (CAD) y la
documentación técnica.
3. Aplicaciones Multimedia.
Para toda aplicación que manipula gráficos, imágenes, animación y voz, los OODBMS son los primeros
en la elección de los desarrolladores.

LA NORMA CORBA
CORBA es una especificación normativa que resulta de un consenso entre los miembros de la
OMG, un consorcio que agrupa hoy por hoy a más de 700 empresas tanto de la industria
informática como consumidores de la misma. Esta norma cubre cinco grandes ámbitos que
constituyen los sistemas de objetos distribuidos:
• Un lenguaje de descripción de interfaces, llamado Lenguaje de Definición de Interfaces
IDL (Interface Definition Language), traducciones de este lenguaje de especificación
IDL a lenguajes de implementación (como pueden ser C++, Java, ADA, etc.) y una
infraestructura de distribución de objetos llamada ORB (Object Request Broker) que ha
dado su nombre a la propia norma: CORBA (Common Object Request Broker
Architecture).
• Una descripción de servicios, conocidos con el nombre de Servicios CORBA
(CorbaServices), que complementan el funcionamiento básico de los objetos de que dan
lugar a una aplicación. Estas especificaciones cubren los servicios de nombrado, de
persistencia, de eventos, de transacciones, etc. El número de servicios se amplía
continuamente para añadir nuevas capacidades a los sistemas desarrollados con
CORBA.
• Una descripción de servicios orientados al desarrollo de aplicaciones finales,
estructurados sobre los objetos y servicios CORBA. Con el nombre de Facilidades
CORBA (CorbaFacilities), estas especificaciones cubren servicios de alto nivel, como
las interfaces de usuario, los documentos compuestos, la administración de sistemas y
redes, etc. La ambición es aquí bastante amplia ya que CorbaFacilities pretende definir
colecciones de objetos prefabricados para aplicaciones habituales en la empresa:
creación de documentos, administración de sistemas informáticos, etc.
• Una descripción de servicios verticales denominados Dominios CORBA
(CorbaDomains), que proveen funcionalidad de interés para usuarios finales en campos
de aplicación particulares. Por ejemplo, existen proyectos en curso en sectores como:
telecomunicaciones, finanzas, medicina, etc.
<<Título>>
¡Error! No se encuentra el origen de la referencia. 2
Figura 1. La norma CORBA
• Un protocolo genérico de intercomunicación, el Protocolo General Inter-ORB GIOP
(General Inter-ORB Protocol), que define los mensajes y el empaquetado de los datos
que se transmiten entre los objetos. Además define implementaciones, de ese protocolo
genérico, sobre diferentes protocolos de transporte, lo que permite la comunicación
entre los diferentes ORBs consiguiendo la interoperabilidad de elementos de diferentes
vendedores. Por ejemplo el IIOP para redes con la capa de transporte TCP.
Figura 2. GIOP
<<Autores>>
3 ¡Error! No se encuentra el origen de la referencia.
1.2. ESTRUCTURA
ORB (Object Request Broker) es el sistema intermedio (middleware) que establece relaciones
cliente/servidor entre objetos. Mediante la utilización un de ORB, un cliente puede invocar
transparentemente un método de un objeto servidor que se encuentre en la misma máquina o en
otra distinta. El ORB intercepta la llamada realizada por el objeto que implementa la petición,
pasa los parámetros, invoca el método y retorna los resultados. No es necesario que el cliente
sepa dónde se localiza el objeto que ejecutará el método, el lenguaje en el que está programado,
el sistema operativo, ni cualquier otro aspecto que no sea su interfaz. Hay que resaltar que los
papeles de cliente y servidor que se dan a los objetos son simplemente para coordinar las
interacciones entre ambos; estos papeles pueden cambiar ya que un objeto puede ser cliente o
servidor dependiendo de la ocasión.
En la figura siguiente se muestra un la estructura de un sistema distribuido basado en
CORBA. En él se puede observar dos partes: una cliente y una servidora. En la parte cliente
existirá un programa cliente propiamente dicho al que CORBA le añade cierta infraestructura
para permitir la comunicación con el servidor a través de la red. Del otro lado, la parte servidora
estará formada por el objeto que exporta su funcionalidad, integrado en el servidor (proceso en
el que se ejecuta) y diversos elementos que permiten que las invocaciones realizadas por el
cliente a los métodos del objeto lleguen a éste, sean procesadas y sus resultados devueltos.
Figura 3. Estructura CORBA
<<Título>>
¡Error! No se encuentra el origen de la referencia. 4
La parte cliente estará formada por:
• Los Stubs del Cliente
Proporcionan una capa intermedia entre el cliente y el núcleo del ORB. Definen
cómo los clientes invocan los servicios que proporcionan los objetos servidores. Desde
la perspectiva del cliente, el stub actúa como una especie de proxy, dando la impresión
de que la invocación se está realizando sobre un objeto local como en cualquier
aplicación orientada a objetos. El stub se encarga de codificar la operación y sus
parámetros, y de enviarla de forma remota.
• La interfaz de invocación dinámica
Permite descubrir en tiempo de ejecución métodos para ser invocados. CORBA
define una biblioteca, que permite localizar el método, generar los parámetros, realizar
la llamada remota y recoger los resultados.
• El almacén de interfaces
Permite obtener y modificar la descripción de todos los componentes que en él
están registrados, los métodos que soporta y los parámetros que requiere. CORBA llama
a esas descripciones firmas. El almacén de interfaces (Interface Repository) es una base
de datos distribuida modificable en tiempo de ejecución.
• La interfaz del ORB
Consiste en unas pocas librerías de servicios locales para realizar labores
auxiliares en la aplicación. Por ejemplo, CORBA proporciona APIs (Aplication
Programming Interface) para convertir referencias a objetos a cadenas. Estas llamadas
pueden ser muy interesantes si se necesita comunicar o almacenar referencias a objetos.
La capacidad de soportar tanto invocaciones dinámicas como estáticas, además
del almacén de interfaces, da a CORBA una gran ventaja sobre las plataformas
intermedias competidoras. Las invocaciones estáticas son rápidas y fáciles de
programar. Las invocaciones dinámicas proporcionan la máxima flexibilidad, pero son
difíciles de programar. Esta últimas son muy usadas por herramientas que descubren
servicios en tiempo de ejecución.
<<Autores>>
5 ¡Error! No se encuentra el origen de la referencia.
Por lo que respecta al lado del servidor no hay diferencia entre la invocación
dinámica y estática, ya que ambas tienen el mismo mensaje semánticamente hablando.
En los dos casos el ORB localiza al Adaptador de Objetos del objeto y le transmite un
mensaje que contiene el nombre del servicio a invocar y sus parámetros. La
implementación recibe a través del esqueleto del objeto los datos necesarios, ejecuta el
servicio y retorna el resultado para que sea enviado al cliente en forma de un nuevo
mensaje.
Los elementos que componen la parte servidora son los siguientes:
• El esqueleto del servidor
Proporciona los elementos necesarios para que los clientes invoquen los
servicios exportados por el objeto. Estos esqueletos realizan una función similar a los
stubs del cliente tratando de hacer transparente todo el proceso de comunicación.
• El esqueleto de interfaces dinámicos (DSI)
Proporciona un mecanismo de enlazado en tiempo de ejecución para servidores
que necesitan manejar llamadas a métodos que no tienen esqueletos estáticos definidos.
• El adaptador de objetos
Proporciona en tiempo de ejecución un entorno para la instanciación de objetos
en el servidor (proceso que los acoge), la asignación de referencias y la gestión las
peticiones que les lleguen.
• El almacén de implementaciones
Proporciona en tiempo de ejecución un almacén de información acerca de las
clases que el servidor soporta, los objetos instanciados y sus identificadores.
• La interfaz del ORB
Consiste en unas pocas APIs de servicios locales iguales a las de la parte
cliente.
<<Título>>
¡Error! No se encuentra el origen de la referencia. 6
1.3. VENTAJAS
Algunas de las ventajas que tiene son:
• Se encarga de organizar los servicios que se pueden encontrar en la red a través de las
interfaces IDL.
• Es independiente de la plataforma y del lenguaje de desarrollo lo que facilita el
desarrollo en entornos heterogéneos.
• Gestiona las comunicaciones, informando a clientes y servidores de caídas de los
canales de comunicación.
• Facilita la integración de software heredado. Tan sólo hay que definir las interfaces IDL
de este software para ponerlo disponible en CORBA.
• Proporciona servicios adicionales para, por ejemplo, encontrar objetos y servicios
dentro de entornos distribuidos, llegando incluso a definir entornos de trabajo CORBA
para diferentes disciplinas: telecomunicación, medicina, ...