INTEGRACIÓN DINÁMICA DE APLICACIONES
CON SERVICIOS INFORMÁTICOS
JHON JAIRO GUANUME ANGULO
CÓDIGO 920991
SEBASTIÁN RAMÍREZ CANO
CÓDIGO 1120620
UNIVERSIDAD PILOTO DE COLOMBIA
FACULTAD DE INGENIERÍA
PROGRAMA DE INGENIERÍA DE SISTEMAS
BOGOTÁ
2018
INTEGRACIÓN DINÁMICA DE APLICACIONES
CON SERVICIOS INFORMÁTICOS
JHON JAIRO GUANUME ANGULO
CÓDIGO 920991
SEBASTIÁN RAMÍREZ CANO
CÓDIGO 1120620
Trabajo de Grado para optar al
Título de Ingeniería de Sistemas
Director
GILBERTO PEDRAZA GARCÍA
Ingeniero de Sistemas y Computación PhD.
UNIVERSIDAD PILOTO DE COLOMBIA
FACULTAD DE INGENIERÍA
PROGRAMA DE INGENIERÍA DE SISTEMAS
BOGOTÁ
2018
NOTA DE ACEPTACIÓN
______________________________
______________________________
______________________________
______________________________
______________________________
Presidente del Jurado
______________________________
Jurado
______________________________
Jurado
Bogotá 15 de mayo de 2018
CONTENIDO
Pág.
GLOSARIO ....................................................................................................... 11
RESUMEN ........................................................................................................ 13
INTRODUCCIÓN. ............................................................................................. 14
1. SITUACIÓN DEL PROBLEMA ................................................................... 16
1.1 DEFINICIÓN DEL PROBLEMA. ................................................................ 16
1.2 FORMULACIÓN DEL PROBLEMA. .......................................................... 17
1.3 JUSTIFICACIÓN ....................................................................................... 18
1.4 OBJETIVOS. ............................................................................................. 18
1.4.1 GENERAL ................................................................................................. 18
1.4.2 ESPECÍFICO ............................................................................................ 18
1.5 LÍMITES .................................................................................................... 18
1.6 ALCANCE ................................................................................................. 19
2. MARCO REFERENCIAL. ........................................................................... 20
2.1 MENSAJERÍA ........................................................................................... 20
2.2 CANAL DE COMUNICACIÓN ................................................................... 20
2.3 CANAL PUNTO A PUNTO ........................................................................ 21
2.4 TRANSFORMADOR O MEDIADOR DE MENSAJE .................................. 22
2.5 ENRUTADORES DE COMUNICACIÓN .................................................... 23
2.6 ENDPOINT DE COMUNICACIÓN ............................................................ 23
2.7 BUS DE MENSAJERÍA O ESB ................................................................. 24
3. METODOLOGÍA ......................................................................................... 26
3.1 FASE UNO................................................................................................ 26
3.1.1 FASE DOS ................................................................................................ 26
3.1.2 FASE TRES .............................................................................................. 27
3.1.3 FASE CUATRO ........................................................................................ 27
3.2 DISEÑO METODOLÓGICO. ..................................................................... 27
4. DESARROLLO METODOLÓGICO ............................................................ 29
4.1 DEFINICIÓN Y ESPECIFICACIÓN DE REQUERIMIENTOS .................... 29
4.1.1 REQUERIMIENTOS FUNCIONALES ....................................................... 29
4.1.2 DELIMITAR COMPONENTES DE INTEGRACIÓN DE MENSAJERÍA. .... 29
4.1.3 DEFINIR LÓGICA DE NEGOCIO ............................................................. 29
4.1.4 DESARROLLAR LOS CANALES DE MENSAJERÍA QUE CONECTA
CON LAS APLICACIONES. .................................................................................... 30
4.1.5 CREACIÓN DE MENSAJES DE EJECUCIÓN. ......................................... 30
4.1.6 CONSTRUIR ENRUTADORES QUE SE INTEGRAN CON EL ESB. ........ 31
4.1.7 CONSTRUIR UN MÉTODO DE TRANSFORMACIÓN DE MENSAJES
PARA EL ESB FLEXIBLE. ...................................................................................... 31
4.1.8 CONSTRUCCIÓN DEL ENDPOINT PARA EL ESB FLEXIBLE. ............... 32
4.1.9 DEFINIR LA COMUNICACIÓN ASÍNCRONA. .......................................... 32
4.1.10 DEFINIR LAS HERRAMIENTAS PARA LA CONSTRUCCIÓN DEL ESB
FLEXIBLE ............................................................................................................... 32
4.1.11 CONSTRUIR EL BUS DE SERVICIO FLEXIBLE. ..................................... 33
4.1.12 INTEGRAR EL BUS DE SERVICIO FLEXIBLE CON LA MENSAJERÍA DE
APLICACIONES. ..................................................................................................... 33
4.1.13 CONSTRUIR MÓDULO DE AUDITORÍA. ................................................. 33
4.1.14 CONSTRUIR EL MÓDULO DE TRAZABILIDAD ....................................... 34
4.1.15 CONSTRUIR EL MÓDULO DE SEGURIDAD. .......................................... 34
4.1.16 CONSTRUIR EL MÓDULO DE ERRORES ............................................... 35
4.1.17 CONSTRUIR CASOS PRUEBAS ............................................................. 35
4.1.18 ENTREGA DE PRODUCTO ..................................................................... 35
4.2 REQUERIMIENTOS NO FUNCIONALES ................................................. 36
4.2.1 ATRIBUTOS DE CALIDAD ....................................................................... 36
4.2.1.1 Disposición................................................................................................ 36
4.2.1.2 Seguridad ................................................................................................. 36
4.2.1.3 Auditoría ................................................................................................... 36
4.2.1.4 Trazabilidad .............................................................................................. 37
4.2.1.5 Confiabilidad ............................................................................................. 37
4.2.1.6 Manejo de errores ..................................................................................... 38
4.2.1.7 Despliegue ................................................................................................ 39
4.2.1.8 Mantenibilidad ........................................................................................... 39
4.2.2 Rendimiento .............................................................................................. 39
4.3 ARQUITECTURA DE LA SOLUCIÓN ....................................................... 40
4.3.1 DISEÑO DE COMPONENTES ARQUITECTURA DE INTEGRACIÓN ..... 40
4.3.2 ARQUITECTURA PROPUESTA ............................................................... 40
4.3.2.1 Descripción ............................................................................................... 42
4.3.2.2 Responsabilidades .................................................................................... 42
4.3.3 CAPA DE SERVICIOS .............................................................................. 42
4.3.3.1 Descripción ............................................................................................... 43
4.3.3.2 Responsabilidades .................................................................................... 43
4.4 MODELO DE DOMINIO ............................................................................ 43
4.5 ARQUITECTURA DE LA SOLUCIÓN. ...................................................... 44
4.6 DESCRIPCIÓN GENERAL Y DETALLADA DE LA ESTRATEGIA DE
SOLUCIÓN ............................................................................................................. 45
4.7 VISTA FUNCIONAL .................................................................................. 47
4.7.1 Descripción ............................................................................................... 48
4.7.2 Responsabilidades .................................................................................... 48
4.8 VISTA DE DESPLIEGUE. ......................................................................... 49
4.8.1 Descripción ............................................................................................... 49
4.8.2 Responsabilidades .................................................................................... 49
4.8.3 Descripción ............................................................................................... 50
4.8.4 Responsabilidades .................................................................................... 50
4.9 HERRAMIENTAS DETALLADAS .............................................................. 51
4.9.1 IDE ECLIPSE ............................................................................................ 51
4.9.2 LENGUAJE DE PROGRAMACIÓN JAVA ................................................. 51
4.9.3 APACHE CAMEL ...................................................................................... 51
4.9.4 CONTENEDOR DE APLICACIONES SERVICEMIX ................................. 52
4.9.5 BASE DE DATOS MONGODB .................................................................. 52
4.9.6 ACTIVEMQ ............................................................................................... 52
4.10 PRUEBAS ................................................................................................. 53
4.10.1 Casos de Pruebas ..................................................................................... 53
4.10.2 PRUEBAS A LAS APLICACIONES EXTERNA ......................................... 56
4.10.3 Caso de prueba uno facturación ............................................................... 56
4.10.4 Caso de prueba dos inventario .................................................................. 58
4.10.5 Caso de prueba tres recomendador .......................................................... 59
4.10.6 Caso de prueba cuatro generar factura ..................................................... 61
4.10.7 Caso de prueba cinco eliminar .................................................................. 63
4.10.8 Caso de prueba seis recomendador (bus de servicios) ............................. 64
5. CONCLUSIONES ....................................................................................... 66
6. TRABAJO A FUTURO................................................................................ 68
BIBLIOGRAFÍA ................................................................................................. 69
ANEXOS ........................................................................................................... 70
LISTA DE FIGURAS
Pág.
Figura 1. Canal de Comunicación ......................................................................................... 21
Figura 2. Canal Punto a Punto ............................................................................................... 22
Figura 3. Transformador o mediador de Mensaje ............................................................... 22
Figura 4. Enrutadores de Comunicación .............................................................................. 23
Figura 5. Endpoint de Comunicación .................................................................................... 24
Figura 6. Bus de mensajería o ESB ...................................................................................... 25
Figura 7. Módulo de Error ....................................................................................................... 39
Figura 8. Arquitectura por Capas ........................................................................................... 41
Figura 9. Capa de Servicios ................................................................................................... 42
Figura 10. Modelo de Dominio ............................................................................................... 44
Figura 11. Arquitectura de la solución. ................................................................................. 45
Figura 12. Flujo de Mensajería .............................................................................................. 47
Figura 13. Flujo de Autenticación .......................................................................................... 47
Figura 14. Flujo Auditoría ........................................................................................................ 48
Figura 15. Vista de despliegue ............................................................................................... 49
Figura 16. Diagrama de secuencia ....................................................................................... 50
Figura 17. Entorno Gráfico herramienta Postman .............................................................. 53
Figura 18. Encabezado del servicio ...................................................................................... 54
Figura 19. Cuerpo del servicio ............................................................................................... 54
Figura 20. Respuesta del servicio ......................................................................................... 55
Figura 21. Mensaje de respuesta del servicio ..................................................................... 55
LISTA DE TABLAS
Pág.
Tabla 1. Delimitar componentes de Integración de mensajería. ...................................... 29
Tabla 2. Definir lógica de negocio ........................................................................................ 29
Tabla 3. Construcción de canales de mensajería que se conecta con el ESB ............. 30
Tabla 4. Creación de mensajes de ejecución ...................................................................... 30
Tabla 5. Construcción de conectores y mediadores para el ESB flexible. ..................... 31
Tabla 6. Construir enrutadores que se integran con el ESB ............................................. 31
Tabla 7. Construir un método de transformación de mensajes para el ESB flexible. ... 32
Tabla 8. Construcción del EndPoint para el ESB Flexible ................................................. 32
Tabla 9. Definir tipo de comunicación asíncrona. ............................................................... 32
Tabla 10. Definir las herramientas para la construcción del ESB flexible ....................... 33
Tabla 11. Construir el Bus de Servicio flexible .................................................................... 33
Tabla 12 .Integrar el Bus de servicio flexible con la mensajería de aplicaciones .......... 33
Tabla 13. Construcción del módulo de auditoría ................................................................. 34
Tabla 14. Construcción del módulo de trazabilidad. ........................................................... 34
Tabla 15. Construcción del módulo de Seguridad para el ESB flexible .......................... 34
Tabla 16. Construcción del módulo de Seguridad para el ESB flexible .......................... 35
Tabla 20. Caso de prueba Uno Facturación ........................................................................ 58
Tabla 21. Caso de prueba Dos Inventario............................................................................ 59
Tabla 22. Caso de prueba Tres Recomendador ................................................................. 61
Tabla 23. Caso de prueba Cuatro generar factura ............................................................. 63
Tabla 24. Caso de prueba Cinco eliminar ............................................................................ 64
Tabla 25. Caso de prueba Seis recomendador (bus de servicios) .................................. 65
LISTA DE ANEXOS
ANEXO A. MANUAL DE USUARIO ...................................................................................... 70
ANEXO B. ARCHIVOS DE CONFIGURACIÓN .................................................................. 73
ANEXO C. ERRORES CONTEMPLADOS DENTRO DEL PROGRAMA ....................... 74
GLOSARIO
Backend: proceso que ejecuta el servidor web para procesar, tareas órdenes,
secuencias, funcionalidades, disparadores a base de datos, es el agente de
entregar el contenido que no es visible para el usuario final.
Balanceadores de carga: herramienta encargada de distribuir equitativamente
las peticiones del tráfico de información de los servicios web a los diferentes
servidores donde se instala la aplicación.
CÓDIGO UUID: código identificador estándar universal que permite reconocer
objetos dentro del software.
CXF: framework para la construcción de servicios web.
Daily: operación de la metodología ágil Scrum donde se realiza una reunión
diaria para revisar avance, estado y novedades encontradas en el proyecto de
software.
DSL: conexión de servicios web que permite la conectividad con los servicios
expuestos.
ESB: son las iniciales de (Enterprise Service Bus) o bus de servicio
empresarial, funciona como intermediario para el flujo de información con las
aplicaciones.
Framework: patrón para el desarrollo de aplicaciones.
JBOSS: servidor de aplicaciones web.
JSON: notación de objetos de JavaScript, cuyo formato de intercambio de
datos basado está basado en un archivo plano o de texto.
LOGS: trazabilidad o secuencia de sucesos donde se almacenan todos los
eventos que se generan una aplicación.
Middleware: permite la comunicación y la administración entre aplicaciones
distribuidas lo que permite el intercambio de información entre aplicaciones.
ORQUESTACIÓN: es la coordinación y disposición de los diferentes servicios
web expuestos.
Plugin: complemento que requiere una aplicación en específico, que añade
funcionalidades a un componente determinado.
Postman: herramienta o extensión de Google Chrome de uso gratuito que
permite probar y consumir servicios web.
Protocolo HTTP: protocolo de transferencia de texto que gestiona el
intercambio de información.
REST: patrón de diseño que se enfoca en el protocolo de intercambio y
manipulación de información.
Scrum: metodología ágil para la elaboración de proyectos de software.
Servicios web: sirve para intercambiar datos entre aplicaciones con capacidad
de interactuar con la red.
T.I: tecnologías de las información
Timeout: error que ocurre al momento en que se supere el límite de tiempo de
respuesta del servicio web.
RESUMEN
El presente trabajo de grado se constituye en el desarrollo de software, se hace
necesario destacar la construcción de un bus de servicio flexible que tenga la
capacidad de integrar aplicaciones heterogéneas con distintos sistemas para
cualquier tipo de empresa. El problema actual se evidencia cuando la
información internamente de una organización se halla recopilada en diferentes
servidores lo que implica una mayor cantidad de instrucciones manejables que
se ejecutan entre sistemas, por motivo se presentan inconvenientes al
momento de transmitir la información de un punto a otro. La presente
investigación tiene como resultado la integración entre aplicaciones con el bus
de servicio flexible con el objetivo de integrar un máximo de tres aplicaciones
por corporación.
INTRODUCCIÓN.
El presente trabajo de grado como principal objetivo se efectúa para optar por
el título de ingeniero de sistemas de la universidad piloto de Colombia el
contenido de este proyecto está orientado en el desarrollo de software, de
manera puntual, en la construcción de un bus de servicio flexible que se
encuentre en la capacidad de integrar aplicaciones de otros sistemas, el
contexto del bus de servicio está diseñado con un framework llamado apache
camel cuya función principal es ser un enrutador de mensajes lo que permite
realizar conexiones entre aplicaciones y/o servicios que hacen conforman el
ESB. Esto quiere decir, si se pretende transmitir información de un punto a otro
con sistemas de diferente lenguaje de programación, infraestructura, sistemas
o subsistemas la herramienta a desarrollar está en la capacidad de integrar
aplicaciones sin tener en cuenta las evidencias anteriores. Como mejoramiento
se identifican los elementos a través de peticiones de servicios web acorde con
el modelo de arquitectura de micro servicios Rest propuesto.
La importancia de realizar este trabajo de grado radica en el reto de innovar en
el uso de herramientas opensource, lo que permite tener un mayor número de
elecciones de programa de computador a usar, por otra parte, se tiene una
mayor variedad de distribución para el uso de estas plataformas a utilizar. A
pesar de que son herramientas fuertemente criticadas el uso de estas
tecnologías están cogiendo mucho auge debido a la confiabilidad y seguridad
de las librerías con las que cuenta cada extensión de los diferentes tipos de
framework, lo forja una mejor adaptabilidad de cada uno de los entornos o IDE
de desarrollo con los que se puede conectar nuestro ESB flexible.
Partiendo de los requerimientos básicos de algunas empresas colombianas se
evidencia que muchas de las entidades realizan procedimientos manuales lo
que genera el desgaste de un recurso de la compañía, atendiendo a estas
consideraciones se presenta una pérdida de tiempo al personal encargado,
este quiere decir que en algunos procedimientos al interior de las compañías
no se garantizan satisfactoriamente o no se obtienen los resultados esperados
al no tener automatizados sus procesos. De lo anterior expuesto resulta un
mercado al que se le puede ofrecer un bus de servicio flexible con las
características mencionadas.
Como resultado de la investigación se desarrolló en su totalidad el ESB flexible
cumpliendo con los objetivos propuestos en este trabajo de grado, lo que
genera una gran satisfacción, a pesar de los limitantes como el uso específico
de un formato para la mensajería donde la solución encontrada es utilizar una
base de datos que comparte el mismo formato, no se trata solo de este se
debió acortar el alcance del proyecto, la cantidad de integraciones con el ESB a
establecer, por último se debió eliminar el entorno gráfico donde se planteaba
tener una mejor experiencia para el usuario final con el ESB, por otro lado el
tiempo de entrega, como resultado se realiza este proyecto de la siguiente
manera
El proyecto se ejecuta con los lineamentos de la metodología ágil Scrum donde
se da cumplimiento al estado de los objetivos del proyecto con el fin de trabajar
colaborativamente en equipo cuyo ente es analizar la lógica de negocio, ajustar
solicitudes de servicios, certificar el análisis, diseño y construcción de la
aplicación desarrollada con componentes openSource garantizando el ciclo de
vida en el diseño de software.
Durante la ejecución de este trabajo de grado el aporte más significativo es la
gratificación, ya que creó un producto totalmente desde cero cumpliendo con la
construcción total de una aplicación robusta que se encuentra completamente
diseñada bajo los estándares necesarios para posicionarse en un mercado
competitivo de las tecnologías de la comunicación.
El impacto de este trabajo de grado se verá reflejado a futuro con el uso de
esta herramienta en particular, ya que nos permite abrir paso en un ambiente
laboral aportando el conocimiento para cubrir las necesidades en el
modelamiento de procesos e integración de servicios para cualquier entidad.
1. SITUACIÓN DEL PROBLEMA
El problema actual se evidencia cuando la información internamente de una
organización se halla recopilada en diferentes servidores lo que implica una
mayor cantidad de instrucciones manejables que se ejecutan entre sistemas,
por motivo se presentan inconvenientes al momento de transmitir la
información de un punto a otro.
1.1 DEFINICIÓN DEL PROBLEMA.
El problema surge con la información dentro de una organización, ya que se
encuentra almacenada en diferentes sistemas, aplicaciones, en distintos
servidores, es decir en una infraestructura tecnológica opuesta. Es por esto que
en particular que se desea asegurar la trasferencias de mensajería de un lugar
a otro, se hace necesario indagar sobre el uso de nuevas tecnologías donde
permita usar conectores que faciliten la comunicación entre diferentes
aplicaciones, logrando minimizar el tiempo de respuesta entre el llamado de
una aplicación con otra mediante el intercambio de mensajes que contienen
información compartida entre aplicaciones y/o plataformas.
EL problema actual está planteado por una empresa en referencia un
restaurante bar que cuenta con varias sedes en la ciudad de Bogotá con el
objetivo de administrar su catálogo de productos y ventas que ofrece al
mercado. La solución final se encuentra orientada a esta compañía tipo pyme
que cuenta con una cantidad de recursos limitados, donde se pretende
desarrollar un marco de trabajo conceptual que permita a la organización
integrar los datos y la lógica de negocio de sus aplicaciones por separado.
Dado el problema propuesto se requiere adaptar una arquitectura API REST
que gestiona la comunicación entre servicios web, dicha solución integra y
gestiona el intercambio de información entre diferentes sistemas.
Por otra parte se pretende reducir la cantidad de operaciones con las que
interactúa un usuario día a día en su puesto de trabajo, personalizando al
detalle el flujo de la información de las aplicaciones con las que interactúa, así
exponer una capa de negocio mediante una orquestación de servicios REST.
Dicha empresa actualmente utiliza conexiones punto a punto lo que genera
conflicto entre aplicaciones por no tener un lenguaje en común, se propone un
desarrollo que se encargue de minimizar las dependencias entre aplicaciones y
lógica de negocio.
El objetivo del desarrollo es evitar el trabajo repetitivo que en ocasiones genera
una pérdida de control, teniendo como un resultado final una desinformación,
pérdida de comunicación tanto a nivel personal como entre aplicativos.
Esto quiere decir que la información que se maneja al interior de las entidades
se encuentra almacenada hasta en dos diferentes aplicaciones o servidores
que no cuentan con un sistema que facilite la conexión, o sirva de puente entre
ellas mismas para realizar la comunicación de la información de una manera
eficaz y eficiente.
La solución final de la herramienta propuesta, está orientada en el ambiente
académico, diseñada bajo parámetros específicos, tomando en cuenta
requerimientos estándar del mercado, lo que significa que no es muy flexible a
cambios. Por lo tanto, la función principal del software consiste en ser un
mediador flexible entre las diferentes aplicaciones para que estas puedan
comunicarse entre sí.
1.2 FORMULACIÓN DEL PROBLEMA.
El trabajo administrativo contable de pequeñas, medianas y grandes empresas,
requiere del constante manejo de múltiples aplicaciones que faciliten registros,
manejos operacionales o incluso soportes contables, sin embargo, la
articulación de esta multiplicidad de información resulta ser un desafío para la
gran mayoría de usuarios.
Es allí donde surge el problema cuando la información usualmente se halla
almacenada en diferentes servidores, repositorio de aplicaciones, en puntos de
geolocalización contrapuestos. Esto significa que al momento de hacer uso de
los datos no se encuentran disponibles, no coinciden, o no son compatibles
puesto que los productos dentro de la organización no cuentan con una
infraestructura compatible para la transferencia de información de un punto a
otro.
Esto hace necesario desarrollar conectores que permitan comunicar las
diferentes aplicaciones, a su vez ayudar a las organizaciones a tomar
decisiones más integrales proporcionando acceso más rápido, visibilidad,
control sobre los datos a medida que circulan por las aplicaciones y sistemas
de la empresas que están siendo usadas.
Dada la necesidad de unificar el flujo de la información entre las diferentes
aplicaciones o sistemas, se requiere desarrollar una solución que permita
conectar una diversidad de aplicaciones heterogéneas ya sea por su lenguaje
de programación, formato o servicios web donde se almacena dicha
información.
1.3 JUSTIFICACIÓN
A raíz de la necesidad de implementar un bus de servicio dinámico que consiga
articular las aplicaciones en uso al interior de las empresas, el propósito inicial
del trabajo de grado, es realizar una integración de servicios con la
comunicación de aplicaciones, teniendo en cuenta los problemas técnicos
relacionados con la funcionalidad de los diferentes aplicativos que hacen parte
de las empresas.
Integrar sus sistemas y procesos compartiendo datos e información en tiempo
real. Inicialmente el diseño del bus de servicios está dirigido para una empresa
en concreto, sin embargo, se espera que el diseño de esta aplicación consiga
consolidarse como un mecanismo de articulación que logre ser funcional para
numerosas empresas.
1.4 OBJETIVOS.
1.4.1 GENERAL
Desarrollar un bus de servicio flexible de invocación dinámica que integre
mensajes con diferentes sistemas.
1.4.2 ESPECÍFICO
Diseñar, construir e implementar conectores y mediadores para el manejo
de las interacciones entre servicios e instancias.
Usar servicios web de tipo REST con mensajería en formato JSON.
Garantizar la mensajería entre sistemas a partir de la sincronización de los
servicios expuestos.
1.5 LÍMITES
Los servicios están diseñas en una arquitectura REST.
El mensaje de entrada que proviene de diferentes sistemas debe venir en
formato de intercambio JSON.
El número máximo de sistemas de integración con el ESB es hasta tres
aplicaciones para este trabajo de grado.
Para la seguridad se utiliza un código de identificador más conocido como
token.
1.6 ALCANCE
El bus de servicio tendrá la flexibilidad y adaptabilidad para un máximo de
tres aplicaciones.
Se hace entrega de la fase uno que contempla la construcción del bus de
servicio flexible el cual está en la capacidad de integrar aplicaciones
mediante servicios de tipo REST y mensajería en formato en JSON.
No se realiza integración de datos entre aplicaciones, dado que por tiempo
se debió eliminar la integración entre la data y aplicaciones.
No se hace entrega de interfaz gráfica. ya que no se cuenta con el tiempo
necesario para desarrollar dicho entorno gráfico.
La simulación de la solución final se mostrará por medio de la herramienta
llamada postman, el cual es un aplicativo de uso gratuito que permite
consumir servicios web de tipo REST.
2. MARCO REFERENCIAL.
En este capítulo se describe de manera detallada el funcionamiento de un bus
de servicio flexible iniciando con la definición de un mensaje y terminado con la
integración del bus de servicio con el mensaje expuesto, donde se detalla la
creación del mensaje tipo REST, pasando por ESB publicando la ejecución del
flujo del mensaje a través de todos los componentes que interactúan con el bus
de servicio flexible.
2.1 MENSAJERÍA
Se define un mensaje de comunicación entre sistemas y aplicaciones al
proceso de intercambio de datos en donde interactúa un emisor que despacha
a un receptor un mensaje explícito a través de un canal de comunicación
determinado. En el entorno de ingeniería se precisa como un mensaje al paso
de transferencia de información de un sistema a otro mediante un formato en
específico, para en este proyecto se reciben y envían los mensajes en formato
de texto plano que se utiliza para el intercambio de datos, dicho formato es un
documento JSON el cual contiene la estructura de los mensajes que consume
el ESB flexible.
2.2 CANAL DE COMUNICACIÓN
Una vez teniendo el mensaje se empieza a desglosar que es un canal de
comunicación, un canal de comunicación es el intermedio por el cual se
transporta la información o mensaje con la que gestiona el emisor para hacer
llegar al receptor dicho mensaje.
Para esta aplicación los canales de comunicación son objetos que se encargan
de proveer o trasladar los mensajes de una aplicación a otra en una misma o
en diferentes plataformas. Cuya finalidad es garantizar la transferencia de
mensajes de un punto a otro, dichos canales definen las rutas de comunicación
entre las aplicaciones a integrar.
Figura 1. Canal de Comunicación
Fuente: GREGOR, Hohpe, BOBBY Woolf enterprise integration patterns:
designing, building, and deploying messaging solutions. 1 ed. E.U: 2004. p.60
Existen métodos de difusión que se utilizan para hacer llegar a su destino el
mensaje, lo que permite garantizar la entrega del mensaje de modo que los
difusores se conocen como conectores de comunicación, estos conectores son
los encargados de ser un punto de conexión a través de una palabra
estratégica o una serie de partes del mensaje que establecen una relación
clave entre el mensaje y el canal de comunicación.
Lo que permite la sincronización del mensaje es una adecuada unión del
formato JSON con los demás esquemas que se enlazan a la aplicación, a
través de un conector que envía eventos a diferentes sistemas, los conectores
se encargan de ser mediadores en el flujo de mensajería donde interactúa un
emisor enviando una solicitud al receptor del sistema de mensajería donde,
luego de una serie de procedimientos la configuración del conector coordina,
además gestiona el envío y la recepción del mensaje.
Cuando dos aplicaciones desean intercambiar datos lo hacen enviando la
información a través de un canal que conecta la aplicación que envía los datos
que puede no saber qué sistema recibirá la información, es donde se debe
utilizar un canal en específico para enviar dichos datos.
2.3 CANAL PUNTO A PUNTO
Las uniones se integran a un canal punto a punto, a través de sitios de
conexión que son los encargados de asegurar que un receptor recibe un
mensaje de las distintas aplicaciones por medio de una cantidad de puntos de
conexión en la que se ejecuta la integración al sistema, lo que permite que los
mensajes fluyan entre distintos sistemas de una empresa estos canales definen
la vía que tomara la información.
Si varios receptores intentan consumir un mensaje, el canal garantiza que la
mensajería se gestiona en forma de cola, el primero que entra es el primero
que sale como las fila de un banco, por lo que los receptores no tienen que
coordinarse entre sí, dada la cantidad de peticiones que se envía al receptor. El
canal está en la capacidad de enviar a varios receptores para consumir
múltiples mensajes al mismo tiempo, pero solo un receptor a su vez consume
un solo mensaje.
Figura 2. Canal Punto a Punto
Fuente: GREGOR, Hohpe, BOBBY Woolf enterprise integration patterns:
designing, building, and deploying messaging solutions. 1 ed. E.U: 2004. p.111
2.4 TRANSFORMADOR O MEDIADOR DE MENSAJE
Una vez teniendo el mensaje en el canal de comunicación definido como en
todo lenguaje es necesario unificar la información para ello se requiere los
mediadores que son los encargados de promover la negociación y la
comunicación entre ambas partes, logrando concebir un mismo lenguaje entre
las partes involucradas.
Además de ser un mediador funciona como un traductor, dado que si el
mensaje viene en diferentes lenguajes, dicho mediador debe están en
capacidad de transformar los mensajes, a un lenguaje general que sea capaz
de entender las personas y el sistema.
Ejemplo los traductores de idiomas se encargan de ser mediadores entre las
palabras de origen en un texto y la palabra destino, dicho traductor necesita
realizar validaciones de la palabra existe, dado procedimientos internos del
sistema es capaz de arrojar resultado esperado haciendo entendible el
resultado o palabra final del emisor hacia el receptor. Examinado el mensaje y
haciéndolo llegar al Canal o mensaje de destino.
Figura 3. Transformador o mediador de Mensaje
Fuente: GREGOR, Hohpe, BOBBY Woolf enterprise integration patterns:
designing, building, and deploying messaging solutions. 1 ed. E.U: 2003. p.85
2.5 ENRUTADORES DE COMUNICACIÓN
Los enrutadores son intermediarios que se encargan de direccionar los
mensajes según su contenido a los diferentes destinos. Dicho servicio de
enrutamiento analiza cada mensaje y lo direcciona mediante los filtros de cada
petición del servicio REST.
En un ejemplo dichos enrutadores son los que tienen la función de hacer llegar
el mensaje del emisor al receptor por medio de señales de humo, teléfonos
móviles, cartas, filtros específicos etc.
Es algo así como un mensajero que se encarga de inspeccionar el contenido
del mensaje, lo en ruta para hacer llegar dicha encomienda al destino final o
destino correcto.
Figura 4. Enrutadores de Comunicación
Fuente: GREGOR, Hohpe, BOBBY Woolf enterprise integration patterns:
designing, building, and deploying messaging solutions. 1 ed. E.U: 2003. p.85
2.6 ENDPOINT DE COMUNICACIÓN
El Endpoint define la cantidad de objetos, por ende la aplicación pueden enviar
y recibir mensajes, aprobando o denegando la integración de mensajería con
los diferentes componentes. La función principal del Endpoint es ser un
intermediario entre consumo y obtención de servicios Web para este caso el
framework de apache Camel. Por medio del Endpoint un servicio Web puede
ser publicado o ser un punto de destino, proporcionando la información
necesaria para entregar dicho mensaje.
Dicho Endpoint interactúa con el sistema de mensajería siendo el que expone
el servicio o mensaje a ser consultado. Se puede hacer referencia a un
mensajero el cual es la entidad encargada de realizar la trasmisión del mensaje
a un receptor para que esta encomienda llegue a su destino se deben tomar
rutas de validación para nuestro caso se llamarían DSL que normalmente se
asocia a una URL o dirección de envió por consiguiente se debe garantizar la
trazabilidad de la encomienda, al momento del mensajero encontrar la
dirección se dispone a entregar o devolver el paquete o servicio.
Figura 5. Endpoint de Comunicación
Fuente: GREGOR, Hohpe, BOBBY Woolf enterprise integration patterns:
designing, building, and deploying messaging solutions. 1 ed. E.U: 2003. p.95
2.7 BUS DE MENSAJERÍA O ESB
Una vez entendido cómo funciona la mensajería en conjunto con el Endpoint se
procede a explicar que es un bus de servicio, como su palabra lo dice es una
herramienta que permite trasladar de un punto a otro la información.
Ejemplo un bus de servicio público donde ingresan personas que tienen
diferentes idiomas, ideologías pero su finalidad es la misma llegar al punto de
destino en un tiempo determinado, una parada en específico. Gracias al bus de
servicio público las personas llegan a tiempo a su destino logrando su objetivo
que es llegar a su destino final, desde un destino origen.
En sistemas un bus de integración de servicios es un conector de aplicaciones
que se encarga de comunicar, transmitir, conectar, transformar la información a
partir de la sincronización asíncrona de servicios, dicha sincronización se
realiza mediante servicios expuestos en protocolos HTTP por medio de
mensajería de servicios web REST con formato JSON.
La ventaja de un bus de servicio es la combinación de mensajería que permite
que diferentes sistemas se comuniquen a través de un conjunto compartido de
recursos. La estructura middleware de conexión permite conexiones entre
aplicaciones con el bus de mensajes y así trabajar juntos utilizando mensajería.
Figura 6. Bus de mensajería o ESB
Fuente: GREGOR, Hohpe, BOBBY Woolf enterprise integration patterns:
designing, building, and deploying messaging solutions. 1 ed. E.U: 2003. p.137
3. METODOLOGÍA
En este capítulo se describe de forma detallada la manera a desarrollar la
aplicación para cumplir con el alcance del proyecto.
El proyecto está elaborado bajo la metodología ágil Scrum lo que permite
trabajar colaborativamente en equipo, se realizan cuatro entregas o Sprint
parciales, sujetos a cambios ligados al alcance y desarrollo del bus de
servicio flexible.
El cronograma de actividades se realiza mediante la aplicación Trello lo que
permite dar seguimiento de las tareas, mejor organización en el estado del
proyecto por semana, dado que el dayli se realiza semanalmente donde se
analiza, avance de desarrollo, ejecución de casos de prueba y validación
por Sprint.
3.1 FASE UNO
Inicialización del proyecto, se analiza lógica de negocio, se evalúan
solicitudes de servicios web REST con formato JSON dado que son mejor
alternativa a los servicios para el bus de servicio flexible.
3.1.1 FASE DOS
Análisis, diseño y construcción de la aplicación realizando la integración con
los diferentes componentes que interactúan con el ESB.
Se define la arquitectura inicial, el esquema de clases, la infraestructura,
análisis de los componentes y los requisitos técnicos a utilizar en el bus de
servicio flexible.
Se validan los componentes establecidos para realizar la instalación de los
objetos que harán parte del bus de servicio flexible. Se establecen las
siguientes herramientas para el desarrollo del ESB:
IDE: Eclipse.
Lenguaje de Programación: Java.
Servicio de bus de datos Apache: camel
Contenedor de aplicaciones: Servicemix.
Base de datos: mongodb.
Active MQ
3.1.2 FASE TRES
Pruebas
Analizar mediante un software JMETER y/o balanceadores la cantidad de
peticiones que se le realizarán a la aplicación en un rango de tiempo
específico.
Ejecutar las pruebas correspondientes al bus de servicio flexible.
3.1.3 FASE CUATRO
Implementación.
Entrega final del desarrollo y sustentación del ESB.
3.2 DISEÑO METODOLÓGICO.
Se desea integrar esta solución en un restaurante bar con varias sedes, donde
se requiere integrar tres aplicaciones que se usan en paralelo para el manejo
contable, administrativo, y de gestión de los diferentes locales de la franquicia.
La aplicación está segmentada en subsistemas que funcionan de la siguiente
manera:
La primera aplicación está instalada y configurada en cada una de las
terminales del bar, para realizar las nota pedidos y generar la correspondiente
facturación de cada nota pedido, almacenando al detalle cada producto de
dichas nota pedido.
La segunda aplicación contiene al detalle la información de las ventas que se
realizaron durante el día de cada una de las terminales de la franquicia,
generando un reporte de tipo inventario que contiene cada uno de los
productos e ítems que se encuentran disponibles y/o faltantes para dar
continuidad con la operación para cada una de las sedes.
La última aplicación se encarga de la administración de cada uno de los
restaurantes, generando un reporte donde se totaliza las ventas por cada sede,
total ventas de cada producto, enviando alertas sobre la trazabilidad de
promedio total de ventas diario, semanal y mensual con base en la
información que se alimenta de las otras dos aplicaciones.
El problema actual por la que dicha franquicia desea reestructurar e innovar
sistematizando la comunicación de la información mediante un desarrollando
de distribución limitado de aplicaciones diseñadas a la medida. Durante el
proceso anteriormente se ingresaba la información manualmente a las demás
aplicaciones origen a la aplicación destino ocasionando doble trabajo y pérdida
de tiempo por parte del área comercial de la cadena de restaurantes, se
propone implementar un bus de servicios flexible que almacene, extraiga y
cargué la información de las tres aplicaciones volviendo un proceso
automatizado que transfiera la información de las tres aplicaciones a un solo
servidor.
4. DESARROLLO METODOLÓGICO
En este capítulo se describe de forma detallada a desarrollar la aplicación para
cumplir con el alcance del proyecto en cuanto a requerimientos funcionales, no
funcionales partiendo de las historias de usuario, definiendo atributos de
calidad, arquitectura de la solución y casos de prueba.
4.1 DEFINICIÓN Y ESPECIFICACIÓN DE REQUERIMIENTOS
4.1.1 REQUERIMIENTOS FUNCIONALES
4.1.2 DELIMITAR COMPONENTES DE INTEGRACIÓN DE MENSAJERÍA.
Esta historia se relaciona con el desarrollador. En la tabla número uno se
describe la historia de usuario definición de componentes de mensajería.
4.1.2 DELIMITAR COMPONENTES DE INTEGRACIÓN DE MENSAJERÍA.
Delimitar componentes de Integración de mensajería
Como desarrollador deseo diseñar y desarrollar los diferentes componentes que harán parte del despliegue del bus de servicio flexible, dichos componentes necesarios para integrar con los objetos de cada una de las aplicaciones del negocio.
Condiciones de Satisfacción
Validar los componentes establecidos en la metodología para realizar el modelo de objetos y componentes que harán parte del bus de servicio flexible para la integración de mensajería.
Tabla 1. Delimitar componentes de Integración de mensajería.
4.1.3 DEFINIR LÓGICA DE NEGOCIO
Esta historia se relaciona con el usuario. En la tabla número dos se describe la
historia de usuario donde se define la lógica de negocio para la integración de
mensajería con el ESB flexible.
Definir lógica de negocio.
Como usuario deseo realizar el análisis de lógica de negocio, para que la información, en un proceso detallado de un modelo conceptual describa cómo interactúa el bus de servicio flexible con cada una de las aplicaciones a desplegar.
Condiciones de Satisfacción
Para el éxito de este requerimiento se deben tener avaladas los criterios de aceptación del negocio donde contiene al detalle la información de cada aplicación.
Tabla 2. Definir lógica de negocio
4.1.4 DESARROLLAR LOS CANALES DE MENSAJERÍA QUE CONECTA
CON LAS APLICACIONES.
Esta historia se relaciona con el Desarrollador. En la tabla número tres se
describe la historia de usuario donde se define los canales de mensajería que
se conectan con el ESB flexible.
Desarrollar los canales de mensajería que conecta con el ESB
Como desarrollador deseo construir los canales que conectan las aplicaciones con la mensajería de cada una de las aplicaciones.
Condiciones de Satisfacción
Si un canal de mensajes y la aplicación tiene datos para transmitir o datos que desea recibir deberá usar un canal. El desafío está en que canal usar para transmitir y recibir dicha información.
Tabla 3. Construcción de canales de mensajería que se conecta con el ESB
4.1.5 CREACIÓN DE MENSAJES DE EJECUCIÓN.
Esta historia se relaciona con el Desarrollador y el Usuario. En la tabla número
Cuatro se describe la historia de usuario donde se definen los mensajes que se
mostraran con en el resultado de cada ejecución.
Desarrollar Mensajes de prueba y posibles mensajes que se integran con la aplicación
Como desarrollador deseo programar los mensajes que se mostraran con cada una de las ejecuciones del ESB, dichos mensajes deben ejecutarse en dos etapas. Etapa Uno: Mensajes de prueba donde se analiza el comportamiento de los mensajes Rest, soporte de cantidad de peticiones que es capaz de procesar mediante servicios Web. Etapa Dos: Mensajes de servicio de web mediante peticiones Rest con la capacidad de traer data con las posibles integraciones que se van a realizar.
Condiciones de Satisfacción
Como usuario se da el avala de los mensajes mostrados y el desarrollador requiere que los mensajes para esta aplicación sean acorde con las peticiones del servicio.
Tabla 4. Creación de mensajes de ejecución
Esta historia se relaciona con el Desarrollador. En la tabla número Cinco se
describe la historia de usuario donde se define la construcción de conectores y
mediadores para el manejo de las interacciones entre servicios, aplicaciones e
instancias del ESB.
Construir Conectores y mediadores para el manejo de las interacciones entre servicios, aplicaciones e instancias del ESB.
Como desarrollador deseo programar los conectores que se encargan de integrar las aplicaciones con los mensajes generados en el ESB flexible.
Condiciones de Satisfacción
Como desarrollador se requiere validar los conectores que debe servir de puente entre el conector y mensaje de manera que se realice el paso de la información de manera adecuada minimizando la pérdida de mensajes.
Tabla 5. Construcción de conectores y mediadores para el ESB flexible.
4.1.6 CONSTRUIR ENRUTADORES QUE SE INTEGRAN CON EL ESB.
Esta historia se relaciona con el Desarrollador. En la tabla número Seis se
describe la historia de usuario donde se define la construcción de enrutadores
de mensajería para el ESB flexible.
Construir enrutadores que se integran con el ESB
Como desarrollador deseo programar los enrutadores que se encargan de direccionar los mensajes a los diferentes destinos de los servicios a exponer. Garantizando los mensajes y las lógica de las rutas que contiene cada mensaje.
Condiciones de Satisfacción
Como desarrollador se requiere garantizar el intercambio de datos, enviando los datos a través de un canal encargado de enrutar los mensajes que se conectan con el ESB.
Tabla 6. Construir enrutadores que se integran con el ESB
4.1.7 CONSTRUIR UN MÉTODO DE TRANSFORMACIÓN DE MENSAJES
PARA EL ESB FLEXIBLE.
Esta historia se relaciona con el Desarrollador. En la tabla número Siete se
describe la historia de usuario donde se define la construcción del método
transformación de mensajería para el ESB flexible.
Construir un método de transformación de mensajes que se integran con el ESB.
Como desarrollador deseo unificar la información para ello se requiere la transformación de mensajes a un lenguaje general que sea capaz de entender las personas y el sistema
Condiciones de Satisfacción
Como desarrollador se debe garantizar que dicha transformación realice las validaciones de los mensajes en su formato origen REST y el mapeo sea correspondiente al origen del mensaje. Tabla 7. Construir un método de transformación de mensajes para el ESB flexible.
4.1.8 CONSTRUCCIÓN DEL ENDPOINT PARA EL ESB FLEXIBLE.
Esta historia se relaciona con el Desarrollador. En la tabla número Ocho se
describe la historia de usuario donde se define la construcción del EndPoint
Construir EndPoint
Como desarrollador deseo programar y construir el endpoint que es el encargado de interactuar con el sistema de mensajería siendo el que expone el servicio o mensaje a ser consultado por el servicio web.
Condiciones de Satisfacción.
Como desarrollador se requiere definir y garantizar las rutas DSL donde normalmente se asocia una URL o dirección donde se expone el servicio web mediante peticiones Rest.
Tabla 8. Construcción del EndPoint para el ESB Flexible
4.1.9 DEFINIR LA COMUNICACIÓN ASÍNCRONA.
Esta historia se relaciona con el Desarrollador. En la tabla número Nueve se
describe la historia de usuario donde se define la construcción Comunicación
asíncrona de mensajería para el ESB.
Desarrollar Comunicación Asíncrona en mensajería
Como desarrollador deseo construir la comunicación de mensajería asíncrona ya que el mensaje se establece en dos o más puntos de conectividad en tiempo diferente y localización en lugares diferentes.
Condiciones de Satisfacción
Como desarrollador se debe garantizar que el remitente no tiene que esperar que el receptor reciba el mensaje, dado que se tiene un sistema de colas donde el primero en entrar es el primero en salir.
Tabla 9. Definir tipo de comunicación asíncrona.
4.1.10 DEFINIR LAS HERRAMIENTAS PARA LA CONSTRUCCIÓN DEL ESB
FLEXIBLE
Esta historia se relaciona con el Desarrollador. En la tabla número Diez se
describe la historia de usuario donde se define las herramientas para la
construcción del ESB flexible.
Mapear herramientas para construcción del ESB
Como desarrollador deseo saber que herramientas o software se requiere para desarrollar construir el bus de servicio.
Condiciones de Satisfacción
Como desarrollador se debe garantizar el uso de los siguientes componentes para el éxito de la solución:
IDE: Eclipse.
Lenguaje de Programación: Java.
Servicio de bus de datos Apache: camel
Contenedor de aplicaciones: Servicemix.
Base de datos: Mongodb.
Active MQ.
Tabla 10. Definir las herramientas para la construcción del ESB flexible
4.1.11 CONSTRUIR EL BUS DE SERVICIO FLEXIBLE.
Esta historia se relaciona con el Desarrollador. En la tabla número Once se
describe la historia de usuario donde se construye del ESB flexible.
Construir el Bus de Servicio flexible
Como desarrollador deseo construir - desarrollar el bus de servicio flexible utilizando los conectores y mediadores ya desarrollados y definidos.
Condiciones de Satisfacción
Como desarrollador deseo garantizar la herramienta de conectividad de aplicaciones que lleva como nombre bus de servicio flexible garantizando los puntos de conexión entre el bus y la mensajería de aplicaciones.
Tabla 11. Construir el Bus de Servicio flexible
4.1.12 INTEGRAR EL BUS DE SERVICIO FLEXIBLE CON LA MENSAJERÍA
DE APLICACIONES.
Esta historia se relaciona con el Desarrollador. En la tabla número Doce se describe la
historia de usuario donde se integra el Bus de servicio flexible con la mensajería de
aplicaciones
.
Integrar el Bus de servicio flexible con la mensajería de aplicaciones
Como desarrollador deseo integrar el bus de servicio de flexible, con el servicio web a exponer por medio de protocolo HTTP, este servicio debe estar en la capacidad de responder el mensaje con las peticiones realizadas.
Condiciones de Satisfacción
Como desarrollador debo garantizar el servicio web expuesto y que el flujo de mensajería responsa con las respuestas configuradas satisfactoriamente.
Tabla 12 .Integrar el Bus de servicio flexible con la mensajería de aplicaciones
4.1.13 CONSTRUIR MÓDULO DE AUDITORÍA.
Esta historia se relaciona con el Desarrollador. En la tabla número Trece se
describe la historia de usuario donde se define la construcción del módulo de
auditoría para el ESB flexible.
Desarrollar módulo de auditoría.
Como desarrollador y se debe realizar en el modelo de datos una tabla con nombre auditoría, que es la encargada de llevar registro de todas las transacciones, operaciones y trazabilidad de procesos que intervienen con la mensajería en la integración del bus de servicio flexible.
Condiciones de Satisfacción
La tabla auditoría es creada exitosamente registrando las transacciones en cada operación que es realizada en el Bus de servicio.
Tabla 13. Construcción del módulo de auditoría
4.1.14 CONSTRUIR EL MÓDULO DE TRAZABILIDAD
Esta historia se relaciona con el Desarrollador. En la tabla número Catorce se
describe la historia de usuario donde se define la construcción del módulo de
trazabilidad para el ESB flexible.
Desarrollar trazabilidad de la aplicación.
Como desarrollador deseo construir un registro de actividades que almacene en un archivo plano, todas las incidencias, errores, transacciones que se realicen al servicio web que integra al bus de servicio.
Condiciones de Satisfacción
Registrar las incidencias y trazabilidad en un archivo plano en modo error.
Tabla 14. Construcción del módulo de trazabilidad.
4.1.15 CONSTRUIR EL MÓDULO DE SEGURIDAD.
Esta historia se relaciona con el Desarrollador. En la tabla número Quince se
describe la historia de usuario donde se define la construcción del módulo de
Seguridad para el ESB flexible.
Desarrollar el módulo de seguridad
Como desarrollador deseo construir el módulo de seguridad de la aplicación que permite autenticar los usuarios finales que serán administradores de la aplicación.
Condiciones de Satisfacción
Otorgar un código de autorización generado con UUID, que se le otorga a las entidades o aplicaciones que van a consumir los servicios expuestos del bus de servicios flexible.
Tabla 15. Construcción del módulo de Seguridad para el ESB flexible
4.1.16 CONSTRUIR EL MÓDULO DE ERRORES
Esta historia se relaciona con el Desarrollador. En la tabla número Dieciséis se
describe la historia de usuario donde se define la construcción del módulo de
errores del sistema para el ESB flexible.
Desarrollar Estructura de los Errores del Sistemas
Como desarrollador deseo construir el módulo de los errores del sistema, su función es la captura de todos los errores de la aplicación, arrojando una estructura del sistema para lograr una mejor revisión de la trazabilidad de errores.
Condiciones de Satisfacción
En la trazabilidad de errores validar, la cantidad de fallos que registre el bus de datos de la aplicación, cuando el flujo de mensajería no es el acorde con el flujo esperado.
Tabla 16. Construcción del módulo de Seguridad para el ESB flexible
4.1.17 CONSTRUIR CASOS PRUEBAS
Esta historia se relaciona con el Desarrollador. En la tabla número Diecisiete se
describe la historia de usuario donde se define la construcción de Casos
pruebas para el ESB flexible.
Entrega de documento con Casos de prueba
Como desarrollador deseo construir el documento de escenarios de casos de prueba, identificando el escenario, funciones, descripción, criterios de aceptación, criterios de falla, precondiciones y flujos de pruebas para el ESB.
Condiciones de Satisfacción
Como desarrollador deseo garantizar la entrega del documento de set de pruebas con los casos de prueba para el bus de servicio que cumpla con los requerimientos funcionales y no funcionales.
Tabla 17. Construcción de Casos pruebas para el ESB flexible
4.1.18 ENTREGA DE PRODUCTO
Esta historia se relaciona con el Desarrollador. En la tabla número dieciocho se
describe la historia de usuario donde se hace entrega de producto o el ESB
flexible.
Entrega de producto
Como desarrollador deseo entregar el desarrollo con el producto final que contiene el bus de servicio flexible que está en la capacidad de integrar hasta tres aplicaciones. En la entrega se Incluyendo la documentación, set de pruebas, manual y documento con errores conocidos.
Condiciones de Satisfacción
Como desarrollador deseo garantizar la entrega del producto final satisfactoriamente con los estándares de calidad, validando el correcto funcionamiento del ESB y sus componentes.
Tabla 18. Entrega de producto
4.2 REQUERIMIENTOS NO FUNCIONALES
4.2.1 ATRIBUTOS DE CALIDAD
4.2.1.1 Disposición
Además de la flexibilidad que ofrece el desarrollo del bus de servicio, se pensó
en la calidad que ofrece el ESB. Se desea garantizar la persistencia y
confiabilidad de la información, por otro lado la construcción de diferentes
componentes que están la capacidad de almacenar datos.
La parte transaccional cuenta con una tabla auditoría con la capacidad de
procesar y almacenar todo el flujo de procesos realizado dentro del Bus de
servicios, para garantizar la seguridad de la información, así mismo dejar una
buena trazabilidad de todos los movimientos realizados en el entorno que
ofrece el bus de servicio.
4.2.1.2 Seguridad
La seguridad se pensó para la fase uno, dicha fase contempla con un código
de autorización generado con UUID, que se le otorga a las entidades o
aplicaciones que van a consumir los servicios expuestos del bus de servicios
flexible.
Este código se guarda en un archivo de propiedades, junto con la información
de la entidad o aplicación que esté consumiendo el servicio. El sistema verifica
que el código asignado ingresado en el servicio exista en el archivo de
propiedades, si existe, da la autorización para el consumo del servicio, si no
niega el ingreso a la aplicación.
4.2.1.3 Auditoría
Para el módulo de auditoría, se tiene una colección en la base de datos, donde
se guardarán los registros de cada uno de los consumo del servicio. Los datos
que se almacenan son los siguientes para la tabla auditada:
Fecha del consumo
Nombre de la aplicación que se consumió
Servicio consumido
Entrada
Salida
El código de seguridad asignado en el bus de servicio, se guarda
automáticamente y se asigna a la entidad o aplicación que está
consumiendo el servicio.
4.2.1.4 Trazabilidad
La trazabilidad o secuencia de sucesos es donde se almacenan todos los
eventos que se generan en el bus de servicio flexible, se realiza por medio de
mensajes en un archivo plano denominado log.
Estos mensajes se disparan durante todo el ciclo del bus de servicio, validando
el estado de la integración de los mensajes, flujo de mensajería, tipo de
respuestas o peticiones con mensajería.
Dicha trazabilidad arroja tres tipos de log, que se categorizan según el evento o
suceso ocurrido que son:
SEVERE, son para logs de errores, si sale algún error en el sistema, el log
lo muestra en este nivel.
WARN, son para los logs de advertencia.
INFO, son para los logs informativos.
4.2.1.5 Confiabilidad
Hablando en un ambiente de desarrollo, con suficiente presupuesto, se piensa
en una infraestructura, con dos servidores que contengan el mismo bus de
servicios funcionando paralelamente gestionando por un balanceador de
cargas.
El balanceador de cargas es el encargado de validar el estado de los
servidores mediante parámetros que el servidor envía a cada uno de los
servidores, dichos parámetros son petición entrantes al bus de servicio desde
un servidor externo, lo que significa que dependiendo del servidor y la cantidad
de peticiones entrantes de carga que tenga en el momento, el balanceador se
encarga de direccionar a cada servidor dependiendo la cantidad de solicitudes
de cada bus de servicio. Esto nos permite tener un bus de servicios en alta
disponibilidad (Ver imagen modelo de despliegue).
Además de la infraestructura, se debe pensar en la confiabilidad de los datos,
surge una pregunta, ¿cómo se va a asegurar que no haya pérdida de datos
durante la integración de los servicios? Para solucionar esto, se pensó en dos
capas de seguridad.
Primera, dado el caso de producirse un error y no poder transportar la
información, se envía la información a un gestor de colas ActiveMQ, el cual va
a tener la información guardada, para hacer una cierta cantidad de reintentos
de envío con esta información para poder transmitir los datos cuando sea
posible.
Segunda si por algún motivo llega a fallar el gestor de colas, no se puede subir
la información al gestor de colas, entonces se envía la información a la base de
datos, en una colección de errores pendientes por reintento.
4.2.1.6 Manejo de errores
Se dividieron los 1errores en varios tipos:
Primer tipo de error, conocido como propios del protocolo http, ya que para esta
fase uno, el bus de servicio sólo acepta protocolos http, lo cuales usarán los
mismo códigos que usa el protocolo http.
Segundo tipo de error, son los errores arrojados por los servicios que consume
el bus, estos errores, son los mismo errores arrojados por los servicios y será la
respuesta del bus de servicios.
Tercero los errores propios del bus de servicio, lo cuales se dividen en 2
niveles: 1000, 2000:
Los errores de tipo 1000: son los errores del desarrollo del bus, bugs que se
hayan pasado por alto durante el desarrollo.
Los errores de tipo 2000: son errores de conectividad, ya sea a la base de
datos, al gestor de colas o a los servicios que se van a consumir.
1 Para más información sobre los códigos de errores ver el anexo Documento de errores (archivo de configuración)
Figura 7. Módulo de Error
Fuente: Sebastian Ramírez – Jhon Guanume
4.2.1.7 Despliegue
Para el despliegue del bus de servicio flexible, se usa Servicemix, el cual es un
contenedor de aplicaciones de JBOSS, que reconoce los proyectos
desarrollados en Apache Camel y los ejecuta.
En este contenedor se instalan todos los componentes necesarios para el
funcionamiento del bus, como ActiveMQ, CXF, Driver de base de datos, etc.
También contiene los archivos de propiedades y logs que usará el bus de
servicios.
4.2.1.8 Mantenibilidad
Dado que el sistema utiliza componentes OpenSource, cada componente
puede ser libre de ser actualizado a la medida de cada herramienta, el
proveedor ofrece las actualizaciones a de su software, es el usuario final es
quien toma la decisión de si realizar dicha actualización.
El sistema va a tener una estructura, con la cual, si se requiere integrar
aplicaciones lo puede realizar directamente con el personal encargado de
administrar la aplicación, ya que se realiza entrega de la línea base totalmente
comentariada para las personas que no entiendan mucho de buses de
servicios tenga la capacidad de ingresar al código fuente, solo sea reemplazar
y ejecutar los cambios en el código fuente.
4.2.2 Rendimiento
El bus de servicio flexible realizando sus respectivas validaciones en cuanto a
funcionalidad, ejecución de procesos, el tiempo máximo de ejecución de estos
procesos no debería ser superior a 0.6 segundos.
El tiempo de respuesta depende del consumo de cada aplicación por lo tanto el
tiempo de respuesta de variación entre la aplicación y el tiempo de respuesta
en procesamiento no debe ser mayor a 0.6 segundos.
4.3 ARQUITECTURA DE LA SOLUCIÓN
4.3.1 DISEÑO DE COMPONENTES ARQUITECTURA DE INTEGRACIÓN
El presente capítulo describe la arquitectura de componentes propuesta para
realizar la integración de servicios web por medio de un ESB flexible, para esta
versión se realiza la entrega 1.0 cumpliendo con los requerimientos propuestos
en el trabajo de grado desarrollando un Bus de Integración flexible, a futuro se
pretende el mejorando de escenarios presentados en la actualidad.
Este diseño busca definir dentro de la arquitectura de integración de
aplicaciones los principios fundamentales de la Arquitectura Orientada a
Servicios Rest, con arquitectura de Micro servicios, con el fin de apoyar desde
la tecnología los objetivos de negocio.
El Modelo de Arquitectura también define el comportamiento de cada uno de
los componentes y la base de datos para resolver los escenarios de
integración representativos para el trabajo de grado.
La Arquitectura de componentes define la integración con las diferentes
unidades de negocio como la aplicación del restaurante bar, entre otras. El
modelo contiene el análisis de cada unidad de negocio, en términos de
responsabilidades, comportamiento, y relaciones con otras unidades de
negocio.
4.3.2 ARQUITECTURA PROPUESTA
La arquitectura de referencia de las soluciones define un conjunto de capas,
cada una con características y responsabilidades propias, en cada una de
estas capas está compuesta de módulos que definen capacidades funcionales
o técnicas requeridas por el negocio.
Figura 8. Arquitectura por Capas
Fuente: Sebastian Ramírez – Jhon Guanume
4.3.2.1 Descripción
En esta capa se encuentran los canales consumidores de servicios,
aplicaciones internas que intercambian información con las aplicaciones
backend de la compañía. Estas aplicaciones realizan el consumo utilizando
adaptadores que exponen servicios REST/HTTP, MQ, entre otras.
4.3.2.2 Responsabilidades
Esta capa permite transformar los mensajes de requerimiento en canales de
formato JSON del ESB, enruta los mensajes hacia los componentes de servicio
específicos, gestiona el Timeout de respuesta hacia los canales y gestiona la
respuesta de los servicios específicos hacia los canales.
4.3.3 CAPA DE SERVICIOS
Figura 9. Capa de Servicios
Fuente: Sebastian Ramirez – Jhon Guanume
4.3.3.1 Descripción
En esta capa se encuentran los flujos de requerimiento y respuesta que
realizan la implementación del servicio.
4.3.3.2 Responsabilidades
Esta capa se encarga de implementar la validación, transformación y
enriquecimiento de los mensajes de requerimiento que envían los canales para
integrarse con los backends del negocio, enrutar los mensajes de
requerimiento hacia el backend correspondiente, recibir la respuesta del
backend, gestionar errores de ejecución, técnicos y de negocio que se
presenten.
4.4 MODELO DE DOMINIO
Se hace necesario resaltar la complejidad de conexiones con las que
interactúan las aplicaciones y los servicios entre componentes internos o
externos de una organización. En consecuencia se evidencia múltiples
conexiones, lo que sin duda genera una pérdida en tiempo de respuesta en las
peticiones realizadas al servidor, por otra parte se nota un conflicto entre
aplicaciones, entre nodos de conectividad. En la actualidad un posible ejemplo
de una compañía que no tiene implementado un bus de servicio. Se visualiza
de la siguiente manera.
Figura 10. Modelo de Dominio
Fuente: Sebastian Ramírez – Jhon Guanume
4.5 ARQUITECTURA DE LA SOLUCIÓN.
Se evidencia la independencia de las conexiones entre aplicaciones web, el
bus de servicios, la base de datos, dentro de este marco se visualizan la
reutilización conexiones, un flujo flexible al enrutamiento de los mensajes hacia
el bus de servicio, este a su vez despacha a cada destino los mensajes que
consumirá de cada aplicación de igual manera se evidencia la independencia
con comunicación asíncrona de la mensajería.
Figura 11. Arquitectura de la solución.
Fuente: Sebastian Ramírez – Jhon Guanume
4.6 DESCRIPCIÓN GENERAL Y DETALLADA DE LA ESTRATEGIA DE
SOLUCIÓN
La idea surgió luego de pasar la propuesta de trabajo de grado, una vez
aprobada esta propuesta se dio inicio en el desarrollo, diseño y construcción de
los requerimientos funcionales, no funcionales para la implementación del bus
de servicio flexible. En paralelo se dio inicio con la parte investigativa de las
diferentes herramientas a utilizar. Una vez definidos dichos parámetros se dio
inicio al ciclo de vida del software con la Etapa de:
Iniciación: la cual contempla la definición de los objetivos, alcance del proyecto,
investigación de un bus de servicios, diseño de arquitectura, impacto e
innovación y metodología de ciclo de vida del proyecto.
Elaboración: la cual contempla la redefinición de los objetos, validación de
historias de usuario, definición de la línea base, presentar una arquitectura
propuesta.
Desarrollo o construcción: se empezó desde cero definiendo cada objeto, cada
artefacto a construir, para este desarrollo no se usó ningún bus de servicio
base. La programación se inició desde cero esto con el fin de tener total
libertad además flexibilidad en la construcción de los componentes a utilizar.
De lo anterior expuesto se requiere aprender el funcionamiento de un bus de
servicio flexible con la capacidad de integrarse con aplicaciones externas
mediante mensajería a servicios web con formato REST.
Se optó por programar en el lenguaje JAVA con el framework Apache Camel
en específico Blueprint, el cual es un enrutador de mensajes que ofrece la
facilidad para el traspaso o transferencia de datos en cualquier formato entre
aplicaciones, la ventaja de Blueprint reside en la capacidad de integrar o
soportar múltiples protocolos como (HTTP, HTTPS, ActiveMQ, SMTP, etc.).
Otra ventaja de usar Blueprint es que dentro de sus utilidades se encuentra el
uso de patrones de diseño, integrados a sus herramientas lo cual ofrece una
gran optimización en el proceso de mapeado y en la construcción de nuestro
bus de servicio.
Para almacenar la información tanto de la auditoría, como de la integración de
mensajería, se utilizó una base de datos no relacional en específico MongoDB.
La ventaja de utilizar esta base de datos no relacional se basa en su flexibilidad
al momento de manejar los datos, ya que no se posee atributos específicos al
momento de almacenar la información, no posee relaciones y dependencias
entre los datos.
Está en la capacidad de almacenar cualquier dato independiente del esquema,
en la base de datos MongoDB la información se almacena en un formato
JSON. Dichas ventajas sobre la bases de datos no relacional, fueron perfectas
para el bus de servicios, ya que como se va a integrar con aplicaciones de las
cuales no conoce qué información, parámetros de entrada o salida, entonces
se puede almacenar cualquier tipo de información, sin tener tablas específicas
para dicha información.
Para exponer al mismo tiempo consumir los servicios web, se utilizó la
herramienta CXF, con la cual se obtiene el PATH del servicio que se está
consumiendo. Esta funcionalidad es clave por lo tanto, importante para el
desarrollo de nuestro servicio, la función del componente es utilizar el PATH del
servicio que consume el bus de servicio, el bus realiza validaciones dentro de
su configuración de aplicaciones que tiene definida dentro de los parámetros ya
establecidos, el PATH consume el servicio de la aplicación.
Por lo tanto el bus de servicios queda, con las mismas ventajas de cualquier
otro bus de servicios, pero con la diferencia que el bus, logra integrar
aplicaciones sin un desarrollo extra, es capaz de buscar a qué aplicación
corresponde el servicio que se está intentando consumir, lo consume y
devuelve su respuesta.
4.7 VISTA FUNCIONAL
Figura 12. Flujo de Mensajería
Fuente: Sebastian Ramírez – Jhon Guanume
Figura 13. Flujo de Autenticación
Fuente: Sebastian Ramírez – Jhon Guanume
Figura 14. Flujo Auditoría
Fuente: Sebastian Ramírez – Jhon Guanume
4.7.1 Descripción
En esta capa se encuentran los flujos de agendamiento, generación de
mensajería y enrutamiento de mensajes hacia los componentes específicos.
4.7.2 Responsabilidades
Agenda la ejecución de cada servicio, hace el llamado de la información a las
bases de datos del negocio, genera la mensajería correspondiente y enruta los
mensajes hacia los componentes específicos, recibir la respuesta del backend
para actualizar los estados en la base de datos, gestionar errores de ejecución,
técnicos y de negocio que se presenten.
4.8 VISTA DE DESPLIEGUE.
Figura 15. Vista de despliegue
Fuente: Sebastian Ramírez – Jhon Guanume
4.8.1 Descripción
En esta vista se encuentran las peticiones web, que son enrutadas hacia los
servidores específicos por medio del balanceador
4.8.2 Responsabilidades
Equilibrar la carga enviada a cada servidor distribuyendo la cantidad de
peticiones de servicio web a cada uno de los servidores. Lo que garantiza alta
disponibilidad y desempeño. PROTOCOLO DE ARQUITECTURA
Figura 16. Diagrama de secuencia
Fuente: Sebastian Ramírez – Jhon Guanume
4.8.3 Descripción
En este diagrama se encuentra la interacción, de peticiones web para el flujo
de mensajería del ESB, donde se evidencian los componentes y subsistemas
4.8.4 Responsabilidades
Detallar el proceso mediante el cual una petición web realiza el ciclo por toda el
ESB arrojando los tipos de respuesta esperados.
4.9 HERRAMIENTAS DETALLADAS
Se validan los componentes establecidos para realizar la instalación de
los objetos que harán parte del bus de servicio flexible. Se establecen
las siguientes herramientas para el desarrollo del ESB:
4.9.1 IDE ECLIPSE
Es una plataforma de desarrollo que integra JAVA la cual se compone
de plugins, este software se puede instalar completamente gratis desde
la página web, el componente presenta múltiples herramientas de
desarrollo como de modelado, integración, construcción de entornos.
Es una herramienta muy robusta, que se complementa para
elaboración de trabajos, desarrollo, ejecución y depuración de
aplicaciones en el ámbito profesional.
4.9.2 LENGUAJE DE PROGRAMACIÓN JAVA
Como su nombre lo indica es un lenguaje de programación y una
plataforma informática, dado que en el mercado existen muchas
herramientas desarrolladas bajo este lenguaje se ve la necesidad de
usar dicho lenguaje ya que existen aplicaciones que no funcionan si no
tienen instalados los plugins de JAVA. El lenguaje JAVA tiene su propia
estructura, reglas, donde dentro de su estructura se compone de
paquetes donde se encuentran las clases, dentro de las clases
métodos, variables, constantes etc. Haciéndolo un entorno de
desarrollo amigable para el ingeniero que desea crear sus aplicaciones
4.9.3 APACHE CAMEL
Es un framework de integración de aplicaciones o sistemas permite
establecer reglas básicas sobre objetos java, por medio de URL´s se
conecta directamente con cualquier tipo de transporte o mensajería
como HTTPS, lo que permite definir reglas de enrutamiento y
mediadores apache camel posee una librería con dependencias a
cualquier aplicación java. En específico Blueprint, el cual es un
enrutador de mensajes que ofrece la facilidad para el traspaso o
transferencia de datos en cualquier formato entre aplicaciones, la
ventaja de Blueprint en la capacidad de integrar o soportar múltiples
protocolos como (HTTP, HTTPS, ActiveMQ, SMTP, etc.). Otra ventaja
de usar Blueprint es que dentro de sus utilidades se encuentra el uso de
patrones de diseño, integrados a sus herramientas lo cual ofrece una
gran optimización en el proceso de mapeado y en la construcción del
bus de servicio.
4.9.4 CONTENEDOR DE APLICACIONES SERVICEMIX
Es un contenedor de aplicaciones robusto que integra a apache camel
por medio de mensajería, enrutamiento y patrones de integración
empresarial, lo que permite la conexión con el bus de servicio flexible
mediante peticiones HTTP garantizando la comunicación,
transformación y enrutamiento de la información dando acceso a la
integración entre las diferentes aplicaciones ya instaladas.
4.9.5 BASE DE DATOS MONGODB
Es una base de datos no relacional ni transaccional, lo que significa
que no guarda los datos en registros si no en documentos, estos
documentos son almacenados en un formato JSON. Lo que permite un
mejor rendimiento dado que el formato estándar de este proyecto se
basa en JSON garantiza las necesidades para las aplicaciones web
desarrolladas lo que significa que al momento de realizar alguna
petición el bus de servicio busca en la base de datos el documento
JSON con la información que requiere mostrar al usuario final.
4.9.6 ACTIVEMQ
Es una herramienta de gestión de colas donde se envían peticiones en
cualquier formato texto con la información a procesar en el bus de
servicio, esta herramienta gestiona el flujo de mensajería siendo el
mediador que conecta los mensajes de un lenguaje a otro.
4.10 PRUEBAS
En este capítulo se detallan los casos de prueba que integran el ESB. Enfocado en los casos de
uso e historias de usuario.
4.10.1 Casos de Pruebas
Este capítulo muestra las evidencia de las pruebas hechas al bus de servicio
desarrollado para el trabajo de grado.
Este capítulo se divide en dos partes:
La primera son las pruebas a los servicios externos del ESB, para validar su
funcionamiento.
La segunda son las pruebas del bus integrando las aplicaciones probadas
anteriormente.
Para estas pruebas se usa la herramienta “Postman”, el cual es una extensión
del navegador “google Chrome”. Esta herramienta nos permite consumir
servicios web, en nuestro caso de tipo REST.
Figura 17. Entorno Gráfico herramienta Postman
Fuente: https://www.getpostman.com/
En la parte superior de la herramienta, se elige el método del servicio (POST,
GET, DELETE, PUT, etc.) y se ingresa la url que se va a consumir.
Figura 18. Encabezado del servicio
Fuente: https://www.getpostman.com/
La segunda parte, es donde se colocan los “headers” o encabezados del
servicio. Estos headers no son obligatorios, depende del servicio que se vaya a
consumir.
Figura 19. Cuerpo del servicio
Fuente: https://www.getpostman.com/
La tercera parte, es el “request” o el cuerpo del servicio, ahí va el mensaje que
se le va a enviar al servicio, en nuestro caso es un cuerpo en formato JSON.
Figura 20. Respuesta del servicio
Fuente: https://www.getpostman.com/
Y por último, está la parte de la respuesta del servicio. Es donde nos muestra el
mensaje de respuesta que regresó el servicio luego de consumirlo.
Figura 21. Mensaje de respuesta del servicio
Fuente: https://www.getpostman.com/
4.10.2 PRUEBAS A LAS APLICACIONES EXTERNA
Se tienen 3 aplicaciones externas para estas pruebas, se va a consumir un
servicio de cada aplicación.
4.10.3 Caso de prueba uno facturación
La primera prueba, es para la aplicación de “Facturación”. Se va a consumir el
servicio de “generar factura”, el cual es un servicio POST, que tiene como
entrada un JSON, y responde otro JSON.
Esta aplicación expone sus servicios en el localhost, con el puerto 9091.
Caso de prueba 1 Facturación
Aplicación: Facturación
Operación: Generar Factura
URL: http://localhost:9091/compra/generarFactura
Tipo: REST
Método: POST
Headers: Content-Type: application/json
Cuerpo:
{
"empleado":
{
"id":"cj-00002"
},
"restaurante":
{
"nit":"nit-0001"
},
"items":
[
{
"nombre":"alimento-perro-hills-2kl-
pollo",
"cantidad":100
},
{
"nombre":"coca-cola-zero",
"cantidad":2
},
{
"nombre":"super-ricas-pollo",
"cantidad":1
}
],
"nombresCliente":"Jhon Guanume",
"direccionCliente":"sdsddd",
"numeroCliente":"3164123233241058"
}
Respuesta:
{
"codigo": "eb13c3d6-6084-4703-9317-f057144d8377",
"fecha": "May 2, 2018 7:20:29 PM",
"iva": 0.19,
"empleado": {
"id": "cj-00002",
"nombres": "Ivonne",
"apellidos": "Cano Salazar",
"cedula": "22019320"
},
"restaurante": {
"id": "res-001",
"nombre": "Casa",
"nit": "nit-0001",
"direccion": "calle 32 1-30 local 124-1"
},
"items": [
{
"codigo": "00003",
"nombre": "coca-cola-zero",
"cantidad": 2,
"precio": 2500
},
{
"codigo": "00005",
"nombre": "super-ricas-pollo",
"cantidad": 1,
"precio": 1300
},
{
"codigo": "00006",
"nombre": "alimento-perro-hills-2kl-pollo",
"cantidad": 100,
"precio": 53000
}
],
"nombresCliente": "Jhon Guanume",
"direccionCliente": "sdsddd",
"numeroCliente": "3164123233241058",
"total": 5306300
}
Evidencia:
Tabla 17. Caso de prueba Uno Facturación
4.10.4 Caso de prueba dos inventario
La segunda prueba, es para la aplicación de “Inventario”. Se va a consumir el
servicio de “Eliminar”, el cual es un servicio POST, que tiene como entrada un
JSON, y responde un texto.
Esta aplicación expone sus servicios en el localhost, con el puerto 9092.
Caso de prueba 2 Inventario
Aplicación: Inventario
Operación: Eliminar
URL: http://localhost:9092/inventario/eliminar
Tipo: REST
Método: POST
Headers: Content-Type: application/json
Cuerpo: {
"nombre":"alimento-perro-hills-2kl-pollo",
"cantidad":3
}
Respuesta: OK
Evidencia
Tabla 18. Caso de prueba Dos Inventario
4.10.5 Caso de prueba tres recomendador
La tercera prueba, es para la aplicación de “Recomendador”. Se va a consumir
el servicio de “Insertar Datos”, el cual es un servicio POST, que tiene como
entrada un JSON, y responde con otro JSON.
Esta aplicación expone sus servicios en el localhost, con el puerto 9093.
Caso de prueba 3 Recomendador
Aplicación: Recomendador
Operación: Insertar Datos
URL: http://localhost:9093/recomendador/insertarDatos
Tipo: REST
Método: POST
Headers: Content-Type: application/json
Cuerpo: {
"restaurante":{
"nit":"nit-0001",
"nombre":"Casa"
},
"items":[
{
"nombre":"alimento-perro-hills-2kl-pollo",
"cantidad":1,
"cantidadBodega":802,
"valorVenta":53000,
"valorCompra":1200
}
]
}
Respuesta: {
"mensaje": "Se insertaron los datos correctamente"
}
Evidencia
Tabla 19. Caso de prueba Tres Recomendador
Se integran las aplicaciones al bus de servicios, y se consumen los mismos
servicios pero ya no directamente a las aplicaciones externas, si no, que se
consumen pasando por el bus de servicios.
El bus de servicios expone sus servicios en el localhost y el puerto 9090.
4.10.6 Caso de prueba cuatro generar factura
La cuarta prueba, es para la aplicación de “Facturación”. Se va a consumir el
servicio de “Generar Factura” pasando por el bus de servicios, el cual es un
servicio POST, que tiene como entrada un JSON, y responde con otro JSON.
Caso de prueba 4 Generar Factura
Aplicación: Facturación (Bus de servicios)
Operación: Generar Factura
URL: http://localhost:9090/compra/generarFactura
Tipo: REST
Método: POST
Headers: Content-Type: application/json
Cuerpo:
{
"empleado":
{
"id":"cj-00002"
},
"restaurante":
{
"nit":"nit-0001"
},
"items":
[
{
"nombre":"alimento-perro-hills-2kl-pollo",
"cantidad":100
},
{
"nombre":"coca-cola-zero",
"cantidad":2
},
{
"nombre":"super-ricas-pollo",
"cantidad":1
}
],
"nombresCliente":"Jhon Guanume",
"direccionCliente":"sdsddd",
"numeroCliente":"3164123233241058"
}
Respuesta:
{
"codigo": "eb13c3d6-6084-4703-9317-f057144d8377",
"fecha": "May 2, 2018 7:20:29 PM",
"iva": 0.19,
"empleado": {
"id": "cj-00002",
"nombres": "Ivonne",
"apellidos": "Cano Salazar",
"cedula": "22019320"
},
"restaurante": {
"id": "res-001",
"nombre": "Casa",
"nit": "nit-0001",
"direccion": "calle 32 1-30 local 124-1"
},
"items": [
{
"codigo": "00003",
"nombre": "coca-cola-zero",
"cantidad": 2,
"precio": 2500
},
{
"codigo": "00005",
"nombre": "super-ricas-pollo",
"cantidad": 1,
"precio": 1300
},
{
"codigo": "00006",
"nombre": "alimento-perro-hills-2kl-pollo",
"cantidad": 100,
"precio": 53000
}
],
"nombresCliente": "Jhon Guanume",
"direccionCliente": "sdsddd",
"numeroCliente": "3164123233241058",
"total": 5306300
}
Evidencia
Tabla 20. Caso de prueba Cuatro generar factura
4.10.7 Caso de prueba cinco eliminar
La quinta prueba, es para la aplicación de “Inventario”. Se va a consumir el
servicio de “Eliminar” pasando por el bus de servicios, el cual es un servicio
POST, que tiene como entrada un JSON, y responde con un texto.
Caso de prueba Cinco ELIMINAR
Aplicación: Inventario (Bus de servicios)
Operación: Eliminar
URL: http://localhost:9090/inventario/eliminar
Tipo: REST
Método: POST
Headers: Content-Type: application/json
Cuerpo: {
"nombre":"alimento-perro-hills-2kl-pollo",
"cantidad":3
}
Respuesta: OK
Evidencia
Tabla 21. Caso de prueba Cinco eliminar
4.10.8 Caso de prueba seis recomendador (bus de servicios)
La sexta prueba, es para la aplicación de “Recomendador”. Se va a consumir el
servicio de “Insertar Datos” pasando por el bus de servicios, el cual es un
servicio POST, que tiene como entrada un JSON, y responde con otro JSON.
Caso de prueba 6 Recomendador (Bus de servicios)
Aplicación: Recomendador (Bus de servicios)
Operación: Insertar Datos
URL: http://localhost:9090/inventario/eliminar
Tipo: REST
Método: POST
Headers: Content-Type: application/json
Cuerpo: {
"restaurante":{
"nit":"nit-0001",
"nombre":"Casa"
},
"items":[
{
"nombre":"alimento-perro-hills-2kl-pollo",
"cantidad":1,
"cantidadBodega":802,
"valorVenta":53000,
"valorCompra":1200
}
]
}
Respuesta: {
"mensaje": "Se insertaron los datos correctamente"
}
Evidencia
Tabla 22. Caso de prueba Seis recomendador (bus de servicios)
5. CONCLUSIONES
De lo anterior expuesto en este trabajo de grado es necesario insistir en la
importancia de los buses de servicio para la carrera de ingeniería de sistemas,
a raíz de las evidencias encontradas a lo extenso del este proyecto se valida la
necesidad de montar un bus de servicio que automatice los procesos en las
compañías.
Como resultado cabe sugerir que es una plataforma innovadora en el mercado
de las tecnologías de la información. Dicha plataforma muestra una perspectiva
a un nicho empresarial de acuerdo con el uso de herramientas OpenSource
donde resulta que existe una gran variedad de optimismos herramientas que
son muy flexibles para la estética de quien las desea aprender a explorar. En
cuanto a la ejecución de este proyecto se optó por usar la herramienta Apache
camel a causa de ello se logró el objetivo principal que consiste en desarrollar
en su totalidad un bus de servicio flexible que esté en la capacidad de
integrarse con aplicaciones de otros sistemas.
Al tener un ESB flexible OpenSource permite tener una mejor administración en
el control de los procedimientos que posee una entidad, proporcionando la
gestión necesaria de los procesos entre subsistemas híbridos de la
organización, acoplando las necesidades del cliente según sus requerimientos
cuyo objetivo es integrar aplicaciones dependiendo su funcionalidad, tal es el
caso proyectando los resultados esperados.
En cuanto a la cantidad de servicios que se incorporan en el ESB no tiene
límite dado que por ser desarrollado con componentes OpenSource la
capacidad de librerías son configuradas a medida de la línea base. Lo que
significa que es un proceso a la medida, así mismo cada ESB es totalmente
independiente cuenta con la capacidad de integrarse a cualquier sistema en el
cual se instale. Solo basta cambiar unos parámetros de conectividad muy
básicos, lo que permite una mayor flexibilidad logrando llegar desde la empresa
más pequeña al más grande cabe mencionar que no tiene limitantes en cuanta
infraestructura, lenguaje de programación y gestión de mensajería entre
aplicaciones. No hay que dejar de lado la seguridad, se pensó en una
autenticación personalizada lo que permite al usuario final ser el único que
puede acceder al ESB, por otro lado el costo de y tiempo de implementación es
muy bajo debido a que se utilizan herramientas OpenSource.
El único limitante de esta herramienta es la imaginación, dependiendo de las
necesidades de cada de cada compañía esta herramienta está en la capacidad
de brindar seguridad, integridad, rendimiento, transformación de servicios web
reduciendo el tiempo de implementación entre la comunicación de aplicaciones.
Lo que permite pensar a necesidades a futuro como integración con
dispositivos móviles, análisis en tendencias de datos, solicitudes de peticiones
en múltiples canales donde la integración se basa en procesos de negocio.
6. TRABAJO A FUTURO
Para la fase dos de este proyecto se propone realizar las actividades que no
lograron ser cubiertas a causa de la reducción del alcance, se hace necesario
destacar el tiempo para la ejecución de este trabajo de grado fue limitado para
cumplir la propuesta inicial planteada. Se considera importante continuar con
este trabajo de grado a futuros estudiantes que se encuentren interesados en
seguir este trabajo de grado
Para el desarrollo de bus de servicio flexible se sugiere que la información que
se encuentra almacenada en cada aplicación sea capaz de transmitirse
automáticamente entre sistemas y subsistemas, esto quiere decir que tenga la
flexibilidad de pasar los datos de un servicio a otro sin la necesidad de realizar
un desarrollo o funcionalidad específica para dichos servicios.
Se recomienda aumentar el número de aplicaciones integradas al bus de
servicio flexible según las necesidades de cada compañía, se aspira que el
ESB no tenga un límite aplicaciones por empresa. Por otro lado el ESB debe
estar en la capacidad de operar con cualquier protocolo de transferencia de
información ya sea http, HTTPS, SMTP, mensajes en cola, etc.
Por último, reforzar la seguridad se desea contar con las mínimas condiciones
de seguridad para las integraciones del ESB flexible con las diferentes
aplicaciones. Se plantea tener un mejor repositorio de seguridad esto significa
poder elegir el tipo de seguridad a utilizar, en el modelo actual de seguridad se
utiliza un código UUID creando un token para toda la aplicación, se aspira tener
estándares de seguridad con usuario/contraseña o por certificados.
Como modelo de negocio se recomienda realizar publicidad dando a conocer
esta herramienta donde se ofrezca el ESB flexible en un mercado posicionando
brindando un portafolio de servicio con administración de usuarios, estándares
de calidad de la información promoviendo los lineamientos TI.
BIBLIOGRAFÍA
GREGOR, Hohpe, BOBBY Woolf enterprise integration patterns: designing,
building, and deploying messaging solutions. 1 ed. E.U: 2003. p.60
GREGOR, Hohpe, BOBBY Woolf enterprise integration patterns: designing,
building, and deploying messaging solutions. 1 ed. E.U: 2003. p.103
GREGOR, Hohpe, BOBBY Woolf enterprise integration patterns: designing,
building, and deploying messaging solutions. 1 ed. E.U: 2003. p.85
GREGOR, Hohpe, BOBBY Woolf enterprise integration patterns: designing,
building, and deploying messaging solutions. 1 ed. E.U: 2003. p.95
GREGOR, Hohpe, BOBBY Woolf enterprise integration patterns: designing,
building, and deploying messaging solutions. 1 ed. E.U: 2003. p.137
Herramientas Detalladas todas las herramientas Son OpenSource
IDE Eclipse [en línea]. Bogotá: página oficial de eclipse [Consultado el 13 de
abril de 2018]. Disponible en internet http://www.eclipse.org/downloads/
JAVA [en línea]. Bogotá: página oficial de Java [Consultado el 13 de abril de
2018]. Disponible en internet
https://www.java.com/es/download/faq/whatis_java.xml
Apache Camel [en línea]. Bogotá: página oficial de Apache Camel [Consultado
el 13 de abril de 2018]. Disponible en internet http://camel.apache.org/
Servicemix [en línea]. Bogotá: página oficial de Servicemix [Consultado el 13
de abril de 2018]. Disponible en internet http://servicemix.apache.org/
MongoDB [en línea]. Bogotá: página oficial de MongoDB [Consultado el 13 de
abril de 2018]. Disponible en internet https://www.mongodb.com/
ActiveMQ [en línea]. Bogotá: página oficial de ActiveMQ [Consultado el 13 de
abril de 2018]. Disponible en internet http://activemq.apache.org/
ANEXOS
ANEXO A. Manual de usuario
Este documento pretende dar una guía, para la instalación, configuración y uso
del bus de servicios flexible para el trabajo de grado para la Universidad Piloto
de Colombia
Se crea este manual para dar un mejor manejo de las conexiones y datos, entre
las aplicaciones que consuman estos servicios.
El documento se divide en la parte de instalación, configuración y uso del bus
de servicio.
1. INSTALACIÓN
1.1 INFRACTRUCTURA
A continuación se enumeran las especificaciones recomendadas de
infraestructura que deben tener los servidores que vayan a contener el bus de
servicios en producción. Pero como ya se mencionó, son especificaciones
recomendables, lo que quiere decir, que puede funcionar con otras
especificaciones de infraestructura.
Sistema operativo basado en Linux.
Disco duro de 30GB o más.
Memoria RAM de 16GB o más.
Dos servidores con estas especificaciones
Un balanceador, para controlar la carga de los servidores
1.2 SOFTWARE
Las herramientas que se van a enumerar a continuación, a diferencia del punto
anterior, en este si se debe respectar cada herramienta con la versión exacta.
Se nombrará la herramienta y en seguida se especificará la versión. Si la
versión tiene un “x”, quiere decir que el número que reemplace esa x, puede
ser cualquiera de las versiones que existan para esa herramienta.
Apache Servicemix – 7.0.1
Maven – 3.x
Java – 1.8
MongoDB – Recomendable última versión
Vim o cualquier editor de texto
Para Java, Maven, Vim y MongoDB, si se tiene el sistema operativo basado en
Linux, se puede instalar por medio de comandos en la terminal de Linux o si se
desea, pueden descargar los instaladores de la página oficial de cada
herramienta.
1.3 CONTENEDOR DE APLICACIONES
El contenedor de aplicaciones (Servicemix), es la herramienta que va a
arrancar el sistema, y contendrá todos los componentes necesarios para el
correcto funcionamiento del bus de servicios.
Para la instalación, nos dirigimos a la página oficial de Apache Servicemix
http://servicemix.apache.org/downloads.html, y en la parte de descargas,
buscamos y descargamos la versión mencionada en el punto anterior.
Descomprimimos el archivo descargado y con eso, ya tenemos el contenedor
de aplicaciones instalado.
Para arrancar el sistema, abrimos el terminal de Linux, y nos vamos a la ruta
donde descomprimimos el archivo descargado. Entramos a la carpeta que se
descomprimió e ingresamos al fichero “/bin”. Por último escribimos el comando
“./servicemix” y arrancará el sistema. Si todo se hizo bien se debería ver una
pantalla así:
2. DESPLIEGUE
Para el despliegue del sistema se deben tener los siguientes archivos:
ejb.dynamics-<versión>.jar
modulo.auditoria-<versión>.jar
config.esb.dynamic.properties.cfg
config.esb.security.properties.cfg
Los archivos “.jar”, son los que contienen la aplicación, y los archivo
“.properties.cfg”, son los archivos de configuración para lograr integrar los
servicios al bus. Se hablará sobre estos últimos archivos en la siguiente
sección.
Para desplegar los archivos “.jar”, se deben copiar y pegar en la carpeta
“deploy” contenida en la ruta donde se instaló el contenedor de aplicaciones.
Igualmente se deben copiar y pegar los archivo de configuración pero estos
van en la carpeta “/etc” del contenedor de aplicaciones.
Para verificar que los archivos quedaron correctamente desplegados, nos
vamos al terminal donde arrancamos el contenedor de aplicaciones y
escribimos el comando “bundle:list”. Este comando lista todos los componentes
que se tienen instalados en el contenedor de aplicaciones. Ahí debemos ver al
final de la lista dos componentes con estos nombres: “ESB.Modulo.Auditoria” y
“EJB.Dynamics” y si todo salió bien, en la parte izquierda debe decir “Active”, lo
cual nos indica que los sistemas quedaron en un estado activo y listos para
usarse.
ANEXO B. Archivos de configuración
Se tienen dos archivos de configuración “config.esb.dynamic.properties.cfg” y
“config.esb.security.properties.cfg”. El primer archivo contiene las
configuraciones del bus de servicios y el segundo contiene los códigos para la
seguridad.
Las propiedades en estos archivos tienen dos partes, la primera es el nombre
del atributo, por ejemplo “HOST”, y la segunda es el valor del atributo por
ejemplo “localhost”, y están separados por un “=”, por lo tanto el ejemplo
quedaría así: “HOST=localhost”.
Los nombres de los atributos para la configuración del bus no deben ser
tocados a menos que se hagan cambios en el desarrollo del bus, de lo
contrario se deben dejar exactamente como están en el archivo. Los valores de
los atributos si son variables, se debe colocar dependiendo de la información
solicitada.
1. CONFIGURACIÓN DEL BUS DE SERVICIOS
Para configurar el bus de servicios se debe abrir el archivo
“config.esb.dynamic.properties.cfg” con cualquier editor de texto. Dentro del
archivo estarán los atributos necesarios para el funcionamiento del bus y
encima de cada atributo se encuentra una descripción detallada sobre qué
valor debe tener cada uno de estos atributos.
2. ARCHIVO DE SEGURIDAD
El archivo de seguridad tiene una funcionalidad muy parecida al archivo de
configuración del bus. Este archivo también tiene el nombre de un atributo y el
valor, pero en este caso, el nombre del atributo va a ser variable, ya que, el
nombre del atributo será un código recomendable sea un código UUID, el cual
será entregado a la entidad, persona, etc. Que se quiera tenga acceso a los
servicios integrados en el bus, y como valor del atributo, será el nombre de la
entidad, persona, etc. Al cual se le otorgó el código.
3. USO DEL BUS DE SERVICIOS
No se tiene una forma general para consumir los servicios por medio del bus,
ya que este depende del servicio externo. Esto quiere decir que la forma de
consumir el servicio va a ser muy similar a como se consume el servicio
externo, con la diferencia de que el host para consumir ya no va a ser del
servicio externo si no del bus de servicios, y si se configuró que el bus tenga
seguridad, se debe poner un atributo extra en el “header” de la petición, el cual
es “Cod-Security” y tendrá como valor el código explicado en la sección anterior
para dar acceso a los servicios.
ANEXO C. Errores contemplados dentro del programa
A lo largo del desarrollo y programación del bus de servicios es importante
contemplar la mayoría de los errores posibles, solucionarlos y generar las
respectivas correcciones que se requieran en cada caso.
No obstante, existen una serie de errores que pueden no encontrarse dentro
del proceso o que incluso, pueden generarse una vez finalizada la etapa de
programación, para ello el presente documento pretende dar cuenta de este
tipo de errores que pueden surgir, explicar cuál es la razón por la que tienen
lugar, identificar el error y facilitar el manejo del mismo.
En ese orden de ideas, el listado es el siguiente:
1. Error 1000: Corresponde a la familia de error de bugs del sistema, son
errores no esperados, y por ende, no capturados. El mensaje que este tipo
de error puede arrojar depende del sistema. Todos los errores de este tipo
tendrán este código. De igual manera mostrarán un mensaje en formato
JSON con 3 atributos: 1) el error que indica si el mensaje mostrado
corresponde a la respuesta de un error (puede ser “true” en caso de que
sea error o “false” si no lo es) 2) El código del error. 3) Un mensaje que es
generado por el bus de servicio para cada código
2. Error 2000: Hace parte de la familia de errores de conectividad del sistema.
Este tipo de error se mostrará como un mensaje en formato JSON con 3
atributos: 1) el error que indica si el mensaje mostrado corresponde a la
respuesta de un error (puede ser “true” en caso de que sea error o “false” si
no lo es) 2) El código del error. 3) Un mensaje que es generado por el bus
de servicio para cada código
3. Error 2001: Se trata de un error de conectividad a la base de datos principal
del sistema
4. Error 2002: Consiste en un error de conectividad al ActiveMQ
5. Error 2003: Se refiere a un error de conectividad entre las aplicaciones de
integración.
6. Error 404: Este tipo de error aparece cuando no se encuentra un servicio.
Se mostrará como un mensaje en formato JSON con 3 atributos: 1) el error
que indica si el mensaje mostrado corresponde a la respuesta de un error
(puede ser “true” en caso de que sea error o “false” si no lo es) 2) El código
del error. 3) Un mensaje que es generado por el bus de servicio para cada
código
7. Error 401: Cuando no hay autorización para consumir el servicio. Este tipo
de error se mostrará como un mensaje en formato JSON con 3 atributos: 1)
el error que indica si el mensaje mostrado corresponde a la respuesta de un
error (puede ser “true” en caso de que sea error o “false” si no lo es) 2) El
código del error. 3) Un mensaje que es generado por el bus de servicio para
cada código
8. Adicional a los anteriores errores, existen otros dos tipos que son de http y
los errores de las aplicaciones de integración, estos, no son controlados, es
decir que, si alguno de estos errores aparece, este mismo se muestra como
respuesta del servicio expuesto por el bus.