FACULTAD DE INGENIERIAS Y CIENCIAS AGROPECUARIAS / INGENIERÍA EN SISTEMAS DE COMPUTACIÓN E INFORMÁTICA

Transcripción

1 i FACULTAD DE INGENIERIAS Y CIENCIAS AGROPECUARIAS / INGENIERÍA EN SISTEMAS DE COMPUTACIÓN E INFORMÁTICA INTEGRACIÓN DE SISTEMAS MEDIANTE UN BUS DE SERVICIOS EMPRESARIALES Trabajo de Titulación presentado en conformidad con los requisitos establecidos para optar por el título de Ingeniera en Sistemas de Computación e Informática Profesor Guía Ingeniero Patricio Moreno Autora Verónica Aracely Irigoyen Ruiz Año 2013

2 ii DECLARACIÓN DEL PROFESOR GUÍA Declaro haber dirigido este trabajo a través de reuniones periódicas con el estudiante, orientando sus conocimientos y competencias para un eficiente desarrollo del tema escogido y dando cumplimiento a todas las disposiciones vigentes que regulan los Trabajos de Titulación. Patricio Moreno Ingeniero de Sistemas

3 iii DECLARACIÓN DE AUTORÍA DEL ESTUDIANTE Declaro que este trabajo es original, de mi autoría, que se han citado las fuentes correspondientes y que en su ejecución se respetaron las disposiciones legales que protegen los derechos de autor vigentes. Verónica Aracely Irigoyen Ruiz

4 iv AGRADECIMIENTOS Agradezco a Dios por darme las herramientas necesarias y colmarme de bendiciones al cursar esta carrera universitaria, disfrutando de cada éxito y superando cada fracaso, para concluir con este último escalón que me convertirá en una profesional. Agradezco a mi familia, que ha estado conmigo siempre, impulsándome a ser mejor cada día; sin ellos, jamás hubiera obtenido tantos logros, ni hubiera aprendido de mis errores; gracias por ser mi apoyo en todo momento. Un agradecimiento especial a mis amigos y profesores que de una u otra forma estuvieron a mi lado en el transcurso de esta etapa que está por concluir. Y por último, aunque no menos importante, muchas gracias a mi querido Advance, porque cada una de las personas que conforma esta prestigiosa empresa aportaron para que no me detenga, sea compartiendo sus conocimientos o animándome a seguir con empeño. A todos ellos gracias una vez más por ser una pieza indispensable en mi vida profesional y en mi crecimiento personal.

5 v RESUMEN El presente trabajo de titulación establece una comparación práctica de la funcionalidad de un bus de servicios empresariales, entre las herramientas Oracle Service Bus y Apache Camel, desde el punto de vista de patrones de integración, y adicionalmente se realiza una comparación analítica de otros criterios, definidos en base a las características que ambas herramientas ofrecen. Con este estudio se busca determinar la competitividad que existe entre productos propietarios y de código abierto, debido a que los buses de servicios empresariales se han convertido en una de las soluciones más populares para la problemática de la integración entre diferentes aplicaciones. De acuerdo a las características de las empresas y sus proyectos, estas están en la facultad de decidir qué clase de producto utilizarán de entre las alternativas que el mercado ofrece.

6 vi ABSTRACT This thesis makes a practice comparison about enterprise service bus functionality, among Oracle Service Bus and Apache Camel; it takes into account integration patterns. And an analytical comparison of other relevant criteria, selected based on the characteristics that both tools provide. This study seeks to determine the competitive level between proprietary and open source products, given that enterprise service buses have become one of the most popular solutions to the integration application problem. Depending on the characteristics of a given company and the projects it handles, the company can decide which product to use from the alternatives that the market offers.

7 ÍNDICE 1. CAPÍTULO I. INTRODUCCIÓN ÁMBITO DEL PROBLEMA ALCANCE OBJETIVOS Objetivo General Objetivos Específicos LIMITACIONES CAPÍTULO II. MARCO TEÓRICO INTEGRACIÓN DE SISTEMAS PATRONES DE INTEGRACIÓN Content-Based Router Message Translator Dynamic Router Splitter Aggregator Dead Letter Channel EVOLUCIÓN DE LA INTEGRACIÓN DE SISTEMAS Sistemas Punto a Punto EAI (Enterprise Application Integration) BUS DE SERVICIOS EMPRESARIALES (ESB) HERRAMIENTA ORACLE SERVICE BUS (OSB) HERRAMIENTA APACHE CAMEL CAPÍTULO III. DEFINICIÓN DE CRITERIOS DE COMPARACIÓN CRITERIOS DE COMPARACIÓN CONCEPTOS IMPORTANTES PONDERACIONES CAPÍTULO IV. ESCENARIOS DE TOMA DE DATOS INSTALACIÓN DEL OSB INSTALACIÓN DE APACHE CAMEL DISEÑO DE PRUEBAS... 35

8 Contexto de la Aplicación Recursos Aplicación por patrones Desarrollo de Pruebas Captura de Mediciones CAPÍTULO V. RESULTADOS TIEMPOS DE PROCESAMIENTO CARGA TRANSACCIONAL CALIFICACIONES OTROS CRITERIOS DE COMPARACIÓN COSTOS Oracle Service Bus Apache Camel CAPÍTULO VI. PROTOTIPO CONSTRUCCIÓN PRUEBAS Y RESULTADOS Cliente NORMAL Cliente PREFERENTE CAPÍTULO VII. CONCLUSIONES Y RECOMENDACIONES REFERENCIAS... 95

9 ANEXOS ANEXO 1: ENCUESTAS ANEXO 2: GUÍA DE INSTALACIÓN DE OSB ANEXO 3: TIEMPOS DE RESPUESTA ANEXO 4: CARGA TRANSACCIONAL ANEXO 5: DIAGRAMA DE COMPARACIÓN ENTRE ESBS

10 FIGURAS Figura 1: Patrón de integración Content-Based Router... 6 Figura 2: Patrón de integración Message Translator... 7 Figura 3: Patrón de integración Dynamic Router... 8 Figura 4: Patrón de integración Splitter... 9 Figura 5: Patrón de integración Aggregator... 9 Figura 6: Patrón de integración Dead Letter Channel Figura 7: Estructura compleja de una conexión punto a punto Figura 8: Arquitectura tradicional de EAI Figura 9: Diagrama de la estructura de Enterprise Service Bus Figura 10: Diagrama de la arquitectura de Enterprise Service Bus Figura 11: Diagrama de Oracle Service Bus Figura 12: Arquitectura de Oracle Service Bus Figura 13: Diagrama de Apache Camel Figura 14: Vista de alto nivel de los principales conceptos que componen la arquitectura de Camel Figura 15: Arquitectura de los servicios de negocio y lo servicios proxy Figura 16: Ejemplo de la estructura de un archivo CSV Figura 17: Consola Hawtio Figura 18: Ejemplo de la definición de un Web Service Figura 19: Ejemplo de la estructura de un archivo wsdl Figura 20: Ejemplo de archivo XML Figura 21: Ejemplo de la estructura de un archivo xsd Figura 22: Lista de componentes necesarios para la instalación de OSB Figura 23: Proyecto CafeteriaDivisor Figura 24: Diseño del flujo del mensaje en el componente Figura 25: XML de entrada con dos pedidos. (OSB) Figura 26: XML de salida con los dos pedidos Figura 27: Configuración de los componentes split y aggregate Figura 28: XML de entrada con dos pedidos (APACHE CAMEL) Figura 29: XML de salida con los dos pedidos procesados (APACHE CAMEL) Figura 30: Proyecto CafeteriaEBC Figura 31: Diseño del flujo del servicio Figura 32: Diseño del flujo del servicio (ProcesarPedido.proxy) Figura 33: XML de entrada con tres pedidos: Figura 34: XML de salida con los dos Figura 35: Configuración del componente choice Figura 36: XML de entrada con tres pedidos Figura 37: XML de salida con los datos de... 56

11 Figura 38: Componente XQuery (ConfigBusiness.xq) Figura 39: Proxy Service que Figura 40: XML de entrada. Tipo de cliente: Normal y Preferente Figura 41: XML de respuesta. Tipo de cliente: Normal y Preferente Figura 42: Configuración del componente dynamicrouter Figura 43: Servicios disponibles, publicados en Apache Karaf Figura 44: Formulario xml de entrada para ejecutar el caso de Figura 45: XML de respuesta para el caso de prueba de Figura 46: Mapeo de atributos de la estructura no xml a la Figura 47: Proyecto del Figura 48: Flujo del Figura 49: Selección del archivo cvs para ejecutar la prueba de transformación Figura 50: Formulario de respuesta y visualización del archivo xml generado. 66 Figura 51: Archivo cvs: datosnoxml utilizado para la transformación y archivo xml: resp_#.xml generado en la transformación Figura 52: Configuración de las rutas de camel para realizar la transformación cvs-xml. Tc Figura 53: Directorios de entrada y salida con un archivo xml generado Figura 54: archivo cvs y archivo xml con los datos de clientes Figura 55: Proyecto CafeteriaError con Figura 56: Diseño del flujo del mensaje en el Proxy Service (ValidacionErrorPS.proxy) Figura 57: XML de entrada, se presenta el contador de tiempo de espera Figura 58: XML de salida Figura 59: Configuración de la propiedad errorhandlerref Figura 60: XML de entrada con la información Figura 61: XML de salida Figura 62: Consola de JUnit con resultado exitoso de uno de los Figura 63: Consola donde se puede ver los Figura 64: Ruta <camel:from> del Prototipo Figura 65: Rutas: <camel:process>, <camel:setheader> y <camel:simple> del Prototipo Figura 66: Ruta <camel:split> del Prototipo Figura 67: Rutas <camel:choice> y <camel:when> del Prototipo Figura 68: Ruta <camel: dynamicrouter> del Prototipo Figura 69: Resultado de la prueba realizada con el prototipo de un cliente NORMAL Figura 70: Resultado de la prueba realizada con el prototipo de un cliente PREFERENTE Figura 71: Diagrama de comparación de ESBs, según Forrester Wave

12 TABLAS Tabla 1: Estructura de la definición de los patrones de integración Tabla 2: Tabla de calificaciones según el nivel de importancia para obtener las ponderaciones de los criterios de comparación aplicando la matriz de pares.. 29 Tabla 3: Tabla donde se detalla el proceso para calcular las ponderaciones para cada criterio de evaluación Tabla 4: Tabla donde se detalla el proceso para calcular las ponderaciones para cada patrón de integración Tabla 5: Tabla con resultados de ejemplo de la evaluación por criterio entre las herramientas OSB y Apache Camel Tabla 6: Cuadro con resultados finales de ejemplo entre las herramientas Apache Camel y OSB Tabla 7: Estructura del WSDL con la información del cliente y los pedidos Tabla 8: Tabla con los resultados finales de los tiempos de respuesta de cada patrón de integración Tabla 9: Tabla con los resultados finales de los tiempos de carga transaccional para cada patrón de integración Tabla 10: Cuadro de evaluación de los Patrones de Integración con cada herramienta Tabla 11: Resultados finales de la comparación de los Patrones de Integración entre Apache Camel y Oracle Service Bus Tabla 12: Comparación de criterios adicionales para las herramientas Apache Camel y OSB Tabla 13: Resultados de la comparación de los criterios adicionales Tabla 14: Costos de WLS y OSB por procesador Tabla 15: Costos de WLS y OSB por usuario nombrado Tabla 16: Datos de entrada para ejecutar la prueba sobre el prototipo con el tipo de cliente Normal Tabla 17: Datos de entrada para ejecutar la prueba sobre el prototipo con el tipo de cliente Preferente Tabla 18: Resultados de las pruebas unitarias para el Prototipo... 91

