CORBA

Common Request Architecture Object Broker

CORB A

CORB A

INTRODUCCIN
Marco Histrico
En los aos 70, la computacin estaba presidida por los sistemas de tiempo compartido, los cuales pudieron llevarse a cabo gracias al uso de la multitarea. Estos sistemas permitan que multitud de usuarios pudieran interactuar simultneamente en una misma computadora desde las famosas terminales bobas, que no fueran ni ms ni menos que una pantalla con un teclado conectado a la computadora central, la cual era la nica que posea poder de procesamiento. Sin embargo, con el paso del tiempo, este escenario fue cambiando de rumbo, debido principalmente a dos causas: Por un lado, el desarrollo de los microprocesadores permitieron reducir el costo y el tamao de las computadoras, y a su vez aumentaron su capacidad de procesamiento, dando lugar a que el consumo de estas maquinas pudiera hacerse en forma masiva; Por otro lado, el -desarrollo de las redes informticas y las telecomunicaciones permitieron la transferencia de datos a gran velocidad, como as tambin la interconexin de mas computadoras sin importar su ubicacin fsica. En este contexto, en los aos 80, la informtica comienza a descentralizarse dando lugar a los sistemas distribuidos. Un sistema distribuido es un conjunto de procesadores interconectados por medio de una red de interconexin que no poseen una memoria ni un reloj comn. Si bien su nacimiento surge en los aos 80, es recin en los aos 90 donde se produce el verdadero auge de los sistemas distribuidos, debido principalmente al desarrollo de internet. Surgieron distintas propuestas para llevar adelante esta idea. Entre las principales podemos encontrar: DCOM (Microsoft) Java RMI Corba (OMG) A lo largo del presente trabajo nos centraremos en Corba.

CORB A Qu es Corba?

Definimos a CORBA (Common Object Request Broker Architecture Arquitectura Comn de Intermediarios en Peticiones a Objetos) como un Middleware que permite a los componentes de una red interoperar en un entorno distribuido sin importar la tecnologa que cada uno utilice. Esta definicin merece algunas explicaciones: El hecho de que Corba sea un Middleware implica que se trata de una capa de software independiente del hardware y del sistema operativo que posee cada maquina, que ofrece servicios y protocolos estandarizados para facilitar la construccin de un sistema distribuido. En este sentido, un Middleware se encuentra por encima del sistema operativo y del software de red, y por debajo de las aplicaciones de los usuarios finales. Al hablar de la tecnologa de cada mquina, no solo hacemos referencia a los elementos hardware, tales como el microprocesador, sino tambin a elementos software, como es el caso del sistema operativo o del lenguaje de programacin utilizado para desarrollar los procesos. Corba es un estndar propuesto por OMG (Object Management Group Grupo de Gestin de Objetos). OMG, fundado en 1989, es el consorcio de empresas ms grande de la actualidad, ya que cuenta con ms de 700 compaas como miembros del grupo, tales como HP, Apple, IBM, Sun Microsystems y Microsoft, entre otros. Se trata de una organizacin no comercial sin fines de lucro, y su objetivo no es desarrollar software, sino producir especificaciones que sirvan como estndares de tecnologas orientadas a objetos.

Ventajas de utilizar CORBA

Heterogeneidad Un sistema heterogneo consiste conjuntos de elementos de hardware y software de distintos fabricantes (que posiblemente utilicen distinta tecnologa) interconectados entre si. Un ejemplo prctico de esta ventaja seria la integracin de antiguos sistemas empresariales de gestin, cuya actualizacin es muy costosa, no solo en dinero sino tambin en capacitacin de personal, con nuevas tecnologas, de forma tal que ambos puedan convivir en un mismo sistema. Movilidad Con el fin de equilibrar la carga en el sistema, los procesos pueden migrar de una computadora a otra, garantizando de esta manera el rendimiento global del sistema.

CORB A

Al ser una especificacin de la OMG, la misma es pblica y gratuita. Esto quiere decir que cualquier fabricante puede desarrollar software basndose en las especificaciones de CORBA. Gracias a la especificacin CORBA 2.0, existe interoperabilidad entre implementaciones CORBA de distintos fabricantes.

Desventajas de utilizar Corba

Burocracia Las especificaciones tardan en desarrollarse debido a que estan sujetos a demasiados pasos de burocracia, y en consecuencia las implementaciones tardan en salir al mercado. Complejidad A pesar de que existen capas de abstraccin que facilitan el desarrollo de las aplicaciones, CORBA es una plataforma de desarrollo muy compleja.

CORB A

Comparacin entre Ole, Corba y Java

JavaSoft, filial de Sun Microsystems Java RMI Pginas Web (HTML) Applets

Origen

Microsoft COM/DCOM Linking Embedding Compound Document Activex components and

OMG IIOP IDL / ORB OpenDoc

Arquitectura

Interfaces

Lenguaje

Infraestructur a Comunicacin entre objetos

Definidas en IDL Iunknown impuesto por los desarrolladores Otras interfaces definidas por Unidad de Microsoft para los herencia servicios No hay herencia, pero si agregacin y composicin Objetos sobre todo en C ++ Objetos en C, C+ Ensamblado en C + +, Smalltalk, Ada y +, Visual Basic, VBA, otros VBScript Proxy (cliente) Stub (cliente) Skeleton Stub (servidor) (servidor) DCOM encima de IIOP o protocolos DCE especficos ESIOP

Definidas en Java por el programador Herencia (extends) e implementacin (implements)

Objetos en ensamblado JavaScript Proxy Remote object JDBC

Java en

CORB A

Arquitectura CORBA
Revisin de CORBA
La especificacin CORBA detalla las interfaces y caractersticas del componente ORB de la OMA. La ltima actualizacin hasta el momento es CORBA 2.2. En la Figura 2, se muestra la arquitectura CORBA y como se relacionan sus distintos componentes.

Figura 2: Arquitectura de CORBA. Como se ve en la figura numero 3, CORBA se compone de cinco componentes principales:

ORB ncleo IDL (Lenguaje de Definicin de Interfaz) DII (Interfaz de Invocacin Dinmica) Interfaz UAB Adaptadores de objetos

CORB A

La arquitectura CORBA est orientada a objetos. Los objetos CORBA presentan muchas caractersticas de otros sistemas orientados a objetos, incluyendo la herencia de interfaces y el polimorfismo. Lo que hace a CORBA ms interesante es que proporciona estas capacidades, incluso cuando es utilizado en lenguajes no orientados a objeto como C o COBOL, aunque CORBA trabaja particularmente bien con los lenguajes orientados a objeto como C++ y Java.

Misin del ORB

Una parte fundamental de la arquitectura CORBA es el ORB, componente software cuyo fin es facilitar la comunicacin entre objetos. El ORB se encarga de enviar las peticiones a los objetos y retornar las respuestas a los clientes que invocan las peticiones. Un ORB debe proporcionar los 5 servicios siguientes:

