GGalache PDF

Universidad de Buenos Aires
Facultad de Ingeniera
Infraestructura para Recuperacin Automtica ante

Fallos de Sistemas de Software mediante Modelos de
Control en Tiempo Real
Aplicacin a Plataformas Java EE
Tesis de Grado de Ingeniera en Informtica

Orientacin Sistemas Distribuidos
Alumna:
Guillermina Gabriela Galache

ggalac@fi.uba.ar - guillermina.galache@gmail.com
Directores:
Dr. Rodrigo Castro, FCEyN/UBA (externo)

Ing. Osvaldo Clua, FI/UBA
Ao 2012
Tesis de Ingeniera en Informtica
Guillermina G. Galache - 77060
Resumen
En la presente Tesis se desarrolla una plataforma de software para posibilitar la adaptacin
automtica y autnoma de Sistemas Informticos ante una degradacin en su calidad de servicio.
La metodologa Self-Healing ofrece ventajas particulares cuando se aplican tcnicas de control
a lazo cerrado. Primero se acepta la no idealidad del sistema y el dbil conocimiento de la dinmica de
su entorno y sus usuarios. Luego, se agrega una capa de supervisin que detecta estados o tendencias
no deseables y reacciona controlando parmetros de operacin en pos de mitigar la degradacin del
servicio.
Un factor que limita su adopcin en entornos industriales es la fuerte dependencia de cada
estrategia de control particular con la herramienta especfica que lo implementa, dificultando la
convergencia hacia una plataforma estndar.
Para contrarrestar esta situacin, desarrollamos una herramienta genrica para disear e
implementar distintas estrategias de control en un contexto flexible y modular. Sus tres funciones
centrales: monitoreo, control y actuacin se logran mediante componentes independientes integrados
mediante una red de datos.
Los controladores se implementan en un entorno de modelado y simulacin basado en el
formalismo DEVS (Discrete Event System Specification) que permite especificar de forma
matemticamente robusta controladores de cualquier naturaleza: continuos, a tiempo discreto, a
eventos discretos, y/o combinaciones de ellos (hbridos).
Esto facilita el desarrollo de estrategias de control acorde al enfoque System-In-The-Loop
(sistema dentro del lazo): los modelos son desarrollados, ensayados y verificados mediante
simulaciones desacopladas del sistema real a controlar (sistema fuera del lazo); luego, cuando el
desempeo es aceptable, las entradas y salidas del controlador son simplemente redireccionadas
hacia el sistema real (sistema dentro del lazo) para su validacin.
Mediante un proceso iterativo los modelos de simulacin pasan a ser ejecutados en tiempo real
convirtindose directamente en el producto final.
Demostramos la eficacia de la plataforma diseando un control sencillo tipo on-off para regular
el consumo de CPU y memoria de una aplicacin Web sobre Java EE. Los ensayos expusieron
dinmicas inesperadas de la aplicacin controlada, y la plataforma mostr flexibilidad para adaptar el
control incorporando los nuevos conocimientos adquiridos.
Esperamos que nuestro desarrollo contribuya a disminuir la brecha existente entre la Ingeniera
de Software y la Ingeniera de Control en el contexto del aseguramiento de la calidad de servicio de
aplicaciones industriales.
Agradecimiento
Quiero agradecerles a mis directores, Dr. Rodrigo Castro e Ing. Osvaldo Clua, por haberme
orientado en la realizacin del presente trabajo.
A Lic. Adriana Echeverria, Ing. Hugo Pagona y Lic. Alejandro Turri por haber aceptado ser
jurados del presente trabajo y por su buena predisposicin para definir rpidamente la fecha de la
defensa.
A mi familia, en especial a mi mam y a Martin, por haberme apoyado durante toda mi carrera
e hicieron posible que pudiera llevarla adelante.
A mis amigos y especialmente a Julia por haberme ayudado con la preparacin de la defensa y
en los ensayos.
Por ltimo, quiero dedicarle este trabajo a mi hija Micaela que es quien me inspira en todo lo
que hago, y es la personita ms importante en mi vida.
Contenido
Captulo 1: Introduccin................................................................................................................8
1.1 - Contexto.............................................................................................................................9
1.2 - Motivacin .......................................................................................................................10
1.3 - Definicin del Problema .................................................................................................. 11
1.4 - Objetivos ..........................................................................................................................12
1.5 - Estructura del Informe .....................................................................................................12
Captulo 2: Conceptos Preliminares ............................................................................................14
2.1 - JVM .................................................................................................................................15
2.1.1 - Componentes Principales de la JVM .......................................................................16
2.2 - Servidores de Aplicaciones JEE ......................................................................................18
2.3 - Confiabilidad y Sistemas Self-Healing............................................................................21
2.3.1 - Qu se entiende por confiabilidad de un sistema? .................................................21
2.3.1.1 - Las Amenazas a la Confiabilidad del Sistema..............................................22
2.3.1.2 - Formas de Lograr la Confiabilidad de un Sistema .......................................26
2.3.2 - Elementos de los Sistemas Self-Healing .................................................................28
2.3.2.1 - Fault Model o modelo de defectos ...............................................................28
2.3.2.2 - System Response o respuesta del sistema .....................................................29
2.3.2.3 - System Completeness o completitud del sistema ..........................................30
2.3.2.4 - Desgin Context o contexto de diseo ...........................................................30
2.4 - Monitoreo y Actuacin ....................................................................................................31
2.4.1 - Tcnicas de Monitoreo .............................................................................................33
Captulo 3: Estado del Arte .........................................................................................................34
3.1 - Principales enfoques en sistemas Self-Healing ...............................................................35
3.1.1 - Self-Healing basado en Modelos de Arquitecturas ..................................................36
3.1.2 - Self-Healing basado en Ingeniera de Control .........................................................39
3.2 - Trabajos previos relevantes .............................................................................................43
3.2.1 - JVMMon ..................................................................................................................43
3.2.2 - Aqua .........................................................................................................................45
3.2.3 - Arco Iris ...................................................................................................................47
3.2.3.1 - Extensiones Realizadas a Rainbow ..............................................................49
3.2.3.2 - Principio de Funcionamiento de Arco Iris....................................................50
3.2.3.3 - Eleccin de Estrategias Rainbow vs Arco Iris..............................................51
3.2.4 - Teora de control aplicada a un servidor Web ..........................................................51
4
3.2.4.1 - Arquitectura de Apache HTTP Server: Propiedades relevantes del

sistema a controlar ......................................................................................................51
3.2.4.2 - Entradas de Control y Salidas Controladas ..................................................52
3.2.4.3 - Obtencin del Modelo del Sistema a Controlar ...........................................53
3.2.4.4 - Evaluacin del Modelo del sistema ..............................................................54
3.2.4.5 - Diseo del Modelo del Controlador .............................................................55
3.2.5 - Anlisis preliminar ...................................................................................................55
3.3 - Relevamiento de tecnologas de Monitoreo y Actuacin para la JVM ...........................56
3.3.1 - Tcnicas de Monitoreo de la JVM ...........................................................................56
3.3.2 - Java Platform Debugger Architecture (JPDA) .........................................................57
3.3.2.1 - Java Virtual Machine Tool Interface (JVMTI) .............................................58
3.3.3 - Java Management Extensions (JMX) ......................................................................59
3.3.3.1 - Managed Bean (MBean) ..............................................................................60
3.3.3.2 - Platform MBeans..........................................................................................61
3.3.4 - Simple Network Management Protocol (SNMP) ....................................................62
3.3.5 - Herramientas de Monitoreo de la JVM....................................................................63
3.3.6 - APIs de Administracin y Monitoreo ......................................................................64
Captulo 4: Solucin Propuesta e Implementacin .....................................................................65
4.1 - Servidor de aplicaciones - JBoss .....................................................................................67
4.1.1 - Arquitectura del JBoss AS .......................................................................................67
4.1.2 - JBoss web server ......................................................................................................68
4.2 - Monitor ............................................................................................................................69
4.2.1 - Nagios ......................................................................................................................69
4.2.1.1 - Arquitectura ..................................................................................................69
4.2.1.2 - Plugins ..........................................................................................................71
4.2.1.3 - Macros ..........................................................................................................72
4.2.2 - Recoleccin de mtricas ..........................................................................................73
4.3 - Sensor y Actuador ............................................................................................................74
4.3.1 - BrainyPDM ..............................................................................................................75
4.3.1.1 - Arquitectura ..................................................................................................75
4.3.2 - Recepcin de las mtricas ........................................................................................77
4.3.3 - Modificaciones Realizadas a BrainyPDM ...............................................................78
4.3.3.1 - Transmisin de las mtricas al sistema de control externo ..........................78
4.3.3.2 - Actuacin ......................................................................................................82
5
4.4 - Control mediante Modelos en Tiempo Real ....................................................................85

4.4.1 - Formalismo DEVS ...................................................................................................86
4.4.2 - PowerDEVS .............................................................................................................88
4.4.2.1 - Arquitectura de PowerDEVS .......................................................................88
4.4.3 - Modificaciones realizadas a PowerDEVS ...............................................................92
4.4.3.1 - Envo de datos al exterior .............................................................................92
4.4.3.2 - Recepcin de datos del exterior....................................................................92
Captulo 5: Prueba de Concepto ................................................................................................100
5.1 - Descripcin del escenario ..............................................................................................101
5.2 - Control ...........................................................................................................................101
5.2.1 - Controlador ............................................................................................................102
5.3 - Esquema de la prueba de concepto ................................................................................104
5.3.1 - Nagios ....................................................................................................................104
5.3.2 - BrainyPDM ............................................................................................................106
5.3.2.1 - Configuracin de los MBeans ....................................................................106
5.3.2.2 - Configuracin de los transmisores .............................................................107
5.3.2.3 - Configuracin de los actuadores ................................................................108
5.3.3 - PowerDEVS ...........................................................................................................109
5.3.3.1 - Sensor ......................................................................................................... 110
5.3.3.2 - Procesador .................................................................................................. 110
5.3.3.3 - Efector ........................................................................................................ 112
5.4 - Casos de prueba ............................................................................................................. 113
5.4.1 - Caso de prueba 1 .................................................................................................... 113
5.4.1.1 - Caso de Test 0 (Lnea de base) ................................................................... 114
5.4.1.2 - Caso de Test 1 ............................................................................................. 116
5.4.1.3 - Caso de Test 2 ............................................................................................. 118
5.4.2 - Caso de prueba 2 ....................................................................................................120
5.4.2.1 - Caso de Test 0 (Lnea de base) ...................................................................121
5.4.2.2 - Caso de Test 1 .............................................................................................122
5.4.3 - Discusin de resultados .........................................................................................125
Captulo 6: Conclusiones y Trabajo Futuro...............................................................................126
6.1 - Conclusiones ..................................................................................................................127
6.1.1 - Sntesis de aportes ..................................................................................................128
6.1.2 - Produccin cientfica .............................................................................................128

6.1.3 - Clasificacin segn la Taxonoma de Koopman ...................................................129
6.2 - Trabajo Futuro ...............................................................................................................130
Anexo A: Manual de instalacin ...............................................................................................131
A.1 - Compilacin ..................................................................................................................132
A.2 - Instalacin .....................................................................................................................133
A.2.1 - Nagios ...................................................................................................................133
A.2.2 - BrainyPDM ...........................................................................................................133
A.2.3 - PowerDEVS ..........................................................................................................135
A.2.4 - JBoss .....................................................................................................................135
Anexo B: Cdigo Fuente de los Modelos DEVS ......................................................................136
B.1 - Sensor ............................................................................................................................137
B.2 - Procesador .....................................................................................................................137
B.3 - Efector ...........................................................................................................................141
Anexo C: Artculo presentado en ASSE 2012 ...........................................................................144
Glosario .....................................................................................................................................161
Referencias ................................................................................................................................165
ndice de Figuras .......................................................................................................................173
ndice de Listados......................................................................................................................175
Captulo 1: Introduccin
1.1 - Contexto
La importancia de las disciplinas de aseguramiento de la calidad de servicio y de la
confiabilidad de Sistemas Informticos crece acorde a su incremento en complejidad y adopcin
masiva. Al mismo tiempo, aumentan las dificultades para implementar exitosamente dichas disciplinas
dentro de las restricciones impuestas por el mercado en trminos de tiempo y costos de desarrollo.
Surge entonces la necesidad de disear estrategias que le otorguen a los Sistemas Informticos
capacidades para administrarse en forma autnoma y automtica en fase de produccin, partiendo
exclusivamente de especificaciones de objetivos de calidad definidos en la fase de diseo. Esto implica
que posean la capacidad de reaccionar ante fallas propias y/o cambios en su entorno de ejecucin que
impliquen un desvo del objetivo de calidad estipulado, sin necesidad de intervencin humana y de
forma transparente para el usuario.
Diversos esfuerzos realizados tanto en el mbito acadmico como industrial han propuesto
distintos enfoques para obtener lo que se conoce como sistemas Self-Healing [Ghosh et al, 2007,
Koopman, 2003]. En el mbito privado IBM es una de las empresas que ms esfuerzos ha dedicado a
la investigacin en el tema (cf. [Ganek & Corbi, 2003] y [Kephart & Chess, 2003]).
La consideracin a priori, en fase de diseo, de todas las posibles condiciones de falla de un
sistema y el consecuente diseo de medidas explcitas para prevenirlas, presenta grandes dificultades
cuando los sistemas tienen una complejidad tan solo levemente mayor a casos triviales, haciendo a los
problemas intratables en la prctica (explosin de estados).
En cambio, el enfoque Self-Healing acepta la no idealidad del sistema y el dbil
conocimiento previo del comportamiento dinmico de su entorno y de sus usuarios, para luego
agregarle una capa de supervisin que detecte anomalas o situaciones que puedan conducir al sistema
supervisado a un estado no deseable, y reaccione controlando parmetros de operacin en pos de
contrarrestar el estado de falla. Esta estrategia es ms eficiente en trminos de escalabilidad ya que
depende en mucho menor medida (o en ninguna medida, dependiendo del caso) del tamao del
sistema. De hecho, una determinada estrategia de control puede ser directamente reutilizable
aplicndola a distintos Sistemas de Software de escala muy variada, siempre y cuando compartan
aquellas propiedades de su arquitectura para las cuales fue diseada la estrategia de control.
Existen diferentes enfoques para el desarrollo e investigacin de sistemas Self-Healing. En
[Ghosh et al., 2007] los autores relevan y clasifican varios de dichos enfoques.
Uno de los ms evolucionados y difundidos es el propuesto por los autores en [Garlan &
Schmerl, 2002]. Utiliza el modelo de arquitectura del sistema a controlar para evaluar la dinmica del
mismo durante su ejecucin y tomar decisiones acerca de la necesidad o no de aplicar acciones de
adaptacin. El modelo de arquitectura utilizado representa al sistema a travs de un grafo equivalente
que consta de componentes del sistema, sus interconexiones (conectores) y sus propiedades relevantes.
Este modelo es conocido en la literatura como C&C (componentes y conectores).
Otro enfoque muy distinto es el basado en modelos matemticos de ciertas dinmicas del
sistema y de lazos de realimentacin aptos para la aplicacin de la Ingeniera de Control (ver
[Patikirikorala et al., 2012] para un relevamiento sistemtico y el libro de texto [Hellerstein et al.,
2004] de referencia obligada en el tema).

Se trata de un rea joven, esencialmente interdisciplinaria, que aplica el vasto conocimiento
acumulado durante ms de dos siglos de uso de modelos matemticos para mecanismos de
autorregulacin de sistemas fsicos esta vez a controlar sistemas lgico-digitales (redes, sistemas de
cmputo). El objetivo de control suele ser el de mantener mtricas de performance (delay, jitter,
throughput, consumo de recursos, tasa de violacin de deadlines, etc.) dentro de ciertos rangos
aceptables usualmente especificados por medio de Requerimientos de Calidad.
Las acciones de control disparan eventos discretos que implican la regulacin gradual de
recursos disponibles (pools, buffers, colas, slots, etc.) entre diferentes consumidores compitiendo por
los mismos (tareas de sistema operativo, paquetes de red, trabajos en batch, pedidos HTTP, etc.)
Usualmente en las disciplinas informticas, controles de ese estilo suelen disearse usando
tcnicas ad-hoc. Sin embargo, la teora clsica de control ha sido reconocida como un camino
prometedor para explotar los conocimientos tericos y metodolgicos previos acumulados en dicha
disciplina [Arzen et al., 2006]. Basndose en teora de control, la estabilidad y la respuesta transitoria
de los mecanismos de control pueden ser sistemticamente analizadas en forma matemtica, y los
controladores pueden ser diseados siguiendo diferentes criterios de optimalidad y/o robustez.
Evidentemente, uno de los principales escollos a vencer es la carencia de primeros principios
fundamentales en los sistemas digitales, principios que la fsica provee claramente para sistemas
mecnicos, elctricos, hidrulicos, etc.
Es notable que independientemente del enfoque que se trate, todo sistema Self-Healing puede
plantearse conceptualmente como 4 etapas centrales expresables en trminos de Ingeniera de Control:
a) monitoreo, con el fin de la recoleccin de datos acerca de la ejecucin del sistema y de su entorno;
b) traduccin y clculo del error, en donde los datos recolectados son adaptados y comparados con
los objetivos de calidad, calculando los desvos o errores; c) control, dedicado al anlisis y clculo
de un curso de accin para contrarrestar los desvos y d) actuacin, para la ejecucin de acciones de
control concretas sobre propiedades manipulables del sistema.
1.2 - Motivacin
A pesar de la caracterizacin unificada aplicable a todo sistema de Self-Healing -mencionada
en la seccin precedente-, y de tratarse siempre de enfoques basados fundamentalmente en modelos aunque de distinta naturaleza-, es notable la gran dispersin de herramientas que proliferan.
Si bien la variedad de modelos surgidos de distintos enfoques puede interpretarse como una
virtud para una disciplina incipiente y en crecimiento, la consecuente diversidad de herramientas
especializadas para experimentacin y/o implementacin de soluciones prcticas aparece, en la
realidad, como una traba en al menos tres sentidos:
1. Difcil reutilizacin de tcnicas de monitoreo y actuacin, usualmente implementadas
de modo ad-hoc para situaciones particulares.
2. Difcil convergencia hacia una plataforma robusta y de aceptacin amplia que permita
permear la barrera de la investigacin para transferirse como tecnologa usable en la
industria de software.
10
3. Difcil colaboracin entre distintos dominios de especializacin (e.g. las comunidades

de Ingeniera de Software e Ingeniera de Control).
Luego, la motivacin principal disparadora de la presente Tesis es intentar superar estas
trabas, y como primer paso en este camino, construir una plataforma prctica de Self-Healing para:
1. Proveer de manera sencilla y flexible aquellas funciones comunes a todos los sistemas
de Self-Healing: Monitoreo y Actuacin, independiente de cualquier enfoque de diseo
de control.
2. Ofrecer una amplia libertad de adopcin de varios enfoques para diseo de
controladores basados en modelos, posibilitando incluso la coexistencia de enfoques.
3. Permitir una sencilla transicin desde el estado de prototipo de investigacin hacia el
estado de producto industrial.
Tal plataforma permitira a equipos de diseo de controladores -posiblemente
interdisciplinares- concentrar la mayor parte de sus esfuerzos en el desarrollo de mejores estrategias
de control basados en modelos, al reducir considerablemente los esfuerzos tcnicos previos (para poder
monitorear y actuar sobre el Sistema de Software objetivo) y posteriores (para poder transicionar hacia
un producto industrial).
Como se ver ms adelante, la adopcin de herramientas de modelado y simulacin para
desarrollar modelos multiformalismo tendr un impacto central en la efectividad de nuestra propuesta.
1.3 - Definicin del Problema

La gran mayora de las empresas han incorporado la utilizacin de Sistemas Informticos como
componente crtico de sus negocios. An ms, muchas los utilizan como nico medio para brindar sus
servicios y en los escenarios ms exigentes se requiere que los sistemas presten servicio las 24 horas
los 365 das del ao. Por otro lado, con el crecimiento de Internet y el avance de las tecnologas de
hardware y software, los sistemas se han vuelto cada vez ms complejos.
En los ltimos tiempos se increment notablemente la utilizacin de la plataforma Java
Enterprice Edition (JEE) para el desarrollo de las aplicaciones distribuidas que apoyan las operaciones
de negocio, especialmente por parte de las PyMES (Pequeas y Medianas Empresas). Siendo adems
el JBoss el servidor de aplicaciones open source ms utilizado en el mercado capaz de competir con
los servidores propietarios.
Sin embargo, se destinan escasos, y a veces nulos recursos para control del cumplimiento de los
objetivos de calidad durante la ejecucin de estos sistemas. La administracin de los mismos se suele
limitar al monitoreo y mantenimiento manual reactivo ante la ocurrencia de fallas.
De esta forma surge la necesidad de monitorear el comportamiento de tales sistemas para as
poder detectar problemas o situaciones anmalas a tiempo y resolverlos antes de que llegaran a ser
fatal y afectar seriamente el negocio. An ms, es deseable que este proceso se encuentre
automatizado. Es decir, que exista un mecanismo capaz de monitorear las mtricas de calidad
deseadas, analizarlas, detectar condiciones anmalas que presenten un riesgo potencial de
incumplimientos de los objetivos de calidad, planificar las acciones correctivas y luego aplicarlas, sin
11
intervencin humana y en forma transparente para el usuario.

Se define entonces la necesidad de contar con herramientas para simplificar el proceso de
implementacin de controladores que permitan incorporar capacidades de Self-Healing a los Sistemas
Informticos.
1.4 - Objetivos
La presente Tesis se propone disear una infraestructura genrica y reutilizable para incorporar
rpidamente capacidades de Self-Healing a Sistemas de Software y a su infraestructura de hardware.
Como caso prctico de demostracin se adoptar como Sistema de Software a ser controlado a
un Servidor de Aplicaciones JEE JBoss, incluyendo la Mquina Virtual Java (JVM - Java Virtual
Machine) sobre la cual se ejecuta.
Nuestra nueva infraestructura deber permitir:
A. Recolectar informacin de la JVM, del Servidor de Aplicaciones y del su entorno de
ejecucin (e.g. recursos de hardware, red, etc.)
B. Prevenir la ocurrencia de fallas y/o de situaciones anmalas que puedan comprometer la
confiabilidad del sistema, o en caso de ocurrencia pueda sobreponerse a las mismas.
C. Adoptar diversas posibles estrategias de control de manera flexible y sencilla sin que ello
implique la necesidad de realizar modificaciones de bajo nivel en la plataforma.
Se relevar y documentar el estado del arte de las tecnologas existentes que permiten obtener
informacin tanto de la JVM como del Servidor de Aplicaciones as como tambin de aquellas que
posibiliten actuar sobre los mismos.
Las tecnologas para lograr lo tems A, B y C descriptos arriba debern ofrecer la mayor
generalidad posible: su pertinencia para el caso prctico seleccionado (JBoss+JVM) deber
representar slo un caso particular.
1.5 - Estructura del Informe

El presente informe se encuentra organizado de la siguiente manera:
En el Captulo 2 se resean algunos conceptos necesarios para comprender y contextualizar el
contenido del informe.
El Captulo 3 presenta el estado del arte acerca del desarrollo de sistemas Self-Healing y sus
diversos enfoques de arquitectura ms importantes. En l adems se presentan algunos trabajos previos
relevantes investigados en esta Tesis y se enumeran las principales tecnologas existentes que permiten
el monitoreo y actuacin sobre la JVM y el JBoss.
En el Captulo 4 se describe la nueva infraestructura desarrollada, su arquitectura y los detalles
relevantes de implementacin. En particular, en la Seccin 4.4 - Control mediante Modelos en Tiempo
Real, se detalla la decisin de diseo ms saliente del presente trabajo: la utilizacin de un simulador
12
en modo System-In-The-Loop como contenedor de los modelos de control.

El Captulo 5 propone una prueba de concepto con diversos casos prcticos de test y se
muestran resultados fruto de la aplicacin de la plataforma sobre un sistema real.
Finalmente en el Captulo 6 se presentan las conclusiones de la Tesis y los trabajos futuros que
se desprenden de la misma.
En los Anexos se encuentra el Manual de Instalacin de la plataforma desarrollada, el cdigo
fuente de los modelos que componen el sistema controlador utilizado en los casos de test, y el artculo
cientfico producido a partir de los resultados de la presente Tesis.
13
Captulo 2: Conceptos
Preliminares
14
El objetivo del captulo es introducir los conceptos necesarios para comprender el alcance del
presente trabajo. Los cuales involucran la descripcin de la JVM, los Servidores de Aplicaciones, la
especificacin JEE, los sistemas Self-Healing y los conceptos que ellos implican as como tambin una
descripcin acerca de los conceptos de monitoreo y actuacin.
2.1 - JVM
La JVM (del ingls Java Virtual Machine) es una computadora abstracta, o mquina virtual
(tambin llamada VM del ingls Virtual Machine) que, al igual que una real, consta de un conjunto de
instrucciones y maneja varias reas de memoria en tiempo de ejecucin. Pertenece a la categora de las
mquinas virtuales HLL-VM, del ingls High Level Language Virtual Machine (Mquinas Virtuales
de Lenguaje de Alto Nivel) del tipo de Process Virtual Machine (Mquinas Virtuales de Procesos).
Este tipo de mquina virtual se ejecuta como un proceso normal dentro de un sistema operativo y
soporta la ejecucin de un slo proceso dentro de la misma. Por otro lado, la mquina se inicia
automticamente cuando se lanza el proceso que se desea ejecutar (una aplicacin Java en el caso de
una JVM) y se termina cuando ste ltimo finaliza. Su objetivo es el de proporcionar un entorno de
ejecucin independiente de la plataforma de hardware y del sistema operativo, que oculte los detalles
de la plataforma subyacente y permita que un programa se ejecute siempre de la misma manera sobre
cualquier plataforma. Es decir que este tipo de mquina virtual da soporte para la programacin
multiplataforma. Para ms detalle acerca de la arquitectura y tipos de mquinas virtuales consultar
[Smith & Nair, 2005].
En una mquina virtual HLL-VM existe un compilador que genera cdigo en un determinado
conjunto o juego de instrucciones virtual especfico de la VM, es decir en un determinado ISA (del
ingls Instruction Set Architecture). En el caso de la JVM a este conjunto de instrucciones se lo llama
bytecode. Este cdigo, junto con informacin de la estructura (metadata), es lo que es distribuido para
que pueda ser ejecutado en las distintas plataformas (archivos .class para el caso de la JVM), para lo
cual se debe contar con una mquina virtual, capaz de cargarlo y ejecutarlo, para cada una de las
mismas. La ejecucin del cdigo puede ser ya sea mediante un intrprete (forma ms simple) o a travs
de un compilador que lo compila en el cdigo de maquina (cdigo nativo) de la plataforma para que
sea directamente ejecutado en la misma (ejecucin ms rpida). El esquema del funcionamiento
descripto se encuentra resumido en la Figura 1.
Existen diferentes implementaciones de la JVM para distintas plataformas y de distintas
organizaciones, adems la misma puede ser desarrollada en software, hardware, en web browser, pero
todas tienen que cumplir con la especificacin dada por Sun (Oracle en la actualidad), la cual est
descripta en [Lindholm & Yellin, 1999].
15
Figura 1 - Esquema de funcionamiento de una HLL-VM
2.1.1 - Componentes Principales de la JVM

En la Figura 2 se muestra el esquema de la arquitectura de la JVM adoptado como base para el
presente trabajo, obtenido de [Orlando & Russo, 2006]. En la misma se puede ver los componentes
principales de la JVM los cuales son descriptos a continuacin.
Cabe resaltar la particular relevancia del mecanismo de Garbage Collector, el cual jugar un rol
importante en la Seccin 5.4 - Casos de Prueba.
Execution Unit o Unidad de ejecucin: en este componente se encuentra las funcionalidades
de la JVM encargadas de ejecutar, emulando una CPU, las operaciones necesarias. Una
operacin puede ser una instruccin en bytecode, es decir una instruccin del ISA de la JVM,
una instruccin del compilador o una instruccin en cdigo nativo. Est compuesto por:
o Interpreter o Interprete: es el encargado de traducir las instrucciones del bytecode a
instrucciones nativas de la plataforma destino.
o Just In Time Compiler o Compilador en tiempo de ejecucin: quien es el encargado
de transformar los mtodos que se encuentran en bytecode a cdigo nativo aplicndole
algunas optimizaciones.
o JNI - Java Native Interface o Interfaz nativa Java: quien se encarga de la carga
dinmica y la ejecucin de las instrucciones nativas.
o Exception Handler o Manejador de excepciones: es el encargado de manejar las
excepciones lanzadas por las aplicaciones as como tambin las lanzadas por la VM.
Estas ltimas son definidas como unchecked, excepciones no chequeadas y estn
16
vinculadas con errores ocurridos dentro de la VM. Mientras que las primeras son
definidas como checked, es decir excepciones chequeadas.
OS Virtualization Layer Unit o Capa de virtualizacin del sistema operativo: este mdulo es
una capa de abstraccin que provee un punto de entrada para todos los componentes de la JVM
a los recursos del sistema operativo.
Memory Management Unit o Unidad de manejo de memoria: se encarga del manejo de la
memoria Heap y la memoria stack de la JVM. La memoria Heap es un rea de memoria
compartida por todos los threads donde se almacenan las instancias de las clases, es decir los
objetos, y las colecciones creados durante la ejecucin de la aplicacin Java. Mientras que la
memoria stack es el espacio de memoria dado a cada nuevo thread creado y es donde se
almacenan las variables locales y los resultados parciales durante la ejecucin de una funcin,
esta memoria juega un rol fundamental en la invocacin de mtodos y en la devolucin de los
resultados. Para ms detalle acerca del tema se puede consultar [Venners, 2000a]. Entre las
funcionalidades de este componente se encuentra la administracin de: la creacin de objetos, la
referencia entre ellos, la finalizacin y la eliminacin de los mismos de la memoria. Adems
contiene mecanismos de creacin de memoria rpida para la asignacin de reas de memoria
para operaciones internas de la JVM (Fast Allocation Mechanisms). Una parte principal de este
componente es el Garbage Collector:
o Garbage Collector: debido a que en el lenguaje de programacin Java, a diferencia de
otros lenguajes de programacin, no es responsabilidad del programador la liberacin
de la memoria que dej de ser utilizada, existe este componente encargado de hacerlo.
El Garbage Collector es el componente de la JVM encargado de revisar la memoria y
desalojar los objetos que ya no estn siendo utilizados. Existen diferentes estrategias de
implementacin de este algoritmo. Para ms detalle se puede consultar [Venners,
2000b].
System Services Unit o Unidad de servicios del sistema: est formada por componentes que
ofrecen servicios de alto nivel a las aplicaciones Java, entre los cuales se encuentran:
o Thread Management o Administracin de los threads: se encarga del manejo de la
creacin y finalizacin de los threads, as como tambin de los mecanismos de
sincronizacin de los mismos de acuerdo a la especificacin de la JVM [Lindholm &
Yellin, 1999] y a la especificacin del lenguaje Java [Gosling et al., 2005].
o Class Loader o Cargador de clases: es el responsable de la carga de las clases a
memoria. Dado el nombre de una clase, este componente se encarga de localizar la
definicin de la misma.
o Management and Debugging o Depurador y Administrador: incluye funcionalidades
para debugging (depuracin) de las aplicaciones y para la administracin de la JVM.
17
Figura 2 - Arquitectura de la JVM obtenida de [Orlando & Russo, 2006]
2.2 - Servidores de Aplicaciones JEE

Un Servidor de Aplicaciones o Application Server es un Sistema de Software que funciona
como contenedor o marco para la ejecucin de aplicaciones, generalmente se trata de las llamadas
aplicaciones empresariales, es decir aplicaciones que dan soporte integral al negocio de una empresa.
Se encuentra conformado por un conjunto de componentes independientes e interdependientes
entre s que implementan funcionalidades comunes a todas las aplicaciones, independientemente del
negocio a la cual se trate y que no estn relacionadas con el mismo, como ejemplo se puede citar el
manejo de la seguridad, el acceso a sistemas externos, incluyendo base de datos, manejo de
transacciones, etc. De esta forma estos componentes funcionan como frameworks para la construccin
de las aplicaciones permitiendo as que el desarrollo de las mismas este concentrado principalmente en
las funcionalidades propias del negocio depositando en dichos componentes las funcionalidades de
soporte.
En tiempo de ejecucin el Servidor de Aplicaciones es el encargado del manejo de la
optimizacin de los recursos del sistema, e.g. la memoria, los threads, etc. as como tambin de la
conectividad con recursos externos, e.g. un motor de base de datos. Adems es el responsable de
proveer la calidad del servicio (QoS - Quality of Service) deseada para las aplicaciones que se ejecutan
en l, incluyendo disponibilidad, confiabilidad, seguridad, escalabilidad, etc.
Las arquitecturas ms utilizadas de Servidores de Aplicaciones son .NET, propietaria de
Microsoft y JEE, conocida anteriormente como J2EE de la cual existen productos de diversas
empresas y organizaciones.
18
Un Servidor de Aplicaciones JEE es un Servidor de Aplicaciones que cumple con la

especificacin JEE (Java Enterprise Edition) desarrollada por The Java Community Process / JCP
[JCP]. Es decir que un Servidor de Aplicaciones Java ejecuta aplicaciones desarrolladas en dicho
lenguaje, por lo tanto se ejecuta sobre una JVM.
La JCP o Java Community Process es un proceso abierto y participativo creado en 1998 para
el desarrollo y revisin de las especificaciones de la tecnologa Java.
Si bien la JEE es una especificacin tambin es considerada como un estndar debido a que los
Servidores de Aplicaciones deben cumplir ciertos requisitos de conformidad para ser declarados
conformes a JEE.
La JEE define un marco para el desarrollo en el lenguaje Java de Aplicaciones Empresariales
multi-capas o multi-tier. En la Figura 3 se muestra la arquitectura de la misma en donde se puede
observar las tres capas que la componen. Por un lado se tiene la Capa Cliente o Client Tier, en donde
se brinda soporte para diversos tipos de clientes, entre ellos los navegadores web o web browsers
(accediendo ya sea mediante HTML o mediante applets), aplicaciones Java, entre otros. Por otro lado
se encuentra la Capa Media o Middle Tier, la cual est compuesta por dos subcapas: el contenedor web
o Web Container y el contenedor EJB Enterprise JavaBeans o EJB Container, las cuales sern
tratadas en el prximo prrafo ya que ellas son los componentes principales de los Servidores de
Aplicaciones Java. La ltima capa de la arquitectura se trata de la capa llamada EIS - Enterprise
Information Tier y es la que da soporte para el acceso a sistemas de informacin existentes por medio
de APIs estndares, como por ejemplo a gestores de base de datos. Para mayor informacin acerca de
la plataforma JEE se puede consultar [Singh et al, 2002] y [Jendrock et al, 2010].
Figura 3 - Arquitectura de JEE (obtenida de [Singh et al, 2002])
Un concepto clave de la arquitectura JEE es el de contenedor, el cual no es ms que un

19
ambiente de ejecucin estandarizado que provee diversos servicios, por ejemplo el contenedor web
provee el servicio de atender los pedidos de los clientes, procesarlos y devolver las respuestas,
mientras que el contenedor EJB provee soporte para el manejo automtico de la transaccin y del ciclo
de vida de los componentes EJB, como tambin proveen una manera estndar de acceso a la base de
datos.
El contenedor web, tambin llamado contenedor Servlet/JSP, es responsable de manejar el
ciclo de vida de los servlets y las pginas JSP as como tambin de mapear las URLs a los respectivos
servlets.
Un servlet es una clase Java que se ejecuta del lado del servidor y, o bien implementa la
interfaz javax.servlet.Servlet o hereda de alguna de las clases ms convenientes para un protocolo
especfico, como por ejemplo la clase javax.servlet.http.HttpServlet. Reciben peticiones y devuelven
los resultados siguiendo el protocolo HTTP, siendo el formato ms comn de salida una pgina HTML
o un archivo XML.
Una pgina JSP o Java Server Pages es, desde el punto de vista funcional, similar a un servlet
ya que el contenedor la convierte en un servlet la primera vez que es ejecutada. Son un hbrido entre
HTML y Java que nacieron como una simplificacin del estndar Java Servlet. En sus primeras
versiones eran una combinacin de HTML con cdigo Java embebido luego, con el uso de XML,
surgieron las JSP Tag Libs (bibliotecas de etiquetas XML que permiten el acceso a cdigo Java
compilado) para luego pasar a ser el estndar JSTL (JSP Standard Tag Libraries), es decir que las
pginas JSP permiten mezclar HTML esttico con HTML generado dinmicamente.
Cuando un navegador invoca un aplicacin lo hace mediante el protocolo HTTP y quien recibe
dicha peticin es el servidor web, un componente del contenedor web1, quien es el responsable de
trasladar la solicitud al contenedor web propiamente dicho quien invoca el servlet correspondiente.
Si bien el funcionamiento de un contenedor web es algo complejo existen tres pasos
principales que realiza al recibir un pedido para un determinado servlet:
1. Crea un objeto ya sea de la interfaz javax.servlet.ServletRequest o de la interfaz
javax.servlet.http.ServletRequest, llamado request y lo llena con la informacin del pedido
que ser utilizada por el servlet, entre ella se encuentra: los parmetros, el header del
mensaje, los cookies, etc.
2. Crea un objeto de la interfaz javax.servlet.ServletResponse o de la interfaz
javax.servlet.http.ServletResponse, llamado response que ser utilizado por el servlet para
enviarle la respuesta del pedido al cliente.
3. Invoca el servlet correspondiente pasndole como parmetro los objetos creados. ste utiliza
el objeto request para tomar conocimiento del pedido realizado y luego de procesarlo
cargara en el objeto response la respuesta al mismo.
El contenedor EJB gestiona la ejecucin de los EJB. Los EJB o Enterprise Java Beans son
componentes escritos en Java que encapsulan, de una forma integrada, la lgica del negocio de una
aplicacin, es decir la funcionalidad que cumple con los objetivos principales de la misma [Jendrock et
al, 2010]. El contenedor, adems de manejar el ciclo de vida de estos componentes, se encarga de otras
1
Funcionamiento bsico, existe la posibilidad de utilizar un servidor web externo.
20
funcionalidades crticas comunes a todas las aplicaciones como es el manejo de transacciones, la

seguridad de acceso a los EJB, manejo de la concurrencia, la persistencia de los datos, etc., de esta
forma el desarrollador de las aplicaciones tiene que nicamente preocuparse por la programacin de la
lgica del negocio de las mismas. Es decir que el contenedor EJB permite a mltiples aplicaciones
tener acceso de forma concurrente a datos y lgica de negocio de manera segura y optimizada.
2.3 - Confiabilidad y Sistemas Self-Healing