13 1 1. Capítulo I. INTRODUCCIÓN 1.1. Ámbito del Problema Cuando la integración de sistemas estaba en auge, los ingenieros especializados realizaban dicha integración de forma manual y generando API's para cada sistema a medida. Con el paso del tiempo y el crecimiento de la tecnología, las aplicaciones se volvían más amplias y complejas. Las empresas se dieron cuenta que en estas integraciones existían patrones; los definieron y desarrollaron para realizar los procesos comunes tomando en cuenta dichos patrones. De esta manera, aparecieron las nuevas tecnologías, pero eran propietarias. Las compañías invertían grandes cantidades de dinero en estas tecnologías y cuando la integración de sistemas se convirtió en un recurso necesario, también en empresas pequeñas y medianas, salieron al mercado nuevas alternativas tecnológicas, pero esta vez, de código abierto, las cuales eran auspiciadas por las mismas empresas logrando solventar sus requerimientos de integración y con menor inversión final sobre el producto. Para este trabajo de titulación se cuenta con el apoyo y la predisposición del distribuidor local, partner de FuseSource (AdvanceConsulting) que facilitará la información referente a Apache Camel, la cual es una de las herramientas que será motivo de estudio. Esta empresa tiene como campo laboral el desarrollo de software a medida y lleva cuatro años en el mercado, realizando proyectos con entidades como: Armada del Ecuador, Secretaría Nacional de Planificación y Desarrollo (SENPLADES), Banco Central del Ecuador (BCE) y Banco Ripley. En la actualidad la gran mayoría de compañías han implementado sistemas automáticos para controlar sus procesos, y las relaciones empresariales han incrementado también en los últimos tiempos. Por esta razón ha surgido la necesidad de que dichos sistemas sean integrados para compartir datos y funcionalidad.

14 2 El mercado de herramientas de integración presenta opciones propietarias y de código abierto, siendo las primeras las que tienen mayor notoriedad en cuanto a eficiencia, por ejemplo Oracle Service Bus; aunque hoy por hoy algunas herramientas de código abierto pueden competir a la par en muchas de sus características y beneficios como Apache Camel. Para demostrar esta hipótesis se elaborará un análisis comparativo de esfuerzos y tiempos de respuesta entre el ESB Oracle Service Bus y el ESB Apache Camel y posteriormente se elaborará un prototipo para integrar dos sistemas utilizando la herramienta que obtenga mejores resultados en la comparación Alcance Este trabajo de titulación tiene como alcance presentar un estudio comparativo entre el ESB propietario Oracle Service Bus y el ESB de código abierto Apache Camel tomando en cuenta criterios importantes basados en los patrones de integración empresarial de mayor aplicación, tales como: enrutamiento de mensajes, enrutamiento basado en contenido, traductor de mensajes, filtro de mensajes, lista de destinatarios, enrutamiento dinámico, divisor de mensajes, agregador de mensajes, ordenamiento de mensajes y canal de DeadLetter; y ciertos patrones exclusivos de las herramientas consideradas. Al realizar este análisis se presentará un cuadro de resultados concluyendo sus beneficios y el nivel de competitividad entre ellos. Adicionalmente se realizará un prototipo de integración entre dos sistemas utilizando una de las tecnologías estudiadas, seleccionada según las conclusiones presentadas Objetivos Objetivo General Implementar un prototipo de integración de sistemas, utilizando el bus de servicios empresariales seleccionado entre las herramientas: ESB propietario Oracle Service Bus y ESB de código abierto Apache Camel, analizando tiempos de procesamiento, carga transaccional y fiabilidad.

15 Objetivos Específicos Determinar los ambientes de prueba que se utilizarán en la comparación de las herramientas. ü Cuantificar los resultados del análisis realizado entre las dos herramientas tomando en cuenta diferentes criterios de tiempos de procesamiento, carga transaccional y fiabilidad. ü Determinar la cantidad de trabajo adicional que se requiere al realizar e implementar una integración con las dos herramientas planteadas. ü Elaborar un prototipo de integración de sistemas para demostrar de manera práctica las conclusiones a las cuales se llegó con el estudio Limitaciones En el siguiente trabajo de titulación se consideran las siguientes limitaciones: 1. La comparación entre las dos herramientas se basará en los siguientes patrones de integración: ü enrutamiento de mensajes: o enrutamiento basado en contenido o enrutamiento dinámico ü traductor de mensajes ü divisor de mensajes ü agregador de mensajes ü canal de DeadLetter 2. Se evaluará cada patrón de manera práctica, tomando en cuenta la precisión, facilidad de pruebas y tiempo de respuesta. 3. No se realizarán pruebas prácticas con patrones adicionales u otros criterios, debido a que con los definidos anteriormente se cubre el alcance del presente trabajo. 4. Si en el transcurso de la investigación se encuentran criterios adicionales que aporten valor al resultado, se los tomará en cuenta,

16 4 realizando las respectivas comparaciones en base a las especificaciones de cada herramienta, mas juicio de expertos, de haberlo. 5. El Capítulo IV. ESCENARIOS DE TOMA DE DATOS presentará el diseño de cada caso de prueba y sus resultados; sin entrar en el detalle de los pasos que se realizan para diseñar cada componente. 2. Capítulo II. MARCO TEÓRICO 2.1. Integración de Sistemas Para entender lo que es Integración de Sistemas se deben conocer algunos conceptos: Parafraseando lo expuesto en el sitio Definicion.de, un sistema de información es un conjunto de componentes que interaccionan entre sí para alcanzar un objetivo determinado que satisfaga las necesidades de una organización; estos componentes pueden ser datos, personas, actividades o recursos materiales los cuales procesan dicha información y la distribuyen de manera adecuada. Por su parte, Integración es constituir un todo, completar un todo con las partes que faltaban o hacer que alguien o algo pase a formar parte de un todo. (Definicion.de) Adicionalmente, en la revista Negocios de Seguridad, en su artículo Integración de Sistemas de Seguridad se cita una definición de integración de sistemas según Carlos Guzmán, instructor de la Asociación Latinoamericana de Seguridad (ALAS), que dice: integrar es un proceso mediante el cual intercomunicamos diferentes sistemas para tener una interacción entre ellos, con un objetivo, funciones y secuencia de operación definidos. En esta ecuación, la intercomunicación es la que permite intercambiar información entre un sistema y otro. Se relaciona básicamente con protocolos de comunicación mientras que la interacción es la que permite ejecutar acciones que involucren elementos de diferentes sistemas

17 5 y que se basen en información proveniente de cualquiera de ellos. Se asocia a la lógica de funcionamiento de cada uno. Con la evolución de la integración de sistemas, aparecieron otros conceptos relacionados como patrones de integración, los cuales buscan estandarizar las soluciones, es decir que cuando se deba resolver diferentes problemas que requieran los mismos procedimientos, se apliquen medidas antes utilizadas y probadas en la resolución del mismo tipo de problema y así disminuir el esfuerzo. Tomando estas definiciones, se puede decir que la integración de sistemas es construir un sistema completo a partir de otros subsistemas que administran y organizan diferentes porciones de información para cumplir un objetivo específico en una determinada organización. La integración de sistemas busca aplicar patrones y servir de puente entre las aplicaciones, encargándose del medio de transporte y del protocolo Patrones de Integración Un patrón es un modelo que sirve de muestra para sacar otra cosa igual. (WordReference.com) Y según Definición.de se refiere a los hechos o las cosas recurrentes. Estos factores o elementos se repiten con previsibilidad y, por lo tanto, pueden funcionar como modelo para producir determinada cosa a partir de ellos. (Negrillas eliminadas) Los patrones de integración estandarizan la realización de ciertas tareas dentro de la integración de sistemas, definen diseños comunes y determinan un lenguaje común para la comunicación entre diferentes aplicaciones. En 1979 el arquitecto Christopher Alexander escribe el libro The Timeless Way of Building donde propone el aprendizaje y utilización de diferentes patrones de diseño para la construcción de edificios con mayor calidad. El objetivo es aplicar estos patrones tantas veces como sean necesarias sin pensar en nueva solución cada vez.

18 6 En 1987 esta idea fue acoplada a la programación orientada a objetos en un artículo escrito por Ward Cunningham y Kent Beck, donde se propone utilizar patrones para diseñar propios programas y aplicaciones con la siguiente estructura: Tabla 1: Estructura de la definición de los patrones de integración. Problema Resumen Solución Enunciado del problema Resumen de las circunstancias que crean el problema Solución que se puede aplicar en dichas circunstancias Los patrones fueron evolucionando hasta volverse más específicos y solventar necesidades como: variedad en plataformas y tecnologías, estándares poco definidos, aplicaciones de terceros, socios comerciales, etc. En el mercado existen soluciones para este tipo de problemas. Algunas herramientas son propietarias como: Oracle e IBM; y otras son de código abierto como OpenESS, Mule y Fuse. Los patrones que serán caso de estudio en este trabajo de titulación, se detallan a continuación: Content-Based Router Figura 1: Patrón de integración Content-Based Router Tomado de

19 7 Problema Resumen Solución Enrutamiento basado en contenido Se requiere manejar una situación en donde una única función lógica se debe propagar a diferentes sistemas físicos, por ejemplo un control de inventario. Utilizar un enrutador basado en el contenido del mensaje para dirigir cada uno, al destinatario correcto, según dicho contenido Message Translator Figura 2: Patrón de integración Message Translator Tomado de Problema Resumen Solución Traductor de mensajes Cada aplicación utiliza su propio formato de datos, por lo que se debe traducir el mensaje en el formato de datos que la aplicación admita. Utilizar un filtro especial, un traductor de mensajes, entre los filtros o aplicaciones para convertir de un formato de datos a otro.

20 Dynamic Router Figura 3: Patrón de integración Dynamic Router Tomado de Problema Resumen Solución Enrutamiento dinámico Se necesita evitar la dependencia del router en todos los destinos posibles, manteniendo su eficiencia y enrutando los mensajes basados en una lista dinámica de destinatarios. Utilizar un router dinámico, que puede autoconfigurarse basado en mensajes especiales de configuración de los destinos participantes.

21 Splitter Figura 4: Patrón de integración Splitter Tomado de Problema Resumen Solución Divisor de mensajes Se requiere procesar un mensaje que contiene múltiples elementos, cada uno de los cuales tiene que ser procesado de una manera diferente. Se necesita dividir un solo mensaje en partes para ser transferidas individualmente. Utilizar un divisor para separar el mensaje compuesto en una serie de mensajes individuales, cada uno contiene datos relacionados con un elemento Aggregator Figura 5: Patrón de integración Aggregator Tomado de

22 10 Problema Resumen Solución Agregador de mensajes Se requiere combinar resultados individuales pero relacionados, en un único mensaje para que puedan ser procesados como conjunto. Utilizar un filtro de estado, agregador, para recoger y almacenar mensajes individuales hasta que se reciba un conjunto completo de mensajes relacionados que se publicará Dead Letter Channel Figura 6: Patrón de integración Dead Letter Channel Tomado de

23 11 Problema Resumen Canal de DeadLetter Se requiere tomar acciones sobre mensajes que es sistema no puede entregar. Solución Mover el mensaje al canal DeadLetter en el cual se registra el mensaje al nivel ERROR y se lo reenvía hasta 6 veces, con un retraso de un segundo antes de cada intento Evolución de la Integración de Sistemas Sistemas Punto a Punto Son aquellos en los que por un solo canal de datos se comunica únicamente dos nodos (dos máquinas), cada una de las cuales puede actuar como cliente y como servidor. Estos sistemas son menos costosos pero tienen más restricciones ya que están formados por pequeños grupos de trabajo, además la seguridad es difícil ya que la administración no es centralizada. El momento en que el número de nodos crece, el número de conexiones se incrementa a razón de n*(n-1) / 2 lo cual complica enormemente su administración y mantenimiento. Si las conexiones punto a punto crecen en la organización de una manera rápida, se obtendrá como resultado una estructura bastante desordenada que es difícil de mantener. Un ejemplo de una estructura creciente se muestra en la Figura 7.

