El proyecto

Varias veces ya he hablado del proyecto en el que estoy actualmente trabajando. Pues bien, ha llegado el momento de introducirlo un poco en profundidad.
Su nombre es Geiser y es un proyecto que esta realizando TID para Telefonica de España.
El proyecto tiene como objetivo realizar una gestion integrada de la Red de Transporte.

Tecnologicamente es un tema muy amplio. Por lo que no me voy a meter en ello. La biblia de todos estos temas son las normas de la ITU-T, pero buscando en la gueb por algunos de los terminos clase, algo se puede encotrar: SDH, PDH, DWDM.

El proyecto surge porque en telefonica trabajan con 3 fabricantes: Alcatel, Lucent y XXXX (vaya!!, ahora no me acuerdo del tercero). Lo cual tiene sus problemas. Logico!, no hay una red integrada, sino que se tiene gestores de red de diferentes fabricantes.
Por debajo de los gestores de red, hay gestores de elemento (no tiene vision de red) y son los encargados de gestionar los diferentes elementos que hay en la red.

El macro proyecto, esta dividido en varios subproyectos (modulos, o proyectos verticales):

Creacion de Red: Donde yo estoy. Se realiza la creacion de los elementos nacesarios para poder provisionar.

Provision: Permite provisionar circuitos.

Medidas de Calidad: El nombre ya lo dice.

Inventario: Registro de todo lo que hay en planta.

Alarmas: El nombre ya lo dice.

Horizontalmente, hay bastantes subproyectos mas, y unos cuantos mas verticales asociados.

Mi suybproyecto es bastante complejo. No porque tecnicamente sea algo especialmente dificil de desarrollar, sino porque la forma de crear las cosas, y el como esta muy oscuro.
La creacion de entidades conlleva basicamente el analizar las ordenes de creacion, el planificar el como hacer la creacion, el realizar el registro en inventario y el crear lo necesario en planta a traves de los gestores de elemento.
Lo que si me agrada (pero por otro lado va a ser necesario, por lo oscuro que estan muchas cosas) es que vamos a tener un periodo de prueba muy amplio.



Ya para acabar, decir que el proyecto es realmente grande. En presupuesto es el mas grande que tiene contratado TID para el 2003 (osea hay muchos ojos mirandonos :( ), y en numero de personas involucradas actualmente ronda las 130.

Rational Rose y su generacion ANSI -C++

Cuando he usado anteriormente Rational Rose use la generacion C++. Mi opinion sobre la herramienta no era muy buena ya que la curva de aprendizaje me parecia muy alta. Ademas de eso, para mi tenia las siguientes desventajas:

Como la generacion es muy parametrizable para generar codigo a tu gusto, previamente debes configurar bastantes cosas.

La ingenieria inversa aparte de hacerse con una herramienta aparte, era realmente complicada. O por lo menos para mi, que no la hice funcionar.

Metia demasiados comentarios en los ficheros. Comentarios que por otro lado no debias tocar.

Por todo ello, nunca me gusto y preferia la forma de funcionar de Together. Together no mete comentarios en los ficheros, los parsea y sincroniza los modelos con el codigo. Si haces cambios en el codigo, el modelo se refresca automaticamente.
El problema de Together es que es muy cara, y por ello no he tenido la oportunidad de usarla profesionalmente.
Por otro lado esta hecha en Java, por lo que es portable, pero a cambio consume muchos recursos.

Sin embargo ahora algo ha cambiado. En Rational parece que por fin se han dado cuenta de que su forma de trabajar no era muy buena y han incorporado el mapping a ANSI-C++. Las primeras pruebas realizadas han sido positivas, por lo siguiente:

Mete menos comentarios. 1 comentario por entidad: clase, atributo, operador, ...

No es tan parametrizable como el mapping C++ por lo que no genera cosas automaticamente. O lo que es lo mismo, todo te lo picas tu. Yo personalmente prefiero esto, a que me genere automaticamente cosas del tipo: constructor por defecto, operadores por defecto, metodos set/get para los atributos, ...

La ingenieria inversa esta integrada, no siendo una herramienta aparte. En las pruebas realizadas ha funcionado correctamente. Si modificabas algo en el codigo, te lo recogia en el modelo. Lo mas rebuscado que hicimos fue el añadir una clase que no estaba; la detecto metiendola en un paquete que esta dedicado precisamente a eso, a las cosas nuevas que ha obtenido por ingenieria inversa y no estaban en el modelo. Luego simplemente te toca llevar la nueva clase al sitio que desees.

Por todo ello, espero que usemos este nuevo mapping de RR 2000 en el proyecto.

Sobre sniffers (y 2)

He visto que hay una version de tcpdump para windows, windump. Para obtenerla con una busqueda en google, vale, :).

Tras echar un vistazo a un README (por que no los mirare siempre....) he visto que la instalacion de ngrep no es tan sencilla. Previamente hay que instalar winpcap, que se define como 'the Free Packet Capture Architecture for Windows'. Que no es mas que el porting a windows de libpcap.

