Arquitecturas Distribuidas en Redes Heterogneas Prcticas en CORBA

Curso 2010-2011
Rev-20101028

1.
1.1.

Introduccin
Qu es CORBA?

CORBA (Common Object Request Broker Architecture) es un estndar que dene una plataforma para el desarrollo de sistemas distribuidos basados en el paradigma de orientacin a objetos. La norma est denida por el OMG (Object Management Group, autores tambin del estndar UML) mediante un conjunto de APIs, protocolos de comunicacin y mecanismos que garantizan la interoperabilidad entre aplicaciones independientemente de la plataforma y del lenguaje de implementacin. Conceptualmente, CORBA se asemeja bastante a Java RMI. Sin embargo, posee ciertas caractersticas que lo hacen diferente. La principal de ellas es que CORBA es agnstico respecto del lenguaje de programacin. Tal y como veremos ms adelante, las interfaces de los objetos se denen mediante un lenguaje denominado IDL (Interface Description Language). A partir de dicho lenguaje, se generarn los stubs y skeletons correspondientes en el lenguaje de implementacin. La infraestructura CORBA proporciona protocolos interoperables que garantizan el correcto paso de mensajes independientemente del lenguaje empleado (cliente y servidor pueden estar escritos en distintos lenguajes). Es importante destacar que CORBA es una especicacin pblica, no un producto. Los distintos estndares que denen la norma pueden ser seguidos para crear diversas implementaciones, garantizando la independencia respecto al suministrador. Al tratarse de un estndar, la interoperabilidad entre distintas implementaciones est garantizada.

Figura 1: Funcionamiento bsico de RMI

1.2.

Cmo funciona CORBA?

El funcionamiento bsico de CORBA pasa por la denicin de las interfaces de los componentes mediante el lenguaje IDL. Este lenguaje descriptivo nos proporciona mecanismos para denir tipos, mdulos, interfaces, operaciones, excepciones, etc. De esta forma, el programador puede denir la forma que tendrn los componentes de su sistema. Tras esto, el cdigo IDL ser compilado al lenguaje de implementacin (siguiendo unas reglas de mapping estandarizadas), generando los stubs del cliente y los skeletons del servidor. La gura 2 muestra un ejemplo de las interfaces y clases generadas para el caso del lenguaje Java a partir de la denicin de una calculadora en IDL.

Figura 2: Compilacin de una calculadora IDL a lenguaje Java En dicha compilacin de IDL a JAva, se generan los siguientes elementos bsicos con los que vamos a trabajar: La interfaz de operaciones, en este caso CalculatorOperations. Esta interfaz incluye todas las operaciones denidas en el chero IDL para nuestra calculadora. La clase base del servant, en este caso CalculatorPOA. En CORBA se denomina servant al objeto que encarna el comportamiento del objeto remoto. Tener claro este concepto es muy importante, ya que resulta clave a la hora de comprender cmo se comporta un servidor CORBA. Pensemos en los objetos remotos como si fueran personas en una pelcula u obra de teatro y, en los servants como actores que interpretan esos personajes o papeles. A la hora de dar comportamiento a nuestra calculadora (es decir, implementar sus operaciones) deberemos crear una nueva clase que extienda de esta, generalmente aadiendo el sujo Impl al nal para evitar confusiones (en nuestro caso, CalculatorImpl). Por supuesto, esta nueva clase deber implementar las operaciones de nuestra calculadora. La interfaz del objeto remoto, en nuestro caso Calculator. Esta interfaz, que extiende tanto CalculatorOperations como CORBA.Object representa al objeto calculadora remoto para ser empleado desde los clientes.