Con el crecimiento del uso y de la complejidad de los Sistemas Informticos, la confiabilidad
de los mismos fue cobrando cada vez mayor importancia. Hecho que incentiv el comienzo de la
investigacin acerca de cmo hacer que los sistemas puedan administrarse a s mismo, es decir que
tenga la capacidad de reaccionar antes fallas y/o cambios en su ambiente de ejecucin, sin la necesidad
de la intervencin humana, de manera similar a como el sistema biolgico cura las heridas del cuerpo.
De esta manera surgieron varios trminos relacionados con este tema: Self-Healing, SelfManager, Self-Adaptative, Autonomic Computing, entre otros [Huebscher & McCann, 2008], [Salehie
& Tahvildari, 2009] y [Cheng et al, 2009]. No existiendo una unificacin en el criterio de su
utilizacin.
A modo de ejemplo, IBM, una de las empresas que dedica esfuerzo a la investigacin acerca de
este tema, como lo demuestran las publicaciones [Ganek & Corbi, 2003] y [Kephart & Chess, 2003],
utiliza los trminos Autonomic Computing y Self-Management para definir a los sistemas que pueden
auto administrarse en lo referente a las siguientes 4 habilidades: incorporacin automtica de nuevos
componentes, auto optimizacin, auto proteccin y auto recuperacin ante fallas o errores. Se reserva
el trmino Self-Healing para indicar la ltima habilidad mencionada: auto recuperacin ante fallas o
errores [Kephart & Chess, 2003] y [Hinnelund, 2004].
En el ambiente acadmico se utiliza el trmino Self-Healing como sinnimo de self-adaptative
(auto adaptable) y de self-managing (auto administrable), y describe a los sistemas que tienen
mecanismos de auto monitoreo y adaptacin ante fallas o cambios en el ambiente como se puede
encontrar en [Cheng et al., 2005]. En otros trabajos se lo utiliza para indicar un componente de los
sistemas self-management (auto administrables) [Park et al., 2008], tambin es utilizado como
sinnimo de fault tolerance (tolerante a fallas) [Avizienis et al., 2004].
Como puedes verse no hay un consenso en la definicin y el alcance de los sistemas SelfHealing, pero lo que s podemos afirmar es que su objetivo es obtener sistemas confiables.
Siendo el objetivo de la incorporacin de caractersticas Self-Healing a un sistema hacer que el
mismo sea confiable (dependable), comenzaremos por definir que significa que un sistema sea
confiable. Para ello se usar como base el trabajo [Avizienis et al., 2004].
2.3.1 - Qu se entiende por confiabilidad de un sistema?

La definicin estndar de confiabilidad indica que es la capacidad de un sistema de entregar
servicios que pueda justificadamente ser confiables o en otras palabras, es la medida en la que pueda
justificadamente confiarse en el servicio entregado por un sistema [Verssimo & Rodrigues, 2001],
21
entendindose como servicio entregado por un sistema como el comportamiento percibido por el
usuario del mismo.
En [Avizienis et al., 2004] proponen una definicin alternativa basada en el criterio que un
sistema puede fallar y usualmente lo hace, frente a lo cual surge el interrogante el sistema sigue
siendo confiable a pesar de haber ocurrido una falla? En base a esto, la definicin propuesta indica que
la confiabilidad es la capacidad de un sistema de evitar que ocurran fallas ms frecuentemente o con
ms gravedad que lo aceptable. Esta definicin provee un criterio para decidir si, a pesar de la falla
ocurrida, un sistema puede considerarse confiable. En el trabajo [Avizienis et al., 2000] puede
encontrarse los orgenes del concepto de confiabilidad.
El grado de confiabilidad de un sistema puede ser evaluado o expresado a travs de los
atributos del mismo listados a continuacin, muchos de los cuales pueden ser expresados como
funciones de probabilidad ([Verssimo & Rodrigues, 2001]):
Availability o disponibilidad: indica el grado en que el sistema se encuentra operable y puede
ser expresado como la probabilidad que el sistema se encuentre operativo en un determinado
tiempo.
Realiability o exactitud: se refiere a la continuidad en el correcto funcionamiento del sistema y
puede ser expresado como la probabilidad que el sistema no falle durante el perodo de
produccin del mismo. Para sistemas de perodo de produccin continuo, este atributo puede ser
expresado como el tiempo medio entre fallas o el tiempo promedio hasta que se produzca una
falla.
Safety o seguridad: indica el grado de ausencia de consecuencias catastrficas, en los usuarios
y en el ambiente, cuando el sistema falla. Puede expresarse como la probabilidad condicional de
que, dada una falla, la misma no sea catastrfica.
Integrity o integridad: indica la ausencia de alteraciones en el sistema.
Maintainability o mantenibilidad: mide la capacidad de experimentar modificaciones y
reparaciones del sistema y puede expresarse como el tiempo necesario para recuperarse.
Algunos de estos atributos pueden no ser necesarios en todos los sistemas, pero cuando lo son
deben ser considerados en un sentido probabilstico y no determinstico, ya que es inevitable la
presencia u ocurrencia de fallas.
2.3.1.1 - Las Amenazas a la Confiabilidad del Sistema

Durante el ciclo de vida de un sistema, que consiste en las fases de desarrollo y uso, el mismo
puede sufrir distintas amenazas que comprometan su confiabilidad. Cuando la misma se ve
comprometida, su deterioro involucra tres facetas: failure (falla), error y fault (defecto).
Failure o Falla
Se dice que se produce una falla cuando el sistema no brinda su servicio en forma correcta, ya
sea porque no cumple con la especificacin funcional, es decir la descripcin acordada del servicio
esperado, o porque la cumple pero la misma no es correcta, lo que significa que no es aceptable para el
usuario.
22
Las fallas pueden ser calificadas de acuerdo a los siguientes puntos de vista:
Dominio: segn el punto de vista del dominio del efecto del dao provocado por la falla se
puede tener dos tipos:
o las que afectan al contenido de la informacin entregada, las cuales son llamadas
content failure o fallas de contenido.
o las que afectan al tiempo de respuesta del sistema, llamadas timing failures o fallas
temporales.
Puede suceder el hecho que una falla sea de ambos tipos, es decir que afecte el contenido de la
informacin entregada y a la vez los tiempos de respuesta del sistema. En este caso tenemos dos
escenarios posibles: que el sistema deje de funcionar, ante lo cual estamos frente a una falla por
cada o halt failure o que siga funcionando pero de manera errnea, siendo la sucedida una falla
llamada falla errtica o erratic failure.
Deteccin: cuando el dao producido por la falla es detectado e indicado al usuario, estamos en
presencia de signaled failures o fallas sealizadas, en caso contrario se la llama unsigned
failures o fallas no sealizadas.
Consistencia: desde el punto de vista de como los usuarios del servicio brindado por el sistema
perciben al mismo en presencia de una falla, podemos tener los siguientes casos:
o el servicio del sistema es percibido idnticamente por todos los usuarios, en cuyo caso
estamos en presencia de una falla consistente o consistent failure.
o algunos o todos los usuarios perciben diferentes servicios por parte del sistema, en este
caso de dice que la falla es inconsistente o inconsistent failure, este tipo de fallas
tambin es conocido como Byzantines failures o falla Bizantinas.
Consecuencias: desde el punto de vista de las consecuencias de la falla producida sobre el
entorno del sistema, se pueden definir dos niveles de severidad lmites, en relacin al beneficio
de proveer el servicio en ausencias de fallas y las consecuencias de la ocurrencia de las mismas
o minor failures o fallas menores, en el caso donde los costos del dao son similares al
beneficio de proveer el servicio sin fallas.
o catastrophic failures o fallas catastrficas, para el caso donde el costo de las
consecuencias es mucho mayor.
Error
Un error es la parte del estado del sistema que es susceptible de producir una falla, es decir que
una falla es el efecto externo observable del error. Es por eso que fallas similares pueden ser
ocasionadas por diferentes errores.
Que un error pueda conducir a la presencia de una falla depende de dos factores:
la estructura del sistema, en especial de la redundancia que exista.
el comportamiento del sistema, la parte del mismo que contiene el error puede nunca ser
necesitada o ejecutada para brindar el servicio o un error puede ser eliminado antes de que
23
produzca la falla.
Se dice que un error es detectado si su presencia es indicada por algn mensaje indicativo o se
percibe alguna seal del mismo, si est presente pero no es detectado se dice que el error es latente.
Una forma de clasificar los errores es de acuerdo a las fallas que ellos pueden causar.
Fault o Defecto
Un defecto es la causa de un error, es decir que un error es una manifestacin de un defecto en
el sistema. Se dice que un defecto est latente cuando no genera una falla y se dice que se activa
cuando la causa.
Todos los defectos que pueden afectar a un sistema durante su ciclo de vida son clasificadas
segn los siguientes puntos de vista:
Punto de vista
Defectos
Segn la fase de creacin u ocurrencia
defectos de desarrollo
defectos operacionales
Segn se produzcan dentro o fuera del sistema
internos
externos
Segn la causa fenomenolgica
causados por fenmenos naturales

causados por el hombre
Segn la dimensin
defectos de hardware
defectos de software
Segn el objetivo
maliciosos
no maliciosos
Segn la intensin
intencionados
no intencionados
Segn la capacidad
defectos accidentales
defectos causados por incompetencia
Segn su persistencia
permanentes
transitorios
En [Avizienis et al., 2004] se identificaron 31 posibles combinaciones entre estas clases

elementales de defectos, las cuales fueron volcadas en un diagrama similar a los de la Figura 4 y
Figura 5, y clasificadas en los siguientes grupos no excluyentes entre s: defectos de desarrollo o
developmnet faults (1 al 11), defectos fsicos o physical faults (6 a 23) y defectos de iteracin o
iteractions faults (14 a 31).
24
Figura 4 - Clases de defectos combinados Parte 1
Figura 5 - Clases de defectos combinados Parte 2
25
Los autores concluyen lo siguiente a partir del anlisis de la clasificacin realizada:

Los defectos naturales, que son los enumerados desde 11 al 15, son defectos fsicos (hardware)
causados por fenmenos naturales sin intervencin humana. Durante la fase de operacin del
sistema estos defectos pueden ser internos (defectos 12-13), debido a procesos naturales que
causan deterioros fsicos o externos (defectos 14-15), debidos a procesos naturales que se
originan afuera del sistema y causan interferencias fsicas.
Los defectos causados por el hombre son resultados ya sea por la accin u omisin de acciones.
Segn su objetivo, pueden dividirse en:
o maliciosos (defectos 5-6 y 22-25): son defectos introducidos con el propsito de causar
dao o alterar el funcionamiento del sistema y cuyo objetivo puede ser causar la
negacin del servicio, acceder a informacin confidencial o modificar el sistema.
o no maliciosos (defectos 1-4, 7-21 y 26-31): son defectos introducidos sin intensiones
malignas pudiendo ser causados accidentalmente o por incompetencia.
Los defectos de iteracin son defectos operacionales causados por elementos externos al
sistema, ya sea por acciones del hombre o por fenmenos naturales. Para que este tipo de
defectos prosperen generalmente necesitan la presencia de una vulnerabilidad, es decir de una
debilidad en el sistema.
Fallas en la confiabilidad del sistema

Los defectos pueden causar una inaceptable degradacin del rendimiento del sistema o hasta la
falla total del mismo. Por esta razn, en la especificacin de confiabilidad se debe acordar lo esperado
sobre cada uno de los atributos que la describen. Indicando que clases de defectos son esperados y el
ambiente en el cual el sistema operar.
Una falla en la confiabilidad ocurre cuando el sistema sufre fallas ms frecuentemente o ms
graves que lo aceptable.
2.3.1.2 - Formas de Lograr la Confiabilidad de un Sistema

Existen diversas tcnicas para conseguir que un sistema sea confiable, la eleccin de la misma
depender de cual atributo o atributos de la confiabilidad son requeridos para el sistema en cuestin.
Las tcnicas existentes son:
Fault prevention o prevencin de fallas: tiene como objetivo mejorar o modificar los procesos
de desarrollo de manera tal de reducir el nmero de defectos introducidos en el sistema
producido.
Fault tolerance o tolerancia a fallas: el objetivo de esta tcnica es garantizar que el sistema
contine operando adecuadamente an ante la presencia de algn defecto en alguno de sus
componentes. Consta de las siguientes fases:
o Error detection o deteccin de errores: identificacin de la presencia de un error en el
sistema, utilizando alguna de las siguientes estrategias:
Concurrent detection o deteccin concurrente: la deteccin se realiza durante

el funcionamiento normal del sistema.
26
Preemptive detection o deteccin preventiva: la deteccin se realiza

suspendiendo el funcionamiento del sistema, etrategia utilizada para chequear
errores y defectos latentes.
o Recovery o recuperacin del sistema: se trata de llevar al sistema a un estado sin

errores detectados y sin defectos que puedan activarse nuevamente, de manera tal que
pueda seguir operando. Estrategias posibles:
Error handling o manejo de errores: eliminacin de los errores del estado

actual del sistema utilizando alguna de las siguientes tcnicas:
Rollback o recuperacin hacia atrs: consiste en llevar el sistema al

ltimo estado guardado anterior a la ocurrencia del error, los estados
guardados se llaman checkpoint.
Rollforward o recuperacin hacia adelante: consiste en llevar al

sistema a un estado de coherencia futura, es decir a un estado sin errores
posterior a la ocurrencia del error. Esta tcnica es aplicada en los casos
en donde los daos causados pueden ser completamente calculados
permitiendo hacer correcciones al estado errneo.
Compensation o recuperacin por compensacin: consiste en lograr

que el estado errneo tenga suficiente redundancia como para lograr
enmascarar el error ocurrido.
Fault handling o manejo de los defectos: evitar que los defectos se activen
nuevamente a travs de los siguientes pasos:
1. Diagnstico del defecto: se identifican las causas del error, registrando
su ubicacin y tipo.
2. Aislamiento del defecto: luego de identificar las causas del error se
aslan, lgica o fsicamente, los componentes defectuosos para evitar que
los mismos participen en la entrega del servicio del sistema.
3. Reconfiguracin del sistema: luego del aislamiento de los componentes
defectuosos se realiza la reconfiguracin del sistema, que puede consistir
en la conmutacin a componentes de repuesto o en la reasignacin de
tareas entre los componentes que permanecen sanos.
4. Reinicializacin del sistema: por ltimo, se reinicia el sistema y se
chequea, actualiza y graba la nueva configuracin actualizando las tablas
y registros del mismo.
Combinando las distintas estrategias de deteccin de errores con las de recuperacin se

obtienen distintas tcnicas a aplicar. La eleccin de cual utilizar est directamente relacionada con las
clases de fallas que pueden ser toleradas. No todas las tcnicas de implementacin de fault toelrance
son igualmente efectivas. Se llama coverage o alcance a la medida de su efectividad y se define como
la probabilidad que pueda ser tolerada una determinada falla [Verssimo & Rodrigues, 2001].
27
Fault removal o remocin de fallas: esta tcnica puede aplicarse tanto en la fase de desarrollo
como en la de produccin.
o En la fase de desarrollo consiste de tres pasos:
1. Verificacin: se chequea que el sistema cumpla determinadas propiedades
llamadas condiciones de verificacin.
2. Diagnstico: si la verificacin resulta negativa, es decir que no se cumplen las
condiciones de verificacin, se pasa a diagnosticar los defectos que hacen que no
se cumplan dichas condiciones.
3. Correccin: luego del diagnstico se pasa a realizar las correcciones necesarias.
o Para la fase de produccin las tcnicas a aplicar pueden ser:
De mantenimiento correctivo: para remover defectos que produjeron errores.
Preventivo: para descubrir y remover defectos antes que causen errores.
Fault forecasting o prediccin de fallas: esta tcnica se realiza mediante una evaluacin del
comportamiento del sistema con respecto a la ocurrencia o activacin de defectos. Esta
evaluacin tiene dos formas:
o Evaluacin cualitativa u ordinal: identificar, clasificar y categorizar los tipos de fallas
o la combinacin de eventos que pueden generar una falla en el sistema.
o Evaluacin cuantitativa o probabilstica: evaluar en trminos de probabilidades la
medida en que algunos de los atributos de confiabilidad son satisfechos.
2.3.2 - Elementos de los Sistemas Self-Healing

En [Koopman, 2003] se desarroll una taxonoma para la descripcin de los elementos que
forman parte de los sistemas Self-Healing. Se proponen cuatro categoras generales para la descripcin
de los mismos: fault-model (modelo de defectos), system response (respuesta del sistema), system
completeness (completitud del sistema) y design context (contexto de diseo).
2.3.2.1 - Fault Model o modelo de defectos

En esta categora se describen los defectos de los cuales se espera que el sistema sea capaz de
sobreponerse, es decir, de aquellos que tolerar. Las caractersticas tpicas que se utilizan para la
descripcin de los mismos son:
Fault duration o duracin del defecto: si los defectos son permanentes, intermitentes (slo
aparecen ocasionalmente) o transitorios (causadas por una condicin del entorno que aparece
slo ocasionalmente).
Fault manifestation o manifestacin del defecto:
o Caractersticas de la manifestacin de los defectos y del sistema ante la ocurrencia de
los mismos: si el componente defectuoso informa de la ocurrencia del efecto o si en
presencia del mismo deja de funcionar, etc.
28
o Gravedad de la ocurrencia de los efectos y la severidad en que ellos afecta al sistema en

ausencia de mecanismos de Self-Healing: por ejemplo si en presencia del efecto el
sistema se cae o si sigue funcionando pero con ciertas limitaciones (ms lento, con
prdida de recursos, etc.).
Fault source u origen del defecto: se refiere al origen o procedencia de los defectos: debido a
defectos de fabricacin, requerimientos incorrectos, operacin del sistema en forma errnea, etc.
Granularity o granularidad: cantidad de componentes que son afectados por la falla, de ella
depender el mecanismo Self-Healing a aplicar.
Fault profile expectations o perfil probable de los defectos: perfil de los defectos que son
considerados como tolerables: esperados, inesperados, aleatorios o defectos que son probables
de ocurrir en base a un anlisis, entre otros.
2.3.2.2 - System Response o respuesta del sistema

En esta categora se debe detallar de qu manera el sistema se recupera ante la ocurrencia de
una falla. Las caractersticas que describen la respuesta del sistema ante la ocurrencia de un defecto
son:
Fault detection o deteccin de defectos: describe como el sistema detecta la presencia de un
defecto:
o Tipo de mecanismo: interno a los componentes, por comparacin de componentes
replicados, por chequeo entre pares o por chequeos por parte de un supervisor.
o Tcnicas utilizadas: no intrusivas (testeo de los resultados), ejecucin de tareas de
auditora, tareas redundantes, reinicios peridicos, si se utiliza un mecanismo de testeo
on-line mediante la inyeccin de fallas intencionalmente, etc.
Degradation o degradacin: determina el grado de degradacin en que se encuentra el sistema
luego de la aplicacin del mecanismo de Self-Healing.
Fault response o respuesta ante la presencia de un defecto: mecanismo de respuesta aplicado
al detectar un defecto en el sistema para mantener las propiedades deseadas del sistema en lo
que respecta a calidad del servicio, integridad transaccional, seguridad, etc:
o Tipo de mecanismo: preventivos, pro-activos (la accin es disparada cuando se detectan
defectos que son tolerados pero que pueden ser indicio de la aparicin futura de una
posible falla) o reactivos.
o Tcnicas utilizada: enmascaramiento del error, rollback (vuelta atrs) hasta el ltimo
estado guardado (checkpoint), rollforward (ir hacia adelante) con compensacin o
reintento de la operacin ya sea utilizando los recursos originales como recursos
alternativos. Otras ms complejas pueden ser: reconfiguracin de la arquitectura del
sistema, invocacin de versiones alternativas de tareas, eliminacin de tareas menos
importantes, y hasta requerir asistencia externa al sistema
Recovery o recuperacin: mecanismo de recuperacin utilizado para recobrar la operatividad
del sistema: puede involucrar la integracin de recursos recientemente incorporados,
29
transferencia del estado del sistema a determinados recursos o llevar el sistema hasta un estado
conocido.
Time constants o constantes de tiempo: se determinan los tiempos que tiene el sistema para
responder ante una falla. En caso de defectos intermitentes el proceso de deteccin-respuestarecuperacin debe ser ms rpido que el perodo de arribo de los defectos, para as evitar la
cada del sistema. La constante de tiempo de ocurrencia de los defectos puede determinar la
frecuencia en la cual se deben realizar los checkpoint.
Assurance o garanta: garantas que debe mantener el sistema durante y despus del proceso de
recuperacin ante la ocurrencia de una falla: garantizar el tiempo transcurrido entre el momento
en que ocurre el defecto y el momento en el cual se lo detecta, mantener ciertas garantas
necesarias durante el modo de operacin degradado y durante la operacin de recuperacin, etc.
2.3.2.3 - System Completeness o completitud del sistema

Es importante determinar cmo se ver afectado el mecanismo de Self-Healing por la falta de
conocimiento de los lmites reales del sistema y por especificaciones y diseos incompletos. Esta
categora tiene como objetivo detallar esos aspectos no conocidos del sistema los cuales pueden
describirse a partir de los siguientes rasgos del sistema:
Architectural completeness o completitud de la arquitectura: si la arquitectura del sistema
est completamente definida o si la misma evolucionar con el tiempo, si utiliza componentes
preconstruidos cuyos detalles y comportamientos no sean conocidos por parte del diseador, si
el sistema es abierto, en el sentido que pueden agregarse componentes de terceras partes durante
o despus de su desarrollo o si se encuentra construido sobre mecanismos de descubrimiento
que extienden su arquitectura o implementacin en tiempo de ejecucin.
Desginer knowledge o conocimiento del diseo: si se carece o no del conocimiento acerca de
algunos aspectos de los componentes utilizados y de su funcionamiento.
System self-knowledge o auto conocimiento del sistema: conocimientos internos del sistema y
de su entorno de ejecucin, necesarios para la aplicacin de mecanismos de Self-Healing. El
auto-conocimiento del sistema frecuentemente est limitado por el conocimiento interno de sus
componentes, por la accesibilidad al conocimiento de un componente por parte de otro o por
defectos en la representacin de dicho conocimiento, ya sea por defectos de diseo como por
deterioro causado por la evolucin del sistema.
System evolution o evolucin del sistema: describe como el mecanismo de Self-Healing har
frente a la evolucin de los sistemas: por cambios en los modos de operacin, por defectos
acumulados en los componentes, por adaptacin al ambiente externo, por evolucin de sus
componentes o por cambios en el uso del sistema.
2.3.2.4 - Desgin Context o contexto de diseo

En esta categora se describen varios factores que influyen en el alcance de las capacidades de
Self-Healing y que deben ser considerados para su diseo.
Abstract level o nivel de abstraccin: en qu nivel se aplicar el mecanismo de Self-Healing:
30
e.g. a una aplicacin de software, al sistema operativo, al hardware, etc.
Component homogeneity u homogeneidad de los componentes: que tan homogneo es el

sistema: completamente homogneos (mismos componentes duplicados o componentes
compatibles) o pueden tener algn grado de heterogeneidad, por ejemplo en una granja de
servidores puede ser que cada uno tenga distintas versiones de hardware o de sistema
operativo, o que tengan distintos software instalados. La heterogeneidad de un sistema limita su
habilidad para migrar tareas de administracin a estrategias Self-Healing.
Behavioral predetermination o predeterminacin del comportamiento: cmo es de

predecible y determinstico el comportamiento del sistema: hay cosas que son imposibles de
cuantificar (por ejemplo el tiempo de ejecucin en el peor de los casos), otras pueden parecer
determinables pero son impracticables debido al comportamiento no conocido de algunos
componentes o a causa de defectos, algunas tareas estn basadas en eventos o son intermitentes
o peridicas.
User involvement in healing o participacin del usuarios en la reparacin: si el mecanismo

de Self-Healing es completamente autonmico o el usuario debe participar del proceso de
reparacin y, de ser as, de qu forma lo har: para ayudarlo en su funcionamiento a pesar de la
falla ocurrida o para proveerle el asesoramiento que lo gue en su comportamiento SelfHealing.
System linearity o linealidad del sistema: se determina la existencia o no de acoplamiento

entre componentes. Si el sistema es completamente lineal, la aplicacin de Self-Healing de un
componente puede llevarse a cabo sin preocuparse por sus efectos sobre los otros componentes.
System scope o alcance del sistema: alcance del sistema al cual se desea aplicar el mecanismo
de Self-Healing: un nico componente, una parte del sistema, todo el sistema, etc.
2.4 - Monitoreo y Actuacin

Se entiende por monitoreo a un proceso que permite verificar sistemticamente el desempeo y
la disponibilidad de los elementos crticos de una infraestructura de IT as como tambin conocer
continuamente el estado de la misma. De esta forma es posible detectar problemas en su etapa
temprana y resolverlos antes que se vuelvan fatales, logrando as una continuidad en la operacin del
sistema.
Existen diversas herramientas de monitoreo que identifican y registran eventos tales como la
falta de disponibilidad de un equipo, sistema o recurso, violaciones a los umbrales de operacin
establecidos, as como tambin identifican degradaciones en el desempeo del sistema que puedan
provocar problemas o tiempos de respuesta no aceptables. Dichas herramientas deben poder observar
continuamente los ambientes productivos con el mnimo impacto posible sobre la infraestructura que
estn monitoreando, es decir que su uso de CPU, memoria y ancho de banda de la red deben estar
limitados al mnimo. Por otro lado, son desarrolladas con el objetivo de la mnima intervencin
humana y contienen opciones que permiten que los administradores puedan ser alertados cuando se
detectan condiciones que pueden terminar en situaciones no deseadas.
31
El nfasis de toda aplicacin de monitoreo es el de ser pro activa, por ejemplo ser capaz de
alertar al administrador de posibles problemas antes que los mismos se hagan evidente a los usuarios.
Hay dos consideraciones claves que determinan cuan pro activa es una aplicacin de monitoreo: el
grado y amplitud de mtricas que provee y la habilidad de configurar automticamente los umbrales de
las mtricas en base a experiencias adquiridas por la herramienta. Algunas contienen la inteligencia
suficiente para poder analizar el estado del sistema y el de sus componentes e identificar la posible
causa de un problema.
Existen distintos aspectos a monitorear en una infraestructura de IT, pudiendo cada una de las
aplicaciones de monitoreo estar orientadas a uno slo o a ms de uno de ellos, siendo estos los
siguientes:
Red: algunas permiten conocer la disponibilidad de la red as como tambin los niveles de
trfico de la misma en distintas ubicaciones. Mientras que otras ms completas ofrecen una vista
de la topologa de la red mostrando sus interconexiones, y algunas ms especializadas permiten
ver el flujo de trfico sobre la misma, permitiendo as conocer que protocolos estn ocupando el
mayor ancho de banda, entre otras cosas.
Sistema Operativo: algunas herramientas estn orientadas a monitorear el sistema operativo de

los servidores en la red: permiten conocer el uso de CPU, de memoria, la actividad y uso el
disco rgido. Algunas tambin permiten monitorear un proceso en particular que se encuentra
ejecutando en un determinado servidor.
Aplicaciones: algunas herramientas permiten la incorporacin de mdulos que posibilitan el
monitoreo de una aplicacin en particular que tendr el conocimiento especfico necesario para
poder obtener datos de la misma.
Servicios: muchas herramientas de monitoreo ofrecen la posibilidad de agrupar aplicaciones y
redes en servicios permitiendo al administrador observar el estado de todos los componentes y
capas que forman parte de los servicios brindados por un sistema. La esencia de las herramientas
de monitoreo de servicios no es la de obtener una vista integral de los componentes
involucrados en brindar el servicio, sino ms bien implica conocimiento de la interdependencia
entre los componentes del mismo, aplicaciones y redes, y hace uso de ese conocimiento para
detectar donde pueden ocurrir cuellos de botellas.
Muchas veces se utiliza monitoreo junto con un test de stress o test de carga en ambientes preproductivos, con la intensin de poder detectar cuellos de botellas en la infraestructura, antes que sea
puesto en produccin.
El proceso de monitoreo suele ir acompaado de acciones que se ejecutan cuando se detecta un
problema en el sistema monitoreado y que estn orientadas a sacar al mismo del estado errneo, es
decir de corregir el problema, y ponerlo nuevamente operativo. A estas acciones se le llama actuacin
y pueden ser realizadas manualmente, es decir con intervencin humana o automticamente.
El objetivo de los sistemas Self-Healing es el de proveer acciones automticas sobre el sistema
monitoreado ante la deteccin de un problema o situacin anmala en el mismo.
32
2.4.1 - Tcnicas de Monitoreo

Las herramientas de monitoreo tpicamente utilizan tres tcnicas diferentes, las cuales no slo
no son excluyentes sino que pueden obtenerse mejores resultados si se las combinan:
Instrumentacin del cdigo fuente: tcnica aplicada a herramientas de monitoreo de
aplicaciones, consiste en adosar cdigo al cdigo fuente de la aplicacin con el fin de recolectar
determinada informacin durante la ejecucin de la misma. Esta insercin de cdigo puede ser
realizada en tiempo de compilacin, en tiempo de ejecucin o en tiempo de desarrollo.
Monitoreo basado en eventos: se recolecta cierta informacin deseada cuando ocurre un
determinado suceso de inters.
Monitoreo basado en tiempo: tcnica tambin conocida como muestreo, consiste en tomar el
estado del sistema en determinados intervalos de tiempo, llamado perodo de muestreo. La
forma ms simple de este mtodo causa menor overhead (sobrecarga) que la instrumentacin de
cdigo. Mientras que en su forma ms compleja puede llegar a requerirse parar el sistema para
poder obtener la informacin deseada. El perodo de muestreo debe ajustarse segn las
caractersticas particulares del sistema monitoreado.
Las mediciones pueden ser tomadas internamente o externamente a la aplicacin, las internas
necesitan incorporar cdigo dentro de la aplicacin para detectar eventos.
La eleccin de la tcnica a usar es siempre un balance entre: el nivel de detalle deseado para el
dato recolectado, la cantidad de datos recolectados y la perturbacin causada en el
sistema monitoreado.
33
Captulo 3: Estado del Arte
34
Habiendo presentado los conceptos generales necesarios para comprender el desarrollo del
presente trabajo, se expondr ahora un relevamiento del estado del arte de tcnicas y mtodos de
relevancia en relacin a los objetivos planteados en la Seccin 1.4 -Objetivos.
Por ello, se har foco en:
Los principales enfoques de Self-Healing.
Una seleccin de trabajos previos relacionados con i) los enfoques de Self-Healing antes
mencionados y ii) las tecnologas del dominio de aplicacin elegido: la JVM, un Servidor de
Aplicaciones Java, y su correspondiente entorno de hardware.
Las tcnicas ms modernas disponibles para monitoreo y actuacin relacionadas al dominio de
aplicacin mencionado.
Se espera obtener una visin integral que permita tomar mejores decisiones de diseo para
nuestra propuesta de solucin en el Captulo 4: Solucin Propuesta e Implementacin
3.1 - Principales enfoques en sistemas Self-Healing

En lo que respecta al diseo y arquitectura de los sistemas Self-Healing el desafo es
encontrar una solucin genrica y reutilizable.
El mecanismo de Self-Healing de un sistema puede ser implementado interna como
externamente al mismo. Si es externo al sistema este ltimo no es consciente del proceso de monitoreo
que se est ejecutando como parte del mecanismo. Mientras que si es interno, el monitoreo est
completamente embebido en la aplicacin.
El enfoque externo es la forma ms reutilizable pero las posibilidades de monitoreo y
reparacin son limitadas. En algunos casos es la nica posibilidad a aplicar como por ejemplo en los
sistemas propietarios o en los sistemas donde no se tiene acceso a su cdigo fuente.
El enfoque interno permite un control y monitoreo ms fino y puede adquirir un conocimiento
ms ntimo del sistema, lo que permite mecanismo de deteccin, localizacin y reparacin ms
sofisticados, pero tiene la desventaja que su implementacin no es fcilmente reutilizable.
Una alternativa es la combinacin de ambos enfoques. Hay dos formas de llevar adelante dicha
combinacin: una es utilizando un proceso de monitoreo externo pero con componentes dentro del
sistema que cooperen con el mismo y que tengan una interfaz estndar, otra forma es que cada
componente del sistema incluya un proceso de monitoreo que provea una interfaz con la cual puedan
comunicarse entre ellos y de esta forma cooperar en el proceso de reparacin en caso de ser necesario.
Existen una gran variedad de propuestas de arquitectura y tcnicas para la construccin de
sistemas Self-Healing. Podemos mencionar una basada en componentes de Self-Healing [Vuori,
2007] en donde el mecanismo de autoreparacin y su proceso de monitoreo subyacente estn
insertados en los propios componentes del sistema.
Por otro lado se tiene la arquitectura propuesta en [Garlan & Schmerl, 2002] basada en
modelos de arquitectura en la cual se monitorea al sistema externamente como un todo. Este enfoque
fue extensamente investigado y, en base al mismo, se desarroll un framework para el monitoreo y
35
adaptacin dinmica de sistemas en tiempo de ejecucin.

Otra tcnica, aplicable a sistemas basados en componentes, es la que utiliza componentes
redundantes ([Diaconescu & Murphy, 2005] y [Diaconescu & Murphy, 2003]), donde se tiene
distintas versiones de aquellos componentes del sistema que se desea controlar, proveyendo idntica o
similares funcionalidades pero optimizadas para distintos escenarios.
Por ltimo se tiene el enfoque basado en aplicacin de teora de control clsica a los
Sistemas Informticos mediante la incorporacin de un control retroalimentado a los mismos
(fuertemente promovido desde IBM, originalmente de la mano de Joseph L. Hellerstein). Un control
retroalimentado, tambin conocido como control de lazo cerrado, es una operacin que en presencia de
perturbaciones externas al sistema tiende a reducir la diferencia entre el estado del sistema (variable de
salida) y el estado deseable del sistema (entrada de referencia). El trabajo de Hellerstein y sus colegas
se inspira en el hecho de que en otras reas de la ingeniera (e.g. mecnica, elctrica, aeronutica, etc.)
la teora de control es ampliamente utilizada en el diseo de sistemas confiables y robustos. El
resultado de este trabajo junto con casos de estudio prcticos fueron volcados en el libro [Hellerstein et
al., 2004].
En los prximos prrafos se resumen dos ejemplos paradigmticos ilustrando similitudes y
diferencias entre el enfoque basado en modelos de arquitectura -por ser el ms difundido- y el
enfoque que aplica teora de control -por ser una alternativa muy atractiva y considerablemente
menos difundida en el rea de la Ingeniera de Software-.
3.1.1 - Self-Healing basado en Modelos de Arquitecturas

Los sistemas Self-Healing que utilizan como modelo del sistema al modelo de arquitectura
son conocidos como arquitecture-based o basado en arquitectura. Se han realizados numerosas
investigaciones y trabajos acerca de ellos [Oriezy et al, 1999] y [Cheng, 2008].
David Garlan y colaboradores han dedicado considerables esfuerzos al tema incluyendo el
desarrollo de un framework para dar soporte a la implementacin de sistemas Self-Healing. Dicho
framework fue denominado Rainbow [Garlan et al, 2004]. En [Cheng et al., 2005] se presentan varios
ejemplos de su utilizacin aplicado a distintos tipos de sistemas.
La arquitectura propuesta por Garlan y Schmerl en [Garlan & Schmerl, 2002] se basa en el
paradigma de control de sistemas closed-loop o bucle cerrado el cual divide el problema en tres fases:
monitoreo, modelado y control del sistema y cuyo esquema es mostrado en la Figura 6. En dicho
esquema el comportamiento del sistema es monitoreado por componentes externos al mismo,
responsables de determinar si el sistema se encuentra dentro de los parmetros aceptables y en caso de
no estarlo, realizar las acciones necesarias para adaptarlo. Este mecanismo externo requiere de uno o
ms modelos del sistema que le provea una vista global y abstracta del mismo.
36
Figura 6 - Control de bucle cerrado
El enfoque propuesto por Garlan y Schermerl utiliza modelos de arquitectura del sistema en
tiempo de ejecucin, representados como grafos de componentes interactuantes, donde cada nodo
del grafo es llamado componente y representa cualquier elemento del sistema, y los arcos son
llamados conectores y representan los caminos de interaccin entre los componentes. El diagrama de
dicho enfoque se muestra en la Figura 7 (obtenida de [Garlan & Schmerl, 2002]), donde se observa el
esquema de funcionamiento: el sistema (1) es monitoreado para observar su comportamiento (2). Los
valores obtenidos del monitoreo son abstrados y relacionados con las propiedades del modelo de
arquitectura (3), si existen cambios en estas propiedades se procede a una evaluacin para determinar
si el sistema se encuentra operando dentro del rango de valores aceptables (4), de no ser as se pone en
marcha un mecanismo de reparacin (5) para determinar las acciones necesarias para adaptar la
arquitectura del sistema, las cuales, una vez determinadas, son propagadas al mismo (6).
Figura 7 - Esquema del enfoque basado en modelos de arquitectura [Garlan & Schmerl, 2002]
Rainbow persigue el objetivo de dar soporte a los desarrolladores para implementar

mecanismos de adaptacin externa en todo tipo de sistema de manera poco costosa. Para poder ser
aplicado a cualquier sistema provee una infraestructura reutilizable junto a mecanismos que permiten
especializarla de acuerdo a necesidades especficas del sistema. Estos mecanismos posibilitan elegir
cuales aspectos del sistema se quiere modelar y monitorear, cuales condiciones deben desencadenar el
37
mecanismo de adaptacin y cmo se la realizar. La infraestructura reutilizable (llamada

infraestructura de adaptacin), est dividida en tres capas como se muestra en la Figura 8.
Sus componentes son:
System Layer o capa del sistema: aqu se definen e implementan las interfaces de acceso al
sistema. Contiene un mecanismo para el monitoreo del sistema, denominado Probes, uno para el
descubrimiento de nuevos recursos, llamado Resource Discovery y otro, el Effectors, que lleva
a cabo las modificaciones necesarias en el sistema.
Architecture Layer o capa de arquitectura: el mdulo Gauges agrupa la informacin
proveniente de los Probes de la capa del sistema y actualiza las propiedades correspondientes
del modelo de arquitectura. El Model Manager maneja y provee acceso al modelo arquitectural
del sistema, el cual es chequeado peridicamente por el Constraint evaluator quien, en caso de
ocurrir una violacin a la restricciones impuestas al sistema, pone en funcionamiento el
mecanismo de adaptacin. Por ltimo el Adaptation engine determina el curso de accin y lleva
a cabo las acciones necesarias para adaptar al sistema con el fin de llevarlo al nuevo estado
deseado.
Translation Layer o capa de traduccin: esta capa ayuda a relacionar la informacin entre el
sistema y el modelo y viceversa.
Figura 8 - Esquema del framework Rainbow. [Garlan et al, 2004]
Los aspectos personalizables de Rainbow son mostrados como trapecios en el esquema de la

Figura 8, requieren de un conocimiento del sistema al cual se lo quiere aplicar, e incluyen: las
propiedades del mismo, las reglas o restricciones a evaluar, las acciones de adaptacin a aplicar (ante
una violacin a alguna de las restricciones establecidas) y la especificacin de como se llevan a cabo
estas acciones.
Por otro lado, utiliza el concepto de estilo arquitectnico (architectural style) para capturar
caractersticas comunes de los sistemas. Un estilo arquitectnico caracteriza a una familia de sistemas
38
que comparten ciertas propiedades semnticas y estructurales y est definido por: los componentes y
tipo de conectores, las restricciones sobre la composicin de dichos componentes, sus propiedades y
los anlisis que pueden realizarse sobre el sistema. Rainbow ampla este concepto incorporando
atributos dinmicos del sistema: las operaciones de adaptacin que pueden realizarse sobre los
elementos del sistema para alterar su configuracin y las estrategias de adaptacin que pueden
aplicarse para sacarlo de un estado indeseable. Estos atributos determinan el estilo de adaptacin.
3.1.2 - Self-Healing basado en Ingeniera de Control

