SG 09 Patrones de Integración Empresarial Apache Camel
4 recomendaciones3,014 vistas
El documento describe la integración de aplicaciones utilizando Apache Camel y patrones de integración empresarial, enfocándose en la reutilización de soluciones probadas para resolver problemas comunes de integración. Se abordan los principios y beneficios de la mensajería asíncrona, así como la implementación efectiva de reglas de ruteo mediante un framework de código abierto. Finalmente, se presenta un caso de estudio que ilustra cómo utilizar Apache Camel para la integración de componentes en un entorno empresarial.
SG 09 Patrones de Integración Empresarial Apache Camel
- 1. Enterprise Integration Patterns Apache Camel Domingo Suárez Torres CTO SynergyJ
- 2. Objetivo Comprender los beneficios de usar Patrones para Integrar aplicaciones usando OpenSource con Apache Camel 2
- 3. Agenda • Patrones de diseño • Patrones de Integración Empresarial (EIP) • Integración en la plataforma Java – Bajo nivel • Sockets • WebServices • EJB – SessionBeans – Message Driven Beans (JMS) – Alto nivel • J2EE Connector Architecture (JCA) • Java Business Integration (JBI) • Caso de estudio con Apache Camel 3
- 4. Patrones de Diseño Antecedentes 4
- 5. Volumen I • En 1979 el arquitecto Christopher Alexander escribe: – “The Timeless Way of Building” • El libro en Google Books – http://bit.ly/qK1nH 5
- 6. Volumen II • Editado en 1977 • Libro en Google Books – http://bit.ly/14NKKk 6
- 7. The Timeless Way of Building • En el libro se propone el aprendizaje y uso de una serie de patrones para la construcción de edificios de una mayor calidad. 7
- 8. The Timeless Way of Building • "Cada patrón describe un problema que ocurre infinidad de veces en nuestro entorno, así como la solución al mismo, de tal modo que podemos utilizar esta solución un millón de veces más adelante sin tener que volver a pensarla otra vez." 8
- 9. OOPSLA-87 • En 1987, Ward Cunningham y Kent Beck usan las ideas de Alexander y publican un articulo • Using Pattern Languages for OO Programs. • http://bit.ly/o8YkZ 9
- 10. Principios de los 90’s • Se publica en 1995 • Usa una estructura muy simple para explicar los patrones: – Nombre del patrón – Problema – Solución – Consecuencias 10
- 11. Enterprise Integration Patterns Evolución de los patrones de diseño a contextos más específicos, en este caso a la integración de aplicaciones. 11
- 12. Necesidad de la integración • Aplicaciones legadas. • Variedad de plataformas y tecnologías. • Carencia de estándares bien definidos. – Cada proveedor define su tecnología. • Aplicaciones de terceros • eGoverment • Socios comerciales 12
- 13. Aplicaciones de integración • Necesarias para servir de puente entre las aplicaciones • Traduce y adapta tipos de datos • Se encarga del medio de transporte asi como del protocolo • En el mercado existen productos para este tipo de necesidades 13
- 14. Mercado • Enterprise Service Bus – Progress Software – Oracle – Sun – IBM – Tibco • Mucho dinero $ y muchas otras opciones... 14
- 15. OpenSource • Apache ServiceMix • OpenESB • Mule • Fuse • Apache Camel es la base de varios de estos proyectos 15
- 16. Volvamos a lo básico • Patrones – Casi todos los problemas de integración ya han sido resueltos – Muchos patrones están construidos en los diversos productos, ya sean propietarios o de código abierto. – Necesario documentarse en el tema. 16
- 17. Literatura • Publicado en 2004 • Excelente referencia para diseñar y construir aplicaciones de integración. • Recopila 65 patrones para integrar aplicaciones. • Plantea a la mensajería asíncrona como piedra angular para la integración. 17
- 18. ¿Porque mensajería? • Comunicación de aplicaciones a aplicaciones • Asíncrono • La información se intercambia como mensajes sobre canales • Confiable (durable). Se permiten operaciones sin conexión • Mejora el uso de hilos • Transaccional 18
- 19. Enterprise Integration Patterns • Plantea una nomenclatura estándar para modelado y diseño de la solución. 19
- 20. Diagrama sencillo 20
- 21. Mensajes 21
- 22. Filtros y pipes 22
- 23. Ruteo de mensajes 23
- 24. Traducción de mensajes 24
- 25. Algo más elaborado 25
- 26. Plantillas • OmniGraffle – http://bit.ly/11Bq7X • OpenOffice – http://bit.ly/14zt3t • Microsoft Visio – http://bit.ly/3FGtN4 26
- 27. EIP • Pros – Escalamiento – Desacoplamiento – Pruebas de unidad (Unit Testing) • Contras – Latencia VS rendimiento (throughput) – Pruebas de integración (Integration Testing) – Desacoplamiento no es siempre lo mas adecuado 27
- 28. Apache Camel Me gusta el OpenSource. A veces no tenemos dinero para adquirir licencias. 28
- 29. Apache Camel • Es un poderoso framework que implementa gran cantidad de los EIP • http://camel.apache.org 29
- 30. Apache Camel • Bajo la licencia Apache 2.0 • Puedes implementar reglas de ruteo y mediación con: – Un Domain Specific Language (DSL) en Java – Con XML (Spring) – Con un DSL en Scala • Utiliza URIs para identificar los endpoints de la aplicación 30
- 31. Apache Camel Conceptos Fundamentales 31
- 32. Endpoint • Es un termino común usado en comunicaciones del tipo inter-proceso (inter- process communication) • Dependiendo del contexto, un endpoint puede referirse a una dirección, como el par servidor:puerto, para una comunicación basada en TCP • O puede ser una entidad de software que responde a una dirección, • Ejemplo: – www.servidor.com:80 32
- 33. Tipos de Endpoint • ServerSocket o ClientSocket • Un WebService • Un Archivo • Servidor de FTP • Un Destination de JMS • Una dirección de correo • Un Plain Old Java Object (POJO) • ¿Se entiende la idea? 33
- 34. URIs • Uniform Resource Identifier • Sirven para identificar los endpoints • Desacopla el componente que va a ser usado • Es similar a una URL • Ejemplo: – foo:0000-0000-9E59-0000-5E-2 34
- 35. CamelContext • Es un objeto que representa el sistema de ejecución de Camel • Administra el ciclo de vida de los componentes configurados en Camel 35
- 36. Componentes • EndpointFactory es un mejor nombre, componente es un nombre confuso • Se necesita un URI para crear el componente • Ejemplos: myCamelContext.getEndpoint("pop3:// john.smith@mailserv.example.com? password=myPassword"); myCamelContext.getEndpoint("ftp://server? user=ss&password=myPassword"); 36
- 37. Tipos de componentes • Apache Camel soporta múltiples componentes entre ellos (+70): – JMS – FTP – POP3, SMTP – WebServices – Archivos – Protocolo FIX – Hibernate – HL7 (Estandar Médico) – Sockets con Apache Mina – Personalizables 37
- 38. Usando Camel 38
- 39. Regla simple de ruteo from(“aUri”).to(“anotherUri”); 39
- 40. Integración de componentes Archivo Message Message Message JMS Channel Translator Channel POJO 40
- 41. Ruteador Basado en Contenido 41
- 42. Caso de estudio Cámara de Compensación del Mercado de Derivados 42
- 43. Requerimiento • Recibir los hechos de operaciones del mercado mexicano de derivados • Validar la información. • Integrarla a los diversos sistemas de la cámara de compensación – AS/400 con RPG y Cobol – Java EE sobre Solaris con WebLogic y Oracle • Monitorear la actividad del mercado para realizar operaciones preventivas y correctivas 43
- 44. Detalle aburrido • Recibir tramas de información través de un Socket. • Separar los registros recibidos • Validar numero de secuencia • Bitacorar el registro • Ejecutar lógica de negocio • Generar reporte estadístico de la información • Integrar información al sistema de la empresa 44
- 45. Solución • Uso de SpringFramework • Camel se integra sin problemas con Spring • Escritura de reglas de ruteo y mediación simples y sencillas • El desarrollo se concentro en escribir POJOS, nada complicado y fácil de probar. • Altamente personalizable y configurable • Sin costo de licencias. 45
- 46. Contexto Message Message JMS-ActiveMQ SocketServer Message Splitter Event-Driven Channel Translator Channel Consumer JMS-Weblogic Transactional Content Based Message Channel Resequencer Client Router Translator Event-Driven Consumer Control Bus 46
- 47. Conclusiones EIP y Apache Camel 47
- 48. Conclusiones • La implementación de los EIP fue una buena decisión • Permitió reutilizar ideas y soluciones probadas • La arquitectura quedo muy bien definida, clara y de fácil comprensión • Incluso el usuario pudo entender y opinar sobre nuestros modelos de diseño (Nomenclatura estándar de EIP) 48
- 49. Apache Camel • No tuvimos que implementar casi nada de infraestructura • Usamos la infraestructura disponible • No pagamos licencias • Usamos las facilidades del servidor de aplicaciones y agregamos el excelente funcionamiento de ActiveMQ 49
- 50. Apache Camel • La implementación de la logica de negocio fue en Java Puro • Facilito implementar pruebas de unidad muy simple • No fue necesario utilizar herramientas especiales, solo el IDE (Eclipse) • Alto performance • Aplicación integrada a todos los procesos de negocio de la cámara de compensación. 50
- 51. Contexto Message Message JMS-ActiveMQ SocketServer Message Splitter Event-Driven Channel Translator Channel Consumer JMS-Weblogic Transactional Content Based Message Channel Resequencer Client Router Translator Event-Driven Consumer Control Bus 51
- 52. Preguntas y Respuestas domingo.suarez@synergyj.com twitter: @domix Presentación: http://slideshare.net/domingo.suarez
- 53. Créditos de las fotos • http://www.flickr.com/photos/elvispayne/2074381213/ • http://www.flickr.com/photos/samiksha/429302387/ • http://www.flickr.com/photos/vetrone/3046845038/ • http://www.flickr.com/photos/elpei/812950306/ • http://www.flickr.com/photos/stevephillips/238560751/ • http://www.flickr.com/photos/pensiero/628674486/ • 53