Prototipo Arquitectural para la Interoperabilidad entre Plataformas Empresariales y Plataformas Móviles que Soportan Interacción con Servicios Geográficos

Texto completo

(1)PROTOTIPO ARQUITECTURAL PARA LA INTEROPERABILIDAD ENTRE PLATAFORMAS EMPRESARIALES Y PLATAFORMAS MOVILES QUE SOPORTAN INTERACCION CON SERVICIOS GEOGRAFICOS. SERGIO CAMILO TORRES MOLINA RAUL ANDRES CASTRO. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERIA INGENIERIA DE SISTEMAS BOGOTA D.C. 2015.

(2) PROTOTIPO ARQUITECTURAL PARA LA INTEROPERABILIDAD ENTRE PLATAFORMAS EMPRESARIALES Y PLATAFORMAS MOVILES QUE SOPORTAN INTERACCION CON SERVICIOS GEOGRAFICOS. AUTORES: SERGIO CAMILO TORRES MOLINA: 20032020145 RAUL ANDRES CASTRO: 20032020030. PROYECTO DE GRADO. MODALIDAD DE MONOGRAFIA. DIRECTOR: JULIO BARON VELANDIA Profesor Facultad de Ingeniería. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERIA INGENIERIA DE SISTEMAS BOGOTA D.C. 2015.

(3) INDICE GENERAL CAPÍTULO 1.. PLANTEAMIENTO DEL PROBLEMA ............................................ 8. 1.1. DESCRIPCIÓN DEL PROBLEMA .............................................................. 8. 1.2. FORMULACIÓN DEL PROBLEMA ............................................................ 9. 1.3. JUSTIFICACIÓN DEL PROBLEMA .......................................................... 10. CAPÍTULO 2.. OBJETIVOS Y ALCANCES DEL PROYECTO ............................ 11. 2.1. OBJETIVO GENERAL .............................................................................. 11. 2.2. OBJETIVOS ESPECIFICOS..................................................................... 11. 2.3. ALCANCES .............................................................................................. 12. 2.4. LIMITACIONES ........................................................................................ 12. 2.5. RESULTADOS ESPERADOS .................................................................. 12. CAPÍTULO 3.. MARCO REFERENCIAL ............................................................. 14. 3.1. MARCO CONCEPTUAL ........................................................................... 14. 3.2. MARCO TEORICO ................................................................................... 23. CAPÍTULO 4.. MARCO METODOLOGICO ......................................................... 41. 4.1. METODOLOGÍA ....................................................................................... 41. 4.2. DISEÑO DE LA PROPUESTA DE INVESTIGACION ............................... 41. 4.3. PROCESO DE DESARROLLO DEL PROYECTO ................................... 43. CAPÍTULO 5.. MARCO TEMÁTICO .................................................................... 48. 5.1. GESTIÓN DEL PROYECTO BAJO EL MODELO OPENUP .................... 48. 5.2. CARONTE ................................................................................................ 78. CAPÍTULO 6.. RESULTADOS .......................................................................... 101. CAPÍTULO 7.. BIBLIOGRAFIA .......................................................................... 104. CAPÍTULO 8.. ANEXOS .................................................................................... 106. 8.1. EVALUACION DEL PROYECTO: ANALISIS COSTO / BENEFICIO ...... 106 8.2. PLAN DE RIESGOS O RISKLIST .......................................................... 110 8.3. ESPECIFICACIÓN DE CASOS DE PRUEBA ........................................ 111.

(4) INDICE DE TABLAS TABLA 1. ESTILOS ARQUITECTÓNICOS ............................................................ 17 TABLA 2. PLANTEAMIENTO DEL PROBLEMA.................................................... 49 TABLA 3. CARACTERIZACIÓN DEL PRODUCTO ............................................... 49 TABLA 4. COMPENDIO DE INVOLUCRADOS DE INTERÉS .............................. 50 TABLA 5. NECESIDADES Y CARACTERÍSTICAS ............................................... 51 TABLA 6. OTROS REQUERIMIENTOS ................................................................ 53 TABLA 7. HITOS Y OBJETIVOS ........................................................................... 55 TABLA 8. HITOS FASE DE INICIO ....................................................................... 57 TABLA 9. HITOS FASE DE ELABORACIÓN ........................................................ 58 TABLA 10. HITOS FASE DE CONSTRUCCIÓN ................................................... 58 TABLA 11. HITOS FASE DE PRUEBAS ............................................................... 59 TABLA 12. LISTADO MAESTRO DE REQUERIMIENTOS ................................... 60 TABLA 13. CASO DE USO INGRESAR A LA APLICACIÓN ................................. 68 TABLA 14. CASO DE USO CREAR USUARIOS................................................... 70 TABLA 15. CASO DE USO MODIFICAR USUARIOS ........................................... 71 TABLA 16. CASO DE USO CONSULTAR USUARIOS ......................................... 72 TABLA 17. CASO DE USO CREAR ASEGURADORAS ....................................... 72 TABLA 18. CASO DE USO MODIFICAR ASEGURADORAS................................ 73 TABLA 19. CASO DE USO CONSULTAR ASEGURADORAS.............................. 73 TABLA 20. CASO DE USO REGISTRAR ACCIDENTE ........................................ 74 TABLA 21. CASO DE USO CONSULTAR ACCIDENTE ....................................... 75 TABLA 22. CASO DE USO VER DETALLE ACCIDENTE ..................................... 76 TABLA 23. CASO DE USO IDENTIFICAR ACCIDENTE ....................................... 77 TABLA 24. CASO DE USO OBTENER UBICACIÓN............................................. 77 TABLA 25. FACTORES DE SELECCIÓN SERVIDOR DE APLICACIONES......... 78 TABLA 26. FACTORES DE SELECCIÓN LENGUAJE DE PROGRAMACIÓN ..... 79 TABLA 27. FACTORES DE SELECCIÓN PLATAFORMA MÓVIL ........................ 80 TABLA 28. FACTORES DE SELECCIÓN APIS GEOGRÁFICAS ......................... 80 TABLA 29. FACTORES DE SELECCIÓN SERVIDORES DE APLICACIÓN ........ 81 TABLA 30. PATRONES CAPA DE PRESENTACIÓN ........................................... 83 TABLA 31. PATRONES CAPA DE NEGOCIO ...................................................... 83 TABLA 32. PATRONES CAPA DE INTEGRACIÓN .............................................. 84 TABLA 33. CUADRO DESCRIPTIVO IMPLEMENTACIÓN DAO .......................... 89 TABLA 34. CUADRO DESCRIPTIVO IMPLEMENTACIÓN ENTITY ..................... 90 TABLA 35. CUADRO DESCRIPTIVO IMPLEMENTACIÓN EXCEPTION ............. 90 TABLA 36. CUADRO DESCRIPTIVO IMPLEMENTACIÓN RESOURCEMAN...... 91 TABLA 37. CUADRO DESCRIPTIVO IMPLEMENTACIÓN SERVICES................ 92 TABLA 38. CUADRO DESCRIPTIVO IMPLEMENTACIÓN CHECKEDEXCEP .... 93 TABLA 39. CUADRO DESCRIPTIVO IMPLEMENTACIÓN DTO .......................... 94 TABLA 40. CUADRO DESCRIPTIVO HELPER..................................................... 94 TABLA 41. CUADRO DESCRIPTIVO SESSION FACADE ................................... 96.

