Evaluación alternativas de integración Qualdev SPCC

Texto completo

(1)EVA LUA CIÓN A LTERNA TIVA S DE INTEGRA CIÓN QUA LDEV SPCC. Nadya Alexandra Calde rón R Código: 200210920. Asesores: Nicolás López Giraldo. Proye cto de Grado para optar por el título de Ingenie ro de Sistemas y Computación. Unive rsidad de los Andes Facultad de Ingenie ría Departamento de Ingenie ría de Sistemas y Computación Ene ro de 2007.

(2) CONTENIDOS. 1. 2.. INTRODUCCIÓN ................................................................................... 3 OBJETIVOS.......................................................................................... 4 2.1. O BJETIVO S ESPECIFICOS.................................................................... 4 3. PROPUESTA S PA RA LA INTEGRA CIÓN ..................................................... 5 3.1. MÓ DULO DE R EPR ESENTACIÓ N DE UN PROC ESO ...................................... 5 3.2. EVALUACIÓ N ................................................................................... 6 3.2.1. Web Se rvice s............................................................................. 6 3.2.2. Eleggua.................................................................................... 9 3.2.3. ESB ....................................................................................... 10 4. MODELOS DE DA TOS PA RA LOS MÓDULOS............................................. 13 5. DESCRIPCIÓN DEL PROTOTIPO ............................................................ 15 6. CONCLUSIONES.................................................................................. 16 7. TRA BAJO FUTURO............................................................................... 17 REFERENCIA S............................................................................................. 18.

(3) 1. INTRODUCCIÓN Qualde v SPCC es la he rramie nta de apoyo a los procesos de desarrollo de pequeñas organizaciones de construcción de software. Esta he rramienta presta soporte que se representa en e l mane jo de históricos de mé tricas y una fue rte disponibilidad visual de l estado de los proye ctos desde todas las dimensiones. En particular e l caso de estudio es e l grupo mismo y su construcción se realiza de forma incremental, en este momento se cuenta con la implementación de l módulo de administración de proye ctos como e je central de la he rramie nta y sobre e l cual se e spe ra construir un conjunto de componente s que inte gren las aplicaciones que dan soporte a cada uno de los procesos o áreas de proceso con las que e l grupo traba ja a ctua lmente como planeación, adm inistración de la configura ción, medición y análisis, etc. El propósito de esta inve stigación es e valuar dife re nte s alte rnativas de integración de he rramie ntas, dise ñar e implementar un prototipo como prueba de conce pto para la integración de l módulo de Planeación y Seguimiento al table ro de control, espe cíficamente de la he rramienta Planning Tool con la que e l grupo Qualde v trabaja para e l seguim iento de esta área de proceso. La motivación de esta investigación se encuentra principalmente de ntro de la construcción incremental de l SPCC , pues se ne cesita integración con las he rram ientas de soporte a los procesos para consolidar el histórico y e l apoyo a la toma de de cisione s, principio en e l cual se basa el SPCC.. Fig. 1.

(4) Ex iste e l conce pto de inte gración, pe ro es importante tene r en cuenta que las funcione s de entrada f y las funciones de visualización g (Figura 1) se deben re solve r te niendo en cuenta la dinámica de los procesos Qualde v. •. Empresas Pe queñas. •. He rramie ntas Actuales: Changese t, Planning Tool, Me trics. La importancia de esta investigación radica en dos aspe ctos principales: •. El de sarrollo de infraestructuras de integración está e n cre cim iento y se busca e valuar las ve ntajas y desventajas de cada una de e llas dentro de las caracte rísticas de l grupo de construcción QualDe v.. •. El impacto que tiene el proce so de planeación para la obtención de históricos y análisis de mé tricas de los proye ctos de construcción de software, Planning Tool está construido siguie ndo estos mismos principios y basado en las prácticas estable cidas en el área de proceso de Planeación de Proye ctos (PP) en el nivel 2 de madurez de l mode lo escalonado de l C MMI.. 2. OBJETIVOS Para e l desarrollo de la integración entre módulos de áreas de proce so o procesos que se quie re n inte gra r a l table ro de control, e l obje tivo de este proye cto e s e va luar dife rentes a lte rna tivas de. integra ción de he rram ientas en e l contex to Qua lDe v y propone r la. arquite ctura de integración con base en el estudio de las alte rnativas evaluadas y las propuestas de otros proye ctos que se han ade lantado en e l grupo.. 2.1. OBJETIVOS ESPECIFICOS •. Estudiar ventajas y desventajas de posibles te cnologías de integración basado en e l trabajo adelantado hasta el momento en e l grupo y nue vas te cnologías de inte gración de aplicaciones.. •. Definir ¿qué es un módulo de represe ntación de un proceso o subproceso? Y ¿cuáles son las caracte rísticas m ínimas de lógica de negocio, transformaciones y visualización que debe provee r para la inte racción con e l table ro de control?.

