Mobility Issues Under IEEE 802.15.4e LLDN Mode

La realidad que nos encontramos normalmente, es que en una operadora ya existen muchos sistemas, con su propio inventario, con lo cual no es fácil imponer, en un tiempo breve, una de las soluciones ideales descritas en el apartado anterior. Desarrollar un sistema de gestión suele llevar bastante tiempo y suponer una inversión monetaria también bastante grande, por lo que deben estar diseñados para perdurar en el tiempo, y su sustitución por otro sistema debe estar suficientemente justificada.

Ante la aparición de un nuevo sistema en el mapa de sistemas de una operadora lo único que se puede plantear son ligeras adaptaciones en el resto de sistemas, para que la integración sea un éxito. En una operadora que ya tiene implantados sistemas de gestión funcionando, no se suele disponer ni del tiempo ni del dinero para reorganizar todo el mapa de sistemas y plantear un escenario de inventario único (centralizado o distribuido) desde cero. Cambiar la arquitectura de los sistemas para que en lugar de que consulten una base de datos propia, realicen consultas a un sistema externo va más allá de lo que se considera una adaptación ligera. Normalmente deberemos ajustarnos a esta arquitectura, con lo que la solución que diseñemos deberá respetar la existencia de esas bases de datos locales y todos los accesos a las mismas que se encuentran programados en lo que es el software del propio sistema.

Figura 25: Aparición de un nuevo sistema en un mapa, cada uno con su base de datos Sin embargo siempre tendremos que velar para que no se produzcan desalineamientos de datos. El nuevo sistema que estemos implantando podrá tener sus conjuntos de datos propios y exclusivos, pero lo más normal es que también deba utilizar datos de los que hemos denominado “comunes” a otros sistemas. Sobre estos datos comunes es necesario definir una estrategia para definir su ciclo de vida, es decir, hay que saber de qué manera se genera cada dato, dónde se guarda, quién lo puede modificar, y hacia qué lugares hay que propagarlo para que pueda ser consultado.

Si en un mapa de sistemas existe más de un sistema maestro del mismo conjunto de datos, algo falla en ese mapa, ese esquema llevará inevitablemente a tener conflictos de desalineamiento de datos. Es muy importante que los procesos encargados de modificar un cierto conjunto de datos estén centralizados y localizados en un único sistema. Y también es importante que todo el mundo lo sepa, que todos los departamentos de la operadora conozcan los procesos de modificación de datos, y por tanto hacia quién deben dirigir una petición de ese tipo cuando les surja la necesidad demostrada de modificar algún dato que no es de su propiedad.

La solución más habitual para estas integraciones de poco impacto es implementar un mecanismo de replicación de datos. Pensemos por ejemplo en la tabla con todos los clientes de la operadora. Existirá un sistema que se definirá como el sistema maestro de esta tabla. El sistema maestro es el único que puede introducir nuevos registros en esa tabla, borrarlos o modificar datos en la misma, por tanto deberá poseer procesos para llevar a cabo estas acciones. Si otro sistema necesita disponer, para su consulta, de todos o alguno de los datos de la tabla de clientes, se debe implementar un proceso de volcado automático y periódico de esos datos, teniendo como origen el sistema maestro. Los procesos de volcados de datos no son la solución ideal, pero es una de las soluciones más inmediatas para resolver el problema planteado. Cada sistema mantiene su base datos, con la definición y estructura que tuviera en cuanto a sus tablas y atributos. No hay que cambiar nada en cuanto a las funcionalidades internas que hubiera en cada sistema a la hora de acceder a sus bases de

datos. Lo único que se añade, en el sistema que recibe los datos, es un proceso para actualizar el valor de ciertos datos de sus tablas internas (lo cual permitirá que el sistema pueda trabajar con datos más actualizados), pero a partir de ahí, todo es igual que antes de la integración.

Figura 26: Replicación de datos pasando de un sistema a otro

Siempre hay que encontrar un compromiso entre la frecuencia de los volcados y la carga de procesamiento que los mismos imponen, tanto al sistema origen de los datos (encargado de la tarea de generar el volcado), como al sistema que los recibe (que debe procesar los datos del volcado y almacenarlos en su base de datos). Para disminuir la carga de los sistemas podríamos pensar en un único volcado diario, y ejecutado en horas de poca actividad (por la noche), sin embargo eso implica que el sistema destinatario podría tener datos desactualizados en un momento dado.

Otro aspecto importante a tener en cuenta es el volumen de información que viaja en los mencionados volcados. No es lo mismo hablar de miles de registros que hablar de miles de millones, evidentemente. Dependiendo de la necesidad de datos que tenga el sistema receptor podremos encontrarnos en algún caso en el que el volcado puede ser muy voluminoso. Existirá un límite inferior en el periodo entre dos volcados consecutivos que es el tiempo que necesitan los dos sistemas implicados en conjunto, uno para generar el volcado y otro para procesarlo. El tiempo entre volcados no puede ser inferior a ese tiempo de procesamiento porque de lo contrario los volcados se solaparían y los sistemas no tendrían tiempo para procesarlos. Y el tiempo de procesamiento de cada volcado es directamente proporcional al volumen de datos que se estén manejando. Cada vez la tecnología avanza más en este aspecto, produciendo soluciones para mover una gran volumen de datos, entre dos bases de datos, en cada vez menos tiempo.

A pesar de los inconvenientes comentados, los mecanismos de volcados de datos entre sistemas suelen ser la solución más rápida para realizar una integración de mínimo impacto. Los mecanismos de volcado pueden ir desde un, poco sofisticado, mecanismo de intercambio de ficheros (por ejemplo mediante protocolo ftp, en un directorio compartido entre ambos sistemas), hasta arquitecturas mucho más complejas, como por ejemplo vistas implementadas directamente sobre bases de datos, u otros métodos de replicación más eficientes.