(5) TABLA 42. CUADRO DESCRIPTIVO UTILS ......................................................... 96 TABLA 43. CUADRO DESCRIPTIVO IMPLEMENTACIÓN MANAGEDBEANS ... 97 TABLA 44.CUADRO DESCRIPTIVO IMPLEMENTACIÓN SECURITYUTILS....... 98 TABLA 45. CUADRO DESCRIPTIVO IMPLEMENTACIÓN WEB SERVICES ...... 99 TABLA 46. CUADRO DESCRIPTIVO IMPLEMENTACIÓN OTROS. .................... 99 TABLA 47. RELACIÓN COSTO BENEFICIO. ..................................................... 108 TABLA 48. LISTADO DE PLAN DE RIESGOS .................................................... 110 TABLA 49. ESPECIFICACIÓN PRUEBAS CU001 .............................................. 111 TABLA 50. ESPECIFICACIÓN PRUEBAS FE 1 CU002...................................... 112 TABLA 51. ESPECIFICACIÓN PRUEBAS FE 2 CU001...................................... 112 TABLA 52. ESPECIFICACIÓN PRUEBAS CU002 .............................................. 114 TABLA 53. ESPECIFICACIÓN PRUEBAS FE 1 CU002...................................... 115 TABLA 54. ESPECIFICACIÓN PRUEBAS FE 2 CU002...................................... 116 TABLA 55. ESPECIFICACIÓN PRUEBAS FE 3 CU002...................................... 117 TABLA 56. ESPECIFICACIÓN PRUEBAS FE 4 CU002...................................... 118 TABLA 57. ESPECIFICACIÓN PRUEBAS CU004 .............................................. 118 TABLA 58. ESPECIFICACIÓN PRUEBAS CU005 .............................................. 120 TABLA 59. ESPECIFICACIÓN PRUEBAS CU006 .............................................. 121 TABLA 60. ESPECIFICACIÓN PRUEBAS CU007 .............................................. 122 TABLA 61. ESPECIFICACIÓN PRUEBAS CU008 .............................................. 122 TABLA 62. ESPECIFICACIÓN PRUEBAS CU009 .............................................. 124 TABLA 63. ESPECIFICACIÓN PRUEBAS CU010 .............................................. 125 TABLA 64. ESPECIFICACIÓN PRUEBAS CU011 .............................................. 126 TABLA 65. ESPECIFICACIÓN PRUEBAS CU012 .............................................. 127.

(6) INDICE DE FIGURAS FIGURA 1. MODELO DE ARQUITECTURA .......................................................... 14 FIGURA 2. ESQUEMA DE CALIDAD DE SOFTWARE ......................................... 20 FIGURA 3. COMPONENTES DE LA CAPA CLIENTE .......................................... 24 FIGURA 4. CAPA WEB ......................................................................................... 25 FIGURA 5. LÓGICA DE EJECUCIÓN ENTRE LAS CAPAS ................................. 26 FIGURA 6. COMPONENTES HIBERNATE ........................................................... 30 FIGURA 7. COMPARATIVO DE LOS TIPOS DE SERVICIOS .............................. 35 FIGURA 8. CICLO DE VIDA DE UNA ACTIVIDAD................................................ 36 FIGURA 9. COMPONENTES GENERALES DEL SISTEMA ................................. 40 FIGURA 10. CICLO DE VIDA DE UNA ITERACIÓN ............................................. 45 FIGURA 11. RELACIONES EN EL CICLO DE VIDA DE UN PROYECTO. ........... 46 FIGURA 12. MODELO ARQUITECTURAL (VISTA LÓGICA)................................ 67 FIGURA 13. DIAGRAMA DE CASOS DE USO ..................................................... 68 FIGURA 14. PATRONES JEE ............................................................................... 83 FIGURA 15. COMPONENTE GEOGRÁFICO........................................................ 85 FIGURA 16. SISTEMAS Y RECURSOS INVOLUCRADOS .................................. 85 FIGURA 17. REPRESENTACION NIVELES DE ARQUITECTURA ANDROID..... 86 FIGURA 18. ARQUITECTURA ESPECIFICA DEL SISTEMA ............................... 87 FIGURA 19. IMPLEMENTACIÓN DAO ................................................................. 88 FIGURA 20. IMPLEMENTACIÓN ENTITY ............................................................ 89 FIGURA 21. IMPLEMENTACIÓN EXCEPTION..................................................... 90 FIGURA 22. IMPLEMENTACIÓN RESOURCEMANAGER ................................... 91 FIGURA 23. IMPLEMENTACIÓN SERVICES ....................................................... 92 FIGURA 24. IMPLEMENTACIÓN CHECKEDEXCEPTION ................................... 93 FIGURA 25. IMPLEMENTACIÓN DTO.................................................................. 93 FIGURA 26. IMPLEMENTACIÓN HELPER ........................................................... 94 FIGURA 27. IMPLEMENTACIÓN SESSION FACADE .......................................... 95 FIGURA 28. IMPLEMENTACIÓN UTILS ............................................................... 96 FIGURA 29. IMPLEMENTACIÓN MANAGEDBEANS ........................................... 97 FIGURA 30. IMPLEMENTACIÓN SECURITYUTILS ............................................. 98 FIGURA 31. IMPLEMENTACIÓN WEB SERVICES .............................................. 98 FIGURA 32. MODELO DE DATOS........................................................................ 99 FIGURA 33. LÍNEA BASE ................................................................................... 107 FIGURA 34. ARQUITECTURA OBJETIVO. ........................................................ 107.

(7) CONSIDERACIONES DE DOCUMENTACIÓN Este documento tiene en cuenta la Norma Técnica Colombiana NTC 1486 para la presentación de tesis, trabajos de grado y otros trabajos de investigación y la Norma Técnica Colombiana NTC 5613 de referencias bibliográficas, contenido forma y estructura..

(8) AGRADECIMIENTOS El más cordial agradecimiento a nuestro director de proyecto de grado Julio Barón Velandia cuyos lineamientos y conocimientos ayudaron a encauzar el camino para la materialización de esta iniciativa. A nuestro jurado Alberto Acosta por permitirnos retribuir al menos un poco el conocimiento obtenido y demostrar lo que la universidad ha forjado. Queremos resaltar los valiosos aportes de Cristian David Palomino, analista de pruebas (Certified tester ISTQB foundation level) quien nos guió en el aseguramiento de calidad de la documentación y la implementación realizada. Por ultimo a nuestras familias quienes nos han brindado la fuerza y el apoyo para recorrer este camino lleno de retos y desafíos pero al final lleno del sentimiento de satisfacción y realización tanto personal como profesional..

(9) CAPÍTULO 1.. PLANTEAMIENTO DEL PROBLEMA. 1.1 DESCRIPCIÓN DEL PROBLEMA Producto de la revolución tecnológica de las últimas décadas están emergiendo una gran cantidad de sistemas de información que por lo general están construidos sobre diferentes plataformas y lenguajes de programación, sin embargo la disponibilidad, validez e integridad de la información son necesidades que se tienen que seguir cumpliendo principalmente en soluciones que se implementan para entornos empresariales, un ejemplo son los ERP (por sus siglas en inglés, enterprise resource planning o planificación de recursos empresariales en español) los cuales se alimentan de varias fuentes de información y cuentan con una gran cantidad de reglas de negocio las cuales obedecen a intereses de múltiples áreas de la organización (comercial, administrativa, gerencial u operativa), revisando el tema a gran escala para la integración de estas plataformas existen buses empresariales los cuales interpretan y traducen el paso de mensajes entre las mismas, sin embargo si una organización contemplara la iniciativa de intentar descentralizar sus funcionalidades trasladándolas a un entorno móvil encontraría una barrera al querer cumplir ese deseo debido a la baja disponibilidad de recursos que tiene en este ambiente, esto sin mencionar que las oportunidades de mejora al operar con este tipo de aplicaciones se deben reflejar en un soporte del negocio más versátil y transversal que permita a la vez un manejo complejo y robusto de la capa de lógica de negocio con el fin de responder y adaptarse a las variaciones del entorno con implementaciones cada vez más portables y que integren el uso de herramientas geográficas. Es así como la arquitectura de software surge como pilar fundamental en el propósito de lograr la descentralización de estos sistemas situándose como una de las principales necesidades de la industria del Software a nivel mundial, sin embargo en la fase de análisis y diseño arquitectural pueden existir diferentes enfoques para un mismo escenario de solución, cada uno planteando su propio conjunto de patrones, componentes, herramientas, buenas prácticas, ventajas y desventajas por lo que en ultimas el verdadero resultado que debe obtenerse de la fase de análisis es la correcta elección de ese conjunto de elementos para lograr la implementación más adecuada conforme al requerimiento que se está abordando En el documento “Introducción a la Arquitectura de Software” de David Garlan y Mary Shaw se argumenta la relevancia de la Arquitectura de Software en el aumento del tamaño y la complejidad de los sistemas de software, los autores plantean que la fase del diseño tiene que ir más allá de los algoritmos y estructuras de datos en un proceso de computación y concentrarse más en el. 8.