Se entiende como controlador al mecanismo de regulacin continua de ciertas variables de un
sistema para conseguir que otras variables evolucionen acorde a un modo deseado. Un sistema de
control de lazo cerrado es aquel que opera calculando que valor colocar en las primeras en base a la
medicin del desvo (o error) en las ltimas.
El objetivo ms comn de la aplicacin de control a lazo cerrado es estabilizar el
funcionamiento del sistema en un estado deseado a pesar de las perturbaciones impredecibles que
pueda sufrir (usualmente provenientes de su entorno de operacin, pero tambin causadas por
degradaciones internas). Las variables que son monitoreadas y comparadas con valores deseados son
por ejemplo tiempo de respuesta, tasa de transferencia, utilizacin de un recurso, etc. Las variables que
son manipuladas (usualmente parmetros modificables del sistema) pueden ser el tamao de algn
buffer, niveles permitidos de concurrencia, etc.
Los elementos principales de un sistema de control de lazo cerrado se observan en la Figura 9.
Se trata de un control de tipo SISO Single-Input, Single-Output: una nica entrada de control y una
nica salida. Los ms utilizados son de tipo MIMO Multiple-Input, Multiple-Output, mltiples
entradas de control y mltiples salidas.
Figura 9 - Diagrama en bloques de un sistema de control de lazo cerrado tipo SISO
39
Los elementos de la figura 9 son:

Planta: sistema que se quiere controlar.
Entrada de control: ajuste de algn/os parmetro/s que afectan al comportamiento de la Planta
y que puede/n ser ajustado/s dinmicamente.
Salida controlada: condicin que se mide y controla, puede ser cualquier caracterstica medible
de la Planta (uso de CPU tiempo de respuesta, etc.).
Entrada de perturbacin: representa cualquier entrada que pueda afectar la forma en que la
Entrada de Control influye en la Salida del sistema (ejecucin de un sistema de backup, el
anlisis de un antivirus, etc).
Entrada de ruido: representa cualquier perturbacin que afecte la Salida del sistema.
Entrada de referencia: valor deseado de la Salida del sistema (o de una transformacin de la
misma).
Sensor: mide la Salida del sistema y la transforma de manera tal que pueda ser comparada con
la Entrada de referencia.
Error de control: diferencia entre el valor de la Salida medida y la Entrada de referencia.
Controlador: determina, utilizando el valor actual y los anteriores del Error de control, la
Entrada de control que se debe aplicar para que la salida evolucione hacia el valor de la
Entrada de referencia.
.Objetivos ms comunes de los sistemas de control:
Regulacin: controlar que la salida del sistema sea igual o cercana a la entrada de referencia,
e.g. mantener el porcentaje de utilizacin de un servidor web en 66%.
Optimizacin: obtener el mejor valor posible de la salida del sistema, e.g. optimizar algn
parmetro del sistema que permita minimizar su tiempo de respuesta.
Eliminacin de perturbaciones: asegurar que las perturbaciones que se encuentran actuando
sobre el sistema no afecten significativamente la salida del mismo.
Los sistemas de control pueden ser caracterizados a travs de las siguientes propiedades, que
permiten comparar dos sistemas de control distintos de manera tal de poder seleccionar el ms
adecuado:
Estabilidad: un sistema es estable si para cualquier entrada acotada la salida tambin lo es, los
sistemas inestables generan grandes oscilaciones con ciclos que alternan entre valores extremos
de las mtricas. En el caso de los Sistemas Informticos las salidas no pueden ser constantes
debido a su naturaleza estocstica y al hecho que suelen tener regiones de operacin (segn la
carga de trabajo, la configuracin, etc.) donde su rendimiento es aceptable y zonas donde no lo
son. Hellerstein y sus colegas definen a la estabilidad de estos sistemas dentro de una regin de
operacin.
Convergencia: un sistema de control es convergente si la salida controlada converge, o se
acerca lo suficiente, a la entrada de referencia o al valor ptimo, para el caso de los sistemas
40
cuyo objetivo es el de optimizacin.

Error de estado estacionario: es el valor del error de control en el estado estacionario del
sistema.
Sobrepico: se refiere al valor mximo por encima del valor del estado estacionario que toma la
salida del sistema.
Tiempo de establecimiento: tiempo que tarda el sistema hasta converger.
En la Figura 10, obtenida de [Diao et al., 2004], se muestra el grfico de la salida de un sistema
estable, representada por las lneas verticales, junto con el valor de la entrada de referencia. Del grfico
pueden obtenerse las caractersticas del sistema: error en estado estacionario (ess)=-1, tiempo de
establecimiento (ks)=9 y valor del sobre-pico (Ms)=32%, este valor se calcula a partir de
(1+Ms)yss=3,95 siendo este ltimo el valor mximo alcanzado mientras que yss es el valor al cual
converge la salida del sistema y cuyo valor es 3.
La teora de control provee tcnicas que permiten, analizar y desarrollar sistemas de control de
lazo cerrado en base de las caractersticas listadas anteriormente. En lo que respecta al anlisis de
sistemas de control, primero se estudia si el sistema es estable y en caso de serlo, se completa el
anlisis midiendo el error en tiempo estacionario, el sobre-pico y el tiempo de estabilizacin. En el
caso del diseo de nuevos sistemas de control, primeramente se definen los valores de error en tiempo
estacionario, el sobre-pico y el tiempo de estabilizacin deseados y luego se disea y construye el
sistema de manera tal que resulte estable y tenga dichas caractersticas. Esta tcnica es muy utilizada
en la ingeniera mecnica, en la elctrica, en la aeronutica, entre otras, para el diseo de mecanismos
de control de lazo cerrado.
El mecanismo de control de lazo cerrado permite que un sistema compuesto de elementos de
mal rendimiento funcione correctamente con slo agregarle un nuevo elemento llamado Controlador,
el cual ajusta dinmicamente el comportamiento de los componentes en base a la/s medicin/es
obtenida/s de su salida. Para ms detalle consultar [Abdelzaher et al, 2008].
Figura 10 - Respuesta de un sistema estable
El control de Sistemas de Software en tiempo real es una disciplina joven que aplica tcnicas
clsicas de control sobre Sistemas Informativos considerando a stos ltimos como los objetos de
control. El objetivo de control suele ser mantener las mtricas de performance (rendimiento) dentro de
41
rangos aceptables especificados por requerimientos de calidad de servicio. Las acciones de control son
eventos discretos que modifican la asignacin de los recursos disponibles a las entidades que compiten
por ellos. Si bien estos sistemas de control son tpicamente diseados con tcnicas adhoc (i.e. sin
seguir ninguna metodologa formal), la Teora de Control es cada vez ms utilizada por su robustez
terica y metodolgica [Arzen et al, 2006] que permite garantizar propiedades de performance y
estabilidad del sistema controlado ante condiciones impredecibles.
Problemas de los Sistemas Informticos que pueden ser abordados por la teora de control:
Traduccin de los requerimientos de SLOs (Service Level Objectives) deseados en los valores
necesarios para casa uno de los efectores mediante los cuales el sistema es controlado (e.g.
tamao de pool).
Optimizacin del uso de algn recurso (e.g. aplicacin la tcnica de balanceo de carga).
Cumplimiento de los SLAs (Service Level Agreement) establecidos, an en presencia de alta
carga de trabajo.
Para la aplicacin de la teora de control en los Sistemas Informticos existen algunos
obstculos que se deben afrontar, a diferencia de otras ingenieras en donde dicha teora se encuentra
madura [Hellerstein, 2003].
El primer paso es la seleccin de la/s entrada/s de control y de la/s salida/s del sistema. Como
entrada de control se suele utilizar alguno/s de los parmetros que exponen los sistemas para su
optimizacin de acuerdo a las necesidades del negocio. Los parmetros seleccionados deben poder ser
modificados dinmicamente y su efecto debe ser inmediato, es decir no deben necesitar del reinicio del
sistema para que el nuevo valor surta efecto. Por otro lado, deben afectar significativamente a las
mtricas elegidas como salidas del sistema. Con respecto a la seleccin de las salidas del sistema,
deben ser elegidas de manera tal que sean significativas y que a la vez puedan ser medidas.
Por otro lado, el diseo sistemtico de controladores requiere un modelo de la relacin entre la
entrada y la salida del sistema, al cual se lo llama modelo del sistema y es la base del diseo del
controlador. La construccin de este modelo es uno de los principales desafos para la aplicacin de
forma satisfactoria de la teora de control a los Sistemas Informticos. Debido a que en dichos sistemas
no suele estar claramente definida la relacin entre las entradas de control y la salida del sistema.
Segn explica Hellerstein en [Hellerstein, 2003], existen cuatro enfoques a seguir para su
construccin:
Utilizacin del mtodo numrico llamado ajuste a curvas: enfoque puramente emprico que
genera modelos estticos.
Modelar al sistema utilizando la metodologa de caja negra: se requiere elegir un punto de
operacin y, en base a la realizacin de varios experimentos, desarrollar un modelo emprico,
generalmente utilizando los modelos ARX (Auto Regressive with Exogenous input).
Utilizacin de procesos estocsticos, e.g. teora de colas: provee una manera de calcular los
efectos producidos por las entradas de control del estilo de tamao de buffers, cantidad, nmero
de servidores, etc, en las salidas controladas que son del tipo tiempos de respuesta, tasa de
transferencias, etc, asumiendo la distribucin de los tiempos de llegada de los pedidos y de la
velocidad con la cual los servicios pueden atenderlos.
42
Construccin del modelo del sistema en base al conocimiento de algunas de las caractersticas
especficas del mismo: slo puede ser aplicado cuando se tiene conocimiento de dichas
caractersticas.
Respecto a los sensores tambin existen algunos posibles problemas a enfrentar al aplicar teora
de control:
Intervalos de muestreos distintos o no sincronizados al tomar mtricas desde distintas fuentes,
hecho que frecuentemente resulta en la prdida de datos.
Mtrica a controlar no disponible o de difcil o costosa obtencin.
La operacin del sensor no debe interferir significativamente en el funcionamiento del sistema,
i.e. no debe producir una sobre carga o interferencia en el normal funcionamiento del sistema.
Demora en la obtencin de la informacin por parte del sensor, debido a que la tarea de
monitoreo suele ser de menor prioridad y puede ser relegada cuando existe otra de mayor
prioridad. Esto provoca que el controlador no reciba la informacin en el tiempo necesario para
actuar.
Uno de los principales problemas existente al aplicar teora de control a los
Sistemas Informticos radica en que el conjunto de los efectores disponibles tiene una relacin algo
compleja con la salida controlada y tienen un efecto indirecto en la misma.
Existen varios trabajos donde se ha aplicado teora de control a Sistemas Informticos
[Patikirikorala et al., 2012]. En la presente Tesis se selecciona como gua a [Hellerstein, 2003] y
[Hellerstein et al, 2004, 2005] y en particular la aplicacin especfica descripta en mayor detalle en
3.2.4 - Teora de control aplicada a un servidor Web.
3.2 - Trabajos previos relevantes

Esta seccin presenta una seleccin de trabajos acadmicos relevantes que fueron investigados
y analizados con el fin de obtener conocimiento de respaldo a la hora de proponer un diseo propio. Su
contenido no es prerrequisito para la comprensin de los captulos 4 en adelante.
La Seccin ofrece una sntesis de estos trabajos mirados desde la ptica de nuestros intereses
expuestos en 1.4 -Objetivos.
3.2.1 - JVMMon
En [Orlando & Russo, 2006] los autores presentan una infraestructura de monitoreo de la
JVM, llamada JVMMon y cuya arquitectura se muestra en la Figura 11, que mantiene la evolucin
del estado de la misma en conjunto con los errores y fallas producidas, a travs de un proceso de tres
pasos:
1. Mediante un agente de monitoreo, desarrollado utilizando JVMTI y ByteCode
Instrumentation (BCI), se interceptan los eventos generados dentro de la JVM y se recolecta
los datos acerca de su estado.
43
2. Luego existe un demonio que se ejecuta en una JVM separada de la monitoreada que recibe y
procesa los datos recolectados por el agente de monitoreo y enva al recolector de datos las
fallas producidas y los cambios relevantes en el estado de la JVM.
3. Por ltimo se tiene el recolector de datos que almacena la informacin recibida del demonio
en una base de datos, lo que permite realizar un anlisis on-line y off-line de la evolucin del
estado de la JVM monitoreada.
Adicionalmente se mantiene un archivo de log donde se registra cada evento generado desde la
JVM, que es utilizado para reconstruir su estado cuando la misma se cae.
Figura 11 - Arquitectura de JVMMon
El prototipo que desarrollaron fue evaluado por sus autores midiendo el costo introducido en el
tiempo de ejecucin y la cantidad de memoria utilizada durante su ejecucin (memory footprint). La
evaluacin fue llevada a cabo ejecutando, tanto con la JVM en modo cliente como en modo servidor,
las aplicaciones del benchmarks SPEC JVM98 [SPEC JVM98] y un Productor/Consumidor
desarrollado para tal fin. Los resultados de dicha evaluacin fueron los siguientes: en lo relacionado
con el uso de memoria no encontraron ningn impacto notable en el Heap de la JVM, mientras que en
lo referido al overhead (sobrecarga) introducido los resultados variaron dependiendo de la
caracterstica de cada aplicacin, obtenindose valores razonables para los programas que no
consumen mucha memoria mientras que para los que si lo hacen resultaron en valores altos, desde 3 a
8 veces mayor al tardado sin la infraestructura.
Por otro lado realizaron una comparacin de la sobrecarga introducida por JVMMon contra la
generada por HProf [HPROFSUN]: obtuvieron como resultado que HProf en general produce una
sobre carga mucho mayor que JVMMon y al igual que con este ltimo, el monitoreo del Heap es el
principal cuello de botella.
Por ltimo cabe mencionar que, segn los autores, JVMMon est siendo utilizada para la
44
evaluacin de la confiabilidad de la JVM.
3.2.2 - Aqua
En [Diaconescu & Murphy, 2005] y en [Diaconescu & Murphy, 2003] se presenta un
framework llamado AquA, de Automatic Quality Assurance, que permite a los sistemas basados en
componentes adaptarse de manera automtica a los cambios en su ambiente de ejecucin, con la
finalidad de optimizar su rendimiento. Dicho framework est basado en el uso de componentes
redundantes, se utilizan distintas versiones de cada uno de los componentes del sistema que se
quieren adaptar, proveyendo la misma o similar funcionalidad pero optimizadas para distintas
caractersticas del entorno de ejecucin. La diferencia entre las distintas versiones de un componente
puede ser ya sea a nivel de configuracin como a nivel de implementacin. El conjunto de los
componentes redundantes que proveen similar funcionalidad se lo llama grupo redundante.
La funcionalidad bsica del framework es: (1) monitorear el funcionamiento del sistema, en lo
que respecta a su rendimiento y disponibilidad y a las caractersticas de su entorno de ejecucin; (2)
analizar las mtricas recolectadas para detectar algn cambio considerable en el entorno o en el
rendimiento del sistema; (3) en caso de que as sea, adaptar el sistema a las nuevas caractersticas del
entorno, seleccionando el o los componente/s (uno de cada grupo) redundante que ms se adecue/n a
las nuevas condiciones optimizando el funcionamiento del sistema. En [Diaconescu & Murphy, 2003]
se describe un escenario simple de utilizacin del framework.
Figura 12 - Arquitectura de AQuA
En la Figura 12, obtenida de [Diaconescu & Murphy, 2003], se muestra la arquitectura de

AquA, la cual consta de tres capas lgicas:
Monitoring o Capa de monitoreo: encargada de obtener informacin en tiempo de ejecucin
acerca del rendimiento del sistema y de las caractersticas del entorno, y de analizar la
informacin recolectada e identificar algn componente con problemas.
45
Evaluation o Capa de evaluacin: responsable de determinar, en base a las polticas de

decisin establecidas, que variante de un componente redundante es la ms ptima para el
contexto en el cual se encuentra ejecutando el sistema.
Action o Capa de accin: incluye el sistema en s junto con los mecanismo encargados de
realizar el intercambio de los componentes redundantes.
Los autores de AQuA realizaron un prototipo funcional, llamado AQuA J2EE, y lo aplicaron a
la aplicacin empresarial Dukes Bank, proveda por Sun como parte del JEE Tutorial
[SUNJEETutorial], utilizando como servidor de aplicaciones al JBoss [Diaconescu & Murphy, 2005].
El monitoreo fue implementado mediante la instrumentacin del interceptor del contenedor JBoss,
para interceptar todas las llamadas a los mtodos de los EJB. El mecanismo de activacin de los
componentes se basa en la capacidad de hot deploy del JBoss, i.e. la capacidad que tiene de poder
instalar dinmicamente las aplicaciones y paquetes sin necesidad de reiniciar el servidor. Las
funcionalidades de deteccin de anomalas, de evaluacin y de decisin fueron implementadas
utilizando polticas de decisin escritas en el lenguaje ABLE [ABLE] y pueden ser modificadas,
agregadas y eliminadas sin necesidad de tratar con el mecanismo subyacente del framework.
Figura 13 - Integracin de AQuA J2EE con el JBoss
La Figura 13, obtenida de [Diaconescu & Murphy, 2005], muestra la integracin del framework
con el JBoss donde se ve que existe una instancia del framework por cada componente manejado, es
decir por grupo redundante, cada una de ellas realiza el mismo ciclo de funcionalidades: monitoreo y
deteccin (M), evaluacin y decisin (E) y activacin del componente (A).
Los componentes redundantes utilizados para la prueba de AQuA J2EE son los EJB que forman
parte de la aplicacin Dukes Bank, los cuales estn desarrollados de manera tal que mantienen su
estado mientras dure la sesin del usuario que accedi a los mismos. Las distintas versiones de los EJB
se difieren en el valor del parmetro de configuracin max-bean-age, que indica la cantidad de tiempo
que un EJB inactivo es mantenido en la memoria cache antes que el mismo sea desalojado.
46
AQuA J2EE se reconfigura dinmicamente segn la carga del sistema: para alta carga es ms
conveniente un valor alto para el parmetro max-bean-age, ya que en estos casos es frecuente que los
EJBs se encuentren inactivos por un tiempo largo pero aun as estn siendo utilizados, porque se
encuentran esperando por la respuesta de otro EJB o por la liberacin de algn recurso. Con poca carga
es ms conveniente un valor bajo del parmetro en cuestin, en caso contrario los EJB que ya no son
necesarios igualmente permanecern inactivos mucho tiempo en el cache, produciendo as un consumo
de memoria ineficiente.
Para ms detalle acerca de la implementacin y los resultados de las pruebas puede consultarse
[Diaconescu, 2006].
3.2.3 - Arco Iris

Arco Iris es un framework desarrollado como Tesis de la Facultad de Ciencias Exactas y
Naturales de la Universidad de Buenos Aires, [Chiocchio & Tursi, 2011] para extender a Rainbow (ver
3.1.1 - Self-Healing basado en Modelos de Arquitecturas).
El objetivo de Arco iris es hacer ms flexible y agregar capacidad expresiva a Rainbow, que
permita a los stakeholders del sistema (i.e. a todas las partes interesadas) involucrarse en el proceso de
definicin de requerimientos de atributos de calidad.
En la Figura 14 y la Figura 15 (obtenidas de [Chiocchio & Tursi, 2011]), se muestran la
arquitectura original de Rainbow y la de Arco Iris, respectivamente, en ambas se puede ver la
colaboracin entre los principales componentes arquitectnicos de ambos frameworks.
En la Figura 14 se observa que una persona con el rol de arquitecto del sistema configura el
framework mediante la creacin del modelo de arquitectura y la generacin de un conjunto de archivos
de configuracin: para la creacin del modelo de arquitectura se deben especificar los componentes y
conectores del sistema, sus propiedades y restricciones y tambin se pueden definir invariantes a nivel
de sistema o subsistema. Estas restricciones e invariantes son evaluadas peridicamente por Rainbow
para verificar si el sistema funciona dentro de los lmites definidos como normales.
47
Figura 14 - Arquitectura de Rainbow
Para entender las extensiones realizadas a Rainbow se comentarn los siguientes componentes
de la Figura 14:
Target System: sistema a adaptar.
Probes: componentes que obtienen informacin del sistema a adaptar necesaria para la auto
reparacin del mismo.
Gauges: componentes encargados de interpretar la informacin recolectada por los Probes y
traducirla a pares del tipo <Propiedad,Valor>, donde Propiedad se refiere al nombre de una
propiedad correspondiente a un componente o conector de la arquitectura del sistema a adaptar y
Valor es el nuevo valor que poseer dicha propiedad .
Gauge Coordinator: coordina la informacin provista por todos los Gauges y notifica al
Rainbow Model de los cambios en el sistema en ejecucin.
Rainbow Model: actualiza los valores de las propiedades de los componentes, conectores,
subsistemas o sistemas del modelo de arquitectura y detecta violaciones a las restricciones o
invariantes configuradas en dicho modelo.
Architecture Evaluator: consulta peridicamente al Rainbow Model por ocurrencia de
violaciones en el modelo de arquitectura y en caso de existir alguna dispara el mecanismo de
adaptacin invocando al Adaptation Manager.
Adaptation Manager: ejecuta la estrategia de reparacin ms adecuada para dejar al sistema en
48
el mejor estado posible.

Strategy: contiene la lgica necesaria para reparar el sistema.
Effectors: componentes que realizan acciones simples y concretas sobre el sistema a pedido de
las Strategy.
Tambin es necesario comprender que se entiende por Escenario de Atributo de Calidad, ya que
Arco Iris es definido por sus autores como: Arcor Iris = Rainbow + Escenarios de Atributos de
Calidad. Dichos escenarios (tambin conocidos por QAS, por sus siglas en ingls Quality Attribute
Scenarios) consisten en la especificacin de un requerimiento para un atributo de calidad en particular
y permite definir cmo deber responder el sistema ante determinados estmulos y en ciertos entornos
de ejecucin. Un Escenario o QAS consiste de seis partes:
Fuente del Estmulo: quin gener el estmulo, puede ser desde un humano hasta un sistema.
Estmulo: condicin que debe ser tenida en cuenta cuando llega al sistema.
Entorno: condiciones bajo las cuales ocurre el estmulo, e. g.: operacin normal, operacin con
alta carga, etc.
Artefacto: parte del sistema afectada por el estmulo.
Respuesta: que hace el sistema ante la llegada del estmulo.
Medicin de la Respuesta: como puede medirse la respuesta del sistema ante el estmulo.
3.2.3.1 - Extensiones Realizadas a Rainbow

En lo que respecta a la configuracin del framework, adems de configurar el modelo de
arquitectura y los archivos de configuracin del framework, con Arco Iris se debe tambin hacer lo
propio con los escenarios de los atributos de calidad.
En la Figura 15 se puede ver el diagrama de colaboracin entre los distintos componentes de la
arquitectura de Arco Iris y los cambios que fueron introducidos a Rainbow para obtenerlo.
49
Figura 15 - Arquitectura de Arco Iris
Los siguientes son los cambios principales introducidos en Arco Iris:

Probes y Gauges: poseen conocimiento del concepto de estmulo. Los Probes debern indicar el
estmulo al cual estn asociados y los Gauges debern poder interpretar dicha informacin y
notificar al Arco Iris Model de la actualizacin sobre el modelo utilizando el siguiente formato
<Propiedad,Valor, Estmulo>, donde Estmulo es el estmulo desencadenante de la actualizacin.
Gauge Coordinator: fue extendido por Arco Iris Gauge Coordinator conservando su
comportamiento original e incorporando el concepto de estmulo tal como lo hacen los nuevos
Gauges. Esto permite a Arco Iris coordinar informacin proveniente tanto de Gauges de
Rainbow como de Aro Iris.
Rainbow Model: fue extendido por Arco Iris Model permitiendo manipular informacin de
estmulos proveniente del Arco Iris Gauge Coordinator sin perder el soporte original provisto
por el Rainbow Model.
Adaptation Manager: fue extendido por el Arco Iris Adaptation Manager.
3.2.3.2 - Principio de Funcionamiento de Arco Iris

Cuando el Arco Iris Model es notificado que un estmulo fue invocado en el sistema, solicita al
Self-Healing Configuration Manager el subconjunto de escenarios habilitados que han dejado de
cumplirse y que poseen dicho estmulo, con esta informacin invoca al Arco Iris Adaptation Manager
indicando los escenarios detectados como rotos a los cuales deber intentar reparar.
50
Arco Iris incorpor la posibilidad de priorizar escenarios asignndole a cada uno prioridades
relativas, de esta forma al momento de elegir una estrategia de auto reparacin la seleccionada no
comprometa alguna otra funcionalidad del sistema considerada ms importante.
3.2.3.3 - Eleccin de Estrategias Rainbow vs Arco Iris

En Rainbow, las Estrategias tienen un conjunto de precondiciones que determinan si la misma
puede ser utilizada para reparar el sistema en un determinado momento. De esta forma, cuando
Rainbow detecta un problema en el sistema, recorre todas las estrategias existentes para ver si son
aplicables para las condiciones actuales, no teniendo manera de conocer a priori el conjunto de
estrategias candidatas en el momento en el que una o ms restricciones dejan de cumplirse.
Arco Iris utiliza el mismo tipo de estrategias que Rainbow, pero desacopla la deteccin del
problema de la solucin, mediante la utilizacin de los escenarios de atributos de calidad, donde se
definen las condiciones para la deteccin del problema y la referencia a posibles estrategias de
reparacin a ser consideradas cuando el escenario se ve comprometido. As las Estrategias ya no
necesitan conocer las circunstancias en las que su ejecucin tiene sentido.
3.2.4 - Teora de control aplicada a un servidor Web

En el trabajo [Gandhi et al, 2001] se describe la aplicacin de teora de control en el diseo de
un sistema de control a lazo cerrado tipo MIMO (Mltiple Input Mltiple Output) aplicado al servidor
Web Apache HTTP Server. El trabajo mencionado explica tambin los obstculos enfrentados y como
fueron superados en el proceso de diseo del controlador.
3.2.4.1 - Arquitectura de Apache HTTP Server: Propiedades relevantes del

sistema a controlar
En la Figura 16 (obtenida de [Hellerstein et al., 2004]) se puede ver como el Apache HTTP
Server se encuentra estructurado como un pool de workers (threads o procesos del sistema operativo).
Cuando llega un pedido de un cliente el mismo es encolado en la Accept Queue hasta que un worker se
encuentre disponible para atenderlo. Un worker se encuentra disponible cuando se encuentra en estado
idle, mientras que si est en estado busy significa que se encuentra procesando un pedido. El protocolo
HTTP 1.1 provee conexiones persistentes, es decir que los workers no cierran las conexiones una vez
finalizado el procesamiento, sino que se queda en estado wait y la conexin permanece abierta para
atender los subsiguientes pedidos del mismo cliente (mientras el worker se encuentre en este estado no
podr procesar pedidos de otros clientes).
51
Figura 16 - Arquitectura del Apache HTTP Server
Existen dos parmetros que afectan fuertemente la arquitectura descripta:

MaxClient: limita el tamao mximo del pool de workers.
KeepAlive: tiempo mximo durante el cual un worker puede permanecer en el estado wait antes
de cerrar la conexin con el cliente y as volver a estar disponible para atender pedidos.
Los valores de estos parmetros afectan al consumo de recursos y al rendimiento del Apache
HTTP Server: un valor alto de MaxClient permite que el Apache pueda procesar mayor cantidad de
pedidos concurrentes, pero por otro lado, si es demasiado grande generar un alto consumo de CPU y
de memoria. Para el caso de KeepAlive, si el mismo tiene un valor alto habr una subutilizacin de la
CPU por estar los workers demasiado tiempo en el estado wait, reduciendo su valor se reduce el
tiempo durante los cuales se encuentran en estado ocioso y ms tiempo procesando pedidos, pero se
genera un aumento en el consumo de CPU. A su vez, si el valor de dicho parmetro es demasiado
pequeo, las conexiones pueden terminar prematuramente incrementando an ms el consumo de CPU
ya que la conexin debe ser reconstruida para cada subsiguiente pedido del mismo cliente.
3.2.4.2 - Entradas de Control y Salidas Controladas

El objetivo del control aplicado es regular el consumo de CPU y de memoria por parte del
Apache. Tomando como referencia los valores de consumo deseados, el controlador ajusta los
parmetros KeepAlive y MaxClients (KA y MC respectivamente) de modo tendiente a mantener los
consumos de los recursos en cuestin en valores cercanos a los indicados como objetivo.
El controlador MIMO resultante tendr como entradas de control a los parmetros KA y
MC y como salidas controladas al consumo de CPU y consumo de memoria (CPU y MEM
respectivamente), tal como se muestra en la Figura 17 ([Hellerstein et al., 2004]).
52
Figura 17 - Control tipo MIMO para el Apache HTTP Server
En la seleccin de las entradas de control los autores encontraron un obstculo: ninguno de los
parmetros de configuracin del Apache pueden ser modificados dinmicamente. Esto requiri
modificar el cdigo fuente de Apache para permitir que KeepAlive y MaxClients sean manipulados sin
requerir reinicios, permitiendo su control en tiempo real.
3.2.4.3 - Obtencin del Modelo del Sistema a Controlar

Para la construccin de un modelo que relacione KA y MC con MEM y CPU (es decir, una
abstraccin matemtica del Apache HTTP Server en trminos de estas cuatros variables) los autores
utilizaron un enfoque emprico que consiste en 4 pasos: 1) determinar los experimentos apropiados a
realizar, 2) recolectar datos del Server, 3) construir el modelo a partir de los datos recolectados
utilizando tcnicas de identificacin de sistemas, y por ltimo 4) validar el modelo construido.
Para la realizacin de los experimentos utilizaron un servidor ejecutando un Apache accedido
por varios clientes simulados con un generador de carga sinttico siguiendo un comportamiento
estocstico determinado por el modelo WAGON de Liu [Liu et al, 1999].
El valor de MC fue variado desde 1 a 1024, mientras que a KA se lo hizo variar de 1 a 20
segundos ya que detectaron que valores mayores a 50 no tena efectos significativos en la utilizacin
del server, mientras que valores mayores a 20 tenan un efecto muy pequeo.
Por otro lado, los valores de las salidas de control fueron obtenidos mediante un promedio
temporal con un perodo de muestreo de 5 segundos.
La Figura 18, obtenida de [Gandhi et al, 2001], muestra las seales utilizadas para cada una de
las entradas de control junto a los resultados de los experimentos realizados.
Figura 18 - Entradas de control y resultados de los experimentos
53
Los autores eligieron construir, utilizando los datos recolectados mostrados en la Figura 18, un
modelo ARX lineal de primer orden de la forma dada por la ecuacin de la Figura 19. All, los
parmetros A y B son matrices de 2x2 que fueron estimadas utilizando el mtodo de regresin por
mnimos cuadrados.
+ = . + . : = [
] , = [ ],
Figura 19 - Ecuacin del modelo ARX para el Apache Server
3.2.4.4 - Evaluacin del Modelo del sistema

Se realizaron dos evaluaciones del modelo diseado. La primera fue realizada utilizando una
tcnica llamada prediccin de un paso y que consta de predecir el valor de una mtrica en tiempo k+1
basndose en valores medidos en tiempo k. Para la segunda evaluacin se utiliz una prediccin
multi-pasos, en la cual el valor en k+1 es calculado en base a las predicciones en el tiempo k.
En los grficos de la Figura 20 se muestra los resultados de las evaluaciones realizadas al
modelo. La Figuras (a) y (b) se corresponden con la evaluacin realizada utilizando la prediccin de un
paso para las salidas controladas, CPU y MEM respectivamente. En el eje x se encuentra el valor real
mientras que en el eje y el valor calculado. La lnea recta muestra lo que sera un modelo perfecto, es
decir donde el valor experimental es igual al calculado utilizando el modelo. En (c) se muestra el
resultado para la evaluacin que utiliz la tcnica multi-pasos, la lnea slida representa la respuesta
del sistema real frente a una serie de cambios en los valores de KA y MC, mientras que las lneas
punteadas representa la respuesta del modelo frente a los mismos cambios.
Figura 20 - Resultados de las evaluaciones: (a) y (b) utilizando prediccin de un paso para CPU y MEM
respectivamente. (c) utilizando prediccin multipaso
Los autores concluyeron que el modelo predice satisfactoriamente la respuesta del sistema,
especialmente de la salida controlada MEM donde se observa poca variabilidad, pero que sin embargo,
existen regiones en las cuales la precisin del modelo se degrada, especialmente cuando KA=6 y
MC=800. Se observa que el modelo es ms preciso cerca del centro de la regin de operacin, KA=11
y MC=600, y menos preciso en los bordes de dicha regin o fuera de ella.
54
3.2.4.5 - Diseo del Modelo del Controlador

Para el diseo del control se opt por una estructura de tipo PI (del ingls Proportional
Integral), el cual, debido a su robustez, es muy utilizado en ingeniera de control de procesos fsicos.
Un controlador PI opera acorde a la ecuacin en diferencias finitas dada por la Figura 21 donde
uk es un vector de 2x1 conteniendo las entradas de control, ek es el vector de error de control
(tambin 2x1) que se calcula como ek=rk-yk, siendo rk las entradas de referencia e yk las salidas
controladas.
+ = . + .
=
Figura 21 - Ecuacin en diferencias finitas que rige a un control PI
Un controlador PI clsico tiene dos parmetros Kp y KI llamados ganancia proporcional y

ganancia integral respectivamente. Sus valores son obtenidos de manera tal de cumplir con las
especificaciones del control deseadas. El trmino proporcional es usado para reaccionar
instantneamente a las desviaciones, mientras que el trmino integral es utilizado para eliminar el error
en estado estacionario.
En este caso ambos parmetros son matrices de 2x2 y sus valores fueron calculados utilizando
dos mtodos distintos, propios de la disciplina de ingeniera de control: la tcnica de ubicacin de
polos y el mtodo LQR del ingls Linear Quadratic Regulator (basada en encontrar parmetros que
minimicen la suma de los esfuerzos de control y las desviaciones de la seal de salida de su valor
deseado) obteniendo resultados ms satisfactorios con este ltimo mtodo.
Para mayor detalle acerca del diseo del controlador consultar [Gandhi et al, 2001] y [Diao et
al., 2002].
Con la determinacin de A, B, Kp y KI concluye el diseo del controlador mediante mtodos
analtico-matemticos que garantizan, en condiciones de idealidad, propiedades muy relevantes como
Estabilidad, Convergencia, Sobrepico, Tiempo de establecimiento (presentados antes en 3.1.2 - SelfHealing basado en Ingeniera de Control).
3.2.5 - Anlisis preliminar

Los trabajos analizados presentan ciertas limitaciones desde el punto de vista de los objetivos
perseguidos en esta Tesis.
JVMMon: Desarrolla una infraestructura que monitorea la JVM, uno de los objetivo de la
presente Tesis, pero no acta sobre la misma es decir que no es posible usarse para control.
AquA: Se trata de un framework general, aplicado al sistema JVM+JBoss (es decir el mismo
sistema que pretendemos controlar como caso de estudio en la presente Tesis). Est pensado
exclusivamente para Self-Healing basado en componentes redundantes (ver 3.1 - Principales
enfoques en sistemas Self-Healing), no siendo posible la utilizacin de otra tcnica o enfoque,
como s se quiere obtener en la presente Tesis. Por otro lado, su objetivo de control est limitado
55
a la optimizacin del rendimiento, mientras que nuestro objetivo de control es generalizado.

Arcos Iris: Si bien este framework permite agregar capacidades de Self-Healing a cualquier
Sistema de Software, tal como es el objetivo en esta Tesis, recae exclusivamente en el enfoque
basado en modelo de arquitectura (ver 3.1 - Principales enfoques en sistemas Self-Healing) y no
es posible la utilizacin de cualquier otro, como se pretende lograr en esta Tesis.
Aplicacin de Teora de Control al Apache HTTP Server: No se trata de una plataforma de
uso genrico ya que el controlador fue desarrollado para ser aplicado nicamente al Apache
HTTP Server. Sin embargo, este trabajo influir fuertemente nuestras decisiones de diseo ya
que buscaremos ofrecer la posibilidad de disear controladores en forma de ecuaciones en
diferencias finitas: la forma ms usual de implementar controladores digitales en la disciplina de
Ingeniera de Control. Tambin servir como inspiracin al momento de disear nuestro caso de
estudio prctico.
Los trabajos analizados no cubren la totalidad de nuestros objetivos planteados para una
plataforma de Self-Healing. Esto mantiene vigentes nuestras motivaciones originales (ver 1.2 Motivacin), es decir, desarrollar una nueva alternativa.
3.3 - Relevamiento de tecnologas de Monitoreo y

Actuacin para la JVM
Esta seccin presenta un relevamiento tcnico-descriptivo de los recursos disponibles
actualmente para monitorear y/o afectar la ejecucin de la JVM (incluyendo tecnologas, APIs,
herramientas, etc. acorde a la Java Platform Standard Edition (J2SE) 6.0).
Este conocimiento servir para comprender algunas decisiones tcnicas tomadas en el Captulo
4: Solucin Propuesta e Implementacin. Su contenido no es prerrequisito para la comprensin de los
captulos 4 en adelante.
3.3.1 - Tcnicas de Monitoreo de la JVM

Tcnicas de monitoreo que pueden ser aplicadas a la JVM:
Bytecode instrumentation (BCI) o monitoreo por instrumentacin: consiste en agregar o
reemplazar bytecodes en determinadas ubicaciones del cdigo original, de manera tal de poder
obtener informacin deseada o de lanzar eventos durante la ejecucin de la aplicacin Java.
Como las bytecode son independientes de la plataforma esta instrumentacin es ms portable
que la instrumentacin del cdigo fuente.
Event-based monitoring o monitoreo basado en eventos: la JVM se encuentra internamente
instrumentada para informar de la ocurrencia de determinados eventos, como por ejemplo el
comienzo o finalizacin de un thread.
56
3.3.2 - Java Platform Debugger Architecture (JPDA)