Tras probar la version que me baje antes, y tras compilar el codigo fuente de ngrep me sigue dando el mismo error: 'Error opening adapter: No error'. Habra que ver el porque. Pero no ahora que ya he perdido mucho tiempo con esto.

Ya para acabar. He visto un libro que parece muy interesante, Practical TCP/IP. Designing, Using, and Troubleshooting TCP/IP Networks on Linux and Windows by Niall Mansfield.

Sobre sniffers

Cada dia sale una cosa nueva. Nunca sabes que va a surgir. Esta vez ha venido por JJ. Como siempre, enredando en mil movidas. Va de ngrep.
Simplemente con hacer una busqueda en google ya te salen varios enlaces sobre dicho programita, 'network grep'.
Aqui se puede obtener, incluso para Windows. Y aqui hay bastante info.

Aparte de ngrep existen mas sniffers: tcpdump, dsniff (que puede sacar de otros protocolos aparte de tcp: imap, pop, telnet), snoop (o nett1 en HP-UX). Bueno seguro que hay muchisimos mas.

Por cierto, no esta disponible para cygwin. Habría que probar compilando el codigo fuente. Supongo que lo hará sin problemas.
En Windows 2000, el EXE del primer enlace me pide la DLL packet.dll que no esta disponible. Hay otro enlace para bajarte un proyecto Visual C++.

Ya para acabar..., ayer probé Knoppix 3.X. La caña. Metes el CD y tras indicarle en el prompt de boot que inicie con el idioma Español, te detecta todo, arranca y a funcionar con el KDE. ¡Impresionante!. Detectó la tarjeta de sonido y todo.

KDE o GNOME

Actualmente tengo una distribucion Red Hat con los dos escritorios montados (ahora mismo no se la version exacta) y la verdad es que a pesar de que Gnome tiene un gran numero de 'seguidores' a mi a primera vista (tampoco se mucho de sus interioridades) me ha gustado mas la apariencia de KDE.

Otra cosa que me ha gustado mucho mas es la distribucion inicial de aplicaciones en el menu inicio.

Pero bueno, para que puedas decidir por ti mismo, aparte de echarles un vistazo, ahi va un link a un articulo comparandolas. Aunque parece que esta todavia en construccion. Habra que volverlo a echar un vistazo dentro de un tiempo...

Pasar en Corba informacion de usuario del cliente al servidor de manera transparente

En la aplicación que estamos haciendo hay que registrar en base de datos que usuario y con que role hace unas determinadas operaciones. La aplicacion es cliente/servidor.

Se tiene un Servicio CORBA de Seguridad que mantiene informacion sobre las sesiones que mantiene un usuario (claro, con un role determinado). El alta de la sesion se hace desde el cliente y el servicio es accesible tanto desde el cliente como desde el servidor. Pero para obtener información en el proceso servidor, se deberá tener algo que identifique la sesión. Aqui surge el problema que comento hoy.

Como al final lo que tengo que hacer, es almacenar un usuario y su role en una tabla de la BD, lo mas facil es pasarlo como un argumento mas. Pero esta solución no me gustaba nada, ya que se mezclan los datos de la operación con datos, llamemosles, administrativos. Además se tienen mucha operaciones de este tipo.

Se me ocurrió que en CORBA debería haber algun mecanismo para pasar este tipo de información. Y efectivamente asi es. Pero es una pena que no lo pueda usar, ya que el ORB que usamos es propietario y no lo soporta. Lo podrían implementar, pero no nos podemos permitir esperar ese tiempo. Por lo tanto usare la opción de pasar la información del usuario en todas las llamadas que lo necesiten. Eso si, en un struct :).

Ahora a lio, a la investigacion realizada al respecto....
Lo primero que hice fue buscar en el estándar sobre el objeto Context, ya que me sonaba de que por ahi podrían ir los tiros. Tras mirarlo (rapidamente) y no quedarme muy claro, hice una busqueda en el grupo adecuado, comp.object.corba y según lei, es un mecanismo que no merece la pena usar. Al final, y mas importante, por no ser un mecanismo trasparente y por ser bastante inseguro (se pasan cadenas)
Por lo tanto puse un mensaje, al cual me respondieron indicandome que la manera de hacerlo es usando los siguiente mecanismos:

Portable Interceptors

ServiceContext

En el cliente el PI añade los tokens al ServiceContext y en el servidor el PI comprueba los tokens y realiza las acciones pertientes.
Los Portable Interceptores, como su nombre ya indica lo que hacen es interceptar la llamada entre el cliente y el servidor, para poder realizar acciones de manera transparente. Hay servicios estandares que hacen uso de ellos, como el de seguridad.
El cliente hace la llamada y antes de enviar los datos por la red, se ejecuta el codigo en el interceptor cliente. Una vez llegan los datos al servidor se ejecuta el interceptor servidor y despues se pasa ya al codigo del servidor.
Tras la llamada al metodo del servidor se vuelven a ejecutar los interceptores asociados al retorno, primero el PI del servidor y despues el PI del cliente.

