Diapositiva 1

JMitJava Monitoring by Introspection ToolToms

Quienes somosEs un tp profesionalTutoria de rosita1Equipo de TrabajoToms Fernndez LbbeCristian Santilli

TutorLic. Rosa Graciela WachenchauzerToms2

El problemaToms

Lo primero es contar el problema que queremos solucionar con la herramienta3Un equipo de desarrollo construye una aplicacinEst funcionando?Est funcionando bien?No? Por qu?POR QUEEEEE?!!!!!Funciona con una velocidad aceptable?La aplicacin dej de funcionar el viernes a la noche y nadie se enter hasta el lunes a la maana?

Toms

En la actualidad, durante el desarrollo de un software, es necesario tener conocimiento del estado del sistema (valores que est manejando, tiempos de cargas, etc.), pero esto no es un problema para nada trivial.

4La solucinAgregar cdigo de control a la aplicacin, que me pueda dar informacin actualizadaTomsSi est funcionando, bienSi se est rompiendo, dnde se est rompiendo. Cunta gente la est utilizando es algo que queremos saber5Un poco de contextoCristian1:406Unas lneas de cdigoif (!clazz.getName().equals(anArray[position].getName())) {return false;}position++;CristianEntrar en contextoPara los que nunca vieron una lnea de cdigo, ac les mostramos un par, con cosas como estas se escriben todas las aplicaciones que conocen7Ms lneas de cdigopublic static MethodDefinition create(String declaringClassName, String methodName, Class[] parameterTypes, String returnType) throws ClassNotFoundException {Class declaringClass = CoreUtils.getClass(declaringClassName);Class returnTypeClass = CoreUtils.getClass(returnType);List>();if (parameterTypes == null) {return create(declaringClass, methodName, (List>)null, null);}Cristian

En realidad es mas as.8Muchas ms lneas de cdigoFuente: Wikipedia. http://es.wikipedia.org/wiki/L%C3%ADneas_de_c%C3%B3digo_fuenteCristianUna aplicacin real puede tener millones de lneas de cdigo.

Tomamos los sistemas operativos como ejemplo, pero cualquier aplicacin de tamao mediano hoy en da puede tener varios millones de lneas de cdigo.

Jmit: 40.0009Y entonces, que implica la solucin anterior?Cuando la aplicacin est terminada, hay que sacar el cdigo de control?Si la aplicacin ya est lista y surge un problema, hay que volver a modificarlaMayor esfuerzo en Horas HombreMezclar incumbenciasConocer de antemano los controles que se van a realizar

Cristian

Se puede tener la informacin del sistema actualizada, pero a costa de:

el cdigo debe ser desarrollado por las mismas personas que estn desarrollando la aplicacin. el cdigo de aplicacin se mezcla con el cdigo de control estos deben ser desarrollados al momento que se desarrolla la aplicacin, de lo contrario implicara introducir nuevo cdigo en funcionalidad que puede estar cerrada Implica que, cuando la aplicacin est lista para ser puesta en produccin, habra que quitar todo este cdigo de control, con el problema de no saber exactamente donde est, e incluso la posibilidad de introducir errores (es necesario sacarlo, porque reduce innecesariamente la performance de la aplicacin). Incluir un nuevo tipo de control sobre el cdigo de una aplicacin ya en produccin implicara modificar el cdigo original, debiendo iniciar un proceso de cambio en el proyecto: desarrollo, testing, etc.

10AOPAspect Oriented Programming (Programacin Orientada a Aspectos)Para explicarlo se debe entender OOP.

Toms5:50Es el primer concepto tcnico que vamos a hablarViene de Aspect Oriented ProgrammingOrganizar el cdigoUn paradigma distinto al habitual. Paradigma es una forma de trabajar, de organizar el cdigo fuente para que esas 250 millones de lneas de cdigo de las que hablabamos antes pasen de ser imposibles de entender a casi imposibles11OOPObject Oriented Programming (Programacin orientada a Objetos)011

Posicin=Avanzar()0TomsEl paradigma habitual. En l, uno de los conceptos mas importantes es el de encapsulamiento. Un objeto es algo que se define que tiene un estado y un comportamiento. Ejemplo AutoProblema->Cdigo repetido en todos lados. Que pasa si se quiere cambiarHotmail

Por ejemplo, el objeto auto, tiene un estado que podra ser por ejemplo la posicin (la posicin cero) y un comportamiento (sabe avanzar), Todo el cdigo relacionado con el auto tiene que ir dentro de ese objeto.

Pero, el problema surge cuando hay comportamiento que se repite en varios objetos al mismo tiempo, por que esto se traduce en cdigo repetido por todos lados. Una vez que uno tiene el cdigo repetido por todos lados, qu pasara si debemos modificar ese comportamiento? Tendramos que modificar cdigo por todos lados!Por eso aparece el concepto de aspectos.

12Aspectos

Cdigo replicadoToms

Me parece que esta diapositiva la sacara13Ahora si, AOPEl objetivo de AOP es encapsular esos comportamientos que se ven repetidos por el cdigo.Un aspecto es un concepto que no se puede encapsular, ya que involucra a muchos objetos distintosNo reemplaza al modelo anterior, se utiliza como un complemento

TomsEjemplo: Cdigo de seguridad Hotmail

Por ejemplo, El cdigo de seguridad. Es comn que en las aplicaciones se tenga que manejar seguridad. Por ejemplo, si usan hotmail, les va a pedir que inicien sesin, y no les va a dejar que entren a ninguna pgina si no lo hacen. Si no se utilizan aspectos, es probable que ese cdigo de seguridad est replicado por varios lugares distintos, y si es as, existe el problema que hablamos cuando se quieren aplicar cambios.

14Qu problemas soluciona AOP?Monitorear la aplicacin ya no implica mezclar incumbenciasSe pueden agregar o remover aspectos por configuracin, ya no es necesario tocar el cdigo original para esto.Hasta cierto punto se resuelve el problema de conocer de antemano los controles que se quieran realizar. TomsLos aspectos se desarrollan de forma separadaAgregar/quitar AspectosConocer de antemano los monitores ya no es tan necesario

Mediante la utilizacin del paradigma de aspectos, varios de estos problemas son resueltos. Monitorear la aplicacin ya no implica mezclar incumbencias: Estas funcionalidades transversales (cross cutting concerns) se desarrollan de forma modular separados del cdigo original, lo que resuelve el problema.

Cuando se deseen quitar estos aspectos es tan simple como indicarlo en un archivo de configuracin, ya no es necesario tocar el cdigo original para esto.

Hasta cierto punto se resuelve el problema de conocer de antemano los controles que se quieran realizar. Por ejemplo, si se quisiera monitorear algo de una aplicacin que se encuentra productiva, esto no implicara modificar el cdigo original de la aplicacin, sin embargo, s es necesario desarrollar el cdigo del aspecto para ese tipo de monitoreo, probarlo, etc. Introducir un error en el cdigo de monitoreo implica introducir un error en la aplicacin.

15Qu problemas NO soluciona AOP?Es necesario desarrollar el cdigo del aspecto, el cual podra contener errores.An se requieren horas hombreEs necesario contar con recursos que tengan conocimiento del paradigma y de algn framework.

Toms

16

La SolucinCristian10:00La solucin utiliza el paradigma de aspectos, pero tambin con algunos agregados.Solucin a los problemas que por si solos los aspectos no solucionaban.17JMitProveer una herramienta que permita:Simplificar el monitoreo de aplicaciones permitindole al equipo de trabajo conocer el estado de las mismas sin la necesidad de agregar cdigo extra.Agregar o remover monitores de la aplicacin en forma declarativa y limpiaCristianOlvidate de agregar el cdigo de control, ahora lo agregamos nosotros.Olvidate de sacarlo, ya que tambin lo hacemos nosotros.18A quin va dirigido JMit?A aquellas personas con conocimiento tcnico de la aplicacin que se quiere monitorear.Cristian.Los monitores se aplican muy a bajo nivel, sobre lneas de cdigo y clases especficas. Quien utilice Jmit debe saber donde vale la pena aplicar cada monitor.19Qu permite JMit?Definir mediante un archivo de configuracin los distintos monitores , y donde se aplicarn. Definir distintos tipos de monitores para cada etapa del sistema (Por ejemplo: desarrollo, testing, produccin). Programar alarmas ante eventos definidos por el usuario (por ejemplo, enviar un mail ante cierto valor de un atributo).

Cristian20VisualizacinPermite distintos modos de visualizacinCada visualizacin podra tener distinta profundidad y estar orientado a distintos niveles de una organizacin. Podran crearse nuevos mdulos de visualizacin para casos particularesVarios mdulos de visualizacin pueden utilizarse al mismo momento.Cristian.Grafico, texto, mail, SMSDesarrollador, lider de proyecto, gerente, responsable de infraestructura (esta controlando la aplicacin).Coexistir visualizaciones, misma informacin, distinta manera.21Aplicaciones en simultneoMuchas aplicaciones podran monitorearse con una sola instancia de JMit.CristianNo solo visualizaciones al mismo tiempo, tambien varias aplicaciones pueden reportar informacin al mismo tiempo.Todo esto se va a entender mas.22MetodologaLa metodologa de trabajo utilizada en el proyecto, cuya caracterstica principal es la de ser un proyecto acadmicoToms17:00Antes de hablar de la arquitectura, mdulos y las cosas divertidas les contamos un poco cual fue la metodologa de trabajo que utilizamos La principal diferencia es que es un proyecto acadmico23La metodologa utilizadaCascada

TomsNo es la mejor metodologa, la elegimos en nuestro caso (Scrum->mentira)Otras Metodologas (iterativas) No nos servan. Poca disponibilidad horaria. materias, parciales, finalesNo podemos comprometernos semana a semanaLas limitaciones y problemas que puede tener esta metodologa fueron riesgos que asumimos y supimos mitigar con algunas de las herramientas utilizadas.Problema de no enterarse de un error. Arrastro. Entregas Incrementales.

---------------------------------------

Uno de los problemas que puede traer el modelo de cascada es que si uno se da cuenta de un error de anlisis en la etapa de test se arrastr el error durante todo el proyecto, y si la versin fue muy larga, entonces corregirlo ser muy costoso. Para mitigar este riesgo utilizamos lo que se llaman entregas incrementales

No es la mejor metodologa para muchos proyectos, en nuestro caso particular, la elegimos por las caractersticas adquiridas por ser un proyecto acadmico. Otras metodologas proponen comunicacin mas fluida y ciclos mas cortos e iterativos dando pequeos pasos, con reuniones cortas y con alta periodicidad.Cuando comenzamos el proyecto, los dos estbamos cursando materias (distintas, en distintos horarios) lo que nos complicaba encontrar momentos en los que reunirnos. Al mismo tiempo, el ciclo de las materias nos oblig a trabajar distinta cantidad de horas cada semana (en pocas de parciales / finales era poco el tiempo que le podamos dedicar al proyecto, mientras que en otros momentos tenamos varias horas por semana disponibles). Esto ltimo tambin hizo que no nos pudiramos comprometer con la profesora que semana a semana le llevaramos nuevas funcionalidades construidas, porque de vez en cuando no lo bamos a poder cumplir. Por esta razn, nos pareci que el modelo de cascada era el adecuado para el proyecto.

Las limitaciones y problemas que puede tener esta metodologa fueron riesgos que asumimos y supimos mitigar con algunas de las herramientas utilizadas.

Uno de los problemas que puede traer el modelo de cascada es que si uno se da cuenta de un error de anlisis en la etapa de test se arrastr el error durante todo el proyecto, y si la versin fue muy larga, entonces corregirlo ser muy costoso. Para mitigar este riesgo utilizamos lo que se llaman entregas incrementales

El scrum en este tipo de proyectos es una MENTIRA24La metodologa utilizadaEntregas incrementales

EntregaEntregaTomsPartir el proyecto en modulosCada modulo una cascada

Las entregas incrementales nos dan una visin del proyecto mas actualizada, es como pasar a tener proyectos mas cortos, donde cometer un error en el anlisis no es tan costoso que si esperramos al final del proyecto completo para encontrarlo.25La metodologa utilizadaRevisiones

RevisinRevisinRevisinTomsNo siempre lo hicimos, alguna veces porque fueron pasadas por alto y otras simplemente porque no lo consideramos necesario.

Agregando revisiones despus de cada etapa del modelo tratamos de encontrar la mayor cantidad de errores antes de darla por terminado26La metodologa utilizadaVersiones

Versin 1.0TomsDe todas las funcionalidades que planteamos elegimos las mas importantesOtras, mas las que se nos fueron ocurriendo sobre la marcha tambin quedaron afueraEs importante que el contenido del proyecto no cambie, porque sino los cambios continuos pueden hacer que el proyecto fracaseDefinimos las funcionalidades que se incluiran en esta primer versin desde el primer da. Lo hicimos en base a la cantidad de gente que iba a trabajar (nosotros dos) y el tiempo disponible.Otra funcionalidad documentada.

---------------------------------------------------------------------

Definimos las funcionalidades que se incluiran en esta primer versin desde el primer da. Lo hicimos en base a la cantidad de gente que iba a trabajar (nosotros dos) y el tiempo disponible. Al mismo tiempo, pensamos el producto como uno mas grande, pero que podr seguir creciendo en futuras versiones. Aquellas ideas que se nos fueron ocurriendo durante el desarrollo, las dejamos documentadas para que puedan ser incluidas en el futuro.27CalendarioCreamos un calendario en el que planteamos todos los hitos a cumplir, principalmente:RevisionesEntregas incrementales

Toms

28CalendarioEn el calendario incluimos: Estimacin de horas totales que debamos tardar para cada una de las tareasEstimacin de la fecha en la que se tena que terminar cada tarea

TomsLas fechas de entrega para el final del proyecto estuvieron alrededor de un mes y medio retrasadas, la fecha original para la finalizacin del proyecto era el 3 de nov, la finalizacin real fue hoy, 22 de diciembre. El inicio del proyecto fue el 1/10/2009.

La estimacin en horas estuvo en lneas generales acertada con la realidad. La estimacin en fecha de entrega de cada revisin no siempre fue la estimada. EL problema en general no fue la estimacin de horas, sino las horas a la semana que pensbamos que podamos dedicarle al proyecto frente a las que realmente podamos dedicar.

Las fechas de entrega para el final del proyecto estuvieron alrededor de un mes y medio retrasadas, la fecha original para la finalizacin del proyecto era el 3 de nov, la finalizacin real fue hoy, 22 de diciembre. El inicio del proyecto fue el 1/10/2009.

Realmente empezamos a buscar ideas y pensar proyectos en junio del 2009 y hablar del proyecto en mayo del 200929Open SourceGNU Lesser General Public LicenseLicencia que permite a cualquiera que lo desee descargar el cdigo fuente, compilarlo y utilizarloQuien lo desee puede contribuir desarrollando una parte de la misma.

TomsEn parte por la simplicidad que el soft propietarioSin pagarSin avisarnosPara agregar cdigo si nos tienen que avisar30Herramientas para la Gestin del Proyecto

TomsHerramientas que usamos y herramientas que NO usamos (por qu)31Solucin PropuestaCmo pensamos JMit?Cristian23:4032

ArquitecturaCristianMdulos, bloques, objetivos especficos. Cuales son, que hacen.Vamos a hablar un poco33Mdulos de JMitJMit tiene al menos 5 mdulos con responsabilidades distintas.AspecterMonitorEngineVisualizerSenderReceiverCristian

34Mdulos de JMitAspecterLibrera encargada de inyectar cdigo de monitoreo en la aplicacin original.

Cristian

Toma el archivo, e inyecta los aspectos. (entrecruza, teje)

35Mdulos de JMitMonitorEngineAplicacin web encargada de recopilar los eventos ocurridos en la aplicacin a monitorear e interpretarlos

Cristian

36Mdulos de JMitVisualizerAplicacin web encargada de mostrar los monitores

Cristian37Mdulos de JMitSenderLibrera encargada de enviar mensajes desde un mdulo hacia otro

Cristian

RAPIDO!!!38Mdulos de JMitReceiverLibrera encargada de recibir los mensajes que se envan desde un Sender en otro mdulo

Cristian

RAPIDO!!!39Por qu no hacer todo en un solo mdulo?Cmo se comunican los mdulos?Por qu no hacerlo en dos mdulos?Mdulos de JMit

Toms27:30No un mdulo -> No queremos interferir con el flujo normal de la aplicacin. Agregar poco cdigo. No meter erroresNo dos modulos -> Poder tener distintos tipos de visualizacin, Distintos targets40Opciones consideradas para la comunicacin entre mdulosTransferencia de archivosBase de datos compartidasInvocacin a procedimientos remotos o RPCMensajeraTomsLa transferencia de archivos consiste en que la aplicacin emisora escribe un archivo y lo graba en cierta porcin del disco visible por otra aplicacin (la receptora). La aplicacin receptora consulta regularmente si hay nuevos archivos o cambios en los existentes, y de ser as, los abre y los "consume".Esta aproximacin no es buena para nuestro caso, ya que puede ser demasiado lento. Puede no ser tan simple encontrar una "porcin de disco visible" por ambas aplicaciones, ya que pueden estar corriendo en distintos servidores en distintos lugares fsicos.

La opcin de "base de datos compartida" la descartamos porque implicara instalar un motor de base de datos en el ambiente de la aplicacin cliente (que va a usar el mdulo de integracin como emisora).

Invocacin a procedimientos remotos o RPC por sus siglas en ingles y Mensajera fueron las dos opciones ms convincentes, sin embargo, Mensajera permita reducir un poco ms el acoplamiento entre las aplicaciones y era ms confiable.41Mensajera por HTTPPerformanceNo intrusin en el cdigo y ambiente de la aplicacin clienteBajo acoplamientoAsincronismoRobustezSeguridadTomsPerformance: La transferencia de informacin debe ser veloz, algunos tipos de monitoreo puede necesitar enviar mucha informacin y la comunicacin entre las aplicaciones puede convertirse en un cuello de botella.No intrusin en el cdigo y ambiente de la aplicacin cliente: As como con todos los mdulos de JMit, el mecanismo de integracin tiene que introducir la mnima funcionalidad posible del lado del cliente.Bajo acoplamiento:"El cambio es inevitable", las aplicaciones estn pensadas para evolucionar por si solas, los cambios en una no deben afectar a las otras aplicaciones con las que sta se comunica.Asincronismo: Es necesario que para el cdigo cliente, enviar un evento a JMit sea tan simple como dejar un sobre en un buzn. Se debe utilizar una aproximacin "send and forget" (enviar y olvidarse). Es indispensable sumar la menor cantidad de procesamiento a la aplicacin cliente, no se le puede agregar la responsabilidad (y sumar los tiempos) de esperar a que el mensaje se reciba del otro lado.Robustez: Ante todo, siempre JMit debe permitir que la aplicacin cliente funcione con normalidad, los errores que puedan surgir en la comunicacin deben quedar encapsulados, dentro de JMit y nunca transmitirse a la aplicacin cliente (Habr ms decisiones tomadas en funcin de este NFR, ver Excepciones en el Sender).Seguridad: Es importante que los mensajes enviados lleguen en tiempo y forma al receptor, sin embargo, en algunos casos perder algn mensaje puede no ser crtico.42MonitoresTiempos de procesamiento por mtodo.Tiempos de procesamiento promedio por mtodo.Conteo de la construccin de objetos.Conteo de invocaciones a un mtodo.Valor de un atributo de un objeto.TomsAlgunos de los monitores que planteamosQued construida la estructura para que crear nuevos monitores sea simple

43AlarmasLas alarmas son un aviso creado por el usuario para informarle sobre alguna condicin en particular en el programa definido por el mismo.El aviso intenta tener prioridad sobre otros eventos.TomsTipos de alarma:- Que el valor supere una cota superior.- Que el valor no supere una cota inferior.- Que el valor supere una cota superior por ms de un tiempo predeterminado.- Que el valor no supere una cota inferior por ms de un tiempo predeterminado.44ConfiguracinEn forma declarativa

TomsLa configuracin se realiza mediante un archivo XML como se muestra, indicando 45Los Mdulos

TomsDiseo un poco mas detallado de cada uno de los modulos

46

AspecterTomsEncargado de inyectar los aspectosLo hace cuando la aplicacin cliente se compila47Por qu?Mdulo encargado de inyectar los aspectos al cdigo de la aplicacin originalLos aspectos inyectados dependen de los Monitores que se hayan declarado en el archivo de configuracinInyecta el mnimo indispensable de cdigo y busca no interferir con el flujo normal de la aplicacin originalToms

48Diseo

TomsTiene mucho que ver con lo que es la programacin orientada a aspectos. No es un invento nuestroWeaving Instrumentor tiene la receta49Extensiones - PluginsEst pensado para que nuevos monitores puedan ser creados de forma plugin

Toms

50Tecnologas

Javassist

Xerces2

Toms

51

Sender

TomsComo dijimos antes, mdulo encargado de mandar los eventos52Receiver

TomsSi alguien los sabe mandar, alguien los tiene que saber recibir53Por qu?Abstraer a los mdulos que necesiten comunicacin de la forma en la que se implemente la mismaPoder reemplazar el da de maana la tecnologa utilizada para mensajera, incluso dejar de usar mensajera

http://www.enterpriseintegrationpatterns.com/Introduction.htmlToms

54Diseo Sender

TomsUn endpoint por destinoChanel -> Canal de comunicacinLo importante es que quien tenga que mandar mensajes solo tiene que conocer a Sender55Diseo Receiver

TomsAc lo importante es que quien tenga que recibir mensajes solo tiene que conocer el Receiver, le van a avisar cuando un mensaje llegue.56Tecnologas

Toms

57

MonitorEngine

Cristian38:0058Por qu?Es quien se encarga de analizar los eventos recibidos desde la aplicacin cliente a la que se le aplicaron aspectosDecide a que visualizadores debe ir la informacin y cada cuanto tiempoCristian

59Diseo

CristianMostrar como usa Sender y ReceiverExplicar ciclo de vida de los monitoresExplicar Front ControllerMonitorDescriptor sirve para plugins60Extensiones - PluginsAl igual que el mdulo Aspecter, el MonitorEngine fue pensado para poder agregar nuevos monitores de forma plugin

Cristian

61Backend

CristianContar que hace cada uno de los items62Tecnologas

Xerces2

CristianLo mismo que antes + GWT63

Visualizers

Cristian

64Por qu?Mdulo encargado de visualizar de alguna forma los monitoresPuede tener distintos niveles de profundidad dependiendo de a quien est dirigidoSe pueden definir varios para un nico MonitorEngineCristian

65Console Visualizer

Cristian

66Mail Visualizer

Cristian

67Graphic Visualizer

Cristian

68Nuevos VisualizersSe pueden desarrollar nuevos visualizers de forma simple.Se debe utilizar un Receiver, implementar una interfaz y listo.Podran crearse distintos para cada caso particular, son simples de construirCristianLos mdulos visualizers desarrollados son tal vez los mdulos menos extensibles69Tecnologas

Java MailCristian

Lo mismo que antes mas Java Mail70MavenMaven ayuda a la gestin del proyecto y maneja el ciclo de vida de las aplicacionesJMit se integra con Maven, haciendo que sea transparente para el equipo de trabajo la invocacin al mdulo Aspecter cada vez que se compilaCristianMaven es una herramienta que sirve para la gestin de proyectos java. Por ejemplo, todas estas tecnologas que venimos mencionando se integran muy fcilmente cuando se utiliza maven.Lo que buscamos hacer fue que Jmit sea fcilmente integrable con cualquier aplicacin. Como Maven puede manejar el ciclo de vida de las distintas aplicaciones, integrando JMit al mismo hace que el desarrollador no se tenga que preocupar de invocar al aspecter cada vez que compila, sino que esto se har automticamente

71Maven

ar.edu.uba.fi.jmitmaven-plugin1.0process-classesjmitMyApplicationMyApplication.jmit.xmldevelopmenttarget/classes/artarget/classes

Cristian

72Despliegue

Toms45:00Aplicaciones Web o de escritorio, pero con acceso a la redMonitorEngine una aplicacin webVisualizer una aplicacin web73DemoCmo se utiliza JMit74