Una interfaz de invocacin dinmica o DII (dynamic invocation interface) para que la aplicacin cliente construya dinmicamente los mensajes. Una interfaz skeletons dinmica o DSI (dynamic skeleton interface) para que la aplicacin servidor responda mensajes construidos dinmicamente. Un repositorio de interfaces o IR (interfaces repository) Una interfaz de programacin para el propio ORB Una implementacin de BOA (Basic Objetc Adapter)

El programa cliente utiliza los servicios de invocacin dinmica o los del Stub generado a partir del fuente IDL, as como los servicios del propio ORB. La implementacin del objeto en el lado servidor llama a los servicios DSI, al BOA, al skeletons esttico generado a partir de la fuente IDL y a los servicios del ORB. El ORB llama al repositorio de interfaces especificado por la norma y a un

CORB A
repositorio correspondiente de implementacin dejado a eleccin desarrolladores.

de los

La principal caracterstica del ORB es la transparencia, cmo facilita la comunicacin cliente/servidor. Generalmente, el ORB oculta lo siguiente: Ubicacin de los objetos. El cliente no sabe dnde se encuentra el objeto destino. Puede residir en un proceso diferente en otra mquina a travs de la red, o dentro del mismo proceso Implementacin de los objetos. El cliente no sabe cmo esta implementado el objeto remoto, en qu lenguaje de programacin o de scripts est escrito, o el sistema operativo y el hardware, sobre el que se ejecuta. Estado de ejecucin del objeto. Cuando el cliente lanza una peticin sobre un objeto remoto, no necesita saber si el objeto est en ese momento en ejecucin, y listo para aceptar peticiones. El ORB de forma transparente inicializa el objeto en caso de ser necesario, antes de enviarle la peticin Mecanismos de comunicacin de los objetos . El cliente no sabe qu mecanismos de comunicacin (por ejemplo, TCP/IP, memoria compartida, llamada a mtodo local) utiliza el ORB para enviar la peticin al objeto y retorna la respuesta al cliente. Estas caractersticas del ORB permiten a los desarrolladores de aplicaciones preocuparse ms por las cuestiones propias del dominio de sus aplicaciones y desentenderse de las cuestiones de programacin a bajo nivel del sistema distribuido. La idea de un ORB es que cuando un componente de aplicacin quiere utilizar un servicio proporcionado por otro componente, primero debe obtener una referencia para el objeto que proporciona ese servicio. Despus de obtenerla, el componente puede llamar a los mtodos en ese objeto, accediendo as a los servicios proporcionados por ste; evidentemente el programador del componente cliente debe saber en tiempo de compilacin que mtodos estn disponibles por un objeto servidor particular. La principal responsabilidad de ORB es resolver las peticiones por las referencias a objetos, posibilitando a los componentes de aplicacin establecer conectividad entre ellos. Cuando se crea un objeto CORBA tambin se crea una referencia para l. Cuando es utilizada por un cliente, la referencia siempre -durante toda la vida del objeto- se refiere a dicho objeto para la que fue creada. En otras palabras, la referencia a un objeto siempre hace referencia a un nico objeto. Las referencias a objetos son inmutables , de esta forma un cliente no puede manipular una referencia y modificarla. Las referencias a objetos pueden tener un formato estndar o propietario. Los clientes pueden obtener las referencias a objetos de muy diversas formas: En la creacin de objetos. El cliente puede crear un nuevo objeto y conseguir as una referencia al objeto.

CORB A

10

A travs del servicio de directorio. El cliente puede invocar a un servicio de bsqueda de cualquier tipo, con el fin de obtener referencias a objetos. Estos servicios no crean nuevos objetos, sino que almacenan referencias a objetos e informacin asociada (por ejemplo, nombres y propiedades) para los objetos existentes, y los proporcionan previa solicitud. Convirtiendo la referencia al objeto en una cadena y recuperndola. Una aplicacin puede solicitar al ORB que convierta una referencia a un objeto en una cadena, y esta cadena almacenarla en un fichero o base de datos. Ms tarde, la cadena puede ser recuperada y transformada nuevamente en una referencia a un objeto por el ORB.

El ORB peticin dinmica

La interfaz de invocacin dinmica (DII) permite al cliente enviar una peticin hacia otro objeto de la red, generalmente a objetos para los que el cliente no tiene Stub. La especificacin DII describe dos modos de invocacin dinmica, un modo sncrono, en el que el cliente se bloquea en espera de la respuesta del servidor un modo asncrono, en el que el cliente no espera la respuesta del servidor y puede pedirla mas tarde.

El servidor no establece diferencias entre las invocaciones estticas, que utilizan el Stub del lado del cliente y las invocaciones dinmicas que no lo utilizan. En una invocacin esttica, el programa cliente utiliza el Stub generado a partir del fuente IDL para enviar las peticiones al objeto remoto. En la invocacin dinmica, el programa cliente construye dinmicamente una peticin sin utilizar el Stub. El ORB no traza distincin entre los dos mecanismos. El cliente es entonces completamente dinmico, descubriendo en la ejecucin los servicios disponibles mediante el ORB al que esta conectado. El ORB define la operacin get_interface que devuelve una referencia utilizada mas adelante para extraer del repositorio de interfaces la informacin necesaria para la construccin de la invocacin dinmica. La norma DII especifica una operacin create_request para construir una peticin a partir de esta informacin. Al ser la peticin en forma dinmica, en el request se encuentra toda la informacin que se incluira en el Stub del cliente. La peticin se enva de manera sincrona con la operacin invoke o de manera asincrona con la operacin send, que pasa inmediatamente el control al programa cliente. En el caso de send el cliente puede preguntar por el estado de la operacin por medio de get_response. Cuando se recibe un resultado positivo, significa que se puede utilizar el resultado de la operacin, o que ha tenido lugar una

CORB A

11

excepcin de la que el cliente es informado. Toda esta secuencia de operaciones conlleva al mismo resultado que una invocacin esttica. Esto permite independencia ante los cambios de implementacin o de localizacin del lado del cliente, en relacin con la programacin. La aplicacin cliente utiliza las interfaces de los servicios del ORB para conectarse a este e indicar, mediante los naming services, que repositorios de interfaces considera utilizar. Estas interfaces definen tambin las operaciones que se validan para todos los objetos adems de sus definiciones en IDL. Una ultima interfaz permite convertir las referencias a los objetos en cadenas de caracteres y viceversa. Antes de enviar un mensaje cualquiera, el ORB debe inicializarse mediante la operacin Orb_init definida en el modulo CORBA de la norma Corba. Esta inicializacion puede hacerse varias veces y devuelve los mismos resultados si se utilizan los mismos parametros. Esta propiedad permite a una aplicacin multithread utilizar el mismo ORB desde varios threads distintos, o implementar un ORB como una biblioteca. Desde el lado del servidor, el Object Adapter debe mantener la ilusin en el cliente que el objeto que este invoca esta siempre activo, presto a responder sus peticiones. Define tambin la interfaz entre el servidor y el ORB. En una red dinmica, los servidores pueden ser activos o inactivos, y cada servidor puede implementar uno o varios objetos. El Object Adapter permite preparar los objetos a la recepcin de las peticiones e informar al ORB cuando estas peticiones han sido ejecutadas. El Object Adapter es responsable de:

