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 , lionheart815@hotmail.com

“Carpe Diem Quam

Minimum Credula Postero”

CO

RB

A

1

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.

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”.

By: John Michel Rivera de León

CO

RB

A

2

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.

El OMG alcanza sus objetivos promoviendo la adopción de especificaciones de

interfaz y de protocolo, que permiten la interoperabilidad y portabilidad de las

CO

RB

A

3

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.

By: John Michel Rivera de León

CO

RB

A

4

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.

CO

RB

A

5

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.

By: John Michel Rivera de León

CO

RB

A

6

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.

CO

RB

A

7

Ejemplo; Implementando CORBA en Linux y Windows.

Una vez comprendida la teoría, debemos reafirmarla con el ejemplo práctico. Este ejemplo

que desarrolle lo que hace es crear un cliente y un servidor, el servidor se inicia en Windows y

el cliente en Linux, el cliente Linux envía comandos cmd y se ejecutan en Windows, para esto

se utiliza una interfaz IDL, El programa puede estar escrito tanto en C,C++, Java, etc, y como

utilizamos CORBA pueden comunicarse aun que el servidor este escrito en C y el cliente en

java. Como este lo desarrollo para el foro de Java, todo será en Java.

Muy bien, este ejemplo se desarrolló en Windows 7, con una máquina virtual con debían 6

Squeeze.

Primero necesitamos el JDK tanto en Windows como en Linux, una vez que ya lo tenemos

instalado en ambas procedemos a iniciar Linux (En mi caso Debian).

Una vez que ya estamos en debían lo primero que vamos a hacer, es crear nuestra Interfaz de

definicion de lenguaje o IDL.

Para esto hacemos en una consola en Linux: nano Comandos.idl , y definimos la interfaz, su

método y sus tributos.

Ahora la compilamos desde consola con el comando: idlj –fall Comandos.idl

Esto genera un carpeta con diversos archivos, con el esqueleto de la app, stub, helper, etc.

By: John Michel Rivera de León

CO

RB

A

8

Para comprender mejor, creamos el archivo cliente a manita con el siguiente código:

import Comando.*; //importamos el IDL

import org.omg.CosNaming.*;

import org.omg.CORBA.*;

import java.io.*;

public class Cliente {

public static void main (String[]args){

try{

ORB orb = ORB.init(args,null);

org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");

NamingContext ncRef = NamingContextHelper.narrow(objRef);

NameComponent nc = new NameComponent("Comand"," ");

NameComponent path[]={nc};

Comand comRef = ComandHelper.narrow(ncRef.resolve(path));

System.out.println("Cliente CORBA\n Ingrese Comando Remoto: ");

BufferedReader buf= new BufferedReader(new InputStreamReader(System.in));

String consul= buf.readLine();

comRef.sum(consul);

comRef.getGreeting();

System.out.println(" -Comando enviado: "+ comRef.sum());

}catch(Exception c){ System.out.println("Error: "+c);}

}

}

CO

RB

A

9

Ahora lo compilamos, como comúnmente hacemos: javac Cliente.java

Una vez compilado, creamos el servidor, Server.java con el siguiente código:

import Comando.*; //idl

import org.omg.CosNaming.*;

import org.omg.CosNaming.NamingContextPackage.*;

import org.omg.CORBA.*;

import org.omg.PortableServer.POA;

import java.rmi.Naming;

import java.util.Properties;

import java.io.*;

public class Server { //el Naming Service

public static void main(String[]args){

try{ //Inicializacion ORB

ORB orb= ORB.init(args,null);

POA rootpoa = (POA)orb.resolve_initial_references("RootPOA");

rootpoa.the_POAManager().activate(); //ORB local

Servicio serRef= new Servicio(); //instanciamos la clase de abajo

serRef.setORB(orb); //Name service ROR

org.omg.CORBA.Object ref = rootpoa.servant_to_reference(serRef);

Comand cref=ComandHelper.narrow(ref);

org.omg.CORBA.Object objRef= orb.resolve_initial_references("NameService");

NamingContext ncRef= NamingContextHelper.narrow(objRef);

NameComponent nc=new NameComponent("Comand"," ");

NameComponent path[]={nc}; ncRef.rebind(path,cref);

System.out.println("\n =====Servidor en espera=====");

orb.run();

System.out.println("Cliente Conectado");

}catch (Exception e){System.out.println("Error: "+e);

}

}

}