(10) diseño y especificación de la estructura general del sistema, no obstante para lograr que esta interacción sea fluida y transparente en los componentes que constituyen el sistema hay que lograr un nivel apropiado de abstracción de las funcionalidades con el fin de acceder de modo estandarizado a la lógica que se encuentra encapsulada en estas, una vez establecido ese modelo se definen las interfaces por la cuales se constituyen los contratos en el que los componentes se comunicarán y compartirán la información; Es en este punto donde se plantea el escenario de análisis para definir cuáles son los parámetros, las interacciones y los componentes que conformarán el sistema para lograr un ambiente colaborativo funcional, sin embargo uno de los principales inconvenientes de los dispositivos móviles como tabletas o teléfonos inteligentes radica en sus limitadas capacidades en cuanto a recursos como almacenamiento, memoria y demás aspectos técnicos en comparación con equipos de cómputo tradicionales. Adicionalmente se debe tener presente que la efectividad de una solución de este estilo se encuentra directamente relacionada a la interacción entre los diferentes componentes que la conforman con el usuario y con otros sistemas, variables como el tiempo de respuesta, la calidad del formato y la cantidad de información son métricas que definen en última instancia el nivel de aceptación final, en el propósito de hacer que esta interacción sea factible hoy en día han surgido herramientas informáticas como lenguajes de programación multiplataforma y metodologías arquitecturales que permiten establecer la sinergia de múltiples sistemas implementados en diferentes tecnologías. 1.2 FORMULACIÓN DEL PROBLEMA Dado un conjunto de funcionalidades de negocio que soportan una interacción con servicios geográficos ¿qué componentes, patrones y herramientas se requieren para la confiabilidad, escalabilidad, portabilidad y disponibilidad de la lógica de negocio y de la información que se encuentra centralizada ambientes empresariales robustos para ser aplicada en dispositivos móviles?. 9.

(11) 1.3 JUSTIFICACIÓN DEL PROBLEMA Entre los avances de mayor desarrollo y popularización en la actualidad se encuentra la Internet móvil la cual ha permitido compartir información en tiempo real de una forma más eficiente gracias al uso de dispositivos móviles, conforme a la experiencia obtenida en el desarrollo de actividades laborales en entornos empresariales se percibe la oportunidad de extender estos avances a escenarios de negocio de mayor complejidad; Realizando indagaciones preliminares se encuentra que la mayoría de organizaciones encuentran una barrera tecnológica en el deseo de descentralizar la información de sus compañías principalmente por la gran cantidad de personalizaciones hechas a las herramientas, a una lógica de negocio muy compleja y a las diferentes plataformas tecnológicas sobre las que esta se apoya. En un primer acercamiento al escenario solución se contempla una gran oportunidad en el desarrollo de este proyecto al adelantar el análisis y aplicación de patrones de diseño en la implementación de la API (en inglés Application Programming Interfaceo interfaz de programación de aplicaciones en español) de dispositivos móviles la cual es de reciente aparición y que en revisiones a la documentación entregada por el fabricante presenta una gran versatilidad, por otro lado el uso de software libre permite la utilización y explotación de funcionalidades y componentes expuestos por herramientas propietarias con un costo muy bajo (casi nulo) optimizando la relación costo/beneficio de este tipo de implementaciones. El propósito del presente proyecto es proponer el diseño y establecer las características de arquitectura para la implementación de una aplicación móvil que integre escenarios de negocio robustos e información geográfica para plataformas móviles brindando una aproximación al fundamento teórico y práctico que un desarrollo de esta naturaleza pueda poseer para su puesta en escena avalando su mantenibilidad y adaptabilidad a lo largo del tiempo. Por ultimo emplear este diseño en el desarrollo de un prototipo orientado a respaldar y alentar la escasa oferta de soluciones con enfoque empresarial que existe en el mercado hoy en día, buscando maximizar el aprovechamiento de estas tecnologías que en la actualidad se encuentran en proceso de popularización y avance Como aporte a la innovación hay un impacto positivo en este proyecto debido a que se plantean las bases, directrices y lineamientos para la implementación de soluciones móviles que integren escenarios empresariales complejos, dándoles el rigor académico necesario de cualquier disciplina y brindándole un enfoque dirigido a la incorporación de patrones que apliquen en el proceso de integración de las diferentes tecnologías y a las buenas prácticas que propone la industria para su posterior discusión y mejora.. 10.

(12) CAPÍTULO 2.. OBJETIVOS Y ALCANCES DEL PROYECTO. 2.1 OBJETIVO GENERAL Diseñar y desarrollar una arquitectura que permita una integración robusta entre el entorno empresarial con plataformas móviles utilizando herramientas geográficas interactuando en una arquitectura orientada a servicios. 2.2. OBJETIVOS ESPECIFICOS. 2.2.1 Establecer los criterios de diseño arquitecturales para cada uno de los componentes que garanticen una alta cohesión entre los mismos para obtener artefactos ampliamente escalables y que describa las siguientes características:  Soporte multiplataforma de los componentes de software generados.  Utilización de estándares y estrategias de diseño para su mantenibilidad y escalar el modelo de negocio exponiendo de manera segura los elementos del mismo.  Acceso a componentes complejos modulares a través de interfaces ligeras. 2.2.2 Analizar la viabilidad arquitectural mediante la elaboración de unas matrices donde se compare las cualidades, funciones, ventajas y desventajas para el desarrollo de aplicaciones en dispositivos móviles que proporcione integración con entornos robustos, agilidad en el desarrollo, funcionalidad, mantenimiento, seguridad en la información y velocidad en la ejecución teniendo presente el costo total de propiedad Vs. estimación de beneficios de esa implementación desde un enfoque metodológico y tecnológico de las diferentes plataformas indagadas logrando un balance entre calidad y esfuerzo. 2.2.3 Diseñar la arquitectura de una aplicación móvil que establezca una conexión liviana con aplicaciones empresariales. 2.2.4 Realizar autenticación sobre una BD, consulta y actualización datos y cargar información basada en un sistema espacial georeferenciado. 2.2.5 Desarrollar la aplicación prototipo bajo un sistema operativo para móviles el cual será elegido conforme a los resultados del análisis de factibilidad, aplicando la arquitectura diseñada como evidencia de la viabilidad de lo planteado.. 11.

(13) 2.3 ALCANCES Con el desarrollo del presente proyecto se busca la realización de los siguientes hitos como consolidación y aplicación de lo propuesto: 2.3.1 La definición de arquitectura debe permitir a la aplicación móvil el uso de un módulo de mapas que permita hacer uso de las herramientas geográficas dentro del dispositivo móvil y de servicios como la captura de imágenes a través de la cámara del mismo. 2.3.2 Se contempla el desarrollo de un cliente web por lo que se debe suministrar tanto para este como para la aplicación móvil estándares mínimos de seguridad para el ingreso mediante un componente centralizado. 2.3.3 Utilización de XML por su flexibilidad para que la arquitectura tenga la capacidad de interoperar con otras tecnologías lo que garantizará que los métodos de negocio puedan ser utilizados tanto desde el cliente web como desde el aplicativo móvil. 2.3.4 Garantizar la integridad dela información que se trasmite y se recibe en el dispositivo móvil debido a que la aplicación debe transferir archivos binarios. 2.4 LIMITACIONES Las características que se listan a continuación se establecen como cotas para el proyecto. 2.4.1 En el ideal de soportar el proyecto en tecnologías libres y de bajo costo se contempla el desarrollo de la línea base del aplicativo móvil con una capacidad funcional inicial, cualquier oportunidad de mejora se evidenciará por escrito sin que esto afecte el proceso de la implementación. 2.4.2 Se considera a ARCGIS como el proveedor de servicio de mapas más viable para la implementación en este proyecto por la experiencia, la robustez de la plataforma y calidad de la información, conforme a esto los demás requerimientos y tecnologías que se diseñen y levanten deberán ir alineados a las especificaciones técnicas que se soporten en tal plataforma. 2.5 RESULTADOS ESPERADOS Se consideran los siguientes entregables como los demostrables deseables que resultarán de la ejecución del proyecto: 2.5.1 Documentación soportando el Diseño arquitectural representando la interoperabilidad entre los componentes.. 12. del. prototipo.

(14) 2.5.2 Documentación con aplicación de la metodología OpenUP para el desarrollo y gestión del proyecto 2.5.3 Aplicativo Web con funcionalidades iniciales básicas evidencia de la aplicación del diseño. 2.5.4 Aplicativo Móvil Interoperando con escenario empresarial robusto. 2.5.5 Servidor de aplicaciones con implementaciones de negocio robustas interoperando con el dispositivo móvil.. 13.