Generacin e interpretacin de las referencias a los objetos Invocacin de los mtodos Seguridad de las interacciones Activacin y desactivacin de los servidores e implementaciones de los objetos Registro de las implementaciones

El object adapter depende de la naturaleza del servidor: BOA (Basic Object Adapter) que supone que el servidor es una aplicacin separada de la aplicacin cliente. LOA (Library Object Adapter) que supone que el servidor es de hecho una DLL que se cargara dinamicamente en la aplicacin del cliente. OODA (Object-Oriented Database Adapter) que supone que el servidor es una base de datos orientada a objetos. La norma Corba solo especifica BOA (Basic Object Adapter) que supone que el servidor es una aplicacin separada de la aplicacin cliente.

CORB A

12

Las estrategias posibles de activacin de un servidor por el BOA son:

Activacin de un servidor compartido que engloba las implementaciones de varios objetos. Activacin de un servidor persistente, que engloba varias implementaciones y activado fuera del propio BOA. Activacin de un servidor de objeto responsable de una sola implementacin Activacin de un servidor de mtodo, responsable de un solo mtodo de una implementacin dada.

En principio un Object Adapter invoca un objeto en el interior de un servidor por medio del skeletons. Cada objeto es pues conocido por su skeletons que habr sido completado por el programador con mtodos del objeto considerado. Corba define una interfaz llamada skeletons dinmico. El DSI, que es homologo del DII en el lado servidor, permite al ORB transmitir peticiones a objetos para los que el servidor no tiene skeletons propiamente dicho. Como el DII, el DSI permite un nivel suplementario de flexibilidad en la evolucin y el mantenimiento de los sistemas de objetos distribuidos. Para utilizar el DSI, el programador debe implementar un procedimiento que recibir todas las peticiones sean cuales sean los objetos destinatarios. Este procedimiento, la dynamic implementation routine, recibe el nombre del objeto, de la operacin y de sus parmetros para cada uno de los mensajes, y es luego responsable de la ejecucin de estas operaciones en los objetos correspondientes. El ultimo componente ORB es el Interface Repository (IR) que es el anuario de las interfaces de objetos del sistema distribuido. Todas las interfaces, as como las definiciones de objetos, se guardan y son administradas por el IR. Por ejemplo, el ORB recurrir a los servicios del IR: Para comunicar con otros ORB de implementacion distinta. Para verificar el tipo de los parmetros pasados en las peticiones, comparndolos con las definiciones guardadas de las operaciones. Para eventualmente, verificar la existencia de ciclos en los grafos de herencia mltiple y la unicidad de los nombres de operaciones en los caminos de herencia. Pero esa informacin puede ser utilizada tambin por programas cliente: Durante el desarrollo para navegar en la lista de las interfaces disponibles. Para crear herramientas de desarrollo visual que ayuden a la administracin del codigo fuente IDL de los objetos.

CORB A

13

Para facilitar la instalacin y distribucin de objetos en una configuracin dada de una red. Un ORB puede poseer varios IR correspondientes a diferentes necesidades: Un IR para los objetos desarrollados internamente, un IR para los adquiridos del exterior, y un IR para los objetos aun en fase de prueba, por ejemplo. Cada IR posee un identificador nico y se basa en un mecanismo de persistencia y de guardado de interfaces. En el IR es donde se guardan todas las definiciones de objetos aplicativos conformes a la norma Corba, en un formato accesible al ORB para que pueda administrar la interaccin entre estos objetos, pero que es tambin accesible al desarrollador a travs de una interfaz IDL estandarizada. La norma Corba distingue la capa de servicios con el lenguaje de especificacin IDL, de la capa de transporte, con la especificacin del ORB. Los servicios son descritos como objetos en IDL que los compiladores transforman en programas clientes y servidores en los lenguajes de programacin tradicionalmente utilizados por los programadores. EL ORB se define, de manera muy general, tanto en el lado del cliente como en el lado del servidor, en la ptica de una integracin fcil en esquemas muy variados. Presenta mecanismos completamente dinmicos (DII y DSI) que estn particularmente adaptados a sistema de informacin que deben evolucionar rpidamente, protegiendo a clientes y servidores de los cambios de localizacin o de implementacin que podran darse. Estos mismos mecanismos permiten interconectar ORB diferentes o un ORB y una aplicacin o un programa que no utilicen la tecnologa orientada a objetos. El ORB es en este sentido una herramienta de integracin de sistemas con nuevas aplicaciones y tecnologas, con las mas antiguas. La combinacin IDL/ORB es el repositorio de objetos dedicados de la empresa, sobre el que se pueden construir fcilmente herramientas de creacin de programas de modelizacin perfeccionadas. Es una herramienta para la modelizacin del sistema de informacin de la empresa.

Independencia de la plataforma
Un resultado del proceso de clasificacin y desclasificacin es, que debido a que los parmetros se convierten en la transmisin a un formato independiente de la plataforma, la comunicacin entre componentes es independiente de la plataforma. Esto significa que, por ejemplo, un cliente ejecutndose en un sistema Macintosh puede invocar mtodos en un servidor ejecutndose en un sistema Unix. Adems de la independencia del sistema operativo utilizado, las diferencias de hardware, como puede ser el orden de los bytes ms significativos o el tamao de una palabra, son as mismo irrelevantes, ya que el ORB hace automticamente la conversin necesaria.

CORB A

14

