Iván López Martín presentó sobre arquitecturas orientadas a eventos y cómo pueden mejorar el rendimiento de aplicaciones, permitiendo procesar tareas de forma asíncrona y en paralelo. Discutió cómo Spring Integration y el Framework Reactor pueden usarse para construir aplicaciones basadas en eventos de forma flexible y testeable. También mostró ejemplos prácticos usando estas tecnologías con Grails.

1. Iván López Martín @ilopmar
¡Quiero Tiempo Real y lo
quiero para ayer!

2. ¿Quién soy?
Iván Lopez Martín @ilopmar
Trabajo en Kaleidos
Uso Groovy/Grails desde hace casi 4 años
Creador de www.bokzuy.com
Creador de varios plugins de Grails
Sospechoso habitual de Madrid-GUG (Groovy User Group)
Geek, padre, desarrollador, sysadmin, linuxero y pro-software libre

3. Arquitecturas tradicionales
Request-response
POST /register-user
POST /register-user
POST /register-user

4. Arquitecturas tradicionales

5. Arquitecturas tradicionales

6. A problem postponed is a problem solved
really?

7. Arquitecturas orientadas a eventos
- Event Driven Architecture (EAD)
- Fire & Forget
- Desacoplan al productor del consumidor
- Acción inmediata en los consumidores
- Tiempo real / Notificaciones push

8. Arquitectura tradicional
Ejemplo arquitectura tradicional (request-response)
POST /purchase
- Recibir petición 5 ms
- Validación de datos 20 ms
- Guardar 40 ms
- Generar PDF 200 ms
- Enviar email 80 ms
- Renderizar respuesta 50 ms
POST /purchase
Total 395 ms

9. Can we do it better?

10. Arquitecturas orientadas a eventos
Ejemplo EDA
POST /purchase
- Recibir petición 5 ms
- Validación de datos 20 ms
- Guardar 40 ms
- Generar PDF 200 ms
- Enviar email 80 ms
- Renderizar respuesta 50 ms
No
No
No
Sí
Sí
No
¿Puede hacerlo alguien más?
POST /purchase
Total 115 ms ~ 70% mejora

11. Arquitecturas orientadas a eventos
POST /purchase
- Recibir petición 5 ms
- Recibir petición 5 ms
- Validación de datos 20 ms
- Validación de datos 20 ms
- Guardar 40 ms
- Guardar 40 ms
- Renderizar respuesta 50 ms
- Renderizar respuesta 50 ms
Total: 115 ms
POST /purchase
Generar PDF
Enviar email

12. Don't keep your clients waiting!
Can I defer it?

13. Objetivos
- Arquitectura menos acoplada, más fácil de extender, evolucionar y
mantener
- Construir sistemas de alto rendimiento y altamente escalables
- Mantener la lógica dónde debe estar y no repartida por toda la
aplicación
- Idealmente los cambios los pueden realizar equipos distintos

14. ¿Y en Grails?
Todo esto está muy bien pero yo
he venido a hablar de “mi libro”: Grails
- Platform Core
- Events push
- Plugin Executor
- Grails 2.3 Async

15. Ejemplo síncrono
// Envío de email de confirmación al registrar un usuario
def user = new User(params).save()
emailService.sendRegistationMail(user)
render view:'registerOk'
class EmailService {
public void sendRegistrationMail(User user) {
sendMail {
to user.email
subject “Confirm your account”
html g.render(template: “userEmailConfirmation”)
}
}
}

16. Ejemplo asíncrono
// Platform core
def user = new User(params).save()
event('sendRegistrationMail', user)
render view:'registerOk'
class EmailService {
@grails.events.Listener
public void sendRegistrationMail(User user) {
sendMail {
to user.email
subject “Confirm your account”
html g.render(template: “userEmailConfirmation”)
}
}
}

17. Ejemplo asíncrono
// Executor
def user = new User(params).save()
runAsync {
emailService.sendRegistationMail(user)
}
render view:'registerOk'

18. I love the smell of code in the morning

19. Problemas
- Código muy acoplado a la solución utilizada
- Difícil de testear

20. ¿Y si no queremos que sea así?
- Podemos extraer esas dependencias a “configuración”
- Es posible cambiar el comportamiento de la aplicación cambiando
sólo la configuración

21. Spring Integration
Permite utilizar dentro de
Spring los conocidos
Enterprise Integration Patterns
http://www.enterpriseintegrationpatterns.com/

22. Spring Integration
- Mecanisnos ligeros de mensajería en aplicaciones Spring
- Integración de sistemas externos declarando adaptadores.
- Abstracción de alto nivel de aplicaciones de mensajería.
- El código de la aplicación no es consciente del API de la mensajería.
- Proporciona un modelo simple para construir aplicaciones EIP
manteniendo separación conceptos y permitiendo crear código
mantenible y fácilmente testeable.

23. Principales Características
“Pipe and filters”

24. Message
- Datos (payload) pueden ser
cualquier objeto
- Cabecera (header)
información adicional
almacenada en un Map
- Son inmutables

25. Channel
- Point-to-Point
- Publish-Subscribe

26. Endpoints
- Transformer
- Service activator
- Filter
- Channel adapter
- Router
- Enricher
- Splitter
- Bridge
- Aggregator
...

27. Adapters
- JMS
- Mail (POP3/IMAP/SMTP)
- AMQP
- JDBC
- TCP
- XMPP
- UDP
- Twitter
- File
- RSS
- FTP
- MongoDB
- SFTP
- Redis
- RMI
- GemFire
- HTTP (REST)
- Stream
- WS

28. Talk is cheap. Show me the code.

29. DEMO
Por favor sacrificad una virgen cabra para que los dioses de las
demos repartan suerte

30. FUTURO/ALTERNATIVAS
- Reactor Framework: Proporciona abstracciones para Java, Groovy y
el resto de lenguajes de la JVM para construir aplicaciones eventdriven. En hardware normal consiguen 15.000.000 de eventos por
segundo. Soporte de Java 8.
- Spring 4: Soporte de Groovy como “first class citizen”, Reactor
Framework, no más XMLs, Websockets nativos, SockJS,...
- Grails 2.4: Release previa a la 3.0 con soporte de Spring 4.

31. CONCLUSIONES
- La arquitectura estandar de Grails sirve para muchos casos
- No escala infinito
- Hay que plantearse desde el principio qué tipo de aplicación
estamos construyendo
- Puede que no estemos construyendo el próximo Instagram ¿o tal vez
sí?
- Es necesario pensar en flujos de la información
- Costes de infraestructura vs Costes de código
(más hierro vs deuda técnica)

32. ¡ GRACIAS !
Iván López Martín
@ilopmar
http://lopezivan.blogspot.com
lopez.ivan@gmail.com
https://github.com/lmivan
Feedback de la charla:
http://goo.gl/e4AjKY