Zona HTML Zona Java Zona PHP Zona ASP Zona Bases de datos
Inicio > Tutoriales > Plataformas > Linux > Curso práctico de Corba en GNU/Linux
-Tutoriales

Curso práctico de Corba en GNU/Linux


El servidor CORBA

Lo primero es recomendar al lector que sea un poco paciente al enfrentarse por primera vez al código de un servidor de CORBA. Este código siempre es idéntico al 90% en todos los casos, por lo que su comprensión una vez permite trabajar con CORBA con mucha soltura en sucesivos desarrollos de servidores CORBA.

El servidor CORBA es el programa que se encarga de crear el objeto CORBA y registrarlo dentro del ORB.

Como vamos a ver gran parte del código de este servidor es idéntico al del cliente, en especial las partes de inicialización del ORB y de uso del servidor de nombres. Sin embargo dentro del servidor CORBA vamos a ver un elemento que no aparecía en el cliente: el adaptador de objetos. Recordar al lector que el adaptador de objetos es el que mantiene control sobre los objetos que están registrados del ORB y el se encarga de encaminar las peticiones de los clientes hacia los objetos CORBA, entre otras funciones.

Como ya comentamos en entregas anteriores CORBA 2.2 introdujo la gran novedad del POA (Adaptador de Objetos Portable), que sustituyó al BOA (Adaptador de Objetos Básico) que tenía muchos problemas a la hora de portar aplicaciones entre diferentes ORB en el lado del servidor.

Nos vamos a centrar en este ejemplo en POA al haber quedado BOA obsoleto a partir de CORBA 2.2, ha desaparecido del estandar. POA es un adaptador de objetos cuyo uso puede ser muy sencillo pero que ofrece muchas posibilidades de diseño de la aplicación CORBA, puediendo llegar a soportar diseños muy complejos. Quizás en alguna futura entrega del curso se cubra POA en profundidad en un artículo dedicado a él.

Pasamos pues a ver el código del servidor CORBA, dentro del cual se crea el objeto CORBA Calculator y se da de alta en el ORB. A partir de ese momento cualquier cliente podrá acceder al objeto CORBA.

// ============================================================
// = Ejemplo de servidor CORBA con JavaORB                  =
// ============================================================

// Servidor con POA

public class ServerPOA
{
  public static void main( String args[] )
  {
    // 1.
    // Inicializamos el ORB
    org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);

    // 2.
    // Resolvemos la referencia al RootPOA
    org.omg.CORBA.Object objPoa = null;
    org.omg.PortableServer.POA rootPOA = null;
    try
    {
      objPoa = orb.resolve_initial_references("RootPOA");
    }
    catch ( org.omg.CORBA.ORBPackage.InvalidName ex )
    {}

    // 3.
                // Hacemos un narrow de referencia de objeto a referencia POA
    rootPOA = org.omg.PortableServer.POAHelper.narrow(objPoa);

    // 4.
    // Instanciamos un objeto Calculator
    CalculatorPOAImpl calc = new CalculatorPOAImpl();

    try
    {
      // 5.
      // Activamos el servant dentro del ORB
      byte[] servantId = rootPOA.activate_object(calc);

      // 6.
      // Obtenemos la referencia al servant
      org.omg.CORBA.Object ref = rootPOA.id_to_reference(servantId);

      // 6.
      // Accedemos al NamingService
      org.omg.CORBA.Object obj = null;
      org.omg.CosNaming.NamingContext naming = null;
      try
      {
        obj = orb.resolve_initial_references("NamingService");
        System.out.println("Locallizado el NamingService");
        naming = org.omg.CosNaming.NamingContextHelper.narrow(obj);
        System.out.println("Narrow del NamingService");
      }
      catch ( org.omg.CORBA.ORBPackage.InvalidName name )
      {
        System.out.println("No se ha podido obtener el NamingService");
        System.exit(0);
      }

      if ( naming == null )
      {
        System.out.println("No se ha encontrado el NamingService");
        System.exit(0);
      }

      // 7.
      // Construccion del nombre del objeto Calculator
      org.omg.CosNaming.NameComponent [] name = new org.omg.CosNaming.NameComponent[1];
      name[0] = new org.omg.CosNaming.NameComponent();
      name[0].id = "Calculator";
      name[0].kind = "Example";

      try
      {
        naming.bind(name,ref);
      }
      catch ( org.omg.CosNaming.NamingContextPackage.NotFound ex )
      {
        System.out.println("Objeto no encontrado");
        System.exit(0);
      }
      catch ( org.omg.CosNaming.NamingContextPackage.AlreadyBound ex )
      {
        System.out.println("Ya hay un objeto con ese nombre");
        naming.unbind(name);
        System.exit(0);
      }
      catch ( org.omg.CosNaming.NamingContextPackage.InvalidName ex )
      {
        System.out.println("Nombre inválido");
        System.exit(0);
      }
      catch ( org.omg.CosNaming.NamingContextPackage.CannotProceed ex )
      {
        System.out.println("No se ha podido continuar");
        System.exit(0);
      }

      // 8.
      // Activamos el gestor de invocaciones del POA
      rootPOA.the_POAManager().activate();
      System.out.println("El servidor está preparado...");
      // 9.
      // Nos quedamos a la espera de peticiones sobre Calculator
      orb.run();
    }
    catch ( java.lang.Exception ex )
    {
      System.out.println("Se ha capturado una excepción");
      ex.printStackTrace();
    }

  }
}