(15) CAPÍTULO 3.. MARCO REFERENCIAL. 3.1 MARCO CONCEPTUAL 3.1.1 Arquitectura de software y su relevancia. Siendo el software una estructura compleja debe ser construida desde una base conceptual sólida, no considerar escenarios clave como problemas comunes, mantenibilidad o permanencia a largo plazo puede poner cualquier intento de implementación en riesgo. Herramientas y entornos de desarrollo simplifican la creación de aplicaciones pero no reemplazan la necesidad de diseñar la aplicación teniendo en cuenta diferentes escenarios y requerimientos específicos. Los riesgos implícitos en una mala arquitectura incluyen: software inestable, pobre desempeño en un entorno de producción, difícil adopción o implementación y que no es capaz de soportar los requerimientos de negocio existentes o futuros. Los sistemas deben ser diseñados en consideración con el usuario, el sistema (la infraestructura de Tecnologías de la Información) y los objetivos de negocio. Para cada una de estas áreas se deben esbozar escenarios clave identificando atributos de calidad importantes (por ejemplo la fiabilidad o la escalabilidad) y áreas clave de la satisfacción y la insatisfacción del usuario y en lo posible se debe desarrollar y considerar las métricas que miden el éxito encada una de estas áreas, a continuación se representa en una figura la interacción de estas áreas en la conformación de un modelo de arquitectura. Figura 1. Modelo de Arquitectura. Fuente los autores. El equilibrio y armonía entre los requisitos de estas tres áreas es esencial, por ejemplo la experiencia general del usuario de la solución es a menudo una suma de las necesidades de negocio con la infraestructura que la soporta, sin embargo 14.

(16) los cambios en uno o el otro puede afectar significativamente el resultado de esta experiencia, del mismo modo cambios en los requisitos de frente a la experiencia de usuario pueden tener un impacto significativo en los requerimientos de negocios e infraestructura en entornos donde el rendimiento podría ser un objetivo importante para el usuario, pero el dueño del sistema puede no ser capaz de invertir recursos en el hardware requerido para cumplir con esa meta el 100 por ciento de las veces o el hardware cuenta con recursos limitados como es el caso de los dispositivos móviles. Es por eso que la arquitectura de software se centra en cómo los principales elementos y componentes dentro de una aplicación son utilizados o interactúan con otros elementos y componentes más importantes dentro de la aplicación, la selección de las estructuras de datos y algoritmos o los detalles de la implementación de los componentes individuales son los temas de análisis y diseño. La arquitectura y el diseño son preocupaciones que muy a menudo se superponen, en lugar de utilizar reglas específicas y rápidas para distinguir entre la arquitectura y el diseño hay un mayor sentido colaborativo cuando se combinan estas dos áreas. En algunos casos las decisiones son claramente más arquitectónicas de frente al entorno, pero en otros casos las decisiones pesan más sobre el diseño. 3.1.2 La arquitectura actual de las aplicaciones móviles. Con el paso de los años el diseño de aplicativos móviles parece cada vez más sencillo sin embargo la potencia de cálculo disponible en estos dispositivos se encuentra aún por detrás de sus homólogos de escritorio o servidores y en el corto o mediano plazo no se vislumbra un cambio significativo en ese sentido, Incluso los dispositivos más recientes todavía cuentan con sólo alrededor de un tercio o en el mejor de los casos la mitad de los recursos de computación (Memoria) de una computadora de escritorio de gama baja, adicionalmente la calidad de las conexiones de datos disponibles en un dispositivo móvil suele ser muy variables en base a la fuerza de la señal o localización la que es muy inferior a la banda ancha de acceso a Internet. A menudo durante el desarrollo ágil de aplicaciones estas consideraciones de rendimiento se ignoran hasta el final del proyecto y optimizados sólo cuando es necesario. En el desarrollo de aplicaciones móviles se debe tener más consideración en las limitaciones de rendimiento del dispositivo por lo que hay que dársele prioridad en la fase de diseño. Cada plataforma tiene diferentes “mejores prácticas” a nivel de código para la optimización del rendimiento en función del lenguaje de programación y los marcos disponibles en la plataforma, algunas buenas prácticas sin embargo temas como el uso correcto de la memoria y los límites al número de objetos creados innecesarios se pueden aplicar a todas las plataformas. En la fase de diseño se debe dar a las decisiones arquitectónicas mayor relevancia 15.

(17) especialmente a aquellas que pueden limitar el rendimiento y que también sean difíciles de cambiar posteriores al ciclo de desarrollo tales como el diseño de las interfaces de programación de servicios web y formatos de datos. Estas consideraciones se derivan principalmente del limitado ancho de banda disponible para los dispositivos móviles. Si es posible las API (Application Programming Interface por sus siglas en inglés o Interfaz de programación de aplicaciones en español) utilizadas por una aplicación móvil deben ser diseñados para recuperar sólo la información más relevante y útil excluyendo cualquier dato adicional que no sea utilizado por la aplicación. En el diseño de las API para comunicarse con las aplicaciones móviles existen varias recomendaciones como utilizar un formato de datos ligero como JSON en lugar de formato más detallado como XML con el fin de hacer el mejor uso del ancho de banda limitado disponible para dispositivos móviles. Entre algunas ventajas en el uso de un formato ligero como JSON se tienen:  Conservar el ancho de banda.  Permitir que los resultados que se obtengan más rápidamente.  Ágil deserialización de los datos a medida que llega al cliente. Otras consideraciones importantes respecto al rendimiento en un dispositivo móvil es la vida de la batería, por eso si se debe desarrollar una aplicación que este en constante sondeo de un servicio web para actualizaciones o procesamiento de datos en segundo plano continuamente, la batería se agotará más rápidamente. Si arquitectónicamente viable (y si existen las capacidades de notificación de inserción en la plataforma móvil), se recomienda el uso de notificaciones push para proporcionar actualizaciones de datos a través de votación periódica. Actualmente existen capacidades de notificación push en los teléfonos con plataformas iPhone, Android, y Windows 7. Por ultimo siendo la idea de la aplicación llevar a cabo una gran cantidad de procesamiento o análisis de datos estos deberán ser subidos a la plataforma del servidor de aplicaciones empresarial para que se realice allí el procesamiento intensivo de la CPU y luego devolver los resultados al dispositivo para evitar que se descargue la batería y proporcionar una experiencia más ágil al usuario. 3.1.3 Componentes, conectores y relaciones. En la investigación de arquitectura de software hay conceptos clave como los componentes y conectores, con el paso del tiempo la tecnología ha madurado a un nivel donde la adopción de la industria es muy extendida sin embargo se evidencian algunos principios fundamentales que aún permanecen, el punto de vista tradicional de la arquitectura de software adolece de una serie de problemas clave que no puede ser resuelto sin necesidad de cambiarla perspectiva sobre el mismo concepto de arquitectura de software. Estos problemas incluyen la falta de alta calidad en las decisiones y representaciones de diseño, el hecho de que estas decisiones de. 16.

(18) diseño son transversales y se entrelazan, que estos problemas conducen a altos costos de mantenimiento, debido a que las reglas de diseño y limitaciones son fácilmente violados y las decisiones de diseño obsoletos no se eliminan, la principal consideración en este punto es que las decisiones de diseño deben permitir la posibilidad de añadir, quitar y cambiar los componentes del diseño arquitectónico con un menor esfuerzo en cualquier momento. 3.1.4 Estilos o Patrones Arquitectónicos. Un estilo arquitectónico a veces llamado patrón arquitectónico es un conjunto de principios-patrón que proporcionan un marco abstracto para una familia de sistemas. Un estilo arquitectónico mejora la clasificación y promueve la reutilización del diseño proporcionando soluciones a problemas recurrentes con frecuencia. Garlan y Shaw definen un estilo arquitectónico como: “un tipo de familia de sistemas en términos de un modelo de organización estructural. Específicamente un estilo arquitectónico determina el vocabulario de los componentes y conectores que se pueden utilizar en ese estilo, con un conjunto de restricciones sobre cómo se pueden combinar”. El beneficio más importante es que proporciona un lenguaje común con oportunidades para realizar diferentes tipos de análisis independientes de la tecnología que se hable, esto facilita un mayor nivel de entendimiento lo que también incluye patrones y principios, los estilos arquitectónicos se pueden organizar por su área clave de enfoque. La siguiente tabla muestra las principales áreas de interés y los correspondientes estilos arquitectónicos. Tabla 1. Estilos arquitectónicos. Categoría. Estilo Arquitectural Arquitectura Orientada Servicios (SOA). Se refiere a las aplicaciones que exponen y consumen funcionalidad a como un servicio a través de contratos y mensajes. Un estilo de arquitectura que prescribe el uso de un sistema de software que puede recibir y enviar mensajes a través de uno o más canales de comunicación, por lo que las aplicaciones puedan interactuar sin necesidad de conocer los detalles específicos sobre la otra.. Comunicación Bus de mensajes. Despliegue. Descripción. Segrega el sistema en dos aplicaciones, donde el cliente hace. Cliente / Servidor. 17.