JPDA (del ingls Java Platform Debugger Arquitecture) es una infraestructura que da soporte a
la construccin de aplicaciones de debug, es decir aplicaciones depuradoras, para la plataforma J2SE y
est compuesta por las siguientes APIs:
Java Virtual Machine Tools Interface (JVMTI): interfaz nativa implementada por cada JVM
que provee mecanismos para controlar la ejecucin de las aplicaciones que se encuentran
corriendo dentro de una JVM as como tambin para inspeccionar su estado.
Java Debug Wire Protocol (JDWP): define el formato de la informacin intercambiada entre el
proceso que se est depurando y la interfaz del depurador. No define el mecanismo de transporte
entre ellos, slo da la especificacin del protocolo de comunicacin: as el proceso que se est
depurando y la interfaz del depurador pueden ejecutarse en implementaciones diferentes de la
VM y/o en separadas plataformas, permitiendo tambin que la interfaz del depurador pueda
estar escrita en otro lenguaje y no necesariamente en Java.
Java Debug Interface (JDI): API de alto nivel que permite obtener informacin acerca del
estado de la ejecucin de una JVM, ya sea local como remota, ocultado la complejidad de
JVMTI y de JDWP. Adems provee control explcito sobre la ejecucin de la misma,
permitiendo, entre otras cosas, crear, suspender y reanudar threads, notificar excepciones,
inspeccionar el estado de un thread suspendido y de sus variables locales. [JDIAPI]
Cada una de las APIs descriptas en el prrafo anterior conforman una capa de la arquitectura de
JPDA, la cual es mostrada en la Figura 22, donde:
Aplicacin Java: es el programa que se encuentra ejecutando en la JVM y que est siendo
depurado mediante el depurador.
VM: es la JVM donde se est ejecutando la aplicacin que est siendo depurada.
Parte posterior: es el componente del depurador responsable de comunicar los pedidos de la
parte delantera del depurador a la VM as como tambin de las respuestas de esta ltima. La
comunicacin entre la parte delantera y la posterior del depurador se realiza utilizando el
protocolo JDPW.
Parte delantera: es el componente del depurador que implementa JDI y es sobre el cual se
monta la interfaz de usuario.
Figura 22 - Arquitectura de JPDA
57
El depurador que se desarrolle utilizando esta arquitectura puede construirse sobre cualquiera
de las capas de JDPA indicadas eligiendo la que ms convenga segn el caso del que se trate, es decir
puede ser hecho sobre JDI que es la capa de mayor nivel de abstraccin como as tambin construirse
sobre JDWP o JVMTI, dependiendo de las necesidades especficas del mismo. Para mayor
informacin se puede consultar [JPDA].
3.3.2.1 - Java Virtual Machine Tool Interface (JVMTI)

JMTI (del ingls Java Virtual Machine Tool Interface) es la capa de menor nivel de
abstraccin de la infraestructura JPDA y es una interfaz nativa que permite inspeccionar el estado de la
JVM y controlar la ejecucin de las aplicaciones que estn corriendo en ella [JVMTI]. Fue introducida
en la versin 5 de la plataforma Java con el objetivo de remplazar a las APIs Java Virtual Machine
Profile Interface (JVMPI) y Java Virtual Machine Debug Interface (JVMDI), interfaces que fueron
introducidas en la versin 1.1 y que deprecadas en la versin 6.
Los clientes de esta interfaz, llamados Agentes, pueden ser notificados de sucesos que ocurren
en la JVM, es decir de eventos, como por ejemplo: acceso o modificacin de campos, carga de clases,
liberacin de un objeto, etc. Cada agente debe definir funciones callback para manejar cada uno de los
eventos de los cuales desea ser notificado. Por otro lado, JVMTI les provee una gran variedad de
funciones que les permiten consultar el estado de la JVM (memoria, threads, Heap, etc) y controlar la
aplicacin monitoreada. Adems proporciona soporte para BCI (Bytecode Instrumentation). En
[JVMTIEVENT] se encuentra la lista completa de los eventos posibles de ser notificados mientras que
en [JVMTIFUN] se encuentra la lista de las funciones disponibles.
El agente es iniciado por la JVM en su fase de inicializacin, es decir antes que se ejecute
cualquier bytecode o se cargue alguna clase, y se ejecuta en el mismo proceso que la JVM
monitoreada, minimizando as los costos de comunicacin con la misma. La comunicacin del agente
con la JVM se realiza a travs de llamadas directas a las funciones provedas por JVMTI, a travs de
los eventos lanzados por JVMTI o mediante BCI.
La especificacin JVMTI soporta ms de un agente ejecutndose simultneamente en cuyo
caso cada uno tendr su propio ambiente JVMTI, de esta forma cambios realizados en el ambiente de
un agente no tiene efectos en el estado del ambiente de los otros. El estado de la JVM y el ambiente
nativo son nicos para todos los agentes concurrentes, quedando en la responsabilidad del
programador de estos prevenir las interacciones destructivas entre ellos, ya que JVMTI no es capaz de
hacerlo.
El estado del ambiente de cada agente incluye las siguientes propiedades, establecidas por ellos
cuando se cargan:
Capabilities o capacidades: definen que funcionalidades estarn disponibles en el ambiente
JVMTI del agente. Inicialmente se encuentran todas deshabilitadas debido a que pueden incurrir
en un costo de procesamiento o uso de memoria.
Event notifications o notificaciones de eventos: define los eventos en los cuales el agente est
interesado en ser notificado.
Event callbacks o funciones callbacks para los eventos: define la funcin callback que
atender la ocurrencia de cada uno de los eventos indicados para ser notificado. Se llama
58
funcin callback a una funcin que es pasada como parmetro a otra funcin y que es ejecutada
cuando esta ltima es invocada.
memoria asignada.
Los agentes pueden ser escritos en cualquier lenguaje nativo que soporte la convencin de
llamadas de C y las definiciones de C o C++, suelen ser programas pequeos y estar controlados
mediante un proceso externo que implementa la mayor parte de la funcionalidad de la herramienta de
monitoreo, de esta forma no interfiere ni genera sobrecarga en la aplicacin monitoreada.
Al estar JVMTI basada en la habilitacin de las propiedades de las cuales un agente est
interesado en utilizar, el impacto en la performance o rendimiento de las aplicaciones por la
introduccin del agente puede ser reducido seleccionando solamente las capacidades que se necesiten,
a diferencia del API JVMPI que era ms que todo un enfoque de todo o nada.
Bytecode Instrumentation
JVMTI provee soporte para BCI a travs de las siguientes maneras:
Static Instrumentation o instrumentacin esttica: la clase es instrumentada antes de ser
cargada en la JVM, i.e. lo que se instrumenta es el archivo .class. Este mtodo es bastante
impracticable y en general un agente no puede conocer el origen del archivo que ser cargado.
Load-Time Instrumentation o instrumentacin en tiempo de carga: la instrumentacin se
realiza en el momento en que clase se carga en la JVM, cuando el archivo se carga se enva al
agente los bytecodes para que sean instrumentados. Este mecanismo de instrumentacin es ms
eficiente.
Dynamic Instrumentation o instrumentacin dinmica: la clase instrumentada es una clase ya
cargada en la VM, en este caso es posible modificarla varias veces y hasta volver a llevarla a su
estado original. Este mecanismo permite instrumentacin que vara durante la ejecucin de la
aplicacin.
La instrumentacin puede ser restringida a porciones de cdigos y puede tambin ser
condicional. Cabe destacar que a causa que la instrumentacin BCI consta de agregar bytecodes, la
JVM es capaz de optimizar el cdigo instrumentado y de esta forma minimizar el overhead (sobre
carga) introducido por el agente.
3.3.3 - Java Management Extensions (JMX)

La especificacin JMX [JMXESP, 2006a], parte de la plataforma Java desde la versin 5 de la
misma, es decir desde la J2SE5.0, define la arquitectura, los patrones de diseo, las APIs y los
servicios para el manejo y monitoreo de aplicaciones, dispositivos o servicios, ya sean estos locales o
remotos.
En la Figura 23 (obtenida de [JMXESP, 2006a]) se muestra la arquitectura JMX, compuesta por
los siguientes tres niveles:
Instrumentation level o nivel de instrumentacin: provee la especificacin para la
implementacin de recursos manejables a travs de JMX y la de un mecanismo de notificacin
de eventos entre componentes de los distintos niveles. Los recursos a manejar a travs de JMX
59
pueden ser aplicaciones, implementaciones de servicios, dispositivos, etc. Dentro de la

arquitectura de JMX, la abstraccin de un recurso manejable es llamada Managed Bean
(MBean).
Agent level o nivel de agente: provee la especificacin para la implementacin de agentes JMX
quienes son los que controlan los MBeans y hacen que estos estn disponibles para las
aplicaciones desde las cuales se quieren manejan los recursos asociados a los mismos. Un
agente JMX consta de un MBean Server, de un conjunto de servicios que permiten manejar los
MBeans y de al menos un conector o adaptador de comunicacin. Un MBean Server es el
ncleo del agente JMX y contiene un registro de los MBeans que se encuentran en el mismo y
que estn disponibles para ser accedidos. Los servicios son objetos, generalmente
implementados como MBeans, que pueden realizar operaciones de gestin sobre los MBeans
registrados. Los adaptadores y conectores proveen a las aplicaciones acceso al agente. Estos tres
componentes del nivel de agente son obligatorios en una implementacin de la especificacin
JMX.
Distributed services level o nivel de servicios distribuidos: define las interfaces y componentes
para la implementacin de gestores JMX. Estas interfaces y componentes permiten que las
aplicaciones de gestin accedan al Servidor JMX y manipule los MBeans que lo conforman.
Figura 23 - Arquitectura JMX
3.3.3.1 - Managed Bean (MBean)

Los MBeans son objetos Java que implementan una determinada interfaz y que se ajustan a
determinados patrones de diseo, encapsulan los aspectos a monitorear o controlar del recurso
asociado y definen que eventos del mismo se notificarn. La especificacin de JMX define varios tipos
de MBeans cada uno de los cuales cubre necesidades diferentes de instrumentacin:
Standard MBean: es la forma ms sencilla de instrumentar un recurso, provee una interfaz de
administracin esttica con los mtodos de acceso a los atributos y de las operaciones que
pueden invocarse. Los mtodos que expone el objeto son determinados en el momento de la
60
compilacin del mismo y no pueden ser modificados en tiempo de ejecucin. En [SUN, 2008b]
se puede encontrar un ejemplo de implementacin de este tipo de MBean.
Dynamic MBean: debe implementar una determinada interfaz y exponer su interfaz de
administracin en tiempo de ejecucin, se lo utiliza para instrumentar recursos en tiempo de
ejecucin. Los mtodos toman entre sus argumentos: el nombre del atributo cuyo valor se desea
obtener, para la lectura de un atributo o el nombre del atributo y el nuevo valor, para el caso de
escritura.
Open MBean: es un Dynamic MBean donde los tipos de datos utilizados para los atributos,
constructores y operaciones estn restringidos a un conjunto limitado [Kreger et al, 2002a]. Es
posible utilizarlos remotamente sin necesidad de importar clases especficas.
Model MBean: es un Dynamic MBean genrico y altamente configurable en tiempo de
ejecucin. Pueden ser usados para instrumentar dinmicamente casi cualquier recurso ya que
proveen una clase MBean genrica con un comportamiento por defecto. No hay que
implementarlo sino que configurarlo indicndole las caractersticas del recurso instrumentado a
travs del uso de metadatas. Se diferencia de los otros Dynamic MBean en que este tipo es
creado y mantenido por el MBean Server [Kreger et al, 2002b].
MXBean: es un tipo de MBean que referencia nicamente a un conjunto predefinido de tipos de
datos llamados Open Types, definidos en el paquete javax.management.openmbean, todo
atributo ser mapeado a los mismos siguiendo las reglas que se encuentran en la especificacin
de los MXBeans [MXBEANESP]: cualquier cliente podr ser capaz de utilizarlo sin necesidad
de que el mismo acceda a clases especficas del modelo. Sigue las mismas convenciones y se
define de manera similar a los Standard MBeans. Fueron introducido en la J2SE 5 pero en ella
se encontraban disponibles slo los MXBeans predefinidos que permiten monitorear la JVM
(3.4.3.2 - Platform MBeans), mientras que en la J2SE 6 se incorpor la posibilidad de poder
definir los propios. En [SUN, 2008b] se puede encontrar un ejemplo de implementacin.
3.3.3.2 - Platform MBeans

La JVM incluye un MBean Server llamado Platform MBean server, y varios MXBeans
llamados Platform MBeans que permiten monitorear y manejar la JVM, tanto en forma local como
remotamente. Cada uno de estos MXBean, mostrados en el Listado 1, encapsula un rea funcional
distinta de la JVM. Para ms informacin consultar [PLATMBEANS].
61
Listado 1 - Platform MBeans
MXBean
Componente de la JVM que maneja
ClassLoadingMXBean
Class Loader
CompilationMXBean
Compiler
GarbageCollectorMXBean Garbage Collector

MemoryManagerMXBean
MemoryPoolMXBean
Memoria
y MemoryMXBean
OperatingSystemMXBean Sistema Operativo donde se encuentra ejecutando la JVM
RuntimeMXBean
ThreadMXBean
Runtime System (Sistema de Ejecucin de Java o Plataforma Java)

Threads
3.3.4 - Simple Network Management Protocol (SNMP)

El SNMP es un protocolo de la capa de aplicacin que facilita el intercambio de informacin de
administracin entre dispositivos de una red, existen tres versiones del mismo siendo las ms utilizadas
la versin 1 (SNMPv1) y la versin 2 (SNMPv2). La ltima versin (SNMPv3) posee cambios
significativos con relacin a sus predecesores, sobre todo en aspectos de seguridad, sin embargo no ha
sido mayoritariamente aceptada en la industria. Los componentes bsicos de una red administrada a
travs de este protocolo, cuya especificacin es la RFC 3418, son:
Dispositivos o Sistemas Administrados: nodos de una red que contiene un agente SNMP
mediante el cual es administrado.
Agente: mdulo de software que reside en los dispositivos administrados y cuya funcin es
recolectar informacin del mismo y exponerla, en el formato establecido por el protocolo
SNMTP, a los sistemas de administracin. La informacin acerca de cada sistema administrado
que los agentes deben exponer se define a travs de Management Information Bases (MIBs),
un tipo de base de datos que contiene informacin jerrquica, estructurada en forma de rbol y
cuyos objetos se definen utilizando un lenguaje formal llamado Structure of Management
Information (SMI), especificado en el RFC2578 y del cual existen dos versiones SMIv1 y
SMIv2.
Sistemas Administradores de Red: aplicaciones de software que supervisan y controlan a los
dispositivos administrados.
Java SE trae incorporado un agente SNMPv2 que posibilita el acceso, a travs de SNMP, a la
62
informacin especificada por la JSR 163 (JavaTM Platform Profiling Architecture) siendo el MIB
que la describe el JVM-MANAGEMENT-MIB [JVMMIB]. Este agente, construido sobre las APIs de
monitoreo y administracin de la plataforma Java ([SUNMONandMAN]), no es extensible, slo puede
exponer los datos que estn definidos en el MIB indicado, si se desea exhibir informacin propia se
debe escribir un nuevo MIB, si es que no existe algn estndar que ya lo haga y agregar a la JVM un
nuevo agente que lo exponga, lo cual requiere un cierto conocimiento de SNMP. Por otro lado, el
poder de expresin de SNMP es limitado siendo la descripcin de datos complejos bastante engorrosa.
Para administrar la JVM a travs de SNMP es necesario contar ya sea con una consola de
administracin o con un API que entienda dicho protocolo, para tal fin Sun provee el API Java
Dynamic Management Kit, existen otras herramientas y APIs, tanto open source como comerciales
[SNMPLINKS]. En [SNMPJVM] se puede encontrar ms informacin acerca del monitoreo de la
JVM a travs de SNMP.
3.3.5 - Herramientas de Monitoreo de la JVM

Existen varias herramientas que permiten monitorear la JVM, algunas estn orientadas a
obtener determinada informacin de la misma para el diagnstico de ciertos problemas:
Jhat: muestra informacin acerca de los objetos que se encuentra en el Heap, tamao que
ocupan, objetos que referencian, etc.
Jstack: imprime el stack trace de los threads de un determinado proceso y permite detectar
deadlocks.
Jinfo: muestra informacin de configuracin de un proceso Java.
Jmap: permite tomar una fotografa detallada de lo que est ocurriendo en la memoria de un
determinado proceso o de un servidor remoto en un determinado momento.
Jstat: muestra estadsticas de consumo de recursos de la JVM. Recolecta informacin acerca del
uso de memoria y de estadsticas del garbage collection y de classloading de la JVM.
Otras permiten una visualizacin ms amplia de la JVM:
JConsole: herramienta compatible con JMX que permite obtener informacin acerca del
consumo de recursos de las aplicaciones que estn corriendo en una JVM, tanto remota como
local, y del estado de esta ltima. Muestra informacin de: los MBeans que se encuentran
registrados en el agente JMX al cual se conecta, uso de memoria, uso y estado de los threads,
estadsticas del garbage collection y de classloading de la JVM. En Java 6 se incorpor: la
posibilidad de extender la interfaz grfica ya sea mediante el agregado de pestaas a la misma o
personalizando las existentes para los MBeans de las aplicaciones y la posibilidad de adosarle
las aplicaciones a monitorear dinmicamente sin necesidad de arrancar la JVM con ninguna
opcin que se lo indique ([SUN, 2008a]).
VisualVM: herramienta incorporada en la actualizacin 7 de Java SE 6.0 que unifica varias
herramientas existentes, incluyendo JConsole, jstat, jinfo, jstack, y jmap, para la obtencin de
diferentes tipos de datos de la JVM, reorganizando y presentando la informacin grficamente
de manera tal de poder ver diferentes datos de las aplicaciones que se encuentran ejecutando
dentro de la JVM, ya sea local como remotamente. Es posible extenderla agregndole nueva
63
funcionalidad mediante plugins, soporta la incorporacin de cualquier plugin desarrollado para

Jconsole ([SUNVISUALVM]).
3.3.6 - APIs de Administracin y Monitoreo

La plataforma Java SE 6.0 provee las siguientes APIs para administrar y monitorear la JVM
([SUNMONandMAN]):
java.lang.management: monitoreo y administracin de la JVM y del sistema operativo en el
cual se est ejecutando la misma. Permite que las aplicaciones puedan monitorearse a s mismas
y que las herramientas basadas en JMX monitoreen y manejen JVM remotas o locales.
Contiene las interfaces para los Platforms MXBeans.
com.sun.management: es una extensin de Sun del API java.lang.management que adems
define la interfaz de administracin de otros componentes de la plataforma.
java.lang.instrument: permite instrumentar aplicaciones Java, es una alternativa a JVMTI si lo
nico que se requiere es la funcionalidad de instrumentacin.
Java Management Extensions (JMX) APIs: implementa la especificacin JMX.
Attach API: extensin de la plataforma Sun Microsystem que permite que un agente de
monitoreo o administracin sea adosado y cargado dinmicamente en la JVM sin necesidad de
tener que reiniciar la misma.
JConsole API: extensin de la plataforma Sun Microsystem que provee una interfaz para
acceder programticamente a la JConsole y el agregado de plugins a la misma.
64
Captulo 4: Solucin Propuesta e

Implementacin
65
La solucin propuesta a los objetivos planteados en la introduccin del presente documento se

muestra en el esquema de la Figura 24, donde pueden verse sus principales componentes. A la
izquierda se presenta el Nodo Controlado, en el cual se ejecuta aquellas aplicaciones que debern ser
supervisadas y controladas. A la derecha se presenta el Nodo de Control, el cual concentra las
tecnologas necesarias para ejecutar los algoritmos de control que supervisen uno o ms nodos
externos.
En el Nodo Controlado se encuentra el sistema monitoreado, en nuestro caso es el Servidor
de Aplicaciones JBoss y su JVM. En el mismo nodo se encuentra un Monitor del Entorno Local,
que recolecta mtricas del ambiente local en el cual se est ejecutando el JBoss.
En el Nodo de Control se encuentra el Monitor Global que recolecta las mtricas enviadas
por los monitores de entornos locales, y las mtricas del JBoss y de la JVM obtenidas va la tecnologa
JMX.
Todas las mtricas recolectadas son enviadas al Sensor quien se encarga de adaptar el formato
de las mediciones y transmitirlas al Control en Tiempo Real. Este ltimo es el encargado de calcular
si existen desvos en los objetivos de calidad deseables, es decir de evaluar si existen diferencias
apreciables entre los valores deseados y los valores actuales para cada una de las mtricas obtenidas.
Estas situaciones anmalas, que podran conducir a la ocurrencia de una falla, pueden ser prevenidas
mediante acciones correctivas. Si el Control en Tiempo Real determina que se debe aplicar una accin
correctiva, calcula su valor y se la comunica al Actuador quien ser el encargado de aplicarla en el
sistema va JMX. En nuestro caso toda accin correctiva ser ya sea la ejecucin de una operacin o el
cambio del valor de algn atributo del MBean que encapsula el recurso del sistema que se necesita
controlar.
Figura 24 - Esquema de la solucin propuesta
Todo este mecanismo sucede sin que la/s aplicacin/es Java que se estn ejecutando en el
servidor tengan conocimiento que la JVM, el servidor JBoss y su entorno estn siendo monitoreados.
Con este esquema, pueden configurarse en el Monitor Global que mtricas del entorno, del
servidor de aplicaciones y de la JVM se desea recolectar, segn el tipo de fallas deseen prevenirse.
El uso de un control externo posibilita su intercambio fcilmente as como tambin la
incorporacin de nuevos aspectos a controlar, lo que da lugar a la posibilidad de aplicar distintas
estrategias de control sin necesidad de modificar el resto de los componentes de la infraestructura,
66
permitiendo an la utilizacin de ms de una en paralelo.

Por otro lado, el sacar las mtricas del producto del sensado hacia afuera del sistema
controlado, la JVM y del Servidor de Aplicaciones, permite correlacionarlas con la informacin de su
entorno de ejecucin, pudiendo construir mtricas ms complejas segn sea necesario.
En lo que respecta al sistema de control de tiempo real, se pretende que el mismo incorpore en
forma natural el enfoque propuesto por [Hellerstein et al., 2004] el cual consiste en aplicar teora de
control a los Sistemas Informticos, pero no obstante la infraestructura desarrollada deber permitir
cambiar de enfoque sin demasiado costo.
4.1 - Servidor de aplicaciones - JBoss

JBoss AS es el servidor de aplicaciones Java open source o de cdigo abierto ms utilizado en
el mercado y el primero de este estilo capaz de competir con los servidores propietarios. Naci en 1999
como un pequeo proyecto open source llamado EJBoss (Enterprise Java Beans Open Source
Software) que provea una implementacin para la especificacin Enterprise Java Bean (EJB), parte de
la especificacin J2EE. En 2001 se form la compaa JBoss Group, LLC, en 2004 se transform en la
corporacin JBoss Inc y en 2006 fue adquirida por RedHat Inc.
En 2002 estuvo disponible la primera versin como servidor de aplicaciones, la JBoss AS 3,
compitiendo con los servidores propietarios WebSphere y WebLogic.
Durante la etapa final del desarrollo del presente trabajo salieron a la luz la ltima versin de la
6 (la 6.1) y las versiones finales 7.0.0, 7.0.1 y la 7.0.2. Se produjo un cambio radical entre la versin 6
y la 7, las principales modificaciones fueron: la arquitectura, la organizacin interna de directorios y se
dejaron de exponer algunos MBeans.
Para la realizacin de los casos de prueba del presente trabajo se utiliz la versin 5.1.
Si bien la infraestructura desarrollada puede aplicarse tanto al JBoss 5.x, 6.x y 7.x, como a
cualquier aplicacin Java que pueda ser manejada mediante JMX, no pudieron migrarse los casos de
prueba a la versin 7.x debido a que los MBeans utilizados en ellos no estn disponibles en esta ltima
versin.
4.1.1 - Arquitectura del JBoss AS

En esta seccin se describir la arquitectura del JBoss AS en sus versiones 5.x y 6.x, las cuales
comparten la arquitectura, siendo la principal diferencia entre ellos que el JBoss AS 5.x es un servidor
de aplicaciones conforme con el estndar Java EE 5, mientras que JBoss 6.x es una implementacin no
oficial de Java EE 6. En los prrafos siguientes se referenciar indistintamente a ambas versiones como
JBoss AS.
El JBoss AS no es una aplicacin monoltica que implementa toda la funcionalidad dada por el
estndar Java EE, sino ms bien todo lo contrario, ya que el mismo se encuentra compuesto por una
coleccin de componentes independientes e interdependientes entre s, cada uno de los cuales
implementa una porcin especfica de dicho estndar.
67
La arquitectura del JBoss est compuesta por el microcontainer y por un conjunto de servicios
con funcionalidades especficas, siendo el primero el componente principal de la misma y es quien
integra a los servicios que forman parte del JBoss AS.
El microcontainer no es ms que un framework de inyeccin de dependencias, es decir que
inyecta los objetos necesarios segn las relaciones plasmadas en los archivos de configuracin. Los
servicios estn desarrollados usando POJOs2 (Plain Old Java Objects), es decir mediante clases Java
simples y que no dependen de ningn framework en particular [Jamae & Johnson, 2009a]. Esta
arquitectura posibilita el escalamiento del servidor mediante la adhesin de nuevos servicios as como
tambin permite desactivar los servicios que no se desean utilizar, obtenindose as un servidor de
aplicaciones personalizado conteniendo nicamente los servicios necesarios segn las necesidades del
negocio.
4.1.2 - JBoss web server

JBoss AS ejecuta las aplicaciones web utilizando un nuevo producto de RedHat llamado JBoss
Web Server, el cual fue construido sobre el Apache Tomcat 6.0.
El Apache Tomcat, tambin llamado Jakarta Tomcat o simplemente Tomcat, es el contenedor
web que implementa las especificaciones de servlet y JavaServerPages (jsp) de Sun Microsystems,
ms conocido y utilizado en el mercado [APACHETOMCAT]. Tomcat tambin funciona como un
servidor web de propsito general, capaz de realizar las mismas tareas que los servidores web nativos
ms populares, como por ejemplo el Microsoft IIS y el Apache HTTP Server. Al estar desarrollado en
Java tiene la ventaja de ser portable a cualquier plataforma pero a la vez lo hace ms lento, al servir el
contendido esttico, que los servidores web nativos.
En lo que respecta a servidores web nativos Apache tambin es lder en el mercado con su
Apache HTTP Server [APACHEHTTP], un servidor web desarrollado en C rpido y altamente
escalable.
RedHat combin las ventajas de ambos productos utilizando en el JBoss Web Server la
biblioteca nativa de Apache usada por el Apache HTTP Server, llamada Apache Portable Runtime
(APR) [APACHEARP]. Obteniendo as la velocidad de este ltimo junto con la versatilidad del
Tomcat. En la Figura 25 se muestra la arquitectura del JBoss Web Server (para ms informacin
consultar [JBOSSWEB]).
Figura 25 - Arquitectura del JBoss Web Server (obtenida de [JBOSSWEB].)

2
El trmino POJO fue creado por Martin Fowler, Rebecca Parsons y Josh Mackenzie en el 2000 con el objetivo de
revalorizar la programacin simplemente orientada a objetos en contraposicin al uso de frameworks cada vez ms
complejos.
68
4.2 - Monitor
Para la eleccin de la aplicacin de monitoreo a utilizar como monitor de la infraestructura, se
tuvieron en cuentas los siguientes requerimientos:
Debe ser open source o estar bajo alguna licencia libre tipo GNU GPL [GGPL].
Debe permitir el monitoreo del servidor de aplicaciones, de la JVM y del ambiente en donde
ellos se estn ejecutando.
Debe permitir la correlacin temporal de las mtricas recolectadas.
Debe persistir las mtricas obtenidas en una base de datos y adems es deseable que las
mismas puedan ser enviadas al sistema de control directamente, es decir sin tener que acceder
a la base de datos ni al disco rgido.
De las aplicaciones investigadas, openNMS [OPENNMS], Nagios [NAGIOS], Zabbix
[ZABBIX] y Zennos [ZENNOS], se eligi utilizar Nagios, debido a que su arquitectura, permite
extenderlo y/o realizarle las modificaciones necesarias para cumplir con los requerimientos
mencionados, sin necesidad de tocar los componentes core del mismo, es decir los componentes que
contienen la funcionalidad bsica del monitoreo. Por otro lado existen una gran variedad de plugins
que extienden sus funcionalidades como por ejemplo el almacenaje de las mtricas en distintas base de
datos (MySQL, rrdb, etc), generacin de grficos, interfaz grfica para hacer su configuracin ms
amigable, etc. Cabe destacar tambin que cuenta con muy buena documentacin, tanto oficial como de
la comunidad lo que permite una rpida curva de aprendizaje del producto.
Por otro lado es importante recalcar que Nagios es una aplicacin madura altamente utilizada
en el mercado por parte de importantes empresas, como puede verse en [NAGIOSUSERS] y de la cual
se han escrito numerosos libros, algunos de los cuales son listados en [NAGIOSBOOKS].
4.2.1 - Nagios
Nagios es una herramienta de monitoreo open source o de cdigo abierto altamente utilizada en
el mercado. Naci en 1999 bajo el nombre de NetSaint que debi ser cambiado en el 2002 a causa de
coincidir con una marca comercial existente, tomando entonces el nombre de Nagios. Actualmente
adems de la versin open source denominada Nagios Core, existe una versin comercial basada en
esta ltima, llamada Nagios XXI. En los prximos prrafos se va a profundizar en la arquitectura de la
versin Nagios Core que fue la utilizada en el presente trabajo.
4.2.1.1 - Arquitectura
Nagios est construido sobre una arquitectura de agentes/servidor, es decir que est conformado
por varios agentes que recolectan informacin de los hosts remotos que se quieren monitorear y se la
envan a un proceso que funciona como servidor y que centraliza la recepcin y procesamiento de los
datos recolectados. En la Figura 26 se encuentra el esquema de la arquitectura de Nagios, donde puede
observarse los distintos componentes del mismo:
69
Figura 26 - Arquitectura de Nagios
El scheduler: proceso servidor de Nagios, encargado de ejecutar, cada un determinado tiempo,

los plugins configurados, recolectar los resultados y guardar el estado de los recursos
monitoreados en el archivo de estado y las respuestas recibidas en el archivo de log.
Los plugins: se llama as a los agentes, son pequeos programas ejecutables o scripts que
pueden estar desarrollado en cualquier lenguaje de programacin, cuya funcin es chequear el
estado de un servicio, que puede ser desde un proceso hasta un elemento de hardware como por
ejemplo el espacio en disco, y enviar el resultado al proceso servidor. Estos plugins pueden
correr localmente, es decir en la misma mquina donde se encuentra el servidor o en forma
remota. Estos plugins no forman parte de Nagios sino que suelen ser desarrollados por terceras
partes con el fin de adicionarle funcionalidades al mismo.
Los archivos de configuracin: son archivos de texto plano que siguen un determinado formato
y donde se configuran, entre otras cosas, los recursos monitoreados y los plugins utilizados.
El archivo de estado: archivo donde el scheduler guarda el estado de los recursos monitoreados.
El archivo de log: archivo donde el scheduler guarda los datos recolectados por los plugins.
La GUI: interfaz grfica web generada mediante CGI que permite consultar la configuracin, el
estado de los recursos monitoreados, obtener estadsticas y reportes varios, consultar el archivo
de log, etc.
Los recursos monitoreados: Estos pueden ser hosts o servicios. En Nagios un host es cualquier
cosa que se le pueda asociar un nombre y una direccin, mientras que un servicio es cualquier
cosa asociada a un host que se pueda monitorear, pudiendo ser ya sea un servicio ejecutndose
en el mismo (POP, SMTP, HTTP, etc) como algn otro tipo de mtrica asociada a l como e.g. el
espacio en disco, cantidad de usuarios, tiempo de respuesta, etc [NAGIOSOBJECTS].
70
4.2.1.2 - Plugins
Nagios, a diferencia de otras aplicaciones de monitoreo, no incluye ningn mecanismo interno
para chequeo de estado de hosts y servicios ni de recoleccin de mtricas, sino que se basa en
programas externos, llamados plugins que realizan dicha tarea. Estos programas pueden ser ejecutables
o scripts. Cuando Nagios lo cree conveniente ejecuta estos plugins, quienes realizan la accin
correspondiente y devuelven el resultado a Nagios para que lo procese y, en caso que corresponda,
tome alguna accin necesaria. De esta forma los plugins actan como una capa de abstraccin entre la
lgica de monitoreo que se encuentra en Nagios y los recursos que son monitoreados
[NAGIOSCOREPLUGINS].
Todo script y programa ejecutable que se quiere que funcione como plugin de Nagios debe
cumplir como mnimo con los siguientes requisitos:
Devolver un cdigo que indique el estado del host o servicio que monitorea, Nagios determina
su estado segn este cdigo devuelto siguiendo el Listado 2 (para ms detalle consultar
[NAGIOSPLUGINAPI] o [NAGIOSPLUGINDEV]):
Listado 2 - Cdigo de retorno de los plugins de Nagios
Cdigo
de
retorno
Estado para
los servicios
Estado para los hosts
Descripcin
OK
UP
Fue posible chequear el servicio o host y

parece estar funcionando.
Fue posible chequear el servicio o host pero

no parecen estar funcionando correctamente o
se encuentra sobre el umbral de alerta.
UP o DOWN/UNREACHABLE El estado que Nagios determina para el caso
de los hosts depende de la configuracin y
puede consultarse [NAGIOSPLUGINAPI]
para mayor detalle.
WARNING
CRITICAL
DOWN/UNREACHABLE
El plugin detecta que el servicio o host no est

funcionando o est sobre el umbral crtico.
UNKNOWN
DOWN/UNREACHABLE
No se pudo realizar el chequeo del servicio o

host.
Devolver a STDOUT al menos una lnea de texto que describa el estado devuelto a travs del
cdigo de retorno.
Adems del cdigo de retorno y de la descripcin del estado del host o servicio monitoreado, se
puede obtener informacin adicional acerca del funcionamiento de un plugin, esta informacin es
llamada performance data y puede ser de dos tipos (ver [NAGIOSPERFDATA] para ms detalle):
Informacin interna relacionada con la ejecucin del monitoreo, como por ejemplo el nmero de
71
segundos que dur su ejecucin. Esta informacin est disponible para todos los plugins.
Mtricas del host o servicio monitoreado, esta informacin es opcional pero si se encuentra debe
ser retornada a continuacin de la lnea de texto obligatoria y separada de la misma con "|". Las
mtricas retornadas deben respetar el siguiente formato:
'etiqueta'=valor[UOM];[warn];[crit];[min];[max] donde:
o [warn];[crit]: son los valores de los umbrales de alerta y crtico de la mtrica.
o [min];[max]: son los valores mnimos y mximos posibles de la mtrica.
o UOM: es la unidad de medida de la mtrica.
Este ltimo tipo de performance data puede ser enviada a aplicaciones externas para su
procesamiento. Esto hace que pueda elegirse libremente que aplicacin o aplicaciones se quiere utilizar
para el tratamiento y/o almacenamiento de las mtricas. Esta flexibilidad es una de las principales
ventajas de Nagios sobre las otras aplicaciones de monitoreo investigadas, ya que permite realizar
personalizaciones sin tener que tocar el componente core de Nagios.
4.2.1.3 - Macros
En Nagios, la manera de indicar que script, programa, etc se debe ejecutar para la recoleccin
de cada una de las mtricas es mediante la definicin de comandos [NAGIOSCOMMANDS] y de
servicios [NAGIOSSERVICIOS]. Los macros permiten referenciar informacin de hosts, servicios,
etc; para ser utilizadas en dichas definiciones. Antes que Nagios ejecute un comando remplaza todos
los macros que se encuentren en su definicin con su valor correspondiente [NAGIOSMACROS].
En [NAGIOSMACROSSTAND] se encuentra la lista de los macros disponibles de los cuales
cabe destacar los siguientes:
$LASTSERVICECHECK$: timestamp que indica cuando fue la ltima vez que se monitoreo el
servicio.
$HOSTNAME$: nombre corto del host, es el valor dado al atributo host_name de la definicin
del mismo.
$SERVICESTATE$: indica el estado actual del servicio ("OK", "WARNING", "UNKNOWN",
o "CRITICAL").
$SERVICEEXECUTIONTIME$: nmero real que indica cuanto tiempo dur la ejecucin del
programa, script, etc que se invoca para realizar el monitoreo del servicio.
$SERVICEDESC$: es la descripcin indicada en la definicin del servicio.
$SERVICEOUTPUT$: es la primera lnea del resultado del ltimo monitoreo del servicio.
$SERVICEPERFDATA$: es la informacin de performance data del resultado del ltimo
monitoreo del servicio.
72
4.2.2 - Recoleccin de mtricas

Para la recoleccin de mtricas del JBoss y de la JVM se utiliz un plugin llamado check_jmx
obtenido de [JMXNAGIOSPLUGIN] que permite monitorear atributos JMX desde Nagios. Este plugin
est desarrollado en Java y consta de dos archivos, el archivo con la lgica del plugin escrita en Java y
un shell script que ejecuta esta ltima cuando Nagios lo determina.
Como el plugin no cumpla con los requisitos de todo plugin para Nagios (ver la seccin 4.2.1.2
- Plugins para ms detalle) se le debi realizar las siguientes modificaciones:
Se le agreg la seccin de performance data a la respuesta del plugin.
Se le agreg un parmetro opcional a travs del cual recibe la unidad de medida de la mtrica, que
ser la utilizada dentro de la informacin de performance data devuelta por el plugin. Si este
parmetro no es indicado, el valor de la mtrica devuelto no estar acompaado de ninguna unidad
de medida.
Se configuraron cuatro comandos para la utilizacin de dicho plugin los cuales son mostrados
en el Listado 3 y se diferencian entre ellos en si lo que se quiere monitorear es un atributo simple del
MBean o es un atributo compuesto, es decir si lo que se quiere obtener es el valor de una propiedad de
un atributo del MBean que es un objeto. Por otro lado para cada uno de los casos se tiene uno que
acepta como parmetro la unidad de medida y otro que no lo hace.
Listado 3 - Comandos configurados para el plugin check_jmx
#Definicin del check_jmx comando para el caso de un atributo compuesto sin unidad
define command{
command_name
command_line
-w $ARG5$ -c $ARG6$
check_jmx_comp
/usr/local/nagios/libexec/check_jmx -U $ARG1$ -O $ARG2$ -A $ARG3$ -K $ARG4$ -vvvv
}
#Definicin del check_jmx comando para el caso de un atributo compuesto pasando la unidad
define command{
command_name
check_jmx_comp_uom
command_line
/usr/local/nagios/libexec/check_jmx -U $ARG1$ -O $ARG2$ -A $ARG3$ -K $ARG4$ -vvvv
-w $ARG5$ -c $ARG6$ -u $ARG7$
}
#Definicin del check_jmx comando para el caso de un atributo simple
define command{
command_name
check_jmx_simple
command_line
/usr/local/nagios/libexec/check_jmx -U $ARG1$ -O $ARG2$ -A $ARG3$ -vvvv -w $ARG4$
-c $ARG5$
}
#Definicin del check_jmx comando para el caso de un atributo simple con unidad
define command{
command_name
command_line
-c $ARG5$ -u $ARG6$
check_jmx_simple_uom
/usr/local/nagios/libexec/check_jmx -U $ARG1$ -O $ARG2$ -A $ARG3$ -vvvv -w $ARG4$
73
En lo que respecta a la recoleccin de mtricas del entorno se pueden utilizar cualquiera de los
plugins oficiales de Nagios disponibles en [NAGIOSPLUGINS] como tambin cualquiera de los
desarrollados por terceros que se pueden obtener en [NAGIOSEXCHANGEPLUGINS], dependiendo
de qu mtrica se desee medir.
En este punto cabe destacar que entre los distintos accesorios que tiene Nagios existen dos muy
tiles para el monitoreo de hosts remotos, ellos son el NRPE - Nagios Remote Plugin Executor
[NRPE] y el NSCA - Nagios Service Check Acceptor [NSCA].
EL NRPE permite ejecutar plugins de Nagios de manera remota, as como tambin permite
comunicarse con algunos agentes Windows, de esta forma es posible el monitoreo de mquinas
remotas an aquellas que tengan Windows. En la Figura 27 se muestra el esquema de funcionamiento
del NRPE.
Figura 27 - Esquema de funcionamiento del NRPE [NRPE]
El NSCA permite realizar monitoreo pasivo, es decir que utilizando NSCA Nagios no decide
cuando interrogar a los recursos monitoreados, es decir cuando recolectar las mtricas, sino que en
cambio se queda esperando la recepcin de las mismas, las cuales son enviadas remotamente por el
agente NSCA. En la Figura 28 se muestra el esquema de funcionamiento del mismo
Figura 28 - Esquema de funcionamiento del NSCA [NSCA]
4.3 - Sensor y Actuador

La funcin del sensor es la de recibir las mtricas recolectadas por el sistema de monitoreo,
comunicrselas al control de tiempo real para que las analice con el fin de detectar alguna anomala
que pueda llevar a producir una falla en el servidor o en la JVM. Si el sistema de control determina que
es necesario aplicar alguna accin correctiva se la comunica al actuador quien se encarga de aplicarla.
74
Para cumplir con la funcionalidad descrita se decidi utilizar un plugin de Nagios llamado
BrainyPDM [BRAINYPDM] debido a que su arquitectura permite expandirlo fcilmente sumado al
hecho que est desarrollado en Java lo que hace que la comunicacin va JMX de la accin correctiva a
aplicar es directa. Por otro lado almacena las mtricas recibidas de Nagios en una base de datos, ya
sean en rrdb o en MySQL y provee una interfaz grfica web mediante la cual pueden configurarse
cuales mtricas se desea almacenar.
4.3.1 - BrainyPDM
BrainyPDM es ms que un plugin Nagios, es un programa desarrollado en Java que se ejecuta
independientemente de Nagios cuya funcin principal es la de procesar la informacin de performance
data recibida de este ltimo a travs de TCP/IP y almacenarla en una base de datos rrdb interna o en
una base de datos externa, dependiendo de cmo se lo configure.
Para poder ser utilizado en la infraestructura desarrollada se le debi modificar la funcionalidad
del mismo as como tambin agregarle nueva funcionalidad que consiste principalmente en i) la
transmisin de las mtricas, ya procesadas al control en tiempo real, ii) la recepcin de parte de este
ltimo de las acciones correctivas a aplicar, y iii) la aplicacin de las mismas a travs de JMX.
4.3.1.1 - Arquitectura
En la Figura 29 se presenta la arquitectura de BrainyPDM y la interaccin de este con el resto
de la infraestructura, en dicha figura puede observarse que el mismo est compuesto por mdulos,
donde cada mdulo representa una funcionalidad particular, por otro lado cada uno de ellos tiene cero
o ms dependencias de otro mdulo, se llama hijo a aquel que tiene una o ms dependencia de otro y
padre a aquel que tiene uno o ms hijos, es decir a aquel del cual dependen uno o ms mdulos. Un
mdulo hijo no funcionar si no lo hace su padre [BRAINYPDMARQ].
75
cmp modulos
BrainyPDM
graph module
web module
use
Usuario
datastore
(from
Actores)
snaphshot
dodo module
authorization module
ACL
control module
actuacion transmision
dbembedded
Nagios
flow
nagios module
flow
JBoss/JVM
flow
modulemgr
Sistema de Control
Externo:
PowerDEVS
Figura 29 - Arquitectura de BrainyPDM
A continuacin se describen cada uno de los mdulos listados en la figura de referencia:

modulemgr: es el encargado de cargar y arrancar, teniendo en cuenta las dependencias, el resto
de los mdulos cuando comienza la ejecucin de BrainyPDM y de pararlos cuando finaliza la
misma.
datastore: es el encargado de almacenar los datos ya sea en la base de datos embebida como en
la externa.
authorization module: es el encargado de la autenticacin de los usuarios y de otorgarle los
permisos, para ello utiliza ACL.[ACLWIKI]
web module: es el modulo que contiene la funcionalidad relacionada con la interfaz web, utiliza
el servidor web embebido jetty.
Nagios module: es el encargado de procesar la informacin recibida de Nagios.
dbembedded: este mdulo maneja la base de datos embebida.
dodo module: es un mdulo virtual que es utilizado para crear dependencias virtuales, como por
ejemplo cuando se utiliza una base de datos externa el mdulo datastore no depender de
dbembedded sino que habr que hacerlo depender de este mdulo.
Los mdulos listados pertenecen a la arquitectura original a la cual se le agreg un mdulo
76
llamado control module el cual se encarga de enviar las mtricas al control de tiempo real externo y
de aplicar la accin correctiva que este ltimo determine. A este mdulo se lo hizo depender del
Nagios module ya que si no se tienen mtricas no tiene sentido tener la funcionalidad de control
activa.
4.3.2 - Recepcin de las mtricas

Para que BrainyPDM reciba la informacin recolectada por Nagios, es necesario configurar el
comando llamado process-service-perfdata tal como se muestra a continuacin (ver Anexo A: Manual
de instalacin):
define command{
command_name process-service-perfdata
command_line /usr/lib/nagios/plugins/send.sh
"$LASTSERVICECHECK$||$HOSTNAME$||$SERVICESTATE$||$SERVICEEXECUTIONTIME$||$SERVICEDESC$||$SERVIC
EOUTPUT$||$SERVICEPERFDATA$"
}
donde send.sh es un shell script que enva a BrainyPDM, va TCP, la informacin definida
mediante los macros.
El procesamiento y anlisis de la informacin recibida de Nagios est basada en plugins,
llamados procesadores, los cuales son configurados en el archivo nagios-def.xml, ubicado en el
directorio $BRAINY_HOME/plugins/nagios/3, donde se indica los procesadores disponibles indicando
para cada uno de ellos el nombre con el cual se lo va a identificar, la clase que lo implementa, la
descripcin, los parmetros que definen su comportamiento y, en caso que corresponda, los parmetros
propios de cada uno.
Entre los parmetros que definen el comportamiento deseado de un plugin, se encuentran los
siguientes:
serviceFilter: el plugin slo ser utilizado para procesar aquella informacin proveniente de
Nagios cuyo nombre de servicio coincida con el filtro indicado en este parmetro.
hostFilter: el plugin slo ser utilizado para procesar aquella informacin proveniente de
Nagios cuyo nombre del host coincida con el filtro indicado en este parmetro.
parsePerfData: indica si el plugin debe procesar o no la informacin de performance data es
decir los datos provenientes del macro SERVICEPERFDATA.
parseOutput: indica si el plugin procesar o no los datos provenientes del macro
SERVICEOUTPUT.
overwriteOrder: este valor indica que plugin ser quien almacenar la informacin de
performance data recibida en caso que exista ms de uno con posibilidades de hacerlo y quien lo
har ser el que tenga el valor ms chico.
De esta forma cuando BrainyPDM arranca carga en memoria todas las definiciones de los
plugins procesadores configurados y cada vez que recibe informacin desde Nagios la procesar con
3
donde $BRAINY_HOME representa el directorio en el cual se encuentra instalado el BrainyPDM
77
aquellos que corresponda segn de que servicio y/o host se trate.

Ejemplo: en el siguiente ejemplo el plugin, al cual corresponde la definicin mostrada,
procesar la informacin del monitoreo del servicio llamado PING proveniente de cualquier host y
analizar y almacenar la informacin de performance data que reciba.
<serviceFilter><![CDATA[PING]]></serviceFilter>
<hostFilter><![CDATA[.*]]></hostFilter>
<parsePerfData>true</parsePerfData>
Se pueden desarrollar plugins propios o utilizar algunos de los tres que BrainyPDM trae, entre
los cuales se encuentra el llamado DefaultPerformanceData, implementado por la clase
org.brainypdm.plugins.nagios.RegExpr y que utiliza una expresin regular para determinar que
formato de performace data procesar. Es este plugin el utilizado para el presente trabajo y el mismo
fue configurado para procesar informacin del tipo:
label=value[UOM];[warn];[crit];[min];[max].
Al proceso descripto se le agreg la funcionalidad que enva los datos de performance data
procesados al control de tiempo real externo, mecanismo que ser explicado ms en detalle en la
prxima seccin.
4.3.3 - Modificaciones Realizadas a BrainyPDM

En esta seccin se explicar las funcionalidades agregadas al BrainyPDM para que pueda ser
parte, tanto como sensor como actuador, de la infraestructura desarrollada.
Se dividi la seccin en dos partes, primero se explica cmo es la transmisin de las mtricas
al/los controles en tiempo real externo y luego como es el mecanismo de actuacin sobre el sistema
controlado.
4.3.3.1 - Transmisin de las mtricas al sistema de control externo

En esta seccin se explica cmo se desarroll la iteracin de BrainyPDM con el sistema de
control en tiempo real externo para la transmisin de las mtricas recolectadas.
Uno de los objetivos planteados para la solucin propuesta es permitir que el sistema de
control de tiempo real externo pueda ser intercambiado fcilmente, la infraestructura desarrollada no
slo permite esto sino que tambin permite que haya ms de uno trabajando en paralelo. De esta forma
es posible aplicar distintos enfoques sin que ello signifique un gran esfuerzo.
Para lograr el objetivo planteado se sigui el mismo criterio que el utilizado para el
procesamiento de la informacin recibida de Nagios, es decir que se tiene un archivo XML llamado
transmisores-def.xml ubicado en $BRAINY_HOME/plugins/control/4, en donde se configuran los
transmisores disponibles siendo cada uno de ellos los encargados de transmitir las mtricas deseadas al
sistema de control que corresponda y de la manera ms adecuada para este ltimo. Para cada uno de
los transmisores se le deben configurar los siguientes parmetros:
4
78
name: identificacin unvoca del transmisor

className: clase que implementa el transmisor que est siendo configurado, esta clase debe
heredar de la clase abstracta TransmisorBase la cual contiene la funcionalidad comn a todo
transmisor, debiendo slo implementarse en las clases concretas el mtodo enviar que es donde
se realiza la transmisin de las mtricas.
description: descripcin del transmisor.
idle: true/false y sirve para habilitar/deshabilitar el transmisor.
Si se desea transmitir todo lo recibido de Nagios no se debe configurar nada adicional, en
cambio si por el transmisor que se est configurando solo interesan enviar algunas mtricas se
debe configurar los siguiente:
o host: se configura los host de los cuales se quiere transmitir las mtricas recibidas, por
cada host se indica:
name: nombre del host
los servicios interesados, indicando para cada uno de ellos:
name: nombre del servicio
metrics: las mtricas interesadas a transmitir indicando para cada una de

ellas:
o name: nombre de la mtrica
labelType: tipo de etiqueta a enviar, dependiendo del valor configurado en este atributo, el
formato del mensaje a enviar al control externo ser: [[host;]servicio;]mtrica=valor
respectivamente:
o C: completa
o S: servicio + nombre de la mtrica
o M: slo el nombre de la mtrica
params: parmetros propios de cada transmisor, por ejemplo para el transmisor implementado
para la prueba de concepto realizada, el cual transmite las mtricas a travs de UDP se tienen los
siguientes parmetros:
o ip y port: ip y puerto a donde se va a transmitir las mtricas.
Al igual que sucede con los plugins que procesa la informacin recibida de Nagios, cuando
BrainyPDM arranca carga en memoria los transmisores configurados creando una instancia de cada
uno de ellos.
Luego que la informacin recibida desde Nagios es procesada, si la misma contiene la seccin
de performance data, adems de almacenarla en la base de datos correspondiente (externa o
embebida) se obtienen todos los transmisores configurados para transmitir las mtricas recibidas,
segn host, servicio y/nombre de la mtrica de la cual se trate, y se enva los datos a travs de ellos
mediante la ejecucin de su mtodo enviar.
79
En la Figura 30 se muestra el esquema del Sensor descripto mientras que en la Figura 31 se

puede ver el diagrama de secuencia del proceso de recepcin de las mtricas y su transmisin al
sistema de control externo.
Figura 30 - Esquema del proceso del sensor
Figura 31 - Diagrama de secuencia del proceso de recepcin de mtricas y transmisin de las mismas al
sistema de control externo
80
De esta forma la responsabilidad de conocer cmo y dnde, es decir a que control externo se
debe enviar la informacin, recae nicamente en los transmisores, sin que BrainyPDM tenga
conocimiento de ello. En caso de querer agregar un nuevo enfoque, lo nico que hay que hacer es
configurar el transmisor correspondiente y si los existentes no son adecuados para la comunicacin con
el nuevo sistema de control que se quiere utilizar, slo se debe desarrollar uno nuevo hacindolo
heredar de la clase abstracta TransmisorBase e implementando su mtodo enviar con la lgica
adecuada para la transmisin.
Para poder transmitir las mtricas al sistema de control externo seleccionado con el fin de
desarrollar una solucin completa y mostrar el funcionamiento de la infraestructura armada, se
desarroll el transmisor TransmisorByUDP el cual enva la informacin a travs del protocolo UDP al
cual se le debe configurar la direccin IP y el puerto a travs de los cuales se enviaran los datos. En la
Figura 32 se muestra el diagrama de clases de los transmisores, en ella se ve la clase base abstracta
mencionada y la clase implementada, as como tambin la interfaz que define el comportamiento de
todo transmisor.
Figura 32 - Diagrama de clases de los transmisores
81
4.3.3.2 - Actuacin
El proceso de actuacin sigue el mismo criterio que el de transmisin de las mtricas al sistema
de control externo, en el sentido que existe un archivo XML llamado actuadores-def.xml ubicado en
$BRAINY_HOME/plugins/control5, en el cual se configuran los actuadores disponibles, siendo un
actuador el encargado de recibir del control en tiempo real la accin correctiva definida y de aplicarla.
Para cada uno de los actuadores se le deben configurar los siguientes parmetros:
name: identificacin unvoca del actuador
className: clase que implementa el actuador que est siendo configurado, esta clase debe
heredar de la clase abstracta ActuadorBase la cual contiene la funcionalidad comn a todos los
actuadores, debindose implementar en las clases concretas el mtodo recibir que es a travs del
cual se recibe la accin correctiva a aplicar.
description: descripcin del actuador.
idle: true/false, sirve para habilitar/deshabilitar al actuador.
url: url donde se encuentran los MBeans sobre los cuales se actuar.
params: parmetros propios de cada actuador, por ejemplo para el caso del actuador
implementado para ser utilizado en la prueba de concepto, el cual recibe la indicacin de la
accin correctiva a aplicar a travs del protocolo UDP, se tiene que configurar:
o port: puerto en el cual va a estar escuchando por directivas de actuacin
La clase ActuadorBase, clase padre de todo actuador, implementa la interfaz Actuador la cual
hereda de Runneable [RUNNEABLE], es decir que cada uno de los actuadores se ejecuta como un
thread independiente del resto. Cuando BrainyPDM arranca levanta las definiciones de los actuadores
configurados creando una instancia para cada uno de ellos y pone en ejecucin el thread asociado. En
el mtodo run de cada uno de ellos se ejecuta el mtodo recibir del actuador quien se queda a la espera
de recibir alguna directiva del control externo. Cuando este ltimo determina que se debe aplicar una
accin correctiva, le enva al actuador correspondiente la directiva acerca de cul accin debe aplicar.
De manera similar a lo que sucede con los transmisores, la responsabilidad de conocer cmo y
de dnde proviene la accin correctiva a aplicar, es decir de qu control externo se recibir la directiva,
recae nicamente en los actuadores, sin que BrainyPDM tenga conocimiento de ello. En caso de querer
agregar un nuevo enfoque, lo nico que hay que hacer es configurar el actuador correspondiente y si
los existentes no son adecuados para la comunicacin con el nuevo sistema de control que se quiere
utilizar, slo se debe desarrollar uno nuevo hacindolo heredar de la clase abstracta ActuadorBase
implementando su mtodo recibir con la lgica adecuada para la recepcin de la informacin.
Para recibir la accin correctiva a aplicar desde el control externo seleccionado con el fin de
desarrollar una solucin completa y mostrar el funcionamiento de la infraestructura armada, se
desarroll el transmisor ActuadorByUDP que recibe la informacin a travs del protocolo UDP y al
82
cual se le debe configurar el puerto donde se quedar esperando la recepcin de la informacin. En la

Figura 33 se muestra el diagrama de clases de los actuadores, en ella se muestra la clase abstracta base
y el actuador implementado, as como tambin la interfaz que define el comportamiento de todo
actuador.
Figura 33 - Diagrama de clases de los actuadores
La aplicacin de la accin correctiva, es decir la actuacin sobre el sistema controlado (en

nuestro caso el JBoss y la JVM) se realiza a travs de JMX, lo que en la prctica significa que se
ejecuta alguna operacin o se cambia el valor de algn atributo de un MBean que encapsula el recurso
cuyo comportamiento se est queriendo modificar.
Para que un MBean pueda ser accedido para plasmar alguna accin correctiva a aplicar, es
decir para que el recurso al cual encapsula pueda ser modificado en tiempo de ejecucin, debe ser
configurado en el archivo mbeans-def.xml, ubicado en el mismo directorio que el archivo donde se
configuran los actuadores. Los datos que se configuran por cada uno de los MBeans son:
id: es el identificador unvoco del MBean, es el utilizado, junto con el id del mtodo, desde el
sistema de control externo para indicar que MBean y cual mtodo de este ltimo, debe recibir la
accin.
name: es el object name del MBean.
83
metodos: se configuran todos los mtodos del MBean que se quieren exponer, indicando para
cada uno de ellos:
o id: identificador unvoco del mtodo, se lo utiliza junto con el id del MBean para
indicar el MBean y el mtodo que recibe la accin a aplicar.
o name: nombre del mtodo a invocar en caso de ser una operacin o el nombre del
atributo.
o type: 'o' indica que es una operacin y 's' o 'S' si el mtodo es para cambiar el valor de
un atributo.
o signatura: indica como es la signatura del mtodo, es decir el tipo de dato de los
parmetros del mismo. La signatura de los mtodos a invocar debe cumplir con las
siguientes condiciones:
contener clases que tengan un constructor que tome como parmetro un string al
cual debe convertirlo en un objeto de la clase indicada.
no tener arrays, esta restriccin est relacionada con la manera en que el MBean
es invocado.
Una vez configurado correctamente un MBean, este ya puede ser invocado desde cualquier
actuador.
Ejemplo de configuracin de un MBean.
<mbean id="jbosswebConn" name="jboss.web:type=Connector,port=8080, address=%2F127.0.0.1">
<metodos>
<metodo id="acceptCountAttr" name="acceptCount" type="s">
<signatura>
<class>int</class>
</signatura>
</metodo>
</metodos>
</mbean>
El sistema de control externo le indicar al actuador correspondiente que MBean y que mtodo
de este ltimo se debe ejecutar, a travs de un mensaje con el siguiente formato:
mbean1|operacion|arg1,arg2,...,argn||mbean2|operacion|arg1,arg2,...,argn||....
donde MBeani es el id del MBean correspondiente.
El actuador buscar la definicin del/los MBean/s indicados y ejecutar el mtodo
correspondiente de cada uno de ellos en el orden en el cual fueron enviados.
84
Figura 34 - Diagrama de secuencia del proceso de actuacin sobre el sistema controlado
Figura 35 - Esquema del proceso de actuacin
En la Figura 35 se muestra el esquema de actuacin mientras que en la Figura 34 se muestra el

proceso descripto, en donde se ve como el actuador, al recibir del control externo la indicacin de
actuar junto con el identificador del MBean y mtodo a ejecutar o atributo a modificar, obtiene de la
configuracin el Object Name y los datos de la operacin o atributo que se quieren ejecutar o
modificar, respectivamente, y luego aplica la accin ejecutando la operacin o modificando el atributo.
4.4 - Control mediante Modelos en Tiempo Real

La arquitectura de la infraestructura propuesta fue diseada de manera tal que sea posible optar
flexiblemente por distintas estrategias de control sin que ello implique modificacin alguna al resto
de los componentes.
85
Se busca que los modelos de controladores, cualquiera sea su naturaleza (continuos, a tiempo
discreto, a eventos discretos, o hbridos), se implementan dentro de un nico entorno de modelado y
simulacin.
Esto permite seguir la estrategia conocida como System-In-The-Loop (sistema dentro del lazo):
los modelos son desarrollados, ensayados y verificados mediante simulaciones standalone,
desconectadas del sistema real a controlar (sistema fuera del lazo). Luego, las entradas y salidas del
controlador son redireccionados hacia el sistema real (en nuestro caso, hacia/desde plugins de
monitoreo y actuacin) y son ejecutados en tiempo real (sistema dentro del lazo).
Asimismo se busca que el tipo de modelos a obtener incluya de manera natural la categora de
modelos naturalmente utilizada en Ingeniera de Control digital (ecuaciones en diferencia) y as
disminuir la brecha existente con la Ingeniera de Software a la hora de seguir el enfoque que aplica
Teora de Control a Sistemas Informticos.
Se elige para esto a la herramienta de Modelado y Simulacin de cdigo abierto PowerDEVS
([POWERDEVS]), de propsito general, pero nativamente concebida para control en tiempo real.
Asimismo, por el hecho de estar basado en DEVS permite la especificacin de modelos de cualquier
naturaleza, tal como se pretende. Esta decisin se basa en dos experiencias exitosas recientes: una
aplicando PowerDEVS en el diseo de controladores para sistemas informticos [Castro et al, 2009] y
otra aplicando otro simulador basado en DEVS operando en tiempo real para la implementacin
prctica de un controlador de calidad de servicio para una red de datos [Castro et al, 2012].
Para lograr nuestros objetivos se debi realizar modificaciones a PowerDEVS para que pueda
integrarse a la infraestructura desarrollada a la vez que permanezca siendo una herramienta autnoma.
Esto se logr incorporando a PowerDEVS capacidades de comunicacin va red. Estas sern
explicadas luego de una pequea introduccin al formalismo DEVS.
4.4.1 - Formalismo DEVS

DEVS [Zeiger et al, 2000] es un formalismo propuesto en 1976 por Bernard Zeigler para el
modelado de sistemas a eventos discretos, que permite representar cualquier sistema que realice una
cantidad finita de cambios en un intervalo de tiempo finito. Un modelo DEVS procesa una trayectoria
de eventos de entrada y, segn esa trayectoria y sus propias condiciones iniciales, produce una
trayectoria de eventos de salida.
El modelo DEVS ms simple es llamado Modelo Atmico (M) y queda definido por la
siguiente estructura matemtica de conjuntos y funciones [Kofman, 2000a]:
M=(X, Y, S, int, ext, , ta)

donde:
X: es el conjunto de todos los valores que un evento de entrada puede adoptar.
Y: es el conjunto de los valores de los eventos de salida.
S: es el conjunto de los valores de estado.
86
int : es la funcin de transicin interna.

ext : es la funcin de transicin externa.
: es la funcin de salida.
ta: es la funcin de avance de tiempo.
Su funcionamiento bsico es el siguiente: Cada posible estado s S tiene asociado un avance de
tiempo el cual es calculado mediante la funcin de avance de tiempo ta(s). El avance de tiempo es un
nmero real no negativo que indica el tiempo durante el cual el sistema estar en un determinado
estado en ausencia de eventos de entrada. Cuando dicho tiempo transcurre el sistema produce un
evento de salida dependiente del estado en el cual se encontraba, es decir que el evento producido tiene
un valor de (s), y cambia a un nuevo estado dado por int (s). Se dice entonces que el sistema realiz
una transicin interna.
Si antes de que finalice el avance de tiempo ocurre un evento externo con valor x el sistema
cambia a un nuevo estado, el cual depender del tiempo transcurrido (e), del estado en el cual se
encontraba el sistema y del evento externo recibido y cuyo valor est dado por ext (s,e,x), no
producindose evento de salida alguno.
Los sistemas complejos pueden pensarse como el acoplamiento de sistemas ms simples,
obteniendo modelos acoplados, de esta manera los eventos de salidas de algunos subsistemas se
convierten en eventos de entrada de otro. La teora garantiza que el acoplamiento de modelos DEVS
define un nuevo modelo DEVS, de esta forma los sistemas complejos pueden ser representados por
DEVS de una manera jerrquica [Kofman, 2000b].
Una de las ventajas principales de la especificacin DEVS es que es altamente orientada a la
simulacin, por lo cual la programacin de simuladores para estos modelos es muy sencilla [Kofman,
2000c]. La idea bsica se reduce a 4 pasos:
1. Buscar el modelo atmico prximo en realizar una transicin interna, es decir aquel cuyo
tiempo de avance coincida con el tiempo transcurrido.
2. Avanzar el tiempo de la simulacin y ejecutar la transicin interna del atmico.
3. Propagar el evento de salida producido por el atmico hacia el resto de los modelos atmicos
conectados a l, ejecutando las transiciones externas correspondientes.
4. Volver al paso 1.
En lo que respecta a la arquitectura del simulador, se tiene una estructura jerrquica similar a la
estructura del modelo a simular, tal como se muestra en la Figura 36, y se asocia a cada elemento del
mismo una clase de simulador diferente segn de qu tipo se trate, la clase asociada a un modelo
atmico se llama simulator, mientras que la asociada a un modelo acoplado se llama coordinator.
Por otro lado existe un coordinador raz que es el encargado de iniciar los ciclos de simulacin y de
dirigir el avance del tiempo de la simulacin.
87
Figura 36 - Simulador jerrquico (derecha) asociado a un modelo (izquierda)
4.4.2 - PowerDEVS
PowerDEVS ([POWERDEVS]) es un entorno de simulacin de modelos DEVS desarrollado
por un grupo de investigacin de la Facultad de Ciencias Exactas, Ingeniera y Agrimensura de la
Universidad Nacional de Rosario. En el presente trabajo se utiliz la versin 2.0 del mismo.
La descripcin que sigue brinda el conocimiento necesario para comprender las modificaciones
realizadas a PowerDEVS, que tienen relevancia mas all de la presente Tesis ya que permitir a
PowerDEVS interactuar con elementos externos va red para cualquier propsito.
4.4.2.1 - Arquitectura de PowerDEVS

PowerDEVS est compuesto de varios programas independientes [Bergero & Kofman, 2010]:
Editor de modelos: es el programa principal, desde el punto de vista del usuario, ya que provee la
interfaz grfica y el acceso al resto de las aplicaciones. Mediante este editor es posible construir y
editar los diagramas en bloques de los modelos as como tambin crear y editar libreras. Este
editor posibilita que pueda utilizarse PowerDEVS sin necesidad de tener conocimientos acerca del
formalismo DEVS, ya que adems cuenta con una completa biblioteca de atmicos. Slo es
necesario un conocimiento bsico del formalismo en caso de necesitarse la creacin de nuevos
atmicos. En la Figura 37 se muestra la interfaz del editor principal, ventana de la izquierda y un
ejemplo de armado de un modelo DEVS, ventana de la derecha.
88
Figura 37 - Interfaz del editor de PowerDEVS: Editor principal (izquierda). Editor de un modelo (derecha)
Editor de modelos atmicos: permite la edicin del cdigo C++ de cada uno de los atmicos del
modelo. Mediante este editor se programan el contenido de las funciones de salida, de avance de
tiempo, de transicin interna y de transicin externa de cada atmico. Adems de estas funciones
del formalismo DEVS hay 2 funciones adicionales, la de inicializacin y la de terminacin las
cuales son ejecutadas antes de que la simulacin comience y al finalizar la misma,
respectivamente. Cuando el modelo es guardado se generan los archivos .cpp y .h. En la Figura 38
se muestra la edicin del cdigo que define el comportamiento del atmico marcado, en particular
en dicha imagen se ve la funcionalidad de la funcin de transicin externa del mismo.
Figura 38 - Interfaz de edicin de cdigo de los atmicos de PowerDEVS
El preprocesador: genera los archivos ejecutables a partir de los creados a travs del editor.
Interfaz de simulacin: interfaz que permite ejecutar la simulacin dando la posibilidad de

configurar algunos parmetros de la misma, Figura 39.
89
Figura 39 - Interfaz de simulacin de PowerDEVS
En la Figura 40 se muestran las clases principales de PowerDEVS que estn involucradas en la

simulacin, donde:
Simulator: es una clase abstracta de la cual deben heredar las clase asociada a cada atmico, quien
debe implementar los mtodos que representan a las funciones definidas en el formalismo DEVS,
es decir las funciones de transicin interna, transicin externa, de salida y la de avance de tiempo
ms dos mtodos adicionales que define Simulator, llamados init y exit y que son ejecutados al
comienzo y al final de la simulacin, respectivamente y cuyas finalidades son la de inicializacin y
liberacin de los recursos utilizados por los atmicos.
Event: esta clase es utilizada para informar la ocurrencia de un evento, a la funcin de transicin
externa le llega como entrada con la informacin del evento externo ocurrida, mientras que la
funcin de salida la utiliza para enviar informacin a otros atmicos. Contiene las siguientes
propiedades:
o port: es un nmero entero que indica el puerto de entrada por donde se recibi un
evento, o el puerto por donde se debe enviar el evento.
o value: contiene el dato que se recibe o que se quiere propagar.
o realTimeMode: es un nmero entero que determina si el evento debe ser o no
sincronizado con el tiempo real.
Coupling: representa un acoplado del modelo DEVS.
Connection: esta clase es utilizada para representar las conexiones entre los modelos que
conforman la estructura de los acoplados.
RootSimulator: esta clase es la encargada de ejecutar la simulacin interactuando con el acoplado

principal (instancia de la clase RootCoupling).
RootCoupling: esta clase hereda de la clase Coupling y est asociada al acoplado principal del
modelo, es decir al acoplado superior de la estructura jerrquica que representa al modelo. Se hizo
esta diferencia ya que este acoplado se difiere de los dems en que no tiene a un padre a quien
90
notificarle los cambios de los tiempos sino que se lo debe notificar al RootSimulator.
Figura 40 - Modelo de clases principales de PowerDEVS.
Adems de estas clases se tienen una serie de archivos que contienen, para cada uno de los
sistemas operativos soportados, las funciones y tipos de datos tiles para los atmicos y/o para el
mismo PowerDEVS, estas bibliotecas son: pdevslib.cpp, pdevs.linux.cpp, pdevs.win.cpp y
pdevs.rtai.cpp.
91
4.4.3 - Modificaciones realizadas a PowerDEVS

Con el propsito de poder utilizar PowerDEVS como sistema de control de la infraestructura
desarrollada hubo que agregarle la funcionalidad de comunicacin con el exterior. Esta funcionalidad
agregada consiste en el envo de informacin al exterior, necesaria para notificar la directiva de
actuacin a BrainyPDM y la recepcin de datos del exterior, para la recepcin de las mtricas
recolectadas.
La comunicacin de PowerDEVS con el exterior se realiz a travs de un socket utilizando el
protocolo UDP y est disponible slo para la versin de PowerDEVS 2.0 para Linux. A continuacin
se explica ms en detalle cmo se desarroll la nueva funcionalidad.
4.4.3.1 - Envo de datos al exterior

Para poder enviar informacin a otras aplicaciones se le agreg una funcin a la biblioteca
pdevslib para Linux, cuya signatura se muestra a continuacin:
void sendNET(int port,char*ip,char*data,int size);
donde:
port: es el puerto que, junto con la IP, identifican el destino de los datos.
ip: es la IP del destino al cual se le quiere enviar los datos.
data: son los datos a enviar.
size: es el tamao en bytes de los datos a enviar.
De esta forma cuando un modelo atmico necesita enviar informacin hacia el exterior de
PowerDEVS slo tiene que invocar dicha funcin. En la Figura 41 se muestra un ejemplo de uso de la
misma.
Figura 41 - Ejemplo de uso de la funcin sendNET
4.4.3.2 - Recepcin de datos del exterior

Para que un modelo atmico pueda recibir datos va red, se implement un mecanismo de
subscripciones mediante el cual un modelo atmico, que necesita recibir informacin del exterior,
primero debe registrarse como interesado en ser notificado de la llegada de datos por un determinado
92
puerto de red, es decir debe registrarse como listener de dicho puerto. Luego, cuando se recibe
informacin a travs del puerto, los modelos registrados son notificados desde el motor de simulacin
de la misma manera que cuando ocurre un evento externo, es decir ejecutando su funcin de transicin
externa.
Al registrarse, un modelo atmico puede hacerlo para ser notificado de todos los datos
recibidos a travs de un determinado puerto o tambin tiene la posibilidad de indicar el tipo de mensaje
que le interesa, es decir que en este ltimo caso no ser notificado de todos los datos recibidos por ese
puerto, sino solamente de aquellos que vienen identificados con el tipo indicado (mensajes tipificados).
Formato del mensaje tipificado

Se considera que un mensaje est tipificado cuando tiene el formato xxxx=yyyy donde xxxx
representa el tipo de mensaje e yyyy el contenido del mismo.
El tamao de la cadena que identifica al mensaje est determinada por una constante llamada
SIZETYPEMSG cuyo valor es 128, mientras que el tamao total del mensaje, es decir incluyendo el
tipo y el carcter separador (=), est determinado por la constante SIZEBUFFER cuyo valor es 512.
Modificaciones realizadas al cdigo

Se agreg las siguientes funciones a la biblioteca pdevslib para Linux (pdevslib.linux.cpp):
void RequestNET(int port,Simulator* atomic): esta funcin es la que debe ser utilizada por los
atmicos para registrarse como interesados en los datos que se reciban por el puerto indicado.
void RequestNET(int port, Simulator *atomic,char*msgType): esta funcin es la que debe ser
utilizada por los atmicos para registrarse como interesados en los datos del tipo indicado que
son recibidos por el puerto dado.
void alertOfNET(NETMessage msg): esta funcin es quien est encargada de analizar los
mensajes recibidos a travs de algn puerto, detectar si son tipificados o no, y enviar los datos
recibidos, ya sean tipificados o no, a los atmicos registrados para el puerto dado.
void initNet(): esta funcin es utilizada para inicializar los recursos utilizados para toda la
funcionalidad de recepcin de datos va red. Es ejecutada cuando se realiza el primer registro de
un atmico, es decir en la primera ejecucin de un RequestNet.
void cleanNet(): esta funcin libera los recursos que fueron inicializados en initNet y es
ejecutada cuando se abandona la simulacin, es decir en RootSimulator::exit().
void* net_handler(void*args): esta funcin se ejecuta en un thread separado para cada puerto
que tenga modelos registrados y es la encargada de quedarse esperando en cada uno de ellos por
la llegada de datos.
Adems se crearon las siguientes clases:
PortListeners: esta clase es la que mantiene una lista con los atmicos registrados para un
determinado puerto, inicialmente tiene una capacidad para una cantidad de atmicos dada por la
constante INIT_LENG_LIST (cuyo valor es de 10) y est pensado que cuando se registran ms
de esa cantidad de atmicos para el puerto se redimensione la lista interna, pero esta
funcionalidad no fue implementada. Los mtodos principales de esta clase son:
93
o void addListener(char*msgType,Simulator* atomic): mediante este mtodo se agregan

los modelos atmicos registrados para recibir datos que llegan al puerto al cual est
asociado el objeto PortListeners, si se quiere recibir un determinado tipo de mensaje se
le pasa ste por parmetro, si este valor es NULL entonces el atmico ser notificado de
todos los mensajes que se reciban por el puerto.
o void alertOfMsg(void*data,Time t,char*typeMsg=NULL): mediante este mtodo se le
notifica a los atmicos de la llegada de un mensaje por el puerto para el cual se
registraron. A aquellos atmicos que lo hicieron para un determinado tipo de mensaje se
le notificar slo si el mensaje recibido es del tipo que indicaron.
PortListenersList: esta clase mantiene la lista de todos los objetos de la clase PortListeners, y
contiene los mtodos necesarios para su manipulacin, entre los principales estn:
o bool addPortListener(int port,Simulator* atomic): este mtodo permite registrar un
atmico como interesado en ser notificado de los datos recibidos a travs del puerto
indicado.
o bool addPortListener(int port,Simulator* atomic,char* typeMsg): este mtodo permite
registrar un atmico como interesado en ser notificado de los datos recibidos a travs
del puerto indicado para recibir mensajes el tipo dado por typeMsg.
o void alertOfNETMsg( int port,void*data,Time time): mediante este mtodo se le
notifica, al objeto PortListeners asociado al puerto indicado, de la recepcin de
informacin a travs del mismo.
o void alertOfNETMsg( int port,void*data,Time time,char*typeMsg): mediante este
mtodo se le notifica al objeto PortListeners asociado al puerto indicado, la recepcin
de un mensaje del tipo dado por typeMsg a travs de dicho puerto.
o PortListeners* findPortListeners(int port): busca el objeto PortListeners que mantiene
la lista de atmicos que se registraron para el puerto dado.
MsgQueue: es una cola de mensajes cuyo principales mtodos son:
o int recvNoWait(QUEUEMSG *data, long type=0): mediante este mtodo se puede
obtener un mensaje de la cola de manera no bloqueante, es decir que si no existe un
mensaje del tipo dado no se queda esperando sino que devuelve 0 y permite continuar.
o int send(QUEUEMSG* data, long type=1): coloca un mensaje en la cola del tipo dado
sino se especifica ninguno se le asigna el tipo 1 por defecto. En nuestro caso este ltimo
parmetro no es utilizado, es decir que todos los mensajes encolados sern del tipo por
defecto.
Esquema de funcionamiento
En la Figura 42 se muestra el esquema del mecanismo de subscripcin en ella se pueden ver los
distintos componentes que forman parte del mismo, mientras que en la Figura 43 se muestra un
diagrama de secuencia que representa el proceso del registro de un atmico como listener de un
determinado puerto.
El proceso de subscripcin ocurre cuando se inicia la simulacin en PowerDEVS, cuando el
94
simulador comienza su ejecucin ejecuta el mtodo init() de todos los atmicos del modelo, si alguno
de ellos llama a la funcin RequestNET para registrase como listener de algn puerto, se crean los
recursos necesarios para el mecanismo de notificacin de la informacin recibida a travs de la red.
Como se puede ver en las figuras citadas, estos pasos se ejecutan una sola vez y entre los recursos
creados se encuentran el objeto PortListenerList y la MSQueue. Por otro lado, por cada puerto
involucrado, es decir por cada puerto para el cual se registr por lo menos un modelo atmico, se crea
un objeto PortListener que contendr todos los modelos atmicos registrados y un thread (pthread_t)
en donde se ejecutar la funcin net_handler, cuya funcionalidad principal es esperar por la llegada de
datos a travs del puerto asociado.
En el diagrama de la Figura 44 se muestra el proceso de recepcin de informacin, donde se
puede ver que cuando esto sucede se enva a la cola los datos recibidos junto con el nmero de puerto
por el cual se los recibi.
Figura 42 - Esquema del mecanismo de subscripcin
95
sd Comunicacion v ia red
Este diagrama muestra la secuencia de pasos necesaria para que un atmico se registre como listener de
un determinado port.
RootSimulator
Atomico
library
Este bloque se ejecuta solo una

vez, cuando se ejecuta el primer
RequestNET.
pdevslib.linux
init(Time, ...)
RequestNET(port,this)
opt Inicializacin de recursos
[si no fueron inicializados los recursos de red ]
PortListenersList
listeners= create()
Representa cualquier atmico de un modelo que

quiere ser notificado de los datos que son recibidos
a travs de un determinado port.
En caso de estar interesado slo en un tipo
particular de mensajes es la misma secuencia slo
que se utilizan los mtodos o funciones que toman
como parmetro el tipo de mensaje.
MsgQueue
create()
existed= addPortListener(port, atomic, [typeMsg]) :bool
Devuelve true si ya existe un objeto

