Curso práctico de Corba en GNU/Linux

En los pr�ximos cap�tulos vamos a describir como se afronta la soluci�n a un problema utilizando una perspectiva orientada hacia CORBA. Para ello vamos a describir las fases de an�lis y dise�o de una aplicaci�n, la cual utilizaremos como ejemplo a lo largo del curso. Posteriormente y a partir del dise�o veremos que reflejar este dise�o dentro de CORBA utilizando el lenguaje OMG/IDL. Para poder este lenguaje por completo utilizaremos el compilador de OMG/IDL a Java de una herramienta de libre distribuci�n conocida como JavaORB, la cual implementa el estandar CORBA 2.3.

�An�lisis de la aplicaci�n

Como en todo desarrollo software en la fase de an�lisis debemos de capturar todo lo que se espera que nuestra aplicaci�n haga. Para ello debemos ir buscando toda la funcionalidad requerida. Inicialmente vamos a describir el escenario de funcionamiento y despues vamos a utilizar casos de uso del sistema para capturar mas requerimientos del sistema.

De cualquier modo esta parte de A&D (An�lisis y Desarrollo) no ser� ni mucho menos formal, ya que el objetivo del curso es aprender CORBA y no A&D de sistemas, un tema demasiado complejo y amplio como para ser cubierto en tan poco espacio. El objetivo de esta secci�n es dar unas pinceladas de A&D y ver como se ajustan estos procesos a CORBA.

�Escenario

El problema que se nos plantea es: "una organizaci�n quiere agilizar las comunicaciones internas entre sus empleados. Para ello est� evaluando diferentes soluciones y entre ellas han pensado en un servicio de env�o de mensajes s�ncrono, es decir, en un servicio al que est�n de forma cont�nua conectados sus empleados y por el que se puedan comunicar, en comunicaciones uno a uno, uno a varios o varios a varios".

Partimos de la hip�tesis de que todos los empleados tienen un ordenador con el que trabajan, por lo que en principio este va a ser la herramienta a trav�s de la cual se comunicar�n.

Al ser una organizaci�n grande hay ordenadores de muchos tipos, y seg�n el tipo de trabajo unos empleados trabajan en un tipo de ordenador u otro. En concreto se han detectado: m�quinas Linux en la zona de desarrollo software, m�quinas MacOS en la zona de dise�o y m�quinas con Windows en departamentos como los de gesti�n.

Por lo tanto, la soluci�n que demos debe de funcionar en todas estas plataformas, es decir, los binarios que se generen deben de soportar varias plataformas. Por ello todo apunta a que en los clientes vamos a utilizar Java como lenguaje de desarrollo.

El n�mero de empleados de la empresa en bastante elevado, del orden de 10000 personas, por lo que el tr�fico de comunicaciones puede ser muy elevado. Como hay que soportar comunicaciones entre varios empleados simult�neamente parece que vamos a necesitar un servidor central que coordine estas comunicaciones, ya que sino la complejidad en los clientes podr�a ser demasiado elevada. Dicho servidor deber� soportar una carga elevada de conexiones y nuestra experiencia nos decanta a utilizar C++ como lenguaje de implementaci�n, aunque queremos dejar las puertas abiertas a otros lenguajes.

No se descarta la posibilidad de conexiones directas entre clientes sin tener que pasar por el servidor, para poder evitar congestiones dentro del servidor. Es una aplicaci�n que claramente tiene su mayor complejidad en las comunicaciones. Por ello se ha pensado en el uso de CORBA como "middleware" ya que as� CORBA se encargar�a de gestionar dichas comunicaciones, permitiendo incluso la conexi�n de redes con diferentes protocolos.

El servicio ha de ser gestionable, permitiendo definir pol�ticas de conexi�n y existiendo unos operadores del servicio con una funcionalidad mayor a la de los clientes.

Como resumen del escenario:

• Existe un servidor central al que se conectar�n los clientes. Posiblemente estar� desarrollado en C++.
• Varios clientes se conectar�n al servidor de forma simult�nea. El lenguaje de implementaci�n ser� Java por la necesidad de ser multiplataforma.
• Existir�n clientes "operadores" con posibilidades adicionales.
• Se utilizar� CORBA para gestionar las comunicaciones.
• Deber� existir una interfaz de gesti�n del servicio.

�Objetos de la aplicaci�n

Del escenario podemos deducir que en la aplicaci�n van a existir los siguientes objetos:

1. Objeto servidor: Se va a encargar de ir recibiendo las diferentes conexiones de los clientes. Adem�s debe permitir conexiones de los operadores autenticadas, los cuales podr�n gestionar el servicio. Deber� ofrecer el servidor una interfaz de gesti�n. Debe tambi�n recibir los mensajes de los diferentes clientes y enviarlos a todos los dem�s, as� como facilitar las conexiones directas entre clientes.
2. Objeto cliente: Debe de permitir al usuario conectarse al servicio y enviar mensajes. Debe permitir tambi�n establecer conexiones directas entre usuarios.
3. Objeto operador: Es un objeto cliente ampliado con operaciones de gesti�n y de informe del funcionamiento del servicio. Una vez identificados los objetos que van a participar en el sistema, y tener su funcionalidad definida, podemos ya definir las interfaces IDL de cada uno de ellos, interfaces que deben cubrir toda la funcionalidad descrita.

�Dise�o de la aplicaci�n. Interfaces IDL

En el dise�o de la soluci�n al problema nos vamos a centrar en definir las interfaces IDL que cubran toda la funcionalidad requerida. Del an�lisis hemos concluido que necesitamos tres objetos dentro del sistema, por lo que existir�n tres interfaces IDL dentro del mismo.

Toda la aplicaci�n en s� pertenecer� a un m�dulo com�n, al que llamaremos "Mensajes". Dentro de este m�dulo se definir�n las tres interfaces que hemos detectado.

�Interfaz del servidor

// Interfaz a implementar por el servidor
interface servidor {
    // Conexion de un operador
    string conectar_operador (in operador interfaz, in string clave);
    // Devuelve una cadena con el nombre del servidor
    string conectar (in cliente interfaz);
    // Desconecta un usuario del sistema
    boolean desconectar (in cliente interfaz);
    // Mira si un usuario esta conectado y recibe la interfaz al mismo
    cliente presente (in string nombre) raises (comun::ClienteNoPresente);
    // Devuelve una lista de los usuarios presentes en el sistema
    void listaUsuarios (out comun::lista_usuarios lista);
};

�Interfaz del cliente

// Interfaz a implementar por el cliente
interface cliente {
    // Funci�n b�sica de recepcion de mensajes
    // Devuelve "true" ante recepcion correcta
    boolean recibeMensaje (in string mensaje);
    // Mensajes de aviso especiales del servidor
    boolean recibeAviso (in comun::alarma mensaje);
    // Mensajes directos a otros usuarios
    void enviaMensaje (in comun::usuario destino, in string mensaje);
};

�Interfaz del operador

// El operador es informado de accesos al servicio
interface operador:cliente {
    boolean nuevaConexion(in string nombre);
};

�Interfaz com�n

Para compartir estructuras de datos comunes entre los tres interfaces lo que hacemos es definirnos un interfaz nuevo llamado "comun", en el que declararemos todas las estructuras de datos compartidas por los diferentes interfaces.

interface comun {
    // Version de la aplicacion
    readonly attribute string version;
    // Nombre de usuario
    typedef string usuario;
    // Lista de usuarios
    typedef sequence lista_usuarios;
    // Excepcion de usuario no presente
    exception ClienteNoPresente {usuario nombre;};
    struct alarma {
        unsigned short codigo;
        string mensaje;
    };
}; 

�Conclusiones de A&D

Vemos que gracias principalmente al lenguaje OMG/IDL, a la salida de la fase de A&D tenemos ya modularizado y especificado el sistema. A partir de este momento podemos repartir las interfaces a los distintos grupos de desarrollo. Cada grupo se puede encargar de implementar una interfaz, y si se respetan dichas interfaces, la fase de integraci�n del sistema ser� poco costosa.

Por otro lado a�adir nueva funcionalidad al sistema resulta sencillo. Se identifica a que modulo pertenece dicha nueva funcionalidad, y se a�ade a su interfaz IDL. Es m�s, dentro de las interfaces queda perfectamente capturado los criterios de dise�o, por lo que no se introducir�n cambios que deterioren la arquitectura inicial del sistema.

Resumiento podemos destacar las ventajas:

• OMG/IDL modulariza permitiendo la implementaci�n en paralelo.
• OMG/IDL asegura que la integraci�n de los m�dulos va a ser poco costosa.
• OMG/IDL permite una mantenibilidad del c�digo.
• OMG/IDL captura de forma concisa el dise�o del sistema.