PDF de programación - Manual de CORBA

CORBA

Manual de CORBA (Common Object Request Broker Architecture)

La arquitectura común de intermediarios en peticiones a objetos (CORBA) es una
arquitectura de comunicaciones entre sistemas heterogéneos que soporta construcción e
integración de tecnologías de diferente fabricante. Puede agrupar antiguas y nuevas
aplicaciones de software. Lo que conocemos como Middleware.
By: John Michel Rivera de León , [email protected]



“Carpe Diem Quam

Minimum Credula Postero”





CORBA

Manual de CORBA (Common Object Request
Broker Architecture)

Actualmente las telecomunicaciones son uno de los
sectores más activos y con tasa más alta de crecimiento,
principalmente en los países desarrollados.

El software tiene un nuevo enfoque: el desarrollo de
componentes, que depende de la capacidad de integración
para comunicarse entre ellos según las interfaces
estandarizadas.

Las especificaciones de estandarización son descritas por
CORBA, que permite el desarrollo de programas de
software fácilmente expansibles, reemplazables y que es el
inicio para “conectar todo lo que hay en el mundo a
Internet ”, sin poner en riesgo la funcionalidad de los
elementos y las aplicaciones en su totalidad.

“CORBA es el proyecto de middleware más importante y
ambicioso emprendido por la industria hasta el momento”.



CORBA Manual
Introductorio

Dentro de este manual,

usted conocera la

tecnología CORBA,

además se mostrara un

ejemplo implementado

de comunicación con

CORBA entre Linux

Debian y Windows 7.



A
B


R
O
C



1

By: John Michel Rivera de León

CORBA

CORBA (Common Object Request Broker Architecture — arquitectura común de
intermediarios en peticiones a objetos), es la arquitectura estándar de OMG para
procesamiento distribuido.

CORBA es una arquitectura de comunicaciones entre sistemas heterogéneos que
soporta construcción e integración de tecnologías de diferente fabricante. Puede
agrupar antiguas y nuevas aplicaciones de software.

Está basada en un gestor de peticiones a objetos comunes y permite
interoperabilidad entre aplicaciones en máquinas remotas en un entorno
distribuido. Es una plataforma que tiene funcionalidad de sistema abierto y que
requiere para cada lenguaje soportado una interfaz estandarizada entre CORBA y
la herramienta de programación.

CORBA esta definida por el OMG (Object Management Group) para la creación y
uso de objetos remotos, cuyo objetivo es proporcionar interoperabilidad entre
aplicaciones en un entorno distribuido y heterogéneo. Es conocido como un tipo
de “middleware”, ya que no efectúa las funciones de bajo nivel necesarias para ser
considerado un sistema operativo.

OMG

El OMG es un consorcio internacional sin ánimo de lucro establecido en 1989. Su
objetivo es, ayudar a reducir la complejidad, disminuir los costes y acelerar la
introducción de nuevas aplicaciones software, promoviendo la teoría y la práctica
de la tecnología de objetos en los sistemas distribuidos.

Originalmente estaba formada por 13 compañías, pero los miembros del OMG
han crecido progresivamente y en la actualidad es el consorcio de software más
grande del mundo, compuesto por más de 760 vendedores, programadores y
usuarios. De hecho todas las grandes compañías de software interesadas en el
desarrollo orientado a objetos distribuidos son miembros del OMG.



A
B
R
O
C



2

El OMG alcanza sus objetivos promoviendo la adopción de especificaciones de
interfaz y de protocolo, que permiten la interoperabilidad y portabilidad de las





aplicaciones orientadas a objetos distribuidos. En este consorcio no se producen
guías de cómo implementar o producir software, sólo especificaciones.



CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar las
interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a
partir de este IDL, la interfaz a un lenguaje determinado, describiendo cómo los
tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y
del servidor.


IDL (Interface Definition Language)

Para poder especificar los servicios que ofrecen los objetos que forman parte de
un sistema abierto y distribuido, se necesita contar con algún lenguaje preciso,
bien definido, e independiente de cualquier posible representación de los datos o
estructuras que él define, así como la futura implementación de los objetos que
especifica. La norma ISO/IEC 14750 (ITUT X.920) define dicho lenguaje, al que se
conoce como lenguaje de definición de interfaces de ODP, o ODP IDL por su
acrónimo en inglés.

Su principal objetivo es describir la signatura de los objetos que especifica, en
términos de las estructuras de datos que se manejan y el perfil de las operaciones
que definen sus servicios. De esta forma se consigue la ocultación necesaria para
el desarrollo de aplicaciones abiertas .

