PÚBLIA BLIIANA VNZULA UNIVIA AFAL UANTA FAULTA INGNIÍA ULA INGNIÍA N MPUTAIÓN ALL AMINTA INTGAIÓN AT PATI BAAA N AQUITTUA B Trabajo special de Grado presentado ante la Universidad afael Urdaneta para optar al título de: INGNI MPUTAIÓN Autores: Br. Andrés Leonardo rtega lano Br. Lascario José Pacheco Arrieta Tutor: Jubert Pérez Maracaibo, diciembre de 2014
ALL AMINTA INTGAIÓN AT PATI BAAA N AQUITTUA B rtega lano, Andrés Leonardo Pacheco Arrieta, Lascario José.I. 22463397.I. 22.452.241 ector Tierra Negra, Av. 11, #69-47 ector Pueblo Nuevo, Av 9B, #60B-55 Telf: (0424) 6404229 Telf: (0424) 6186531 andresortegao@hotmail.com lascariopacheco@hotmail.com Pérez Zabala, Jubert Tutor académico
AGAIMINT A mis padres, Lascario Pacheco y aquel Arrieta, por haberme dado la oportunidad de llegar hasta aquí y por apoyarme y orientarme toda la vida. A mi familia, por hacerme lo que soy. A mis amigos, porque sin ellos el viaje de la vida no tendría sentido. A Verónica orena, porque ella me impulsa a ser más. A los profesores y al personal de la Universidad afael Urdaneta, por ser excelentes personas. - Lascario Pacheco.
ÍNI GNAL UMN ABTAT Pág. INTUIÓN. 1 1. APÍTUL I. L PBLMA... 3 1.1. Planteamiento del problema........3 1.2. bjetivos.......7 1.3. Justificación...8 1.4. elimitación.....9 1.4.1. elimitación temporal...9 1.4.2. elimitación espacial...10 1.4.3. elimitación científica...10 2. APÍTUL II. MA TÓI..11 2.1. Antecedentes de la investigación 11 2.2. onceptos Básicos 13 2.2.1 oftware 13 2.2.1.1. oftware de aplicación 13 2.2.1.2. oftware de sistema 14 2.2.2. ardware..14 2.2.3. istema de información.15 2.2.3.1. omponente y módulo 16 2.2.4. Middleware...16 2.2.4.1. Middleware orientado a mensajes 17 2.3. Fundamentos teóricos... 18 2.3.1. erramienta de software 18 2.3.2. Integración de datos...18 2.3.3. Interoperabilidad.19 2.3.4. Nivel corporativo.19 2.3.5. Arquitectura de software 20 2.3.5.1. Tipos de arquitectura de software 21 2.3.5.1.1. ervice oriented architecture.....21 2.3.5.1.2. Modelo vista controlador.21 2.3.5.1.3. Arquitectura dirigida por eventos...22 2.3.6. nterprise application integration (AI)..23 2.3.7. nterprise ervice Bus.. 23 2.3.7.1. onectores 24 2.3.8. erramientas B......25 2.3.9. Mule B Anypoint tudio....26 2.3.9.1. Anypoint tudio...26
2.3.9.1.1. Aspectos generales de la herramienta 26 2.3.9.1.2. Interfaz de usuario.. 26 2.3.9.1.2.1. xplorador de paquetes.....26 2.3.9.1.2.2. ditor gráfico....27 2.3.9.1.2.3. ditor XML....27 2.3.9.1.2.4. xplorador de conexiones.. 27 2.3.9.1.2.5. onsola.. 27 2.3.9.1.3. Funciones adicionales....28 2.3.9.1.3.1. Instalar nuevo software... 28 2.3.9.1.3.2. esplegar aplicación... 28 2.3.9.2. Mule B.....29 2.3.10. squema de distribución de servicios en una implementación B...29 2.3.10.1. ubsistemas básicos... 30 2.3.10.1.1. eguridad......31 2.3.10.1.2. Acceso a base de datos... 31 2.3.10.1.3. Mensajería.. 31 2.3.10.1.4. eportes.....32 2.3.10.1.5. Logs.....32 2.3.10.2. Módulos de negocio.....32 2.3.10.2.1. ervicios y no aplicaciones.. 33 2.3.10.2.2. ervicios de alto nivel...33 2.3.10.3. Módulos de cliente....33 2.3.10.4. xtensiones.... 34 3. APÍTUL III. MA MTLÓGI.....35 3.1. Tipo de investigación.35 3.2. iseño de la investigación.... 36 3.3. Técnicas e instrumentos de recolección de datos...36 3.3.1. bservación indirecta estructurada.36 3.4. Fases de la metodología..37 3.4.1. Fase de análisis de requerimientos del sistema 37 3.4.2. Fase de planificación del desarrollo 38 3.4.3. Fase de diseño y codificación del sistema.38 3.4.4. Fase de pruebas....39 3.4.5. Fase de distribución 39 4. APÍTUL IV. ANÁLII L ULTA...40 4.1. Análisis de requerimientos...40 4.1.1. equerimientos de hardware 41 4.1.1.1. ervidor de Mule B....41 4.1.1.2. liente de aplicación demostrativa...41 4.1.2. equerimientos de software.....42 4.1.2.1. ervidor Mule B.. 42 4.1.2.2. liente de aplicación demostrativa.....42 4.1.3. Análisis y priorización de requerimientos genéricos.42
4.1.3.1. Análisis y priorización de requerimientos de software.43 4.1.3.2. Análisis y priorización de requerimientos de hardware...44 4.1.4. equerimientos de diseño...46 4.2. Planificación del proyecto...47 4.2.1. istorias de usuario.. 47 4.2.1.1. Módulo de inicio de sesión...48 4.2.1.2. Módulo de consulta de base de datos.50 4.2.1.3. Módulo de consulta de archivo de texto.51 4.2.1.4 Módulo de consulta de hoja de cálculo.52 4.2.1.5. Módulo principal del sistema. 53 4.3. iseño del sistema....54 4.3.1. Modelo de datos....54 4.3.1.1. Modelo de datos para el ingreso de usuario y seguridad general.55 4.3.1.2. Modelo de datos de la aplicación....56 4.3.2. Módulos de sistema integrado....58 4.3.2.1. Módulos del sistema de acuerdo con las historias de usuario...59 4.3.2.2. Módulos del sistema de acuerdo con los modelos de datos..60 4.3.2.3. Módulos del sistema finales.61 4.3.3. iagramas UML del sistema de integración.62 4.3.3.1. iagrama de casos de uso de la aplicación demostrativa..62 4.3.3.2. iagrama de componentes del sistema.64 4.3.3.5. iagramas de estados del sistema.65 4.3.3.5.1. iagrama de estados del objeto de consulta de base de datos.65 4.3.3.5.2. iagrama de estados del objeto de consulta de hoja de cálculo.66 4.3.3.5.3. iagrama de estados del objeto e consulta de archivo de texto..67 4.3.3.5.4. iagrama de estados del objeto de consulta de credenciales.68 4.4. esarrollo de los módulos del sistema..69 4.4.1. esarrollo de los subsistemas básicos..70 4.4.1.1. ubsistema de acceso a base de datos..70 4.4.1.2. ubsistemas de logs...71 4.4.2. esarrollo de los objetos de negocio del sistema.72 4.4.2.1. bjeto de consulta de base de datos..73 4.4.2.2. bjeto de consulta de datos en archivo de texto...77 4.4.2.3. bjeto de consulta de datos en hoja de cálculo...79 4.4.2.4. bjeto de consulta de credenciales de usuario...82 4.5. Interfaces de la aplicación demostrativa..85 4.5.1. Interfaz de inicio de sesión..85 4.5.2. Interfaz principal del sistema...88 4.6. Pruebas a los módulos del sistema...91 4.6.1. Pruebas unitarias...91 4.6.1.1. esultados de las pruebas unitarias 92 4.6.1.2. onclusión de las pruebas unitarias 93 4.6.2. Pruebas de integración...93 4.6.2.1. esultados de las pruebas de integración.93 4.6.2.2. onclusión de las pruebas de integración.93
4.6.3. Pruebas de estrés.....94 4.7. Integración e implementación de los módulos del sistema...98 4.7.1. esarrollo de la aplicación alojada en el servidor web del front-end 99 4.7.1.1. ervlet de consulta de base de datos.99 4.7.1.2. ervlet de consulta de archivo de texto.99 4.7.1.3. ervlet de consulta de hoja de cálculo..100 4.7.1.4. ervlet de consulta de credenciales de usuario..100 4.7.2. escripción del entorno de pruebas y demostraciones utilizado.100 4.7.3. escripción de las acciones demostrativas utilizadas 102 NLUIN...103 MNAIN...105
ÍNI TABLA Tabla 1. equerimientos de software para el cliente web..46 Tabla 2. istoria de usuario del módulo de inicio de sesión..49 Tabla 3. istoria de usuario del módulo de consulta a base de datos. 50 Tabla 4. istoria de usuario del módulo de consulta de archivo de texto 51 Tabla 5. istoria de usuario del módulo de consulta de hoja de cálculo.. 52 Tabla 6. istoria de usuario del módulo principal del sistema...53 Tabla 7. esultados de pruebas de estrés de módulo de consulta de archivo de texto..95 Tabla 8. esultados de pruebas de estrés de módulo de consulta a hoja de cálculo..96 Tabla 9. esultados de pruebas de estrés de módulo de consulta a base de datos.97 Tabla 10. escripción de características de hardware y software de los equipos de despliegue....101 Tabla 11. escripción de las características de software de los equipos de despliegue...101 1
ÍNI FIGUA Figura 1. Jerarquía de los módulos del sistema.. 30 Figura 2. Modelo de datos del módulo de inicio de sesión.55 Figura 3. iagrama entidad relación del módulo de inicio de sesión 56 Figura 4. Modelos de datos de la aplicación demostrativa.57 Figura 5. iagrama entidad relación de la aplicación demostrativa.. 58 Figura 6. Vista general de los módulos del sistema (historia de usuario)...59 Figura 7. Vista general de los módulos del sistema (modelo de datos)...60 Figura 8. iagrama de casos de uso del sistema...63 Figura 9. iagrama de componentes del sistema...64 Figura 10. iagrama de estados del objeto de consulta de datos...66 Figura 11. iagrama de estados del objeto de consulta de hoja de cálculo...67 Figura 12. iagrama de estados del objeto de consulta de archivo de texto...68 Figura 13. iagrama de estados del objeto de consulta de credenciales...69 Figura 14. Formulario de configuración del subsistema básico de acceso a base de datos...7 1 Figura 15. Formulario de configuración del subsistema básico de logs...72 Figura 16. iagrama de flujo de mensajes del objeto de consulta de base de datos 73 Figura 17. Formulario de configuración del componente de solicitud/respuesta TTP (obj. de acceso a base de datos)......74 Figura 18. Formulario de configuración del subsistema de acceso a base de datos (obj. de acceso a base de datos)...75 Figura 19. Formulario de configuración avanzada del subsistema de acceso a base de datos...76 Figura 20. iagrama de flujo de mensajes del objeto de consulta de archivo de texto..77 Figura 21. Formulario de configuración del componente de solicitud/respuesta TTP (obj. de consulta de archivo de texto)...78 Figura 22. Formulario de configuración del componente de ejecución de código Java..79 Figura 23. iagrama de flujo de mensajes del objeto de consulta de hoja de cálculo..79 Figura 24. Formulario de configuración del componente de solicitud/respuesta (obj. de consulta de hoja de cálculo)...80 Figura 25. Formulario de configuración del componente consumidor de web services...81 Figura 26. Formulario de configuración avanzada del componente consumidor de web services.....81 Figura 27. Formulario de configuración del componente Mapper...82 2
Figura 28. iagrama de flujo de mensajes del objeto de consulta de credenciales...83 Figura 29. Formulario de configuración del componente de solicitudrespuesta TTP (obj. de consulta de credenciales)...83 Figura 30. Formulario de configuración del subsistema de acceso a base de datos (obj. de consulta de credenciales)...84 Figura 31. Bosquejo de las interfaces de inicio de sesión...86 Figura 32. Interfaces de inicio de sesión...87 Figura 33. Bosquejo de la interfaz principal(1)...89 Figura 34. Bosquejo de la interfaz principal (2)...90 Figura 35. Interfaz principal desarrollada...91 Figura 36. Pruebas unitarias...92 Figura 37. iagrama de despliegue del sistema...98 3
rtega lano Andrés Leonardo, Pacheco Arrieta Lascario José. ALL AMINTA INTGAIÓN AT PATI BAAA N AQUITTUA B. Trabajo especial de grado. Universidad afael Urdaneta. Facultad de ingeniería de computación. Maracaibo abril, 2015. UMN l presente trabajo de grado tiene como objetivo principal el desarrollo de una implementación de B para la integración de datos de forma interoperable en plataformas corporativas, presentando una aplicación demostrativa que refleje su funcionamiento. n el marco metodológico la investigación se clasifica como de tipo proyectiva o proyecto factible con un diseño de laboratorio, transeccional contemporáneo, multivariable de caso. La metodología de software utilizada para el desarrollo de la aplicación fue la de programación extrema, siguiendo las fases de análisis y requerimientos del sistema, planificación del desarrollo, diseño y codificación del sistema, pruebas, y distribución. La aplicación demostrativa consiste en una aplicación web donde el cliente, accesible desde un navegador, realiza solicitudes a un servidor web el cual a su vez ejecuta peticiones al bus de servicios para poder extraer información desde distintas fuentes: un archivo de texto, una hoja de cálculo, y una base de datos; utilizando como plataforma para la integración el bus de servicios Mule B por su desempeño y alta escalabilidad. Palabras clave: Integración de datos, Bus de servicios empresariales, aplicación web, interoperabilidad, servicios web. andresortegao@hotmail.com lascariopacheco@hotmail.com 1
rtega lano Andrés Leonardo, Pacheco Arrieta Lascario José. VLPMNT F A PAT ATA INTGATIN TL BA N B AITTU. egree thesis. Universidad afael Urdaneta. Facultad de ingeniería de computación. Maracaibo abril, 2015. ABTAT The present degree thesis has as main goal the development of an B implementation for the data integration of interoperable way in corporate platforms, presenting an illustrative application that reflects its functioning. In the methodological framework the investigation is classified as a projective type or feasible project with a laboratory design, contemporary transactional, multivariable of case. The software methodology used for the development of the application was extreme programming, following the analysis and system requirements, planification of the development, design and codification of the system, tests, and distribution phases. The illustrative application consists in a web application where the client, accessible from a browser, makes requests to a web server which executes requests to a service bus to be enable to extract information from different sources: a text file, a spreadsheet, and a database; using as platform for the integration the Mule B for its performance and high scalability. Keywords: ata integration, interoperability, web services. nterprise service bus, web application, andresortegao@hotmail.com lascariopacheco@hotmail.com 2
INTUIÓN n el mundo actual, la tecnología se ha visto muy acoplada con los procesos de negocio que manejan las empresas, independientemente de su tamaño. in embargo, ocurre algo en las corporaciones de mayor tamaño que no ocurre en las A V obligadas a utilizar los componentes tecnológicos más eficientes. n esta búsqueda de la eficiencia se presentan casos en los cuáles un componente de software no es compatible con otro; se está en presencia de empresas pequeñas: la cantidad de información manejada en las primeras supera por mucho a las segundas. s por esta razón que estas grandes industrias se ven islotes de procesamiento, en los cuales cada componente hace las cosas a su manera, de forma cerrada. s en estos casos en los cuales hace falta emplear algún mecanismo que permita a estas aplicaciones cerradas a interactuar entre ellas, de forma que puedan unirse y ofrecer funcionalidades que de verdad concuerden con el objetivo de las empresas. s en estos casos en los cuales aparece un problema y una solución: la integración de aplicaciones. sta integración permitirá que las aplicaciones que trabajan de forma aislada compartan un conjunto común de información, compartan datos y los utilicen como si estuvieran realmente diseñadas para trabajar en conjunto. in embargo, muchos de los acercamientos que se han realizado para tratar de solventar esta problemática no siempre logran hacerlo de forma eficaz, fácil y escalable. A pesar de todo esto, existe una solución que promete solventar el problema cumpliendo con los requerimientos mencionados previamente: la arquitectura B. s por ello que este proyecto de investigación pretende promover el desarrollo de soluciones de integración de sistemas basados en esta tecnología que, a pesar de no ser tan nueva, no goza de la popularidad y comunidad que 1
realmente merece. s por esto que se aprovecharán las ventajas de esta arquitectura en miras de ofrecer una aplicación demostrativa que permita palpar estas características propias de la arquitectura B. 2
APÍTUL I L PBLMA 1.1 Planteamiento del Problema A nivel informático, la integración de datos hace referencia a una disciplina encargada de permitir que distintas aplicaciones tengan acceso a los datos de operar efectivamente. Por lo general, la integración de datos conduce a la consiste en la combinación de datos interoperabilidad, pues la segunda de distinta índole, la cuales, generalmente, provenientes de aplicaciones otras, de forma que las mismas posean toda la información que necesitan para almacenan sus datos de forma distinta, con el fin de llevar a cabo una función dentro de un sistema. Por otra parte, las arquitecturas utilizadas en el ámbito empresarial están conformadas por distintos módulos separados, con el fin de sacar mayor provecho a las tecnologías que mejor se adapten a cada área. stos sistemas pueden haber sido desarrollados dentro de la misma organización o por una compañía tercera. También pueden funcionar en sistemas operativos distintos, almacenando la información en diferentes formatos, cada uno con su propia base de datos. Por esta razón, desde el punto de vista empresarial, la integración de datos y la interoperabilidad ofrecen tiempos de ejecución de procesos más reducidos, al permitir que las aplicaciones requeridas por una organización compartan repositorios de datos y utilicen los mismos para funcionar de manera óptima, dando lugar a la evasión de redundancia innecesaria y al rápido acceso a la información requerida por una aplicación de la empresa. A propósito, Menge (2007) afirma que en los últimos catorce años se han desarrollado diversas soluciones a este tipo de situaciones, siendo la primera integración punto a punto, donde el problema de integración es manejado por un 3
conector específico para cada par de aplicaciones del sistema que necesiten comunicarse; luego se dio lugar a nterprise Application Integration (AI), la cual es una disciplina que se apoya en la utilización de software y de principios de arquitectura de sistemas computacionales para lograr la integración e interoperabilidad de distintos módulos en una empresa, a través de un medio centralizado. A basada en ub and poke (A) o integración punto a punto comenzó a ser V de mantenimiento o la insuficiente por diversas razones, como altos costos en soluciones que no poseían una alta necesidad de realizar grandes inversiones esta necesidad de una solución con mayores escalabilidad. egún Biske (2011), espués, con el paso de los años, el primer acercamiento a una solución óptima prestaciones se vio satisfecha con la aparición de ervice riented Architecture (A) y nterprise ervice Bus (B), que permitían lograr la interoperabilidad de un conjunto de módulos manteniendo una alta escalabilidad a costos de implementación más bajos. n la actualidad, la integración de datos basada en A y punto a punto aún se utiliza, pues estos modelos han evolucionado para lograr su cometido utilizando A, pero manteniendo sus desventajas de costo y escalabilidad. Ahora bien, cuando no existe integración de ningún tipo dentro de un sistema, los módulos involucrados no se comunican con ningún otro, viéndose forzados a utilizar bases de datos locales para el funcionamiento de cada una de sus aplicaciones. Más aún, al no poseer un medio de intercambio de información, los datos necesarios para el funcionamiento de cada una de las aplicaciones dentro de los módulos deben ser cargados por sus operadores respectivos. Además, los síntomas previamente mencionados se ven agravados debido a que cada módulo debe almacenar la información necesaria para funcionar por su cuenta, de forma que en el sistema existen diversas réplicas de los mismos datos, 4
una para cada módulo, en caso de que el mismo la necesitase. umado a esto, los procesos que requieren la ejecución de aplicaciones ubicadas en distintos módulos se llevan a cabo con lentitud; los operadores encargados de las aplicaciones deben utilizar medios externos a las aplicaciones para enviar información a otros operadores. Por añadidura, la ausencia de un medio normalizado a través del cual los módulos lenta y redundancia de datos innecesaria dentro del sistema,v yaa que no puede módulos sin una vía de manejarse integración de datos o interoperabilidad entre comunicación. on esto se intenta expresar que no puede existir un sistema método de integración de datos, pues, si no se modular multiplataforma sin un puedan intercambiar información es la principal causa de ejecución de procesos alcanza esto, es imposible que se logre la interoperabilidad, que es la razón por la cual se implementa un sistema multiplataforma. Por consiguiente, si estas causas no se atacan a tiempo, la calidad de servicio del sistema decaerá enormemente, debido a que no se maneja un sistema de integración de datos que permita ahorrar espacio en discos, derivando en la necesidad de adquirir equipos más potentes en intervalos de tiempo muy cortos, ya que la capacidad de los que existiesen se vería abrumada rápidamente. Incluso, dada la forma en la que se transmiten los datos entre módulos, se espera que los errores de transcripción humanos se manifiesten frecuentemente, al tener que intervenir el personal de forma más seguida en el proceso de carga de datos a las aplicaciones, derivando en un sistema lento a la hora de procesar información y ofrecer resultados. n suma, un sistema de gran tamaño, que posea diferentes módulos con diferentes plataformas y que no maneje integración de datos e interoperabilidad es inestable, lento y requiere grandes inversiones para poder mantenerse funcionando. 5
Análogamente, cuando existe integración punto a punto la situación se agrava progresivamente, ya que dada la cantidad de módulos presente en una corporación, la implementación de este método es poco mantenible y requiere grandes inversiones en el desarrollo y mantenimiento de los enlaces entre módulos, puesto que ampliar la cantidad de módulos en el sistema también aumentará la cantidad de enlaces presentes en el mismo. A corporativo cual requieren su propio desarrollo y mantenimiento particular. l nivel V del sistema indica que la cantidad de módulos que debe manejarse es elevada, razón por la cual ajustar los enlaces a las políticas de la empresa añade costos al mantenimiento y desarrollo. Las actualizaciones de los productos de terceros implementados en los enlaces añaden más costos a la ya gigantesca suma de n otras palabras, los enlaces entre los módulos son individuales, razón por la dinero que conlleva el mantenimiento de los mismos. n resumen, si no se obtiene una solución distinta a la implementada actualmente, se estima que los costos por mantenimiento a los enlaces punto a punto crecerán hasta volverse insostenibles, derivando en la obsolescencia del sistema, lo cual da lugar a peligrosas brechas de seguridad que son tratadas por las actualizaciones a los enlaces, las cuales no pueden ser aplicadas debido al alto costo que supone mantenerlos. sto se ve agravado por la gran cantidad de enlaces que se requieren para el funcionamiento de todos los módulos de una corporación. in embargo, diversas organizaciones de desarrollo tecnológico ya han dado respuesta a este tipo de problemas, ofreciendo un software integrador de datos que maneja la mayoría de las necesidades de la empresa denominado nterprise esource Planning (P). Pero, como aclara eo (2013), este tipo de implementaciones, al integrar distintos procesos empresariales en un sólo sistema, causan inevitablemente cambios drásticos en los procesos y organización de la 6
empresa, acarreando altos costos en reingeniería, entrenamiento de personal, y planeación. Por esta razón, la solución a los problemas mencionados anteriormente es diseñar y desarrollar una versión funcional de un medio integrador de datos basado en B, el cual ofrecerá una vía de comunicación para todas las aplicaciones presentes en el sistema, dando lugar a la integración de datos e interoperabilidad. Amencionado Para resumir, los B permiten solucionar los problemas que se han V con anterioridad, ya que, de acuerdo con Goel (2008), su implementación no es mantenible y posee un alto nivel de demasiado costosa, es adecuadamente escalabilidad, dando lugar a un nuevo nivel de crecimiento empresarial para la organización que lo utilice, al ofrecerle un mejor nivel de desempeño frente a grandes cantidades de datos, disminuyendo la tasa de errores en la carga de datos al sistema, y aumentando la eficiencia de cada uno de los módulos del mismo. 1.2 Formulación del Problema 1. ómo desarrollar un sistema para la integración de datos basado en B orientado a un ambiente corporativo? 2. uáles son los requerimientos, a nivel de software y hardware, para realizar una implementación de integración de datos basada en B? 1.3 bjetivos 1.3.1 bjetivo General esarrollar una implementación de B para la integración de datos de forma interoperable en plataformas corporativas. 7
1.3.2 bjetivos specíficos 1. efinir la arquitectura del software. 2. iseñar la estructura de datos para los módulos del sistema de integración. 3. ealizar los diagramas de casos de uso, componentes, clases, interacción, estados, y despliegue. 4. esarrollar los módulos del sistema siguiendo las especificaciones y diseños planteados. 6. esarrollar una aplicación demostrativa que refleje el funcionamiento del sistema. 5. ealizar pruebas de estrés, unidad, e integración a cada uno de los módulos que componen el sistema. 1.4 Justificación e Importancia de la Investigación n el ámbito competitivo de la actualidad, la sostenibilidad, desarrollo, y crecimiento de una empresa están directamente relacionados con la eficiencia con que se llevan a cabo sus procesos productivos, y hoy en día, esta eficiencia depende en gran medida de la plataforma tecnológica en la que se sitúa, por lo que es necesario para una empresa contar con unas bases informáticas sólidas, teniendo en cuenta las últimas tendencias de integración de datos e interoperabilidad, las cuales han probado ser las más eficientes popularizadas actualmente, posicionándola como una entidad dinámica y robusta, invulnerable al paso del tiempo, y que aprovecha la tecnología para ofrecer la mejor calidad de servicio a sus clientes y asociados, además de mantener sus sistemas invirtiendo menores cantidades de dinero, mientras se conserva la eficiencia de los procesos llevados a cabo por la misma, facilitando la escalabilidad del sistema al requerir pocas acciones adicionales para lograr el crecimiento en el número de módulos involucrados en el sistema. 8
conómicamente, una empresa se ve beneficiada con la integración de datos e interoperabilidad, debido a que sus procesos se realizan en períodos de tiempo más cortos y con una tasa de error mucho más reducida, a la vez que le permite aprovechar las ventajas de cada una de las distintas plataformas disponibles en el mercado. Por consiguiente, se alcanza una mayor calidad en el servicio ofrecido por la organización, lo cual atrae a una inmensa cantidad de clientes a la misma, aumentando aún más sus ingresos. Por otro lado, desde el punto de vista tecnológico, el desarrollo de este tipo de versatilidad de los B, así como también da a conocer nuevos enfoques a la hora de describir el funcionamiento de esta herramienta, promoviendo así el implementaciones ofrece a la comunidad científica una referencia más de la avance de esta solución al gran problema que supone integrar datos y ofrecer interoperabilidad a nivel corporativo. 1.5 elimitación de la Investigación l principal enfoque de este trabajo especial de grado es ofrecer a la comunidad empresarial venezolana una perspectiva moderna sobre la agilización de sus procesos informáticos, empleando técnicas de integración de datos e interoperabilidad que aún no han sido totalmente aceptadas por esta parte de la población. Para lograr dicho cometido se plantea una versión demostrativa de una implementación de un sistema interoperable gracias a B, que es una arquitectura basada en A, con principios de AI que facilita la tarea de integración de datos en sistemas corporativos multiplataforma. 1.5.1 elimitación Temporal 9
La investigación se realizará en un período de dos trimestres, correspondiendo a los semestres 2014-B y 2014- de la universidad. 1.5.2 elimitación spacial La investigación se llevará a cabo en la Universidad afael Urdaneta, la cual está ubicada en la Vereda del Lago, en Maracaibo, stado Zulia. sta investigación corresponde al área de computación e informática, estando inclinada a la integración de datos e interoperabilidad a nivel corporativo. 1.5.3 elimitación ientífica 10
APÍTUL II MA TÓI sta sección tiene como principal propósito la instauración y exposición, acudiendo a proyectos e investigaciones realizadas por otros autores, de los aspectos teóricos que conforman las bases de la investigación para servir como guía y referencia general en el desarrollo de la misma. 2.1 Antecedentes de la Investigación n el área de la integración de datos, y específicamente en el desarrollo de infraestructuras B existen múltiples trabajos que han contribuido en la conceptualización y avance de este tema. Por ejemplo, Menge (2007) en su trabajo titulado nterprise ervice Bus, presentado en la Free and pen ource onference, da una introducción a dicha arquitectura, presentando primero otras soluciones que han surgido al problema de la integración como la implementación de AI por medio de un Middleware rientado a Mensajes (MM). Luego, describe la Arquitectura rientada a ervicios dejando clara la relación de esta con B, y después explicando y estableciendo que los servicios básicos de integración que B debe proveer son: enrutamiento, invocación, mediación, soporte para transacciones, logging, auditoría, gestión, y servicios de seguridad, además del procesamiento de eventos y orquestación de procesos. Por último, presenta como ejemplo de aplicación de la arquitectura B una plataforma ligera de código abierto llamada Mule, explicando con detenimiento algunos detalles de su implementación. Por consiguiente, este trabajo sirve como base conceptual de lainvestigación. 11
Por su parte, Ahuja y Patel (2011) en su trabajo investigativo titulado nterprise ervice Bus: A Performance valuation, evalúan tres B de código abierto (Mule, ervicemix, W2) comparándolos tanto de forma cualitativa como cuantitativa. Las métricas utilizadas para determinar el desempeño y la eficiencia de cada alternativa fueron: l tiempo de respuesta medio, o en otras palabras, la cantidad de tiempo transcurrida desde el momento en que una solicitud fue enviada hasta el tiempo en que la respuesta fue recibida. esperada para lapetición dada. l rendimiento, medido en número de transacciones por segundo. Una transacción es considerada como satisfactoria si coincide con la respuesta Para obtener estos resultados, usaron una herramienta de código abierto para realizar pruebas de estrés llamada Grinder, realizando múltiples pruebas en distintos escenarios específicos con variando ciertos parámetros en cada una como el número de clientes, o el peso de la solicitud. Luego, para analizar los resultados obtenidos luego de realizar las pruebas, usaron el análisis estadístico de la Prueba t de tudent para validar la hipótesis nula de que los tres B tienen un mismo desempeño. Por esto, el trabajo expuesto por ellos sirve como guía para la correcta evaluación del rendimiento de la herramienta que se desarrollará en este trabajo de investigación, al poner a prueba las distintas características que deben presentar las implementaciones de integración de datos a nivel corporativo basados en arquitectura B. A propósito, arls (2012), en su artículo Is it possible to define A infrastructure?, publicado en el sitio web earcha, presenta un debate completo sobre la verdadera definición de la infraestructura A, con base en los 12