24 12 Figura 7: Estructura compleja de una conexión punto a punto Tomado de: icas-de-cliente-servidor-en.html EAI (Enterprise Application Integration) Cuando la compartición de información entre sistemas deja de ser efectiva y se crean cuellos de botellas, las personas deben intervenir en la toma de decisiones o en el ingreso de la información. Se genera la necesidad de integrar diferentes tipos de sistemas pero para ello debían realizar cambios en su funcionalidad y estructura de datos. EAI busca solventar estos problemas para mejorar la organización y que el esfuerzo de los recursos humanos se centre en la creación y crecimiento de competencias que generen valor en vez de centrarse en solucionar los problemas de integración. EAI, que en español quiere decir Integración de Aplicaciones Empresariales, trata de organizar el flujo de información entre aplicaciones heterogéneas; esto implica el desarrollo de conectores (middleware 1 ) y la utilización de diferentes protocolos de comunicación. 1 Es un software que asiste a una aplicación para interactuar o comunicarse con otras aplicaciones, software, redes, hardware y/o sistemas operativos. (Wikipedia)

25 13 Esta forma de integración presenta limitaciones como rigidez en la herencia (legacy 2 ) ya que cuando se deben implementar cambios importantes en las diferentes aplicaciones se debe modificar el middleware. Figura 8: Arquitectura tradicional de EAI Tomado de: png En el 2003 se reportó que el 70% de todos los proyectos de EAI fallaron, aunque la mayoría de dichas incidencias no se debían a errores técnicos del software o implementación, sino a problemas de gobernabilidad como cambio constante, falta de experiencia en EAI, estándares aún no definidos, y otros. 2 Es un sistema informático que ha quedado anticuado pero continúa siendo utilizado por el usuario y no se quiere o no se puede reemplazar o actualizar de forma sencilla. (Wikipedia)

26 Bus de Servicios Empresariales (ESB) Tras el fracaso de EAI se inició la búsqueda de tecnologías que permitan el diseño de soluciones de integración en un nivel alto de abstracción y que integren el uso de MDA 3 para transformar automáticamente el diseño en una solución ejecutable. Hay muchos proyectos en marcha que proporcionan apoyo para el diseño de estas soluciones, desde proyectos propietarios como Microsoft BizTalk Server, IBM WebSphere Message Broker o proyectos de código abierto como Mule ESB, Apache Camel, Niklas Integration Platform and Spring Integration. Según SearchSOA, en el libro EAI define ESB como una tecnología que permite EAI, la cual es una noción más grande, donde los ESB son un ejemplo de la tecnología. Es casi como decir "Los automóviles son mejores que el concepto de transporte". Un bus de servicios empresariales (ESB) es fundamentalmente una arquitectura. Es un conjunto de normas y principios para integrar múltiples aplicaciones, ESB permite a los usuarios construir arquitecturas de integración, pero varían en la forma en que lo hacen y las capacidades que ofrecen. El concepto central de una arquitectura ESB es que permite integrar diferentes aplicaciones, poniendo un bus de comunicación entre ellos y permitiendo que cada aplicación se comunique con dicho bus. Esto desacopla los sistemas entre sí, lo que suprime la dependencia o el conocimiento de los otros sistemas en el bus; tal como se puede ver en la Figura 9. 3 Model-Driven Architecture

27 15 Figura 9: Diagrama de la estructura de Enterprise Service Bus Tomada de La integración punto a punto crea dependencias estrechas entre aplicaciones, debido a que no existe centralización para controlar o solucionar problemas, lo que no le permite escalar y se vuelve frágil y difícil de manejar en el transcurso del tiempo. El concepto de ESB nació de la necesidad de alejarse de la integración punto a punto y como una evolución de EAI. La utilización de un ESB presenta, según IBM, las siguientes ventajas: ü Mayor reutilización de activos de TI separando la lógica de las aplicaciones y las tareas de integración; con esto se reduce el número, tamaño y complejidad de las interfaces de aplicación. ü Capacidad de añadir o cambiar servicios con una interrupción mínima en las aplicaciones. ü Reducir costos y riesgos involucrados en los cambios del negocio. TIBCO define un ESB como una capa de comunicaciones basada en estándares en una arquitectura orientada a servicios (SOA) que permite que los servicios que se utilicen a través de múltiples protocolos de comunicación, y añade otras:

28 16 ü Simplificar el despliegue y gestión de servicios. ü Fomenta la reutilización de servicios en un ambiente heterogéneo. ü Soporta tecnologías de código abierto y propietario. El autor del libro Enterprise Service Bus, David Chappell, dice sobre el uso de un ESB, que proporciona un enfoque altamente distribuido a la integración y que tiene capacidades únicas que permiten a los distintos departamentos del negocio construir sus propios proyectos con control local y autonomía, sin dejar de conectar entre sí a cada proyecto de integración. En la Figura 10, se puede ver como se pueden conectar a un ESB: procesos de negocio, reglas de negocio, aplicaciones, manejo de documentos, datos, entre otros. Figura 10: Diagrama de la arquitectura de Enterprise Service Bus Tomado de Herramienta Oracle Service Bus (OSB) Es un ESB manejado por políticas y basado en configuraciones que proporciona una consola rica en características para servicios dinámicos y políticas de configuración, así como también para monitoreo de sistemas y tareas. OSB facilita una arquitectura de acoplamiento flexible y centraliza el

29 17 mantenimiento. La consola de OSB permite responder rápida y eficientemente a los cambios en el ambiente orientado a servicios. Figura 11: Diagrama de Oracle Service Bus Tomado de Oracle Service Bus 11g: Design and Integrate Services, 2011, p. 28 A continuación se enumeran algunas de las características más sobresalientes de Oracle Service Bus: ü Transforma y dirige dinámicamente los servicios utilizando reglas de enrutamiento simples y complejas. ü Orquesta servicios de los sistemas de TI existentes con diferentes protocolos de mensajería sin necesidad de cambiar el sistema y los estilos. ü Aísla los cambios de ubicación de servicio. ü Responde rápidamente a las necesidades de la empresa configurando las reglas de enrutamiento basadas en cambios en las reglas de negocio existentes o sistemas de TI, sin necesidad de programación.

30 18 ü Orquesta varios servicios para crear uno nuevo. Oracle Service Bus aporta una infraestructura orientada a servicios tomando en cuenta las necesidades de la empresa convergiendo las capacidades de integración de un ESB con la gestión de servicios, para formar un solo producto; esto acelera la configuración y el despliegue, y simplifica la gestión de servicios compartidos sobre SOA. Figura 12: Arquitectura de Oracle Service Bus Tomado de Oracle Service Bus 11g: Design and Integrate Services, 2011, p. 41 El bus ofrece servicios de envío de mensajes, basados en estándares, incluyendo SOAP, HTTP y Java Messaging Service (JMS). Es típicamente diseñado para trabajar en alto rendimiento, la entrega de mensajes es garantizada para una variedad de productores y consumidores de servicios. Es compatible con XML como un tipo de datos nativo, mientras que también ofrece alternativas para el manejo de tipos de datos.

31 19 Permite establecer una articulación flexible entre los clientes de servicios y los servicios de las empresas, manteniendo al mismo tiempo un punto centralizado de control de seguridad y vigilancia. Oracle Service Bus es un intermediario que procesa los mensajes entrantes de solicitud de servicio, determina la lógica de enrutamiento, y transforma estos mensajes para que sean compatibles con los consumidores de servicios. Se recibe mensajes a través de un protocolo de transporte como HTTP (S), JMS, de archivo y, FTP, y envía mensajes a través del mismo o de un protocolo diferente. El procesamiento de mensajes por parte de Oracle Service Bus es manejada por metadatos, especificados en la definición del flujo de mensajes de un servicio proxy Herramienta Apache Camel Se considera a Camel como un framework de integración cuyo núcleo es un motor de enrutamiento, el cual se combina con otros componentes como ServixMix y OpenESB provee las funcionalidades propias de un ESB. Camel permite definir sus propias reglas de enrutamiento, decidir las fuentes de donde acepta los mensajes, procesarlos y enviar dichos mensajes a diferentes destinos. Camel utiliza un lenguaje de integración que permite definir reglas de enrutamiento complejas, similares a los procesos de negocio. Se pueden detallar algunas de las características más destacadas de esta herramienta: ü Camel no hace suposiciones acerca de los tipos de datos que se necesita procesar dando oportunidad al programador de integrar cualquier tipo de sistema, sin necesidad de convertir los datos a un formato canónico. ü Camel ofrece un mayor nivel de abstracción que le permite interactuar con los diferentes sistemas que utilizan la misma API,

32 20 independientemente del protocolo y el tipo de datos que los sistemas utilicen. ü Camel soporta más de 80 protocolos y tipos de datos. ü Su arquitectura extensible y modular permite implementar y conectar sin problemas sus propios protocolos, propietarios o no. ü Esta arquitectura elimina el requerimiento de hacer conversiones innecesarias haciendo que Camel sea a más rápido. Figura 13: Diagrama de Apache Camel Tomado de Los autores de Camel decidieron crearlo, en vez de utilizar un marco ya existente, presentando algunas ideas novedosas en el ámbito de la integración: ü Motor de enrutamiento y mediación

33 21 ü Patrones empresariales de integración (EIPs) ü Dominio de un idioma específico (DSL) ü Amplia biblioteca de componentes ü Capacidad de carga independiente del enrutador ü Arquitectura conectable y modular ü Modelo POJO ü Fácil configuración ü Convertidor automático de tipos ü Núcleo ligero ü Kit de prueba ü Comunidad entusiasta de apoyo Figura 14: Vista de alto nivel de los principales conceptos que componen la arquitectura de Camel Tomado de Camel in Action, 2010, p. 15 En un nivel alto, Camel se compone de procesadores, componentes, y rutas. Todos estos están contenidos dentro del CamelContext. Camel utiliza rutas como especificaciones para que los mensajes se enruten, estas se definen utilizando uno de los DSLs de Camel (Dominio de lenguaje específico).

34 22 Los procesadores se utilizan para transformar y manipular mensajes durante el enrutamiento y también para aplicar todos los patrones de EIP, que tienen palabras claves correspondientes en los lenguajes DSL. Los componentes son los puntos de extensión en Camel para agregar conectividad a otros sistemas. Para exponer estos sistemas, los componentes proporcionan una interfaz de punto final. 3. Capítulo III. DEFINICIÓN DE CRITERIOS DE COMPARACIÓN 3.1. Criterios de Comparación En el alcance del presente trabajo de titulación, se define que se realizará el estudio comparativo entre el bus de servicios de Oracle y Apache Camel basándose en los criterios de comparación más comunes. Con este antecedente, se determina cada uno de dichos patrones como características, las cuales se califican sobre un valor máximo definido previamente, en porcentaje. La suma de estos valores da como resultado el valor que será la calificación final de cada herramienta sobre 100%. Los valores máximos, mencionados anteriormente, se calculan aplicando la matriz de pares, lo que compara cada uno de los patrones de dos en dos según su importancia; una vez finalizada dicha comparación, se suman todos los valores y con esto se obtiene la ponderación final para cada patrón. Hay que tomar en cuenta que se debe realizar una transformación para que la calificación final se haga en una escala de 100%. Los patrones a ser evaluados son: ü Enrutamiento de mensajes: o Enrutamiento basado en contenido o Enrutamiento dinámico ü Traductor de mensajes ü Divisor de mensajes ü Agregador de mensajes ü Canal Dead Letter

35 23 Adicionalmente se realiza la calificación de cada uno de los patrones definidos, tomando en cuenta los criterios: precisión, tiempo de respuesta y facilidad de pruebas. Para este estudio se utilizarán web services y archivos como: cvs y xml Conceptos Importantes Es importante definir los siguientes conceptos debido a que, los mismos, serán referenciados a lo largo del proceso de comparación: ü Apache Karaf.- Es un OSGi4 basado en tiempo de ejecución que provee un contenedor ligero donde se pueden implementar varios componentes y aplicaciones. ü Business y Proxy Services (Oracle Service Bus): Figura 15: Arquitectura de los servicios de negocio y lo servicios proxy Tomado de: 4 Open Services Gateway Initiative: Su objetivo es definir las especificaciones abiertas de software que permita diseñar plataformas compatibles que puedan proporcionar múltiples servicios. (Wikipedia)

