Tem´atica: Informatizaci´ on
Componente de Servicios para la Integraci´ on de Aplicaciones Web Serviced based component for Web Application Integration Felix Ivan Romero Rodr´ıguez1* , Daniel Arturo Casals Amat 2 , Abraham Cal´ as Torres2 , 2 Ren´ e Rodrigo Bauta Camejo 1 GEYSED.
Centro de Geoinform´ atica y Se˜ nales Digitales. Departamento de Desarrollo de Componentes. Universidad de las Ciencias Inform´ aticas, Carretera a San Antonio de los Ba˜ nos, km 2 12 , Torrens, Boyeros, La Habana, Cuba. CP.:19370 2 CEIGE. Centro de Informatizaci´ on de Entidades. Departamento de Desarrollo de Componentes. Universidad de las Ciencias Inform´ aticas, Carretera a San Antonio de los Ba˜ nos, km 2 12 , Torrens, Boyeros, La Habana, Cuba. CP.:19370 ∗ Autor
para correspondencia:
[email protected]
Resumen La gesti´on de las dependencias es una disciplina orientada a interconectar componentes, aplicaciones o incluso dominios seg´ un as´ı se requiera. De esta manera los sistemas logran un paso para garantizar la interoperabilidad entre ellos y que sean extensibles. Con estas caracter´ısticas las aplicaciones desarrolladas describen los elementos que arquitect´onicamente deciden su escalabilidad a medida crecen en el tiempo. El presente trabajo propone un mecanismo para la gesti´ on de dependencias entre aplicaciones que responden a un dominio com´ un. Para ello el mecanismo se basa en una representaci´ on basada en grafos de dependencias que relacionan las dependencias y los servicios que la resuelven. Palabras claves: dependencias, gesti´ on, servicios ABSTRACT Dependencies management is oriented to interconnect components, applications or domains as well discipline required. In this way the systems achieve a step to ensure interoperability between them and are extensible. With these features applications developed architecturally describe the elements that determine their scalability as they grow in time. This paper proposes a mechanism to manage dependencies between applications that respond to a common domain. For this mechanism is based on a representation based on dependence graphs relating the dependencies and services that solve. Keywords: dependencies, management, services
1 Universidad de las Ciencias Inform´ aticas. La Habana, Cuba
Introducci´ on Conocer las dependencias de los sistemas tempranamente permite definir de forma precisa como quedar´ a la arquitectura de software. Teniendo en cuenta los componentes que utilizar´a un sistema en su construcci´ on define su escalabilidad y la manera que se comunica con otras aplicaciones. Es por ello que identificarla al inicio o durante la construcci´ on deviene en las toma de decisiones en cuanto a la construcci´on de software. La dependencia entre sistemas puede ser representada como la relaci´on que se establece entre componentes, paquetes, aplicaciones donde se necesita de las funcionalidades o salidas de uno o varios para que puede funcionar. Espec´ıficamente una aplicaci´ on depende de otra cuando su funcionamiento esta condicionado por la ejecuci´ on de una segunda aplicaci´ on. Como muestra de ello se pueden situar las aplicaciones que gestionan entidades con caracter´ısticas similares dentro de un mismo entorno, de manera que tienen duplicidad de entidades dentro de su mismo entorno de aplicaci´ on, as´ı como que incluyen las instrucciones necesarias para trabajarlas. Es entonces que surge la problem´ atica de como evitar la gesti´on duplicada de las entidades dentro de un mismo dominio de manera que una aplicaci´ on espec´ıfica realice la gesti´on sobre un conjunto de entidades espec´ıficas y otras aplicaciones se sirvan de sus funcionalidades evitando aumentar el esfuerzo en su construcci´ on para el manejo de artefactos existentes. Espec´ıficamente una aplicaci´on depende de otra cuando su funcionamiento esta condicionado por la ejecuci´ on de una segunda aplicaci´on. Desde una perspectiva binaria, la aplicaci´ on o
Figura 1. Dependencia entre Aplicaciones
el componente libre es el que se denomina antecedente, pues su funcionamiento no se encuentra condicionado externamente. El dependiente es quien tiene condicionado su comportamiento seg´ un cambie, o exista el antecedente. Definiendo formalmente esta relaci´on, seg´ un Larsson and Cmkovic Alhazbi and Jantan (2009) se dice que: Ci → Cj Lo cual significa que Ci tiene como antecedente a Cj . Cuando se trabaja con todo un conjunto (S) de componentes se tiene interdependencia entre ellos en un ecosistema lo cual se representa de la siguiente manera: D = (Ci → Cj ) : Ci , Cj ∈ SΛCi → Cj . El presente trabajo tiene como objetivo describir un componente para gesti´ on de dependencias nivel de dominio entre aplicaciones
Materiales y M´ etodos
Entornos de la gesti´ on de dependencias Inicialmente es necesario analizar c´ omo se lleva a cabo la resoluci´on de las dependencias, lo que permite concebir acciones para el mantenimiento y actualizaci´on de las aplicaciones. Estas acciones como parte de la 2 Universidad de las Ciencias Inform´ aticas. La Habana, Cuba
disciplina de gesti´ on tienen en cuenta la siguiente: Adici´on de componentes. Actualizaci´ on de componentes. Eliminaci´ on de componentes. A ra´ız de estas acciones, se debe tener en cuenta c´omo se afectan los componentes cada vez que se realiza un cambio ya sea en un sistema u otro que definan dependencias mutuas. Es por ello que en Alhazbi and Jantan (2009) proponen esta representaci´ on a trav´es de un grafo de dependencias donde se enlaza el nivel de afectaci´on que tiene cada una de ellas ante cambios previstos. Una vez que se obtiene el grafo, se interpola su matriz de adyacencia, esclareciendo el nivel de interdependencia entre cada componente, logrando analizar detalladamente cada relaci´ on ya sea directa o indirecta.
Figura 2. Grafo de Dependencias y Matriz de Adyacencia Alhazbi and Jantan (2009)
Tipos de dependencias Las dependencias en una aplicaci´ on no deben ser tratadas de la misma forma. Clasificando las dependencias es un modo de organizarlas en su tratamiento, lo que implica definir la acci´on a realizar seg´ un su especie. Para ello una opci´on es agrup´ andolas por similitud, de manera que a un conjunto de dependencias, que presenten un conjunto de caracter´ısticas representan un subconjunto del total de dependencias existentes o lo que ser´ıa: D = {K = {C1 ...Cn }ΛK ∈ S} Para clasificar las dependencias se tiene en cuenta la procedencia, fortaleza, criticidad y formalizaci´ on. De manera que seg´ un Keller and Kar (2000) las dependencia son clasificadas en: 3 Universidad de las Ciencias Inform´ aticas. La Habana, Cuba
Dominio Tipo de Componente. Tipo de Actividad. Dependencia Fuerte. Dependencia Formalizada.
Seguridad en la gesti´ on de dependencias La integridad, confiabilidad y disponibilidad de las dependencias influye en el funcionamiento de las aplicaciones interdependientes. Si uno de estos principios es alterado, repercute en c´omo funcionan los componentes de software y sus dependencias. Si la seguridad en este proceso no es tomada en cuenta, el sistema estar´ a arquitect´onicamente vulnerable. En Cappos et al. (2008) se proponen una serie de actividades con vista a asegurar la gesti´on de paquetes, la cuales son: Validar la comunicaci´ on. Seguimiento de las marcas y firmas temporales. Protecci´on de la conexi´ on mediante HTTPS. Aseguramiento de Servidores espejos. Firma de paquetes y metadatos. Comprobar la integridad de los metadatos.
Resultados y discusi´ on El componente para su funcionamiento debe realizar operaciones relacionadas con la gesti´on de dependencias. Primeramente crea un registro donde plasma las dependencias que presenta la aplicaci´on donde se encuentra alojado. Este registro es representado en json, el cual registra por cada componente su versi´ on, nombre, localizaci´on (uri) y las dependencias en caso de que aplique. De la misma manera que registra sus dependencias crea un registro de los recursos que brinda. Una vez que se tiene representado los recursos de los que se depende y los que se brindan, es necesario conocer el nivel de conexi´on entre ellos, garantizando que todas las dependencias queden resueltas y no queden componentes sin funcionar. Para ello al leer todas las representaciones se puede obtener un grafo que indica las conexiones entre cada uno de los componentes. A partir del grafo identificado, 4 Universidad de las Ciencias Inform´ aticas. La Habana, Cuba
se identifica como un grafo dirigido ac´ıclico Thulasiraman (1992) (DAG). Un DAG es un grafo dirigido, que no posee ciclos, de manera que siguiendo los v´ertices que interconectan los nodos no se regresa al inicio, ello permite recorrer los caminos posibles de dependencias por cada componente o recurso, adem´as la no existencia de ciclos asegura la integridad de cada componente, ya que la dependencia mutua entre dos componentes no existe. Luego se realiza un ordenamiento topol´ogico Sedgewick, Robert; Wayne (2011), que muestra una lista de las relaciones existentes y se registra esta lista por cada componente. El ordenamiento topol´ ogico tiene como base 2 maneras de ejecutarse, a trav´es del reetiquetado o la reposici´on de sus nodos Coto (2003). Debido a las caracter´ısticas mencionadas de un DAG, se puede representar a trav´es de su estructura un grafo de dependencias, como se define en Xia et al. (2010), donde se utiliza con el mismo fin. Una vez representadas las dependencias y los servicios que la resuelven en el grafo, s´olo resta acceder a su definici´on cada vez que se necesite saber como utilizar una entidad espec´ıfica.
[Proceso de gesti´ on de dependencia] El proceso inicia cuando el componente accede a una lista de las aplicaciones que coexisten en su entorno y comienza a recuperar por cada una de ellas las dependencias que necesitan y las que resuelven. Luego de ello realiza la representaci´ on a trav´es de un mapa de dependencias a partir del grafo de dependencias que genera, lo que permite acceder a cada definici´ on cada vez que solicite una nueva dependencia. Luego a trav´es de un mecanismo de persistencia guarda el grafo generado. Luego cuando una aplicaci´on depende de una entidad en espec´ıfico y necesita saber como poder obtenerla, para ello la entidad debe tener en su definici´ on el entorno o dominio en que coexiste, d´ıgase por ejemplo la entidad Estudiante del Dominio Facultad. De la misma manera, debe expresar que se necesita de un estudiante. El comonente busca que aplicaci´on puede resolver dicha dependencia, y devuelve a la aplicaci´on dependiente c´omo acceder a los recursos que est´ a solicitando. Una vez realizada la operaci´ on se accede al recurso y se opera seg´ un lo que se requiera. Para la realizaci´ on del componente fue necesario apoyarse en buenas pr´acticas en la programaci´on. Como parte de dichas pr´acticas fue la utilizaci´ on del par llamado problema soluci´on como patr´on de dise˜ no Larman (1999). En la implementaci´ on fue necesario la utilizaci´on del patr´on de Localizador de Recursos Fowler (2004). Donde se define una entidad intermediaria capaz de localizar los recursos que necesitan una dependencia y devolverla, evitando que las aplicaciones dependientes conozcan exactamente como llegar al recurso. Ello posibilita que si cambia la fuente de los recursos las aplicaciones dependientes puedan encontrar una nueva fuente de recursos.
Trabajos Relacionados
Composer Composer Community (2013) es un gestor dependencias para PHP , seg´ un su mecanismo se declaran las dependencias que puedan existir en un proyecto y a partir de las dependencias definidas se resuelven todas 5 Universidad de las Ciencias Inform´ aticas. La Habana, Cuba
Figura 3. Ejemplo Representaciones de una dependencia
para el proyecto, Las dependencias deben estar expl´ıcitas en la configuraci´on de proyectos de este tipo. El funcionamiento de Composer consiste en declarar las dependencias y construir la aplicaci´on sobre esa definici´ on. Al completarse, es necesario ejecutar la orden que permite satisfacer las dependencias y entonces el mecanismo de este gestor se encarga de descargar y configurar los antecedentes previamente descritos.
Spring Dynamic Modules Spring Dynamic Modules Cogolu`egnes et al. (2010) es una combinaci´on de tecnolog´ıas basadas en Java, que permite crear un registro que interconecta aplicaciones. Como intermediario posee un rgistro que se encarga de gestionar las dependencias entre m´ odulos e incluso gestionar el estado en que se encuentra determinado m´odulo comprobando si se pueden utilizar sus funcionalidades. Su configuraci´on es lo suficiente expl´ıcita lo que implica amplios conocimientos para desarrollar sin embargo su utilizaci´on permite a˜ nadir funcionalidades modularmente y de manera din´ amica.
Git Git es un sistema de control de versiones Chacon (2009) distribuido, utilizado para llevar el hist´ orico de desarrollo de proyectos. A diferencia del control de versiones centralizado, trabaja con capturas del proyecto y no con diferencias. A partir de esta particularidad representa la historia del proyecto a trav´es de una relaci´ on de nodos, construyendo para su navegaci´on un Grafo Dirigido Ac´ıclico, lo que permite navegar entre cada diversificar las procedencias de cada actualizaci´on y manejar su conjunto como un sistemas de ficheros.
6 Universidad de las Ciencias Inform´ aticas. La Habana, Cuba
Conclusiones A diario las aplicaciones en un ecosistema de software duplican funcionalidades similares, ello implica duplicar esfuerzos cuando se pueden especializar en operaciones que las distingan entre ellas. Mediante la gesti´ on de dependencias de las aplicaciones, sobre todo las referentes al dominio de entidades, una aplicaci´ on puede agrupar los procesos sobre un conjunto de entidades y otras aplicaciones pueden reutilizar las funcionalidades a trav´es de servicios. Ello conlleva a la integraci´on de aplicaciones que se desempe˜ nan en un entorno com´ un. El presente trabajo demuestra c´ omo se puede aplicar estos conceptos aplicando t´ecnicas para la gesti´ on de dependencias.
Referencias Saleh Alhazbi and Aman Jantan. Dependencies Management in Dynamically updateable Component Based Systems. page 10, 2009. Justin Cappos, Justin Samuel, Scott Baker, and John H Hartman. Package Management Security. page 20, 2008. Scott Chacon. Pro Git. Springer, New York, 2009. ISBN 9781430218333. Arnaud Cogolu`egnes, Thierry Templier, and Andy Piper. Spring Dynamic Modules in Action. Manning Publications Co., Suamford, 2010. ISBN 9781935182306. The Composer Community. The Composer Community October 2, 2013. 2013. Ernesto Coto. Algoritmos B´ asicos de Grafos. page 26, 2003. Martin Fowler. Inversion of control containers and the dependency injection pattern, 2004. Alexander Keller and Gautam Kar. Dynamic Dependencies in Application Service Management. Technical report, IBM, New York, New York, USA, 2000. Craig Larman. UML y Patrones. Pearson, 2nd edition, 1999. Kevin Sedgewick, Robert; Wayne. Algorithms. Addison-Wesley, 4 edition, 2011. ISBN 9780132762564. K.; Swamy Thulasiraman. Graphs: Theory and Algorithms. John Wiley and Son, New York, NY, USA, 1992. ISBN 978-0-471-51356-8. Yinglong Xia, Viktor K Prasanna, and James Li. Hierarchical Scheduling of DAG Structured Computations on Manycore Processors with Dynamic Thread Grouping aˆ