La clase stub, en este caso _CalculatorStub. Esta clase acta de stub o proxy del objeto remoto, implementando las mismas operaciones que la calculadora. Esta clase nunca es instanciada directamente desde el cdigo del cliente, sino que se obtiene un objeto de la misma en forma de la interfaz Calculator. Adicionalmente, se generarn otras clases que complementan a las anteriores. La clase helper, en nuestro caso CalculatorHelper. Esta clase ofrece un conjunto de operaciones auxiliares para la conversin de objetos del tipo Calculator, serializaciones, etc. La clase holder, en nuestro caso CalculatorHolder. En Remoting vimos que los parmetros de una invocacin a mtodo remoto se pasaban por valor, es decir, en modo in (excepto los objetos que tambin son remotos). CORBA permite especicar tres tipos diferentes de modo de pas de parmetros con una semntica similar a la de Ada95: in, inout y out. En este ltimo caso, la clase holder permite encapsular el objeto pasado como parmetro para que pueda ser manipulado por el servant. Como vemos, gran parte de la magia de CORBA se obtiene a partir de la compilacin de cheros IDL. Pero necesitamos algo ms. Necesitamos un mecanismo para desplegar objetos remotos y instanciarlos. Esto, se consigue mediante los siguientes elementos: ORB (Object Request Broker). Este artefacto, ofrecido en forma de clase singleton, ofrece un conjunto de funcionalidades que permite establecer una serie de propiedades del middleware, instanciar objetos remotos, resolver y registrar servicios, etc. Portable Server. El despliegue de objetos remotos no es trivial. A menudo, en sistemas complejos resulta necesario contar con mecanismos que proporcionen un gran control sobre los componentes a desplegar. Para evitar que dichos mecanismos sean implementados por los fabricantes sin interoperabilidad alguna, CORBA dene en su estndar un conjunto de artefactos que satisfacen estas necesidades: POA o Portable Object Adapter. Esta abstraccin proporciona mecanismos para desplegar objetos remotos bajo un conjunto de polticas que condicionan su comportamiento en lo que al despliegue se reere. Los POA se disponen en una estructura jerrquica, a partir de un POA raz desde el cual podemos crear nuevos POA hijos, formando un rbol. POA Manager. Cada POA tiene asociado un POA Manager, pudiendo varios de ellos compartir el mismo. Esta abstraccin controla el comportamiento en ejecucin de los objetos, deniendo polticas de tratamiento de peticiones, modelo de multiprocesamiento, etc. CORBA es bien conocido por su complejidad. Sus diseadores pensaron en una solucin que cubriera mediante un estndar todas las necesidades de la industria en cuanto a lo que debe proporcionar un middleware. Esto, casi de manera inevitable, supone un sistema complejo. El objetivo de esta prctica es proporcionar una vista general de CORBA a travs de algunos ejemplos prcticos. No te preocupes si todos estos conceptos quedan algo confusos, ya que los comprenders mejor con los casos prcticos.

1.3.

Preguntas
Hemos visto que existe una diferencia clara entre un objeto remoto y el servant que lo encarna. Entiendes correctamente esta diferencia? Crees que sera posible que un mismo objeto remoto fuese encarnado por varios servants? Recuerdas el modo de vida SingleCall de Remoting? Crees que tiene relacin? Sera posible lo contrario, que varios objetos remotos fuesen encarnados por el mismo servant? Se te ocurre un escenario en el que esto tuviera sentido? 3

Hemos visto que el cdigo IDL generar un stub que implementa las operaciones de la calculadora. Pero... qu hacen esas operaciones? Qu contiene su implementacin? Cul es el comportamiento que tienen asociado? Suman y multiplican o hacen otra cosa diferente? Hemos visto que la clase CalculatorHolder se usa para contener objetos en el caso de que una calculadora se pase como parmetro out. Entiendes claramente el motivo? Entiendes que en Java no se puede devolver un nuevo objeto a travs de un argumento?

2.

Primera parte: una calculadora local

Vamos a comenzar realizando un ejercicio de implementacin de una calculadora no distribuida. Para ello, crearemos una clase CalculatorImpl como la siguiente1 :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