(19) Categoría. Estilo Arquitectural. Descripción peticiones al servidor. En muchos casos, el servidor es una base de datos con la lógica de la aplicación representada como procedimientos almacenados. Segrega funcionalidad en segmentos separados de la misma manera que el estilo en capas, pero con cada segmento siendo un nivel situado en un equipo separado físicamente.. N-capas tres capas. Dominio. Un estilo arquitectónico orientado a objetos centra en el modelado de Diseño Guiado por el un dominio del negocio y la dominio definición de los objetos de negocio basado en las entidades del dominio del negocio.. Basado Componentes,. Se descompone el diseño de aplicaciones en componentes en funcionales o lógicos reutilizables que exponen bien definidas las interfaces de comunicación.. Orientada a objetos. Un paradigma de diseño basado en la división de responsabilidades para una aplicación o sistema en objetos reutilizables y autosuficientes individuales, cada uno con los datos y el comportamiento relevantes para el objeto.. Arquitectura niveles. Particiones de las preocupaciones de la aplicación en grupos apilados (capas).. Estructura. por. Fuente los autores. 3.1.5 Patrones de Diseño. Los patrones de diseño son los patrones de mediana escala. Son de menor escala que los patrones arquitectónicos, pero están en un. 18.

(20) nivel más alto que los modismos específicos del lenguaje de programación. La aplicación de un patrón de diseño no tiene efecto en la estructura fundamental de un sistema de software, pero puede tener una fuerte influencia en la arquitectura de un subsistema. Agrupaciones relevantes de Patrones de Diseño:  Descomposición Estructural: Esta categoría incluye patrones que apoyan una descomposición adecuada de los subsistemas y componentes complejos en partes cooperantes. El patrón de todo-parte es el patrón más general de que somos conscientes de esta categoría. Cuenta con una amplia aplicabilidad para la estructuración de componentes complejos.  Organización de las actividades: Esta categoría comprende los patrones que definen cómo los componentes colaboran juntos para resolver un problema complejo. Aquí se resalta el patrón maestro-esclavo, lo que le ayuda a organizar el cálculo de los servicios para los cuales se requiere tolerancia a fallos o precisión de cálculo. También es compatible con la división de servicios en partes independientes y su ejecución en paralelo.  Control de acceso: Estos patrones custodian y controlan el acceso a los servicios o componentes. Aquí se encuentra el patrón Proxy que permite a los clientes la comunicación con el representante de un componente en lugar de con el componente en sí.  Gestión: Esta categoría grupa los patrones que organizan y dan las pautas para el manejo de las colecciones homogéneas de objetos, servicios y componentes en su totalidad. Se destacan dos patrones: el patrón Command Processor que aborda la gestión y programación de los comandos del usuario y el patrón View Handler que describe cómo administrar vistas en un sistema de software.  Comunicación: Los patrones de esta categoría ayudan a organizar la comunicación entre los componentes. Aquí está como ejemplo el patrón publicador-suscriptor el cual ayuda con la tarea de mantener datos consistentes entre los componentes cooperantes. La mayoría de los patrones de diseño son independientes de un paradigma de programación en particular. Por lo general, pueden ser implementados fácilmente en una manera a objetos, pero todos nuestros patrones de diseño son suficientes para adaptarse a las prácticas de programación más tradicionales, en general como un estilo de procedimiento. 3.1.6 Calidad de Software. Según Pressman la calidad de software es “la concordancia con los requisitos funcionales y de rendimiento establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado de forma profesional”.. 19.

(21) Una clasificación de atributos de calidad se muestra en la siguiente figura y está basada en el estándar internacional ISO 9126 para la evaluación de la calidad del software. Figura 2. Esquema de Calidad de Software. Fuente: los autores. 3.1.6.1 Eficiencia: Conjunto de atributos que se correlacionan entre el nivel de desempeño del software y la cantidad de recursos necesitados bajo condiciones establecidas  Desempeño: Grado en el cual un sistema o componente cumple sus funciones dentro de restricciones dadas tales como velocidad, exactitud, o uso de memoria. Ejecutar las funciones del sistema lo suficientemente rápido para satisfacer las expectativas del usuario  Disponibilidad: Asegurar que el servicio este “siempre” disponible. Procurar porque el servicio sea altamente accesible.  Disponibilidad = tiempo disponible / tiempo posible.  Escalabilidad: Capacidad para sostener la calidad del servicio a medida que aumenta la carga: o Escalabilidad Vertical: Adicionar capacidad de Memoria y CPU a los equipos existentes. o Escalabilidad Horizontal: Adicionar el número de servidores La Escalabilidad está muy ligada al desempeño y a la definición de la plataforma tecnológica. La escalabilidad surge como una solución para resolver los problemas de desempeño presentados en una aplicación. 3.1.6.2 Fiabilidad (Confiabilidad): Una vez el software se encuentra funcionando, según se especificó, la confiabilidad define la capacidad de un sistema de mantener su nivel de servicio bajo condiciones definidas por periodos 20.

(22) específicos de tiempo. Se fijan las tasas de falla para que el sistema sea aceptable.  Madurez: Atributos del software que se relacionan con la frecuencia de falla por fallas en el software.  Recuperabilidad: Atributos del software que se relacionan con la capacidad para restablecer su nivel de desempeño y recuperar los datos directamente afectos en caso de falla y en el tiempo y esfuerzo relacionado para ello.  Tolerancia a fallos: Atributos del software que se relacionan con su habilidad para mantener un nivel especificado de desempeño en casos de fallas de software o de una infracción a su interfaz especificada.  Cumplimiento de Fiabilidad: La capacidad del producto software para adherirse a normas, convenciones o legislación relacionadas con la fiabilidad. 3.1.6.3 Usabilidad (Facilidad de Uso): Habilidad de software para que el usuario invierta el mínimo esfuerzo en usar el sistema.  Facilidad de Aprendizaje: Mide la velocidad a la cual los usuarios nuevos se convierten en expertos utilizando el sistema.  Tiempo de un usuario típico en aprender la manera en cómo se usan los comandos relevantes a un conjunto de tareas: Se refiere a que tan rápido el usuario va a aprender a usar un sistema con el cual no había tenido contacto previamente. Este punto se refiere a la consecución de tareas básicas por parte de un usuario novato.  Tasas de error por parte de los usuarios: Este atributo se refiere a aquellos errores que comete el usuario al utilizar el sistema. Una aplicación ideal evitaría que el usuario cometiera errores y funcionaría de manera óptima a cualquier petición por parte del usuario. En la práctica esto difícilmente se logra. Es vital que una vez que se produzca un error el sistema se lo haga saber rápida y claramente al usuario, le advierta sobre la severidad del mismo y le provea de algún mecanismo para recuperarse de ese error.  Eficiencia: Mide el nivel de soporte que un sistema le provee al usuario para que termine con éxito sus tareas. Velocidad de desempeño, una vez que el usuario ha aprendido a utilizar el sistema, se va a ponderar el lograr la velocidad con que puede completar una tarea específica.  Memoria: Cuando un usuario ha utilizado un sistema tiempo atrás, y tiene la necesidad de utilizarlo de nuevo la curva de aprendizaje debe de ser significativamente menor que el caso del usuario que nunca haya utilizado dicho sistema. Esto es de primordial importancia para aplicaciones usadas intermitentemente.  Satisfacción subjetiva: Este atributo se refiere a la impresión subjetiva del usuario respecto al sistema. 3.1.6.4 Facilidad de mantenimiento (Mantenibilidad): La habilidad para identificar y corregir un defecto dentro de un componente de software.. 21.

