DESARROLLO DE SISTEMAS DISTRIBUIDOS OMNIORB CALCULADORA PYTHON C++

4CV2

INDICE
INTRODUCCIN ........................................................................................................................................ 2 CORBA .................................................................................................................................................... 2 Elementos ........................................................................................................................................... 2 Interface Definition Language (IDL) ........................................................................................... 3 Objetos por referencia ................................................................................................................... 3 Objects by value (OBV) ................................................................................................................. 4 CORBA Component Model (CCM) ............................................................................................ 4 Interceptores portables .................................................................................................................. 5 General InterORB Protocol (GIOP) .............................................................................................. 5 Localizaciones de CORBA (CorbaLoc) ..................................................................................... 5 OMNIORB ................................................................................................................................................ 6 DESARROLLO PRCTICO ...................................................................................................................... 19 Cdigo .............................................................................................................................................. 19 Makefile ........................................................................................................................................ 19 Echo.idl .......................................................................................................................................... 20 Servidor.py.................................................................................................................................... 20 Cliente.cc ..................................................................................................................................... 23 Capturas de pantalla ....................................................................................................................... 27 CONCLUSIONES ...................................................................................................................................... 29 BIBLIOGRAFA........................................................................................................................................... 30

JENNYFER OJEDA

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

INTRODUCCIN
CORBA Common Object Request Broker Architecture (CORBA) es un estndar definido por Object Management Group (OMG) que permite que diversos componentes de software escritos en mltiples lenguajes de programacin y que corren en diferentes computadoras, puedan trabajar juntos; es decir, facilita el desarrollo de aplicaciones distribuidas en entornos heterogneos. CORBA fue el primer producto propuesto por OMG. Su objetivo es ayudar a reducir la complejidad, disminuir los costes y acelerar la introduccin de nuevas aplicaciones informticas, promoviendo la teora y la prctica de la tecnologa de objetos en los sistemas distribuidos. Es una tecnologa que oculta la programacin a bajo nivel de aplicaciones distribuidas. No obstante tambin brinda al programador una tecnologa orientada objetos; las funciones y los datos se agrupan en objetos y estos objetos pueden estar en diferentes mquinas, pero el programador acceder a ellos a travs de funciones normales dentro de su programa. CORBA es ms que una especificacin multiplataforma, tambin define servicios habitualmente necesarios como seguridad y transacciones. Y as este no es un sistema operativo en s, en realidad es un middleware. Elementos

La arquitectura CORBA est orientada a objetos. En CORBA los objetos poseen muchas de las caractersticas de otros sistemas orientados a objetos, como son la herencia en cuanto a interfaces y el polimorfismo. Pero lo ms interesante de este aspecto, es la posibilidad de proporcionar estas caractersticas a lenguajes no orientados a objeto como C o COBOL, aunque CORBA trabaja ms eficientemente con lenguajes orientados a objeto como son Java o C++. Object Request Broker (ORB)[editar] El Object Request Broker (ORB), es un componente fundamental de la arquitectura CORBA y su misin es facilitar la comunicacin entre objetos. ste se encarga de enviar las peticiones a los objetos y retornar las respuestas a los clientes que las invocan por el proceso de serializacin. El ORB tiene como principal caracterstica la transparencia. Facilita la comunicacin entre cliente y servidor ocultando:
JENNYFER OJEDA 2

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