/* : CalculatorImpl.java * File * Description : A simple non-distributed calculator class. * */ public class CalculatorImpl { public float add(float lhs, float rhs) { return lhs + rhs; } public float multiply(float lhs, float rhs) { return lhs * rhs; } }

Ahora crearemos un programa cliente que haga uso de esa calculadora:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

/* : Client.java * File * Description : A simple client which uses a non-distributed calculator. * */ public class Client { public static void main(String args[]) { // Create the calculator. CalculatorImpl cal = new CalculatorImpl(); // Use the calculator. try { System.out.println("Adding: 5 + 3 = " + cal.add(5,3));

1 Un consejo!! Nos guste o no, la mayor parte de los profesionales tcnicos de este planeta se comunican en ingls. Suele ser una buena idea escoger identicadores en ese idioma (Calculator en lugar de Calculadora), escribir comentarios, etc, para que cualquiera pueda entender tu programa. Nunca se sabe en qu manos puede caer tu cdigo!

19 20 21 22 23 24 25 26

System.out.println("Multiplying: 10 * 2 = " + cal.multiply(10,2)); } catch (Exception ex) { System.out.println("Unexpected error was ocurred."); ex.printStackTrace(); } } }

Con esto, podemos compilar nuestros cheros y ejecutar la prueba.

3.

Segunda parte: una calculadora distribuida

Ahora vamos a construir nuestra calculadora, esta vez para que pueda ser distribuida a travs de CORBA.

3.1.

Preparacin del entorno

Antes de nada, vamos a preparar el entorno para poder crear y ejecutar aplicaciones CORBA. Como discutimos anteriormente, CORBA es una especicacin que cualquier fabricante puede desarrollar, quedando garantizada la interoperabilidad entre distintas implementaciones. En nuestro caso, vamos a emplear la implementacin de Sun que acompaa al SDK de Java. Tanto Netbeans como Eclipse, no cuentan de manera predeterminada con soporte para desarrollar con CORBA. Esto supone que la generacin de fuentes a partir de cheros IDL deber efectuarse manualmente (o bien hacer uso de algn plugin que facilite la tarea). A lo largo de este guin de prcticas, se proporcionarn fragmentos de cdigo de ejemplo. Es posible hacer uso de cualquier IDE para desarrollar, pero nicamente se proporcionarn instrucciones de compilacin manual.

3.2.

Denicin de las interfaces IDL

Anteriormente denimos una calculadora en Java para ser usada localmente. Llegado a este punto, vamos a denir la interfaz de la misma calculadora empleando el lenguaje IDL:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

/* : mymath.idl * File * Description : A math module which contains a calculator. */ module mymath { interface Calculator { float add(in float lhs, in float rhs); float multiply(in float lhs, in float rhs); }; };

Para compilar este chero y generar el cdigo Java correspondiente, invocaremos el compilador de IDL a Java de Sun.

idlj -f all mymath.idl

Observars que este comando ha creado un nuevo directorio mymath/. Echa un vistazo al contenido y trata de identicar las clases e interfaces descritas en la seccin primera. Ahora vamos a llevar a cabo un pequeo cambio en la implementacin de nuestra calculadora. Deniremos de nuevo el chero CalculatorImpl.java con el siguiente contenido:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

/* : CalculatorImpl.java * File * Description : A simple CORBA-distributed (servant) calculator class * */ import mymath.CalculatorPOA; public class CalculatorImpl extends CalculatorPOA { public float add(float lhs, float rhs) { return lhs + rhs; } public float multiply(float lhs, float rhs) { return lhs * rhs; } }

Como se puede observar, tan solo hemos hecho que nuestra clase herede de CalculatorPOA, importando la misma desde el paquete mymath. Ahora vamos a hacer algo un poco ms complejo: implementar el servidor. Para ello, emplearemos el siguiente cdigo:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