(23)  Analizabilidad: Facilidad para diagnosticar en el sistema deficiencias o bugs o identificar partes que deben ser modificados.  Flexibilidad: qué tan fácil o difícil es hacer una modificación previamente especificada en el sistema  Estabilidad: Capacidad del producto de software de minimizar los efectos inesperados de las modificaciones  Facilidad para pruebas: Capacidad del producto de software de permitir evaluar las partes modificadas  Conformidad: Capacidad del producto de software de satisfacer los estándares o convenciones relativas a la mantenibilidad. 3.1.6.5 Portabilidad: Esta métrica define que tan fácil es adaptar el software para que corra sobre diferentes plataformas, no solo de sistemas operativos sino diferentes versiones diferentes esquemas, base de datos, navegadores y ambientes.  Capacidad para ser instalado. Facilidad con la que el producto se puede instalar y/o desinstalar de forma exitosa en un determinado entorno.  Capacidad para ser reemplazado. Capacidad del producto para ser utilizado en lugar de otro producto software determinado con el mismo propósito y en el mismo entorno.  Adaptabilidad. Capacidad del producto que le permite ser adaptado de forma efectiva y eficiente a diferentes entornos determinados de hardware, software, operacionales o de uso.  Co-Existencia - Coexistir con otro software independiente, en un entorno común, compartiendo recursos comunes. 3.1.6.6 Funcionalidad: Un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades específicas. Las funciones son aquellas que satisfacen las necesidades implícitas o explícitas 3.1.6.7 Seguridad: Este atributo de calidad garantiza que la información no es ni modificada ni divulgada a nadie excepto aquellos estipulados por las reglas de seguridad. Para cumplirlo se basa en los siguientes principios básicos:  Identidad: Los usuarios son identificados con un mecanismo de autenticación.  Autoridad: El usuario solo puede realizar acciones permitidas.  Integridad: La información solo puede ser alterada de formas permitidas.  Privacidad: La información solo es vista por las personas autorizadas de las formas autorizadas.  Auditoria: El sistema mantiene un registro de las acciones que se han realizado, para efectos de análisis futuros.. 22.

(24) 3.2 MARCO TEORICO En el contexto del desarrollo de este proyecto se ven involucrados diferentes plataformas, tecnologías, herramientas y soluciones con el propósito de lograr el objetivo de exponer las funcionalidades de negocio y la interoperación de las mismas. Principalmente se tienen cinco bloques de los cuales la mayoría de la documentación oficial de los fabricantes se encuentra aún en proceso de consolidación o en fuentes como Wikipedia, por lo que a continuación se describen y sintetizan específicamente las características más relevantes y de utilidad en el proyecto. 3.2.1 JAVA EE. Es una plataforma de programación parte del lenguaje Java para desarrollar y ejecutar software de aplicaciones.(ORACLE, 2013) JEE permite utilizar arquitecturas de N capas distribuidas y se apoya en componentes de software modulares ejecutándose sobre un servidor de aplicaciones. La plataforma Java EE está definida por una especificación similar a otras especificaciones de Java, sin embargo también es considerada informalmente como un estándar debido a que los proveedores deben cumplir ciertos requisitos para declarar que sus productos son conformes a Java EE estandarizado por The Java Community Process. 3.2.1.1 Componentes en JEE. Un componente Java EE es una unidad de software funcional auto-contenida que se ensambla en una aplicación con sus clases, archivos relacionados y tiene la capacidad de comunicarse con otros componentes (ORACLE, 2013). La especificación Java EE define los siguientes componentes:  Aplicaciones Cliente y applets: son componentes que se ejecutan en el cliente.  Java Servlets, JavaServer Faces y JavaServerPages (JSP): componentes de la tecnología que se ejecutan en el servidor (componentes web).  Componentes EJB: son componentes de negocio que se ejecutan en el servidor. Los componentes Java EE están escritos en el lenguaje de programación Java y son compilados en la misma forma. Las diferencias entre los componentes Java EE y las clases Java "normales" se fundamenta en que los componentes Java EE son ensamblados en una aplicación Java EE que se despliega en ambientes productivos en el que son administrados y gestionados por un servidor Java EE. 3.2.1.2 Clientes Java EE los clientes Java EE por lo general son clientes web o aplicaciones cliente.. 23.

(25)  Clientes Web Un cliente web a veces se llama “cliente ligero” y se compone de dos partes: o Páginas web dinámicas que contienen varios tipos de lenguaje (HTML, XML, etc), y son generados por los componentes web que se ejecutan en la capa web o Navegador web que ejecuta las páginas recibidas desde el servidor. Los clientes ligeros no suelen consultar bases de datos, ejecutar reglas de negocio complejas, o conectarse a aplicaciones heredadas(ORACLE, 2013). Cuando se utiliza un cliente ligero este tipo de operaciones robustas se asignan a Enterprise JavaBeans que se ejecutan en el servidor Java EE donde pueden aprovechar aspectos como la seguridad, velocidad y la fiabilidad de las tecnologías del lado del servidor. Los Enterprise JavaBeans se especifican en la sección 3.1.3  Aplicaciones Cliente. Las aplicaciones cliente se ejecutan en una máquina cliente y proporciona a los usuarios una interfaz gráfica para la interacción con el sistema y manejo de sus requerimientos. Las aplicaciones cliente escritas en otros idiomas además de Java pueden interactuar con los servidores Java EE lo que le da a la plataforma gran versatilidad al permitirle interoperar con sistemas heredados, clientes e idiomas que no son Java. 3.2.1.3 Servidor de comunicaciones Java EE. La Figura 3 muestra los diversos elementos que constituyen la capa cliente la cual se comunica con la capa de negocio que se ejecuta en el servidor Java EE ya sea directamente o a través de páginas web que se ejecutan en la capa del mismo nombre. Figura 3. Componentes de la capa cliente. Fuente: (ORACLE, 2013). 24.

(26) 3.2.1.4 Componentes Web Java EE. Los componentes Web Java usan la tecnología Java Server Faces o tecnología JSP para la ejecución de las mismas(ORACLE, 2013) y por su clasificación estas pueden ser de dos tipos:  Servlets: son clases de lenguaje de programación que procesan dinámicamente peticiones y construyen respuestas.  Páginas JSP: son documentos basados en texto que se ejecutan como servlets pero permitir un enfoque más natural para la creación de contenidos estáticos. Las páginas HTML estáticas y applets se empaquetan en los componentes web durante el ensamblaje de las aplicaciones, sin embargo estos no se consideran componentes web por la especificación Java EE. Como se muestra en la Figura 4 la capa web al igual que la capa cliente podría incluir el componente Enterprise JavaBeans para manejar la entrada del usuario y enviar ese flujo a la capa de negocio para su procesamiento. Figura 4. Capa Web. Fuente: (ORACLE, 2013). 3.2.1.5 Componentes de Capa de Negocio. La lógica de negocio que es la que en últimas resuelve o satisface las necesidades de un dominio en particular (banca, comercio, finanzas) está a cargo de que los Enterprise JavaBeans se ejecuten en la capa de negocio o en la capa web (ORACLE, 2013). En la siguiente figura se muestra cómo los Enterprise JavaBeans reciben los datos de programas cliente, los procesa si es necesario y los envía a la capa de información para el almacenamiento. Un Enterprise JavaBean también puede. 25.

(27) recuperar los datos almacenados, procesarlos y enviarlos de vuelta a la aplicación cliente. Figura 5. Lógica de ejecución entre las capas. Fuente: (ORACLE, 2013). 3.2.2 Servidor de Aplicaciones JEE. El servidor de aplicaciones JEE se puede definir como una plataforma de software que proporciona servicios de aplicación a los sistemas clientes, ofreciendo un componente de alto rendimiento para aplicaciones de negocio. El servidor de aplicaciones gestiona las peticiones de acceso a la lógica de negocio y acceso de datos de la aplicación. 3.2.2.1 El servidor de aplicaciones JBoss. Es el primer servidor de aplicaciones de código abierto preparado para la producción y certificado JEE, entre sus cualidades resalta su gran capacidad de procesamiento lo que le ha otorgado gran aceptación y popularidad a nivel general. (JBoss Comunity, 2014) Se ha seleccionado para el presente proyecto debido a su combinación entre una arquitectura orientada a servicios y una licencia de código abierto, JBoss AS puede ser descargado, utilizado, embebido y distribuido sin restricciones de licencia. Las características destacadas de JBoss incluyen:  Producto de licencia de código abierto sin coste adicional.. 26.