La localizacin de los objetos: El cliente no tiene porque saber donde se encuentra el objeto destino, puede estar en su propia mquina o en un proceso en una mquina remota. La implementacin de los objetos: El cliente ignora el lenguaje de programacin con el que se ha escrito el objeto remoto, su implementacin o el sistema operativo en el que se encuentra. Estado de ejecucin del objeto: Al enviar una peticin sobre un objeto remoto, el ORB se encarga de inicializar 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 utiliza el ORB para enviar las peticiones y retornar el resultado. Interface Definition Language (IDL) El lenguaje de definicin de interfaz o IDL (Interface Definition Language), es un lenguaje que se utiliza para definir las interfaces entre los componentes de una aplicacin y es el elemento que soporta la interoperabilidad de la tecnologa. El IDL slo puede definir interfaces, no implementaciones. Al especificar las interfaces entre objetos en CORBA, IDL es el encargado de asegurar la independencia del lenguaje de programacin utilizado. Para que esto sea posible, es necesario asegurar que los datos son correctamente intercambiados entre dos lenguajes distintos, para lo cual IDL define los tipos de datos de una forma independiente del lenguaje con las correspondencias necesarias. Por ejemplo, un tipo long en C++ de 32 bits puede corresponderse con un int de Java. OMG ha definido bastantes correspondencias con lenguajes de programacin populares, como: C, C++, COBOL, Java, Smalltalk o Ada. Tendremos principalmente dos tipos diferentes de IDL en CORBA: Stub IDL: es la interfaz esttica a los servicios declarados en las interfaces IDL, para el cliente todas las llamadas parecen locales. Actuar como proxy del objeto remoto, realizando la invocacin de mtodos remotos, incluyendo la serializacin, la recepcin de respuestas y la deserializacin. El cliente puede tener tantos stubs como interfaces IDL existan. Es generado a partir del IDL en el lenguaje de programacin del cliente (C, C++ Java, Smalltalk, Ada, ) por un compilador IDL. Skeleton IDL: es el representante esttico del cliente en el servidor. Para el servidor todas las llamadas parecen locales. Es generado a partir del IDL por un compilador IDL y realiza la deserializacin de las invocaciones del cliente. Objetos por referencia La referencia de los objetos se obtiene a travs de un campo Uniform Resource Identifier (URI) en formato cadena, una bsqueda NameServer (similar a la del Sistema
JENNYFER OJEDA 3

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

de Nombres de Dominio (DNS)) o pasada como argumento durante la llamada a un mtodo. Los objetos referenciados son objetos mucho ms livianos que implementan la interfaz del objeto real, ya sea remoto o local. Las llamadas a mtodos por referencia consisten en una sucesin de llamadas al ORB que se encarga de bloquear los hilos y esperar por una respuesta, ya sea de xito o fracaso. Los parmetros, informacin de retorno (en caso de haberla), y las excepciones son serializadas por el ORB internamente segn el lenguaje de programacin y sistema operativo. Datos por valor El IDL proporciona el lenguaje de definicin de intercomunicacin entre objetos o sistemas operativos. Los objetos de CORBA se pasan por referencia, mientras que los datos (integers, doubles, structs, enums, etc...) se pasan por valor. Esta combinacin hace que podamos complementar datos fuertemente tipados al compilar clientes y servidores, y aun as preservar la flexibilidad que CORBA nos facilita. Objects by value (OBV) Adems de objetos remotos, CORBA y RMI-IIOP definen el concepto de Objects by value u OBV (Objetos por valor) y Valuetypes. El cdigo de los mtodos de objetos Valuetype es ejecutado localmente por defecto. Si el OBV ha sido recibido por el lado remoto, el cdigo necesario debe ser conocido a priori por ambas partes o descargado dinmicamente por el emisor. Para hacer que todo esto sea posible, el registro, definido en el OBV, contiene la base de cdigo que contiene una lista, separada en diferentes mquinas, de URLs desde donde este cdigo debe ser descargado. Adems el OBV puede tener mtodos remotos. Los OBVs pueden tener campos que se transfieren cuando los OBVs son transferidos. Estos campos pueden ser los OBVs por s mismos, formando listas, rboles o grficos arbitrarios. Los OBVs poseen una jerarqua de clases, incluyendo herencia mltiple y clases abstractas. CORBA Component Model (CCM) CORBA Component Model o CCM (Modelo de Componentes de CORBA) es un aadido a la familia de definiciones de CORBA. Fue introducido en la versin CORBA 3 y describe un framework para los componentes de CORBA. Aunque no depende de language dependent Enterprise Java Beans (EJB) es una forma ms general de ste, proporcionando cuatro tipos diferentes de componentes en vez de los dos que el EJB define. Adems proporciona la abstraccin de entidades que pueden proveer y aceptar servicios a travs de unas interfaces propias bien definidas llamadas ports (puertos). El CCM tiene un contenedor de componentes donde los componentes software pueden ser depositados. El contenedor ofrece una serie de servicios que los componentes pueden usar. Estos servicios incluyen (aunque no estn limitados solo a
JENNYFER OJEDA 4

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

stos) notificacin, autenticacin, persistencia y proceso de transacciones. Son los servicios ms utilizados que cualquier sistema distribuido necesita y, moviendo la implementacin de estos servicios de los componentes del software al contenedor de componentes, la complejidad de los componentes se reduce drsticamente. Interceptores portables Los interceptores portables (portable interceptors) son los ganchos usados por CORBA y RMI-IIOP para proporcionar una de las funciones ms importantes del sistema CORBA, que define los siguientes tipos de interceptores: Los interceptores de Referencia del Objeto Remoto (IOR) permiten la creacin de las nuevas referencias de los objetos remotos presentes en el actual servidor. Los interceptores clientes proporcionan la llamada a mtodos remotos desde el lado del cliente. Si el objeto servicio existe en el mismo servidor donde el mtodo es invocado, adems permiten llamadas locales. Los interceptores servidor proporcionan la tramitacin de las llamadas de mtodos remotos en el lado del servidor. Los interceptores pueden incluir la informacin especfica de los mensajes al ser enviados y los IORs al ser creados. Esta informacin puede ser leda ms adelante por el interceptor correspondiente en el lado remoto. Los interceptores pueden a su vez lanzar excepciones de reenvo, redirigiendo la peticin a otro objetivo. General InterORB Protocol (GIOP) El GIOP es un protocolo abstracto por el cual los ORBs se comunican. Los estndares asociados con el protocolo son mantenidos por OMG. La arquitectura de GIOP proporciona una serie de protocolos entre los que se encuentran: Internet InterORB Protocol (IIOP): implementacin de GIOP para su uso por internet, proporcionando una interfaz entre los mensajes GIOP y la capa TCP/IP. SSL InterORB Protocol (SSLIOP): protocolo IIOP sobre SSL, proporcionando encriptacin y autenticacin. HyperText InterORB Protocol (HTIOP): protocolo IIOP sobre HTTP, proporcionando transparencia remota. Zipped IOP (ZIOP): una versin comprimida de GIOP que reduce el uso de ancho de banda. Localizaciones de CORBA (CorbaLoc) Las localizaciones de CORBA (CorbaLoc) hacen referencia a un objeto referenciado CORBA que tiene una estructura similar a la de una URL.

JENNYFER OJEDA

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

Todos los productos CORBA deben soportar dos URLs definidas: CorbaLoc y CorbaName. El propsito de ambas es proporcionar una forma que pueda ser leda y editada por el ser humano para especificar la localizacin donde el IOR puede ser obtenido. Un ejemplo de CorbaLoc se puede ver ms abajo: corbaloc::160.45.110.41:38693/StandardNS/NameServer-POA/_root Un producto CORBA puede opcionalmente soportar el uso de formatos HTTP, FTP y FILE. La finalidad de estos es proporcionar detalles sobre cmo descargar los campos IOR. OMNIORB Implementaciones de CORBA en linux: Open Source: o OmniORB: C++, AT&T of England Small footprint and modern implementation. This ORB is covered in this tutorial. Debian: C++: omniorb4 Python: python-omniorb2 TAO: [TheAceORb.com]: C++ based on the ACE framework Debian: ace JACOrb: Java Implementation MICO: C++ ORBit: Gnome desktop implementation Debian: o C: orbit2 o C++: orbit2spp Fnorb: Python Debian: fnorb The following have name services: omniORB4, ORBit2 and TAO Commercial: o Borland Visibroker: o IONA Orbix:

En este captulo, vamos a travs de tres ejemplos para ilustrar los pasos prcticos para utilizar omniORB. Al pasar por el cdigo fuente de cada ejemplo, se introducen los conceptos y APIs esenciales. Si usted no tiene experiencia previa en el uso de CORBA, debe estudiar este captulo en detalle. Hay referencias a otros documentos esenciales que usted debe conocer. Si usted tiene experiencia con el uso de otros ORB, an debe pasar por este captulo, ya que proporciona informacin importante acerca de las caractersticas y APIs que son necesariamente omniORB especfico. Con el adaptador de objeto porttil, hay
JENNYFER OJEDA 6

DESARROLLO DE SISTEMAS DISTRIBUIDOS muy pocos detalles especficos omniORB.

4CV2