En TAO si estan implementados. Hay informacion sobre el tema en este paper.

ESTA VEZ VA DE RATIONAL ROSE.

En el proyecto que estoy actualmente, tenemos como en el 99% de los proyectos TI un Modelo de Datos (BD relacional). El nucleo de la aplicación y por lo tanto los objetos de negocio con C++ y además hay Interfaces CORBA. Entre las interfaces CORBA, hay interfaces para dar de alta Objetos de Negocio.

Para modelar tanto los Objetos de Negocio como los interfaces CORBA se esta usando Rational Rose. Para realizar el modelo de datos, se esta usando Oracle Designer (¿adivinas cual es la BD?). Aunque también se podría haber utilizado el Rose.

El problema que tenemos actualmente es que tenemos entidades equivalentes en CORBA y en C++, con lo cual hay duplicidad de trabajo realizado. Pero lo mas grave será cuando estemos en fases mas adelantadas y haya que hacer cambios. Dichos cambios habrá que realizarlos en 3 sitios. Osea, ¡UN INFIERNO!.

Lo ideal sería realizar dichos cambios en un sitio y que estos se propagasen.

Olvidemos lo ideal y centremosnos en lo que tenemos en RR. Ahi van las acciones realizadas:

+ La primera prueba realizada fue el generar una clase en dos componentes. RR no lo permite.
+ He preguntado a gente que pilota de RR y no me han podido ayudar. JJ me comentó que con Together tuvo alguna movida similar pero que le sonaba que Paradign Plus si era capaz de hacerlo. De todas formas por lo que tengo oido Paradign no es una herramienta 'user friendly'.
+ La siguiente y estupida prueba consistió en heredar 2 clases de una de analisis y asociarla a cada una de las hijas un componente diferente. Tampoco es la forma.
+ Como somos tan inteligentes no se nos ha ocurrido ninguna otra manera, por lo que me he dado de alta en un grupo de www.rational.com y he puesto un post. Haber si es posible realizarlo...

Ahora solo me queda esperar... y mientras tanto investigare otras herramientas. Me gustaría ver si alguna de las que hay por ahí Open Source maneja esta situación.

Ya para acabar... Hay una forma de solo tener que hacer los cambios en un sitio. Pero no me gusta nada. La solución consistiría en:

+ Hacer las modificaciones en el objeto CORBA
+ Tener el objeto C++ que herede de un Objeto Base (particular para el). Añadirá funcionalidad de la capa de negocio.
+ La implementación del Objeto Base será un typedef al objeto C++ generado por el compilador de idl.

Esta solución aunque solventa el problema de tener que hacer cambios en más de un sitio tiene como problemas:

+ Se arrastran los tipos del mapping de CORBA a C++, y procesos que no tendrían por que saber nada de CORBA, van a tener que. Además obliga a linkar/compilar con codigo CORBA.
+ Los objetos C++ no van a tener atributos, por lo que en ningun momento se podrá hacer referencia a ellos.

Estuve echando un vistazo a un paper del sitio que comente en la entrada anterior: Object/Relational Access Layers. A Roadmap, Missing Links and More Patterns. Dicho documento es una introduccion, que puede ser profundizada con el resto del documentación del site.

A priori según me comentó Miguel, y en esto coincico con él, no parece interesante el montarnos un mecanismo de persistencia complicado, ya que tenemos que hacer algo muy concreto y no nos va a sobrar el tiempo (como siempre), pero lo que si necesitamos es la definición de como pasar la información de los objetos de negocio a la Base de Datos.
A priori a mi se me ocurrieron 3 posibilidades:

Por herencia (la clase que lo hace, hereradia de un interfaz y de la clase de negocio)

a través de un 'Broker'

o a través de un 'Broker Global'
Curiosamente, en el articulo mencionado aparecen justo estas tres opciones, en el apartado 'Moving Attributes to and from the Tuple Layer'.

De todas formas tenía en mente el echar un vistazo al libro 'UML Y PATRONES. Introducción al análisis y diseño orientado a objetos. Craig Larman. Prentice Hall. ISBN 970-17-0261-1'. Ya que recordaba que hay un capitulo que trata la problematica de los objetos persistentes. La verdad es que el 'Framework' que plantea esta muy bien, pero demasiado complejo para lo que nosotros queremos hacer. Ha estado bien echarle un vistazo, pero al final nos quedaremos con algo mas sencillo. Ya comentaré cual será la decisión final.

Aprovecho para comentar que dicho libro esta muy bien. Describe un proceso de modelado usando UML y Patrones de Modelado. El proceso es sencillo. No conozco en profundidaz el Proceso de Modelado de Rational, pero este es muy sencillo. Es un libro muy recomendable de leer.