(5) •. Implementar un prototipo con alguna de. las e valuaciones realizadas para la. integración de l módulo de planeación y se guimiento de proye ctos de construcción de software a l SPCC, e spe cíficamente Planning Tool como he rramie nta de soporte a l proceso en e l grupo, teniendo e n cuenta que los módulos que se integran al SPCC debe n estar orientados a la flex ibilidad y desacoplam iento el m ódulo central de l table ro de control. •. Re troalimentar los procesos de l grupo de acue rdo con las modificacione s ne cesarias por la inte gración.. 3. PROPUESTA S PA RA LA INTEGRA CIÓN Para el desarrollo de la inte gración de las he rram ientas del grupo se e valuaron tres alte rnativas de acue rdo con e l trabajo ade lantado en otros proye ctos y nue vas te cnologías e infraestructuras de inte gración. Adicional a las alte rnativas de integración e s ne cesario de finir e l conjunto de módulos que represe ntarán los dife rentes procesos en e l table ro de control y con los que de ben inte ractuar las aplicaciones ex te rnas para cumplir con las ne ce sidades de l table ro de. re copilación de. datos y presentación de la información. consolidada. Cada una de las alte rnativas al igual que los re que rimie ntos de un módulo de representación de un proceso se rán la guía de este proye cto y se desarrollarán en de talle a continuación.. 3.1. MÓDULO DE REPRESENTA CIÓN DE UN PROCESO Cada una de las he rramientas de soporte a los procesos de l grupo que se de sea integrar con e l table ro de control debe tene r un componente represe ntante cone ctado al core que se rvirá de mediador entre la aplicación fuente y e l spcc. Este componente o conjunto de componentes resolve rán e l módulo de representación de un proceso quien e s re sponsable de las transformaciones de datos que sean ne cesarias (si no hay un age nte inte rmedio que realice las transformaciones de datos previamente ), e s el responsable de la comunicación entre las aplicaciones y finalmente el proveedor de se rvicios para la construcción de la inte rfaz Web de l módulo. De acue rdo con las responsabilidades definidas, los reque rim ientos m ínimos que debe pre sentar cada compone nte o componente s re presentante s de un módulo son:.

(6) Transformaciones de datos: •. Calcular medidas de acue rdo a datos básicos. •. Obtene r datos simples de obje tos comple jos, ne cesarios para calculo de otras medidas. •. Conve rtir datos en inteligencia de l negocio [2]. En este sentido de be distribuir los datos en los destinos ne cesarios para tene r información comple ta y construir .. •. Conve rtir en ambas dire cciones datos en nomenclatura estándar como XML [2]. Comunicación bidire ccional (si es ne ce sario): •. Se rvicios para re cibir datos que se de ben almacenar en e l spcc. •. Se rvicios para alimentar las aplicaciones fuente (e n caso de se r ne cesario) con información calculada por el spcc para el módulo repre sentado.. Construcción de la inte rfaz de presentación de l módulo: •. Se rvicios de consulta de la información de un módulo para prese ntar su información en dife re ntes cliente s de análisis de negocio.. 3.2. EVA LUA CIÓN Con el desarrollo de e ste proye cto se e spe ra contar con crite rios y justificacione s sólidas para la integración de he rram ientas en el grupo QualDe v, de acue rdo con esto se expondrán a continuación las ventajas y desventajas de cada una de las alte rnativas que han llegado al grupo a travé s de otros proye ctos de grado, proye ctos desarrollados por el mismo grupo o e l inte rés por las nue vas te cnologías de inte gración. La integración de datos requie re transformaciones que se pue den desarrollar en dife rentes puntos de acue rdo con las ventajas de cada alte rnativa, pe ro siempre se debe ex tende r e l mode lo de datos e n e l spcc para que soporte cada uno de los módulos que se integran a é l y en e l que se e spe ra conte ne r la informa ción de re troalimenta ción y soporte que debe pre sentar.. 3.2.1. Web Services De acue rdo con e l trabajo ade lantado en proye ctos ante riores en el grupo, la idea de realizar la integración a través de web se rvices se desarrolló inicialmente de acue rdo con e l mode lo.

