Lenguaje OMG/IDL
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:
- 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.
- Objeto cliente: Debe de permitir al usuario conectarse al servicio y enviar mensajes. Debe permitir también establecer conexiones directas entre usuarios.
- 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.
Tutoriales