36 24 o Bussines Services.- Son definiciones de los web services que permiten realizar la llamada a servicios externos, a través de estos el OSB sabe que invocar, como invocar y lo que puede recibir. o Proxy Services.- Son las definiciones de los web services intermediarios que OSB implementa localmente. Aquí se invocan los diferentes servicios de negocio y el OSB los encamina para ser consumidos. ü CSV Files.- Viene del inglés comma-separated values. Estos documentos tienen un formato sencillo que representa datos en forma de tabla, una vez procesado. Las columnas se separan por comas (,) y las filas por salto de línea. Figura 16: Ejemplo de la estructura de un archivo CSV Tomado de ü Facilidad de pruebas.- Proveer las interfaces y procesos necesarios para verificar los resultados a pruebas diseñadas y ejecutadas, en las diferentes transacciones.

37 25 ü Hawtio.- hawtio es una consola web HTML5 ligero y modular con una gran cantidad de plugins para manejar los artefactos Java. Trabaja con contenedores como: Tomcat, Espolón, Karaf, JBoss, etc. Figura 17: Consola Hawtio Tomado de ü Precisión.- Ejecutar las transacciones de manera correcta, dando como resultado los valores convenientes y esperados. ü Tiempo de respuesta.- Proveer los resultados esperados en un tiempo determinado según las condiciones de las transacciones. ü Web Services.- Que en español significa servicios web es una tecnología que permite intercambiar información entre distintas aplicaciones con lenguajes y plataformas diferentes, mediante protocolos y estándares.

38 26 Figura 18: Ejemplo de la definición de un Web Service Tomado de aywebservices ü WSDL.- Significa en inglés Web Services Description Language. Es un documento con formato XML que describe los web services: requisitos del protocolo, formatos de mensajes, etc. para interactuar con los diferentes servicios.

39 27 Figura 19: Ejemplo de la estructura de un archivo wsdl Tomado de ü XML.- Sus siglas en inglés vienen de extensible Markup Language (lenguaje de marcas extensible). Es una tecnología sencilla pero cuenta con otras que complementan su funcionalidad. Se utiliza como herramienta para compartir información de manera segura, fiable y fácil.

40 28 Figura 20: Ejemplo de archivo XML Tomado de un_documento_xml ü XSD.- Significa en inglés XML schema definition. Es un lenguaje de esquema que describe la estructura y las limitaciones del contenido de los xml, Son archivos con extensión.xsd que pueden ser importandos desde un wsdl para formar parte del mismo. Figura 21: Ejemplo de la estructura de un archivo xsd Tomado de

41 Ponderaciones Se establecieron los pesos para cada uno de los criterios de evaluación de patrones, así como también para cada uno de ellos, utilizando una matriz de pares, donde se ubican los nombres de los elementos, en filas y columnas y se comparan de par en par, tomando en cuenta la importancia de cada uno de ellos con las siguientes calificaciones: Tabla 2: Tabla de calificaciones según el nivel de importancia para obtener las ponderaciones de los criterios de comparación aplicando la matriz de pares. CALIFICACIONES IMPORTANCIA 10 Mucho más importante 5 Más importante 1 Igual de importante 1/5 Menos importante 1/10 Mucho menos importante A continuación se suman los valores de cada fila y así se obtienen los pesos para cada criterio y para cada característica. El nivel de importancia para aplicar la matriz de pares y sacar los pesos finales de cada criterio y característica fue tomado de una encuesta realizada a un grupo de expertos en el tema. Los resultados de la misma se pueden verificar en el Anexo 1. En las ilustraciones siguientes, se puede observar los pesos definidos para los criterios de evaluación y para los patrones:

42 30 Tabla 3: Tabla donde se detalla el proceso para calcular las ponderaciones para cada criterio de evaluación CRITERIOS P TR FP SUMA 100,00 Precisión 0,20 5,00 5,20 25,4 Tiempo de respuesta 5,00 10,00 15,00 73,2 Facilidad de pruebas 0,20 0,10 0,30 1,5 TOTAL: 20,50 100,00 Tabla 4: Tabla donde se detalla el proceso para calcular las ponderaciones para cada patrón de integración EC TM ED DM AM CD SUMA 100,00 Enrutamiento basado en contenido 1,00 5,00 1,00 1,00 5,00 13,00 23,4 Traductor de mensajes 1,00 5,00 1,00 1,00 5,00 13,00 23,4 Enrutamiento dinámico 0,20 0,20 0,20 0,20 1,00 1,80 3,2 Divisor de mensajes 1,00 1,00 5,00 1,00 5,00 13,00 23,4 Agregador de mensajes 1,00 1,00 5,00 1,00 5,00 13,00 23,4 Canal de DeadLetter 0,20 0,20 1,00 0,20 0,20 1,80 3,2 TOTAL: 55,60 100,00 En la tabla presentada a continuación se puede observar el cuadro de evaluación de los diferentes patrones por cada una de las herramientas a estudiar.

43 31 CRITERIOS PARA EVALUAR CADA PATRÓN CRITERIOS PARA EVALUAR CADA PATRÓN CRITERIOS PARA EVALUAR CADA PATRÓN APACHE CAMEL Tabla 5: Tabla con resultados de ejemplo de la evaluación por criterio entre las herramientas OSB y Apache Camel. CUADRO DE EVALUACIÓN DE LOS PATRONES DE INTEGRACIÓN POR CADA HERRAMIENTA PONDERACIÓN POR CRITERIO Calificaciones: 0 = nada satisfactorio, 1 = poco satisfactorio, 2 = satisfactorio, 3 = muy satisfactorio Enrutamiento basado en contenido RESULTADO Traductor de mensajes RESULTADO Precisión 25,4% 3 25,4% 3 25,4% OSB PONDERACIÓN POR CRITERIO Enrutamiento basado en contenido RESULTADO Traductor de mensajes CALIFICACIÓN 100% 100% CRITERIOS PARA EVALUAR CADA PATRÓN CALIFICACIÓN 100% 100% RESULTADO Precisión 25,4% 3 25,4% 3 25,4% Tiempo de respuesta 73,2% 3 73,2% 3 73,2% Tiempo de respuesta 73,2% 3 73,2% 3 73,2% Facilidad de pruebas 1,5% 3 1,5% 3 1,5% Facilidad de pruebas 1,5% 3 1,5% 3 1,5% APACHE CAMEL PONDERACIÓN POR CRITERIO Divisor de mensajes RESULTADO Agregador de mensajes RESULTADO Precisión 25,4% 3 25,4% 3 25,4% OSB PONDERACIÓN POR CRITERIO Divisor de mensajes RESULTADO Agregador de mensajes CALIFICACIÓN 100% 100% CRITERIOS PARA EVALUAR CADA PATRÓN CALIFICACIÓN 100% 100% RESULTADO Precisión 25,4% 3 25,4% 3 25,4% Tiempo de respuesta 73,2% 3 73,2% 3 73,2% Tiempo de respuesta 73,2% 3 73,2% 3 73,2% Facilidad de pruebas 1,5% 3 1,5% 3 1,5% Facilidad de pruebas 1,5% 3 1,5% 3 1,5% APACHE CAMEL PONDERACIÓN POR CRITERIO Enrutamiento dinámico RESULTADO Canal de DeadLetter RESULTADO Precisión 25,4% 3 25,4% 3 25,4% OSB PONDERACIÓN POR CRITERIO Enrutamiento dinámico RESULTADO Canal de DeadLetter CALIFICACIÓN 100% 100% CRITERIOS PARA EVALUAR CADA PATRÓN CALIFICACIÓN 100% 100% RESULTADO Precisión 25,4% 3 25,4% 3 25,4% Tiempo de respuesta 73,2% 3 73,2% 3 73,2% Tiempo de respuesta 73,2% 3 73,2% 3 73,2% Facilidad de pruebas 1,5% 3 1,5% 3 1,5% Facilidad de pruebas 1,5% 3 1,5% 3 1,5%

44 32 Tabla 6: Cuadro con resultados finales de ejemplo entre las herramientas Apache Camel y OSB. GRUPO PATRONES DE INTEGRACIÓN CARACTERÍSTICAS PONDERACIÓN POR CARACTERÍSTICA APACHE CAMEL RESULTADO OSB RESULTADO Enrutamiento basado en contenido 23,4% 100,0% 23,4% 100,0% 23,4% Traductor de mensajes 23,4% 100,0% 23,4% 100,0% 23,4% Enrutamiento dinámico 3,2% 100,0% 3,2% 100,0% 3,2% Divisor de mensajes 23,4% 100,0% 23,4% 100,0% 23,4% Agregador de mensajes 23,4% 100,0% 23,4% 100,0% 23,4% Canal de DeadLetter 3,2% 100,0% 3,2% 100,0% 3,2% CALIFICACIONES POR HERRAMIENTA: 100% 100%

45 33 4. Capítulo IV. ESCENARIOS DE TOMA DE DATOS 4.1. Instalación del OSB Oracle Service Bus requiere, para su funcionamiento, la instalación previa de un conjunto de componentes. Los mismos, son recomendados en la documentación oficial de la herramienta. En la siguiente figura se presenta la lista de los mencionados componentes, en el orden que el manual de instalación de Oracle, recomienda instalar: Figura 22: Lista de componentes necesarios para la instalación de OSB. Adaptada de: x.html Los requerimientos de hardware para esta herramienta son los siguientes: ü Memoria > 3 Gb mínimo para correr (si no se dispone de esta característica se recomienda separar la base de datos y el servidor en diferentes máquinas) ü Espacio en disco > Gb en total (4.81 Gb para la descarga de todos los instaladores, 5.15 para la instalación como tal, 5 Gb para la base de datos dependiendo de la configuración y 1.2 Gb para el OSB) JDeveloper es una herramienta de desarrollo, en su mayoría, para generar SCA (Service Composite Application); dicha herramienta no es necesaria en estas prácticas, tomando en cuenta el alcance del estudio, en su lugar se utilizará el IDE de desarrollo Eclipse.

46 34 En la instalación de WebLogic se recomienda seleccionar el componente OEPE (Oracle Enterprise Pack for Eclipse), el cual es el mismo Eclipse conteniendo el pluggin del OSB. Esta lista de componentes se puede instalar en varias plataformas. Para este trabajo de titulación se ha utilizado una distribución de Linux como sistema operativo, donde las versiones son las siguientes: ü OracleXE ü Weblogic OEPE Indigo ü RCU ü SOA ü OSB Para la correcta ejecución de los componentes antes mencionados se debe seguir la guía de instalación que Oracle proporciona en su página: esoasuite11gr1ps pdf. La guía utilizada en el presente documento se adjunta en el Anexo Instalación de Apache Camel Para desplegar las pruebas realizadas con Apache Camel es necesario instalar Apache Karaf, el cual cuenta con una serie de características disponibles para instalar, de acuerdo a los requerimientos de cada aplicación. Adicionalmente se debe instalar la consola web de Apache Karaf, la cual provee una interfaz gráfica para la administración del mismo y por último se debe instalar la herramienta Hawtio, en donde se puede dar seguimiento al flujo de ejecución en Apache Camel. En la práctica, no hay un proceso de instalación, simplemente se debe descargar el paquete de Apache Karaf y descomprimirlo en un directorio seleccionado por el usuario; por lo tanto, se puede realizar este proceso en varias plataformas. Para este trabajo de titulación se ha utilizado una distribución de Linux, y las versiones de los componentes que se deben instalar en el Apache Karaf son las siguientes:

47 35 ü Apache-karaf o Spring RELEASE o Camel-flatpack o Camel-xstream o Camel-cxf o Webconsole o Hawtio o Apache-camel En cuanto a la instalación de las características enumeradas anteriormente, que son las necesarias para el despliegue y funcionamiento de estos casos de prueba, se debe iniciar el Apache Karaf mediante consola y utilizando el comando features:install, instalar la consola gráfica, donde se pueden instalar las demás características. Los requerimientos de hardware para la instalación de esta herramienta con sus componentes son los siguientes: ü Memoria > 512 MB ü Espacio en disco > 97,5 MB Vale recalcar que estas características varían según la complejidad de la aplicación que se construya Diseño de Pruebas Para realizar las pruebas con cada uno de los patrones planteados, se debe diseñar un contexto en el que se pueda aplicar todos ellos de manera individual, pero guardando relación entre sí, con el objetivo de poder integrarlos en la construcción del prototipo Contexto de la Aplicación Para realizar el diseño y desarrollo de pruebas, el contexto de aplicación será el de una Cafetería que maneja información de clientes y pedidos, en donde se cuenta con las siguientes restricciones: ü El tipo de cliente puede ser Normal o Preferente.

48 36 ü Cada cliente puede realizar varios pedidos. ü Se utilizará bebidas Frías o Calientes Recursos Para esta aplicación se utilizará un web service que representa a un Cliente con la siguiente estructura:

49 37 Tabla 7: Estructura del WSDL con la información del cliente y los pedidos ESTRUCTURA DEL CLIENTE ü Nombre ü Apellido ü Fecha de Ingreso ü Tipo ü Pedidos o Pedido Nombre Tipo Precio Estado Nombre del cliente Apellido del cliente Fecha de ingreso del cliente Tipo del cliente (Normal o Preferencial) Lista de pedidos que realiza un cliente Pueden ser uno o varios. Nombre de la bebida Tipo de la bebida (Fría o Caliente) Precio de la bebida Estado del pedido donde se presentarán los diferentes mensajes según el caso de prueba Aplicación por patrones A continuación se define cada caso de prueba que se desarrollará para aplicar los diferentes patrones, en base al contexto de apliaciòn antes definido. Divisor de mensajes: Cada pedido enviado en la solicitud, se separará y será procesado de manera independiente pero en forma paralela a los demás pedidos. ENTRADA Información de pedidos: ü nombre ü tipo ü precio ü estado

50 38 SALIDA Información de cada pedido procesado: ü nombre ü tipo ü precio ü estado {presentación del mensaje de pedido procesado } Agregador de mensajes: El resultado del caso de prueba del Divisor de mensajes, es una lista de pedidos procesados. En este caso de prueba, se agregan nuevamente dichos pedidos. ENTRADA Lista de pedidos procesados con la información de cada uno, por separado: ü nombre ü tipo ü precio ü estado {presentación del mensaje de pedido procesado } SALIDA Información de todos los pedidos procesados: ü nombre ü tipo ü precio ü estado Enrutamiento basado en contenido: Las bebidas frías se procesarán de manera diferente que las bebidas calientes, el atributo que determina esto es el tipo de bebida; el procesamiento consiste en presentar un mensaje que diga: La bebida {tipo de bebida} {nombre de la bebida} ha sido procesada!.

51 39 ENTRADA Lista de pedidos con el tipo de bebida (fría o caliente): ü nombre ü tipo ü precio ü estado SALIDA Información de todos los pedidos procesados: ü nombre ü tipo ü precio ü estado {presentación del mensaje según el contenido de la información de entrada} Enrutamiento dinámico: Se procesará la lista de pedidos dependiendo del tipo de cliente. Si es cliente Normal, los pedidos se procesarán; y si es cliente Preferente, los pedidos se procesarán y pagarán. ENTRADA Lista de pedidos con la información del cliente (Normal o Preferente): ü nombre ü apellido ü fecha de ingreso ü tipo ü pedidos

52 40 SALIDA Información de todos los pedidos procesados según el tipo de cliente: ü nombre ü tipo ü precio ü estado {presentación del mensaje según el contenido de la información de entrada} Traductor de mensajes: Se enviará la información de los clientes en un archivo cvs, el mismo que será transformado a un archivo xml y este se guardará en un determinado directorio. ENTRADA ü archivo cvs con la información de los clientes. SALIDA ü archivo xml con la misma información, guardado en un directorio definido. Canal DeadLetter: Al enviar la petición de bebidas se lanzará un error, la aplicación intentará reenviarla tres veces antes de que se envíe la transacción como fallida.

53 41 ENTRADA Lista de pedidos con la información del cliente: ü nombre ü apellido ü fecha de ingreso ü tipo ü pedidos SALIDA Información de todos los pedidos procesados según el tipo de cliente: ü código del error obtenido ü mensaje del error obtenido Desarrollo de Pruebas Para la construcción de los casos de prueba de Apache Camel se ha seleccionado el IDE Eclipse; y en el caso de Oracle Service Bus se trabajará con el Oracle Enterprise Pack for Eclipse Divisor y Agregador de Mensajes La herramienta de Oracle OSB, ofrece un componente llamado Split-Join, en el cual se comprueba la funcionalidad de los dos patrones de integración: Divisor de Mensajes y Agregador de Mensajes. Por otro lado, la herramienta Apache Camel, permite utilizar dos componentes independientes, para probar dichos patrones. Se desarrollará un solo caso de prueba donde se apliquen los mencionados patrones, con el objetivo de demostrar su funcionalidad de la misma forma, para ambas herramientas. El caso de prueba consiste en enviar una serie de pedidos, pertenecientes a un cliente, los cuales son procesados de manera independiente pero en paralelo; aquí es donde actúa el patrón Divisor de Mensajes. Una vez procesados dichos pedidos, se los vuelve a reunir, para ser presentados como resultado; para ello se aplica el patrón Agregador de Mensajes.

54 42 ORACLE SERVICE BUS En esta herramienta se utiliza un Bussines Service (DivisorAgregadorBS.biz), el cual invoca al componente Split-Join (DivisorAgregador.flow), que tiene toda la definición del flujo del mensaje. Luego, se utiliza un Proxy Service (DivisorAgregadorPS.proxy) que invoca al mencionado Bussines Service para direccionarlo y seleccionar la operación que se utilizará en el caso de prueba. Figura 23: Proyecto CafeteriaDivisor Agregador con sus componentes.

55 43 Figura 24: Diseño del flujo del mensaje en el componente Split-Join (DivisorAgregador.flow).

56 44 Para ejecutar el caso de prueba, se despliega el proyecto en el servidor WebLogic. Se presentará una pantalla, donde se ingresa una estructura xml definida; aquí se puede agregar tantos pedidos como se requiera para realizar la prueba. Figura 25: XML de entrada con dos pedidos. (OSB) En el xml de resultado se desplegarán los mismos pedidos ingresados y se presentará el valor procesado en la etiqueta Estado de cada pedido.

57 45 Figura 26: XML de salida con los dos pedidos procesados. (OSB) APACHE CAMEL Para configurar el patrón de integración: Divisor de Mensajes, se utiliza el componente <camel:split></camel:split> donde se añaden las propiedades para que se realice la operación. A continuación se aplica el patrón de integración: Agregador de Mensajes, utilizando el componente <camel:aggregate></camel:aggregate>, donde, de igual forma, se añaden las propiedades para que se realice la operación que vuelve a agregar los pedidos ya procesados. Esto se puede observar en la siguiente figura:

58 46 Figura 27: Configuración de los componentes split y aggregate de Camel. Para ejecutar el caso de prueba se debe instalar en Apache Karaf, el proyecto creado en Eclipse, el cual contiene las rutas de Camel; y en la herramienta SOAPUI se correr el WSDL generado. Es aquí donde se ingresan los pedidos.

59 47 Figura 28: XML de entrada con dos pedidos (APACHE CAMEL) En el xml de resultado se desplegarán los mismos pedidos ingresados y se presentará el valor procesado en la etiqueta Estado de cada pedido.

60 48 Figura 29: XML de salida con los dos pedidos procesados (APACHE CAMEL) Enrutamiento Basado en Contenido Se pueden realizar una serie de evaluaciones sobre la información de entrada, dependiendo de estas evaluaciones se procesará de diferentes formas, dicho contenido. Para este caso de prueba, se evaluará si las bebidas de los pedidos ingresados son frías o calientes. De acuerdo a esta información, se presentará en la etiqueta Estado, el nombre y el tipo de bebida procesada. En el caso de que no se ingresen los tipos de bebidas definidos, no se reconocerán como pedidos válidos y la respuesta no arrojará el valor esperado. ORACLE SERVICE BUS Para este caso de prueba se utilizan dos Proxy Service. En el primero (EnviarPedido.proxy), se barre cada uno de los pedidos para enviarlos uno

61 49 por uno al siguiente Proxy Service (ProcesarPedido.proxy), en el cual se verifica el contenido de cada pedido. En este caso se valida el tipo de bebida y se procesa la información. Figura 30: Proyecto CafeteriaEBC con sus componentes.

62 50 Figura 31: Diseño del flujo del servicio (EnviarPedido.proxy)

63 51 Figura 32: Diseño del flujo del servicio (ProcesarPedido.proxy). Se despliega el caso de prueba en el servidor WebLogic y se presentará un formulario xml donde se debe ingresar la información de los pedidos.

64 52 Figura 33: XML de entrada con tres pedidos: una bebida fría, una caliente y otro tipo. Cuando el tipo de bebida es fria o caliente, el pedido se procesa, de contrario, este no se reconoce. El formulario xml de resultado se puede ver a continuación.

65 53 Figura 34: XML de salida con los dos pedidos procesados. APACHE CAMEL Para el caso de prueba de Enrutamiento Basado en Contenido se debe utilizar el componente de camel: choice. Para esto, primero se debe separar los pedidos ingresados a través del componente <camel:split></camel:split>, y evaluar de manera separada el tipo de bebida ( fria o caliente ), utilizando el componente <camel:choice></camel:choice>. Dependiendo de esta evaluación se dirige el pedido para que sea procesado de manera específica por las clases: procesarbebidafria o procesarbebidacaliente.

66 54 Figura 35: Configuración del componente choice. En la herramienta SOAPUI se genera un proyecto donde se apunta al WSDL que se despliega en Apache Karaf. Es aquí donde se ingresan los pedidos.

67 55 Figura 36: XML de entrada con tres pedidos (Enrutamiento Basado en Contenido). El formulario xml de respuesta, presenta en la etiqueta Estado de cada pedido el mensaje correspondiente, según el tipo de bebida. Esto se puede verificar en la siguiente figura.

68 56 Figura 37: XML de salida con los datos de respuesta (Enrutamiento Basado en Contenido) Enrutamiento Dinámico Para realizar un caso de prueba del patrón enrutamiento dinámico, se debe enviar los datos de entrada para que sean consumidos por diferentes servicios. En este caso esa decisión se realiza en base al tipo de cliente: Normal o Preferente. Cuando un cliente es Normal, la información de entrada será consumida por un servicio que procesa los pedidos; y cuando el cliente es Preferente, esta información se enviará a un servicio donde simula que los pedidos son procesados y pagados.

69 57 ORACLE SERVICE BUS Para realizar un enrutamiento dinámico con OSB, se utiliza un componente XQuery (ConfigBusiness.xq), donde se detalla la decisión en base a la cual se dirige a los diferentes servicios (BusinessService): ü Normal à DA2BS.biz (pedido procesado) ü Preferente à DivisorAgregadorBS.biz (pedido procesado y pagado) Este XQuery es consumido en un ProxyService (DynamicRouting.proxy), donde se realiza el ruteo a través del componente Dynamic Routing, según el tipo de cliente. Figura 38: Componente XQuery (ConfigBusiness.xq) donde se puede ver la decisión en base al tipo de cliente.

70 58 Figura 39: Proxy Service que consume el XQuery (DynamicRouting.proxy)

71 59 En el servidor WebLogic se ejecuta el proyecto y en el formulario xml que se presenta, se deben ingresar los datos, siendo el tipo de cliente: Normal o Preferente. Figura 40: XML de entrada. Tipo de cliente: Normal y Preferente Tras ejecutar la prueba, se presenta el xml de respuesta con el estado de cada pedido, según el tipo del cliente. Esto se puede observar en las siguientes ilustraciones:

72 60 Figura 41: XML de respuesta. Tipo de cliente: Normal y Preferente APACHE CAMEL El componente que se utiliza para realizar un enrutamiento dinámico con Camel es <camel:dynamicrouter></camel:dynamicrouter>, y es aquí donde se redirecciona a la clase que se realiza la decisión del servicio que consumirá la información. Si el tipo de cliente es NORMAL el estado del pedido será procesado; y si el tipo de cliente es PREFERENTE, el estado del pedido será procesado y pagado.

73 61 Figura 42: Configuración del componente dynamicrouter utilizando las rutas de Camel. En la herramienta SoapUI se genera un nuevo proyecto con el WSDL del proyecto de enrutamiento dinámico ya publicado en el Apache Karaf y se ingresa la información de acuerdo a lo explicado anteriormente, esto se puede ver en las siguientes ilustraciones:

74 62 Figura 43: Servicios disponibles, publicados en Apache Karaf. Figura 44: Formulario xml de entrada para ejecutar el caso de prueba de Enrutamiento Dinámico. Tipo de Cliente: NORMAL y PREFERENTE El formulario xml de respuesta presenta los estados de los diferentes pedidos, según el tipo de cliente ingresado en la información de entrada.

75 63 Figura 45: XML de respuesta para el caso de prueba de Enrutamiento Dinámico. Tipo de cliente: NORMAL y PREFERENTE Transformador de Mensajes Las herramientas Apache Camel y OSB ofrecen componentes que permiten realizar transformaciones de mensajes en diferentes formatos. Para este caso de prueba se enviará un archivo cvs como información de diferentes clientes y el resultado será un archivo xml con la misma información. Este archivo se ubicará en un directorio especificado para cada herramienta. ORACLE SERVICE BUS En este caso de prueba se utiliza la estructura del archivo cvs que se configura a través del componente MFL (Estructura.mfl) y la estructura del archivo xml, mediante el componente xsd (estructura.xsd). Para realizar esta transformación se debe mapear ambas estructuras con el objetivo de que concuerden cada una de las propiedades del cliente. Esto se hace utilizando el componente XQuery Transformation (Transformador.xq)

76 64 Figura 46: Mapeo de atributos de la estructura no xml a la estructura xml. En un BusinessService (TransBS.biz) se especifica el directorio donde se guarda los archivos de salida, y además se selecciona la misma estructura xml. Los componentes BusinessService y XQuery son consumidos en el componente ProxyService (TransPS.proxy), el cual rutea la transformación realizada al directorio especificado. Figura 47: Proyecto del Transformador

77 65 Figura 48: Flujo del ProxyService (TransPS.proxy)

78 66 Para probar este caso se debe despliega el proyecto en el servidor WebLogic y se selecciona el archivo cvs. En el formulario de respuesta no se presenta ningún error y se verifica si el documento xml está en el directorio definido. Figura 49: Selección del archivo cvs para ejecutar la prueba de transformación. Figura 50: Formulario de respuesta y visualización del archivo xml generado. A continuación se puede ver el archivo de entrada y de salida con la misma información.

79 67 Figura 51: Archivo cvs: datosnoxml utilizado para la transformación y archivo xml: resp_#.xml generado en la transformación. APACHE CAMEL Para realizar la transformación de un archivo cvs a un archivo xml utilizando Apache Camel, se utiliza las rutas de Camel para definir el directorio del cual se lee el archivo y el directorio donde se genera el nuevo archivo, además se definen los formatos con la clase: flatpackdataformat, y se procesa y mapea la información en la clase procesararchivo. Figura 52: Configuración de las rutas de camel para realizar la transformación cvs-xml. Tc1 Para verificar el funcionamiento de la prueba, se añade el archivo cvs en el directorio INPUT y este será procesado automáticamente generándose el archivo xml. Se pueden colocar varios archivos y el tiempo de procesamiento es casi imperceptible.

80 68 Figura 53: Directorios de entrada y salida con un archivo xml generado. A continuación se puede ver en la figura los archivos de entrada y salida con la misma información. Figura 54: archivo cvs y archivo xml con los datos de clientes Canal DeadLetter Tanto Apache Camel como Oracle Service Bus ofrecen un manejador de errores en el que se puede determinar el número de veces que la aplicación intentará realizar la transacción, antes de enviar el error. Para este caso de prueba se configura que el número de intentos sea igual a tres y que el tiempo de espera entre ellos sea de tres segundos. ORACLE SERVICE BUS Con esta herramienta se configura un Proxy Service (ValidacionErrorPS.proxy), donde se utiliza el componente Error Handler

81 69 para realizar el seguimiento y presentación del error. El control del tiempo de espera entre intento, se define mediante una clase que se llama a través del componente Java Callout, donde se definen los tres segundos de espera y se lanza el error. Adicionalmente se configura un Business Service (ValidacionErrorFileBS.biz), en el cual se define el directorio donde se almacenará el archivo de salida del error; esta configuración es opcional. Figura 55: Proyecto CafeteriaError con sus componentes.

82 70 Figura 56: Diseño del flujo del mensaje en el Proxy Service (ValidacionErrorPS.proxy). Para ejecutar el caso de prueba, se despliega el proyecto en el servidor WebLogic. Se presentará una pantalla, donde se ingresa los datos del

83 71 cliente y pedidos en la estructura xml definida. En la siguiente figura se puede observar que al ejecutar la prueba, la aplicación cuenta el tiempo de espera que toma en realizar los intentos determinados. Figura 57: XML de entrada, se presenta el contador de tiempo de espera. En el xml de resultado se desplegará el código y el mensaje del error. Figura 58: XML de salida

84 72 APACHE CAMEL Para configurar el patrón de integración: DeadLetter, se utiliza la propiedad errorhandlerref en el componente <camel:route></camel:route>, aquí se define donde se realiza el manejo del error haciendo la llamada a la clase DeadLetterChannelBuilder y se configura la política (RedeliveryPolicy) que se utilizará, determinando tres intentos cada tres segundos, antes de enviar el error. Figura 59: Configuración de la propiedad errorhandlerref Para ejecutar el caso de prueba se despliega el proyecto sobre el Apache Karaf y utilizando la herramienta soapui, se ejecuta el wsdl.

85 73 Figura 60: XML de entrada con la información En el xml de resultado se desplegará el código y el mensaje de error. Figura 61: XML de salida Captura de Mediciones Para evaluar los casos de prueba que se han desarrollado, se utilizará una herramienta llamada JUnit, la misma que permite realizar pruebas unitarias a las diferentes aplicaciones creadas en java, con el fin de corroborar la correcta aplicación de los patrones y obtener los tiempos de respuesta. Esta

86 74 herramienta se configurará de tal manera, que se ejecute la prueba 100 veces y así obtener las métricas de tiempos de respuesta. Así mismo se realiza otra prueba, esta vez de concurrencia, para determinar la variación de tiempos de respuesta con diez usuarios a la vez. Los resultados de funcionalidad fueron exitosos como se puede ver en la consola del JUnit, tanto para Oracle Service Bus como para Apache Camel. Así mismo, los tiempos de respuesta se presentan en la consola de Eclipse, tanto al ejecutar la prueba de procesamiento y carga transaccional. Figura 62: Consola de JUnit con resultado exitoso de uno de los casos de prueba

87 75 Figura 63: Consola donde se puede ver los tiempos de respuesta generados al realizar la prueba 100 veces. 5. Capítulo V. RESULTADOS A continuación se presentan las tablas de resultados finales tras ejecutar los casos de prueba correspondientes, para cada uno de los patrones de integración Tiempos de Procesamiento

88 76 Tabla 8: Tabla con los resultados finales de los tiempos de respuesta de cada patrón de integración PATRONES DE INTEGRACIÓN Divisor-Agregador Enrutamiento Dinámico Transformador Enrutamiento Basado en Contenido Canal Dead Letter HERRAMIENTA TIEMPO DE RESPUESTA OSB 0,0126 CAMEL OSB 0,0126 CAMEL 0,0112 OSB 0,0069 CAMEL 0,0000 OSB 0,0186 CAMEL 0,0172 OSB 9,0156 CAMEL 9,0133 VALOR MÍNIMO 0,0126 0,0112 0,0000 0,0172 9,0133 Como se puede observar los tiempos se respuesta entre una herramienta y otra presentan diferencias mínimas. Para obtener estos tiempos se ejecutó la prueba tres veces y se realizó un promedio de los resultados. La tabla con los detalles de los estudios se puede ver en el Anexo 3.

89 Carga Transaccional Tabla 9: Tabla con los resultados finales de los tiempos de carga transaccional para cada patrón de integración PATRONES DE INTEGRACIÓN Divisor-Agregador Enrutamiento Dinámico Transformador Enrutamiento Basado en Contenido Canal Dead Letter HERRAMIENTA TIEMPO DE RESPUESTA CON 1 USUARIO TIEMPO DE RESPUESTA CON 10 USUARIOS DIFERENCIA OSB 0,0126 0,0122-0,0003 CAMEL OSB 0,0126 0,0150 0,0024 CAMEL 0,0112 0,0132 0,0020 OSB 0,0069 0,0101 0,0032 CAMEL 0,0000 0,0000 0,0000 OSB 0,0186 0,0308 0,0122 CAMEL 0,0172 0,0275 0,0103 OSB 9,0156 9,0237 0,0081 CAMEL 9,0133 9,0074-0,0059 En esta figura se puede observar como la diferencia de tiempos entre la ejecución de pruebas con un usuario y con diez usuarios, es mínima para las dos herramientas que se han estudiado. La ejecución detallada de esta prueba se puede verificar en el Anexo 4.

90 78 CRITERIOS PARA EVALUAR CADA PATRÓN CRITERIOS PARA EVALUAR CADA PATRÓN CRITERIOS PARA EVALUAR CADA PATRÓN APACHE CAMEL 5.3. Calificaciones Una vez ejecutadas todas las pruebas en las dos herramientas, se presentan las tablas de calificaciones para cada criterio y por cada patrón; según las ponderaciones definidas en el Capítulo III. DEFINICIÓN DE CRITERIOS DE COMPARACIÓN. Tabla 10: Cuadro de evaluación de los Patrones de Integración con cada herramienta PONDERACIÓN POR CRITERIO Calificaciones: 0 = nada satisfactorio, 1 = poco satisfactorio, 2 = satisfactorio, 3 = muy satisfactorio Enrutamiento basado en contenido RESULTADO Traductor de mensajes RESULTADO Precisión 25,4% 3 25,4% 3 25,4% CRITERIOS PARA EVALUAR CADA PATRÓN OSB PONDERACIÓN POR CRITERIO Enrutamiento basado en contenido RESULTADO Traductor de mensajes RESULTADO Precisión 25,4% 3 25,4% 2 25,4% Tiempo de respuesta 73,2% 3 73,2% 3 73,2% Tiempo de respuesta 73,2% 3 73,2% 3 73,2% Facilidad de pruebas 1,5% 3 1,5% 2 1,5% Facilidad de pruebas 1,5% 2 1,5% 3 1,5% APACHE CAMEL CALIFICACIÓN 100% 99,6% PONDERACIÓN POR CRITERIO Divisor de mensajes RESULTADO Agregador de mensajes RESULTADO Precisión 25,4% 3 25,4% 3 25,4% CRITERIOS PARA EVALUAR CADA PATRÓN OSB CALIFICACIÓN 99,6% 91,63% PONDERACIÓN POR CRITERIO Divisor de mensajes RESULTADO Agregador de mensajes RESULTADO Precisión 25,4% 3 25,4% 3 25,4% Tiempo de respuesta 73,2% 3 73,2% 3 73,2% Tiempo de respuesta 73,2% 3 73,2% 3 73,2% Facilidad de pruebas 1,5% 3 1,5% 3 1,5% Facilidad de pruebas 1,5% 1 1,5% 3 1,5% APACHE CAMEL CALIFICACIÓN 100% 100% PONDERACIÓN POR CRITERIO Enrutamiento dinámico RESULTADO Canal de DeadLetter RESULTADO Precisión 25,4% 3 25,4% 3 25,4% CRITERIOS PARA EVALUAR CADA PATRÓN OSB CALIFICACIÓN 99,1% 100% PONDERACIÓN POR CRITERIO Enrutamiento dinámico RESULTADO Canal de DeadLetter RESULTADO Precisión 25,4% 3 25,4% 3 25,4% Tiempo de respuesta 73,2% 3 73,2% 3 73,2% Tiempo de respuesta 73,2% 3 73,2% 3 73,2% Facilidad de pruebas 1,5% 2 1,5% 3 1,5% Facilidad de pruebas 1,5% 3 1,5% 1 1,5% CALIFICACIÓN 99,6% 100% CALIFICACIÓN 100% 99,1%