(7) expue sto en la figura 2 con el que se e spe raba contar con un módulo represe ntando cada una de las he rramientas que se desean inte gran y adicionalmente todo e l conjunto de módulos y e l core rodeado de una capa de web se rvices con la que se inte ractúa con las aplicaciones ex te rnas.. Fig. 2 Arquitectura SPCC basada en web services. Andrés Márquez 2006 Esta idea se analizó en de talle y se construyó un mode lo más ce rcano en e l que se demuestra que la funcionalidad se ve lim itada y es poco exte nsible por la comple jidad de las re laciones que se van armando. (Es comunicación punto a punto y no es be néfica para la dinám ica del negocio en Qualde v). De acue rdo con las ideas expuestas en el proye cto de inte gración con we b se rvice s, una representación para un módulo particular tendría las siguientes caracte rísticas: (Figura 3).

(8) Fig. 3 Componentes Integración Web Services •. Los Módulos de repre sentación de proce sos se e ncuentran locales con e l SPCC. En este caso cada módulo inte ractúa con los datos dire ctamente y es e l encargado de hace r todas las transformaciones de datos que se ne cesiten para alimentar e l mode lo de datos para e l módulo e n e l spcc. Esta comunicación se realiza utilizando las inte rfaces de l core que ya existe n.. •. Los e lementos de presentación se encuentran conte nidos e n e l m ismo módulo o se pueden agre gar al clie nte. web de l spcc que ex iste actualmente . Como. la. comunicación es local, la integración de la prese ntación es natural pue s se re fle ja en reglas de navegación a las páginas de los módulos. Estas caracte rísticas presentan desventajas para la solución que se busca pue s la comunicación se realiza en una sola dire cción punto a punto: e sto lim ita la ex tensibilidad de se rvicios y agrega comple jidad a la infraestructura ya que implica un gran número de cambios e n las aplicaciones fuente y destino cada ve z que se desee integrar un nue vo se rvicio. En este se ntido cada inte gración de un nue vo módulo requie re una “metodología” de creación de elementos como: •. Web Se rvice s para la fue nte. •. Lógica de transformación y comunicación con e l core.

(9) •. Accione s sobre la fue nte para invocar los se rvicios. Por lo ante rior se conside ra que la infraestructura basada en we b se rvices únicamente no soluciona de mane ra ade cuada e l problema de l spcc.. 3.2.2. Eleggua Actualmente e l grupo se encuentra trabajando sobre la infraestructura basada e n e ventos desarrollada como proye cto de investigación del m ismo grupo. La inte gración con una infraestructura de e ve ntos se conside ra una buena a lte rnativa pues aunque en este momento las aplicaciones que soportan los procesos son pocas y pequeñas, se e spe ra e l cre cim iento de este soporte de mane ra que se puedan cubrir todas las áreas de proceso de un sistema de calidad.. Fig. 4 Módulo de Proceso como aplicación conectada a Eleggua Con la utilización de Eleggua el SPCC se comporta como cualquie ra de las otras aplicaciones (produce y consume e ventos) de mane ra que la comunicación se realiza e ntre cualquie r conjunto de aplicacione s sin de pende r de fuentes y destinos, simplemente consumidores de e ventos por tópicos..