(28)      . Cumple los estándares de la industria. Confiable a nivel de empresa Orientado a arquitectura de servicios. Flexibilidad consistente Servicios del middleware para cualquier objeto de Java. Soporte completo para JMX.. JBoss contiene un conjunto de API's (applicationProgramming Interface), que permiten la aplicación de estándares JEE, y la implementación de soluciones más robustas y mejor formadas. 3.2.2.2 Arquitectura JBoss. En un nivel macro el servidor de aplicaciones consta de dos elementos principales: (JBoss Comunity, 2014)  Un núcleo contenedor de servicios administrable basado en la carga de clases modulares.  Extensiones a ese núcleo que ofrecen a las funcionalidades que la mayoría de usuarios asocian con un servidor de aplicaciones como el manejo de las peticiones HTTP y gestión de transacciones  Núcleo del Servidor de Aplicaciones El núcleo del servidor de aplicaciones consta de los siguientes elementos principales: o Un sistema de carga de clases modular o Una infraestructura de contenedores de servicio rápido y de gran escalabilidad o Una capa de gestión extensible que tiene la intención de mediar en el acceso al contenedor de servicios mediante la lógica que se requiera agregar, eliminar o modificar. La capa de gestión también proporciona un modelo coherente y persistente de configuración para el servidor de aplicaciones. La capa de gestión posee:  Capacidad de administración remota a través de los módulos de protocolo y administración de dominio-http  Dominios de varios servidores gestionados a través de los módulos de controlador host-proceso-controlador.  Elementos diversos prestados a través del administración clientecontenido y módulos propios de la plataforma.  Un marco de implementación para coordinar la instalación de contenido de implementación en el tiempo de ejecución.  Extensiones La mayor parte de la funcionalidad que los usuarios finales asocian con un servidor de aplicaciones es lo que se denomina extensiones. Los módulos en el código fuente del servidor de aplicaciones son implementaciones de esas extensiones, con cada extensión se proporciona un conjunto coherente de funcionalidades muchas de ellas compatibles con varios aspectos de las especificaciones técnicas de Java EE. 27.

(29) Al implementar estas extensiones a la interfaz se le permite la integración con el núcleo del servidor de aplicaciones en su capa de administración. A través de ese mecanismo las extensiones tienen la capacidad de: o Participar en el análisis y cálculo de referencias de los documentos de configuración del servidor de aplicaciones. o Registrar los recursos y las operaciones que se exponen a través de la API de gestión del servidor de aplicaciones. o Instalar los servicios en un contenedor de servicio del servidor de aplicaciones o Registrarse procesadores unidad de despliegue con el marco de la implementación del servidor de aplicaciones. 3.2.3 Enterprise JavaBeans (EJB). Los EJB proporcionan un modelo de componentes distribuido estándar del lado del servidor. El objetivo de los EJB es dotar al programador de un modelo que le permita abstraerse de los problemas generales de una aplicación empresarial (concurrencia, transacciones, persistencia, seguridad, etc.) para centrarse en el desarrollo de la lógica de negocio en sí. El hecho de estar basado en componentes permite que éstos sean flexibles y sobre todo reutilizables. (Enterprise JavaBeans, 2014) No hay que confundir los Enterprise JavaBeans con los JavaBeans. Los JavaBeans también son un modelo de componentes creado por Oracle - Sun Microsystems para la construcción de aplicaciones, pero no pueden utilizarse en entornos de objetos distribuidos al no soportar nativamente la invocación remota (RMI). 3.2.3.1 EJB de Entidad (EntityEJBs). Su objetivo es encapsular los objetos del lado del servidor que almacena los datos. Los EJB de entidad presentan la característica fundamental de la persistencia: (Enterprise JavaBeans, 2014)  Persistencia gestionada por el contenedor (CMP): el contenedor se encarga de almacenar y recuperar los datos del objeto de entidad mediante el mapeo o vinculación de las columnas de una tabla de la base de datos con los atributos del objeto.  Persistencia gestionada por el bean (BMP): el propio objeto entidad se encarga, mediante una base de datos u otro mecanismo, de almacenar y recuperar los datos a los que se refiere, por lo cual la responsabilidad de implementar los mecanismos de persistencia es del programador. 3.2.3.2 EJB de Sesión (SessionEJBs): gestionan el flujo de la información en el servidor. Generalmente sirven a los clientes como una fachada de los servicios proporcionados por otros componentes disponibles en el servidor. Puede haber dos tipos: (Enterprise JavaBeans, 2014)  Con estado (stateful). En un bean de sesión con estado, las variables de instancia del bean almacenan datos específicos obtenidos durante la conexión con el cliente. Cada bean de sesión con estado, por tanto, almacena el estado 28.

(30) conversacional de un cliente que interactúa con el bean. Este estado conversacional se modifica conforme el cliente va realizando llamadas a los métodos de negocio del bean. El estado conversacional no se guarda cuando el cliente termina la sesión.  Sin estado (stateless). Los beans de sesión sin estado son objetos distribuidos que carecen de estado asociado permitiendo por tanto que se los acceda concurrentemente. No se garantiza que los contenidos de las variables de instancia se conserven entre llamadas al método. 3.2.3.3 EJB dirigidos por mensajes (Message-drivenEJBs). Son los únicos beans con funcionamiento asíncrono. Usando el Java MessagingSystem (JMS), se suscriben a un tema (topic) o a una cola (queue) y se activan al recibir un mensaje dirigido a dicho tema o cola. No requieren de su instanciación por parte del cliente. (Enterprise JavaBeans, 2014) 3.2.3.4 Funcionamiento de un Enterprise JavaBean. Los EJB se disponen en un contenedor EJB dentro del servidor de aplicaciones. La especificación describe cómo el EJB interactúa con su contenedor y cómo el código cliente interactúa con la combinación del EJB y el contenedor, cada EJB debe facilitar una clase de implementación Java y dos interfaces Java. (Enterprise JavaBeans, 2014) El contenedor EJB creará instancias de la clase de implementación Java para facilitar la implementación EJB. Las interfaces Java son utilizadas por el código cliente del EJB. Las dos interfaces conocidas como interfaz "home" e interfaz remota, especifican las firmas de los métodos remotos del EJB. Los métodos remotos se dividen en dos grupos:  Métodos que no están ligados a una instancia específica, por ejemplo aquellos utilizados para crear una instancia EJB o para encontrar una entidad EJB existente. Estos métodos se declaran en la interfaz "home".  Métodos ligados a una instancia específica. Se ubican en la interfaz remota. Dado que se trata simplemente de interfaces Java y no de clases concretas, el contenedor EJB genera clases para esas interfaces que actuarán como un proxy en el cliente. El cliente invoca un método en los proxies generados que a su vez sitúa los argumentos método en un mensaje y envía dicho mensaje al servidor EJB. Los proxies usan RMI-IIOP para comunicarse con el servidor EJB. El servidor llamará a un método correspondiente a una instancia de la clase de implementación Java para manejar la llamada del método remoto. 3.2.4 Hibernate. Hibernate facilita la creación de clases de persistencia utilizando el lenguaje Java incluyendo la asociación, herencia, polimorfismo y composición y el entorno de colecciones Java. (Hibernate, 2014). 29.