/* : Server.java * File * Description : A calculator server. * */ import java.util.Properties; import java.io.*; import import import import org.omg.CosNaming.*; org.omg.CosNaming.NamingContextPackage.*; org.omg.CORBA.*; org.omg.PortableServer.*;

public class Server { public static void main(String args[]) { try

20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

{ // Initialize the ORB. ORB orb = ORB.init(args, null); // Obtain the root POA instance POA rootpoa = POAHelper.narrow( orb.resolve_initial_references("RootPOA")); // Activate the root POA to accept incoming requests rootpoa.the_POAManager().activate(); // Create the servant object CalculatorImpl cal = new CalculatorImpl(); // Register the object in the root POA and obtain a // reference for the object org.omg.CORBA.Object ref=rootpoa.servant_to_reference(cal); // Write the object reference into a file try { String reference = orb.object_to_string(ref); PrintStream ofile = new PrintStream( new FileOutputStream("calculator.ior")); ofile.println(reference); ofile.close(); } catch (IOException ex) { System.out.println("File error"); } System.out.println("Server ready and waiting for requests ..."); orb.run(); } catch (Exception e) { System.err.println("ERROR: " + e); e.printStackTrace(System.out); } System.out.println("Server is shutdown ..."); } }

Este cdigo es sustancialmente ms complejo e ilustra la forma en que un servidor CORBA se despliega. La primera lnea del programa principal (22) inicializa el ORB usando el patrn singleton que proporciona dicha clase. Tras ello, emplearemos la interfaz que nos ofrece este para obtener una referencia al POA raz (lnea 25), lo activaremos para que pueda recibir peticiones (lnea 29), crearemos nuestro servant (lnea 32) y lo registraremos en el POA como un nuevo objeto remoto (lnea 36). A partir de este momento, nuestro servidor puede comenzar a atender llamadas al objeto calculadora. No obstante, para facilitar la localizacin, el servidor rescata la referencia del objeto en formato texto y la escribe en el chero calculator.ior (41-45). Finalmente, el programa principal entra en un bucle de espera de peticiones (lnea 52). Ahora, para acabar con nuestro primer ejemplo de calculadora distribuida, vamos a por el cliente:
1 2 3

/* : Client.java * File * Description : A calculator client

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

* */ import java.util.Properties; import java.io.*; import org.omg.CORBA.*; import mymath.*; public class Client { public static void main(String args[]) { // Initialize the ORB. ORB orb = ORB.init(args, null); // Read the calculator IOR from a text-file // previously generated by server. String calc_ior = null; try { FileInputStream file = new FileInputStream("calculator.ior"); BufferedReader myInput = new BufferedReader( new InputStreamReader(file)); calc_ior = myInput.readLine(); } catch (IOException ex) { System.out.println("File error"); System.exit(0); } // Create a CORBA object from calculator IOR. org.omg.CORBA.Object obj = orb.string_to_object(calc_ior); // Cast the CORBA object to Calculator type. Calculator cal = CalculatorHelper.narrow(obj); // Use the calculator. try { System.out.println("Adding: 5 + 3 = " + cal.add(5,3)); System.out.println("Multiplying: 10 * 2 = " + cal.multiply(10,2)); } catch (SystemException ex) { System.out.println("Unexpected error was ocurred."); ex.printStackTrace(); } // Destroy the ORB. orb.destroy(); } }

Este cdigo comienza de manera similar al del servidor, inicializando el ORB. Tras ello, recuperamos la cadena de texto correspondiente a la referencia del objeto calculadora desde el chero calculator.ior (26-29). A partir de esta, creamos la referencia del tipo CORBA.Object (lnea 37), a partir de la cual haremos un casting al tipo calculadora (lnea 40). Tras eso, podemos usar la calculadora para hacer unas cuantas operaciones (43-51) y acabar destruyendo el ORB (lnea 54).

Ahora vamos a compilar el cdigo del cliente y del servidor.

1 2

javac Client.java javac Server.java

Tras esto, si todo ha ido bien, ejecutamos el servidor...

1

java Server

... y luego el cliente ...

1

java Client

3.3.

Preguntas
Analiza la parte del cdigo del servidor en que se registra el objeto calculadora. Qu es realmente lo que estamos registrando? El objeto remoto? El servant? Ambos? Eres capaz de identicar este mtodo de activacin con alguno de los vistos en .Net Remoting? Navega un poco en la red y averigua ms mtodos para activar objetos. Si te atreves, consulta la especicacin de CORBA, seccin 11.2.4. Hemos visto que el cliente hace una conversin desde CORBA.Object a Calculator apoyndose en CalculatorHelper.narrow(). Crees que este casting podra hacerse sin emplear esta clase? Podramos hacer una conversin empleando los operadores bsicos de Java? chale un ojo al cdigo de CalculatorHelper.narrow(). Crees que una operacin como esta debera tenerse en cuenta cuando hablamos de rendimiento? Tanto en la implementacin del cliente como en la del servidor, hemos empleado el sujo ior para referirnos a la referencia del objeto remoto en formato texto. Sabras decir qu es el IOR? Qu tipo de informacin contiene? Abre el chero calculator.ior generado por el servidor y mira qu aspecto tiene. Vuelve a ejecutar el servidor y abre de nuevo el chero. Ves algn cambio? Sabras decir qu est ocurriendo?

4.

Tercera parte: referencias amigables

En el anterior ejemplo, una de las cosas que ms nos ha podido llamar la atencin es que hablsemos de una calculadora distribuida cuando el servidor le pasa a travs de un chero el IOR de la calculadora al cliente. Esto no es muy distribuible. Vamos a ver cmo podemos separar de una manera sencilla ambos componentes. Vamos a efectuar unos pocos cambios en el cdigo del servidor. En primer lugar, vamos a proporcionar un conjunto de propiedades en la inicializacin del ORB:
1 2 3 4 5 6

// Create ORB properties for specifying its port Properties orb_props = new Properties(); orb_props.setProperty( "com.sun.CORBA.POA.ORBPersistentServerPort", "1234"); // Initialize the ORB.

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

De esta manera le estaremos indicando al ORB que debe escuchar en el puerto 1234 en lugar de escoger uno aleatoriamente. A continuacin, en lugar de obtener el IOR y escribirlo en un chero, vamos a registrar el objeto como un servicio bien conocido.
1 2

((com.sun.corba.se.impl.orb.ORBImpl) orb).register_initial_reference( "Calculator", ref);

Eso es todo con el servidor. Ahora vamos con el cliente. En esta ocasin, deberemos realiza tan solo un pequeo cambio. En lugar de leer el IOR de un chero, usaremos la siguiente referencia en forma de string:
1 2

obj = orb.string_to_object( "corbaloc:iiop:1.2@localhost:1234/Calculator");

Vuelve a compilar de nuevo, y ejecuta servidor y cliente. Si todo funciona, vers que el comportamiento de la calculadora vuelve a ser el esperado, pero... esta vez no necesitamos el chero IOR!

4.1.

Preguntas
Hemos visto que por defecto el ORB selecciona un puerto aleatorio. Crees que esto tiene algo que ver con que los IORs cambiasen cada vez que iniciramos el servidor? Hemos visto una nueva forma de referenciar objetos, ms comprensible para los humanos, denominada corbaloc. Para usarla, es necesario invocar un mtodo propio de la implementacin del ORB en el lado del servidor. Sin embargo, parece que poder publicar objetos de una manera fcil y sencilla es una cualidad fundamental de un middleware. Por qu crees que los ingenieros de OMG decidieron que esta funcionalidad era prescindible? Cual crees que fue la motivacin para dejarla de lado? Crees realmente que es una buena idea que un servidor anuncie todos los objetos remotos que exporta de esta manera?

5.

Cuarta parte: usando un servidor de nombres

Hemos visto que el uso de corbalocs simplica el tratamiento de referencias a objetos remotos. Sin embargo, este mecanismo no fue ideado para este n, sino para registrar servicios bsicos del middleware para que estos puedan ser identicados fcilmente. Para localizar los componentes que conforman nuestros sistemas, necesitamos otros mecanismos. El OMG, una vez ms para garantizar la interoperabilidad entre fabricantes, estandariz un servicio de nombrado que nos permite registrar y consultar referencias a objetos remotos. El funcionamiento bsico es muy similar al del registry de Java RMI. Vamos a ver un ejemplo de cmo trabajar con l. En primer lugar, vamos a incluir una nueva propiedad en nuestro ORB que le permita localizar el servidor de nombres:

10

1 2 3 4 5 6 7

Properties orb_props = new Properties(); orb_props.setProperty( "org.omg.CORBA.ORBInitRef", "NameService=corbaloc:iiop:1.2@localhost:1234/NameService"); // Initialize the ORB. ORB orb = ORB.init(args, orb_props);

A continuacin, vamos a hacer una pequea modicacin a nuestro servidor. En lugar de registrar nuestro objeto calculadora cun un corbaloc, vamos a codicar lo siguiente:
1 2 3 4 5 6 7 8 9 10

// Obtain a reference to the Naming // Service (in form of naming context). org.omg.CORBA.Object nc_ref = orb.resolve_initial_references("NameService"); // Cast into naming context extension class. NamingContextExt nc = NamingContextExtHelper.narrow(nc_ref); // Register the calculator in the naming service. nc.rebind(nc.to_name("Calculator.tool"), ref);

Ahora vamos con el cliente. En lugar de instanciar el objeto directamente desde un corbaloc, vamos a ponernos en contacto con el servidor de nombres para resolver la localizacin de la calculadora.
1 2 3 4 5 6 7 8 9

// Obtain a reference to the name server. NamingContextExt nc = NamingContextExtHelper.narrow( orb.resolve_initial_references("NameService")); // Locate the calculator in the name service obj = nc.resolve(nc.to_name("Calculator.tool")); // Cast the CORBA object to Calculator type. cal = CalculatorHelper.narrow(obj);

Vamos a probar este escenario. Lo primero de todo, es ejecutar el servidor de nombres de la siguiente manera:
1

orbd -ORBInitialPort 1234

Tras esto, ejecutamos servidor y cliente como de costumbre.

5.1.

Preguntas
Como vemos, para localizar el servidor de nombres hemos tenido que proporcionar la URL del mismo. Crees que habra alguna manera de localizar el servidor de nombres sin saberlo de antemano? Qu soluciones se te ocurren?

11

6.

Quinta parte: sumando fracciones

En esta quinta parte, vamos a desplegar una calculadora un poco ms completa. Vamos a aadir la funcionalidad que ya vimos en la parte de Remoting para sumar fracciones. Lo primero, es modicar nuestro cdigo IDL para reejar estos nuevos cambios:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

/* : mymath.idl * File * Description : A math module which contains a calculator. */ module mymath { struct Fraction { float numerator; float denominator; }; interface Calculator { float add(in float lhs, in float rhs); float multiply(in float lhs, in float rhs); float add_fraction(in Fraction lhs, in Fraction rhs); }; };

chale un ojo al cdigo generado correspondiente a la estructura Fraction. Ahora, cmo es lgico, deberemos implementar la nueva operacin add_fraction() en nuestra clase CalculatorImpl. Esta vez no te proporcionaremos el cdigo, ya que deberas saber qu debe incluirse y dnde. Ahora, en el cliente aadiremos un par de lneas para comprobar esta nueva funcionalidad:
1 2 3 4 5

Fraction frac1 = new Fraction(1, 3); Fraction frac2 = new Fraction(4, 5); System.out.println( "Adding: 1/3 + 4/5 = " + cal.add_fraction(frac1, frac2));

Si compilas todo de nuevo y ejecutas, vers cmo es posible sumar fracciones. Ahora vamos a hacer un pequeo cambio en nuestro cdigo. Aunque no tenga ningn sentido, vamos a tratar de intercambiar el denominador de ambas fracciones en el cdigo del servant, de una forma parecida a esta:
1 2 3 4 5 6

public float add_fraction(Fraction frac1, Fraction frac2) { float tmp = frac2.denominator; frac2.denominator = frac1.denominator; frac1.denominator = tmp;

12

7 8 9

return frac1.numerator / frac1.denominator + frac2.numerator / frac2.denominator; }

Ahora, incluiremos un pequeo trozo de cdigo para imprimir los valores de los denominadores despus de invocar a add_fraction().
1 2

System.out.println("frac1.denominator: " + frac1.denominator); System.out.println("frac2.denominator: " + frac2.denominator);

Compilamos y ejecutamos de nuevo y... qu ocurre aqu? Por qu mis denominadores no parecen haberse intercambiado? Cambia el chero IDL para que tome los argumentos de add_fraction() en modo inout. Debers hacer algn cambio en el servant para que el conjunto funcione. Tras eso, prueba de nuevo.

6.1.

Preguntas
Hemos denidos una nueva entidad Fraction de tipo estructura. Como vers, no hemos incluido ninguna operacin que nos proporcione el valor en un nmero real que representa la fraccin. Cul crees que es el motivo? Podamos haber hecho lo mismo empleando una interfaz? Por qu no lo hemos hecho? Hemos tratado de modicar el estado interno de las fracciones desde el cdigo de add_fraction() en el servant. En un principio, ese cambio no se ha propagado. Por qu? Qu est haciendo el ORB por debajo a la hora de transmitir los parmetros? Por qu al aadir el modo inout a la interfaz IDL se soluciona? Por qu al hacer esto hemos necesitado cambiar el tipo Fraction por FractionHolder en el servant? Echa un vistazo de nuevo al cdigo Java generado a partir de mymath.idl. Sabras decir dnde se est efectuando el aplanamiento de las fracciones?

7.

Comentarios nales

En esta prctica hemos visto cmo construir algunas aplicaciones sencillas que nos permiten entender a grandes rasgos cmo funciona CORBA. Como ya hemos mencionado, CORBA es probablemente uno de los middleware ms complejos que existen. Esto despierta distintos sentimientos en los desarrolladores. Ms complejidad signica ms una curva de aprendizaje ms empinada y un mayor esfuerzo al desarrollar, pero supone mayor exibilidad y versatilidad. Tal y como hemos podido ver, muchas funcionalidades que en Remoting se encuentran ocultas mediante implementaciones transparentes, CORBA nos las proporciona de manera explcita, siendo responsabilidad del programador denir esos comportamientos mediante lneas de cdigo. Esto tiene sus pros y sus contras. Cul es tu opinin? Como ejercicio nal, te proponemos que experimentes algo ms con CORBA haciendo alguno de los siguientes ejercicios: Hemos comentado que el POA Manager regula el comportamiento en ejecucin de los objetos desplegados en el servidor. Trata de implementar el servidor de tal forma que, en lugar de esperar en un bucle innito, a cada golpe de teclado cambie el estado del Manager del POA raz, pasando de activo a discarding y holding. Observa el comportamiento en el cliente cuando esto sucede.

13

En Remoting hemos visto el modo de vida SingleCall. En CORBA se puede imitar una funcionalidad similar deniendo un ServantManager con la poltica del POA adecuada. Trata de desplegar un servidor que implemente este comportamiento. En la pgina web de OMG puedes encontrar la especicacin del servicio de nombrado. Es bastante simple, cuenta con un par de interfaces y apenas unas diez operaciones. Te atreveras a implementarlo? Y qu me dices del servicio de eventos?

14