IDL
El lenguaje de definicin de interfaz o IDL (Interface Definition Language), es un lenguaje muy sencillo utilizado para definir interfaces entre componentes de aplicacin. Es importante destacar que IDL slo puede definir interfaces, no implementaciones. IDL, al especificar las interfaces entre objetos CORBA, es el instrumento que asegura la independencia del lenguaje de programacin utilizado. Para ello, la especificacin IDL ha de asegurar que los datos son correctamente intercambiados entre dos lenguajes distintos. Por ejemplo, el tipo long es un entero con signo de 32 bits, que se puede hacer corresponder con un long de C++ (dependiendo de la plataforma) o a un int de Java. Es responsabilidad de la especificacin IDL (y de los compiladores IDL que la implementan), definir dichos tipos de datos de una forma independiente del lenguaje. IDL consigue la independencia del lenguaje a travs de una correspondencia. El OMG ha definido bastantes correspondencias con lenguajes de programacin populares, como: C, C++, COBOL, Java, Smalltalk y Ada. Las correspondencias para otros lenguajes tambin existen, pero o no son estndar o estn en proceso de estandarizacin. En la Tabla 1 se muestra la correspondencia entre los tipos IDL y los tipos C++. Describiendo las interfaces IDL, un ORB genera automticamente cdigo en el lenguaje seleccionado para realizar la integracin de las aplicaciones distribuidas. Evidentemente, puesto que slo describe interfaces, todas las tareas complejas relacionadas con los lenguajes de programacin, como control de flujo, gestin de memoria, composicin funcional, no aparecen en IDL. Evidentemente, la independencia del lenguaje de programacin es una caracterstica muy importante de la arquitectura CORBA. CORBA da a los programadores de la aplicacin la libertad para elegir el lenguaje que mejor se adapta a las necesidades de su aplicacin o bien utilizar varios lenguajes para varios componentes de la aplicacin. Por ejemplo, el cliente de una aplicacin podra estar implementado en Java, lo que asegura que los clientes pueden ejecutarse virtualmente en cualquier mquina. Los componentes servidores de dicha aplicacin podran implementarse en C++, para conseguir una elevada eficiencia. CORBA hace posible la comunicacin entre estos componentes de diversa naturaleza. IDL Short Long Unsigned short C++ CORBA::Short CORBA::Long CORBA::UShort

CORB A
Unsigned long Float Double Char Boolean Octect Any CORBA::ULong CORBA::Float CORBA::Double CORBA::Char CORBA::Boolean CORBA::Octect CORBA::Any

15

Tabla 1: Correspondencia para los tipos de datos bsicos.

El registro de interfaz
Todas las aplicaciones basadas en CORBA necesitan acceder al tipo de sistema de IDL cuando se estn ejecutando. Esto es necesario porque la aplicacin necesita conocer los tipos de valores a ser pasados como argumentos de la peticin. Asimismo, la aplicacin ha de conocer los tipos de interfaces soportados por los objetos que estn utilizando. Ciertas aplicaciones requieren slo un conocimiento esttico del tipo de sistema IDL. Tpicamente, la especificacin IDL es compilada o traducida a cdigo para el lenguaje de programacin de la aplicacin siguiendo las reglas de traduccin como es definido por su correspondencia con el lenguaje. De esta forma, si el tipo del sistema IDL cambia de tal modo que pasa a ser incompatible con el tipo de sistema construido en la aplicacin, la aplicacin ha de volver a construirse. Pero hay ciertas aplicaciones, sin embargo, para las cuales es imposible un conocimiento esttico del tipo de sistema IDL. Para estas aplicaciones CORBA proporciona otro mtodo de definir interfaces sustituyendo a IDL, el registro de interfaz. Las interfaces pueden ser aadidas a un servicio de registro de interfaz, el cual define las operaciones para la recuperacin de la informacin del almacn en tiempo de ejecucin. Utilizando el registro de interfaz, un cliente podra ser capaz de ubicar un objeto desconocido en tiempo de compilacin, preguntar acerca de su interfaz, y despus construir una peticin a ser enviado a travs del ORB.

Stubs y skeletons
Stubs y skeletons son el adaptador intermedio entre el cliente y aplicaciones de servidor y el ORB. La transformacin se realiza mediante la compilacin de las definiciones IDL usando un compilador de IDL y por el mantenimiento de la unidad en las definiciones entre el cliente y aplicaciones de servidor.

CORB A

16

El cliente genera un mapping llamada 'stub'. El servidor genera una mapping llamada "skeletons". Cada stub representa una operacin de objeto (solicitud) que un cliente invoca (por ejemplo llamando a una subrutina que representa la operacin). Cada skeletons proporciona la interfaz de un mtodo por el que reciba una solicitud. Para utilizar los stubs, la aplicacin cliente tiene que llamar a los mtodos en el stubs que solicite un servicio con el objeto. El siguiente diagrama muestra la relacin entre el stub, skeletons y ORB:

CORB A

17

Adaptador de objetos
El adaptador de objetos de ayuda al ORB con la transferencia de las solicitudes de los objetos y activarlo. Tambin objetos asociados con las implementaciones del ORB. Otros servicios del adaptador de identificadores de objetos son la generacin e interpretacin de las referencias a objetos y la seguridad de las interacciones. Es ms comn que hay muchos adaptadores de objetos diferentes para satisfacer las necesidades de sistemas especficos. Hay tres polticas que el OMG especifica sobre la forma de objetos de adaptador puede controlar la activacin de objetos de aplicacin:

Servidor compartido de nuestra poltica - varios objetos podrn llevarse a cabo en el mismo programa. No compartidos del servidor de nuestra poltica - Nuevo servidor se inicia cada vez que se recibe una peticin. Persistentes Directiva de servidor - Los objetos de aplicacin es una actividad constante.

El Adaptador de Objetos El Adaptador de Objetos (OA) es el mdulo que permite a las implementaciones de los objetos acceder a servicios ofrecidos por el ORB como la generacin de referencias para los objetos. El adaptador de objetos exporta una interfaz pblica para su uso por la implementacin del objeto, y una interfaz privada para su uso por el esqueleto del objeto, que depende de la implementacin del adaptador de objetos. Las funciones que debe realizar el adaptador de objetos son:

Generacin e interpretacin de las referencias a objetos Invocacin de mtodos Seguridad en las interacciones Activacin y desactivacin de objetos e implementaciones Traduccin de referencias implementaciones a objetos a sus correspondientes

Registro de las implementaciones

CORB A

18

Si bien la invocacin de los mtodos se realiza a travs del esqueleto de la interfaz, implcitamente tambin se utiliza al adaptador de objetos en funciones tales como la activacin de la implementacin o la autenticacin de la invocacin. El Adaptador de Objetos define la mayora de los servicios que la implementacin de los objetos pueden obtener del ORB. Segn la implementacin, el ORB podr ofrecer unos servicios u otros. Segn la clase de adaptador que se implemente, se debern ofrecer los servicios asociados a dicha clase. Debido a que las implementaciones de los objetos dependen del Adaptador de Objetos, se deben definir los menos adaptadores de objetos diferentes posibles, teniendo en cuenta que, el Adaptador de Objetos Portable (POA) que est incluido dentro del estndar de CORBA, est diseados para cubrir la funcionalidad necesaria en un amplio rango de implementaciones de objetos. Estructura de la implementacin de los objetos La implementacin del objeto proporciona su comportamiento y su estado actual. Esto es necesario, ya que para un cliente el objeto siempre esta activo, y espera que cuando se le haga una modificacin esta se preserve, a menos que el objeto sea compartido con otro cliente. Este comportamiento del objeto debe ser manejado directamente por el objeto, ya que la mayora de los objetos no se encuentran activos todo el tiempo. Al escribir un objeto que cumpla con OMA, es necesario proporcionar una forma de salvar su estado en el momento en el cual sea desactivado, y colocar puntos de chequeo de manera tal que en caso de que el sistema sea desactivado o tenga alguna falla, el objeto sea capaz de recuperarse. El ORB, BOA y el Persistent Object Service proporcionan un espacio que puede ser usado como una referencia al sitio en el cual se encuentra almacenado el objeto.