El paso 1 es idéntico al del cliente. Se inicializa el ORB. En el paso 2 ya empezamos a trabajar con POA. El adapator de objetos POA siempre tiene un POA raíz llamado RootPOA y que el ORB conoce. Los objetos dentro del ORB se registran dentro de un POA determinado, pudiendo cada POA tener políticas de gestión de dichos objetos diferentes. Dentro del ORB pueden existir varios POAs organizados en una estructura jerárquica en árbol.

En el caso más sencillo utilizamos sólo el RootPOA, que tiene unas políticas de gestión predefinidas, y en él registramos a todos nuestros objetos. Si nuestra arquitectura es más compleja habrá que utilizar diferentes POAs con características diferentes, aunque la programación de dichos servidores se complica bastante más que cuando sólo utilizamos un único POA.

En la figura 2 podemos observar el POA de nuestra aplicación y un ejemplo de como podría ser una arquitectura de POAs más complejo

Figura 2: Arquitectura de POAs

Por lo tanto en el paso 2 obtenemos la referencia al objeto RootPOA gracias a la función resolve_initial_references() del ORB. Como esta función nos devuelve un objeto CORBA genérico en el paso 3 debemos de pasar este objeto a una referencia real a POA gracias al narrow() del POAHelper.

En el paso 4 es donde creamos el objeto CORBA CalculatorPOA. La implementación de este objeto la veremos en el siguiente apartado, aunque ya adelantamos que es muy sencilla. En terminología POA a la implementación de una interfaz IDL, que es lo que hace CalculatorPOA implementando la interfaz Calculator, se la conoce como servant. En nuestro caso CalculatorPOA es un servant.

En el paso 5 registramos este servant dentro del RootPOA gracias a la función activate_object() de la API de POA.

Al activar nuestro objeto dentro del POA del ORB del servidor, recibe un identificador que nos devuelve dicha función y almacenamos en servantId. En el paso 6 transformamos este identificador en una referencia a objeto, es la misma información vista de otra forma, con el objetivo de introducir esta referencia al objeto dentro del servidor de nombres.

Lo siguiente que tenemos que hacer es registrar esta referencia al objeto Calculator dentro del servidor de nombres, ya que es allí a donde va a acudir el cliente a buscar la referencia al objeto.

Para ello en el paso 7 se accede al servidor de nombres, paso idéntico al 2 del cliente. El paso 8 es también idéntico al 3 del cliente, con la excepción de que aquí en vez de ejecutar resolve() sobre el servidor de nombres ejecutamos bind(), es decir, aqui unimos dentro del servidor de nombres la referencia al objeto Calculator con el nombre ("Calculator","Example").

En el paso 9 activamos el Manager del RootPOA. Este manager es el que se encarga de recibir las peticiones sobre los objetos registrados en este POA y distribuirlas al servant adecuado, es decir, enviarla a la implementación de la interfaz IDL adecuada. En nuestro caso si se recibe una invocación para Calculator, el manager se la enviaría a CalculatorImpl.

Por último en el paso 10 se invoca el método orb.run() que cede el control de la ejecución al ORB para que puede comenzar a recibir invocaciones del cliente. De este método solo se vuelve en el caso de que el ORB finalice, bien por salida provocada o por muerte.

Recordar al lector que aunque le haya resultado en algun momento un poco compleja o tediosa la lectura de este apartado, una vez entendidos estos pasos son siempre igual en cualquier servidor CORBA, independientemente del lenguaje que se utilice y de lo complejo de la aplicación. La única parte que se complicaría algo más sería la de creación de POAs y sus políticas asociadas. Todo lo demás es idéntico siempre.

En la figura 3 podemos observar el momento en el que se registra el objeto CORBA CalculatorImpl dentro del adaptador de objetos del ORB, momento a partir del cual es conocido dentro de CORBA y puede ser accedido por cualquier cliente remoto.

Figura 3: Registro de objeto CORBA
 
Patrocinados
 

Copyright © 1999-2006 Programación en castellano. Todos los derechos reservados.
Formulario de Contacto - Datos legales - Publicidad

Hospedaje web y servidores dedicados linux por Ferca Network