Seminario sobre Spring Roo y monitorización con Spring Insight organizado por Paradigma Tecnologico y Javahispano, impartido en Madrid el 14 de octubre de 2010 por Federico Caro

1. Spring Roo
&
Spring InsightSpring Insight
@federicojcdm
14 de Octubre de 2010

2. La misión de Spring Roo es ofrecer una herramienta de desarrollo rápido de aplicaciones
(RAD).
El objetivo de Roo es ser totalmente “inocuo” a la solución final, con lo que no
compromete la flexibilidad y potencial que ofrece Java y la arquitectura subyacente.
Permite generarte un “arquetipo de proyecto” inicial, en el que las librerías, estructura
de directorios e integración con el entorno de desarrollo es ofrecido de manera sencilla
y rápida.
Modelo de diseño basado en el patrón Domain Driven Design donde pretende construir
las aplicaciones en base al dominio de la misma, y evitando antipatrones del estilo
Objetivo Roo. ¿Qué es?
2
las aplicaciones en base al dominio de la misma, y evitando antipatrones del estilo
Anemic Domain Model.
Roo es una herramienta (shell o integrada dentro de Spring Tool Suite) donde pretende
incorporar funcionalidades de valor añadido de consola tipo Linux, y con un sistema de
ayuda en línea muy potente e intuitivo, donde casi no es necesario recurrir a la
documentación de referencia.
Roo no introduce ningún elemento de runtime, simplemente es una herramienta de
ayuda para el desarrollo de aplicaciones.

3. Arquitectura Roo
3

4. Comandos de ayuda “help” y “hint”
Autocompletado con tabulador
Adaptación al contexto. Los comandos ofrecidos dependen del estado en el que
estés dentro del script. Ej: Si has creado un proyecto no te ofrece el comando
“project”
Dispone de mecanismos de rollback ante errores en los comandos
Los comandos de Roo pueden ser grabados en un fichero para luego volver a
Funcionalidades Shell
4
Los comandos de Roo pueden ser grabados en un fichero para luego volver a
ejecutarlos.

5. Roo presenta un conjunto de librerías maduras y altamente establecidas en el
mercado:
Spring MVC
Log4j
Spring Security
Hibernate /JPA
JSP
Arquitectura de las aplicaciones generadas
5
JSP
Spring Web Flow
Maven2
Aspect J
Eclipse/STS
JMS
JavaMail, ….

6. Uso de la capa de dominio y capa web únicamente
Elimina las capas de Servicio y DAO. La capa de servicio puede ser añadida en las
siguientes situaciones:
Lógica de negocio que afecta a varias entidades de negocio.
Invocar lógica de negocio fuera del ámbito del protocolo HTTP.
Desacoplo entre la capa web y la capa de negocio.
Aumentar el nivel de testing
Inclsuión de transaccionalidad y seguridad en la capa de servicio.
Líneas generales de arquitectura
6
Inclsuión de transaccionalidad y seguridad en la capa de servicio.
Para crear clases de la capa de servicio, únicamente es necesario crear una clase con su
interfaz y anotar la clase con @Services.
La eliminación de la capa DAO se debe a la no aplicabilidad de esta capa en aplicaciones
con Roo de los siguientes razones:
Testing. Se puede usar técnicas de mocking y no de stubbing
Separación de responsabilidades. Se tiene gracias a ITD
Independencia de implementación: Provisto por JPA