Los Object Adapters (OA) son responsables de :

Llevar un registro de las implementaciones. Generara e interpretar las referencias a los objetos. Realizar un mapeo de las referencias implementaciones correspondientes. a los objetos a sus

Activar y desactivar las implementaciones de los objetos. Invocar mtodos por medio de un esqueleto o del DSI. Coordinar la seguridad de la interaccin junto con el Security Object Service.

Se cuenta con los siguientes OAs :

CORB A

19

Basic Object Adapter (BOA) : Puede manejar ya sea un programa por mtodo, por objeto, o un programa compartido por varias instancias de un tipo de objeto. Proporciona una pequea capacidad e almacenamiento por cada objeto, que puede ser empleada para hacer referencia al lugar en donde este almacena la informacin de manera persistente. Para las configuraciones en las que los objetos residen en procesos distintos al ORB, el BOA proporciona :
o o o o

Generacin e interpretacin de las referencias a los objetos. Activacin y desactivacin de las implementaciones de los objetos. Activacin y desactivacin de los objetos individuales Invocavin de mtodos por medio de esqueletos.

Para el BOA un servidor es una unidad de ejecucin y el objeto es la implementacin de un mtodo o interface. El BOA soporta las siguientes polticas de activacin de objetos :
o o

Servidor compartido : Un servidor maneja varios objetos. Servido persistente : Se parece al anterior pero servidor que no es activado por el BOA, ni se desactiva (permanece activo todo el tiempo). Este servidor se registra ante el BOA mediante un procedimiento de instalacin. Servidor no compartido : Solamente un objeto implementacin puede estar activa en el servidor. de una

o o

Servidor por mtodo : Un objeto tiene sus mtodos divididos entre varios servidores. En este caso el BOA arranca un servidor por cada mtodo invocado, siendo desactivado cada que termina la invoacin.

Library Object Adapter : Esta especializado en objetos que son accedidos por un solo proceso. Estos objetos usualmente no requieren de activacin o de autenticacin.

Object-Oriented Batabase Adapter : Debido a que las bases de datos orientadas a objetos proporcionan los mtodos y el almacenamiento persistente, los objetos pueden ser registrados implcitamente y el OA no necesitara guardar su estado.

Su principal propsito es crear la interface para la implementacin de un objeto como su ORB. El BOA es la interface de objetos CORBA al ORB

CORB A

20

del

Estructura Object Adapter

La interfaz de invocacin dinmica

El DII (Dynamic Invocation Interface) es una interfaz que nos permite la construccin dinmica de invocaciones para un determinado objeto. Esto nos permite, en vez de utilizar una llamada a una funcin determinada de un objeto concreto, que el cliente puede especificar el objeto, la invocacin y los parmetros a pasar a la invocacin a travs de una llamada o conjunto de llamadas. De cara al servidor la invocacin es idntica a una que llega a travs de la interfaz esttica, pero dentro del cliente se logra una flexibilidad fundamental en arquitecturas complejas y dinmicas. Una invocacin dinmica se compone de una referencia al objeto, una operacin y una lista de parmetros. Todos estos datos se obtiene del Repositorio de Interfaces (IR) , un nuevo elemento de la arquitectura que pasamos a detallar. El Repositorio de Interfaces (IR) El Repositorio de Interfaces (IR) es un servicio que ofrece objetos persistentes que representan la informacin IDL de los interfaces disponibles en CORBA, de una forma accesible en tiempo de ejecucin (run-time). Esta informacin puede ser utilizada por el ORB para realizar peticiones. Y adems, el programador de aplicaciones puede utilizar esta informacin para acceder a objetos cuya

CORB A

21

interfaz no se conoca en tiempo de compilacin, o para determinar que operaciones son vlidas en un objeto. Esta interfaz le da al cliente la posibilidad de que en cualquier momento invoque cualquier operacin en cualquier objeto que pueda ser alcanzado por la red. Para poder hacer esto se realizan cuatro pasos :
1. Identificar el objeto que se desea invocar : Para esto los clientes consultarn un servicio de mercadeo de objetos, en donde se obtendr la localizacin del objeto que proporciona el servicio que se esta buscando. 2. Conseguir la interfaz del objeto : El repositorio de interfaces almacena nicamente la informacin relacionada con la sintaxis, de manera tal que los objetos deben usar la operacin get_interface para una referencia al objeto que retorna el componente superior de la interfaz , siendo posible obtener las operaciones de la interfaz, sus parmetros y sus tipos. 3. Construir la invocacin : Se emplea el mtodo create_request pasndole una lista de argumentos. 4. Hacer la invocacin y esperar los resultados : Se emplea el mtodo add_args que le da valor a cada uno de los argumentos de la solicitud.

Secuencia bsica de operaciones

1. El ORB recibe una solicitud a un objeto que se encuentra en un servidor que esta conectado a l, el ORB consulta su repositorio y determina si el servidor y el objeto se encuentran activos en este momento. 2. En caso de que el servidor se encuentre inactivo, es activado por el ORB, recibiendo la informacin necesaria para interactuar con el ORB por medio de su BOA (Basic Object Adapter). 3. El servidor al ser activado llama la rutina impl_is_ready, una llamada al BOA, informndole al ORB que esta listo para activar objetos. 4. En caso de que el objeto no se encuentre activo, el BOA llama a la rutina del servidor para activar el objeto necesario. Y el servidor activa el objeto. 5. El BOA pasa la invocacin al objeto por medio del esqueleto y recibe la respuesta que es enrutada hacia el cliente. 6. Las solicitudes adicionales recibidas por el BOA son manejadas de la misma manera que en los pasos 4 y 5. 7. El servidor puede decidir desactivar un objeto cuando no hay mas solicitudes para este, para hacer esto el primero hace un llamado a la rutina del BOA deactivate_obj, especificando el objeto a desactivar, despus de este llamado el BOA no enviara llamadas a este objeto sin

CORB A

22

activarlo primero. El objeto guarda su estado en un almacenamiento persistente antes de desactivarse. 8. El servidor puede desactivarse por completo, en caso de que todos sus objetos se encuentren desactivados. Para esto hace un llamado a la rutina deactivate_impl informandole al BOA que no se encuentra disponible para activar objetos por mas tiempo. Qu nos permite la DII? Permite al cliente enviar una peticin hacia cualquier objeto presente en la red en un momento dado, en particular a objetos para los que el cliente no tiene STUB. Qu es la invocacin dinmica y en que consiste? El programa cliente construye dinmicamente una peticin sin usar el STUB. Una invocacin dinmica se construye en 4 etapas: 1. 2. 3. 4. Identificar el Objeto Recuperar su interfaz Construir la invocacin y ejecutarla Recibir los resultados o eventuales excepciones

