Seminario Spring Roo. Monitorización con Spring Insight

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

Transcript

1. Spring Roo & Spring Insight Spring 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