PortListeners para el puerto
indicado, o false en caso contrario.
createNode(port, atomic,
[typeMsg])
PorListeners
[si existed=false]:
addListener([msgType], atomic)
[si existed=false]:
create(net_handler, port)
linux thread
pthread_t
ref
Recepcion de Datos
Figura 43 - Diagrama que muestra el registro de un atmico como listener de un puerto
96
Figura 44 - Diagrama de secuencia ante la llega de datos por un puerto
Antes de continuar con la descripcin del esquema de funcionamiento en lo que respecta a la

notificacin de los datos recibidos a los atmicos registrados, vamos a explicar en qu se diferencian el
comportamiento en caso de tratarse de una simulacin en tiempo real con el caso de que no lo sea.
Cuando se realiza una simulacin puede ocurrir que la misma consuma ms tiempo real que el
tiempo simulado o que consuma menos tiempo, pero en cualquiera de ambos casos se encuentra
desfasada del tiempo real. Cuando hablamos de simulacin en tiempo real estamos diciendo que la
simulacin debe respetar estrictamente los tiempos en juego, es decir que los eventos deben ser
emitidos en forma sincronizada con el tiempo real. Para esta modalidad de funcionamiento
PowerDEVS cuenta con un bloque llamado RealTime cuyo objetivo es marcar a los eventos deseados
como de tipo tiempo real, es decir que deben ser entregados en tiempo real.
Cuando el prximo evento que debe ejecutarse es del tipo tiempo real, el motor de simulacin
en lugar de ejecutarlo inmediatamente se queda esperando que transcurra el tiempo ta ejecutando la
funcin waitFor. Es entonces en esta funcin donde se desencolan los datos y se los enva a los
atmicos correspondientes segn el puerto por el cual fueron recibidos.
En el esquema de la Figura 45 se muestra el diagrama de secuencias que describen la ejecucin
de la funcin waitFor en l se puede ver como se desencolan los datos, se los convierte de formato y
se los enva a cada uno de los atmicos registrados.
Es decir que mientras transcurre el tiempo ta, el motor de simulacin revisa la cola
peridicamente para detectar la llegada de mensajes desde el exterior, y en caso que esto suceda
desencadena el proceso de notificacin a los modelo atmicos registrados como listeners del puerto
por el cual se la recibi, utilizando para ello la funcin de transicin externa, es decir de manera
similar a la notificacin de la ocurrencia de un evento externo.
97
Figura 45 - Diagrama de secuencia que muestra la comunicacin de los datos recibidos
En la Figura 46 se resume el esquema completo de envo y recepcin de datos hacia y desde el

exterior de PowerDEVS, en l se muestran los componentes principales que participan de ambos
procesos.
El transmisor de BrainyPDM enva los datos a travs de la red a una determinada IP y puerto,
estos datos son recibidos por el thread asociado al puerto de comunicacin, la funcin que se ejecuta
en dicho thread encola la informacin recibida, la cual luego es desencolada por funcionalidad
contenida en la biblioteca pdevlibs.linux e informada, emulando la ocurrencia de un evento externo, a
los atmicos registrados en el objeto PortListeners asociado al puerto en cuestin.
Por otro lado, cuando el controlador determina la necesidad de aplicar una accin correctiva, el
modelo atmico que funciona como Efector, enva la indicacin al actuador utilizando la funcin
sendNET() ubicada dentro de la biblioteca pdevlibs.linux.
98
Figura 46 - Esquema de recepcin y envo de datos
99
Captulo 5: Prueba de Concepto
100
Con el objetivo de validar el funcionamiento esperado de la infraestructura desarrollada se

realiz una prueba de concepto, se busc abordar alguna problemtica que necesitara obtener mtricas
tanto internas del JBoss y/o de la JVM, es decir obtenidas a travs de JMX; como externas al mismo,
es decir alguna mtrica que no sea propia del servidor o de la JVM sino de su entorno; de manera tal
de abarcar la mayor cantidad posible de aspectos de la infraestructura desarrollada.
5.1 - Descripcin del escenario

Se plantea el siguiente escenario tomado de la experiencia prctica en instalaciones
productivas:
JBoss se encuentra en estado de carga intensa pero su servidor web embebido (JBoss Web
Server [JBOSSWEB]) tiene capacidad para seguir atendiendo pedidos. Se plantea la hiptesis que estas
nuevas peticiones cargarn an ms al JBoss pudiendo causar su colapso, dejndolo inutilizado y
sin poder prestar servicio hasta que la intervencin humana lo estabilice nuevamente, tpicamente
mediante el reinicio de todo el sistema.
La idea propuesta consiste en detectar cuando el JBoss se encuentre sobrecargado, o prximo a
estarlo y actuar de manera tal de reducir la capacidad de recepcin de nuevas peticiones. Para ello es
necesario darle un valor cuantitativo al estado del JBoss definido como sobrecargado, lo que requiere
definir un criterio de medida de carga del mismo en un momento determinado.
Se eligi como medida de la carga del JBoss al siguiente par de mtricas del sistema:
porcentaje de uso de memoria Heap en la JVM, y porcentaje de uso de CPU del JBoss (viendo a la
JVM como un proceso del sistema operativo sobre la cual se encuentra ejecutando JBoss). De esta
forma se pueden definir umbrales para estas mtricas, determinando que a partir de los cuales se debe
considerar que el servidor se encuentra sobrecargado y as aplicar acciones correctivas (como por
ejemplo ajustar los valores de los parmetros que determinan la cola de conexiones del JBoss Web
Server). Cuando el JBoss vuelve a tener los valores de las mtricas definidas como medida de carga
por debajo de estos umbrales (o de otros ms bajos), se vuelven a colocar los valores por defecto de los
parmetros de control.
5.2 - Control
Antes de entrar en detalle acerca de la estrategia de control utilizada, se va a repasar como es el
funcionamiento del JBoss en lo que respecta al procesamiento de los pedidos de los clientes Web.
Como ya se describi antes, JBoss AS utiliza, como servidor web embebido, al JBoss Web
Server el cual es un producto de Red Hat desarrollado utilizando como base al Apache Tomcat
[JBOSSWEB], siendo este ltimo quien le provee la funcionalidad bsica al primero.
El Apache Tomcat puede ser visto, a grandes rasgos, como dos mdulos principales: el
connector (conector) y el container (contenedor). Siendo el conector el encargado de manejar la
conexin entre los clientes (generalmente browsers) y el servidor, recibe los pedidos de los clientes
(requests) y se los enva al contenedor quien realiza el procesamiento adecuado [Kurniawan & Deck,
101
2004].
Existen diversos tipos de conectores disponibles con el Tomcat, entre los cuales se encuentra el
HTTP Connector y el AJP Connector. El primero est basado en el protocolo HTTP/1.1 y es el que se
utiliza cando el Tomcat funciona como un web server autnomo, es decir sin utilizar uno externo, a
esta modalidad de trabajo se la llama standalone. El AJP connector es el conector que se suele usar
cuando se quiere tener un web server externo trabajando junto con el Tomcat. Para la prueba de
concepto realizada se utiliz el conector HTTP ya que se us al JBoss AS en la modalidad stand-alone.
El comportamiento de los conectores puede ser determinado mediante la configuracin de
distintos atributos, algunos de los cuales son comunes para todos los conectores y otros son propios de
cada uno. En particular para el HTTP Conector existen dos atributos, listados a continuacin, que
determinan el comportamiento de ste en lo que respecta al mecanismo de recepcin de los pedidos de
los clientes [Jamae & Johnson, 2009b]:
maxThreads: es la cantidad mxima de threads dedicados al procesamiento de los pedidos de
los clientes (threads de procesamiento o request processor threads) que sern creadas por este
conector. Este valor determina la cantidad mxima de usuarios que podrn estar conectados
concurrentemente en un determinado instante.
acceptCount: determina la longitud mxima de la cola en donde se encolan las nuevas
peticiones cuando todos los threads de procesamiento se encuentran ocupados. Cuando esta cola
se llena toda nueva conexin ser rechazada.
Es decir que el funcionamiento es el siguiente: cuando un cliente realiza una peticin al JBoss
web, si hay algn thread de procesamiento disponible ser este quien atender el pedido, en caso de
estar todos ocupados el pedido ser encolado hasta que alguno se libere, si dicha cola se encuentra
llena, es decir que la cantidad de pedidos encolados es igual al valor del atributo acceptCount, el
nuevo pedido ser rechazado.
Estos atributos, que definen el comportamiento del control de acceso concurrente del conector,
pueden ser accedidos y modificados a travs de JMX por tal motivo son los atributos ajustados en la
accin correctiva, es decir las entradas de control del sistema.
5.2.1 - Controlador
La estrategia de control aplicada no es ms que una simple mquina de estados que traslada al
JBoss entre dos estados distintos, uno denominado estado saturado o sobrecargado y que ocurre
cuando el porcentaje de Heap Utilizado (HU) o el porcentaje de CPU utilizada cruzan los umbrales
de saturacin (us) y el otro denominado estado normal que es cuando ambas mtricas estn por
debajo de los llamados umbrales normales (un) (o de restablecimiento).
102
(a)
HUun
CPUun
Estado
Estado
Saturado
HU, CPU
Estado
Normal
HUus
CPUus
(b)
Figura 47 - Controlador: (a) Mquina de estados. (b) Espacio de estados (con histresis).
En la Figura 47 se muestra dicha mquina de estados, en donde:

HU, CPU: Son los valores del % de memoria Heap utilizada y el % de uso de CPU en el
estado normal, respectivamente.
HU', CPU': Son los valores del % de memoria Heap utilizada y el % de uso de CPU en el
estado saturado, respectivamente.
PAR: Representa los valores de las entradas de control: PARi={maxThreadi,acceptCounti},
con i {n=normal, s=saturado}.
HUus, CPUus: Umbrales a partir de los cuales se considera al sistema en estado saturado.
HUun, CPUun: Umbrales de restablecimiento a partir de los cuales se considera al sistema
nuevamente en estado normal.
103
5.3 - Esquema de la prueba de concepto