Cuntos tipos de invocacin dinmica conoce?

La especificacin DII de Corba describe dos modos de invocacin dinmica: Modo Sncrono: el cliente se bloquea en espera de respuesta del Servidor. Modo Sncrono diferido: (Deferred Sincronous) el cliente no espera la respuesta del Servidor y puede pedirla mas tarde. Existe uno ms: El Modo Asncrono : o oneway (un solo sentido) no bloqueante y la peticin solo puede ocurrir en un sentido.

Dynamic Skeleton Interface Interfaz dinmica Esqueleto

CORB A

23

El Dynamic Esqueleto Interface (DSI) es el equivalente del lado del servidor del DII. Permite que un servidor pueda recibir una operacin o atributo- invocacin en cualquier objeto, incluso uno con un desconocido interfaz IDL en tiempo de compilacin. El servidor no tiene por qu estar vinculado con el cdigo del esqueleto de un interfaz de invocaciones a aceptar la operacin en esa interfaz. En cambio, un servidor puede definir un mtodo que se inform de una operacin de entrada o la invocacin de atributos. Este mtodo permite determinar la identidad del objeto que se invoca. El nombre de la operacin y los tipos y valores de cada argumento debe ser proporcionada por el usuario. El mtodo se puede realizar la tarea solicitada por el cliente, y construir y devolver el resultado. As como el uso de la DII es menos comn que el uso de invocaciones estticas normales, el uso de la DSI es menos comn que el uso de las implementaciones de interfaz esttica. Adems, los clientes no son conscientes de que un servidor se aplicaron en la prctica con el DSI, los clientes simplemente hace IDL llamadas como de costumbre. Usos de la DSI El ISE est explcitamente diseado para ayudarle a escribir entradas. Uso de la DSI, una puerta de entrada puede aceptar la operacin o atributo invocaciones en cualquier conjunto especfico de interfaces y pasarlos a otro sistema. Una puerta de enlace se puede escribir en la interfaz entre el sistema CORBA y algunos no CORBA. La puerta de enlace tiene que saber las reglas de protocolo de sistema no CORBA. Sin embargo, es la nica parte del sistema de CORBA que requiere este conocimiento. El resto del sistema CORBA IDL sigue haciendo llamadas como de costumbre. El protocolo IIOP permite que un objeto en un ORB para invocar sobre un objeto en otro ORB. Los sistemas no CORBA no tiene que soportar este protocolo. Una forma de interfaz de CORBA para tales sistemas es la construccin de una pasarela mediante la DSI. Este punto de acceso aparece como un servidor CORBA que contienen muchos objetos CORBA. El servidor utiliza el DSI para atrapar las invocaciones entrantes y los traducen en llamadas al sistema no CORBA. Una combinacin de la DSI y DII permite un proceso para ser una puerta de enlace bidireccional. El proceso puede recibir mensajes del sistema no CORBA y el uso del DII para realizar llamadas CORBA. Se puede utilizar la DSI para recibir las solicitudes del sistema CORBA y plasmarlas en los mensajes en el sistema de no-CORBA. Otro ejemplo del uso de la DSI es un servidor que contiene un gran nmero de objetos CORBA no su deseo de poner a disposicin de sus clientes. Una forma de lograrlo es proporcionar a un individuo objeto CORBA para actuar como un front-end para cada objeto CORBA no. Sin embargo, en algunos casos esta multiplicidad de objetos puede causar sobrecarga demasiado.

CORB A

24

Otra forma es proporcionar un nico objeto de front-end que se puede utilizar para invocar en cualquiera de los objetos, probablemente mediante la adicin de un parmetro para cada llamada que especifica el objeto no es CORBA para ser manipulado. Esto cambia la vista de cliente porque el cliente no puede invocar en cada objeto individual, tratndolo como un buen objeto CORBA. Puede utilizar la DSI para lograr el mismo espacio de ahorro que el obtenido al usar un solo objeto para el usuario. Puede dar a los clientes una vista que no hay un objeto CORBA para cada objeto subyacente. El servidor indica que su deseo de aceptar invocaciones en la interfaz IDL con la DSI, y que se informe de tal invocacin, identifica el objeto de destino, la operacin o atributo llamado ser, y los parmetros. A continuacin, realiza la llamada sobre el objeto subyacente no CORBA, recibe el resultado y la devuelve al cliente que llama. Dynamic Skeleton Interface : Permite el manejo dinmico de las invocaciones a objetos. No es accedido por un esqueleto especfico para una operacin determinada. Se proporciona acceso a travs de un nombre de operacin y parmetros.

ESQUELETO DINAMICO: el DSI (DII en el servidor), permite al ORB transmitir peticiones a obj para los que el servidor no tiene ESQUELETO propiamente dicho. El DSI permite construir facilmente pasarelas entre ORB, el servidor del primer ORB siendo cliente del segundo para los obj remotos. La pasarela funciona como el obj real, sin cambio para el programa cliente que permite localizar dinamicamente los obj. El interfaz repository (IR) es el anuario de las interfaces de obj del sistema distribuido. El ORB recurrira a los servicios del IR: Para comunicar con otros ORB de implementacion distinta Para verificar el tipo de los parametros pasados en las peticiones Para verificar la existencia de ciclos en los grafos de herencia multiple

CORB A

25

Modelo de comunicaciones CORBA

Protocolos entre ORBs
La especificacin CORBA es independiente de los protocolos de transporte; el estndar CORBA especifica el conocido como GIOP (General Inter-ORB Protocol). GIOP especifica, a alto nivel, un estndar para la comunicacin entre varios componentes CORBA ORBs. GIOP, es slo un protocolo general; el estndar CORBA tambin determina protocolos adicionales, que especializan GIOP para utilizar un protocolo de transporte en particular. Por ejemplo, los protocolos basados en GIOP existen para TCP/IP y DCE. Adicionalmente, los vendedores pueden definir y utilizar protocolos propietarios para la comunicacin entre componentes CORBA. El protocolo basado en GIOP ms importante es el destinado a redes TCP/IP, conocido como IIOP (Internet Inter-ORB Protocol). Los vendedores tienen que implementar el protocolo IIOP para ser considerados conformes a CORBA, aunque pueden ofrecer adems sus protocolos propietarios. Este requerimiento ayuda a asegurar la interoperabilidad entre los productos CORBA de diferentes vendedores pues cada producto conforme a CORBA 2.2 debe ser capaz de hablar el mismo lenguaje. Algunos vendedores han adoptado IIOP como protocolo nativo de sus productos en vez de utilizar un protocolo propietario; sin embargo, se permite que un ORB soporte cualquier nmero de protocolos, siembre y cuando IIOP se soporte, es decir, al comunicarse entre s, los ORBs pueden negociar que protocolo utilizar. Adicionalmente algunos fabricantes estn incorporando IIOP en productos como servidores de bases de datos o herramientas de desarrollo de aplicaciones o navegadores Web.

