CORBA. Carpe Diem Quam Minimum Credula Postero. Manual de CORBA (Common Object Request Broker Architecture)

Transcripción

1 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

2 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 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 es el proyecto de middleware más importante y ambicioso emprendido por la industria hasta el momento. 1

3 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 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. 2 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

4 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 (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. 3

5 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. 4

6 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. 5

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

8 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 7 Esto genera un carpeta con diversos archivos, con el esqueleto de la app, stub, helper, etc.

9 By: John Michel Rivera de León 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); 8

10 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++; 9

11 By: John Michel Rivera de León 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: 10

12 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 Este crea un ID del sistema y le establecimos que se comunicara por el puerto Ahora iniciamos el servidor en otro CMD con al instrucción: java Server -ORBInitialHost localhost -ORBInitialPort

13 By: John Michel Rivera de León 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 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. 12

14 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. 13

15 By: John Michel Rivera de León 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 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.