7. Lenguaje más popular del mundo: modelo open source, librerías heterogéneas y de
calidad, facilidad de recruitment de personas con conocimientos en la tecnología
API’s `populares, estandarizadas, seguras, probadas
Calidad, madurez e integracióncon herramientas: Asistentes de código, refactoring,
profilers, debuggers, etc..
Tipado estático: pocos errores, refactorización robusta, asistente de códigos, …
¿Por qué generar Java?
7

8. No genera penalizaciones en el rendimiento:
No usa proxies dinámicos
No métodos de compilación diferida
No LTW (load time weaving)
No incorpora ninguna librería ni código específico en tiempo de ejecución.
No genera penalizaciones de memoria
Tecnología no intrusiva
8
No generación de clases No uso de la memoria permanente (PermGen)
No genera penalizaciones en el despliegue
NO es necesario introducir ninguna librería en el war.
Incorpora un mecanismo de integración con arquitectura OSGi out-of-the-box

9. Alternativas evaluadas
Pluggable Annotation Processing API (JSR 269)
Generar código en tiempo de construcción (X-Doclet style)
Generar bytecode en tiempo de construcción (ASM)
Generación de bytecode en tiempo de runtime (ASM)
Aproximaciones avanzadas basadas en proxis (Spring AOP)
Aproximaciones de generación de código
9
IDE Plugins
Decisiones/Ventajas:
Decisión 1.Uso de Aspect J.
o Uso de Inter-type declarations (ITD) con Aspect J.
o Desarrollo de unidades de compilación con cometidos diferentes
o Soporte instantáneo de herramientas
o Maduro, modelo “push-in” de refactorización, incluIda en tiempo de compilación.

10. Decisión 2. Crear un shell
o Generación basada en modelo de comandos
o Usabilidad como ciudadano de primera clase
o Encargado de realizar labores de monitorización de cambios mediante un modelo de
polling. Evitar crear pasos de generación “crudos”.
o Roo nunca modifica un fichero java a no ser que se ejecute un comando de usuario
Decisión 3. Generar un modelo mixto de generación pasiva y activa de código,
Decisiones/Ventajas
10
Decisión 3. Generar un modelo mixto de generación pasiva y activa de código,
obteniendo la mejor de ambas.
o Generación pasiva. Uso del shell para generar comandos que van generando los
componentes de la aplicación
o Generación activa. Mecanismo de monitorización continua que permite
actualizaciones incrementales de los ficheros generados (nunca Java).

11. Modelo de generación activa
11

12. El futuro
12

13. Ambos ayudan a generar un arquetipo de proyecto. Evita pérdida de tiempo inicial
Roo es menos agresivo que Grails, puesto que genera código Java estándar y los add-on no
introducen limitaciones específicas-
Ambos actualmente no son tecnologías maduras, aunque con una gran proyección
Tipado estático vs Tipado Dinámico. Bondades del lenguaje. Azúcar sintáctico
Ecosistema de addons y plugins poco maduro.
Arquitectura óptima de generación de código: generación dinámica/estática.
El rendimiento de una aplicación Roo es superior a Grails al no introducir ninguna penalización en
Roo vs Grails
13
El rendimiento de una aplicación Roo es superior a Grails al no introducir ninguna penalización en
tiempo de ejecución
No necesidad de curva de aprendizaje para programadores Java.
Capacidades de depuración y monitorización mucho mayores en Roo. Compatibilidad con Maven.
Grails presenta mayores tasas de valoración en mantenimiento de código (escribes menos).
En resumen valorar rendimiento, mantenibilidad, depuración y habilidades de tu equipo para elegir
una u otra plataforma

14. Herramienta de diagnóstico avanzada que permite monitorizar el rendimiento de aplicaciones en
tiempo real.
Básicamente consiste de un Apache Tomcat modificado.
Muy orientado a aplicaciones realizadas con la tecnología Spring Framework.
Esta tecnología permite complementar las posibilidades de monitorización permitiendo a los
desarrolladores tener acceso de la información de tiempos de respuesta en:
Consultas JDBC
Interacción de Spring Bean
Llamadas a servicios externos
Spring Insight
14
La herramienta puede servir de ayuda a los equipos de QA para detectar problemas en el
rendimiento de las aplicaciones.
Complementa a las herramientas de carga/estrés para descubir el por qué de un problema de
rendimiento.
La tecnología incluye un Kit de desarrollo, el cual puede extender la funcionalidad que ofrece Insight
para coleccionar detalles que permitan descubrir un cuello de botella.
Se integra con SpeedTracer de Google, complementando el análisis de una forma completa (end-to-
end): problemas en rendimiento de la capa cliente, integrado con el comportamiento de la parte
servidora que ofrece Insight.

15. La aplicación no requiere ninguna configuración especial, instrumentación y paso
adicional, para ser instalada dentro del servidor de monitorización.
El servidor captura los eventos de las aplicaciones (conocidos como trazas).
Una traza representa un hilo de ejecución.
Cada traza está formada por un conjunto de operaciones la cual representa un
punto significativo en la ejecución de una traza (por ejemplo una consulta JDBC).
Spring Insight recoge la información asociada a estos eventos, lo cual permite
¿Cómo funciona?.
15
Spring Insight recoge la información asociada a estos eventos, lo cual permite
conocer el por qué el rendimiento de una aplicación no es el correcto.
Spring Insight usa tecnología AOP para monitorizar el rendimiento de las
operaciones. Las aplicaciones son cargadas con un ClassLoader especial que
dinámicamente instrumentan aplicaciones web en tiempo de ejecución.
Spring Insight, de momento, mantiene los datos en memoria. Por tanto, se requiere
más memoria que en una aplicación normal.

16. Conceptos clave:
Target application: Aplicación sobre la que se va a monitorizar el rendimiento en
tiempo de ejecución
Operation: Encapsula una orden de trabajo dentro un hilo de ejecución: Flush de
Hibernate, tiempo de ejecución de la capa de servicio, llamada a un método,
comando JDBC, etc..
Frame: Representa una unidad de ejecución dentro de una jerarquía de llamadas.
Representa básicamente la llamada a un método dentro de la pila de ejecución. El
core de un frame es una operación.
Spring Insight Development Kit
16
core de un frame es una operación.
Trace: Registro de un hilo de ejecución dentro de la ejecución de una aplicación.
Endpoint: Agrupación lógica de trazas similares dentro de una aplicación. La salud y
las métricas son calculadas en base a endpoints. Ejemplo, todas las trazas que
forman parte del mismo método de un mismo método de un controlador forma
parte de un mismo endpoint.
Aspecto: Mediante la aplicación de aspectos, se recopila información de ejecución
de la aplicación target.

17. Relaciones entre artefactos de Insight
17

18. Pasos básicos para la construcción de un plugin
Debe haber un aspecto escrito en AspectJJ encargado de interceptar la ejecución de
métodos: jdbc, spring mvcx, etc..
El aspectJ se encargará de construir operaciones que básicamente se encargan de
renderizar la información asociada. En el caso de JDBC, la consulta que está
lanzando.
Cada operación tiene asociado una plantilla Freemarker encargada de renderizar la
información asociada de la operación dentro del dashboard.
18
Endpoint Analyzer.

19. Madrid
Avda. de Europa, 26 - Ática 5, 3ª Planta
28224 Pozuelo de Alarcón
E-mail: info@paradigmatecnologico.com
Teléfono: +34 91 352 59 42
Fax: +34 91 715 89 66