(10) En la arquite ctura de Eleggua, las aplicaciones exte rnas se re fie ren en este caso a los módulos de representación de procesos que son componentes que pueden encontrarse cone ctados localmente con las inte rfaces de l core de l spcc. Cada uno de estos módulos se simplifica (con respe cto a la a lte rna tiva a nte rior) pues se responsabilizan únicamente de la re ce pción y e nvío de datos, no de be rían tene r ninguna responsabilidad de transformación de datos. La inte racción con los datos e s transparente pues los se rvicios expuestos debe rían re cibir datos e n té rm inos de la lógica de cada módulo y la capa de prese ntación se encuentra contenida e n e l módulo mismo o como ex tensión de l core que ex iste actualmente. De esta forma al igual que con la solución ante rior, la composición de la presentación se puede hace r con te cnología como Portlets: Cada módulo re sponde por sus reque rim ientos. Finalmente la responsabilidad de las transformaciones de datos se delega a los prox ies de coope ra ción de. Eleggua. Las venta jas de esta alte rna tiva son repre sentativas pues. minimizan las modificacione s sobre las aplicaciones fuente y la integración e s bidire ccional lo cual pe rm ite la re troalimentación de las aplicaciones con futuros e ventos que pueda producir e l SPCC . El trabajo ade lantando por e l grupo tiene en este momento la infraestructura Eleggua e n un punto estable y es una bue na alte rna tiva para la integra ción de aplica ciones que requie re e l SPCC. Ex iste n algunos puntos a tene r en cuenta, aunque ninguno de e llos tendría impacto ne gativo sobre la implementación de una solución: •. Algunos e ve ntos no son accione s naturales para todas las aplicaciones. Ej. Planning Tool.. •. No hay volumen de e ve ntos muy grande e n e l contex to de la organización Qua lDev y en e ste sentido puede se r más costoso al principio montar Eleggua para usos pequeños.. 3.2.3. ESB La idea de utilizar un bus de integración de se rvicios ESB (Ente rprise Se rvice Bus) nace por e l cre ciente re conocim iento con el que se e ncue ntra a ctua lmente esta te cnología. 1 1. Para la evaluación de esta infraestructura de integración se tuvieron en cuenta las características que proporciona Websphere ESB de IBM pues dentro de la literatura es el que en este momento se encuentra más completo y disponible. Aunque no es una herramienta libre que utilizaría el grupo, las características generales sirvieron para un primer análisis de las características y comparaciones con la versión de JBoss..

(11) Las arquite cturas orie ntadas a se rvicios han e volucionado y e l número de proye ctos en este campo es cada vez mayor. Las ne cesidades de confiabilidad, seguridad y desempeño entre otras representan los re tos e n e l desarrollo de proye ctos de inte gración. [1] Un ESB es una infraestructura que soporta la implementación de SOA en una organización de mane ra que : •. Desacopla la pre sentación de un se rvicio de la implementación actual de éste .. •. Desacopla aspe ctos té cnicos de la inte racción de los se rvicios. •. Inte gra y adm inistra los dife rentes se rvicios. •. Soporta la transformación de datos y promue ve la estandarización de mensajes de comunicación con te cnologías como XML, aunque represe nta carga en e l trabajo de transformaciones, los ESB soportan en este momento dicha tarea. [1]. •. O rquestación, asincronía, confiabilidad y seguridad son reque rim ientos sobre los que apuestan las implementaciones de un ESB y por lo tanto, el valor ganado de un bus de integración se e ncentra según The SOA Journal e n la habilidad para libe rar los re cursos y concentrarlos en e l de sarrollo de aspe ctos de alto nive l de arquite cturas y se rvicios. [1]. Fig. 5 Arquitectura ESB. Tomado de ESB: Enterprise Services Bus “La siguiente generación de plataformas para la integración empresarial de aplicaciones”. Jorge Humberto Arias. 2005. las.