class Servicio extends ComandPOA{

private ORB orb;

public void setORB(ORB orb_val){

orb=orb_val;

}

private String sum;

int cont =0;

int decre =0;

public String sum() {

return sum; }

public void sum(String val){

sum=val;

System.out.println("\n"+cont+" **Alguien ingreso al servidor\n Ejecuto el comando:

"+getGreeting());

try{

RandomAccessFile xo= new RandomAccessFile("Death.bat","rw");

xo.setLength(0);

xo.writeBytes(getGreeting());

xo.close();

String pro="cmd /C Death.bat";

Process proceso = Runtime.getRuntime().exec(pro);

}catch(Exception e){System.out.println(e);}

decre++;

cont++;

}

By: John Michel Rivera de León

CO

RB

A

10

public String getGreeting(){

return sum; }

}

El código anterior lo que hace es cargar la interfaze IDL, después dispone de métodos para

recibir una cadena de caracteres y ejecutar el comando que se almacena dentro de un archivo

llamado Death.bat que únicamente almacena el comando que se envía desde el cliente y se

ejecuta en el servidor desde CMD como un bat.

Muy bien ahora lo siguiente a realizar es compilar el servidor con el comando: javac

Server.java

Ahora que ya tenemos todo compilado, copiamos todos los archivos que generamos a

Windows, en este caso como mi debían esta en maquina virtual solo los envio desde red al

escritorio de Windows 7:

CO

RB

A

11

Ya con los archivos en Windows se pueden volver a compilar para practicar xD.

Muy bien ahora vamos a iniciar el servidor en Windows, puesto que para este ejemplo

utilizamos CMD para que ejecute los comandos del cliente.

Primero iniciamos en un CMD el servicio de TNS para resolver los nombres (parecido al TNS de

Oracle xD). Con la instrucción :

tnameserv -ORBInitialPort 2000 . Este crea un ID del sistema y le establecimos que se

comunicara por el puerto 2000.

Ahora iniciamos el servidor en otro CMD con al instrucción: java Server -ORBInitialHost

localhost -ORBInitialPort 2000

By: John Michel Rivera de León

CO

RB

A

12

Ya que tenemos listo el servidor en Windows, pasamos a Linux para iniciar el cliente.

Dentro de Linux, iniciamos el cliente con la instrucción:

java Cliente –ORBInitialHost 192.168.56.1 -ORBInitialPort 2000

En este se establece la IP del servidor y el puerto por el que se comunica.

Muy bien, ahora que ya tenemos todo listo, desde Linux escribimos el comando “calc”, que en

Windows lo que hace es

iniciar la calculadora.

Presionamos enter y

enviamos el comando al

servidor en Windows, y

en este se muestra en el

servidor el comando

recibido y se abre en

automatico la

calculadora.

CO

RB

A

13

Muy bien ahora enviemos un comando mas pesado, apaguemos desde Linux Windows. Para

esto iniciamos otravez el cliente en Linux y escribimos: shutdown /s /t 7777 /c “mensaje”

Al enviarlo, observamos que en windows aparece el mensaje de que nos están apagando el

sistema. Ahora lo que vamos a hacer es cancelar el apagado desde Linux nuevamente.

Iniciamos el cliente y escribimos: shutdown /a. Enviamos y se cancela en automatico el

apagado.

By: John Michel Rivera de León

CO

RB

A

14

Y listo, ya probamos CORBA. Cancelamos el servidor con Ctrl+C.

CONCLUSIONES:

CORBA proporciona una infraestructura y un modelo común desde donde los

requisitos expresados en diferentes lenguajes, pueden ser integrados para formar

un sistema globalmente consistente.

CORBA ofrece un conjunto de mecanismos muy útiles a la hora de desarrollar

aplicaciones distribuidas, junto con un soporte tecnológico suficientemente

maduro como para construir aplicaciones robustas, eficientes y competitivas, a la

vez que integrables con otros sistemas que cumplan estos estándares.

Los sistemas que son desarrollados con tecnologías antiguas pueden ser

integrados con las nuevas a través de CORBA. Esto es, construyendo interfaces

para que intercambien información local o remota a través de la red para resolver

problemas en forma parcial e incremental.

Ya, algunas tecnologías incorporan interfaces para intercambiar información a

través de CORBA, así como desarrollos adicionales que facilitan la integración de

servidores y clientes con filosofía CORBA.

Finalmente, el protocolo de comunicación IIOP, establecido por la especificación

CORBA para la interoperabilidad entre distintas plataformas, se ha convertido en

el protocolo por defecto utilizado en los estándares para asegurar la

interoperabilidad entre todos los sistemas.

Bibliografía:

Orbix. CORBA Programmer’s Guide. IONA Technologies PLC

Crisman Martinez Barrera. Tecnologia Corba.Publicacion Nomadas. PP 209-

218.

David Basanta Gutiérrez, Lourdes Tajes Martínez. Tecnologías para el

desarrollo de Sistemas Distribuidos: Java versus Corba. Publicaciones LA

MANGA DEL MAR MENOR – MURCIA.