91 79 Tabla 11: Resultados finales de la comparación de los Patrones de Integración entre Apache Camel y Oracle Service Bus GRUPO PATRONES DE INTEGRACIÓN CARACTERÍSTICAS PONDERACIÓN POR CARACTERÍSTICA APACHE CAMEL RESULTADO OSB RESULTADO Enrutamiento basado en contenido 23,4% 100,0% 23,40% 99,6% 23,31% Traductor de mensajes 23,4% 99,6% 23,31% 91,6% 21,44% Enrutamiento dinámico 3,2% 99,6% 3,19% 100,0% 3,20% Divisor de mensajes 23,4% 100,0% 23,40% 99,1% 23,19% Agregador de mensajes 23,4% 100,0% 23,40% 100,0% 23,40% Canal de DeadLetter 3,2% 100,0% 3,20% 99,1% 3,17% CALIFICACIONES POR HERRAMIENTA: 99,89% 97,71% Cabe recalcar que las calificaciones fueron determinadas según el criterio del autor de este trabajo de titulación, tomando en cuenta su experiencia a través de este estudio.

92 Otros criterios de comparación En este trabajo de titulación se definieron ciertos patrones con los cuales se realiza la comparación entre las herramientas Apache Camel y Oracle Service Bus y para ellos se construyen ejemplos prácticos. Como valor agregado, se expondrán a continuación, una serie de criterios en base a la experiencia del usuario, juicio de expertos e información obtenida de las especificaciones técnicas y de la comunidad de cada herramienta. El objetivo es obtener algunos conocimientos adicionales de las características que ofrecen las dos herramientas que son objeto de este estudio. A continuación se define cada uno de los criterios que serán evaluados: ü Mantenimiento.- La capacidad que tiene la herramienta para proporcionar componentes que faciliten la administración de sus flujos o procesos. ü Soporte no Empresarial.- Soporte informal con el que cuentan las herramientas. ü Soporte Empresarial.- Soporte formal con el que cuentan las herramientas. ü Funcionalidad.- La capacidad que tiene la herramienta para realizar integraciones a través de los patrones. ü Nuevos Componentes.- La capacidad que tiene la herramienta para crear nuevos componentes a partir de los ya incorporados. ü Conectores.- Disponibilidad de conectores para realizar los trabajos de integración entre diferentes plataformas y formatos. ü Costos.- Costos que tienen los servicios que ofrece cada herramienta. ü Licencia.- Necesidad y modo de licenciamiento para los servicios que ofrecen las herramientas. ü Seguridad.- Componentes o servicios que ofrece la herramienta para manejar la seguridad de sus procesos. ü Instalación.- Complejidad de instalación.

93 81 ü Usabilidad.- Facilidad que se ofrece al usuario al momento de utilizar la herramienta. Para evaluar estos criterios se catalogará cada uno de ellos, con un color que tendrá un peso definido: ü Verde à 3 ü Azul à 2 ü Rojo à 1 Esta evaluación se realizará a criterio del autor del presente trabajo de titulación. Tabla 12: Comparación de criterios adicionales para las herramientas Apache Camel y OSB CRITERIO APACHE CAMEL OSB Mantenimiento Soporte no Empresarial Soporte Empresarial Funcionalidad Nuevos Componentes Existen componentes en otros proyectos de código abierto que ofrecen mantenimiento a los procesos de Camel, como: hawtio, CamelWatch y RHQ Debido a que los proyectos son de código abierto, se obtiene información y soporte de la misma comunidad. Existen empresas que se dedican a dar soporte y capacitaciones a la herramienta. Menos garantizado que el soporte propietario. Disponible 24/7 Ofrece funcionalidad de integración aplicando los diferentes patrones. Cambios personalizados en cualquier momento, según Ofrece componentes y consolas avanzadas de monitoreo de procesos, como: Weblogic, Enterprise Management, OSB. Existe una gran cantidad de foros y conocimiento compartido sobre la herramienta, pero el apoyo de la comunidad de Oracle como tal, es soporte con costo. Soporte personalizado basado en SLAs (Service Level Agreement). Disponible 24/7 Ofrece funcionalidad de integración aplicando los diferentes patrones. Cambios bajo petición, pagados y largo tiempo de

94 82 Conectores Costos Licencia Seguridad los conocimientos del usuario. Permite crear nuevos componentes. Diferentes adaptadores para tecnologías y productos. Cuenta con mensajería soportada. Alrededor de 150 conectores disponibles. Costos por soporte. Modo de suscripción. Los procesos de Autenticación, Encriptación, Autorización y Auditoría son complejos de utilizar, según el conocimiento del usuario. espera. Cambios bajo petición, a corto tiempo de espera con altos costos. Diferentes adaptadores para tecnologías y productos. Cuenta con mensajería soportada. Aproximadamente 20 conectores, entre los más utilizados. Costos por licencia, soporte, número de usuarios, etc. Actualización o migración pagadas. Cuenta con procesos de Autenticación, Encriptación, Autorización y Auditoría en sus diferentes consolas de administración. Instalación Sin instalación Compleja Usabilidad La interfaz gráfica se otorga bajo suscripción. Curva de aprendizaje baja, para usuarios con perfiles técnicos. Cuenta con interfaces gráficas amigables al usuario. Su curva de aprendizaje es media para usuarios con perfiles de negocio o perfiles poco técnicos. Los resultados que esta evaluación arroja, se presentan a continuación: Tabla 13: Resultados de la comparación de los criterios adicionales. VALOR MAXIMO RESULTADOS % OSB APACHE CAMEL VERDE AZUL ROJO TOTAL % 85%

95 83 Tomando en cuenta los resultados, se define que la herramienta que se va a utilizar para realizar el prototipo, en el siguiente capítulo, es Apache Camel Costos Al hablar de costos en este trabajo de titulación no se realizará una comparación específica entre las herramientas que son el objeto de este estudio, sin embargo se expone a continuación las características de las mencionadas herramientas en cuanto a este tema: Oracle Service Bus En términos comerciales la instalación del OSB se lo realiza sobre el servidor WebLogic Enterprise Edition y ambos productos son licenciados, pagando para el soporte el 22% anual del valor de dichas licencias. Tomando en cuenta esta información se presenta las siguientes tablas de costos: Tabla 14: Costos de WLS y OSB por procesador Valor por procesador Oracle WebLogic Server Enterprise Edition Licencia $ 25, Soporte anual $ 5, Subtotal 1 $ 30, Oracle Service Bus Licencia $ 23, Soporte anual $ 5, Subtotal 2 $ 28, Total $ 58,560.00

96 84 Tabla 15: Costos de WLS y OSB por usuario nombrado Valor por usuario nombrado Oracle WebLogic Server Enterprise Edition Licencia $ Soporte anual $ Subtotal 1 $ Oracle Service Bus Licencia $ Soporte anual $ Subtotal 2 $ Total $ 1, Vale recalcar que la herramienta de desarrollo es libre de costo Apache Camel Al ser Apache Camel una herramienta de código abierto su utilización no tiene costo alguno y debido a su concepción tampoco cuenta con soporte pagado ya que este se obtiene de la comunidad del producto. Existen productos basados en Apache Camel que cuentan con versiones comerciales, las cuales tienen un costo de soporte anual. Para poner un ejemplo concreto se mencionará a Fuse ESB que es un producto de código abierto que no cuenta con licencia, mas su costo de soporte anual hasta con cuatro procesadores en el servidor de producción es de 10, USD. 1. Capítulo VI. PROTOTIPO Como se mencionó en el capítulo IV. ESCENARIOS DE TOMA DE DATOS, el contexto de los casos de prueba de cada uno de los patrones de integración, fue definido de tal manera que al realizar el prototipo se puedan utilizar los mismos ejemplos, formando una sola aplicación. En el presente prototipo se ingresarán los datos del cliente y sus pedidos, los cuales cuentan con las mismas restricciones y resultados de los casos de prueba realizados anteriormente:

97 85 ü Los pedidos son bebidas de tipo fria o caliente. ü Se pueden incluir varios pedidos por cliente. ü Si el cliente es de tipo NORMAL, el pedido será procesado. ü Si el cliente es de tipo PREFERENTE, el pedido será procesado y pagado Construcción Para la construcción del prototipo se elaboran los flujos de mensajes (rutas de Camel) donde se recibe y procesa la información antes de presentar el resultado final. A continuación se explicará cada una de las mencionadas rutas: Con el componente <camel:from>, se define el wsdl de donde se obtiene la información: estructura de datos y operaciones y la dirección donde será publicado el servicio en el Apache Karaf. Figura 64: Ruta <camel:from> del Prototipo Con el componente <camel:process>, se procesa la información en la clase inputprocessor, donde se obtiene dicha información de entrada para ser guardada en el body del contexto de Camel. Mediante el componente <camel:setheader> y <camel:simple>, se define que la información ingresada es de tipo cliente y que el nombre será el identificador; esto se realiza con el objetivo de conocer a cual cliente pertenece la información procesada de pedidos. Figura 65: Rutas: <camel:process>, <camel:setheader> y <camel:simple> del Prototipo

98 86 Una vez que se cuenta con la información de entrada, se utiliza el componente <camel:split> para separar cada pedido y procesarlo de manera paralela, así se aplica en patrón Splitter o Divisor de Mensajes en la elaboración del prototipo. Figura 66: Ruta <camel:split> del Prototipo Cuando los pedidos se encuentran separados, se utilizan los componentes <camel:choice> y <camel:when> para evaluar en cada uno de dichos pedidos, si la bebida es fría o caliente; y dependiendo del resultado se añade el valor correspondiente en la etiqueta de estado de cada pedido. Con esto se aplica el patrón de integración Content-Based Router o Enrutamiento Basado en Contenido. Figura 67: Rutas <camel:choice> y <camel:when> del Prototipo Después de que todos los pedidos han sido procesados, mediante el componente <camel:dynamicrouter>, se comprueba si el tipo de cliente es

99 87 NORMAL o PREFERENTE; y según el resultado se presentará el mensaje final en la etiqueta estado de cada pedido. Aquí se utiliza el patrón de integración Dynamic Router o Enrutamiento Dinámico. Figura 68: Ruta <camel: dynamicrouter> del Prototipo Para finalizar, con el componente <camel:process> que se puede observar en la figura 61, utilizando la clase outputprocessor, se convierte la información de salida de tipo cliente, a información de tipo pedidos y así, en la presentación del resultado, se desplegarán todos los pedidos procesados según el tratamiento que se realizó sobre cada uno Pruebas y Resultados Para realizar las pruebas sobre el prototipo, se utiliza la misma estructura que se empleó en la ejecución de los casos de prueba de los patrones de integración, aplicando las pruebas unitarias para obtener tiempos de procesamiento y carga transaccional.

100 Cliente NORMAL Tabla 16: Datos de entrada para ejecutar la prueba sobre el prototipo con el tipo de cliente Normal. Información de entrada Valores Nombre Juan Apellido Andrade Fecha de ingreso Tipo NORMAL Pedidos Pedido 1: Nombre agua Tipo fria Precio 1,00 Estado ingresado Pedido 2: Nombre café Tipo caliente Precio 1,50 Estado ingresado Pedido 3: Nombre té Tipo tibio Precio 2,00 Estado ingresado