En IDL, una interfaz es una descripción de un conjunto de posibles operaciones
que un cliente puede solicitar de un objeto. El objeto satisface una interfaz si este
puede satisfacer una solicitud de otro objeto. La interfaz provee mecanismos
compuestos que le permiten a tal objeto soportar múltiples interfaces.

Las operaciones que se realizan denotan servicios que pueden ser atendidos y
ejecutados para cambiar de valor y adquirir un valor. Una operación es reconocida
por un identificador de operación. Una operación no es un valor.



A
B


R
O
C



3

By: John Michel Rivera de León

Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el
implementador del objeto). El código del cliente sirve para poder realizar las
llamadas a métodos remotos. Es conocido como stub, el cual incluye un proxy
(representante) del objeto remoto en el lado del cliente. El código generado para
el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que
rellenar para implementar los métodos del objeto.

Stub

Es el intermediario entre el cliente y el ORB . El Stub recoge del cliente llamadas a
métodos y las transmite al ORB. Se requiere una clase de stub por cada clase
remota.

Además, es un componente que actúa como servidor, puede estar ejecutándose
en cualquier máquina conectada a la red que recibe peticiones por parte de
clientes que pueden ser locales o remotos. Indistintamente de ello, el cliente
siempre tendrá la ilusión de que la llamada se ejecuta localmente. En otras
palabras el stub logra que el programador no se ocupe de las instrucciones de
programación remotas ya que son objetos que residen en el cliente y que
representan objetos
remotos instalados en un servidor.


Los ORBs

Los ORBs, Object Request Brokers, núcleo de cualquier implementación CORBA,
ransmiten los mensajes que se intercambian cliente y servidor, para lo que se
ocupan de:

1. Canalizar las comunicaciones entre los objetos locales y los remotos.
2. Empaquetar los parámetros que el cliente pasa al método remoto y el resultado
que el método devuelve al cliente.
3. Localizar al objeto remoto a partir de una referencia.



A
B
R
O
C



4



Esqueleto

Es el intermediario entre ORB y los objetos del servidor. Recibe llamadas del ORB y
ejecuta los métodos correspondientes en el servidor sobre el objeto que
corresponda. Cuando el cliente establece un objeto local (con servicio remoto), la
petición se realiza por intermedio del protocolo de comunicaciones IIOP a través
del ORB. El servidor recibe la petición, busca el objeto definido (compara el
esqueleto del método en el módulo esqueleto) lo ejecuta y retorna la respuesta al
cliente .


Ventajas


1) Disponibilidad y Versatilidad: Muchas arquitecturas y sistemas operativos
cuentan
con una implementación de CORBA, lo que hace suponer que se puede usar
CORBA en virtualmente cualquier proyecto de sistemas distribuidos.

2) Eficiencia: La libertad de desarrollo ha favorecido la existencia de una pléyade
de implementaciones del estándar que se adaptan a multitud de posibles
necesidades de los
usuarios, generando una competencia que favorece aquellas implementaciones
de mayor calidad y con más características.

3) Adaptación a Lenguajes de programación: Además, es posible emplear los
servicios de CORBA desde cualquier lenguaje de programación, desde C++, C ó
Java, hasta COBOL ó Ada.


Desventajas

El problema fundamental de los sistemas de integración es el software. Aún no
existe mucha experiencia en el diseño, implantación y uso de software como
CORBA. Precisamente, éste es un campo de investigación actual.
Las redes son indispensables para la comunicación entre máquinas; sin embargo,
pueden plantear problemas de saturación, embotellamiento, interrupción o
pérdidas de mensajes.



A
B


R
O
C



5

By: John Michel Rivera de León

El posible acceso a todo el sistema por parte de los usuarios plantea el
inconveniente de la necesidad de un sistema de seguridad adecuado y estándar,
aunque CORBA maneja la seguridad.


El IIOP: Interoperabilidad entre ORB.

CORBA es neutral respecto al protocolo de red utilizado para comunicar cliente y
servidor. Para ello especifica el GIOP (General Inter ORB Protocol) que define a
muy alto nivel la comunicación entre ORBs diferentes. Para redes de tipo TCP/IP
se emplea una instancia de GIOP conocida como IIOP (Internet Inter ORB
Protocol). Gracias a IIOP, es posible que objetos que emplean ORBs de fabricantes
distintos puedan interoperar en redes como Internet.



A
B
R
O
C



6



Ejemplo; Implementando CORBA en Linu