2.1 El Echo Ejemplo Object Nuestro ejemplo es un objeto que tiene un solo mtodo. El mtodo simplemente hace eco la cadena de argumentos. Tenemos que: 1. definir la interfaz de objetos en IDL; 2. utilizar el compilador IDL para generar el cdigo auxiliar 1 ; 3. proporcionar la implementacin objeto sirviente; 4. escribir el cdigo de cliente. 2.2 Especificacin de la interfaz de Echo en IDL Definimos una interfaz objeto, llamado Echo, de la siguiente manera: interfaz Echo { echoString string (en mesg cadena); }; Por el momento, slo tiene que saber que la interfaz se compone de una sola operacin, echoString (), que toma una cadena como argumento de entrada y devuelve una copia de la misma cadena. La interfaz est escrita en un archivo, llamado echo.idl. Es parte del estndar CORBA que todos los archivos de IDL deben tener la extensin `. Idl ', aunque omniORB no hace cumplir esto. Por simplicidad, la interfaz se define en el espacio de nombres global IDL. Usted debe evitar esta prctica por el bien de reusabilidad. Si todos los desarrolladores de CORBA define sus interfaces en el espacio de nombres global IDL, existe el peligro de conflictos de nombre entre dos interfaces definidas de forma independiente. Por lo tanto, es mejor para calificar las interfaces mediante la definicin de ellos dentro de los nombres de mdulos. Por supuesto, esto no elimina la posibilidad de un conflicto de nombres a menos que algn tipo de convencin de nomenclatura se acord a nivel mundial. Sin embargo, un nombre de mdulo bien elegida puede ayudar mucho.

2.3 Generacin de los esquelos de C + + Desde el archivo IDL, usamos el compilador IDL para producir el C + + mapeo de la interfaz. El compilador IDL para omniORB se llama omniidl. Dado el archivo IDL, omniidl
JENNYFER OJEDA 7

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

produce dos archivos de cdigo auxiliar: un archivo de encabezado C + y un archivo fuente C + +. Por ejemplo, desde el echo.idl archivo, se producen los siguientes archivos:

echo.hh echoSK.cc

omniidl debe invocar con la opcin-bcxx argumento para decir que para generar recibos de C + +. La lnea de comandos siguiente genera los stubs para echo.idl: omniidl-bcxx echo.idl Si utiliza nuestro entorno make (ODE), no es necesario invocar omniidl explcitamente. En el dir.mk ejemplo de archivo, tenemos la siguiente lnea: CORBA_INTERFACES = eco Eso es todo lo que necesitamos para instruir ODE para generar los stubs. Recuerde, usted no encontrar los esqueletos en su directorio de trabajo, porque todos los talones se escriben en el directorio de cdigo auxiliar en el nivel superior de su rbol de construccin. 2.4 Referencias a objetos y Servidores Estamos en contacto con un objeto CORBA a travs de una referencia de objeto. La implementacin real de un objeto CORBA se denomina un sirviente. Las referencias a objetos y servidores son entidades muy distintas, y es importante no confundir los dos.

Advertencia omniORB 2.x no hizo uso de distintos tipos de referencias a objetos y servidores, ya a menudo se acepta un puntero a un sirviente cuando la especificacin CORBA dice que slo debera aceptar una referencia de objeto. Si tiene un cdigo que se basa en esto, no se compilar con 3.x omniORB o 4.x, incluso en el modo de compatibilidad BOA.

2.5 Un recorrido rpido de los esqueletos de C + +

JENNYFER OJEDA

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

Los talones de C + + se ajustan a la asignacin definida en la especificacin CORBA.Es importante entender la asignacin antes de empezar a escribir las aplicaciones CORBA. Antes de seguir adelante, vale la pena saber lo que el mapeo hace. Para el ejemplo de interfaz de Echo, la asignacin de C + + por su referencia a un objeto es Echo_ptr. El tipo se define en echo.hh. La seccin pertinente del cdigo se reproduce a continuacin. El cdigo auxiliar producida por otros ORB ser funcionalmente equivalente a omniORB de, pero es casi seguro que un aspecto muy diferente.
class Echo; class _objref_Echo; class _impl_Echo; typedef _objref_Echo* Echo_ptr; class Echo { public: // Declarations for this interface type. typedef Echo_ptr _ptr_type; typedef Echo_var _var_type; static _ptr_type _duplicate(_ptr_type); static _ptr_type _narrow(CORBA::Object_ptr); static _ptr_type _nil(); // ... methods generated for internal use }; class _objref_Echo : public virtual CORBA::Object, public virtual omniObjRef { public: char * echoString(const char* mesg); // ... methods generated for internal use };

En una aplicacin compatible, las operaciones definidas en una interfaz de objeto slo se podrn hacer valer a travs de una referencia de objeto. Esto se hace mediante el uso de la flecha (`-> ') en una referencia de objeto. Por ejemplo, la llamada a la echoString operacin () se escribira echoString obj-> (mesg). Cabe sealar que el tipo concreto de una referencia de objeto es opaco, es decir, que no se debe hacer ninguna suposicin sobre cmo se implementa una referencia de objeto. En nuestro ejemplo, a pesar de que Echo_ptr se implementa como un puntero a la clase _objref_Echo, no debe ser utilizado como un + + puntero de C, es decir, la conversin a void *, operaciones aritmticas y operaciones relacionales, incluyendo pruebas de la igualdad utilizando el operador ==, no debe llevar a cabo en el tipo.

JENNYFER OJEDA

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

