INTEGRACIÓN DINÁMICA DE APLICACIONES CON SERVICIOS ...

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.3 Descripción ............................................................................................... 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



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



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



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



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



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.


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.


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.


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.


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.


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


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.


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.


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.


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.


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.


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


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.


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


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.


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


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.


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.


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.


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


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


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.


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


Figura 13. Flujo de Autenticación


Figura 14. Flujo Auditoría


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


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


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


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


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.

https://www.getpostman.com/

Figura 18. Encabezado del servicio


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


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


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




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.


Caso de prueba 2 Inventario

Aplicación: Inventario

Operación: Eliminar

URL: http://localhost:9092/inventario/eliminar

Tipo: REST

Método: POST


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.


Caso de prueba 3 Recomendador

Aplicación: Recomendador

Operación: Insertar Datos

URL: http://localhost:9093/recomendador/insertarDatos

Tipo: REST

Método: POST


Cuerpo: {

"restaurante":{

"nit":"nit-0001",

"nombre":"Casa"

},

"items":[

{


"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


Cuerpo:

{

"empleado":

{

"id":"cj-00002"

},

"restaurante":

{

"nit":"nit-0001"

},

"items":

[

{


"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


Tipo: REST

Método: POST


Cuerpo: {


"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


Tipo: REST

Método: POST


Cuerpo: {

"restaurante":{

"nit":"nit-0001",

"nombre":"Casa"

},

"items":[

{


"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









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/

http://www.eclipse.org/downloads/

https://www.java.com/es/download/faq/whatis_java.xml

http://camel.apache.org/

http://servicemix.apache.org/

https://www.mongodb.com/

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.

INTEGRACIÓN DINÁMICA DE APLICACIONES CON SERVICIOS ...

Documents

Transcript of INTEGRACIÓN DINÁMICA DE APLICACIONES CON SERVICIOS ...