El desarrollo de aplicaciones en diversas plataformas y lenguajes en una empresa, es un caso de uso muy común que se presenta a lo largo del tiempo. Así mismo, la necesidad de poder integrar los datos de estas diversas aplicaciones, muchas veces incompatibles entre si, lleva a la necesidad de desarrollar aplicaciones que se encarguen del intercambio de estos datos para lograr un consolidado de información que aporte valor a la empresa.
Al momento de diseñar este tipo de aplicaciones, es común el observar patrones una y otra vez. Dichos patrones han sido recopilados y documentados por Gregor Hohpe y Bobby Woolf en su libro "Enterprise Integration Patterns", en el cual ofrecen una visión completa y muy bien explicada de estos patrones, así como de una nomenclatura que se ha vuelto estándar para representar estos patrones.
Apache Camel es la implementación de la gran mayoría de los patrones propuestos por Gregor y Bobby para la plataforma Java y de manera OpenSource bajo licencia Apache 2.0. Apache Camel es una alternativa a diversas herramientas comerciales para realizar aplicaciones empresariales de integración de aplicaciones.
En la conferencia se mostraran los patrones mas comunes, su notación, diseño e implementación usando Apache Camel, de igual manera se mostrara la infraestructura necesaria para ejecutar Apache Camel, los mecanismos de monitoreo de aplicaciones desarrolladas con Camel y como se puede integrar con productos de integración como Brokers de Mensajería (JMS), Enterprise Service Bus (ESB) y servidores de aplicaciones clásicos.
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
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
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 edita en 1995
• Usa una estructura muy
estructurada 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
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
como piedra angular para la
integración.
17
19. Apache Camel
Me gusta el OpenSource.
A veces no tenemos dinero para
adquirir licencias.
19
20. Apache Camel
• Es un poderoso framework que implementa
gran cantidad de los EIP
• http://camel.apache.org
20
21. Apache Camel
• Bajo la licencia Apache 2.0
• Puedes implementar reglas de ruteo y
mediación con:
– Un Domain Specific Language (DSL) basado
en Java
– Con XML (Spring)
– Con un DSL en Scala
• Utiliza URIs para identificar los endpoints
de la aplicación
21
23. 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
23
24. 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?
24
25. 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
25
26. CamelContext
• Es un objeto que representa el sistema de
ejecución de Camel
• Administra el ciclo de vida de los
componentes configurados en Camel
26
27. 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");
27
28. Tipos de componentes
• Apache Camel soporta múltiples
componentes entre ellos:
– JMS
– FTP
– POP3, SMTP
– WebServices
– Archivos
– Protocolo FIX
– Hibernate
– HL7 (Estandar Médico)
– Sockets con Apache Mina
28
29. Caso de estudio
Cámara de Compensación del
Mercado de Derivados
29
30. 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
30
31. 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
31
32. 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.
32