CORBA y el modelo de trabajo en red

Esencialmente, las aplicaciones CORBA se realizan sobre los protocolos derivados de GIOP como IIOP. Estos protocolos van sobre TCP/IP, DCE o cualquier otro protocolo de transporte que utilice la red. Las aplicaciones CORBA no estn limitadas a utilizar nicamente uno de estos protocolos; la arquitectura de una aplicacin puede ser diseada para utilizar un puente que interconecte, por ejemplo, componentes de una aplicacin basados en DCE con otros basados en IIOP. Es decir, mquinas que suplantan los protocolos de la red de transporte. CORBA es una arquitectura que crea otra capa (la capa del protocolo entre ORBs) que utiliza la capa de transporte subyacente. Esto es tambin un punto determinante de la interoperabilidad entre aplicaciones CORBA, CORBA no dicta la utilizacin de una capa de transporte en particular.

Clientes y servidores CORBA

Tradicionalmente, en una aplicacin cliente/servidor, el servidor es el componente o componentes que proporciona servicios a otros componentes de la aplicacin. El cliente es el componente que hace uso de los servicios suministrados por un servidor o servidores.

CORB A

26

La arquitectura de una aplicacin CORBA no es diferente; generalmente, ciertos componentes de una aplicacin proporcionan servicios que son utilizados por otros componentes de otra aplicacin. El papel del cliente y servidor puede intercambiarse temporalmente, ya que un objeto CORBA puede participar en mltiples interacciones simultneamente. En una aplicacin CORBA, cualquier componente que proporciona la implementacin para un objeto es considerado un servidor. El hecho de ser un servidor CORBA significa que, el componente (el servidor), ejecuta mtodos para un objeto particular, en nombre de otros componentes (los clientes).

Stubs y skeletons
Despus de que el programador cree las definiciones de interfaz del componente utilizando IDL, dicho desarrollador procesa los ficheros IDL resultantes con un compilador IDL. El compilador crea los conocidos por client stubs y server skeletons. Los client stubs y server skeletons sirven como una clase de pegamento que conecta las especificaciones de interfaz IDL independientes del lenguaje con un cdigo de implementacin especfico del lenguaje. Los client stubs para una interfaz en particular se suministran para su inclusin con los clientes que utilizan dichas interfaces. El client stub para una interfaz en particular, proporciona una falsa implementacin para cada uno de los mtodos de dicha interfaz. En vez de ejecutar la funcionalidad del servidor, los mtodos del client stub simplemente se comunican con el ORB para clasificar y desclasificar los parmetros. Por otro lado, se tienen los server skeletons, proporcionando el skeletons sobre el que se construir el servidor. Para cada mtodo en la interfaz, el compilador IDL genera un mtodo vaco en el server skeleton. El desarrollador despus proporciona una implementacin para cada uno de esos mtodos. Los stubs y skeletons han sido generalizados a un DII (Dynamic Invocation Interface) y DSI (Dynamic Skeleton Interface), respectivamente. Ambas son interfaces proporcionadas directamente por ORB, y son independientes de las interfaces IDL de los objetos que estn siendo invocados. Utilizando DII una aplicacin cliente puede invocar peticiones, en cualquier objeto, sin tener conocimiento en tiempo de compilacin de las interfaces del objeto. De forma semejante, DSI permite a los servidores ser codificados, sin tener skeletons para los objetos que estn siendo invocados, siendo compilados estticamente en el programa.

CORB A

27

CORBA Facilities
CORBA Facilities Horizontales
Esta facilidades CORBA tanto horizontales como verticales, son diseadas para completar la arquitectura entre los Servicios bsicos de CORBA y las aplicaciones especificas de industria. Con una arquitectura completa, las compaa compartirn datos a nivel de aplicacin y funcionalidades para la integracin de diferentes sistemas de informacin. Las facilidades representan un punto medio entre una aplicacin particular y los servicios y ORB.

La OMG ha definido como Facilidades horizontales las siguientes:

Interfaz de usuario

Gestin de la visualizacin en la pantalla o en papel Gestin de visualizacin de documentos compuestos Ayuda en lnea para el usuario Lenguaje de script para automatizacin de operaciones Gestin del entorno de trabajo

Administracin de informacin

Modelado y creacin de modelos de sistemas de informacin Almacenamiento y recuperacin de modelos Intercambio de datos e informacin entre documentos compuestos Codificacin de los datos (definicin de formatos estndar) Datos cronolgicos (servicios de manipulacin de datos y calendarios)

Administracin de sistemas

Hace referencia en forma directa a la norma SYSMAN Provee un conjunto de interfaces de utilidades para la gestin de sistemas de informacin

Administracin de tareas Hace referencia a la ejecucin, secuenciacin y automatizacin de tareas: Organizacin de tareas (workflow) Sistemas de Agentes (automatizan tareas repetitivas) Administracin de reglas (representan los procesos de la empresa)

CORB A

28

Servicios de automatizacin (lenguajes de script en operaciones efectuadas sobre objetos)

Hoy en da estas especificaciones han sido adheridas a ORBOS (ORB y Servicios) y ya no esta como un grupo aparte. Especficamente a nivel de facilidades verticales la OMG ha definido las siguientes: Especificacin para la administracin de sistemas XCMF. Facilidad para colar de impresin.

CORBA Facilities Verticales o de Dominio

La potencialidad que representa el lenguaje IDL para la especificacin de un objeto u componente ha permitido trabajar en la normalizacin de intereses comunes para un sector de mercado particular y que una vez se llegue a un acuerdo en cuanto a estas especificaciones, sera estndar dentro de este mercado. Para esto se ha creado el Domain Technology Committee (DTC) y esta a su vez esta organizada en una serie de Domain Task Forces (DTF) los cuales escriben documentos de requerimientos (RFI y RFP) para nuevas especificaciones y evalan y recomiendan especificaciones candidatas. Basados en las recomendaciones de los DTF, el DTC conduce un proceso formal de votacin para asegurar que cumple todos los requerimientos del sector y no solo de quien haya propuesto. Posteriormente estas recomendaciones requieren ser enviadas a la Junta de Directores de la OMG para hacerla una especificacin oficial. Actualmente hay 8 DTF: Objetos de negocio Finanzas y seguros Comercio Electrnico Manufactura Salud o Medicina Telecomunicaciones Transportes Investigacin de ciencias de la vida

Tambin bajo la OMG pero que no tienen DTF se encuentran dos Grupos de Inters Especial:

Utilities (principalmente energa elctrica) Estadstica

Seis especificaciones ya han sido adoptadas oficialmente como estndares de dominio vertical, ellos son:

Facilidad Currency del DTF de Finanzas

CORB A

29

Un conjunto de Habilitadores para la administracin de datos de productos, del DTF de manufactura. Servicio de Identificacin de Personas (PIDS) de CORBAMed Servicio de Consulta Lexicon de CORBAMed Control y Administracin de flujos de Audio/Vdeo, del DTF de telecomunicaciones Servicio de Notificacin, del DTF de Telecomunicaciones.