(12) Para e l desarrollo de la integración de he rramie ntas del grupo, las ventajas se ven refle jadas en: •. Inte gración de cualquie r tipo de aplicación. •. Separación de las transformaciones en las mediaciones, para las implementaciones iniciales la configuración básica de seguridad y otros reque rimientos como orquestación no son ne ce sarios, luego e l tiempo se puede inve rtir sobre las mediaciones y transformaciones de datos re le vantes.. •. Soporte de Web se rvice s como access points. •. Seguridad. •. Reutilización de se rvicios (propósito SO A). •. Todo puede se r configurable. Fig. 6 Aunque la utilización de una infraestructura de integración brinda mayor ex tensibilidad en té rm inos de los módulos que puede n alimentar al SPCC. C omparativamente hablando entre Eleggua y un ESB, es ne cesario resaltar que e l grupo se e ncuentra mucho más ade lantado en trabajo sobre la prime ra y la inve rsión sobre nue vas te cnologías puede se r costosa espe cialmente porque en este momento las he rram ientas como e l ESB de Jboss es una te cnología en desarrollo que no cuenta con mucho soporte . (La documentación de l ESB de JBoss es escasa e n este momento, hasta e l momento de realizar esta investigación se encontraba en ve rsión Re lease Candidate JBossESB 4.0). Finalmente los re presentantes de las aplicaciones: los módulos de repre sentación de procesos son los compone ntes e ntre los que se inte ractuaría, desacoplar los módulos de.

(13) proceso de l SPCC re presenta ve ntajas e n la configuración de la pre sentación pues se puede re currir a te cnología como portle ts para e l desarrollo de la m isma como en todos los demás casos.. 4. MODELOS DE DA TOS PA RA LOS MÓDULOS En la se cción ante rior se de finie ron las caracte rísticas de los módulos de re presentación de procesos como los compone ntes que soportan las re sponsabilidade s de un área de proceso (planeación, re que rimie ntos, adm inistración de la configuración, e tc.) y que se encuentra cone ctado al core de l table ro de control por medio de las inte rfaces ex istentes. Cada vez que se realiza la integración de un nue vo módulo se de be contemplar e l impacto en las 3 capas gene rales de la arquite ctura SPCC : datos, aplicación y pre sentación. A nive l de aplicación se deben de te rminar los componentes que mane jaran e l inte rcambio de datos y e l diseño puede realizarse independiente de jando las conex iones re spe ctivas con las inte rfaces que pre senta el core de l table ro en este momento. Por e jemplo e l modelo de planeación. y. seguim iento. se. ha. ve nido. trabajando. en. proye ctos. ante riores. y. conceptualmente tenemos lo que se repre senta en la figura 7 en donde se e stable ce la conexión de l modulo de planeación con los compone ntes ciclo y pe rsona de l core.. Fig. 7 Modelo Planeación. Andrés Márquez 2006.

(14) Integración de Datos: La integración de datos de l SPCC con las he rram ientas que soportan los dife rentes procesos en el grupo se realiza exte ndiendo e l mode lo de datos de l SPCC pues podríamos calificar al table ro de control como e l re positorio central de datos en e l que se consolidan históricos y se cue nta con la información comple ta para resolve r las consultas de inte ligencia de ne gocio. Uno de los principale s problemas e n la integración de datos es la ne cesidad de resolve r consultas con información que se encuentra en dife rentes re positorios de datos, pe ro este problema se resue lve en e l SPCC al transfe rir toda la información a la “bodega de datos” centralizada de l table ro de control. Esto quie re de cir que con la integración de cada módulo se debe exte nde r el mode lo de datos y los componentes debe n inte ractuar con este mode lo. Aunque el mode lo de datos de l spcc no es dimensional y conse rva una e structura relacional, se pue de hablar de é l como una bode ga de datos pues mane jará la historia de la organización y un alto volumen de datos. Cumple con los obje tivos dispuestos para una bodega de datos: [3] •. Ofre ce r fácil acceso a la organización de la organización.. •. Ofre ce r contenido entendible , he rram ientas simple s y fáciles de usar.. •. Prese ntar información de mane ra consiste nte. •. Se r adaptable a cambios tanto en las consultas como e n la forma de tomar de cisione s.. •. Control de acceso seguro, prote cción de la información.. •. Soportar me jor toma de de cisiones e n la organización.. •. Debe se r simple: la comunidad de usuarios debe aceptarla.. De acue rdo con lo ante rior en la integración de datos de l spcc e l reque rim iento principal es la resolución de las incohe rencias para que la información de tallada pe rm ita flexibilidad y confiabilidad e n e l análisis y se tenga una vista 360˚ de la información. Esto quie re de cir que las transformacione s de datos para los dife re ntes módulos deben rea liza rse e n los mediadore s de la integra ción (de a cue rdo con las a lte rna tivas e va luadas: en los prox ies de coope ración de Ele ggua o e n los mediadore s de l ESB). Los componentes de l módulo deben expone r los se rvicios en té rm inos de datos conocidos y del negocio, si se mane ja algún tipo de comunicación estándar como XML, ésta debe que dar resuelta en las.