101 Figura 69: Resultado de la prueba realizada con el prototipo de un cliente NORMAL. 89

102 Cliente PREFERENTE Tabla 17: Datos de entrada para ejecutar la prueba sobre el prototipo con el tipo de cliente Preferente. Información de entrada Valores Nombre Samanta Apellido Lara Fecha de ingreso Tipo PREFERENTE Pedidos Pedido 1: Nombre capuchino Tipo caliente Precio 3,00 Estado ingresado Pedido 2: Nombre agua aromática Tipo fria Precio 1,00 Estado ingresado Pedido 3: Nombre latte Tipo tibio Precio 3,20 Estado ingresado

103 91 Figura 70: Resultado de la prueba realizada con el prototipo de un cliente PREFERENTE. Las pruebas realizadas sobre el prototipo arrojan los siguientes resultados: Tabla 18: Resultados de las pruebas unitarias para el Prototipo TIEMPOS DE RESPUESTA 1 USUARIO 10 USUARIOS DIFERENCIA PROTOTIPO 0,0196 0,0697 0,0501 El detalle de estos resultados se puede verificar en el Anexo 3 y Anexo Capítulo VII. CONCLUSIONES Y RECOMENDACIONES Del presente trabajo de titulación se presentan las siguientes conclusiones y recomendaciones: 1. Se elaboraron diferentes casos de prueba para cada herramienta, aplicando diferentes patrones de integración, que según juicio de expertos, son algunos de los más populares. Adicionalmente la selección de estos

104 92 patrones fue en base a la existencia de documentación apropiada acerca de la aplicación de dichos patrones. Cabe mencionar que la principal causa de que algunos de los patrones de integración se hayan omitido en este estudio, es la complejidad de su implementación versus el tiempo con el que se contaba para la elaboración del presente trabajo de titulación. 2. Del trabajo realizado, y a criterio del autor, la herramienta Oracle Service Bus no es tan intuitiva como si lo es Apache Camel, por lo cual, fue necesario acudir a la documentación oficial del proveedor encontrando que la misma se limitaba a explicar la interfaz del producto sin exposición de tutoriales, para lo cual se tuvo que extender la búsqueda a grupos de discusión y foros relacionados a la materia. En relación a Apache Camel, se encontró un buen número de documentación oficial acerca de la aplicación de cada una de sus funcionalidades, presentando ejemplos puntuales para el efecto. Por esta razón el tiempo-esfuerzo en ejecutar los casos de prueba de Apache Camel fue mucho menor que el invertido en el OSB. 3. Oracle Service Bus cuenta con varias consolas de control y monitoreo de sus procesos, que son parte de la suite, mientras que Apache Camel requiere integrarse con otros productos para lograr esta característica; por lo tanto, en este tema, OSB tiene una ventaja sobre Apache Camel. Pero por otro lado, esto podría aprovecharse al construir soluciones a la medida. 4. Apache Camel ofrece una gran cantidad de conectores disponibles para integrar diferentes sistemas; lo que otorga una gran flexibilidad si se presentara una necesidad adicional de crear o combinar los conectores existentes. Además, es relativamente fácil, dependiendo de la profundidad de conocimientos de la herramienta. 5. No se puede determinar cuándo un tiempo de respuesta es aceptable para todos los casos, pero la teoría dice que este tiempo puede variar dependiendo de la carga que se realice sobre la aplicación y la complejidad del procesamiento de los datos de entrada; por esta razón, para la presente evaluación se considera que un par de segundos como tiempo de respuesta es aceptable.

105 93 6. En general, los tiempos de respuesta de las pruebas ejecutadas para Apache Camel y OSB en cuanto a procesamiento, carga transaccional y fiabilidad, tomaron menos de un segundo por proceso y por lo tanto fueron exitosas. Con esto se puede concluir, en base al alcance de este trabajo, que Apache Camel es una herramienta de código abierto, que responde de la misma forma que lo hacen herramientas propietarias como OSB, cuando se trata de implementar la esencia de los patrones aquí definidos. 7. Tanto las comparaciones prácticas como teóricas realizadas en el presente trabajo, pueden aportar en la toma de decisiones de diferentes empresas que se dediquen a realizar proyectos de integración, debido a que se presentan casos de prueba puntuales para ciertas necesidades como: definición del enrutamiento de mensajes, manejo de errores, división, agregación y traducción de información; y adicionalmente se expone la fortaleza en cada una de las características más importantes de ambas herramientas, con lo cual se podrán evaluar ventajas y desventajas de la utilización de Apache Camel y Oracle Service Bus dependiendo del tipo de proyecto de integración que se busque realizar. 8. En base a la experiencia del autor, se puede concluir que las prestaciones de la herramienta Apache Camel serán mejor aprovechadas en función del nivel de conocimiento del lenguaje de programación java que tenga el usuario desarrollador, ya que una gran parte de configuraciones se realizan a través de código. 9. En base a la experiencia del autor, se puede concluir que un usuario desarrollador que pretenda aprovechar de mejor manera las prestaciones de la herramienta Oracle Service Bus deberá tener un conocimiento intermedio en temas de web services, ya que la metáfora de uso de la herramienta está basado en estos elementos. 10. En relación a la instalación de las herramientas, se recomienda para el caso de OSB ser muy meticuloso a la hora de aplicar lo indicado en la guía de instalación pues su arquitectura de componentes demanda cuidado y orden en la instalación y configuración de los mismos.

106 A pesar de que los tiempos de respuesta del estudio realizado entre ambas herramientas, no tuvieron mayor diferencia, Apache Camel consiguió una leve mejora, con un tiempo promedio de ms, en comparación a los ms de OSB. Por esta razón y a criterio del autor de esta tesis, se determinó que el prototipo realizado sería con Apache Camel.

107 95 REFERENCIAS Alesso, P. (2008) Tips para optimización de la solución en POCs con Oracle Service Bus. Recuperado el 1 de marzo del 2013 de Apache Camel Architecture Recuperado el 1 de marzo del 2013 de Adictos al trabajo Trabajando con los Web Services de Liferay. Recuperado el 21 de marzo del 2013 de WebServices Agencia de Informática y Comunicaciones de la Comunidad de Madrid (2012). Oracle Service Bus: Entorno de Desarrollo. Recuperado el 27 de mayo del 2013 de Presentaciones/ESB_FOR_INTRODUCCION.pdf Beck, K. y Cunningham, W. (1987). Using Pattern Languages for Object- Oriented Programs. Recuperado el 22 de febrero del 2013 de Cabalar, P. y Cabarcos, M. (2011). JUnit: Primeros pasos. Recuperado el 4 de Junio del 2013 de Definicion.de. Sistema de Información. Recuperado el 19 de febrero del 2013 de Definicion.de. Integración. Recuperado el 19 de febrero del 2013 de Definicion.de. Patrón. Recuperado el 21 de febrero del 2013 de

108 96 eappware Enterprise Service Bus. Recuperado el 25 de febrero del 2013 de Espinoza, M. (2000). Sistemas operativos para redes punto a punto. Recuperado el 28 de febrero del 2013 de Emerald Enabling the Real-time Enterprise: Enterprise Application Integration with CrossWorlds Software. Recuperado el 10 de marzo del 2013 de Echeverría, D., Astudillo, H. y Estrada, R. ESB-QM: Modelo de Calidad para productos ESBs. Recuperado el 21 de marzo del 2013 de hawtio hawtio Recuperado el 19 de Julio del 2013 de Ibsen, C. (2009). Enterprise Integration Patterns with Apache Camel. Recuperado el 7 de enero del 2013 de Ibsen, C. y Anstey, J. (2010). Camel in Action (1º. ed.). Stamford, Connecticut, EEUU: Manning Publications Co Idea (Instituto para el desarrollo empresarial administrativo) Herramientas de Calidad Recuperado el 4 de abril del 2013 de on.doc Junco, P (2013). Patrones de Integración. Recuperado el 22 de febrero del 2013 de Kioskea.net

109 97 Microsoft Integración de aplicaciones empresariales (EAI) Recuperado el 28 de febrero del 2013 de Introduction to the BizTalk ESB Toolkit. Recuperado el 25 de febrero del 2013 de Maestros del web msdn Oracle Qué son las bases de datos? Recuperado el 21 de marzo del 2013 de BizTalk Messaging, Implementación del Patrón MESSAGE BROKER Recuperado el 21 de marzo del 2013 de Oracle Fusion Middleware Concepts and Architecture for Oracle Service Bus 11g Release 1 ( ) Recuperado el 1 de marzo del 2013 de rview.htm#sthref62 OZEKI NG SMS Gateway How to send SMS text messages in CSV file format Recuperado el 21 de marzo del 2013 de Oracle. (2011). Quick Start Guide for Oracle SOA Suite 11gR1 ( ). Recuperado el 15 de marzo del 2013 de html Oracle (2010). Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus 11g Release 1 ( ). Part Number E Proxy Services: Creating and Managing. Recuperado el 27 de mayo del 2013 de

110 98 tm#autoid10 Oracle (2010). Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus 11g Release 1 ( ). Part Number E Configuring Proxy Services and Business Services. Recuperado el 4 de junio del 2013 de ingservices.htm Oracle (2013). Oracle Service Bus. Essential Concepts. Recuperado el 6 de Junio del 2013 de Revista Negocios de Seguridad. Integración de Sistemas de Seguridad. Recuperado el 20 de febrero del 2013 de Suárez, D (2009). SG 09 Patrones de Integración Empresarial Apache Camel. Recuperado el 1 de febrero del 2013 de (Fuentes de la referencia revisadas) SearchSOA The difference between EAI and ESB Recuperado el 28 de febrero del 2013 de Shridhar, S. (2011). Oracle Service Bus 11g: Design and Integrate Services. (1º. ed.). California, EEUU: Oracle Tutor Summers, A. (2010). CARACTERÍSTICAS DE CLIENTE-SERVIDOR. Recuperado el 10 de marzo del 2013 de The Apache Software Foundation (2011). Components Included. Recuperado el 27 de mayo del 2013 de

111 99 Vollmer, K. (2011) The Forrester Wave : Enterprise Service Bus, Q Recuperado el 26 de Julio del 2013 de wave-esb-q pdf?version=1&modificationDate= Wordreference.com. Patrón. Recuperado el 21 de febrero del 2013 de Wikipedia. La enciclopedia libre. Enterprise application integration Recuperado el 28 de febrero del 2013 de y Wikipedia La Enciclopedia Libre Extensible Markup Language. Recuperado el 21 de marzo del 2013 de _un_documento_xml Wikipedia La Enciclopedia Libre Servicio web. Recuperado el 21 de marzo del 2013 de Wikipedia. La enciclopedia libre. OSGi Recuperado el 28 de febrero del 2013 de Wikipedia La Enciclopedia Libre Representational state transfer. Recuperado el 21 de marzo del 2013 de Wikipedia La Enciclopedia Libre CSV

112 100 Recuperado el 21 de marzo del 2013 de Wikipedia La Enciclopedia Libre Java class file Recuperado el 21 de marzo del 2013 de wordpress.com decompiled-java-class-from-jar-file Recuperado el 21 de marzo del 2013 de Wikipedia La Enciclopedia Libre XML Schema Recuperado el 22 de mayo del 2013 de Wikipedia La Enciclopedia Libre Wikipedia WSDL Recuperado el 22 de mayo del 2013 de JUnit Recuperado el 4 junio del 2013 de Wähner, K. (2013) Spoilt for Choice: How to Choose the Right Enterprise Service Bus (ESB)?. Recuperado el 09 de junio del 2013 de

113 ANEXOS 101

114 102 ANEXO 1: Encuestas Encuestas realizadas a cuatro expertos en el tema de ESB para determinar la importancia de cada característica y criterio de comparación.

115 103

116 104

117 105

118 106

119 107

120 108

121 109