Adems de la clase _objref_Echo, el mapeo define tres funciones estticas miembros de la clase Echo: _nil (), _duplicate (), y _narrow (). La funcin _nil () devuelve una referencia de objeto nula de la interfaz de Echo. La siguiente llamada se garantiza para devolver TRUE: CORBA :: true_result Boolean = CORBA :: is_nil (Echo :: _nil ()); Recuerda, CORBA :: is_nil () es la nica manera compatible para comprobar si una referencia de objeto es nulo. Usted no debe usar el operador de igualdad ==. Muchos ORB C + + utilizan el puntero nulo para representar una referencia de objeto nula; omniORB no lo hace. La funcin _duplicate () devuelve un nuevo objeto de referencia de la interfaz de Echo. La nueva referencia de objeto se puede usar de manera intercambiable con la antigua referencia de objeto al realizar una operacin en el mismo objeto. Se requieren Duplicaciones para satisfacer la gestin de memoria de recuento de referencia de C + + de mapeo. Todos los objetos CORBA heredan del objeto genrico CORBA :: Object. CORBA :: Object_ptr es el tipo de referencia de objeto para CORBA :: Object. Cualquier referencia a un objeto _ptr est, por tanto, conceptualmente heredado de CORBA :: Object_ptr. En otras palabras, una referencia de objeto, como Echo_ptr se puede utilizar en lugares donde se espera un CORBA :: Object_ptr. La funcin _narrow () toma un argumento de tipo CORBA :: Object_ptr y devuelve un nuevo objeto de referencia de la interfaz de Echo. Si el (tiempo de ejecucin) de tipo real de la referencia argumento de objeto se puede reducir a Echo_ptr, _narrow () devolver una referencia de objeto vlido. De lo contrario, devolver una referencia de objeto nula. Tenga en cuenta que _narrow () realiza una duplicacin implcita de la referencia de objeto, por lo que el resultado debe ser liberado. Tenga en cuenta tambin que_narrow () puede implicar una llamada remota para comprobar el tipo de objeto, por lo que puede lanzar excepciones del sistema CORBA como COMM_FAILURE oOBJECT_NOT_EXIST. Para indicar que ya no puede acceder a una referencia de objeto, debe llamar a la operacin CORBA :: Release (). Su firma es la siguiente:
namespaceCORBA { void release(CORBA::Object_ptr obj); ... // other methods };

Una vez que haya llamado CORBA :: Release () en una referencia de objeto, debe dejar de utilizar esa referencia. Esto es porque los recursos asociados pueden haber
JENNYFER OJEDA 10

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

sido desasignado. Ntese que nos estamos refiriendo a los recursos asociados a la referencia de objeto y no el objeto sirviente. Objetos sirvientes no se ven afectados por los tiempos de vida de las referencias a objetos. En particular, los funcionarios no se borran cuando todas las referencias a ellos han sido puestos en libertad --- CORBA no realiza la recoleccin de basura distribuida. Como se describi anteriormente, el == operador de igualdad no debe utilizarse en las referencias a objetos. Para probar si dos referencias a objetos son equivalentes, la funcin _is_equivalent miembro () del objeto genrico CORBA :: Object se puede utilizar. He aqu un ejemplo de su uso:
Echo_ptr A; ... // initialise A to a valid object reference Echo_ptr B = A; CORBA::Boolean true_result = A->_is_equivalent(B); // Note: the above call is guaranteed to be TRUE

Ahora ha sido introducido en la mayora de las operaciones que se pueden invocar mediante Echo_ptr. El objeto genrico CORBA :: Object proporciona algunas operaciones ms y todos ellos se puede invocar a travs Echo_ptr. Estas operaciones tienen que ver principalmente con interfaces dinmicas de CORBA. Usted no tiene que entender con el fin de utilizar la asignacin de C + + proporcionada a travs de los talones. Dado que las referencias a objetos deben ser liberados de forma explcita, su uso es propenso al error y puede llevar a la prdida de memoria. El mapeo define el tipovariable de referencia objeto de hacer la vida ms fcil. En nuestro ejemplo, el tipo de variable se define Echo_var 2 . El Echo_var es ms cmodo de usar, ya que lanzar automticamente su referencia a un objeto cuando se cancela o cuando se asigna una nueva referencia de objeto.Para muchas operaciones, mezclando datos de tipo Echo_var y Echo_ptr es posible sin ningn tipo de operaciones explcitas o fundicin 3 . Por ejemplo, la operacin echoString ()puede ser llamado usando la flecha (`-> ') en un Echo_var, como se puede ver con un Echo_ptr. El uso de Echo_var se ilustra a continuacin:
Echo_var a; Echo_ptr p = ... // somehow obtain an object reference a = p; // a assumes ownership of p, must not use p any more

Echo_var b = a; // implicit _duplicate p = ... // somehow obtain another object reference

11

JENNYFER OJEDA

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

a = Echo::_duplicate(p); // release old object reference // a now holds a copy of p.

2.5.1 Implementacin del Objeto Sirviente Antes de que la especificacin de Portable Object Adapter (POA), muchos de los detalles de cmo se deben implementar objetos sirvientes y registrados en el sistema eran no especificado, por lo que el cdigo de servidor no era portable entre ORB. La especificacin POA rectifica que. omniORB 4 todava apoya el viejo omniORB 2.x mapeo BOA, pero siempre se debe usar el mapeo POA para un cdigo nuevo. BOA cdigo y el cdigo POA pueden coexistir dentro de un mismo programa Para cada interfaz de objeto, se genera una clase de esqueleto. En nuestro ejemplo, la especificacin POA dice que la clase de esqueleto para la interfaz de Echo es nombrado POA_Echo. Una aplicacin servidor puede escribirse mediante la creacin de una clase de implementacin que se deriva de la clase esqueleto. El POA_Echo clase esqueleto se define en echo.hh. La seccin pertinente del cdigo se reproduce a continuacin.
class POA_Echo : public virtual PortableServer::ServantBase { public: Echo_ptr _this(); virtual char * echoString(const char* mesg) = 0; // ... };

El fragmento de cdigo muestra las nicas funciones miembro que se pueden utilizar en el cdigo de implementacin del objeto. Otras funciones miembro se generan slo para uso interno. Al igual que con el cdigo generado para referencias a objetos, otros ORB basado-POA generar cdigo que ser diferente, pero es funcionalmente equivalente a este. echoString () Es a travs de esta funcin abstracta que una clase de implementacin proporciona la implementacin de la operacin echoString (). Tenga en cuenta que su firma es la misma que la funcin echoString () que se puede invocar a travs de la referencia de objeto Echo_ptr. _This ()

JENNYFER OJEDA

12

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

Esta funcin devuelve una referencia de objeto para el objeto de destino, siempre y cuando las polticas POA permiten. El valor devuelto se debe desasignar mediante CORBA :: Release (). 2.6 Escribir la aplicacin sirviente Se define una clase de implementacin para proporcionar la aplicacin servidora. Hay pocas restricciones sobre la forma de disear su clase de implementacin, excepto que tiene que heredar de la clase esqueleto los talones 'y poner en prctica todas las funciones abstractos definidos en la clase de esqueleto. Cada una de estas funciones abstractas corresponde a una operacin de la interfaz. Son los ganchos para el ORB para realizar upcalls a su puesta en prctica. Aqu es un simple cumplimiento del objeto Echo.
class Echo_i : public POA_Echo, public PortableServer::RefCountServantBase { public: inline Echo_i() {} virtual ~Echo_i() {} virtual char* echoString(const char* mesg); }; char* Echo_i::echoString(const char* mesg) { return CORBA::string_dup(mesg); }

Hay cuatro puntos a tener en cuenta aqu: Responsabilidades de almacenamiento Una cadena, que se utiliza tanto como en el argumento y el valor de retorno de echoString (), es un tipo de datos de tamao variable. Otros ejemplos de los tipos de datos de tamao variable incluyen secuencias, escriba `cualquiera ', etc Para estos tipos de datos, debe ser claro acerca de quin es la responsabilidad de asignar y liberar el almacenamiento asociado. Como regla general, el cliente (o la persona que llama a las funciones de ejecucin) posee el almacenamiento de todos en los argumentos, la implementacin del objeto (o el destinatario de la llamada) deben copiar los datos si se quiere conservar una copia. Para argumentos OUT y valores de retorno, la implementacin del objeto asigna el almacenamiento y la pasa a la propiedad al cliente. El cliente debe liberar el almacenamiento cuando ya no se utilizan las variables. Para ms detalles, por favor refirase a la especificacin C + + mapeo.
JENNYFER OJEDA 13

DESARROLLO DE SISTEMAS DISTRIBUIDOS Multi-threading

4CV2

Como omniORB est totalmente multiproceso, mltiples hilos pueden realizar la misma llamada ascendente a su puesta en prctica al mismo tiempo. Depende de su aplicacin para sincronizar los hilos 'accede a los datos compartidos. En nuestro ejemplo simple, no tenemos datos compartidos para proteger lo que no es necesario realizar la sincronizacin de subprocesos. Como alternativa, puede crear un POA que tiene la Poltica SINGLE_THREAD_MODEL Tema. Esto garantiza que todas las llamadas a ese POA se procesan de forma secuencial. Referencia de conteo As como herencia de la clase esqueleto Echo, la clase de los sirvientes tambin se deriva de PortableServer :: RefCountServantBase que, como su nombre indica, es una clase mixin que proporciona el recuento de referencias para el objeto sirviente. Esto significa que se eliminar una instancia Echo_i cuando no hay ms referencias a ella estn en manos de cdigo de la aplicacin o el propio Plan de Accin. Tenga en cuenta que esto es totalmente independiente del recuento de referencias que se asocia con las referencias a objetos --- un objeto sirviente nunca se elimina debido a una referencia a un objeto CORBA ser liberado. Instantiation Siervos que se derivan de PortableServer :: RefCountServantBase no deben crear instancias como variables automticas (es decir, en la pila). En lugar de ello, siempre se debe crear una instancia de ellos mediante el operador new, es decir, su almacenamiento se asigna en el montn. De lo contrario, el POA puede intentar eliminar un objeto en la pila. 2.7 Escribiendo el cliente
He aqu un ejemplo de cmo se utiliza una referencia de objeto Echo_ptr. void hello(CORBA::Object_ptr obj) { Echo_var e = Echo::_narrow(obj); if (CORBA::is_nil(e)) { cerr << "cannot invoke on a nil object reference." << endl; return; }

JENNYFER OJEDA

14

DESARROLLO DE SISTEMAS DISTRIBUIDOS

CORBA::String_var src = (const char*) "Hello!"; CORBA::String_var dest; dest = e->echoString(src); cerr << "I said,\"" << src << "\"." << " The Object said,\"" << dest <<"\"" << endl;

4CV2

En pocas palabras, la funcin hola () acepta una referencia a un objeto genrico. La referencia de objeto (obj) se redujo a Echo_ptr. Si la referencia de objeto devuelto porEcho :: _narrow () no es nulo, se invoca la operacin echoString (). Por ltimo, tanto el argumento y el valor de retorno de echoString () se imprimen en cerr. El ejemplo tambin muestra cmo se utilizan los tipos T_var. Como se explic en la seccin anterior, los tipos T_var cuidar de asignacin de almacenamiento y liberan automticamente cuando se vuelven a asignar las variables o cuando las variables fuera de mbito. En la lnea 4, la variable e se hace cargo de la responsabilidad de almacenamiento de la referencia de objeto devuelto por Echo :: _narrow (). La referencia de objeto es lanzado por el destructor de correo. Se llama automticamente cuando la funcin devuelve. Lneas 6 y 15 muestran cmo se utiliza una variable Echo_var. Como se explic anteriormente, el tipo Echo_var se puede utilizar de forma intercambiable con el tipo Echo_ptr. El argumento y el valor de retorno de echoString () se almacenan en las variables CORBA :: String_var src y dest respectivamente. Las cadenas administradas por las variables se cancela la asignacin por el destructor de CORBA :: String_var. Se llama automticamente cuando la variable est fuera de mbito (como la funcin devuelve). La lnea 15 muestra cmo CORBA :: se utilizan variables de String_var. Se pueden utilizar en lugar de una cadena (para el que el mapeo es char *) 4 . Tal como se utiliza en la lnea 12, la asignacin de una cadena constante (const char *) a un CORBA :: String_var hace que la cadena que se va a copiar. Por otra parte, la asignacin de un char * a un CORBA :: String_var, tal como se utiliza en la lnea 15, hace que este ltimo asuma la propiedad de la cadena 5 . Bajo el + + cartografa C, se proporcionan los tipos T_var para todos los tipos de datos no bsicos. Es obvio que uno debe usar variables automticas siempre que sea posible tanto para evitar las prdidas de memoria y para maximizar el rendimiento. Sin embargo, cuando uno tiene que asignar los elementos de datos en el montn, es una buena prctica utilizar los tipos T_var para administrar el almacenamiento en pilas.

JENNYFER OJEDA

15

DESARROLLO DE SISTEMAS DISTRIBUIDOS 2.8 Ejemplo 1 --- Colocando el Cliente y la Implementacin

4CV2

Despus de haber introducido el cliente y la implementacin del objeto, ahora podemos describir la forma de vincular a los dos a travs del ORB y el POA. En esta seccin, se describe un ejemplo en el que el cliente y la implementacin del objeto estn en el mismo espacio de direcciones. En las dos secciones siguientes, vamos a describir el caso en que los dos estn en diferentes espacios de direcciones. El cdigo de este ejemplo se reproduce a continuacin:

int main(int argc, char **argv) { CORBA::ORB_ptr orb = CORBA::ORB_init(argc,argv,"omniORB4"); CORBA::Object_var obj = orb->resolve_initial_references("RootPOA"); PortableServer::POA_var poa = PortableServer::POA::_narrow(obj); Echo_i *myecho = new Echo_i(); PortableServer::ObjectId_var myechoid = poa->activate_object(myecho); Echo_var myechoref = myecho->_this(); myecho->_remove_ref(); PortableServer::POAManager_var pman = poa->the_POAManager(); pman->activate(); hello(myechoref); orb->destroy(); return 0;

El ejemplo ilustra varias interacciones importantes entre el ORB, el POA, el siervo y el cliente. Aqu estn los detalles: 2.8.1 ORB Inicializacin Lnea 4 El ORB se inicializa llamando a la CORBA :: ORB_init () funcin. La funcin utiliza la tercera argumento opcional para determinar qu ORB debe ser devuelto. A menos que utilice omniORB caractersticas especficas, por lo general es mejor dejarlo fuera, y obtener el ORB predeterminado. Para pedir explcitamente omniORB 4.0, este argumento debe ser `omniORB4 ' 6 .

JENNYFER OJEDA

16

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

CORBA :: ORB_init () toma la lista de argumentos de la lnea de comando y los procesos de los que se inician `-ORB '. Se elimina estos argumentos de la lista, por lo que el cdigo de aplicacin no tiene que tratar con ellos. Si se produce algn error durante la inicializacin del ORB, como argumentos ORB no vlidos o un archivo de configuracin no vlida, el CORBA :: Initialize se eleva excepcin del sistema. 2.8.2 Obtencin del POA Root Lneas 6-7 Para activar nuestro objeto servidor y ponerla a disposicin de los clientes, hay que registrarlo con un POA. En este ejemplo, se utiliza el POA Root, en lugar de crear ningn nio POAs. El POA Raz se encuentra con resolve_initial_references orbe-> (), que devuelve un CORBA llanura :: Object. En la lnea 7, que reducen la referencia al tipo correcto para un POA. El comportamiento de un POA se rige por sus polticas. El POA Root tiene polticas adecuadas para muchos servidores simples, y estrechamente coincide con la `poltica 'utilizado por la Junta de Auditores de omniORB 2. Consulte el Captulo 11 de la especificacin CORBA 2.6 [ OMG01 ] para ms detalles de todas las polticas del POA que estn disponibles. 2.8.3 Objeto de inicializacin Lnea 9 Una instancia del servidor Echo se inicializa mediante el operador new. Lnea 10 El objeto sirviente se activa en el POA Root usando poa-> activate_object (), que devuelve un identificador de objeto (de tipo PortableServer :: ObjectId *). El identificador de objeto se debe pasar de nuevo a diversas operaciones POA. El llamador es responsable de liberar el identificador de objeto, por lo que se le asigna a un tipo _var. Lnea 12 La referencia de objeto se obtiene del objeto sirviente llamando _Esta (). Al igual que todas las referencias a objetos, el valor de retorno de _Esta () debe ser puesto en libertad por CORBA :: Release () cuando ya no es necesaria. En este caso, se asigna a un tipo _var, por lo que la liberacin est implcito al final de la funcin.
JENNYFER OJEDA 17

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

Una de las caractersticas importantes de una referencia de objeto es que es completamente transparente ubicacin. Un cliente puede invocar en el objeto mediante su referencia a un objeto sin necesidad de saber si el objeto sirviente lugar junto en el mismo espacio de direcciones o se encuentra en un espacio de direcciones diferente. En el caso del cliente colocated y sirviente, omniORB es capaz de cortocircuitar el cliente llama para que no implican IIOP. Las llamadas siguen pasando por el POA, sin embargo, por lo que las diferentes polticas afectan POA llamadas locales en la misma manera como los remotos. Esta optimizacin es aplicable no slo a referencias de objetos devueltos por _Esta (), sino a todas las referencias de objetos que se pasan todo dentro del mismo espacio de direcciones o recibidos desde otros espacios de direcciones a travs de las llamadas remotas. Lnea 13 El cdigo del servidor libera la referencia que contiene al objeto sirviente. La nica referencia a ese objeto est ahora en manos de la POA (gan la referencia en la llamada a activate_object ()), por lo que cuando el objeto se desactiva (o el POA se destruye), el objeto sirviente se eliminar automticamente. Despus de este punto, el cdigo ya no debe utilizar el puntero myecho. 2.8.4 Activacin del POA Lneas 15-16 POAs estn inicialmente en el estado de retencin, lo que significa que las peticiones entrantes se bloquean. Lneas 15 y 16 adquieren una referencia al administrador de POA del POA, y lo utilizan para poner el POA en el estado activo. Ahora se sirven peticiones entrantes. El no poder activar el POA es uno de los errores de programacin ms comunes. Si su programa parece estancado, asegrese de que ha activado el POA! 2.8.5 Realizacin de una llamada Lnea 18 Por fin, podemos llamar hola () con esta referencia de objeto. El argumento se ampli implcitamente al CORBA referencia de objeto genrico :: Object_ptr. 2.8.6 destruccin ORB Lnea 20

JENNYFER OJEDA

18

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

Apagar el ORB de forma permanente. Esta llamada hace que el ORB para liberar todos sus recursos, por ejemplo, las discusiones internas, y tambin para desactivar cualquier objetos sirvientes que estn actualmente activos. Cuando se desactiva la instancia Echo_i, contador de referencia del siervo cae a cero, por lo que se elimina el siervo. La llamada es especialmente importante cuando se escribe un archivo DLL CORBA en Windows NT que se va a utilizar de ActiveX. Si esta llamada no est presente, la aplicacin se bloquea cuando el CORBA DLL se descarga.

DESARROLLO PRCTICO
Cdigo Makefile
GPP := g++ LIBS := -lomniORB4 -lomnithread SHELL=/bin/bash LIBJSON = /home/samarkanov/Prog/libjson all: calcu clean: done rm -r -f $(CURDIR)/calcu/bin ; \ rm -r -f $(CURDIR)/calcu/include ; \

La prctica se desarrollo de manera que el servidor estuviera en Python y el cliente en C++,tambin se implemento un makefile para que de esta manera rpidamente se compilara.

calcu: calcus @echo "Compile `basename $@`..." $(GPP) -Wall -I$(EX)/include $(EX)/src/cliente.cc $(LIBS) -o $(EX)/bin/cliente.out cp $(EX)/src/servidor.py $(EX)/bin/servidor.py calcus: @echo "Compile `basename $@`..." $(eval EX := $(CURDIR)/calcu) mkdir -p $(EX)/include $(EX)/bin omniidl -bcxx -C$(EX)/include $(EX)/echo.idl omniidl -bpython -C$(EX)/include $(EX)/echo.idl

JENNYFER OJEDA

19

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

Echo.idl
interface Echo { string echoString(in string mesg,in string a,in string b); string suma(in string a,in string b); string promedio(in string a,in string b); string mayor(in string a,in string b); string menor(in string a,in string b); string burbuja(in string a,in string b); string seleccion(in string a,in string b); string quicksort(in string a,in string b); string valor(in string a,in string b); string factorial(in string a,in string b); string fibonacci(in string a,in string b); };

Servidor.py
# -*- coding: utf-8 -*import sys from omniORB import CORBA, PortableServer import math sys.path.append("../include") import CosNaming, _GlobalIDL, _GlobalIDL__POA import echo_idl # Define an implementation of the Echo interface class Echo_i (_GlobalIDL__POA.Echo): def echoString(self, mesg,a,b): r=0 c=0 valor=3 print "La operacion a realizar es", mesg,"con los numeros",a,"y",b if mesg=='suma': r=(float(a)+float(b)) if mesg=='promedio': r=(float(a)+float(b))/2 if mesg=='mayor': if float(a)>float(b): r = float(a) elif float(b)>float(a): r=float(b) else: print "Los numeros son iguales" if mesg=='menor': if float(a)<float(b): r = float(a)
JENNYFER OJEDA 20

DESARROLLO DE SISTEMAS DISTRIBUIDOS

elif float(b)<float(a): r=float(b) else: print "Los nmeros son iguales" if mesg=='burbuja': if float(a)>float(b): r = float(a) elif float(b)>float(a): r=float(b) else: print "El nmero mayor del metodo Burbuja" if mesg=='seleccion': if float(a)>float(b): r = float(a) elif float(b)>float(a): r=float(b) else: print "El nmero mayor del metodo Seleccion" if mesg=='quicksort': if float(a)>float(b): r = float(a) elif float(b)>float(a): r=float(b) else: print "El nmero mayor del metodo Quicksort" if mesg=='valor': if float(a)== valor: r=float(a) elif float(b)==valor: r=float(b) else: print "El valor no se encuentra" if mesg=='factorial': if float(a) == 0: r=float(a)+1 elif float(a) == 1: r=float(a) else: print "factorial" for i in range(1,int(a)+1): r=float(b)*i r=float(r) if mesg=='fibonacci': c, d = 0, 1 for i in range(1,int(a)): c, d = d, c + d r=float(c)

4CV2

JENNYFER OJEDA

21

DESARROLLO DE SISTEMAS DISTRIBUIDOS

ret=str(r) return ret def suma(self, a, b): print "suma() called with values:",a,",",b return long(a)+long(b) def promedio(self, a, b): print "promedio() called with values:",a,",",b return long(a)+long(b) def mayor(self, a, b): print "mayor() called with values:",a,",",b return long(a)+long(b) def menor(self, a, b): print "menor() called with values:",a,",",b return long(a)+long(b) def burbuja(self, a, b): print "burbuja() called with values:",a,",",b return long(a)+long(b) def seleccion(self, a, b): print "seleccion() called with values:",a,",",b return long(a)+long(b) def quicksort(self, a, b): print "quicksort() called with values:",a,",",b return long(a)+long(b) def valor(self, a, b): print "valor() called with values:",a,",",b return long(a)+long(b) def factorial(self, a, b): print "factorial() called with values:",a,",",b return long(a)+long(b) def fibonacci(self, a, b): print "fibonacci() called with values:",a,",",b return long(a)+long(b) # Initialise the ORB and find the root POA orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID) poa = orb.resolve_initial_references("RootPOA") # Create an instance of Echo_i and an Echo object reference ei = Echo_i() eo = ei._this() # Obtain a reference to the root naming context obj = orb.resolve_initial_references("NameService") rootContext = obj._narrow(CosNaming.NamingContext) if rootContext is None: print "Failed to narrow the root naming context" sys.exit(1) # Bind a context named "test.my_context" to the root context name = [CosNaming.NameComponent("test", "my_context")] try:
JENNYFER OJEDA

4CV2

22

DESARROLLO DE SISTEMAS DISTRIBUIDOS

testContext = rootContext.bind_new_context(name) print "New test context bound" except CosNaming.NamingContext.AlreadyBound, ex: print "Test context already exists" obj = rootContext.resolve(name) testContext = obj._narrow(CosNaming.NamingContext) if testContext is None: print "test.mycontext exists but is not a NamingContext" sys.exit(1) # Bind the Echo object to the test context name = [CosNaming.NameComponent("Echo", "Object")] try: testContext.bind(name, eo) print "New Echo object bound" except CosNaming.NamingContext.AlreadyBound: testContext.rebind(name, eo) print "Echo binding already existed -- rebound" # Activate the POA poaManager = poa._get_the_POAManager() poaManager.activate() # Block for ever (or until the ORB is shut down) orb.run()

4CV2

Cliente.cc
// eg3_clt.cc - This is the source code of example 3 used in Chapter 2 // "The Basics" of the omniORB user guide. // // This is the client. It uses the COSS naming service // to obtain the object reference. // // Usage: eg3_clt // // // On startup, the client lookup the object reference from the // COS naming service. // // The name which the object is bound to is as follows: // root [context] // | // text [context] kind [my_context] // | // Echo [object] kind [Object] // #include "echo.hh"
JENNYFER OJEDA 23

DESARROLLO DE SISTEMAS DISTRIBUIDOS

#include "echoSK.cc" #include <iostream> #include<stdlib.h> using namespace std; static CORBA::Object_ptr getObjectReference(CORBA::ORB_ptr orb); static void operar(Echo_ptr e,int op,char *ain,char *bin){ if( CORBA::is_nil(e) ) { cout << "hello: The object reference is nil!\n" << endl; return; } CORBA::String_var suma = (const char*) "suma"; CORBA::String_var promedio= (const char*) "promedio"; CORBA::String_var mayor= (const char*) "mayor"; CORBA::String_var menor= (const char*) "menor"; CORBA::String_var burbuja= (const char*) "burbuja"; CORBA::String_var seleccion= (const char*) "seleccion"; CORBA::String_var quicksort= (const char*) "quicksort"; CORBA::String_var valor= (const char*) "valor"; CORBA::String_var factorial= (const char*) "factorial"; CORBA::String_var fibonacci= (const char*) "fibonacci"; CORBA::String_var a = (const char*) ain; CORBA::String_var b = (const char*) bin; CORBA::String_var dest; if(op==1){ dest = e->echoString(suma,a,b); cout << (char*)dest<<"\n"<< endl; }else if(op==2){ dest = e->echoString(promedio,a,b); cout << (char*)dest<<"\n"<< endl; }else if(op==3){ dest = e->echoString(mayor,a,b); cout << (char*)dest<<"\n"<< endl; }else if(op==4){ dest = e->echoString(menor,a,b); cout << (char*)dest<<"\n"<< endl; }else if(op==5){ dest = e->echoString(burbuja,a,b); cout << (char*)dest<<"\n"<< endl; }else if(op==6){ dest = e->echoString(seleccion,a,b); cout << (char*)dest<<"\n"<< endl; }else if(op==7){ dest = e->echoString(quicksort,a,b); cout << (char*)dest<<"\n"<< endl; }else if(op==8){ dest = e->echoString(valor,a,b); cout << (char*)dest<<"\n"<< endl;
JENNYFER OJEDA

4CV2

24

DESARROLLO DE SISTEMAS DISTRIBUIDOS

}else if(op==9){ dest = e->echoString(factorial,a,b); cout << (char*)dest<<"\n"<< endl; }else if(op==10){ dest = e->echoString(fibonacci,a,b); cout << (char*)dest<<"\n"<< endl; }

4CV2

////////////////////////////////////////////////////////////////////// int main (int argc, char **argv){ try { CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); CORBA::Object_var obj = getObjectReference(orb); Echo_var echoref = Echo::_narrow(obj); for (CORBA::ULong count=0; count < 1; count++) operar(echoref,atoi(argv[1]),argv[2],argv[3]); //for (CORBA::ULong count=0; count < 1; count++) //suma(echoref); orb->destroy(); }catch(CORBA::TRANSIENT&) { cout << "Caught system exception TRANSIENT -- unable to contact the " << "server." << endl; }catch(CORBA::SystemException& ex) { cout << "Caught a CORBA::" << ex._name() << endl; }catch(CORBA::Exception& ex) { cout << "Caught CORBA::Exception: " << ex._name() << endl; }catch(omniORB::fatalException& fe) { cout << "Caught omniORB::fatalException:" << endl; cout << " file: " << fe.file() << endl; cout << " line: " << fe.line() << endl; cout << " mesg: " << fe.errmsg() << endl; } return 0;

////////////////////////////////////////////////////////////////////// static CORBA::Object_ptr getObjectReference(CORBA::ORB_ptr orb){ CosNaming::NamingContext_var rootContext; try { // Obtain a reference to the root context of the Name service:
JENNYFER OJEDA 25

DESARROLLO DE SISTEMAS DISTRIBUIDOS

CORBA::Object_var obj; obj = orb->resolve_initial_references("NameService"); // Narrow the reference returned. rootContext = CosNaming::NamingContext::_narrow(obj); if( CORBA::is_nil(rootContext) ) { cout << "Failed to narrow the root naming context." << endl; return CORBA::Object::_nil(); } }catch (CORBA::NO_RESOURCES&) { cout << "Caught NO_RESOURCES exception. You must configure omniORB " << "with the location" << endl << "of the naming service." << endl; return 0; }catch(CORBA::ORB::InvalidName& ex) { // This should not happen! cout << "Service required is invalid [does not exist]." << endl; return CORBA::Object::_nil(); } // Create a name object, containing the name test/context: CosNaming::Name name; name.length(2); name[0].id = (const char*) "test"; // string copied name[0].kind = (const char*) "my_context"; // string copied name[1].id = (const char*) "Echo"; name[1].kind = (const char*) "Object"; // Note on kind: The kind field is used to indicate the type // of the object. This is to avoid conventions such as that used // by files (name.type -- e.g. test.ps = postscript etc.) try { // Resolve the name to an object reference. return rootContext->resolve(name); }catch(CosNaming::NamingContext::NotFound& ex) { // This exception is thrown if any of the components of the // path [contexts or the object] aren't found: cout << "Context not found." << endl; }catch(CORBA::TRANSIENT& ex) { cout << "Caught system exception TRANSIENT -- unable to contact the " << "naming service." << endl << "Make sure the naming server is running and that omniORB is " << "configured correctly." << endl; }catch(CORBA::SystemException& ex) { cout << "Caught a CORBA::" << ex._name() << " while using the naming service." << endl; return 0; } return CORBA::Object::_nil();
JENNYFER OJEDA

4CV2

26

DESARROLLO DE SISTEMAS DISTRIBUIDOS

}

4CV2

Capturas de pantalla
Previamente debemos tener instalado el OMNIORB as como los compiladores de Python y de C++ Para instalar el OMNIORB necesitamos primero actualizar

Posteriormente ejecutamos el siguiente comando: sudo aprt-get install omniorb-idl

O si lo prefieren pueden instalar el omniorb desde el synaptics,seleccionen todos los paquetes e instalenlos Ya que nos situemos en la carpeta donde esta la Calculadora ejecutamos el siguiente comando: make calcu

Observamos que al compilar se generarn varios archivos dentro de la carpeta Include

En la carpeta Bin se generarn los ejecutables

JENNYFER OJEDA

27

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

Abrimos una consola para el cliente y otra para el servidor situndonos en donde estn los ejecutables es decir en Bin,primero ejecutamos el servidor Python servidor.py

Ya luego, en la consola dedicada al cliente ingresamos la siguiente instruccin ./cliente.out opcin numero1 numero2

JENNYFER OJEDA

28

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

CONCLUSIONES

En el presente ejercicio se conoci acerca de Corba su uso es muy parecido a RMI: Los modelos de objetos subyacentes a Java y a CORBA se complementan: Ambos modelos soportan el concepto de Interfaces Abstractas. Los tipos de datos que se manejan en el IDL corresponden de manera natural a los tipos de datos de Java. Sus mecanismos de herencia son casi idnticos. Los mdulos de CORBA corresponden directamente a los paquetes (packages) de Java.

Adems de que ambas tecnologas tienen un modelo de objetos muy compatibles, el papel que cada una de ellas juega en la construccin de sistemas se complementan entre si de manera natural. Es decir, Java permite crear objetos portables y los distribuye de manera sencilla mientras que CORBA permite interconectar dichos objetos e integrarlos con el resto de los sistemas de

JENNYFER OJEDA

29

DESARROLLO DE SISTEMAS DISTRIBUIDOS

4CV2

cmputo existentes, o bien con aplicaciones de objetos escritas en otros lenguajes.

BIBLIOGRAFA

http://omniorb.sourceforge.net/omni40/omniORB/omniORB002.html http://www.cl.cam.ac.uk/research/dtg/attarchive/omniORB/omniORBpy/ http://es.wikipedia.org/wiki/CORBA

JENNYFER OJEDA

30