(31) Figura 6. Componentes Hibernate. Fuente: (Hibernate, 2014). Hibernate es un servicio de persistencia objeto/relacional y consultas para Java, entre las principales características tenemos: 3.2.4.1 Mapeo. El mapeo en Hibernate gestiona asociaciones donde un objeto tiene una relación de uno a varios con otras instancias de su propio tipo, esto facilita un esquema las clases cuando existen varias relaciones de este tipo. (Hibernate, 2014) La asignación de clases Java a tablas de bases de datos se lleva a cabo a través de la configuración de un archivo XML o mediante notación Java. Cuando se utiliza un archivo XML Hibernate genera el código fuente para las clases de persistencia. Hibernate soporta el mapeo de tipos de valor personalizado. Esto hace que los siguientes escenarios posibles:  Asignación de una propiedad a múltiples columnas.  Los objetos en una aplicación front-end siguen los principios de POO, mientras que los objetos en el back-end siguen los principios de normalización de bases de datos, dando lugar a diferentes requisitos de representación. Este problema se llama "impedancia desajuste objeto-relacional". El mapeo es una forma de resolver el problema de falta de concordancia. 3.2.4.2 HibernateQueryLanguage. Hibernate ofrece un lenguaje SQL nativo denominado Hibernate Query Language (HQL) que permite consultas tipo SQL que se escriben contra los objetos de datos de Hibernate. (Hibernate, 2014) 3.2.4.3 Persistencia. Hibernate proporciona persistencia transparente para los POJOs (Plain Old Java Objects) el único requisito para una clase persistente es un 30.

(32) constructor sin argumentos, el comportamiento apropiado en algunas aplicaciones también requiere una atención especial a los métodos equals () y hashCode () (Hibernate, 2014). Las colecciones de objetos de datos normalmente se almacenan en objetos de la colección de Java tales como Sets y Listas propios de Java. 3.2.4.4 Integración. Hibernate puede ser utilizado tanto en aplicaciones Java autónomas y en las aplicaciones Java EE utilizando servlets, EJB de sesión y componentes de servicio, también se puede incluir como una característica en otros lenguajes de programación. 3.2.4.5 Entidades y componentes. En el contexto de Hibernate una entidad es un objeto independiente del mecanismo de persistencia que puede ser manipulado de forma independiente de otros objetos. En contraste un componente está subordinada a una entidad y puede ser manipulado sólo con respecto a esa entidad. (Hibernate, 2014) 3.2.5 JSF (JavaServer Faces). Es una tecnología y marco para aplicaciones Web Java que simplifica el desarrollo de interfaces de usuario en aplicaciones Java EE. JSF usa Java Server Pages (JSP) como la tecnología que permite hacer el despliegue de las páginas, pero también se puede acomodar a otras tecnologías, la especificación de JSF incluye: (Oracle, 2014)  Un conjunto de APIs para representar componentes de una interfaz de usuario y administrar su estado, manejar eventos, validar entrada, definir un esquema de navegación de las páginas y dar soporte para internacionalización y accesibilidad.  Un conjunto por defecto de componentes para la interfaz de usuario.  Dos bibliotecas de etiquetas personalizadas para Java Server Pages que permiten expresar una interfaz Java Server Faces dentro de una página JSP.  Un modelo de eventos en el lado del servidor.  Administración de estados.  Beans administrados. Lo que constituye el pilar fundamental en el desarrollo de los siguientes objetivos de diseño:  Definir un conjunto simple de clases base de Java para componentes de la interfaz de usuario, estado de los componentes y eventos de entrada. Estas clases tratarán los aspectos del ciclo de vida de la interfaz de usuario, controlando el estado de un componente durante el ciclo de vida de su página.  Proporcionar un conjunto de componentes para la interfaz de usuario, incluyendo los elementos estándares de HTML para representar un formulario. Estos componentes se obtendrán de un conjunto básico de clases base que se pueden utilizar para definir componentes nuevos.. 31.

(33)  Proporcionar un modelo de JavaBeans para enviar eventos desde los controles de la interfaz de usuario del lado del cliente a la aplicación del servidor.  Definir APIs para la validación de entrada, incluyendo soporte para la validación en el lado del cliente.  Especificar un modelo para la internacionalización y localización de la interfaz de usuario.  Automatizar la generación de salidas apropiadas para el objetivo del cliente, teniendo en cuenta todos los datos de configuración disponibles del cliente, como versión del navegador. 3.2.5.1 PrimeFaces Es un marco de interfaz de usuario basado en JavaServer Faces que facilita el desarrollo de aplicaciones robustas para la empresa o para los sitios web estándar, las aplicaciones JSF tradicionales son fáciles de crear y configurar sin embargo una de las ventajas de Prime Faces sobre en una aplicación JSF es que solo se tienen que agregar la biblioteca Prime Faces a una aplicación. Hay algunas configuraciones opcionales de menor importancia para la utilización de características de Prim eFaces tales como la carga de archivos y plantillas personalizadas. (Oracle EJB , 2014) 3.2.6 Android. Android es un sistema operativo basado en Linux, diseñado principalmente para dispositivos ligeros como teléfonos inteligentes y tablets. La mayoría de aplicaciones de Android están escritas en JAVA, aunque el sistema operativo no consta de una máquina virtual, por lo que para ejecutar el código JAVA este se compila en un ejecutable DALVIK y corre en la máquina virtual Dalvik la cual es especializada y diseñada específicamente para Android. (Android, 2013) Android para el desarrollo de sus aplicaciones provee un conjunto de herramientas denominada SDK, el cual facilita las librerías necesarias para la construcción de las aplicaciones para el sistema operativo, permite compilar el código en un paquete Androidapk, listas para ser instaladas en los dispositivos. Las características de operación de las aplicaciones en el sistema Android son las siguientes:  Android es un sistema Linux multi-usuario en la que cada aplicación es un usuario diferente.  Por defecto el sistema asigna a cada aplicación un ID único (es conocido solo por el sistema operativo y desconocido e inalcanzable para la aplicación). El sistema operativa asigna permisos a los archivos de acuerdo a cada ID de la aplicación.  Cada aplicación crea su propio proceso en el dispositivo, por lo que cada aplicación se ejecuta en forma aislada de las otras aplicaciones.  Por defecto cada aplicación se ejecuta sobre su propio proceso Linux, Android inicia el proceso cuando alguno de los componentes de la aplicación necesita. 32.

(34) ser ejecutado, por lo que el proceso de una aplicación en desuso será eliminado para permitir que la memoria sea usada por otras aplicaciones. 3.2.6.1 Arquitectura del sistema operativo de Android. Los componentes del sistema Android se describen en detalle a continuación: (Android, 2013)  Aplicaciones: las aplicaciones base incluyen un cliente de correo electrónico, programa de SMS, calendario, mapas, navegador, contactos y otros. Todas las aplicaciones están escritas en lenguaje de programación Java.  Marco de trabajo de aplicaciones: los desarrolladores tienen acceso completo a los mismos APIs del framework usados por las aplicaciones base. La arquitectura está diseñada para simplificar la reutilización de componentes; cualquier aplicación puede publicar sus capacidades y cualquier otra aplicación puede luego hacer uso de esas capacidades (sujeto a reglas de seguridad del framework). Este mismo mecanismo permite que los componentes sean reemplazados por el usuario.  Bibliotecas: Android incluye un conjunto de bibliotecas de C/C++ usadas por varios componentes del sistema. Estas características se exponen a los desarrolladores a través del marco de trabajo de aplicaciones de Android; algunas son: System C library (implementación biblioteca C estándar), bibliotecas de medios, bibliotecas de gráficos, 3D y SQLite, entre otras.  Runtime de Android: Android incluye un set de bibliotecas base que proporcionan la mayor parte de las funciones disponibles en las bibliotecas base del lenguaje Java. Cada aplicación Android corre su propio proceso, con su propia instancia de la máquina virtual Dalvik. Dalvik ha sido escrito de forma que un dispositivo puede correr múltiples máquinas virtuales de forma eficiente. Dalvik ejecuta archivos en el formato DalvikExecutable (.dex), el cual está optimizado para memoria mínima. La Máquina Virtual está basada en registros y corre clases compiladas por el compilador de Java que han sido transformadas al formato .dex por la herramienta incluida "dx".  Núcleo Linux: Android depende de Linux para los servicios base del sistema como seguridad, gestión de memoria, gestión de procesos, pila de red y modelo de controladores. El núcleo también actúa como una capa de abstracción entre el hardware y el resto de la pila de software. 3.2.6.2 Componentes Android.  Intent. Un Intent es un objeto de mensajería que puede utilizar para solicitar una acción de otro componente de aplicación. Aunque las intenciones de facilitar la comunicación entre los componentes de varias maneras, hay tres casos de uso fundamentales: (Android, 2013) o Para iniciar una actividad. o Recibir un resultado de la actividad cuando termine. o Para iniciar un servicio. o Para entregar una emisión.. 33.