Spring Roo&

Spring InsightSpring Insight@federicojcdm

14 de Octubre de 2010

� 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.

Arquitectura Roo

3

� 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.

� 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, ….

� 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 lassiguientes 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 suinterfaz y anotar la clase con @Services.

� La eliminación de la capa DAO se debe a la no aplicabilidad de esta capa en aplicacionescon 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

� 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

� 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 unmecanismo de integración con arquitectura OSGi out-of-the-box

� 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.

� 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).

Modelo de generación activa

11

El futuro

12

� 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

� Herramienta de diagnóstico avanzada que permite monitorizar el rendimiento de aplicaciones entiempo 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 losdesarrolladores 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 elrendimiento de las aplicaciones.

� Complementa a las herramientas de carga/estrés para descubir el por qué de un problema derendimiento.

� La tecnología incluye un Kit de desarrollo, el cual puede extender la funcionalidad que ofrece Insightpara 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 parteservidora que ofrece Insight.

� 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.

� 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.

Relaciones entre artefactos de Insight

17

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.

MadridAvda. de Europa, 26 - Ática 5, 3ª Planta

28224 Pozuelo de Alarcón

E-mail: info@paradigmatecnologico.comTeléfono: +34 91 352 59 42

Fax: +34 91 715 89 66