Ejemplo de programacin en CORBA

En este apartado mostramos un sencillo ejemplo del desarrollo de una aplicacin en CORBA, en concreto en Orbix 2.2 de IONA Technologies PLC sobre el sistema operativo Unix Solaris 5.5.1 de Sun Microsystems. Se trata de un contador, cuyo valor podr ser reseteado, incrementado, decrementado y consultado por los clientes ejecutndose en la misma u otras mquinas. Para informacin sobre IONA, puede acudir a su Sitio Web, en http://www.iona.com/.

Interfaz IDL
El cdigo de la interfaz IDL de un contador, que sera comn a la implementacin de CORBA de cualquier vendedor, es el siguiente: // Interfaz IDL a un contador. interface Contador { // Devuelve el valor actual del contador long daValor (); // Pone el contador al valor especificado oneway void ponValor (in long valor); // Incrementa el valor del contador en la cantidad especificada y devuelve el valor resultante long incrementarValor (in short cantidad); // Decrementa el valor del contador en la cantidad especificada y devuelve el valor resultante long decrementarValor (in short cantidad); }; Por defecto todos los mtodos son bloqueantes, es decir, cuando un objeto llama a un mtodo en un objeto remoto, el objeto que invoca el mtodo espera (se bloquea), hasta que el mtodo se ejecute y retorne. Cuando el objeto remoto termina de procesar la invocacin del mtodo, devuelve el valor resultante, con lo cual podr continuar con el resto de sus operaciones. Para indicar que la operacin sea no bloqueante, se debe especificar la clasula oneway antes de la definicin de ste. Como puede observar, los parmetros en un mtodo pueden ser declarados como in -indica que se trata de un parmetro de entrada-, out -indica que es un parmetro de salida-, o inout -indica que el parmetro se utiliza como entrada y salida del mtodo-.

CORB A
Esta interfaz ser compilada utilizando el compilador IDL, generando tres ficheros:

30

Un fichero de cabecera que deber ser incluido en la implementacin del contador y en sus clientes. Un fichero fuente a ser compilado e incluido en la implementacin del contador. Un fichero fuente a ser compilado e incluido en los clientes del contador.

Servidor
Fichero ContadorSC.h #ifndef ContadorSC_h #define ContadorSC_h // Fichero de cabecera generado por el compilador IDL a partir de Contador.idl #include <Contador.hh>class Contador_i { private: // Valor actual del contador CORBA::Long _valor; public: // Constructor Contador_i(CORBA::Long valor = 0); // Operaciones ofrecidas por el contador virtual void ponValor(CORBA::Long valor, CORBA::Environment &IT_env=CORBA::default_environment); virtual CORBA::Long daValor(CORBA::Environment &IT_env=CORBA::default_environment); virtual CORBA::Long incrementarValor(CORBA::Short cantidad, CORBA::Environment &IT_env=CORBA::default_environment); virtual CORBA::Long decrementarValor(CORBA::Short cantidad,CORBA::Environment &IT_env=CORBA::default_environment); }; // Macro que asocia la interfaz Contador con su implementacin en C++ Contador_i DEF_TIE(Contador,Contador_i) #endif Fichero ContadorSC.cc #include <ContadorSC.h> Contador_i::Contador_i (long int valor) { _valor = valor; } void Contador_i::ponValor(long int valor, CORBA::Environment &se) { _valor = valor;

CORB A
} long int Contador_i::daValor CORBA::Environment &se) { CORBA::Long valor = _valor; return valor; } long int Contador_i::incrementarValor (short int cantidad,CORBA::Environment& se) { _valor = _valor + cantidad; return _valor; } long int Contador_i::decrementarValor(short int cantidad,CORBA::Environment& se) { _valor = _valor - cantidad; return _valor; } Fichero main.cc

31

#include <ContadorSC.h> main( ) { // Se crea una instancia del contador Contador_var Servidor = TIE_Contador(Contador_i)(new Contador_i); // Se entra en el bucle de eventos try { CORBA::Orbix.impl_is_ready ("contador", CORBA::Orbix.INFINITE_TIMEOUT); } catch (const CORBA::SystemException& codigo) { cerr << "Excepcion CORBA al registrar el servidor: "<< codigo; }

Cliente
Fichero ContadorCC.cc // Fichero de cabecera generado por el compilador IDL a partir de Contador.idl include <Contador.hh> int main() { //Referencia al objeto contador Contador_var MiContador; int operacion = 0; short int cantidad = 0; try

CORB A
{ //Se obtiene la referencia al objeto Contador::_bind(":contador"); }

32

catch (const CORBA::SystemException& codigo) { cerr << "Ha fallado el intento de comunicacin con el objeto: "<< codigo << endl; return 0; } while (operacion != 5) { cout << "Comandos posibles:" << endl; cout << "1. Resetear el contador" << endl; cout << "2. Incrementar el contador" << endl; cout << "3. Decrementar el contador" << endl; cout << "4. Visualizar el valor del contador" << endl; cout << "5. Abandonar el programa" << endl; cout << "Seleccion: "; cin >> operacion; switch (operacion) { case 1: MiContador->ponValor(0); break; case 2: cout << "Valor a incrementar:" << endl; cin >> cantidad; MiContador->incrementarValor(cantidad); break; case 3: cout << "Valor a decrementar:" << endl; cin >> cantidad; MiContador->decrementarValor(cantidad); break; case 4: cout << "Valor del contador: " << MiContador->daValor() << endl; break; case 5: return 1; default: break;

CORB A

33

Implementaciones del estndar CORBA

Orbix (IONA) SOMOBJECTs (IBM) DAIS (ICL) Inprise VisiBroker (VISICIENIC)

CORB A

34

Bibliografia
http://www.ucentral.edu.co/NOMADAS/nunme-ante/16-20/PdfsNomadas %2017/15-tecnologia.PDF http://www.dspace.espol.edu.ec/bitstream/123456789/1499/1/2943.pdf http://www.ramonmillan.com/tutoriales/corba.php http://agamenon.uniandes.edu.co/~revista/articulos/corba/corba.htm http://www.tic.udc.es/~fbellas/teaching/adoo-2000-2001/Tema2.pdf http://www.omg.org Ciaran McHale. CORBA Utilities. Available at www.CiaranMcHale.com/download/. OMG. Common Security Interoperability (CSIv2). Available for download from www.omg.org both as a stand-alone document and as a chapter in the CORBA Specification. http://agamenon.uniandes.edu.co/~revista/articulos/corba/corba.htm/ New Features for CORBA 3.0 Steve Vinoski CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments - Steve Vinoski, IONA Technologies, Inc.

CORBA EXPLAINED SIMPLY -Ciaran McHale -www.CiaranMcHale.com