(15) mediaciones de mane ra que se puedan invocar los se rvicios con datos básicos u obje tos de l ne gocio. Para cumplir con la confiabilidad de la información se debe hace r una e valuación de los datos fue nte para contemplar los casos en los que se pue dan filtrar inconsiste ncias y tomar de cisione s sobre las acciones de dichos datos. Frente a e sto se propone n dos tipos de alte rnativas [2]: •. Re chazar los datos inconsiste ntes: Se puede simplemente re chazar el registro de datos o se puede notificar a la fuente de l e rror espe rando que se tomen acciones corre ctivas. Esto último no se re com ienda en e l caso de cargas de datos muy altas pues ge ne ra mucho tráfico.. •. Reemplazar los datos inconsistentes con valores constantes que notifiquen la inconsistencia pe ro que pe rm ita inse rtar los registros.. 5. DESCRIPCIÓN DEL PROTOTIPO Para la e valuación de las alte rnativas presentadas en la primera se cción de este documento, se de cidió implementar un se rvicio pequeño que re cibe e l XML de datos de planning tool, parsea los datos ne ce sarios e inse rta e n la base de datos las tareas encontradas con la información básica. La idea de l prototipo es pone r en funcionam iento e l ESB de Jboss y realizar la inte gración con e l se rvicio que re cibe e l XML de planning tool y lo procesa e inse rta datos en e l repositorio de l spcc. El ambie nte se configuró de la siguiente mane ra: 1. JDK 5 v1.5.0_07 2. Ant v1.7.0 3. JBoss Application Se rve r v4.0.4 GA 4. JBossESB 4.0 RC 1 Para pone r en e je cución e l ESB se siguie ron las guías de iniciación y luego de configurar e l ambiente hasta lle gar a las ve rsiones arriba mencionadas se logró e je cutar la prime ra tarea, en la que a través de la cola de mensajes del se rvidor de aplicaciones se inte rcambia un.

(16) mensaje sencillo JMS introducido desde una aplicación exte rna y desplegado en la consola de l bus. Los e jemplos y las prue bas de l bus se desarrollaron con éxito ex ce pto con e l tema de las transformaciones pues con la documentación actual y los demos incluidos en la distribución de l ESB no se logró e je cutar con éxito ninguna de las transformaciones soportadas por Smooks2 ya que la compilación de las fue nte s te nía e rrores y en conse cuencia al hace r deploy no se re gistraban los listene rs corre ctamente . La configuración inicial para e l inte rcambio de mensajes se realizó de acue rdo con e l mode lo de pe rfiles en el que el inte rcambio de mensajes se realiza entre dos entidades y las transformaciones se realizan con e l propósito de que los mensajes “producidos” por una de las entidade s sea “consum ido” por e l otro participante. El inte rcambio de mensaje e ntre dos entidade s se describe de la siguie nte mane ra: 1. from: Nombre de l participante productor de l mensaje. 2. from-type: Tipo de mensaje de l productor (tipo de mensaje producido) 3. to: Nombre de l participante consum idor de l mensaje . 4. to-type: Tipo de mensaje del consum idor (tipo de mensaje consumido) En la documentación para e l desarrollador se e ncuentra de tallado el proceso para realizar transformaciones utilizando XSLT pe ro todavía no se e ncuentran disponibles las guías para utilizar otros me canismos y la manipulación de los múltiple s descriptores no se logró configura r de forma a de cuada para rea liza r la transformación con Java natural, en conse cue ncia tampoco hasta la última prueba realizada se ha logrado inte grar un web se rvice como access point.. 6. CONCLUSIONES Se definie ron las caracte rísticas de los módulos de represe ntación de proceso como componentes que se cone ctarán con los componentes del core de l table ro a través de las inte rfa ces a ctua les. Dichos módulos de a cue rdo con las e va luaciones rea lizadas no deben. 2. Smooks: Milyn Smooks es una herramienta para la administración de las transformaciones a través del conjunto de mensajes utilizando técnicas como perfilamiento de mensajes y otras técnicas utilizando implementación lógica en estándares como XSLT y Java común..