En esta seccin se explicar las configuraciones que son necesarias realizar en cada uno de los
elementos de la infraestructura para la ejecucin de la prueba de concepto descripta en el punto
anterior. Tambin se mostrar en detalle la estrategia de control aplicada.
5.3.1 - Nagios
Nagios fue configurado para que recolecte las mtricas deseadas cada 15 segundos.
Para obtener el porcentaje de uso de CPU del proceso JVM se utiliz un plugin llamado
check_process_resources el cual est escrito en script shell y permite conocer el porcentaje de uso de
memoria y de CPU de un determinado proceso local a Nagios, es decir de un proceso ejecutndose en
la misma mquina que este ltimo. Este plugin, que se obtiene de [CHECKPROCPLUGIN], puede ser
utilizando en conjunto con check_by_ssh, para monitorear un proceso remoto, es decir uno que se
encuentre ejecutndose en una maquina distinta a la cual se encuentra el Nagios, ver
[CHECKSSHPLUGIN] para ms detalle de cmo se realiza.
Al plugin check_process_resources se le debieron realizar las siguientes modificaciones:
Se le agreg la informacin de performance data.
Se le agreg un parmetro opcional que recibe un texto que es utilizado internamente para filtrar
el proceso deseado en caso de que exista ms de uno con el mismo nombre indicado. Por
ejemplo si se tienen dos procesos JAVA ejecutndose en la misma mquina, se le puede pasar
como valor de este parmetro el texto JBoss para identificar la JVM en la cual se est ejecutando
el JBoss. Dicho parmetro agregado es el -f.
El plugin original utilizaba el comando de Linux ps [PSLINUXCOMMAND] para obtener el
porcentaje de uso de CPU del proceso, el problema con dicho comando es que el valor devuelto
no es en tiempo real ya que lo calcula como el tiempo de uso de CPU dividido por el tiempo
durante el cual el proceso se encuentra en ejecucin. De esta forma, en los casos de picos de
carga este hecho no es reflejado rpidamente en el valor devuelto o en caso de estabilizarse
nunca lo har. Por lo tanto se lo cambio para que utilice el comando top [TOPLINUXCOMMAND]
el cual da informacin de uso de memoria y CPU en tiempo casi real, ya que utiliza la
informacin desde la ltima actualizacin que por defecto es de un segundo.
En lo que respecta al porcentaje de memoria Heap utilizada, no hay forma de obtener dicha
mtrica en forma directa, lo que se hizo fue obtener mediante JMX la cantidad de memoria Heap libre
y la total, y se envan estos valores al sistema de control para que este realice el clculo
correspondiente.
Adems de las mtricas correspondientes a las salidas controladas del sistema, se configur a
Nagios para monitorear las variables de control, acceptCount y maxThreads y los parmetros del
conector currentThreadsBusy y currentThreadsCount. Para as tenerlas disponibles y poder observar
cmo se van modificando sus valores en el transcurso del tiempo, pudiendo de esta forma graficarlos y
correlacionarlos en el tiempo con las otras mtricas recolectadas.
104
Todas las mtricas anteriormente mencionadas fueron configuradas en Nagios a travs de los
servicios mostrados en el Listado 4, los cuales a su vez utilizan los comandos mostrados antes en el
Captulo 4: Solucin Propuesta e Implementacin - 4.2.2 - Recoleccin de mtricas.
Listado 4 - Servicios configurados para la recoleccin de las mtricas.
#Memoria heap total
define service{
use
tesis-service
host_name
localhost
service_description
jboss-heap-total
check_command
check_jmx_simple!service:jmx:rmi:///jndi/rmi://localhost:9003/jmxrmi!jboss.system:type=ServerInfo!TotalMemory!0!0
}
#Memoria heap libre
define service{
use
tesis-service
host_name
localhost
service_description
jboss-heap-free
check_command
check_jmx_simple!service:jmx:rmi:///jndi/rmi://localhost:9003/jmxrmi!jboss.system:type=ServerInfo!FreeMemory!0!0
}
#Valor de acceptCount
define service{
use
tesis-service
host_name
localhost
service_description
jboss-accept-count
check_command
check_jmx_simple!service:jmx:rmi:///jndi/rmi://localhost:9003/jmxrmi!jboss.web:type=Connector,port=8080,address=%
2F0.0.0.0!acceptCount!0!0
}
#Valor de maxThreads
define service{
use
tesis-service
host_name
localhost
service_description
jboss-maxTrheads
check_command
check_jmx_simple!service:jmx:rmi:///jndi/rmi://localhost:9003/jmxrmi!jboss.web:type=ThreadPool,name=http-0.0.0.08080!maxThreads!0!0
}
#Porcentaje de uso de CPU
define service{
use
tesis-service
host_name
localhost
service_description
jboss-cpu-used
check_command
check_process_resources_local!java!JBoss!cpu!50!70!org.jboss.Main
105
#Cantidad de threads ocupadas

define service{
use
tesis-service
host_name
localhost
service_description
jboss-currentTrheadsBusy
check_command
check_jmx_simple!service:jmx:rmi:///jndi/rmi://localhost:9003/jmxrmi!jboss.web:type=ThreadPool,name=http-0.0.0.08080!currentThreadsBusy!-1!-1
}
#Cantidad de threads creadas
define service{
use
tesis-service
host_name
localhost
service_description
jboss-currentTrheadsBusy
check_command
check_jmx_simple!service:jmx:rmi:///jndi/rmi://localhost:9003/jmxrmi!jboss.web:type=ThreadPool,name=http-0.0.0.08080!currentThreadCount!-1!-1
}
5.3.2 - BrainyPDM
En lo que respecta a BrainyPDM, las configuraciones que son necesarias realizar para la
ejecucin de la prueba de concepto comprenden a los MBeans disponibles para la actuacin sobre el
JBoss y a los transmisores y actuadores utilizados para la comunicacin de las mtricas recolectadas y
de la accin correctiva a aplicar, respectivamente.
5.3.2.1 - Configuracin de los MBeans

Para poder aplicar las acciones de control utilizadas en los distintos casos de test realizados, las
cuales consisten en modificacin de los valores de las entradas de control, es decir de los parmetros
acceptCount y maxThreads del JBoss Web Server y el forzado de la ejecucin del Garbage Collector.
Se debieron configurar, en el archivo mbeans-def.xml, los MBeans mostrados en el Listado 5.
El jbosswebConn es el utilizado para la modificacin del parmetro acceptCount, mientras que
el configurado con id jbosswebTPool es el que se utiliza para la modificacin de maxThreads, y por
ltimo el javalangMemory es el que fuerza la ejecucin del Garbage Collector. Como se puede
observar en el mencionado Listado, los dos primeros tienen configurado un mtodo del tipo s, ya se
trata de la modificacin de atributos, mientras que el ltimo el mtodo es del tipo o, es decir que se
trata de la ejecucin de una operacin.
Listado 5 - Configuracin de los MBeans utilizados en la prueba de concepto
<mbean id="jbosswebConn" name="jboss.web:type=Connector,port=8080,address=%2F0.0.0.0">
<metodos>

<metodo id="acceptCountAttr" name="acceptCount" type="s">
<signatura>
<class>int</class>
</signatura>
106
</metodo>
</metodos>
</mbean>
<mbean id="jbosswebTPool" name="jboss.web:type=ThreadPool,name=http-0.0.0.0-8080">
<metodos>

<metodo id="maxThreadsAttr" name="maxThreads" type="s">
<signatura>
<class>int</class>
</signatura>
</metodo>
</metodos>
</mbean>
<mbean id="javalangMemory" name="java.lang:type=Memory">
<metodos>

<metodo id="gc" name="gc" type="o">
</metodo>
</metodos>
</mbean>
5.3.2.2 - Configuracin de los transmisores

Para que las mtricas recolectadas puedan ser enviadas al sistema de control utilizado, es decir
a PowerDEVS, se configur en el archivo transmisores-def.xml el transmisor TransmisorByUDP, tal
como se muestra en el Listado 6Error! Reference source not found.. En donde puede verse que se lo
configur para que solamente transmita las mtricas interesadas: JBoss.cpu, FreeMemory y
TotalMemory.
Listado 6 - Configuracin del transmisor TransmisorByUDP
<transmisor>
<name>powerdevsUDP</name>
<className>org.brainypdm.modules.control.transmisores.TransmisorByUDP</className>
<description>
<![CDATA[
Transmisor que enva las mtricas a travs de un socket mediante UDP. Se comunica con PowerDEVS
]]>
</description>
<idle>false</idle>
<hosts>
<host name="localhost">
<services>
<service name="jboss-cpu-used">
<metrics>
<metric name="JBoss.cpu" />
</metrics>
</service>
107
<service name="jboss-heap-free">
<metrics>
<metric name="FreeMemory" />
</metrics>
</service>
<service name="jboss-heap-total">
<metrics>
<metric name="TotalMemory" />
</metrics>
</service>
</services>
</host>
</hosts>
<labelType>M

</labelType>
<params>
<param>
<name>ip</name>
<value>127.0.0.1</value>
</param>
<param>
<name>port</name>
<value>8000</value>
</param>
</params>
</transmisor>
5.3.2.3 - Configuracin de los actuadores

Por ltimo en el Listado 7 se muestra la configuracin realizada al actuador ActuadorByUDP
en el archivo actuadores-def.xml, en donde se indica la URL del sistema a controlar, la del JBoss en
nuestro caso y el puerto en donde se debe quedar esperando por las indicaciones del sistema de control.
Listado 7 - Configuracin del actuador ActuadorByUDP
<actuador>
<name>ActuadorPpal</name>
<description>
<![CDATA[ Actuador que se queda escuchando en un socket esperando indicaciones.
</description>
<className>org.brainypdm.modules.control.actuadores.ActuadorByUDP</className>
<idle>false</idle>
<url>localhost</url>
<params>
<param>
108
]]>
<name>port</name>
<value>10500</value>
</param>
</params>
</actuador>
5.3.3 - PowerDEVS
Se implementaron dos controladores llamados control simple y control con ejecucin del
Garbage Collector (control con gc). Ambos tienen el mismo esquema y slo difieren en las acciones
correctivas que aplican. La Figura 48 muestra el diagrama en bloques de los mismos, en l se puede
observar tres modelos atmicos cuyas funcionalidades son bien especficas: el sensor, quien es el que
recibe las mtricas; el procesador quien es el atmico que contiene la lgica de control y el efector
quien es el encargado de aplicar la accin de actuacin, cuando el procesador as lo determina. En
dicha figura tambin se muestran las pantallas de configuracin de los parmetros de cada uno de
ellos. En los prximos prrafos se explica el funcionamiento de estos tres atmicos.
Figura 48 - Diagrama en bloques de la estrategia de control utilizada
Antes de entrar en detalle con cada uno de los atmicos del modelo cabe recalcar un
funcionamiento comn a los tres: en todos existe una variable llamada sigma la cual mide el tiempo
que resta hasta que se dispare la transicin interna del modelo atmico. De esta forma cuando se quiere
que un determinado atmico ejecute su transicin interna inmediatamente se debe colocar sigma en
cero, y cuando se quiere que el modelo no cambie nunca de estado por s mismo (a menos que ingrese
un evento externo) se coloca sigma en infinito (equivale a pasivar el modelo, y en la prctica se
logra asignando a sigma un valor muy grande).
Adems es importante destacar que la lgica individual e integral de los tres modelos que se
109
describirn a continuacin fueron sometidos a verificacin mediante ensayos ad-hoc desacoplados

del sistema real a controlar (simulacin en tiempo virtual, standalone), y una vez que el resultado fue
satisfactorio, se procedi a su validacin acoplada al sistema real (simulacin en tiempo real, tipo
System-In-The-Loop) mediante diversos casos de test en 5.4 - Casos de prueba.
5.3.3.1 - Sensor
El sensor es el mismo para los dos controladores implementados y es el encargado de recibir las
mtricas de parte de BrainyPDM, para ello se utiliz el mecanismo agregado a PowerDEVS que
permite a los atmicos registrarse como interesados en ser notificados de la recepcin de mensajes a
travs de un determinado puerto.
En el Listado 8 se detalla la descripcin de las funciones de inicializacin del modelo (init), la
de avance de tiempo (ta), la de transicin interna, la de transicin externa y la de salida del Sensor,
en el Anexo B: Cdigo Fuente de los Modelos DEVS (B.1 - Sensor) se muestra el cdigo fuente
completo de dichas funciones.
En la funcin init el sensor se registra, mediante la funcin RequestNET, para ser notificado
de mensajes recibidos a travs del puerto pasado como parmetro y se coloca un valor alto en la
variable sigma.
Cuando se recibe un mensaje a travs del puerto indicado, se ejecuta la funcin de transicin
externa en donde se verifica que el mensaje sea del formato esperado y de ser as se guarda el mensaje
recibido en una variable global y luego se coloca un cero en la variable sigma, forzando de esta forma
a que se ejecute la transicin interna del sensor.
En la funcin de salida, recordemos que dicha funcin se ejecuta cuando se produce una
transicin interna, se genera un evento de salida que contiene el mensaje recibido.
Listado 8 - Descripcin de las funciones del modelo Sensor
Inicializacin del
Modelo:
Funcin de Transicin
Externa:
Inicializar y subscribirse al SOCKET configurado (RequestNET(puerto,...)

Pasivar el Modelo (sigma->infinito)
Validar el mensaje recibido
Si el formato del mensaje es vlido entonces:
Copiar el mensaje en una variable global
Forzar una transicin interna (sigma->0)
Funcin de Transicin
Interna:
Funcin de Salida:
Funcin de Avance de
Tiempo:
Enviar el mensaje recibido como evento de salida

Aplicar sigma
5.3.3.2 - Procesador
El procesador es donde se encuentra la lgica de control propiamente dicha. Este atmico
recibe siete parmetros: los umbrales de saturacin, los umbrales de restablecimiento, el valor de
110
acceptCount y de maxThread en rgimen normal y el valor de maxThread para el estado saturado. En

la funcin init se reciben dichos parmetros y se los coloca en variables globales del atmico.
Tal como se describi en la seccin anterior, cuando el sensor recibe un mensaje genera un
evento externo que contiene el mensaje recibido, dicho evento es enviado al procesador provocndose
as la ejecucin de una transicin externa en el mismo. Entonces el procesador se fija si el mensaje se
corresponde con alguna de las mtricas esperadas (Jboss.cpu, FreeMemory o TotalMemory) si no lo es
no hace nada, si la mtrica recibida es FreeMemory o TotalMemor y ya se encuentra en condiciones de
calcular el porcentaje de uso de memoria Heap lo calcula, caso contrario guarda la mtrica recibida
hasta estar en condiciones de hacerlo (es decir hasta haber obtenido ambos valores, memoria Heap
libre y Heap total).
Cuando el procesador tiene ambas mtricas, porcentaje de uso de CPU y de memoria Heap, los
compara con los umbrales pasados como parmetro, si alguno de los dos supera el umbral de
saturacin establecido y an no se aplic la accin de control, se colocan en las variables globales los
nuevos valores para las entradas de control, acceptCount y maxThread. Estos valores son 1 para el
acceptCount y el pasado como parmetro para maxThread.
Si los porcentajes de uso estn ambos por debajo de los respectivos umbrales de
restablecimiento y ya se haba aplicado la accin de control, es decir que el JBoss se encuentra
trabajando en modo restringido, se tienen que volver a poner los valores de acceptCount y maxThread
que se corresponden con el rgimen de trabajo normal, los cuales son pasados como parmetro.
Si es necesario actuar sobre el sistema, ya sea para ponerlo en rgimen normal como en
rgimen saturado, se coloca un cero en la variable sigma para as forzar a que se ejecute una transicin
interna en el atmico Procesador, generando de esta forma un evento de salida que enva la orden de
actuacin al efector, tal como se puede ver en la funcin de salida del procesador. Dicha funcin vara
levemente entre ambos controladores implementados, debido a que en el control con gc
adicionalmente a la informacin de actuacin que se le enva al Efector se le indica el estado al cual se
pasar al JBoss.
En el Listado 9 se muestra la descripcin de las funciones de inicializacin del modelo (init), la
de avance de tiempo (ta), la de transicin interna, la de transicin externa y la de salida del
Procesador, en el Anexo B: Cdigo Fuente de los Modelos DEVS (B.2 - Procesador) se muestra el
cdigo fuente completo de dichas funciones.
Listado 9 - Descripcin de las funciones del modelo Procesador
Inicializacin del
Modelo:
Inicializar las variables globales

freeHEAP->0
totalHEAP->0
CPU->0
HEAP->0
Funcin de Transicin
Externa:
Si la mtrica recibida es FreeMemory entonces:

freeHEAP->valor_recibido
Si ya se recibi el nuevo valor de totalHEAP entonces:
Se calcula el nuevo porcentaje de HEAP ocupado:
111

HEAP->100-(freeHEAP*100.00/totalHEAP)
Si la mtrica recibida es TotalMemory entonces:

totalHEAP->valor_recibido
Si ya se recibi el nuevo valor de freeHEAP entonces:
Se calcula el nuevo porcentaje de HEAP ocupado:
HEAP->100-(freeHEAP*100.00/totalHEAP)
Si la mtrica recibida es CPU entonces:
CPU->valor_recibido
Si ya se tienen los nuevos valores de CPU y de HEAP entonces:
Si algunos de los valores supera el umbral de saturacin y el estado actual es NORMAL:
Fijar los valores de las variables de control con los valores en estado SATURADO:
accept_count->1
max_threads->valor_mt_estado_SATURADO
Si el SISTEMA se encuentra en estado SATURADO y los valores de CPU y HEAP estn por
debajo de los umbrales de restablecimiento entonces:
Fijar los valores de las variables de control con los valores en estado NORMAL:
accept_count->valor_ac_estado_NORMAL
max_threads->valor_mt_estado_NORMAL
Funcin de Transicin
Interna:
Funcin de Salida:
Funcin de Avance de
Tiempo:
Generar un evento de salida con los nuevos valores de las variables de control (y para el caso del
controlador con gc con el nuevo estado del sistema).
Aplicar sigma
5.3.3.3 - Efector
Por ltimo se tiene el efector que es quien le enva la orden de actuacin al actuador cuando el
procesador as lo determina. Este atmico recibe como parmetros el puerto y la IP que definen la
direccin a la cual se debe enviar la orden de actuacin.
Cuando el efector recibe un evento externo enva a la direccin y puerto definidos, un mensaje
indicando el identificador los MBeans y de los mtodos de cada uno de ellos que se requiere ejecutar,
junto con los valores a colocar en caso que corresponda. Para esto utiliza la funcin sendNET la cual
fue una de las funcionalidades agregadas a PowerDEVS.
La funcin de transicin externa de este atmico difiere entre los dos controladores
implementados ya que en el control con gc adems de colocar los nuevos valores para las variables de
control, si lo que se produjo fue un cambio al estado saturado, se fuerza la ejecucin del Garbage
Collector. En el Listado 10 se muestran las descripciones de las funciones de inicializacin del modelo
(init), la de avance de tiempo (ta), la de transicin interna, la de transicin externa y la de salida del
Efector, en el Anexo B: Cdigo Fuente de los Modelos DEVS (B.3 - Efector) se muestra el cdigo
fuente completo de dichas funciones.
Listado 10 - Descripcin de las funciones del modelo Efector
112

Inicializacin del Modelo
Funcin de Transicin
Externa
Funcin de Transicin
Interna:
Funcin de Salida:
Enviar el evento de salida con la indicacin de actuacin hacia el SOCKET configurado

(sendNET(puerto,ip,...))
Funcin de Avance de
tiempo:
Aplicar sigma
5.4 - Casos de prueba

Los distintos casos de prueba realizados y presentados en la esta seccin fueron hechos en un
JBoss 5.1.0.GA utilizando la aplicacin Dukes Bank que emula operaciones bancarias online, provista
por Sun Microsystems como parte del JEE Tutorial [SUNJEETutorial]. Con el fin de generarle carga a
la aplicacin y por ende al JBoss, se utiliz el JMeter 2.6 [JMETER], herramienta muy utilizada para
la realizacin de test de carga.
5.4.1 - Caso de prueba 1

Para este primer caso de prueba se utiliz un script de JMeter conteniendo las siguientes
transacciones: el login a la aplicacin, un listado de las cuentas disponibles, consultas de los detalles de
dos cuentas conteniendo una gran cantidad de datos, una extraccin de una de las cuentas y el logout.
Siendo los parmetros del JMeter los mostrados en la Figura 49.
113
Poblacin total de usuarios: 20

Tiempo de subida: 10 minutos
Duracin del test: 30 minutos
Think Time entre
pedidos consecutivos:
o Distribucin Gaussiana
o Valor medio: 300 ms.
o Desviacin estndar: 100 ms.
Figura 49 - Diseo de la carga de la prueba 1 y su poblacin de usuarios concurrentes
Es decir que JMeter le gener carga a la aplicacin durante 30 minutos simulando el acceso de
20 usuarios concurrentes ejecutando las transacciones indicadas. Lo usuarios se fueron incorporando
progresivamente durante los primeros 10 minutos del test hasta alcanzar la poblacin de rgimen.
5.4.1.1 - Caso de Test 0 (Lnea de base)

En los grficos de las Figura 50 y Figura 51 muestran el comportamiento del sistema bajo la
carga descripta y a lazo abierto, es decir sin la utilizacin de la presente plataforma. En la Figura 50
(a) se observa que el consumo de CPU se mantiene por encima del 60% durante toda la prueba, y en
Figura 50 (b) que el porcentaje de Heap libre oscila entre el 56% y el 10% aproximadamente
evidenciando la accin del Garbage Collector de la JVM en dos ocasiones. En los grficos de la
Figura 51 se muestran la cantidad de threads creados (currentThreadCount) y la cantidad de ocupados
(currentThreadBusy) durante la ejecucin del test, donde se observa que los mismos van aumentando
progresivamente a medida que va aumentando la cantidad de usuarios conectados al sistema, hasta
llegar a la poblacin en rgimen.
114
Figura 50 - Prueba 1: Caso de Test 0 (ejecucin sin la plataforma). (a) Consumo de CPU (b) Memoria Heap
libre
Figura 51 - Prueba 1: Caso de Test 0 (ejecucin sin la plataforma). (a) Cantidad de threads creados. (b)
Cantidad de threads ocupados
115
En el marco del escenario de prueba presentado se considera que un uso de CPU superior al
60% es una indicacin de sobrecarga de JBoss. Con el fin de mantener ese porcentaje en valores
menores, se realizaron dos casos de test exploratorios aplicando la plataforma desarrollada en el
presente trabajo, utilizando distintos parmetros y lgicas del control y aplicndole al sistema la misma
carga que la aplicada en la Lnea de base.
5.4.1.2 - Caso de Test 1

En este primer test se utiliz el controlador simple cuyos parmetros son los siguientes:
Umbrales:
Saturacin:
HUus=60%
CPUus=55%
Restablecimiento:
HUun=55%
CPUun=50%
Variables de control: Estado normal:
PARn:
maxThreadn=80
Estado saturado:
acceptCountn=10
PARs:
maxThreads=5 acceptCounts=1
En este caso el JBoss entr en su estado saturado en dos oportunidades, tal como se observa en
los grficos de las Figura 52 y Figura 53 donde se muestran debajo del eje de tiempo barras
horizontales en color naranja claro para los perodos transcurridos en Estado Normal, y en color
naranja oscuro para los correspondientes al Estado Saturado.
En particular en el grfico de la Figura 52 (a), se puede ver como en el primer perodo se
observa un consumo de CPU menor al 60%, tal como se esperaba, mientras que en el segundo se
obtiene un comportamiento similar al caso del sistema a lazo abierto. Esta asimetra no es deseable y
ocurre debido a que al regresar al estado normal, luego del primer ciclo en su estado saturado, el
controlador vuelve a subir el valor de la variable maxThread permitiendo al JBoss crear nuevos threads
cuando lo necesita. Sin embargo, cuando dicha variable es restringida nuevamente segundo ciclo en
estado saturado el JBoss no disminuye la cantidad de threads creados para cumplir con la nueva
restriccin, tal como se esperara que ocurra (ver Figura 53 (a)), lo cual es considerado como un
problema de la aplicacin.
En cuanto al consumo de memoria Heap no se observaron diferencias con el comportamiento al
caso sin la plataforma aplicada (Figura 52 (b)).
116
Figura 52 - Prueba 1: Caso de Test 1. (a) Consumo de CPU (b) Memoria Heap libre6
Figura 53 - Prueba 1: Caso de Test 1. (a) Cantidad de threads creados. (b) Cantidad de threads ocupados
En el grfico de la memoria Heap libre los valores de los umbrales estn expresados en trmino de la memoria
ocupada es por eso que el umbral de saturacin se muestra por debajo del umbral de restablecimiento.
117

Para evitar el problema detectado en el caso de test 1, se realiz un nuevo test pero ahora
utilizando el controlador llamado control con gc, es decir que se agreg una accin a la transicin del
estado normal al saturado que fuerza la ejecucin del Garbage Collector para liberar memoria Heap.
Adicionalmente se modificaron los parmetros del control de manera tal que al cambiar de estado no
se modifica el valor de maxThread (i.e., maxThreadn=maxThreads). A continuacin se muestran los
parmetros del control utilizado:
Umbrales:
Saturacin:
HUus=60%
CPUus=50%
Restablecimiento:
HUun=55%
CPUun=45%
PARn:
maxThreadn=5 acceptCountn=10
Estado saturado:
PARs:
maxThreads=5 acceptCounts=1
En este caso hubo mltiples cambios de estado del JBoss, el cual oper durante todo el test
acorde a los objetivos de calidad estipulados, es decir, respetando los umbrales para el consumo de
CPU y el porcentaje de memoria Heap utilizada (Figura 54). Sin embargo, esto sucede en detrimento
de la flexibilidad del control, debiendo mantener siempre un valor bajo (muy restrictivo) para la
cantidad de pedidos posibles de ser atendidos concurrentemente (Figura 55).
118
7
119
5.4.2 - Caso de prueba 2

Para este caso se utiliz una carga variable con el tiempo tal como se muestra en la Figura 56,
en donde se puede ver que inicialmente se tienen 100 usuarios concurrentes los cuales se fueron
incorporando progresivamente durante los primeros 7,5 minutos del test. Estos 100 usuarios cargan a
la aplicacin durante 10 minutos, luego la cantidad de usuarios se reduce a 40 durante los prximos 10
minutos, cuando comienza a incorporarse otros 50 usuarios llegando, luego de 2,5 segundos, a una
nueva poblacin de rgimen de 90 usuarios.
Poblacin total de usuarios: variable entre 40 y 100.

Tiempo de subida inicial: 7,5 minutos
Tiempo de subida intermedio (incorporacin del Grupo de usuarios 3): 2,5 minutos
Duracin del test: 47,5 minutos
Think Time entre pedidos consecutivos:
o Distribucin Poisson.
o Valor medio: 2000 ms.
o Desviacin estndar: 100 ms.
Figura 56 - Diseo de la carga de la prueba 2 y su poblacin de usuarios concurrentes
Para lograr la carga variable descripta se cre un script de JMeter que contiene tres grupos de
usuarios cuyas caractersticas se detallan a continuacin:
120

Grupo de usuario
Grupo Usuarios-1
Caractersticas
Poblacin total de usuarios: 40.
Tiempo de subida: 450 seg.
Duracin: 2850 seg.
Retardo: 0 seg.
Transacciones ejecutadas: login al sistema, listado de
cuentas, consulta de detalles de una cuenta, extraccin,
transferencia, consulta de detalles de una cuenta, logout.
Grupo Usuarios-2

Duracin: 1050 seg.
Retardo: 0 seg.
Transacciones ejecutadas: login al sistema, listado de
cuentas, consulta de detalles de una cuenta, consulta de
detalle de la misma cuenta pero con rango de fecha ms
amplio, extraccin, transferencia, logout.
Grupo Usuarios-3

Duracin: 1200 seg.
Retardo: 1650 seg.
Transacciones ejecutadas: (dem al grupo 1)
5.4.2.1 - Caso de Test 0 (Lnea de base)

En los grficos de las Figura 57 y Figura 58 se muestra el comportamiento del sistema bajo la
carga descripta en la seccin anterior y sin la utilizacin de la plataforma desarrollada. En la Figura 57
(a) se observa que en los perodos de mayor carga, es decir cuando hay 100 y 90 usuarios concurrentes,
el consumo de CPU se mantiene por encima del 50% teniendo intervalos de tiempo donde supera los
60%. Mientras que en la Figura 57 (b) se muestra el comportamiento de la memoria Heap libre, la
misma decrece continuamente desde el 65,94% hasta el 48%, y no se observa la ejecucin del Garbage
Collector. En la Figura 58 se muestran la cantidad de threads creados (a) y de threads ocupados (b). En
el primer grfico se observa que la cantidad de threads creados es de 60 en casi toda la ejecucin del
test.
121
Figura 57 - Prueba 2: Caso de Test 0 (ejecucin sin la plataforma). (a) Consumo de CPU (b) Memoria Heap
libre
Figura 58 - Prueba 2: Caso de Test 0 (ejecucin sin la plataforma). (a) Cantidad de threads creados. (b)
Cantidad de threads ocupados

Al igual que en el caso de prueba anterior, en el contexto del escenario planteado al comienzo
del captulo se considera un porcentaje superior al 60% como una indicacin de carga del JBoss, por lo
tanto se aplic la plataforma aqu presentada para controlarlo y mantener dicho porcentaje en valores
menores. Se utiliz el controlador simple con los siguientes parmetros:
122

Umbrales:
Saturacin:
HUus=60%
CPUus=45%
Restablecimiento:
HUun=55%
CPUun=40%
PARn:
maxThreadn=120
Estado saturado:
acceptCountn=10
PARs:
maxThreads=10
acceptCounts=1
En los grficos de la Figura 59 se muestra el comportamiento del JBoss durante este caso de
test en lo que respecta a las salidas del sistema. En (a) se observa como el consumo de CPU se
mantuvo por debajo del 60% durante el primer perodo en estado saturado, el cual coincide con el
primer ciclo de carga alta. Cuando la cantidad de usuarios concurrentes disminuye, se puede ver como
el sistema alterna entre el estado normal y el saturado, quedndose en este ltimo estado al volver al
aumentar la carga del sistema. En este ltimo caso el consumo de CPU supero los 60% en varias
oportunidades, esto se debe al mismo problema detectado en el caso de test 1 de la prueba 1, cuando el
JBoss se encuentra en el estado normal, el controlador sube el valor de la variable maxThread
permitiendo as que se creen nuevos threads frente al crecimiento de la cantidad de usuarios. De esta
forma, y debido al comportamiento del JBoss ya observado, cuando dicha variable es restringida
nuevamente, no se disminuye la cantidad de threads creados para as cumplir con la restriccin
impuesta por el controlador. Este ltimo comportamiento se muestra en los grficos de la Figura 60, en
(a) se tiene la cantidad de threads creados a lo largo de la duracin del test, mientras que en (b) se
pueden ver cules de estos estn siendo utilizados en cada instante.
En lo que respecta al consumo de memoria Heap, se observa una leve disminucin al aplicar el
controlador y, tal como suceda en el Caso de test base, no se evidencia la ejecucin del Garbage
Collector durante la ejecucin del presente test (Figura 59-(b)).
123
8
124
5.4.3 - Discusin de resultados

En las pruebas realizadas, se logr el objetivo del escenario de prueba, es decir, mantener el
porcentaje de uso de CPU y de memoria Heap dentro de lmites establecidos.
La anomala detectada es frecuente en los productos de software donde el comportamiento real
difiere del esperado segn la documentacin. Esta caracterstica afecta la aplicabilidad de estrategias
de Self-Healing basadas en modelos, y pone de relevancia la importancia de realizar ensayos
preliminares sistemticos para caracterizar la dinmica del sistema. La plataforma desarrollada en el
presente trabajo, facilit considerablemente esta tarea: ya en el Caso de Test 2 de la Prueba 1 se logr
el objetivo deseado mediante un sencillo cambio de parmetro y la inclusin de un comando de
actuacin extra dirigido hacia componentes especficos del sistema controlado (forzado de Garbage
Collector de la JVM), mostrando la flexibilidad de la herramienta.
Si bien no fue parte del foco de los test, debe mencionarse la evolucin de los tiempos de
respuesta de las transacciones en los 3 experimentos. Lo esperado es que con la plataforma aplicada
(cantidad restringida de threads posibles de ser creados) hubiese conexiones rechazadas por timeout y
que aquellas conexiones aceptadas muestren un tiempo de respuesta menor al caso sin la misma. Sin
embargo, no se observaron timeouts y los tiempos de respuesta fueron mayores en los casos en el cual
de aplic la plataforma.
Una explicacin razonable es la dependencia con otros parmetros que afectan el
comportamiento de recepcin de pedidos de JBoss (muy probablemente keep alive timeout) que no
formaron parte del control, y que debern ser investigados.
125
Captulo 6: Conclusiones y Trabajo

Futuro
126
6.1 - Conclusiones
En el presente trabajo se present una plataforma flexible y extensible que permite la
incorporacin de capacidades de Self-Healing a Sistemas de Software. Si bien la misma fue pensada
para ser utilizada en sistemas de tipo Servidor de Aplicaciones JEE y su JVM subyacente, puede ser
aplicada a cualquier sistema que pueda ser administrado a travs de JMX.
Su arquitectura modular basada en plugins accesibles va protocolos de red permite una sencilla
adaptacin y/o remplazo de las tecnologas de monitoreo, control o actuacin, acorde a distintas
necesidades. Esto permite la libre eleccin de diversos enfoques de arquitecturas de Self-Healing,
incluyendo varios sistemas de control cooperando simultneamente y en tiempo real.
Para ofrecer la mayor flexibilidad posible respecto del tipo de modelo usado para definir
criterios de control, se dise una solucin basada en modelado y simulacin en tiempo real.
Los modelos de controladores, cualquiera sea su naturaleza (continuos, a tiempo discreto, a
eventos discretos, o hbridos), se implementan dentro del entorno de modelado y simulacin
PowerDEVS. Esto permite seguir la estrategia conocida como System-In-The-Loop (sistema dentro
del lazo): los modelos son desarrollados, ensayados y verificados mediante simulaciones standalone,
desconectadas del sistema real a controlar (sistema fuera del lazo). Luego, las entradas y salidas del
controlador son redireccionados hacia el sistema real (en nuestro caso, hacia/desde plugins de
monitoreo y actuacin) y son ejecutados en tiempo real (sistema dentro del lazo).
Esta estrategia elimina los riesgos de introducir errores al pasar de la fase de diseo a la fase de
implementacin de cualquier lgica de control que se implemente, ya que el controlador ser
finalmente ejecutado por el mismo motor de simulacin sobre el cual fue desarrollado.
Una particularidad saliente de nuestro diseo es que incorpora naturalmente el enfoque de SelfHealing basado en Ingeniera de Control, ya que PowerDEVS incluye de forma nativa todos los
algoritmos necesarios para el modelado de controladores mediante ecuaciones en diferencias y/o
ecuaciones diferenciales. Otras formas de definir modelos, como por ejemplo mediante autmatas
finitos, mquinas de estado, etc. son implementados de manera trivial en el contexto de PowerDEVS.
La herramienta construida fue aplicada exitosamente para desarrollar un controlador sencillo
del tipo on-off, cuyo diseo se bas en ejercicios previos realizados, tambin con la herramienta ac
presentada, para ganar conocimiento de la dinmica del sistema (el JBoss 5.1.0.GA + JVM) y sus
respuestas ante acciones de control.
Al aplicar la herramienta al servidor de aplicaciones JBoss, surgi un problema relativamente
comn: el comportamiento real del Sistema de Software difiere del esperado segn su documentacin,
y no se consta de un modelo lgico-matemtico que describa su dinmica. Este problema no es menor,
y representa uno de los principales escollos a enfrentar al pretender aplicar capacidades de SelfHealing a Sistemas de Software. Su superacin fue lograda exitosamente mediante ejercicios de prueba
y error tendientes a caracterizar heursticamente la dinmica del sistema y ajustar los parmetros del
controlador acorde al conocimiento adquirido.
La plataforma desarrollada puede ser aplicada en sistemas industriales (i.e. en sistemas no
acadmicos) debido a que utiliza JMX tanto para el monitoreo como para la actuacin. JMX es una
127
tecnologa estndar parte de la plataforma JEE, diseada nativamente para ser utilizada en aplicaciones
productivas de alta performance, previendo bajos niveles de intrusividad.
Las principales limitaciones de aplicacin estn dadas por la naturaleza del sistema a controlar,
acorde a lo que permita monitorear y a los parmetros que exponga para poder ejercerle acciones de
control en tiempo real.
6.1.1 - Sntesis de aportes

La plataforma desarrollada posibilita:
Incorporar capacidades de Self-Healing a Sistemas de Software, ya sea utilizando:
o Ingeniera de Control: mediante el entorno PowerDEVS incorporado.
o Cualquier otra tcnica que se desee: mediante la arquitectura basada en plugins
accesibles mediante red.
Realizar investigaciones sobre Self-Healing y Autonomic Computing.
Analizar la dinmica de los Sistemas de Software, mediante ensayos y estudios de su
funcionamiento ante cambios de parmetros en tiempo real.
o Detectar oportunidades no triviales de mejora de la calidad.
Ejecutar directamente los modelos diseados, en tiempo real, sobre simuladores en modo
System-In-The-Loop.
Disear controladores hbridos permitiendo su despliegue en ambientes productivos con
mnimos esfuerzos.
Disear modelos multi-formalismo en una nica plataforma basada en eventos discretos: e.g.
mquina de estados, redes de petri, ecuaciones diferenciales, etc.
Estabilizar puntos de operacin planificados, acordes a objetivos de calidad definidos.
o Estabilizar puntos de operacin de emergencia ante determinadas situaciones.
6.1.2 - Produccin cientfica

Como producto de los resultados obtenidos en la presente Tesis se confeccion el artculo
cientfico [Galache & Castro, 2012] (ver Anexo C:), el cual fue presentado en el simposio ASSE 2012
(13th. Argentine Symposium on Software Engineering), 41 JAIIO (Jornadas Argentinas de
Informtica).
En [Patikirikorala et al., 2012] se encuentra el relevamiento ms actual acerca de diseos de
sistemas de auto-adaptacin utilizando enfoques de Ingeniera de Control (ms de 160 publicaciones
analizadas). En oportunidad de una comunicacin personal con los autores durante su presentacin en
la 34th. International Conference on Software Engineering (ICSE 2012, Zurich, Suiza) los mismos
confirmaron que en su relevamiento no encontraron antecedentes de aplicacin de modelado y
simulacin tipo System-In-The-Loop (ver Seccin 4.4 - Control mediante Modelos en Tiempo Real)
como el presentado en [Galache & Castro, 2012].
128
En su taxonoma, la categora Validacin (de los modelos de control) se subdivide en 2

subcategoras mutuamente excluyentes: mediante Simulacin o mediante Caso de Estudio. Ningn
trabajo relevado combina simultneamente, en una misma herramienta, la capacidad de someter a
prueba un modelo primero mediante Simulacin, y luego, inmediatamente, mediante la conexin
directa del mismo modelo a un Caso de Estudio en tiempo real.
6.1.3 - Clasificacin segn la Taxonoma de Koopman

En la Seccin 2.3.2 - Elementos de los Sistemas Self-Healing se present una taxonoma para
la descripcin de los elementos que constituyen los sistemas Self-Healing.
A continuacin utilizaremos las categoras all presentadas para describir la plataforma
desarrollada en la presente Tesis y en particular el Caso de Prueba mediante el cual fue ensayada.
Categora
Taxonmica
MODELO
DE
DEFECTOS
RESPUESTA
DEL
SISTEMA
Plataforma
Caso de Prueba
Al tratarse de plataforma para aplicacin de

mecanismos de Self-Healing en general y no
de un mecanismo en particular no es posible
describir a priori a cuales defectos ser capaz
de sobreponerse el sistema controlado y del
mecanismo de Self-Healing elegido.
El mecanismo de Self-Healing incorporado

fue diseado para que tolere la existencia de
una carga de trabajo mayor que para la cual
fue diseado el sistema o sistemas que se
ejecutan en el JBoss controlado.
Lo que s puede asegurarse es que sea cual

sea dicho mecanismo en todos los casos
quien se encarga de detectar si existe alguna
anomala en el sistema controlado es la
plataforma, sin exigir que se le adiciones
capacidades nuevas al sistema original.
En lo que respecta a la deteccin de los
defectos, la misma se realiza mediante el
chequeo del sistema a travs de los
monitores, i.e. componentes externos al
mismo. Para realizar dicho testeo, se utilizan
tcnicas no intrusivas ya que se realiza
mediante el estndar JMX.
Sin la existencia de este mecanismo, JBoss

podra degradarse y dejar de prestar
servicios o seguir funcionando pero con
tiempos de respuesta inadmisiblemente
lentos.
Como respuesta ante la presencia de un

defecto se activa un mecanismo preventivo,
i.e. se dispara cuando las mtricas cruzan
los umbrales que se consideran que pueden
provocar la degradacin del JBoss.
En lo que respecta a las dems caractersticas

de esta categora, son especficas del
mecanismo que se quiera aplicar.
COMPLETI
TUD DEL
SISTEMA
Los aspectos evaluados en esta categora

dependen del sistema al cual se aplique la
plataforma y no de esta ltima. Respecto a la
evolucin del sistema, la plataforma no se ve
afectada mientras el sistema a controlar siga
exponiendo la misma informacin y los
mismos parmetros que permitan afectar su
funcionamiento en tiempo real.
129
Se tuvo un claro ejemplo de como el

mecanismo de Self-Healing se ve afectado
por la falta de conocimiento de la dinmica
del sistema, es el caso de descripto en 5.4.3
- Discusin de resultados. Ante dicha
situacin, la plataforma permite una
flexible adaptacin como se vio durante el
caso de test: bast con un cambio de valor
para las variables de control y el agregado
de una accin durante la transicin al estado
saturado.
CONTEXTO
DEL
SISTEMA
El mecanismo de Self-Healing se aplica al

sistema como un todo, en el sentido de que se
lo monitorea y se acta sobre el mismo
vindolo como un solo componente.
El objetivo de la herramienta es que no exista
intervencin humana en la aplicacin del
mecanismo de Self-Healing.
El mecanismo de Self-Healing se aplic al

JBoss y la JVM sobre la cual se ejecuta. Si
bien la accin de actuacin se realiza sobre
el JBoss, las salidas controladas involucran
a la JVM.
6.2 - Trabajo Futuro

Los pasos a seguir abarcan distintos aspectos.
Por un lado en las pruebas de conceptos realizadas se utiliz como controlador una sencilla
mquina de estado cuyos parmetros surgieron de ensayos preliminares sobre la dinmica del sistema.
El paso siguiente es utilizar la plataforma para aplicar tcnicas avanzadas de identificacin de
sistemas, obtener modelos matemticos del sistema ensayado, y a partir de ellos disear controles
avanzados utilizando tcnicas de la Teora de Control, tal como hicieron los autores del trabajo 3.2.4 Teora de control aplicada a un servidor Web mencionado en la seccin 3.2 - Trabajos previos
relevantes.
Por otro lado, se quiere avanzar sobre la posibilidad de regular el pool de threads de
procesamientos mediante JVMTI, para subsanar la anomala encontrada en el comportamiento del
JBoss. Se buscar combinar las tecnologas JVMTI y JMX para poder eliminar los threads sobrantes
que quedan inactivos al disminuir el valor de la variable de control maxThreads, cosa que no pudo
lograrse debido a una anomala en la aplicacin.
Otra lnea de trabajo a seguir es el estudio acerca de la manera de integrar el framework Arco
Iris con la herramienta desarrollada, de manera tal de poder aplicar otro enfoque de sistemas SelfHealing, comparar resultados y eventualmente combinar simultneamente estrategias basadas en
modelos de arquitecturas con estrategias basadas en modelos matemticos.
Asimismo es importante caracterizar los lmites operativos propios de la plataforma. Por
ejemplo, se puede realizar un estudio de las frecuencias mximas alcanzables en la recepcin de
mtricas de monitoreo y de envo de eventos de control. Estos lmites estn fijados por las decisiones
de diseo que se tomaron (e.g., utilizar JMX, Nagios, sistema de plugins, simulador en tiempo real
PowerDEVS, etc.) e imponen una cota superior a las dinmicas que son controlables,
independientemente del sistema a controlar. Es decir, se trata de una caracterstica muy relevante a la
hora de considerar tempranamente la viabilidad de aplicar o no nuestra plataforma a un problema en
particular.
130
Anexo A: Manual de instalacin
131
A.1 - Compilacin
Antes de proceder con la instalacin de la plataforma aqu presentada, se deben compilar y
generar los archivos JAR de los siguientes componentes que conforman la misma y que fueron
modificados y adaptados para poder formar parte de ella. Para poder generarlos se debe tener instalado
el utilitario apache-ant, el cual puede ser obtenido de [ANT].
cliente-jmx: componente creado para acceder a los MBeans, es utilizado por BrainyPDM para
la aplicacin de la accin correctiva. Para generar el archivo JAR de este componente hay que
ubicarse dentro de la carpeta principal del mismo (cliente-jmx) y ejecutar el siguiente comando:
ant jar.
check_jmx: plugin de Nagios utilizado para la recoleccin de las mtricas del JBoss y de la
JVM. Para generar el archivo JAR se debe ejecutar ant all estando ubicados dentro de la carpeta
que contiene el cdigo modificado del plugin, check_jmx. Este comando generar dos archivos,
check_jmx y jmxquery.jar.
BrainyPDM: aplicacin Java utilizada como actuador. Est compuesta por varios mdulos,
algunos de los cuales fueron modificados mientras que otros fueron creados exclusivamente
para adicionarle funcionalidad necesaria para la plataforma presentada en este trabajo. Para
generar todos los archivos JAR de estos mdulos modificados o agregados, hay que ubicarse
dentro de la carpeta build que se encuentra dentro del directorio principal del componente, y
ejecutar ant all-jars. Este comando generar los siguientes archivos:
o brainypdm-actuadores-1.0.1.jar: mdulo agregado que contiene los actuadores
disponibles, actualmente slo contiene el ActuadorByUDP creado para utilizar en la
prueba de concepto realizada.
o brainypdm-modules-commons-1.0.2.jar y brainypdm-commons-1.0.2.jar: contienen
funcionalidad utilizada por todos los mdulos de BrainyPDM.
o brainypdm-control-1.0.1.jar: mdulo agregado que contiene la funcionalidad principal
que permite que BrainyPDM pueda funcionar como actuador y sensor de la plataforma
desarrollada.
o brainypdm-main.jar y brainypdm-core-1.0.2.jar: contienen la funcionalidad principal
de BrainyPDM.
o brainypdm-nagios-1.0.2.jar: contiene la funcionalidad necesaria para la comunicacin
con el Nagios.
o brainypdm-plugins-1.0.2.jar: contiene los plugins disponibles que procesan la
informacin proveniente de Nagios.
o brainypdm-transmisores-1.0.1.jar: mdulo agregado que contiene los transmisores
disponibles, actualmente slo contiene el TransmisorByUDP creado para utilizar en la
prueba de concepto realizada.
132
A.2 - Instalacin
Una vez compilados y generados los componentes necesarios podemos proceder a la
instalacin de todos los elementos que forman parte de la plataforma desarrolla.
Si bien el desarrollo de la plataforma fue pensado para poder ser utilizada en cualquier
distribucin de Linux, la misma fue realizada y probada nicamente en Ubuntu 9.04. En los prximos
prrafos se detalla el proceso de instalacin de todos los componentes de la misma, cabe destacar que a
pesar de indicar la ubicacin de donde se pueden obtener cada uno de ellos, junto con el presente
informe se entregan tanto el software original utilizado como las modificaciones realizadas a los
mismos.
Al finalizar los pasos descriptos en la presente seccin se tendr tanto la plataforma instalada
como las configuraciones necesarias para la ejecucin de la prueba de concepto realizada.
A.2.1 - Nagios
Como primer paso se tiene que instalar el Nagios y sus plugins principales, ambos pueden ser
obtenidos de [NAGIOSDOWNLOADS], la versin de Nagios Core utilizada para la prueba de
concepto fue la 3.2.0. Para el proceso de instalacin se puede seguir la gua de instalacin rpida que
se encuentra en [NAGIOSINSTALL] y que esta detallada para varias distribuciones de Linux.
Una vez instalado el Nagios se deben instalar los plugins modificados chek_jmx y
check_process_resources, para ello basta con copiar los archivos del primero previamente generados,
check_jmx y jmxquery.jar, y el archivo check_process_resources.sh, del segundo, dentro del
directorio de plugins del Nagios, por ejemplo $NAGIOS_HOME/nagios/libexel, siendo
$NAGIOS_HOME la ubicacin de la carpeta principal donde se encuentra instalado el Nagios.
A.2.2 - BrainyPDM
Para la instalacin del BrainyPDM se pueden seguir las indicaciones dadas en
[BRAINYPDMINSTALL] o en el archivo INSTALL.txt que acompaa a la versin utilizada (1.0.1),
las cuales son resumidas a continuacin:
1. Instalar la JVM, para la prueba de concepto se utiliz la jdk 6.0 de Sun, ahora de Oracle.
2. Descomprimir los archivos dentro del directorio deseado, de ahora en ms llamado
$BRAINY_HOME. Ejemplo /usr/local/brainypdm.
3. Darle permisos de ejecucin a los archivos shell script ubicados dentro de la carpeta
$BRAINY_HOME, para eso ejecutar: chmod ugo+x *.sh
4. Editar el archivo $BRAINY_HOME/conf/brainy.properties y configurar el puerto de donde
BrainyPDM espera recibir la informacin desde Nagios (nagios.listener.port). Ejemplo:
nagios.listener.port=13200
5. Crear la base de datos embebida, para lo cual se deben realizar los siguientes pasos:
a. Abrir una terminal de Linux, ubicarse en $BRAINY_HOME y arrancar el BrainyPDM
133
ejecutando el siguiente script: ./brainypdm.sh -q

b. Abrir la consola de BrainyPDM ejecutando en una nueva terminal de Linux el
siguiente script, ubicado dentro de $BRAINY_HOME: ./console.sh
c. Utilizando la consola abierta en el paso anterior crear la base de datos, mediante el
siguiente comando: db -c
d. Parar la ejecucin de BrainyPDM utilizando el siguiente comando dentro de la
consola: shutdown -a
e. Arrancar nuevamente el BrainyPDM pero ahora sin ningn parmetro: ./brainypdm.sh
6. Una vez instalado el BrainyPDM hay que remplazar los mdulos modificados y agregarles los
nuevos, para ello se debe hacer las siguientes acciones dentro de la carpeta de instalacin:
o Reemplazar los siguientes archivos JAR ubicados
$BRAINY_HOME/lib por los generados anteriormente:
dentro
de
brainypdm-modules-commons-1.0.1-jar
1.0.2.jar
brainypdm-nagios-1.0.1.jar por brainypdm-nagios-1.0.2.jar
brainypdm-core-1.0.1.jar por brainypdm-core-1.0.2.jar
brainypdm-commons-1.0.1-jar por brainypdm-commons-1.0.2.jar
por
la
carpeta
brainypdm-modules-commons-
o Reemplazar el archivo brainypdm-plugins-1.0.1.jar que se encuentra en la carpeta

$BRAINY_HOME/plugins/nagios/lib por el brainypdm-plugins-1.0.2.jar.
o Reemplazar el archivo brainypdm-main.jar que se encuentra dentro de la carpeta
$BRAINY_HOME/mainlib.
o Reemplazar el archivo log4j.properties que se encuentra dentro de la carpeta config con
el entregado junto con el presente informe dentro del directorio
codigo/brainyPDMArchivos.
o Reemplazar el archivo de configuracin de los plugins de Nagios que se encuentra en la
carpeta $BRAINY_HOME/plugins/nagios/lib por el que se entrega junto con el
presente informe dentro del directorio codigo/brainyPDMArchivos.
o Agregar los archivos cliente-jmx.jar y brainypdm-control-1.0.1.jar en el directorio lib.
o Configurar la interconexin con Nagios:
Copiar el archivo brainysend.sh en la ubicacin deseada.
Configurar en brainysend.sh el puerto indicado en $BRAINY_HOME/

conf/brainy.properties bajo la clave nagios.listener.port (configurado en el paso
4)
Configurar Nagios para que le enve la informacin a BrainyPDM:
Modificar los siguientes datos en el archivo nagios.cfg:

o process_performance_data=1
134
o service_perfdata_command=process-service-perfdata
Agregar el siguiente comando, en el archivo commands.cfg:

define command{
command_name process-service-perfdata
command_line $PATH_SEND/brainysend.sh $LASTSERVICECHECK$||
$HOSTNAME$||$SERVICESTATE$||$SERVICEEXECUTIONTIME$||
$SERVICEDESC$||$SERVICEOUTPUT$|$SERVICEPERFDATA$"
}
donde $PATH_SEND es la ubicacin absoluta del archivo brainysend.sh.

o Crear la carpeta control dentro de $BRAINY_HOME/plugins y copiar dentro de ella los
archivos mbeans-def.xml, actuadores-def.xml y transmisores-def.xml que se encuentra
dentro del directorio codigo/brainyPDMArchivos.. Estos archivos contienen la
configuracin de los MBeans, del actuador y del transmisor, respectivamente, utilizados
para la prueba de concepto.
A.2.3 - PowerDEVS
PowerDEVS necesita de wine [WINE] para su ejecucin. Wine es una aplicacin que permite
ejecutar en Linux software que fue desarrollado para windows, la misma tiene que estar instalada antes
de proceder con la instalacin de PowerDEVS. Con el presente trabajo se entrega la versin utilizada.
Para instalar PowerDEVS se debe ubicar en la carpeta donde se encuentra el paquete de
PowerDEVS a instalar y ejecutar el siguiente comando: dpkg -i powerdevs.deb
Cabe destacar que si PowerDEVS ya estuvo instalado anteriormente, y qued algn contenido
dentro del disco virtual de Wine (drive_c) antes de ejecutarlo por primera vez se debe eliminar la
carpeta
PowerDEVS
que
exista
dentro
de
wine,
generalmente
ubicada
en
/home/$USER_HOME/.wine/drive_c, donde $USER_HOME es la carpeta personal del usuario de
Linux.
La versin de PowerDEVS entregada junto con el presente trabajo ya contiene tanto las
modificaciones realizadas para poder ser utilizado como parte de la infraestructura desarrollada como
los modelos utilizados en la prueba de concepto. La misma fue basada en la versin 2.0 para Linux.
A.2.4 - JBoss
Para que el JBoss pueda ser utilizado con la infraestructura desarrollada se debe habilitar el
acceso remoto a los MXBeans, para ello se debe configurar lo siguiente en el archivo run.conf:
#Setup jmx remoting
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=9003"
# Use the JBoss MBeanServerBuilder
JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
JAVA_OPTS="$JAVA_OPTS -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"
135
Anexo B: Cdigo Fuente de los

Modelos DEVS
136
En este apndice se presenta el cdigo fuente de las cuatro funciones dinmicas que definen a
un modelo atmico DEVS para cada modelo desarrollado en el Sistema Controlador: ta() (funcin de
avance de tiempo), delta_int() (funcin de transicin interna), delta_ext (funcin de transicin
externa) y lambda (funcin de salida), y la funcin auxiliar init() (Funcin de inicializacin).
B.1 - Sensor
En el Listado 11 se muestra el cdigo fuente de las funciones del modelo DEVS atmico:
Sensor.
Listado 11 - Cdigo fuente del modelo atmico Sensor
Variables globales:
double sigma;
char y[1024]; //salida
Funcin init:
int port=(int)va_arg(parameters,double);
sigma=10e10;
RequestNET(port,this);
Funcin de avance de
tiempo:
return sigma;
Funcin de transicin
externa:
char* aux=strchr((char*)x.value,'=');
if(aux == NULL){
printLog("Mensaje recibido con formato erroneo: %s\n",x.value);
return;
}
printLog("Mensaje recibido: %s\n",x.value);
strcpy(y,(char*)x.value);
sigma=0;
Funcin de salida:
sigma=10e10;
Event out = Event(&y,0);
out.setRealTimeMode(REALTIME);
return out;
B.2 - Procesador
Procesador
Listado 12 - Cdigo fuente del modelo atmico Procesador
Variables globales
principales:
double sigma;
//estado
double cpu;
double heap;
long freeHeap;
long totalHeap;
137
//salida
int newAC;
int reseted;
int newMaxThread;
char salida[228];
//parametros
double umbCpuInf;
double umbHeapInf;
double umbCpuSup;
double umbHeapSup;
int acDefault;
int maxtDefault;
int mintDefault;
Funcin init
sigma=10e8;
cpu=0;
memory=0;
heap=0;
freeHeap=0;
totalHeap=0;
reseted=false;
acDefault=0;
umbCpuInf=va_arg(parameters,double)*100;
umbHeapInf=va_arg(parameters,double)*100;
umbCpuSup=va_arg(parameters,double)*100;
umbHeapSup=va_arg(parameters,double)*100;
acDefault=va_arg(parameters,double);
maxtDefault=va_arg(parameters,double);
mintDefault=va_arg(parameters,double);
debug=va_arg(parameters,double);
cambioEstado=0; -->nicamente en el control con gc
Funcin de avance de
tiempo:
return sigma;
Funcin de transicin
interna:
freeHeap=0;
totalHeap=0;
sigma=10e8;
Funcin de transicin
externa:
int typeMsgSize=200;
int msgSize=512;
char typeMsg[typeMsgSize];
char msg[msgSize];
char* aux=strchr((char*)x.value,'=');
int typeMsgLen=strlen((char*)x.value)-strlen(aux);
bool isCpu=false;
bool isHeap=false;
strncpy(typeMsg,(char*)x.value,typeMsgLen);
typeMsg[typeMsgLen]='\0';
aux++;
strcpy(msg,aux);
138
if (debug==1) printLog("typeMsg=%s\n",typeMsg);
if (debug==2) printLog("msg=%s\n",msg);
if (strcmp(typeMsg,"JBoss.cpu")==0){
if (debug==2) printLog("cpu\n");
cpu=atof(msg);
isCpu=true;
isHeap=false;
if (debug==1) printLog("cpu=%s\n",msg);
}
if (strcmp(typeMsg,"FreeMemory")==0){
if (debug==2) printLog("freememory\n");
freeHeap=nctof(msg);
if (debug==1) printLog("freememory=%d\n",freeHeap);
if(totalHeap!=0){
heap=100-((float)(freeHeap*100.00/totalHeap));
isHeap=true;
isCpu=false;
}
}
if (strcmp(typeMsg,"TotalMemory")==0){
if (debug==2) printLog("totalmemory\n");
totalHeap=nctof(msg);
if (debug==1) printLog("totalmemory=%d\n",totalHeap);
if(totalHeap!=0 && freeHeap!=0){
heap=100-((float)(freeHeap*100.00/totalHeap));
isHeap=true;
isCpu=false;
}
}
if(heap!=0 || cpu!=0 ){
//lgica del control
if (isHeap ){
if(heap<umbHeapInf){
cantMetHeapRecibidas++;
cantMetHeapRecibidas2=0;
if (debug==1) {
printLog("cantMetHeapRecibidas=%d\n",cantMetHeapRecibidas);
printLog("cantMetCPURecibidas=%d\n",cantMetCPURecibidas);
}
}else{
cantMetHeapRecibidas=0;
cantMetHeapRecibidas2++;
if (debug==1) {
printLog("cantMetHeapRecibidas2=%d\n",cantMetHeapRecibidas2);
printLog("cantMetCPURecibidas2=%d\n",cantMetCPURecibidas2);
}
139
}
}
if(isCpu ){
if(cpu<umbCpuInf){
cantMetCPURecibidas++;
cantMetCPURecibidas2=0;
if (debug==1) {
printLog("cantMetHeapRecibidas=%d\n",cantMetHeapRecibidas);
printLog("cantMetCPURecibidas=%d\n",cantMetCPURecibidas);
}
}else{
cantMetCPURecibidas=0;
cantMetCPURecibidas2++;
if (debug==1) {
printLog("cantMetHeapRecibidas2=%d\n",cantMetHeapRecibidas2);
printLog("cantMetCPURecibidas2=%d\n",cantMetCPURecibidas2);
}
}
}
if(((heap>=umbHeapSup ) || (cpu>= umbCpuSup && cantMetCPURecibidas2 >=
cantMetCambio2)) && !reseted){
newAC=1;
reseted=true;
sigma=0;
printLog("Actuar: heap= %f - cpu= %f \n",heap,cpu);
newMaxThread=mintDefault;
cambioEstado=1; -->unicamente en el control con gc
}
if(heap<umbHeapInf && cpu<umbCpuInf && reseted ){
if(cantMetCPURecibidas >= cantMetCambio){
newAC=acDefault;
newMaxThread=maxtDefault;
reseted=false;
sigma=0;
cantMetCPURecibidas=0;
cantMetHeapRecibidas=0;
isCpu=false;
isHeap=false;
cambioEstado=1; -->unicamente en el control con gc
}
}
}
Funcin de salida:
Control simple:
char aux[10];
sprintf(salida,"%d",newAC);
sprintf(aux,"%d",newMaxThread);
140
strcat(salida,"|");
strcat(salida,aux);
strcat(salida,"\0");
if (debug==1) printLog("Salida procesador: %s\n",salida);
Event event=Event(&salida,0);
return event;
Control con gc:
if(cambioEstado){
if(reseted){//pasa a estado saturado
sprintf(salida,"%s","es");
}else{//pasa a estado normal
sprintf(salida,"%s","en");
}
sprintf(aux,"%d",newAC);
strcat(salida,aux);
sprintf(aux,"%d",newMaxThread);
strcat(salida,"|");
strcat(salida,aux);
}else{
sprintf(salida,"%s","gc");
}
strcat(salida,"\0");
if (debug==1) printLog("Salida procesador: %s\n",salida);
Event event=Event(&salida,0);
return event;
B.3 - Efector
Efector.
Listado 13 - Cdigo fuente del modelo atmico Efector
Variables globales:
double sigma;
//parmetros
int port;
char ip[16];
Funcin init
char* pip=(char*)va_arg(parameters,char*);
strcpy(ip,pip);
sigma=10e10;
Funcin de avance de
tiempo:
return sigma;
Funcin de transicin
interna:
sigma=10e10;
Funcin de transicin
Control simple:
141

externa:
printLog("Efector recibio: %s \n",(char*)x.value);

char* value=(char*)x.value;
printLog("Efector recibio: %s \n",value);
char *msgCte="jbosswebConn|acceptCountAttr|\0";
char *msgCte2="jbosswebTPool|maxThreadsAttr|\0";
char msg[strlen(msgCte)+strlen(msgCte2)+5];
char newValue[5];
char newValue2[5];
sprintf(newValue,"%s",strtok(value,"|"));
sprintf(newValue2,"%s",strtok(NULL,"|"));
strcpy(msg,msgCte);
strcat(msg,newValue);
strcat(msg,"||");
strcat(msg,msgCte2);
strcat(msg,newValue2);
strcat(msg,"\0");
printLog("Actuacion: %s longitud %d\n",msg,strlen(msg));
sendNET(port,ip,msg,strlen(msg));
printLog("Enviado por ip=%s port=%d\n",ip,port);
Control con gc:
if (debug==2) printLog("Efector recibio: %s \n",(char*)x.value);
char* value=(char*)x.value;
char *msgCte="jbosswebConn|acceptCountAttr|\0";
char *msgCte2="jbosswebTPool|maxThreadsAttr|\0";
char *msgCte3="javalangMemory|gc\0";
char msg[strlen(msgCte)+strlen(msgCte2)+strlen(msgCte3)+5];
char newValue[5];
char newValue2[5];
char type[3];
strncpy(type,value,2);
type[2]='\0';
if (debug==2) printLog("type=%s\n",type);
value+=2;
if (debug==2) printLog("value=%s\n",value);
if(strcmp(type,"gc")==0){//ejecutar el GC
if (debug==1) printLog("Ejecutar un GC\n");
strcpy(msg,msgCte3);
}else{
if (debug==1) printLog("Cambio de estado\n");
sprintf(newValue,"%s",strtok(value,"|"));
sprintf(newValue2,"%s",strtok(NULL,"|"));
strcpy(msg,msgCte);
strcat(msg,newValue);
strcat(msg,"||");
strcat(msg,newValue2);
if(strcmp(type,"es")==0){//cambio a estado saturado -> ejecuto el GC
strcat(msg,"||");
142
strcat(msg,"\0");
}
}
if (debug==2) printLog("Actuacion: %s longitud %d\n",msg,strlen(msg));
sendNET(port,ip,msg,strlen(msg));
if (debug==1) printLog("Enviado por ip=%s port=%d\n",ip,port);
143
Anexo C: Artculo presentado en

ASSE 2012
144
A continuacin se presenta el trabajo:

Galache G. y Castro R. 2012. Una plataforma para el Control a Eventos Discretos de
Sistemas de Software mediante Modelos en Tiempo Real: Aplicacin al Consumo de
Recursos en Web/Java EE. In Proceedings of the 13th Argentine Symposium on
Software Engineering, ASSE 2012, 41 JAIIO. pp 149-163.
conteniendo parte de los resultados obtenidos en la presente Tesis.
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
Glosario
ABI: del ingls Application Binary Interface (interfaz binaria de aplicacin), describe la interfaz de bajo nivel
entre una aplicacin y el sistema operativo, entre una aplicacin y sus bibliotecas, o entre partes componentes
de una aplicacin. Un ABI es distinto de una API, en que este ltimo define la interfaz entre el cdigo fuente y
bibliotecas, por esto ese mismo cdigo fuente compilar en cualquier sistema que soporte esa API, mientras que
un ABI permite que un cdigo objeto compilado funcione sin cambios sobre cualquier sistema usando un ABI
compatible.
ACL: del ingls Access Control List (lista de control de acceso) es un concepto de seguridad informtica y es
una manera de determinar los permisos de acceso apropiados a un determinado objeto, dependiendo de ciertos
aspectos del proceso que hace el pedido de autenticacin. [ACLWIKI]
API: del ingls Application Programming Interface (interfaz de programacin de aplicaciones), es el conjunto
de funciones y procedimientos (o mtodos si se refiere a programacin orientada a objetos) que ofrece cierta
biblioteca para ser utilizado por otro software como una capa de abstraccin. [APIWIKI]
Arquitectura: en el contexto de sistemas informticos se llama arquitectura de software a la definicin de la
estructura, funcionamiento e interaccin entre las partes del mismo. Es decir que define, de manera abstracta,
los componentes que llevan a cabo alguna tarea de computacin, sus interfaces y la comunicacin ente ellos.
Base de datos rrd: del ingls Round-Robin Database, se trata de una base de datos, orientadas al
almacenamiento de datos basados en series temporales, y que garantizan el espacio final ocupado por sus
elementos.
Browser: tambin llamado navegador o explorador web, es un programa que le permite al usuario navegar por
internet.
Callbacks: en programacin, un callback es una porcin de cdigo ejecutable que es pasado como un
argumento a otro cdigo, permitiendo de esta forma construir cdigo de bajo nivel como capas de abstraccin
que pueden ser llamadas desde una subrutina (o funcin) definida en una capa de nivel superior.
Conjunto de Instrucciones: es una especificacin que detalla las instrucciones que una CPU de una
computadora puede entender y ejecutar. [ISAWIKI]
Cuello de botella o bottleneck: es un trmino utilizado para describir el fenmeno por el cual el desempeo o
capacidad de un sistema se ve gravemente limitada por un slo componente del mismo.
Deadlock: se llama as a la situacin donde dos o ms procesos estn cada uno esperando que el otro libere un
recurso en una cadena circular.
Demonio: un demonio o daemon, de sus siglas en ingls Disk And Execution Monitor, es un tipo especial de
proceso que se ejecuta en segundo plano en vez de ser controlado directamente por el usuario, es decir es un
proceso no iterativo Este tipo de programa se ejecuta de forma continua.
Excepciones chequeadas: son excepciones que deben ser capturadas explcitamente mediante el bloque trycatch-finally o propagadas.
Excepciones no chequeadas: son excepciones que no es obligatorio que sean capturadas o propagadas.
161
Framework: se llama as a un conjunto estandarizado de conceptos, prcticas, criterios y/o componentes para
enfocar un tipo de problemtica particular que sirve como referencia, para enfrentar y resolver nuevos
problemas de ndole similar. Dentro del contexto del desarrollo de software, es una estructura de soporte
definida mediante la cual otro proyecto de software puede ser organizado y desarrollado, tpicamente puede
incluir bibliotecas, componentes, etc para ayudar a desarrollar y unir diferentes componentes de un proyecto.
GNU GPL: es una licencia creada a mediados de los aos 80, orientada a proteger la libre distribucin,
modificacin y uso de software, protegindolo de intentos de apropiacin. El software cubierto por esta licencia
es el llamado software libre [GPL].
Heap: es la porcin de memoria en la cual se almacenan los objetos creados durante la ejecucin de las
aplicaciones Java.
Infraestructura de IT: se denomina as al conjunto de elementos o servicios tecnolgicos, es decir
relacionados con la tecnologa de la informacin, que se consideran necesarios para el funcionamiento de una
organizacin o el desarrollo de una actividad.
Instruccin o cdigo nativo: se llama as al cdigo ya compilado, es decir que puede ser ejecutado en una
plataforma en particular.
Instrumentar: se llama as a la funcin de adosar un mecanismo a una aplicacin, JVM, o cualquier otro
recurso con el fin de monitorearla, es decir de observar su comportamiento cuando se est ejecutando.
IT: siglas del ingls Information Technologies (tecnologas de la informacin), que se utilizan para denominar
todo lo relacionado con el diseo, desarrollo, fomento, mantenimiento y administracin de la informacin por
medio de sistemas informticos, para informacin, comunicacin o ambos. Esto incluye todos los sistemas
informticos no solamente las computadoras sino tambin las redes de telecomunicaciones, telemtica, los
telfonos celulares, la televisin, la radio, los peridicos digitales, faxes, dispositivos porttiles, etc.
JAR: del ingls Java Archive, son archivos comprimidos que contienen componentes y/o aplicaciones escritas
en Java.
Java Platform, Standard Edition (J2SE): es una plataforma altamente utilizada para desarrollar programas en
el lenguaje de programacin Java, consiste de una VM junto con un conjunto de bibliotecas necesarias para
facilitar el uso, dentro de las aplicaciones desarrolladas, de la red, el file system, la interfaz grfica entre otras
cosas.
Listener: es un trmino utilizado en la disciplina de desarrollo de software para llamar a los objetos que se
quedan esperando por la ocurrencia de un determinado evento.
Log: es un registro de los eventos producidos en un determinado perodo de tiempo.
Open source o cdigo abierto: es el trmino con el que se conoce al software distribuido junto con su cdigo
fuente. Un programa open source puede ser software libre, es decir que puede ser distribuido libremente, semi
libre o directamente no libre. Sin embargo, por lo general, un programa de cdigo abierto es libre, como
igualmente un programa software libre es open source. Esto ocurre dado que ambos movimientos reconocen el
mismo conjunto de licencias y mantienen principios equivalentes. [OSWIKI]
Overhead: se llama as a la sobrecarga de los recursos necesarios, como por ejemplo el tiempo de ejecucin, la
memoria utilizada, para lograr un determinado objetivo.
Patrn de diseo: se llama as a una solucin a un problema de diseo comn de la cual est comprobada su
efectividad resolviendo problemas similares.
162
Plugin (plug-in): es una aplicacin que se relaciona con otra para aportarle una funcin nueva y generalmente
muy especfica. Esta aplicacin adicional es ejecutada por la aplicacin principal e interactan por medio de la
API. Es una forma de expandir programas de forma modular, de manera que se puedan aadir sin afectar a las
ya existentes ni complicar el desarrollo del programa principal.
Protocolo HTTP/1.1: el protocolo HTTP/1.1 es la versin 1.1 del protocolo HTTP (Hypertext Transfer
Protocol) el cual es el protocolo utilizado para navegar por internet.
Script: los scripts son un conjunto de instrucciones generalmente almacenadas en un archivo de texto que
deben ser interpretados lnea a lnea en tiempo real para su ejecucin, se distinguen de los programas, en que
estos ltimos deben ser compilados y traducidos a lenguaje mquina para luego poder ser utilizados.
Shell script: es un script escrito para un intrprete de comando de un determinado sistema operativo.
Signatura: la signatura o firma de un mtodo define su entrada y su salida. Incluye por lo menos el nombre de
la funcin o mtodo y el nmero de sus parmetros. En algunos lenguajes de programacin, puede incluir el
tipo que devuelve la funcin o el tipo de sus parmetros.
Sistemas de eventos discretos: se llama as a los sistemas donde las seales que transportan la informacin
existen o son consideradas slo a intervalos discretos de tiempo.
SLA: los SLAs son contratos escritos entre el proveedor de un servicio y su cliente en el cual se fija el nivel
acordado para la calidad de dicho servicio.
SLO: se llama SLOs a los valores deseados para las distintas mtricas del sistema, como por ejemplo para el
tiempo de respuesta del mismo.
Socket: designa un concepto abstracto por el cual dos aplicaciones pueden intercambiar cualquier flujo de
datos, generalmente de manera confiable y ordenada. Este trmino tambin es utilizado como el nombre de una
API para la familia de protocolos de Internet TCP/IP.
Stack trace: es un reporte de las llamadas a funciones hechas por un programa.
Stack: es el rea de memoria donde se almacena el estado de invocacin del mtodo Java (no nativo) que se
est ejecutando en el thread. Este estado incluye sus variables locales, los parmetros con los cuales fue
invocado, su valor de retorno (si existe) y clculos intermedios.
Stakeholders: es un trmino que utilizado en el contexto del desarrollo de sistemas de software se refiere a las
personas o entidad interesada/s o involucrada/s en la realizacin de un proyecto o tarea, auspiciando el mismo
ya sea mediante su poder de decisin o de financiamiento, o a travs de su propio esfuerzo.
STDOUT: se llama as a la salida estndar de un programa generalmente la misma esta direccionada a la
terminal del usuario.
Test de carga: test que tiene la finalidad de ver cmo se comporta el sistema frente a la carga normal que
soportar una vez que se encuentre productivo.
Test de stress: test que se le realiza a un sistema con el objetivo de llevarlo al lmite para descubrir la existencia
de fallas en el mismo.
Thread: un thread es un hilo de ejecucin, es decir es una bifurcacin de un programa en dos o ms tareas
concurrentes. La implementacin de threads y procesos difieren de un sistema operativo a otro, pero en la
mayora de los casos un thread est contenido dentro de un proceso. La diferencia bsica entre un proceso de
sistema operativo y un thread es que los threads corren dentro del proceso del sistema operativo que las cre, la
JVM en el caso de Java, y por tanto comparten todos los recursos, incluida la memoria y las variables y objetos
all definidos. Mientras que los procesos no comparten sus datos.
163
Timestamp: es una secuencia de caracteres, que denotan la hora y fecha (o alguna de ellas) en la cual ocurri
determinado evento.
Web Server: o servidor web, tambin llamado servidor HTTP, es un sistema que utiliza el modelo de
arquitectura cliente/servidor y el protocolo HTTP (Hypertext Transfer Protocol) para servir los archivos que
forman parte del contenido de las pginas web accedidas mediante internet.
164
Referencias
[ACLWIKI]
Access control list. http://en.wikipedia.org/wiki/Access_control_list. Pgina

vigente al 04/10/2011
[Abdelzaher et al, 2008]
Abdelzaher, T., Diao, Y., Hellerstein, J.L., Yu. C. y Zhu, X. 2008. Introduction to
control theory and its application to computing systems. In Z. Liu and C. Xia,
editors, Performance Modeling and Engineering.
[ABLE]
ABLE Rule Language. http://www.research.ibm.com/able/ . Pgina vigente al

1/1/2012
[ANT]
Apache Ant, http://ant.apache.org/. Pgina vigente al 08/07/2012.
[APACHEARP]
Apache Portable Runtime Project. http://apr.apache.org/. Pgina vigente al

15/11/2011
[APACHEHTTP]
Apache Http Server. http://httpd.apache.org/. Pgina vigente al 15/11/2011
[APACHETOMCAT]
Apache Tomcat. http://tomcat.apache.org/. Pgina vigente al 15/11/2011
[APIWIKI]
Interfaz de programacin de aplicaciones.

Wikipedia. http://es.wikipedia.org/wiki/Application_Programming_Interface .
Pgina vigente al 07/10/2011.
[Arzen et al, 2006]
Arzen K., Robertsson A., Henriksson A., Johansson M., Hjalmarsson H., y
Johansson K.H. 2006. Conclusions of the ARTIST2 Roadmap on Control of
Computing Systems. SIGBED Rev., Vol. 3 Nro. 3, Pginas 1120
[Avizienis et al., 2000]
Avizienis A., Laprie J.C. y Randell B. Octubre 2000. Fundamental Concepts of

Dependability. In Proceedings of the 3rd IEEE Information Survivability
Workshop (ISW-2000), Boston, Massachusetts, USA. Pginas 7-12.
[Avizienis et al., 2004]
Avizienis A., Laprie J.C., Randell B. y Landwehr C. 2004. Basic Concepts and
Taxonomy of Dependable and Secure Computing. IEEE Transactions on
Dependable and Secure Computing, Vol. 1, Issue 1. Pginas 11- 33.
[Bergero & Kofman, 2010]
Bergero F. y Kofman E. 2010. PowerDEVS A Tool for Hybrid System Modeling

and Real Time Simulation. Submission for the Special Issue of Simulation:
Software Tools Techniques and Architectures for Computer Simulation
[BRAINYPDM]
BrainyPDM - Graphs Nagios's data and make statistics.

http://www.brainypdm.org/ . Pgina vigente al 03/10/2011.
[BRAINYPDMARQ]
BrainyPDM - module architecture.

http://www.brainypdm.org/index.php/documentation/4-architecturedocumentation/4-brainypdm-module-architecture. Pgina vigente al 04/10/2011.
[BRAINYPDMINSTALL]
BrainyPDM quick installation guide.

http://www.brainypdm.org/index.php/documentation/3?task=view. Pgina
[Castro et al, 2009]
Castro, R., Kofman, E. y Wainer, G.2009.A DEVS based end to end Methodology
for Hybrid Control of Embedded Networking Systems. In Proceedings of
ADHS'09: 3rd IFAC Conference on Analysis and Design of Hybrid Systems,
165
Zaragoza, Spain.
[Castro et al, 2012]
Castro, R., Ramello, I., Bonaventura, M., y Wainer, G. A. 2012. M&S-based

design of embedded controllers on network processors.In Proceedings of the
2012 Symposium on Theory of Modeling and Simulation-DEVS Integrative
M&S Symposium. Society for Computer Simulation International.Art Nro. 32
[CHECKPROCPLUGIN]
Check Process Resources.

http://exchange.nagios.org/directory/Plugins/Uncategorized/Software/CheckProcess-Resources/details Pgina vigente al 16/10/2011.
[CHECKSSHPLUGIN]
check_by_ssh Plugin. http://nagiosplugins.org/man/check_by_ssh. Pgina vigente

al 16/10/2011.
[Cheng et al., 2005]
Cheng S.W., Garlan D. y Schmerl B. 2005. Making Self-Adaptation an

Engineering Reality. Bradley Schmerl, School of Computer Science Carnegie
Mellon University.
[Cheng, 2008]
Cheng S.W.,2008. Rainbow: Cost-Eective Software Architecture-Based SelfAdaptation. School of Computer Science, Carnegie Mellon University,
Pittsburgh, PA, USA. ProQuest.
[Cheng et al,2009]
Cheng, B.H., Lemos, R., Giese, H., Inverardi, P., Magee, J., Andersson, J.,
Becker, B., Bencomo, N, Brun, Y.,Cukic, B., Serugendo Marzo, G., Dustdar, S.,
Finkelstein, A.,Gacek, C.,Geihs, K., Grassi, V., Karsai, G., Kienle, H.M., Kramer,
J., Litoiu, M., Malek, S., Mirandola, R., Muller, H.A., Park, S., Shaw, M., Tichy,
M.,Tivoli, M., Weyns, D. y Whittle, J. 2009. Software engineering for selfadaptive systems. chapter Software Engineering for Self-Adaptive Systems: A
Research Roadmap. Springer-Verlag, Berlin, Heidelberg. Pginas 1-26.
[Chiocchio & Tursi,2011]
Chiocchui J, y Tursi, G.G. 2011. Hacia un modelo ms flexible para la

implementacin de la auto reparacin de sistemas de software basada en
Arquitectura. Tesis de Licenciatura en Ciencias de la Computacin. Universidad
de Buenos Aires Facultad de Ciencias Exactas y Naturales.
http://www.dc.uba.ar/inv/tesis/licenciatura/2011/chiocchio, Pgina vigente al
15/01/2012.
[Diaconescu & Murphy, 2003]
Diaconescu A. y Murphy J. 2003. A framework for using component redundancy

for self-optimising and self-healing component based systems. In Workshop on
Software Architectures for Dependable Systems (WADS), ICSE03, Portland,
Oregon USA.
http://www.cs.kent.ac.uk/events/conf/2003/wads/Proceedings/diaconescu.pdf.
Pgina vigente al 13/01/2012
[Diaconescu & Murphy, 2005]
Diaconescu A. y Murphy J. 2005. Automating the Performance Management of

Component-Based Enterprise Systems through the use of Redundancy.
Proceedings of the 20th IEEE/ACM International Conference on Automated
Software Engineering (ASE 2005). http://adadiaconescu.there-youare.com/Papers/ASE2005/fp214-diaconescu.pdf . Pgina vigente al 13/01/2012
[Diaconescu, 2006]
Diaconescu A. 2006. Automatic Performance Optimisation of Component-Based

Enterprise Systems via Redundancy. A Thesis submitted to Dublin City
University for the degree of Ph. D. in the Faculty of Engineering and Computing.
http://www.csi.ucd.ie/staff/jmurphy/publications/thesis-ada.pdf Pgina vigente al
14/01/2012
166
[Diao et al., 2002]
Diao Y., Gandhi N., Hellerstein J.L., Parekh S, y Tilbury D. M. 2002. Using
MIMO feedback control to enforce policies for interrelated metrics with
application to the Apache Web server. Network Operations and Management
Symposium. Pginas 219-234
[Diao et al., 2004]
Diao Y., Hellerstein J.L., Parekh S., Griffith R., Kaiser G. y Phung D. 2004. SelfManaging Systems: A Control Theory Foundation. 1St Workshop on Operating
System and Arquitecturaal Support.
[Galache & Castro, 2012]
Galache G. y Castro R. 2012.Una plataforma para el Control a Eventos

Discretos de Sistemas de Software mediante Modelos en Tiempo Real: Aplicacin
al Consumo de Recursos en Web/Java EE.. In Proceedings of the 13th. Argentine
Symposium on Software Engineering, ASSE 2012, 41 JAIIO. Pginas 149-163
[Gandhi et al, 2001]
Gandhi N., Tilbury D. M., Diao Y., Hellerstein J y Parekh S. 2001. MIMO
Control of an Apache Web Server: Modeling and Controller Design. Submitted to
the 2002 American Control Conference. IBM Research Division.
http://domino.watson.ibm.com/library/cyberdig.nsf/papers/BCB8701FD6FC46C
A85256AEE0074B9F1/$File/RC22216.pdf. Pgina vigente al 16/01/2012
[Ganek & Corbi , 2003]
Ganek A. G. y Corbi T. A. Marzo 2003. The dawning of the autonomic computing

era. IBM Systems Journal.
[Garlan & Schmerl, 2002]
Garlan D. y Schmerl B. Noviembre 2002. Model-based Adaptation for SelfHealing Systems. WOSS 02: Proceedings of the first workshop on Selfhealing
systems. New York, NY, USA: ACM Press, 2002. Pginas 2732
[Garlan et al, 2004]
Garlan, D., Cheng, S.W., Huang, A.C., Schmerl, B. y Steenkiste, P. Octubre 2004.
Rainbow: Architecture-based self-adaptation with reusable infrastructure. IEEE
Computer, Vol. 37, Issue 10. Pginas 4654.
[GGPL]
GNU General Public License. http://es.wikipedia.org/wiki/GPL . Pgina vigente

al 07/10/2011
[Ghosh et al., 2007]
Ghosh D., Sharman R., Raghav R., Rao H. y Upadhyaya S.2007. Self-healing
systemssurvey and synthesis. Vol. 42, Nro.4. Pginas 2164-2185
[Gosling et al., 2005]
Gosling J., Joy B., Steele G. y Bracha.G. The Java Language Specification. Sun
Microsystems, 3ed Edition.
http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html. Pgina vigente
al 07/10/2011.
[Hellerstein et al., 2004]
Hellerstein J.L., Diao Y., Parekh S.y Tilbury D.M. 2004. Feedback Control of
Computing Systems. IEEEJohn Wiley & Sons, Inc.
[Hellerstein et al., 2005]
Hellerstein J.L., Diao Y., Parekh S.y Tilbury D.M. 2005. Control Engineering for
Computing Systems. IEEE Control Systems Magazine
[Hellerstein, 2003]
Hellerstein J.L. 2003. Challenges in Control Engineering of Computing Systems.

IBM Research Division.
[Hinnelund, 2004]
Hinnelund P. Marzo 2004. Autonomic Computing a method for automated

systems management - Systems management using distributed local control.
Masters Thesis in Computer Science at the School of Computer Science and
Engineering, Royal Institute of Technology.
[HPROFSUN]
HPROF: A Heap/CPU Profiling Tool in J2SE

5.0. http://java.sun.com/developer/technicalArticles/Programming/HPROF.html.
167

[Huebscher & McCann, 2008]
Huebscher M. C.y McCann J. A.2008. A survey of autonomic computing degrees,

models, and application. ACM Computing Surveys. Vol. 40, Nro.3, Pginas: 7:17:28
[ISAWIKI]
Conjunto de Instrucciones. Wikipedia.

http://es.wikipedia.org/wiki/Conjunto_de_instrucciones. Pgina vigente al
07/10/2011.
[Jamae & Johnson, 2009a]
Jamae, J. Y Johnson, P. 2009. JBoss in Action. Manning Publications Co. Cap. 2
[Jamae & Johnson, 2009b]
Jamae, J. Y Johnson, P. 2009. JBoss in Action. Manning Publications Co. Cap. 5
[JBOSSWEB]
JBoss Web. http://www.jboss.org/jbossweb. Pgina vigente al 10/10/2011.
[JCP]
Java Community Process. http://jcp.org/en/home/index . Pgina vigente al

22/11/2011.
[JDIAPI]
Java Debug Interface.

http://java.sun.com/javase/6/docs/jdk/api/jpda/jdi/index.html. Pgina vigente al
07/10/2011.
[Jendrock et al, 2010]
Jendrock E., Ball J., Carson D., Evans I., Fordin S. y Haase K. 2010.The Java EE
5 Tutorial. http://docs.oracle.com/javaee/5/tutorial/doc/ . Oracle Parkway. Pgina
[JMETER]
Apache Jmeter, http://jmeter.apache.org/. Pgina vigente al 25/06/2012
[JMXESP,2006a]
Sun Microsystems, Inc. 2006. Java Management Extensions (JMX) Specification,

version 1.4.
http://java.sun.com/javase/6/docs/technotes/guides/jmx/JMX_1_4_specification.p
df. Pgina vigente al 07/10/2011.
[JMXNAGIOSPLUGIN]
Java JMX Nagios Plugin. http://exchange.nagios.org/directory/Plugins/JavaApplications-and-Servers/check_jmx/details. Pgina vigente al 03/10/2011.
[JPDA]
Java Platform Debugger Architecture.

http://java.sun.com/javase/technologies/core/toolsapis/jpda, Pgina vigente al
07/10/2011..
[JVMMIB]
JVM-MANAGEMENT-MIB.
http://download.oracle.com/javase/6/docs/jre/api/management/JVMMANAGEMENT-MIB.mib. Pgina vigente al 07/10/2011.
[JVMTI]
Java Virtual Machine Tools

Interface.http://java.sun.com/javase/6/docs/platform/jvmti/jvmti.html. Pgina
vigente al 07/10/2011.
[JVMTIEVENT]
Sun Microsystems, Inc. Java Virtual Machine Tools Interface: Events.

http://java.sun.com/javase/6/docs/platform/jvmti/jvmti.html#EventSection.
[JVMTIFUN]
Sun Microsystems, Inc. Java Virtual Machine Tools Interface: Functions Index
http://java.sun.com/javase/6/docs/platform/jvmti/jvmti.html#FunctionIndex.
[Kephart & Chess, 2003]
Kephart J.O. y Chess D.M. Enero 2003. The Vision of Autonomic Computing.
IBM Thomas J. Watson Research Center. IEEE Computer. Pginas 41-50.
168
[Kofman,2000a]
Kofman, E. 2000. Bases del formalismo DEVS. Apuntes del Seminario

Formalismo DEVS: Teora Y Aplicaciones.
http://www.eie.fceia.unr.edu.ar/~dsf/devs/SeminarioDEVS2000.html#Contenidos
Sinteticos. Pgina vigente al 04/06/2010.
[Kofman,2000b]
Kofman, E. 2000. Modelos DEVS de acoplamiento. Apuntes del Seminario

Sinteticos Pgina vigente al 04/06/2010
[Kofman,2000c]
Kofman, E. 2000. Simulacin en el formalismo DEVS. Apuntes del Seminario

Sinteticos. Pgina vigente al 04/06/2010
[Koopman, 2003]
Koopman P. 2003. Elements of the Self-Healing System Problem Space. WADS

2003 Workshop on Software Architectures for Dependable Systems.
[Kreger et al,2002a]
Kreger, H., Harold, W. y Williamson L. December 2002. Java and JMX: Building
Manageable Systems. Addison Wesley. Captulo 3.
[Kreger et al,2002b]
Kreger, H., Harold, W. y Williamson L. December 2002. Java and JMX: Building
Manageable Systems. Addison Wesley. Captulo 4.
[Kurniawan & Deck, 2004]
Kurniawan, B. y Deck, P. 2004. How Tomcat Works.
[Lindholm & Yellin, 1999]
Lindholm T. y Yellin F. 1999. The JavaTM Virtual Machine Specification. Sun

Microsystems, 2nd edition.
http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html
. Pgina vigente al 07/10/2011.
[Liu et al, 1999]
Liu Z., Niclausse N., Jalpa-Villanueva C. y Barbier S. Diciembre 1999. Traffic

model and performance evaluation of web server. Tech. Rep. 3840, INRIA
[MXBEANESP]
MXBean Specification.
http://java.sun.com/javase/6/docs/api/javax/management/MXBean.html#MXBea
n-spec. Pgina vigente al 07/10/2011.
[NAGIOS]
Nagios. http://www.nagios.org/. Pgina vigente al 03/10/2011.
[NAGIOSBOOKS]
Nagios Books. http://www.nagios.org/propaganda/books/. Pgina vigente al

03/10/2011.
[NAGIOSCOMMANDS]
Nagios Command Definitions.

http://nagios.sourceforge.net/docs/nagioscore/3/en/objectdefinitions.html#comma
nd. Pgina vigente al 04/11/2012
[NAGIOSCOREPLUGINS]
Nagios Core Nagios Plugins.

http://nagios.sourceforge.net/docs/nagioscore/3/en/plugins.html. Pgina vigente
al 05/10/2011
[NAGIOSDOWNLOADS]
Nagios Downloads. http://www.nagios.org/download. Pgina vigente al

10/07/2012.
[NAGIOSEXCHANGEPLUGINS] Nagios Exchange Plugins. http://exchange.nagios.org/directory/Plugins. Pgina
[NAGIOSINSTALL]
Nagios Quickstart Installation Guides.

http://nagios.sourceforge.net/docs/3_0/quickstart.html. Pgina vigente al
169
10/07/2012.
[NAGIOSMACROS]
Nagios Core - Understanding Macros and How They Work.

http://nagios.sourceforge.net/docs/nagioscore/3/en/macros.html. Pgina vigente al
05/10/2011
[NAGIOSMACROSSTAND]
Nagios Core Standard Macros in Nagios.

http://nagios.sourceforge.net/docs/nagioscore/3/en/macrolist.html. Pgina vigente
al 05/10/2011
[NAGIOSOBJECTS]
Nagios Core - Object Definitions.

http://nagios.sourceforge.net/docs/nagioscore/3/en/objectdefinitions.html. Pgina
[NAGIOSPERFDATA]
Nagios Performance Data. http://nagios.sourceforge.net/docs/3_0/perfdata.html.

[NAGIOSPLUGINAPI]
Nagios Plugin
API. http://nagios.sourceforge.net/docs/3_0/pluginapi.html. Pgina vigente al
05/10/2011.
[NAGIOSPLUGINDEV]
Nagios plug-in development guidelines.

http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN39. Pgina
[NAGIOSPLUGINS]
Official Nagios Plugins. http://www.nagios.org/download/plugins. Pgina vigente

al 03/10/2011
[NAGIOSSERVICIOS]
Nagios Service Definitions.

http://nagios.sourceforge.net/docs/nagioscore/3/en/objectdefinitions.html#service
[NAGIOSUSERS]
Nagios Customers and Users. http://www.nagios.com/users. Pgina vigente al

03/10/2011.
[NRPE]
NRPE - Nagios Remote Plugin Executor.

http://exchange.nagios.org/directory/Addons/Monitoring-Agents/NRPE--2DNagios-Remote-Plugin-Executor/details. Pgina vigente al 03/10/2011
[NSCA]
NSCA - Nagios Service Check Acceptor.

http://exchange.nagios.org/directory/Addons/Passive-Checks/NSCA--2D-NagiosService-Check-Acceptor/details. Pgina vigente al 03/10/2011
[OPENNMS]
OpenNMS. http://www.opennms.org/. Pgina vigente al 03/10/2011.
[Oriezy et al, 1999]
Oreizy, P., Gorlick, M.M., Taylor, R.N., Heimhigner, D., Johnson, G.,
Medvidovic, N., Quilici, A., Rosenblum, D.S. y Wolf, A.L.1999. An ArchitectureBased Approach to Self-Adaptive Software. IEEE Intelligent Systems. Vol. 14,
Nro. 3, Pginas 54-62.
[Orlando & Russo, 2006]
Orlando, S. y Russo, S. 2006. Java Virtual Machine monitoring for dependability

benchmarking. 9th IEEE International Symposium on Object and ComponentOriented Real-Time Distributed Computing, ISORC.
[OSWIKI]
Open Source. Wikipedia. http://en.wikipedia.org/wiki/Open_source Pgina

[Park et al., 2008]
Park J., Jung J. , Piao S. y Lee E. 2008. Self-Healing Mechanism for Reliable
Computing. IJMUE International Journal of Multimedia and Ubiquitous
170
Engineering Vol. 3, Nro. 1

[Patikirikorala et al., 2012]
Patikirikorala, T., Colman, A., Han, J. y Wang, L. 2012. A systematic survey on

the design of self-adaptive software systems using control engineering
approaches. In: 7th Intl. Symposium on Software Eng. for Adaptive and SelfManaging Systems, Zrich, Switzerland. Pginas 33-42
[PLATMBEANS]
Sun Microsystems, Inc. Platform MBeans.

http://java.sun.com/j2se/1.5.0/docs/guide/management/overview.html#mxbeans.
[POWERDEVS]
PowerDEVS. http://en.wikipedia.org/wiki/PowerDEVS. Pgina vigente al

31/05/2010.
[PSLINUXCOMMAND]
Linux Command Directory: ps. http://oreilly.com/linux/commanddirectory/cmd.csp?path=p/ps Pgina vigente al 16/10/2011-
[RUNNEABLE]
Interface Runnable - API

http://download.oracle.com/javase/1,5,0/docs/api/java/lang/Runnable.html.
[Salehie & Tahvildari,2009]
Salehie, M. y Tahvildari, L. 2009. Self-adaptive software: Landscape and

research challenges. ACM Transactions on Autonomous and Adaptive Systems
(TAAS). Vol. 4, Nro. 2 Pginas:14:114:42
[Singh et al, 2002]
Singh I., Stearns B. y Johnson M. 2002. Designing Enterprise Applications with

the J2EE Platform.
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/.
Addison-Wesley Longman Publishing Co. Pgina vigente al 26/11/2011.
[Smith & Nair, 2005]
Smith J.E. y Nair R. Mayo 2005. The Architecture of Virtual Machines. IEEE
Computer, Vol. 38, Issue 5. Pginas 3238.
[SNMPJVM]
SNMP Monitoring and

Management. http://java.sun.com/javase/6/docs/technotes/guides/management/s
nmp.html. Pgina vigente al 03/05/2009
[SNMPLINKS]
SNMPLink.org. http://www.snmplink.org/. Pgina vigente al 03/05/2009.
[SPEC JVM98]
SPEC JVM98 Benchmarks. http://www.spec.org/jvm98/. Pgina vigente al

24/04/2009.
[SUN, 2008a]
Sun Microsystems, Inc. 2008. Java SE Monitoring and Management Guide.

http://java.sun.com/javase/6/docs/technotes/guides/management/toc.html
Captulo 3. Pgina vigente al 03/05/2009.
[SUN,2008b]
Sun Microsystems, Inc. 2008. The Java Tutorials:Java Management Extensions

(JMX). http://java.sun.com/docs/books/tutorial/jmx/index.html. Pgina vigente al
18/06/2009.
[SUNJEETutorial]
Sun Microsystems, The Java EE 5 Tutorial,

http://docs.oracle.com/javaee/5/tutorial/doc/. Pgina vigente al 25/06/2012
[SUNMONandMAN]
Sun Microsystems, Inc. Monitoring and Management for the Java

Platform. http://java.sun.com/javase/6/docs/technotes/guides/management/index.
html. Pgina vigente al 03/05/2009.
[SUNVISUALVM]
Sun Microsystems, Inc. 2008. Java VisualVM.

http://java.sun.com/javase/6/docs/technotes/guides/visualvm/index.html. Pgina
171
[TOPLINUXCOMMAND]
Linux Command Directory: top. http://oreilly.com/linux/commanddirectory/cmd.csp?path=t/top Pgina vigente al 16/10/2011-
[Venners, 2000a]
Venners B. 2000. Inside The Java Virtual Machine. McGraw-Hill Osborne

Media. Cap 5.
[Venners, 2000b]
Venners B. 2000. Inside The Java Virtual Machine. McGraw-Hill Osborne

Media. Cap 9.
[Verssimo & Rodrigues, 2001]
Verssimo P. y Rodrigues L. 2001. Distributed Systems For System Architects.

Kluwer Academic Publishers. Pginas 172-180.
[Vuori, 2007]
Vuori J. 2007. A component-based architecture for Self-Healing systems.
[WINE]
WineHQ. http://www.winehq.org/. Pgina vigente al 13/07/2012.
[ZABBIX]
Zabbix. http://www.zabbix.com/. Pgina vigente al 03/10/2011.
[Zeiger et al, 2000]
Zeiger, B., Kim. T. y Praehofer, H. 2000. Theory of Modeling and Simulation.

2nd. edition. Academic Press, New York.
[ZENNOS]
Zennos. http://www.zenoss.com. Pgina vigente al 03/10/2011.
172
ndice de Figuras
Figura 1 - Esquema de funcionamiento de una HLL-VM ......................................................................16
Figura 2 - Arquitectura de la JVM obtenida de [Orlando & Russo, 2006] .............................................18
Figura 3 - Arquitectura de JEE (obtenida de [Singh et al, 2002]) ...........................................................19
Figura 4 - Clases de defectos combinados Parte 1 ...............................................................................25
Figura 5 - Clases de defectos combinados Parte 2 ...............................................................................25
Figura 6 - Control de bucle cerrado ........................................................................................................37
Figura 7 - Esquema del enfoque basado en modelos de arquitectura [Garlan & Schmerl, 2002] ..........37
Figura 8 - Esquema del framework Rainbow. [Garlan et al, 2004] ........................................................38
Figura 9 - Diagrama en bloques de un sistema de control de lazo cerrado tipo SISO ............................39
Figura 10 - Respuesta de un sistema estable ...........................................................................................41
Figura 11 - Arquitectura de JVMMon .....................................................................................................44
Figura 12 - Arquitectura de AQuA ..........................................................................................................45
Figura 13 - Integracin de AQuA J2EE con el JBoss .............................................................................46
Figura 14 - Arquitectura de Rainbow ......................................................................................................48
Figura 15 - Arquitectura de Arco Iris ......................................................................................................50
Figura 16 - Arquitectura del Apache HTTP Server .................................................................................52
Figura 17 - Control tipo MIMO para el Apache HTTP Server ...............................................................53
Figura 18 - Entradas de control y resultados de los experimentos..........................................................53
Figura 19 - Ecuacin del modelo ARX para el Apache Server ...............................................................54
Figura 20 - Resultados de las evaluaciones: (a) y (b) utilizando prediccin de un paso para CPU y
MEM respectivamente. (c) utilizando prediccin multipaso ...............................................54
Figura 21 - Ecuacin en diferencias finitas que rige a un control PI ......................................................55
Figura 22 - Arquitectura de JPDA...........................................................................................................57
Figura 23 - Arquitectura JMX .................................................................................................................60
Figura 24 - Esquema de la solucin propuesta .......................................................................................66
Figura 25 - Arquitectura del JBoss Web Server (obtenida de [JBOSSWEB].) .......................................68
Figura 26 - Arquitectura de Nagios .........................................................................................................70
Figura 27 - Esquema de funcionamiento del NRPE [NRPE] .................................................................74
Figura 28 - Esquema de funcionamiento del NSCA [NSCA] .................................................................74
Figura 29 - Arquitectura de BrainyPDM.................................................................................................76
Figura 30 - Esquema del proceso del sensor ...........................................................................................80
Figura 31 - Diagrama de secuencia del proceso de recepcin de mtricas y transmisin de las
mismas al sistema de control externo...................................................................................80
Figura 32 - Diagrama de clases de los transmisores ...............................................................................81
Figura 33 - Diagrama de clases de los actuadores ..................................................................................83
Figura 34 - Diagrama de secuencia del proceso de actuacin sobre el sistema controlado ....................85
Figura 35 - Esquema del proceso de actuacin .......................................................................................85
Figura 36 - Simulador jerrquico (derecha) asociado a un modelo (izquierda) ......................................88
Figura 37 - Interfaz del editor de PowerDEVS: Editor principal (izquierda). Editor de un modelo
173
(derecha) ...............................................................................................................................89
Figura 38 - Interfaz de edicin de cdigo de los atmicos de PowerDEVS ...........................................89
Figura 39 - Interfaz de simulacin de PowerDEVS ................................................................................90
Figura 40 - Modelo de clases principales de PowerDEVS. ....................................................................91
Figura 41 - Ejemplo de uso de la funcin sendNET ...............................................................................92
Figura 42 - Esquema del mecanismo de subscripcin ............................................................................95
Figura 43 - Diagrama que muestra el registro de un atmico como listener de un puerto .....................96
Figura 44 - Diagrama de secuencia ante la llega de datos por un puerto ................................................97
Figura 45 - Diagrama de secuencia que muestra la comunicacin de los datos recibidos .....................98
Figura 46 - Esquema de recepcin y envo de datos ...............................................................................99
Figura 47 - Controlador: (a) Mquina de estados. (b) Espacio de estados (con histresis). .................103
Figura 48 - Diagrama en bloques de la estrategia de control utilizada .................................................109
Figura 49 - Diseo de la carga de la prueba 1 y su poblacin de usuarios concurrentes ...................... 114
Figura 50 - Prueba 1: Caso de Test 0 (ejecucin sin la plataforma). (a) Consumo de CPU (b)
Memoria Heap libre ........................................................................................................... 115
Figura 51 - Prueba 1: Caso de Test 0 (ejecucin sin la plataforma). (a) Cantidad de threads creados.
(b) Cantidad de threads ocupados ...................................................................................... 115
Figura 52 - Prueba 1: Caso de Test 1. (a) Consumo de CPU (b) Memoria Heap libre ......................... 117
Figura 53 - Prueba 1: Caso de Test 1. (a) Cantidad de threads creados. (b) Cantidad de threads
ocupados ............................................................................................................................. 117
Figura 54 - Prueba 1: Caso de Test 2. (a) Consumo de CPU (b) Memoria Heap libre ......................... 119
ocupados ............................................................................................................................. 119
Figura 56 - Diseo de la carga de la prueba 2 y su poblacin de usuarios concurrentes ......................120
Figura 57 - Prueba 2: Caso de Test 0 (ejecucin sin la plataforma). (a) Consumo de CPU (b)
Memoria Heap libre ...........................................................................................................122
Figura 58 - Prueba 2: Caso de Test 0 (ejecucin sin la plataforma). (a) Cantidad de threads creados.
(b) Cantidad de threads ocupados ......................................................................................122
Figura 59 - Prueba 2: Caso de Test 1. (a) Consumo de CPU (b) Memoria Heap libre .........................124
ocupados .............................................................................................................................124
174
ndice de Listados
Listado 1 - Platform MBeans .................................................................................................................62
Listado 2 - Cdigo de retorno de los plugins de Nagios .........................................................................71
Listado 3 - Comandos configurados para el plugin check_jmx ..............................................................73
Listado 4 - Servicios configurados para la recoleccin de las mtricas. ..............................................105
Listado 5 - Configuracin de los MBeans utilizados en la prueba de concepto ..................................106
Listado 6 - Configuracin del transmisor TransmisorByUDP .............................................................107
Listado 7 - Configuracin del actuador ActuadorByUDP ...................................................................108
Listado 8 - Descripcin de las funciones del modelo Sensor .............................................................. 110
Listado 9 - Descripcin de las funciones del modelo Procesador........................................................ 111
Listado 10 - Descripcin de las funciones del modelo Efector ............................................................ 112
Listado 11 - Cdigo fuente del modelo atmico Sensor ......................................................................137
Listado 12 - Cdigo fuente del modelo atmico Procesador ...............................................................137
Listado 13 - Cdigo fuente del modelo atmico Efector .....................................................................141
175

GGalache PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

GGalache PDF

Cargado por

Copyright:

Formatos disponibles

Universidad de Buenos Aires

Infraestructura para Recuperacin Automtica ante

Tesis de Grado de Ingeniera en Informtica

Guillermina Gabriela Galache

Dr. Rodrigo Castro, FCEyN/UBA (externo)

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

3.2.4.1 - Arquitectura de Apache HTTP Server: Propiedades relevantes del

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

4.4 - Control mediante Modelos en Tiempo Real ....................................................................85

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

6.1.2 - Produccin cientfica .............................................................................................128

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

2004] de referencia obligada en el tema).

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

3. Difcil colaboracin entre distintos dominios de especializacin (e.g. las comunidades

1.3 - Definicin del Problema

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

intervencin humana y en forma transparente para el usuario.

1.5 - Estructura del Informe

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

en modo System-In-The-Loop como contenedor de los modelos de control.

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

Figura 1 - Esquema de funcionamiento de una HLL-VM

2.1.1 - Componentes Principales de la JVM

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

Figura 2 - Arquitectura de la JVM obtenida de [Orlando & Russo, 2006]

2.2 - Servidores de Aplicaciones JEE

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

Un Servidor de Aplicaciones JEE es un Servidor de Aplicaciones que cumple con la

Figura 3 - Arquitectura de JEE (obtenida de [Singh et al, 2002])

Un concepto clave de la arquitectura JEE es el de contenedor, el cual no es ms que un

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

Funcionamiento bsico, existe la posibilidad de utilizar un servidor web externo.

Tesis de Ingeniera en Informtica

Guillermina G. Galache - 77060

funcionalidades crticas comunes a todas las aplicaciones como es el manejo de transacciones, la