(17) desarrollar transformación de datos, únicamente provee r los se rvicios para re cibir y consultar la estructura de datos del módulo que repre sentan. Frente al cliente web los módulos de repre sentación de proce sos son autónomos lo cual incluye ve ntajas como la utilización de portales para la construcción configurable de la capa de prese ntación. La eva luación de las dife re ntes a lte rna tivas de integra ción, partiendo desde el tra ba jo ade lantado de web se rvices e incluye ndo te cnologías con gran a cogida en este momento, sirvió para de te rm inar la vía más e ficie nte. para desarrollar la integración de. las. he rramie ntas que alimentan el SPCC : Eleggua como infraestructura basada en e ventos pues tiene como ventajas: •. La integración igualitaria de cualquie r aplicación en donde e l m ismo table ro de control se ve como cualquie r participante productor – consum idor de eve ntos. •. El conocimie nto de l grupo sobre esta te cnología ha cre cido y se ha estabilizado la insta la ción de la misma lo cua l reduce e l tiempo de configura ción y se puede aprove char para realizar el análisis de datos de las aplicacione s a integrar.. Sobre el trabajo de integración de datos, la importancia radica en e l seguimie nto que se le haga a los mismos a lo largo de l ciclo de vida entre las dife re ntes aplicaciones de mane ra tal que todos los datos tengan respuesta ante una posible incohe rencia dependie ndo de l im pacto que tiene n sobre los análisis (puede n re gistrarse datos inconsiste ntes o no y en caso positivo te ndrán las fue ntes de estos datos confirmación o no). Finalmente el obje tivo de realizar un prototipo para la integración de l módulo de planeación y seguim iento no se pudo comple tar pues la comple jidad de la integración no radica e n la lógica que debe desarrollarse sino en la falta de documentación y e stabilidad de la te cnología en este momento.. 7. TRA BAJO FUTURO Una vez se ha de cidido la infraestructura de integración de se rvicios y se ha estable cido e l me canismo por e l cual los datos se integran con e l spcc: a través de módulos de representación de procesos que adm inistran la ex tensión del modelo de datos de acue rdo a sus reque rimientos, el trabajo de integración y definición del proce so con el que se debe.

(18) desarrollar un módulo nue vo tiene gran impacto sobre e l grupo pues conside rando la naturaleza de l trabajo que se de sarrolla en Qualde v, una vez se ha resue lto la te cnología se debe estandarizar la me todología de desarrollo. La integración de la presentación se de jó en e ste trabajo a conside ración de lo que de a cue rdo con traba jo a dela ntando con otros proye ctos se. conside re. como la me jor. alte rnativa. El alcance de esta investigación se lim ita a definir que los se rvicios para la pre sentación deben encontrarse autónomos en e l o los componentes que repre sentan un módulo y no mezclarse con los demás componentes de l core. La te cnología de los buses e stá ganando a cogida e n e l me rcado y aunque e n e l desarrollo de un prototipo no se encontraba con la ve rsión libre y comple ta, se re com ienda que el trabajo sobre e l bus de integración se continúe para futuros desarrollos pues e stá teniendo e ntrada fue rte e n e l me rcado a ctua lmente.. REFERENCIA S [1] SO A Web Se rvices Journal. Volumen 6. Noviembre 2006. [2] Kim ball, R ., Case rta, J. “The Data Warehouse ETL Toolkit”. W ile y. 2004. [3] Kim ball, R ., Ross M. “The Data Ware house Toolk it”. W iley 2002 [4] Keen Martin y otros, Ge tting Starte d with Websphe re Ente rprise Se rvice Bus. IBM RedBooks. 2006. Disponible e n: ibm.com /redbooks [5] JBossESB requirements and archite cture . Disponible en: http://labs.jboss.com/file-access/default/members/jbossesb/freezone/resources/project/JBossESBArchitecture.pdf. [6] López Nicolás, Infraestructura De Eventos Para Coope ración De Aplicaciones. Unive rsidad de los Andes. 2005.

(19)