trabajo enfocado al b-learning

1. Universidad Nacional del Nordeste
Facultad de Ciencias Exactas, Naturales y Agrimensura
Trabajo Final de Aplicación
Desarrollo de una Aplicación de
B-Learning para el Aprendizaje del
Autonomic Computing
María Laura Regnet - L.U.: 27741
Prof. Orientador: Mgter. David Luis la Red Martínez
Licenciatura en Sistemas
Corrientes - Argentina
2010

3. A mi familia y profesores

4. Prefacio
“la Civilización avanza al extender el número de operaciones importantes que
podemos ejecutar sin pensar en ellas”.
“Sólo nos resta aprender la manera de hacerlo”
En el contexto actual de la llamada Sociedad de la Información y del
Conocimiento resulta cada vez más necesario superar el umbral que los seres
humanos hemos podido lograr al automatizar cada vez más tareas complejas
para alcanzar nuevos progresos.
Este nuevo paradigma computacional implica el diseño e implementación
de sistemas de computación, software, almacenamiento y apoyo que deben
perseguir los principios básicos de: flexibilidad, accesibilidad y transparencia
para el usuario.
El sistema ejecutará sus tareas y se ajustará a las necesidades del usuario
sin que el usuario deba interiorizarse en las complejidades de su funcionamiento.
Este trabajo se basa en el estudio de software de base que permite el
desarrollo de aplicaciones Autonómicas, el estudio de aplicaciones con ésta
tecnología y en el desarrollo de una aplicación Web de aprendizaje y autoevaluación.
Brinda la posibilidad al alumno de aprender y examinarse por si mismo.
Este sistema b-learning de aprendizaje es un método que permite a uno
mismo, valorar su propia “capacidad”, así como la calidad del “trabajo realizado”.
Todo programa de formación busca que el alumno tome conciencia respecto
de lo que puede y no puede hacer, cómo lo hace, etc., y la autoevaluación sería
un proceso que ayuda a desarrollar esta capacidad. A través del desarrollo
de habilidades metacognitivas; esto quiere decir la habilidad de monitorear su
propio proceso cognitivo (aprendizaje, resolución de problemas, etc.).
Por otra parte, la autoevaluación tiene también un objetivo formativo a
más largo plazo. Se espera que los alumnos se transformen en trabajadores
que tengan conciencia de sus propias responsabilidades, que puedan monitorear sus desempeños, juzgarlos, criticarlos y mejorarlos progresivamente. En
este sentido, lo que justifica el método b-learning de aprendizaje es el desarro-

5. v
llo de autonomía, autodisciplina y autocontrol por parte de los alumnos. Esto
significa que, aun cuando objetivos de aprendizaje como compromiso, cooperación y esfuerzo son importantes, la autoevaluación no debe limitarse a ellos
sino que debe referirse a la calidad del propio trabajo respecto a un resultado
esperado.
Objetivos:
El objetivo inicialmente planteado fue la realización de una aplicación Web
multiplataforma desarrollada en Php, mediante la cual el alumno pudiera contar con un medio de ayuda para evaluar a distancia su nivel de conocimientos,
mediante autoevaluaciones, sobre los contenidos del tema.
Estos objetivos planteados al inicio del trabajo, fueron totalmente cumplidos.
Etapas de Desarrollo:
Se ha efectuado una amplia recopilación bibliográfica específica de los temas pertinentes a la tarea planificada y a los productos de software que se
emplearon para la concreción del Trabajo Final.
Se realizaron las traducciones del material de investigación.
Como consecuencia de las gestiones realizadas por el Profesor Orientador
ante IBM Argentina se han recibido materiales en CDs de dicha empresa, en el
marco del Scholars Program de la misma, destinado a Universidades de todo
el mundo; dicho material es el que será detallado a lo largo de éste libro y
son los temas en los que el alumno registrado en el Software Educativo, será
autoevaluado.
Se ha realizado un detallado estudio del entorno de trabajo Scientific WorkPlace 2.5.0 para la escritura del libro correspondiente al informe final.
Se ha realizado un estudio del software para el desarrollo de la aplicación
Php y MySql sobre Servidor Apache.
Se ha realizado el desarrollo de la aplicación utilizando páginas HTML y
Php.
Una vez finalizada la aplicación se realizó la grabación en DVD de todo
el material correspondiente al trabajo final: una versión de la aplicación, otra
referente al libro en formato LaTex y el PDF generado. También se icluyó los
instaladores de los productos utilizados para el desarrollo.

6. vi
Objetivos Logrados:
Se han alcanzado plenamente la totalidad de los objetivos planteados para
el presente trabajo.
Organización del Informe Final:
El informe final comprende un libro impreso y un DVD, además de un
resumen y de un resumen extendido.
El libro impreso está organizado en capítulos, los que se indican a continuación:
Capítulo 1 - Introducción al B-learning: Se presenta una visión general de
los conceptos sobre el aprendizaje combinado (virtual-presencial). Tomando
como eje, las ventajas de innovación que brinda las nuevas tecnologías en el
aprendizaje.
Capítulo 2 - Nociones de Computación Autonómica: Explica la concepción
de éste nueva tecnología para los sistemas. Trata de sus bases, características,
beneficios y algunas aplicaciones.
Capitulo 3 - Arquitectura de AC: Se señalan los distintos niveles de autonomía que brinda la Computación Autonómica. Explica el ciclo de control
inteligente.
Capitulo 4 - Introducción y Tecnologías del Autonomic Computing Toolkit:
En éste capítulo de hace una reseña de la colección de tecnologías, herramientas, ejemplos, escenarios y documentación que fueron diseñados para quienes
quieran aprender y desarrollar capacidades autonómicasen sus sistemas.
Capitulo 5 - Escenarios e Instalación de AC Toolkit: Muestra cómo se
instala el AC Toolkit.
Capitulo 6 - Escenario de determinación del Problema: Con éste escenario,
se muestra como funciona un sistema de autoadministración y lograr introducir
el atributo de auto-reparación de un entorno autonómico.
Capitulo 7 - Instalación de la Solución usando InstallAnywere: Trata sobre
la solución del escenario de instalación que aspira a ser predictivo por naturaleza que habilita el proceso de instalación del software para requerir menos
intervencion del usuario.

7. vii
Capitulo 8 - PHP: Trata sobre las principales características del lenguaje.
Capitulo 9 - Manual MySql: Se explica el paso a paso cómo funciona este
sistema administrador de base de datos.
Capitulo 10 - Descripción de la Aplicación: Se presentan los principales
aspectos del trabajo efectuado.
Capitulo 11 - Conclusiones: Se detallan las conclusiones más significativas
respecto de la aplicación desarrollada utilizando las facilidades antes mencionadas.
El DVD, adjunto al libro impreso, contiene lo siguiente:
Instaladores del software utilizado.
Resúmenes del trabajo realizado.
Libro del informe final.
Presentación para la defensa final.
Copia de seguridad de la base de datos de la aplicación.
Aplicación desarrollada.

8. viii

9. Índice General
1 Introducción al B-Learning
1.1 ¿Qué es B-Learning? . . . . . . . . . . . .
1.2 Surgimiento de la Modalidad B-Learning .
1.2.1 Un Nuevo Rol Docente . . . . . . .
1.2.2 Diferencias en la Formación Mixta
1.3 Hacia un Nuevo Paradigma . . . . . . . .
1.4 Reflexión final . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
3
8
9
10
2 Nociones de Computación Autonómica
2.1 Introducción . . . . . . . . . . . . . . . .
2.2 Situación Problemática . . . . . . . . . .
2.3 Propuesta de Solución . . . . . . . . . .
2.3.1 Novedades de IBM para AC . .
2.3.2 El Nuevo Paradigma AC . . . . .
2.3.3 Estándares Relacionados con AC
2.4 Beneficios Esperados . . . . . . . . . . .
2.5 Características de los Sistemas de AC .
2.6 Algunas Aplicaciones con Tecnología CA
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
13
14
16
17
17
18
19
21
3 Arquitectura de AC
3.1 Niveles de Maduración Autonómica . . . . . . . .
3.2 Arquitectura de Referencia de AC . . . . . . . .
3.2.1 Ciclo de Control . . . . . . . . . . . . . .
3.2.2 Administrador Autonómico . . . . . . . .
3.2.3 Recurso Administrado . . . . . . . . . . .
3.2.4 Interfase de Manejabilidad . . . . . . . . .
3.3 La Arquitectura AC y los Niveles de Maduración
3.4 Arquitectura AC Para Sistemas Personales (PC)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
26
28
29
29
30
30
ix
.
.
.
.
.
.
.
.
.

10. x
4 Introduc. y Tecnologías del AC Toolkit
4.1 Conceptos Generales . . . . . . . . . . . . . . .
4.1.1 Tecnologías . . . . . . . . . . . . . . . .
4.1.2 Herramientas . . . . . . . . . . . . . . .
4.1.3 Escenarios . . . . . . . . . . . . . . . . .
4.1.4 Información y Documentación . . . . . .
4.2 Uso del AC Toolkit . . . . . . . . . . . . . . . .
4.2.1 Comprensión de Conceptos del AC . . .
4.2.2 Tecnologías y Soluciones de AC Toolkit
4.2.3 Uso de Tecnologías del AC Toolkit . . .
4.3 Tecnologías y Herramientas del AC Toolkit . .
4.4 AME . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 Introducción . . . . . . . . . . . . . . .
4.4.2 Modelo de Recursos AME . . . . . . . .
4.5 Log and Trace Analizer . . . . . . . . . . . . .
4.6 Inst. de la Solución y Tecnolog. de Despliegue .
4.7 Adaptador Genérico de Log . . . . . . . . . . .
4.8 Consola de Soluciones Integradas . . . . . . . .
ÍNDICE GENERAL
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
38
38
38
39
39
39
39
40
41
43
43
43
44
45
45
46
5 Escenarios e Instalación de AC Toolkit
49
5.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Escenario de Determinación de Problema . . . . . . . . . . . . 49
5.3 Escenario de Instalación Automática . . . . . . . . . . . . . . . 51
5.4 El Paquete AC Toolkit . . . . . . . . . . . . . . . . . . . . . . . 52
5.4.1 AC Information . . . . . . . . . . . . . . . . . . . . . . . 52
5.4.2 AME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4.3 RMB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4.4 Integrated Solutions Console . . . . . . . . . . . . . . . 54
5.4.5 Solution Installation and Deployment . . . . . . . . . . 54
5.4.6 Generic Log Adapter and Log Trace Analyzer . . . . . . 55
5.4.7 Problem Determination Scenario . . . . . . . . . . . . . 55
5.4.8 Solution Installation and Deployment Scenario Usando
ISMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.4.9 Solution Installation and Deployment Scenario Using
InstallAnywhere . . . . . . . . . . . . . . . . . . . . . . 57
5.5 Descarga del Paquete AC Toolkit . . . . . . . . . . . . . . . . . 58
5.6 Instalación del Paquete AC Toolkit . . . . . . . . . . . . . . . . 58
5.6.1 Vista General de la Instalación . . . . . . . . . . . . . . 58
5.6.2 Prerequisitos . . . . . . . . . . . . . . . . . . . . . . . . 59
5.6.3 Plataformas Soportadas . . . . . . . . . . . . . . . . . . 60

11. ÍNDICE GENERAL
xi
5.6.4 Instalación del Paquete AC Toolkit . . . . . . . .
5.6.5 Desinstalación del Paquete AC Toolkit . . . . . .
5.7 Instalación de la ISC . . . . . . . . . . . . . . . . . . . .
5.7.1 Antes de Comenzar . . . . . . . . . . . . . . . .
5.7.2 Requerimientos Para la Instalación de la ISC . .
5.7.3 Instalación de la ISC . . . . . . . . . . . . . . . .
5.7.4 Desinstalar la ISC . . . . . . . . . . . . . . . . .
5.8 Arrancar y Detener la ISC . . . . . . . . . . . . . . . . .
5.8.1 Secuencia Gráfica de Arranque y Detención de la
5.9 Instalar el Plug-in de la ISC . . . . . . . . . . . . . . . .
5.10 Verificación de la Instalación . . . . . . . . . . . . . . .
5.11 Resolver Problemas de Instalación . . . . . . . . . . . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
ISC
. . .
. . .
. . .
6 Escenario de Determinación de Problemas
6.1 Introducción al escenario de Determinación de Problemas
6.2 Componentes y Diseño de Escenario . . . . . . . . . . . .
6.2.1 Diseño del Escenario Problem Determination . . .
6.3 Componentes del Escenario de DP . . . . . . . . . . . . .
6.3.1 Componentes del Recurso Administrado . . . . . .
7 Instalación de la Solución
7.1 Introducción . . . . . . . . . . . . . . . . . . .
7.2 Beneficios . . . . . . . . . . . . . . . . . . . .
7.3 Diseño del Escenario y de los Componentes .
7.4 Instalación y Escenario de Despliegue . . . .
7.5 Ejecutar la Solución y Escenario para IA . . .
7.5.1 Iniciar y Detener el Escenario . . . . .
7.5.2 Verificar los resultados del escenario .
7.5.3 Personalizar el Escenario . . . . . . .
7.5.4 Usar el Editor SMD . . . . . . . . . .
7.6 Ejecutar la Solución y Escenario para ISMP .
7.6.1 Iniciar y Detener el Escenario . . . . .
7.6.2 Verificar los Resultados del Escenario
7.6.3 Personalizar el Escenario . . . . . . .
8 Ejemplos con Tecnologías A-C
8.1 DB2 Universal database . . . . . . . . . .
8.1.1 Funciones Complementarias . . . .
8.2 Tivoli Monitoring . . . . . . . . . . . . . .
8.2.1 Administrador de Servicios Tívoli .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
62
62
62
63
64
73
73
74
77
77
78
.
.
.
.
.
81
81
84
85
87
87
.
.
.
.
.
.
.
.
.
.
.
.
.
99
99
100
101
102
105
105
106
107
107
108
108
109
110
.
.
.
.
111
111
114
117
117

12. xii
ÍNDICE GENERAL
8.3
8.2.2 Acciones del Menu . . . . . . . . . . . . . . . .
WebSphere . . . . . . . . . . . . . . . . . . . . . . . .
8.3.1 Introducción a WebSphere . . . . . . . . . . . .
8.3.2 La Integración en el e-business on demand . . .
8.3.3 Plataforma de Software . . . . . . . . . . . . .
8.3.4 Arquitecturas de Tres Niveles . . . . . . . . . .
8.3.5 Familias del Producto . . . . . . . . . . . . . .
8.3.6 La familia de Herramientas WebSphere Studio
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
118
128
128
131
132
136
139
141
9 WebSphere Application Server
143
9.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
9.2 WebSphere Application Server . . . . . . . . . . . . . . . . . . 143
9.3 Fundamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
9.4 WebSphere Development Environment . . . . . . . . . . . . . . 147
9.5 Conceptos del WebSphere Application Server . . . . . . . . . . 148
9.5.1 e-business . . . . . . . . . . . . . . . . . . . . . . . . . . 148
9.5.2 La Familia WebSphere y las Soluciones Para el e-business148
9.5.3 Computación Distribuida y WebSphere Application Server150
9.5.4 WebSphere Application Server, Standard and Advanced
Editions . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
9.6 Arquitectura de WebSphere . . . . . . . . . . . . . . . . . . . . 160
9.6.1 Servidor de Aplicaciones . . . . . . . . . . . . . . . . . 160
9.6.2 HTTP Server y Plug-in . . . . . . . . . . . . . . . . . . 161
9.6.3 Embedded HTTP Server (Servidor HTTP Incluído) . . 161
9.6.4 Virtual Hosts (Hosts Virtuales) . . . . . . . . . . . . . 162
9.6.5 Servidor de Grupos . . . . . . . . . . . . . . . . . . . . 162
9.6.6 Clones . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
9.6.7 Contenedor Web . . . . . . . . . . . . . . . . . . . . . . 163
9.6.8 EJB Container (Contenedor EJB) . . . . . . . . . . . . 165
9.6.9 El Modelo Administrativo WebSphere . . . . . . . . . . 165
9.6.10 Servidor Administrativo . . . . . . . . . . . . . . . . . . 166
9.6.11 Almacenamiento Administrativo . . . . . . . . . . . . . 167
9.6.12 Interfases Administrativas . . . . . . . . . . . . . . . . 167
9.6.13 Referencia Rápida para la Administración . . . . . . . . 170
9.6.14 Discusión . . . . . . . . . . . . . . . . . . . . . . . . . . 170
9.6.15 ¿Qué son los Recursos? . . . . . . . . . . . . . . . . . . 172
10 PHP
173
10.1 Introducción a la Programación Php . . . . . . . . . . . . . . . 173
10.2 ¿Qué se puede hacer con PHP? . . . . . . . . . . . . . . . . . . 174

13. ÍNDICE GENERAL
10.3 Referencia del Lenguaje . . . .
10.3.1 Sintaxis Básica . . . . .
10.3.2 Tipos de Datos . . . . .
10.3.3 Variables . . . . . . . .
10.3.4 Constantes . . . . . . .
10.3.5 Operadores . . . . . . .
10.3.6 Estructuras de Control .
10.3.7 Funciones en PHP . . .
xiii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11 Sistema de Gestión de Base de Datos
11.1 ¿Por qué MySQL? . . . . . . . . . . .
11.1.1 Obtención de MySQL . . . . .
11.2 Principales Características . . . . . . .
11.3 Tipos de Datos . . . . . . . . . . . . .
11.3.1 Cadena de Caracteres . . . . .
11.3.2 Numéricos . . . . . . . . . . . .
11.4 Tipos de Tablas . . . . . . . . . . . . .
11.4.1 ISAM . . . . . . . . . . . . . .
11.4.2 MYSAM . . . . . . . . . . . . .
11.4.3 BerkeleyDB . . . . . . . . . . .
11.4.4 InnoDB . . . . . . . . . . . . .
11.4.5 ¿En qué casos usar cada una? .
11.5 Seguridad . . . . . . . . . . . . . . . .
11.6 Backup de Base de Datos . . . . . . .
11.6.1 Conectar a MySQL desde PHP
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
177
177
178
179
183
185
187
190
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
193
193
194
194
197
197
200
204
205
205
206
206
208
208
209
209
12 Descripción de la Aplicación
12.1 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.1.1 UML (Lenguaje Unificado de Modelado) . . . . . . . . .
12.1.2 Herramienta CASE (Ingeniería de Software Asistida por
Computador): Entreprise Architect . . . . . . . . . . . .
12.2 Desarrollo del Sistema . . . . . . . . . . . . . . . . . . . . . . .
12.2.1 Estructuras de Datos Utilizadas . . . . . . . . . . . . . .
12.2.2 Código Fuente Utilizados: Ejemplos . . . . . . . . . . .
211
211
211
217
220
225
228
13 Conclusión
255
13.1 Conclusiones del Trabajo realizado . . . . . . . . . . . . . . . . 255
13.2 Líneas Futuras de Acción . . . . . . . . . . . . . . . . . . . . . 256

14. xiv
ÍNDICE GENERAL
Bibliografía
257
Índice de Materias
259

15. Índice de Figuras
2.1
2.2
Tecnologías para los emprendimientos, con innovación y productividad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dispositivos fuera de servicio. . . . . . . . . . . . . . . . . . . .
13
14
3.1
3.2
3.3
Arquitectura de referencia de AC. . . . . . . . . . . . . . . . .
Arquitectura de un Elemento Autonómico. . . . . . . . . . . . .
Ejemplo de dos Jerarquías de Control Autonómico. . . . . . . .
27
31
33
5.1
5.2
5.3
65
65
5.10
5.11
5.12
5.13
5.14
5.15
5.16
Ventana de bienvenida a la ISC. . . . . . . . . . . . . . . . . . .
Ventana de licencia de la ISC. . . . . . . . . . . . . . . . . . . .
Ventana de información de la ubicación de la instalación de la
ISC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ventana de cuentas de administrador de la ISC. . . . . . . . . .
Nombre del host y localización del puerto. . . . . . . . . . . . .
Localizaciones de puertos nuevos - ventana 1. . . . . . . . . . .
Localizaciones de puertos nuevos - ventana 2. . . . . . . . . . .
Ventana de plug-ins del WSphere Application Developer. . . .
Ventana de localización de instalación del WebSphere Studio
Application Developer. . . . . . . . . . . . . . . . . . . . . . . .
Ventana de localización e información de la instalación de la ISC.
Proceso de extracción de la ISC. . . . . . . . . . . . . . . . . .
Proceso de finalización de la ISC. . . . . . . . . . . . . . . . . .
Ventana del proceso final de la instalación de la ISC. . . . . . .
Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
71
71
72
72
74
75
75
6.1
6.2
6.3
Diseño del escenario de determinación del problema. . . . . . .
Arquitectura de un escenario de determinación del problema. .
Panel de navegación de la ISC. . . . . . . . . . . . . . . . . . .
85
86
95
5.4
5.5
5.6
5.7
5.8
5.9
xv
66
67
67
68
68
69

16. xvi
ÍNDICE DE FIGURAS
6.4
6.5
Portlet de control de página. . . . . . . . . . . . . . . . . . . .
Induciendo y corrigiendo una condición de error. . . . . . . . .
8.1
8.2
8.3
Almacenamiento de Documentos XML en DB2. . . . . . . . . . 113
Esquema Conceptual de los Almacenes de Datos. . . . . . . . . 115
Plataforma de WebSphere. . . . . . . . . . . . . . . . . . . . . . 129
9.1
9.2
9.3
9.4
9.5
WebSphere para e-bussines. . . . . . . . . . . . . . . . . . . . .
WebSphere Application Server. . . . . . . . . . . . . . . . . . .
Arquitectura Cliente-Servidor de Tres Niveles. . . . . . . . . . .
Componentes del Ambiente de WebSphere Advanced Edition. .
Arquitectura de WebSphere Application Server Advanced Edition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modelo Administrativo de WebSphere. . . . . . . . . . . . . . .
Interfases Administrativas. . . . . . . . . . . . . . . . . . . . . .
Modelo de Administración. . . . . . . . . . . . . . . . . . . . .
9.6
9.7
9.8
95
97
144
147
151
155
160
166
168
171
10.1 Precedencia de Operadores . . . . . . . . . . . . . . . . . . . . 186
12.1 Diagrama de Casos de Usos-Actores . . . . . . .
12.2 Diagrama de Casos de Uso-Caso de Uso . . . . .
12.3 Actor . . . . . . . . . . . . . . . . . . . . . . . .
12.4 Caso deUso - Enterprise Arquitect . . . . . . . .
12.5 Diagrama de Casos de Uso - Enterprise Arquitect
12.6 Inicio de la Aplicación . . . . . . . . . . . . . . .
12.7 Menú de Alumno . . . . . . . . . . . . . . . . . .
12.8 Selección por Temas . . . . . . . . . . . . . . . .
12.9 Material de Lectura . . . . . . . . . . . . . . . .
12.10Agregar Tema Nuevo . . . . . . . . . . . . . . . .
12.11Menú del Administrador . . . . . . . . . . . . . .
12.12Agregar Respuestas . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
216
216
219
219
221
222
223
224
224
225
226
226

17. Índice de Tablas
2.1
Estados de enlace basados en el contexto. . . . . . . . . . . . .
23
5.1
5.2
Espacio requerido por instalaciones Linux y AIX. . . . . . . . .
Espacio requerido por instalaciones Windows. . . . . . . . . . .
60
61
6.1
Estados de enlace basados en el contexto. . . . . . . . . . . . .
97
11.1 BloB y Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
xvii

19. Capítulo 1
Introducción al B-Learning
1.1
¿Qué es B-Learning?
B-Learning es la abreviatura de Blended Learning, término inglés que en términos de enseñanza virtual se traduce como ”Formación Combinada” o ”Enseñanza Mixta”. Se trata de una modalidad semipresencial de estudios que
incluye tanto formación no presencial (cursos on-line, conocidos genéricamente
como e-learning ) como formación presencial.
Se está empezando a adoptar este modelo de formación on-line en nuestro
país, ya que combina las interesantes ventajas de la enseñanza on-line (aulas
virtuales, herramientas informáticas, Internet) con la posibilidad de disponer
de un profesor como supervisor de los cursos.
Teniendo en cuenta que las nuevas tecnologías brindan posibilidades de
innovación en los procesos del aula, éste sistema se presenta como una experiencia diferente para el alumno mediante un diseño pedagógico que combina
la formación presencial con las virtualidades de un diseño de medida. En
su dimensión pedagógica contempla la integración de recursos tecnológicos en
busca de resultados formativos aplicables a necesidades de aprendizaje individualizadas.
1

20. 2
CAPÍTULO 1. INTRODUCCIÓN AL B-LEARNING
1.2
Surgimiento de la Modalidad B-Learning
La sociedad de la información está entre nosotros y es parte de nuestra cotidianidad, sin embargo no es lo mismo hablar de información que de conocimiento,
la información disponible y accesible a través de las nuevas tecnologías facilita
la construcción del conocimiento, pero para conocer, en el sentido de saber,
comprender y poder utilizar la información de manera pertinente, se requiere
el esfuerzo sistemático y constructivo de cada sujeto, se necesita relacionar
en forma significativa la información, se necesita construir nuevos conceptos y
aportar nuevas reflexiones. [3] [13]
La educación para el Siglo XXI, permanente (a lo largo de toda la vida)
y abierta (a todas las personas), inmersa dentro de una sociedad en la que el
conocimiento será una de las
fuerzas que harán peso en el balance socio-económico que conlleva el desarrollo (o el subdesarrollo), tendrá como uno de sus grandes aliados potenciales
las tecnologías de información y de comunicación (TICs).
En este escenario y conjugación de realidades, es donde el software educativo se perfila como la herramienta base de las próximas generaciones de
educandos. Esto exige, a su vez, el diseño de metodologías y herramientas
adecuadas para satisfacer los nuevos requerimientos.
Un software educativo es todo programa para computadora que se desarrolla con la finalidad específica de ser utilizado como recurso didáctico en
procesos de enseñanza y de aprendizaje.
Según lo expresado por se ha descubierto que, como consecuencia de muchas actividades emprendidas cuando se utiliza software educativo, los estudiantes pueden responsabilizarse más de su propio aprendizaje que en otros
casos. A su vez, se ha observado que la utilización de estos recursos tiene
implicancias en el clima de la clase y ayuda a crear ambientes enriquecidos de
aprendizaje y favorece el aprendizaje significativo.
Self hace aportes en relación a las funciones que puede cumplir un software educativo en una situación de enseñanza y de aprendizaje, al expresar
que promueven la motivación, aportan estímulos nuevos, activan la respuesta del alumno, proporcionan información, estimulan la práctica, establecen la
sucesión de aprendizajes y proporcionan recursos.
De acuerdo a los resultados del estudio realizado por Kulik y Cohen en

21. 1.2. SURGIMIENTO DE LA MODALIDAD B-LEARNING
3
torno al empleo de programas educativos en el ámbito universitario, podemos
decir que el uso de software
educativo favorece el desarrollo de actitudes positivas de los alumnos tanto
hacia el área de conocimiento específica como hacia el uso de las computadoras.
El modelo mixto que combina los mejores recursos de la ofertas educativas
presenciales y las realizadas en una modalidad a distancia llamado blended
learning (b-learning) ha demostrado ser la tendencia actual, debido a la posibilidad para los docentes de analizar la mejor propuesta didáctica con incorporación de todos los recursos de acuerdo a los destinatarios, contexto y
temática a abordar o habilidad a desarrollar en los alumnos.
Se pueden identificar dos estrategias que tratan de mejorar la calidad con
blended learning: una es otorgar más responsabilidad a los estudiantes en su
estudio individual proporcionándoles destrezas para dicho estudio, y la otra es
mejorar la calidad de las clases mediante el uso de presentaciones Multimedia.
Es en este sentido que las tecnologías adquieren relevancia en el tratamiento
de los contenidos y garantizan la atención y el interés de los alumnos. (Litwin,
1997). Así, esta nueva metodología reivindica el contacto alumno-docente que
había perdido protagonismo y que resulta esencial para superar los inconvenientes que produce el e-learning tales como: la dificultad de sentirse parte
de una comunidad educativa, el elevado grado de motivación necesario para
seguir un curso online, entre otros. Es por ello que se plantea la necesidad
de un nuevo rol docente, que combine estrategias de su rol tradicional (como
educador en cursos presenciales) y de su rol como mentor (en cursos online)
según las necesidades específicas del curso.
1.2.1
Un Nuevo Rol Docente
En base a su formación docente, el profesor de un curso presencial sabe cuáles
son las tareas, actividades y responsabilidades pedagógicas y administrativas
que posee como tal. Pero, ¿sabe el mentor cuáles son las suyas?
La función del mentor puede ser ejercida por un profesor, un ayudante de
cátedra, un consejero o un graduado que haya obtenido logros importantes
en su carrera profesional o académica. En cualquiera de estos casos, la circunstancia de conocer ”desde adentro” las necesidades de los alumnos, facilita
el desempeño de su rol como mentor y le otorga a su función la importancia

22. 4
CAPÍTULO 1. INTRODUCCIÓN AL B-LEARNING
insustituible de poder responder con ello a las necesidades específicas de su
alumnado.
El perfil deseado del mentor es el de un docente que conozca:
• Las posibilidades, requerimientos y características de una formación online.
• Las características, necesidades y hábitos de los alumnos.
• Los contenidos del curso y materia, incluyendo materiales y recursos
pertinentes para el aprendizaje.
• El medio en el que se desarrolla la comunicación didáctica, el entorno
comunicativo.
Es por ello que considerar al mentor sólo como la persona encargada del
diseño del currículum, de la elaboración de los contenidos del curso y del
empleo de estrategias pedagógicas sería ignorar otros tantos aspectos que hacen
de su tarea una función esencial para lograr un aprendizaje significativo.
A partir de lo expuesto, se puede analizar su rol en base a distintos aspectos:
• Como diseñador de contenidos,
• Como facilitador de la comunicación pedagógica y,
• Como guía y modelo en la formación sincrónica y asincrónica.
Por consiguiente, es de fundamental importancia, como se mencionó anteriormente, que el docente/mentor conozca el medio en el que se desarrolla
la formación ya que sus saberes y capacitación permanente, en el área de las
nuevas tecnologías, serán imprescindibles para su rol. Es necesario que dicha capacitación trascienda los límites de los aspectos técnicos y considere la
didáctica que incorpora las nuevas tecnologías como medio.
En este sentido, y a partir del análisis bibliográfico, surge también la importancia de que el docente haya experimentado la educación a distancia como
alumno antes de desempeñarse como mentor ya que dicha experiencia se considera sumamente enriquecedora para su formación.

23. 1.2. SURGIMIENTO DE LA MODALIDAD B-LEARNING
5
Mentor:diseñador de contenidos
El mentor (o grupo de mentores) que afronta un proceso b-learning desarrolla, como diseñador de contenidos y siempre teniendo en cuenta las necesidades
del alumnado, las siguientes funciones:
• Diseña el material: selecciona los contenidos y realiza las actividades que
considere necesarias. La digitalización del material se podrá realizar en
distintos formatos tales como texto, gráfico, sonido, fragmento de vídeos,
etc., los cuales permitirán la interactividad con los alumnos.
• Define los temas de discusión: aquí establece los temas a tratarse en el
foro (comunicación asincrónica) o en el chat (comunicación sincrónica)
relacionándolos con las lecturas u otros contenidos del curso e indicando,
claramente, cuáles son las preguntas o aspectos a los que deben responder
los alumnos. Asimismo, debe globalizar los temas de aprendizaje, de
manera que ofrezca una estructuración más compleja de los contenidos
que se van generando, evitando así, su presentación de forma aislada.
• Resume los aportes en los debates: a modo de conclusión, y haciendo
hincapié en las ideas claves de los temas tratados, realiza un informe
general antes de relacionarlo con otro tema.
• Distribuye tareas: se encarga de asignar, a los distintos mentores del
grupo, las tareas para el diseño del material, determina, asimismo, las
pautas para su formato y edita el material que se compile.
• Establece y responde preguntas usuales: en este espacio, cumple la doble
función de alivianar su tarea de responder preguntas muy frecuentes
entre los alumnos y de ofrecerles, a los mismos, una guía práctica sobre
los temas más consultados.
• Selecciona noticias y eventos: decide cuáles serán las noticias y los eventos que deban publicarse para el conocimiento de los alumnos. Todo ello
de forma actualizada y en el momento oportuno.
• Elimina contenidos: debe controlar que los contenidos, temas de discusión, eventos, noticias, etc., sólo permanezcan en el soporte virtual el
tiempo necesario a fin de que el exceso de información no vaya en desmedro de la claridad imprescindible para una comprensión clara por parte
de los alumnos.

24. 6
CAPÍTULO 1. INTRODUCCIÓN AL B-LEARNING
• Sugiere fuentes alternativas de consulta: además de los materiales y de
las actividades que diseña debe ofrecer sitios de consulta alternativos
para que el alumno amplíe los temas tratados y desarrolle habilidades
de autogestión y autorregulación de su propio aprendizaje.
Mentor: facilitador de la comunicación pedagógica
Si bien para ser facilitador se deben dominar ciertas estrategias y habilidades pedagógicas y de comunicación, su esencia se encuentra en el entusiasmo,
el compromiso y la dedicación intelectual que el mentor aporte a la dinámica.
Es decir, su propia actitud ante el curso.
En este aspecto, las funciones del mentor serán las siguientes:
• Capacitar a los alumnos: para lograr una mejor y más efectiva comunicación, realiza charlas de capacitación, en las cuales explica la forma de
utilizar el medio en el cual se desarrolla dicha formación. En este sentido,
McIsaac y Gunawardena (1996) describen cuatro tipos de interacción
1. estudiante-mentor (que proporciona motivación, retroalimentación,
diálogo, orientación, etc.);
2. estudiante-contenido (acceso a los contenidos propuestos por los
mentores);
3. estudiante-estudiante (intercambio de información, ideas, motivación, ayuda no jerarquizada, etc.) y
4. estudiante interfase comunicativa (toda la comunicación entre los
alumnos y el acceso a la información se realiza a través de algún
tipo de interfase).
• Socializa: debe esforzarse por crear un ambiente agradable de comunicación, interactuando constantemente con los alumnos y respondiendo a
sus consultas.
• Dinamiza: tiene la facultad para proponer a los alumnos que, en determinados momentos, compartan con él alguna actividad sincrónica a
través del chat o asincrónica en el foro, a fin de incentivarlos e implicarlos
positivamente en su desarrollo.

25. 1.2. SURGIMIENTO DE LA MODALIDAD B-LEARNING
7
• Establece reglas de comunicación: en las discusiones sincrónicas y asincrónicas es importante que determine y controle reglas básicas para la
comunicación. Así es que debe asegurarse de que el alumno conozca los
mecanismos del uso del software y el comportamiento razonable, entre
otras cosas. Para el caso de que se hiciera una mala utilización del medio virtual, y a fin de obtener un nivel académico más elevado de los
contenidos, el mentor debe evitar realizar las observaciones en público,
comunicándoselas directamente al alumno a su correo personal.
Mentor: guía y modelo en la formación sincrónica y asincrónica
La imagen del mentor en el soporte virtual representa, en el alumno, un
modelo a seguir y es una fuente de consulta y guía a lo largo de proceso. Sus
funciones serán:
• En los aspectos técnicos: en este tipo de metodología es muy probable
que, al iniciarse el curso, los alumnos se encuentren frente a problemas
técnicos debido a distintas razones (nivel de los recursos tecnológicos,
el acceso a internet, etc.). También es importante que el mentor tenga
presente que en muchos casos los alumnos no se encuentran familiarizados con el ordenador. Es en este sentido que el mentor actúa como guía
en el uso de las nuevas tecnologías para evitar la frustración del alumno
que encuentre inconvenientes y su potencial deserción. Dicha ayuda técnica, por parte del mentor, debe realizarse por medios alternativos tales
como: vía telefónica, o en forma presencial en su oficina de trabajo con
un horario establecido para recibir a los alumnos.
• En la retroalimentación: el mentor cumple un rol fundamental al responder las preguntas del alumno, guiándolo en su aprendizaje, aclarando dudas y señalándole las posibilidades que tiene a su alcance a fin de
mejorar su aprendizaje.
• En el uso del lenguaje: la forma, el tono y el modo en que el mentor se
comunica con los alumnos, responde dudas, realiza comentarios, expone
resúmenes, aconseja, etc., servirán como modelo para los alumnos al
momento de realizar sus intervenciones.

26. 8
CAPÍTULO 1. INTRODUCCIÓN AL B-LEARNING
1.2.2
Diferencias en la Formación Mixta
Ésta nueva metodología de enseñanza a través del b-learning, que aprovecha
los puntos fuertes del enfoque virtual y el presencial, presenta características
particulares en cada uno de esos aspectos, a saber:
En el entorno tradicional presencial:
• el docente:
es fuente y transmisor del conocimiento;
establece los contenidos curriculares;
determina las estrategias y actividades de aprendizaje;
evalúa los procesos y resultados de aprendizaje,
• el alumno:
actúa como un agente pasivo;
no interviene en las decisiones de los contenidos a prender;
• el aula:
los alumnos y el docente coinciden en el tiempo y el espacio,
lugar donde se transmite el conocimiento.
• los contenidos y actividades: son obligatorios para los alumnos.
• la comunicación: no existe una dialéctica de la comunicación.
• el proceso de aprendizaje: centrado en el docente.
• el material didáctico: recursos tecnológicos limitados.
En el entorno virtual:
• el docente:
actúa como guía, facilitador, mediador, diseñador, socializador, etc.
establece los contenidos ampliatorios a partir de las necesidades de los
alumnos,
determina estrategias y actividades de aprendizaje a partir de los aportes y las consultas que recibe,
no evalúa procesos o resultados de forma numérica, lo hace a través
del monitoreo de las contribuciones de los alumnos ofreciéndoles
comentarios, consejos, etc. en los casos que fuera necesario.

27. 1.3. HACIA UN NUEVO PARADIGMA
9
• el alumno:
posee autnomía en la disposición del tiempo y del ritmo en el proceso
de aprendizaje, así como del espacio en que el mismo se produce,
actúa como agente activo en el proceso de aprendizaje.
• el aula (virtual):
los alumnos entre sí y con el mentor no coinciden en tiempo y espacio,
sólo en aquellos casos en que acuerden compartir una actividad
comunicativa sincrónica en el chat.
lugar de construcción e intercambio de conocimientos.
• los contenidos y actividades:
no son obligatorios para los alumnos.
• la comunicación:
existe una dialéctica de la comunicación entre el mentor y los alumnos
y entre los alumnos entre sí.
• el proceso de aprendizaje:
centrado en la relación entre el docente-alumno, alumno-alumno y el
alumno-conocimiento.
• el material didáctico:
recursos tecnológicos disponibles como soporte para la materia.
1.3
Hacia un Nuevo Paradigma
Como ya se ha dicho en las páginas anteriores, la experiencia de b-learning que
combina la formación presencial en el aula con las potencialidades de la Web:
interacción, rapidez, flexibilidad, economía, acceso, entre otros. Esta mezcla
de canales de comunicación, información y aprendizaje enriquece la formación
permitiendo una participación activa de los distintos agentes involucrados.

28. 10
CAPÍTULO 1. INTRODUCCIÓN AL B-LEARNING
Un modelo que se hace realizable con apoyo de tecnología. Al plantearse la
modalidad b-learning es preciso considerar qué parte de la asignatura debe ser
presencial y qué parte virtual, qué parte puede ser de autoaprendizaje y qué
parte mediada, qué parte sincrónica y qué parte asincrónica, qué papel debe
jugar el docente en el aula y cual el mentor, dónde se sitúan las actividades
individuales y actividades en grupo, cómo se incluyen foros de discusión que recopilen pero también generen conocimiento, cómo organizar ese conocimiento,
cómo diseñar las comunidades de aprendizaje o de práctica, qué tecnologías
y recursos podemos emplear (audio, video), cómo se realiza el acceso y la
distribución de los contenidos, si podemos o no emplear otras herramientas
tecnológicas, cómo lograr la personalización del sistema a la medida de las
necesidades de cada usuario.
La selección de los recursos más adecuados y la determinación de sus funcionalidades y posibilidades es la clave del modelo. Se habla de que se ”mezclan”
instancias presenciales (áulicas) y no presenciales (virtuales), para mejorar situaciones de aprendizaje en función de los objetivos educativos. Es importante
notar que no se hace referencia a estrategias utilizadas todas al mismo tiempo
sino en diferentes momentos del proceso.
1.4
Reflexión final
Del análisis desarrollado, surge de manera clara, una diferencia clave entre el
b-learning y la enseñanza presencial tradicional: la flexibilidad.
Ésta se observa tanto en el sistema como en el mentor, refiriéndose, en
el primer caso, a seis dimensiones básicas (tiempo, espacio, ritmo, entorno,
acceso y currículum), y en el segundo, a la influencia fundamental que ella
ejerce en la relación que se establece entre aquél, los alumnos y los contenidos.
Este concepto, combinado con la idea de que el conocimiento se presenta
como un constructo social enriquecido por la interacción en un entorno virtual,
lleva necesariamente a la conclusión de que la efectividad en una gestión blearning, no se basa en la tecnología hardware y software, sino, principalmente,
en el protagonismo que adquiere este nuevo rol del mentor en el desarrollo de
este tipo de aprendizaje colaborativo.

29. Capítulo 2
Nociones de Computación
Autonómica
2.1
Introducción
Según Alfred North Whitehead “la Civilización avanza al extender el número
de operaciones importantes que podemos ejecutar sin pensar en ellas”.
Esta cita hecha por el eminente matemático Alfred North Whitehead contiene tanto la cerradura como la llave a la próxima era de la informática.
Implica el momento de superar el umbral sólo después de que los humanos
ha podido automatizar cada vez más tareas complejas para alcanzar nuevos
progresos.
Se cree que estamos actualmente sobre tal umbral en informática. Los millones de negocios, miles de millones de humanos que los componen, y billones
de aparatos de los que se dependerá en todo momento, requieren los servicios
de las industrias de IT para asegurar su funcionamiento. Y no es sólo cuestión
de números. Es la complejidad de estos sistemas y la manera en que trabajan
juntos la que crea una escasez de expertos en las IT para manejar todos los
sistemas. Es un problema que crecerá exponencialmente, lo mismo que nuestra
dependencia hacia dichas tecnologías [4] [19].
Para abreviar, no podemos esperar por mucho tiempo a los expertos en las
IT.
11

30. 12
CAPÍTULO 2. NOCIONES DE COMPUTACIÓN AUTONÓMICA
Pero como Whitehead tan elocuentemente lo dijo hace casi un siglo, la
solución estaría en la automatización, en crear una capacidad nueva donde
importantes (y complejos) procesos informáticos puedan ejecutarse sin la necesidad de la intervención humana. El 15/10/2001, Paul Horn, vicepresidente
senior de IBM Research, dirigió la Conferencia de Agenda, una reunión anual
de las mentes tecnológicas más prominentes, que se desarrolló en Arizona,
EE.UU. En su presentación y en un documento que distribuyó allí, sugirió
una solución: sistemas de computación que se autorregulen, de la misma manera en que nuestro sistema nervioso autonómico regula y protege nuestros
cuerpos.
Este nuevo modelo de computación se llamaba autonomic computing o
computación autonómica. Las buenas noticias son que algunos componentes de esta tecnología ya están disponibles. Sin embargo, no existen todavía
sistemas autonómicos completos.
Ésta no es una solución propietaria de IBM. Es un cambio radical de la
forma de manejar los negocios, la educación, el gobierno, etc., desarrollando,
operando y manteniendo sistemas de computadoras. La Computación Autonómica (CA) exige un área nueva de estudio y una manera nueva de conducir
los negocios.
Este nuevo paradigma cambia la definición fundamental de la tecnología
computacional de un paradigma centrado en los equipos, a uno centrado en
los datos. El acceso a datos de fuentes múltiples, distribuidas, además de las
fuentes centrales tradicionales de almacenamiento, brindará a los usuarios el
acceso a la información transparentemente, cuando y donde lo requieren. Al
mismo tiempo, esta nueva visión de la informática hará necesario cambiar el
enfoque de la industria computacional centrado en la velocidad de los procesos
y en el almacenamiento, a un enfoque de desarrollo distribuido en redes que
sean ampliamente auto-gestionadas, auto-diagnosticadas, y transparentes al
usuario.
En este contexto es en el cual la innovación y la productividad se deben
hacer presentes para facilitar la incorporación de las nuevas tecnologías y paradigmas que las sustentan, a los emprendimientos informáticos de la sociedad
de la información y del conocimiento. Ver Fig. 2.1 de la pág. 13.

31. 2.2. SITUACIÓN PROBLEMÁTICA
13
Figura 2.1: Tecnologías para los emprendimientos, con innovación y productividad.
2.2
Situación Problemática
Durante las pasadas dos décadas el desarrollo de la informática impulsada por
la proliferación de equipos de computación ha crecido a ritmo exponencial.
Este crecimiento fenomenal junto con el advenimiento de la Internet ha llevado
a una nueva era de accesibilidad a otras personas, otros sistemas, y lo más
importante, a más información [5].
Este boom de crecimiento ha llevado también a niveles de complejidad sin
precedentes.
Para satisfacer las necesidades de los usuarios, los sistemas de computación
se vuelven más complejos y más costosos de instalar y mantener. Hoy, los
sistemas administradores deben contar con cientos de subsistemas y miles de
parámetros, para tener corriendo los sistemas, y hay que enfrentarse a costos
administrativos elevadísimos además de los de la adquisición de software y
hardware.
La explosión simultánea de información e integración de tecnología en la
vida cotidiana han traído nuevas demandas acerca de cómo las personas manejan y mantienen sistemas de computación. El número de puestos de trabajo
de IT vacantes sólo en los Estados Unidos es de cientos de miles. Aún en

32. 14
CAPÍTULO 2. NOCIONES DE COMPUTACIÓN AUTONÓMICA
Figura 2.2: Dispositivos fuera de servicio.
tiempos de crecimiento económico incierto, la demanda de especialistas en IT
se estima que crecerá por encima del 100% en los próximos seis años.
Como el acceso a la información se vuelve omnipresente debido a las PCs,
los dispositivos manuales y los aparatos inalámbricos, la estabilidad de la actual infraestructura, los sistemas, y los datos, están en un cada vez más alto
riesgo de sufrir salidas de servicio y daño general. Ver Fig.2.2 de la pág. 14.
IBM cree que estamos alcanzando rápidamente un momento umbral en
la evolución de la informática en general y de la infraestructura asociada,
el middleware, y los servicios que los mantienen. La creciente complejidad
del sistema llega a un nivel más allá de la habilidad humana de manejarlo y
asegurarlo.
Esta complejidad creciente con una escasez de profesionales experimentados de IT, apuntan hacia una inevitable necesidad de automatizar muchas de
las funciones hoy asociadas con la computación.
2.3
Propuesta de Solución
La CA busca satisfacer necesidades con la mínima intervención de la administración humana. Los sistemas autonómicos (SA) se adaptan a los cambios de

33. 2.3. PROPUESTA DE SOLUCIÓN
15
condiciones y a las cargas de trabajo, solucionan errores y fallas ellos mismos,
y se preparan para defenderse de un próximo ataque.
Estos sistemas se manejan por sí mismos y reducen la complejidad desde
el punto de vista de las tareas a cargo de los administradores y usuarios.
La solución propuesta por IBM mira el problema desde la perspectiva
más importante: el usuario final. ¿Cómo quieren los clientes de IT que funcionen los sistemas de computación?. Quieren interactuar con los sistemas
intuitivamente, y no quieren tener que estar directamente involucrados en su
funcionamiento. Idealmente, a los usuarios de IT les gustarían sistemas informáticos bonitos, complejos y seguros, pero sin involucrarse en los aspectos de
su manejo y mantenimiento.
IBM anunció nuevos servicios, software, adopción de estándares y programa de asociados para ayudar a las empresas a diseñar e implementar ambientes de computación autonómica de autogestión que pueden generar ahorros de
tiempo de 30 a 50 por ciento en tareas de IT, según estimaciones de consultoría.
Las nuevas ofertas ayudarán a las empresas a transformarse según el modelo on demand, automatizando los procesos de computación y dotando a los
sistemas informáticos de mayor capacidad de respuesta a las necesidades de
los usuarios.
Permitirán administrar sistemas complejos construyendo y aplicando una
arquitectura que los lleva hacia un ambiente autonómico, así como identificar
y solucionar problemas en sus ambientes de IT multiproveedor (multiplataforma) y a crear sistemas que automáticamente diagnostican la causa primaria
de los problemas, reduciendo el costo de las paradas de sistemas.
El nuevo software y los estándares que lo respaldan ayudarán a los desarrolladores y clientes a aplicar tecnología de autogestión a sistemas complejos.
La inspiración actual más directa para esta funcionalidad es el funcionamiento autonómico del sistema nervioso central humano. Los controles autonómicos usan motores neuronales para enviar mensajes indirectos a los órganos
en un nivel sub-consciente. Estos mensajes regulan temperatura, respiración y
ritmo cardíaco sin utilizar el pensamiento consciente. Las implicaciones para
la computación son inmediatamente evidentes; una red organizada de componentes computacionales “inteligentes” que dan lo que se requiere, cuando se
lo requiere, sin esfuerzo físico ni mental consciente.

34. 16
CAPÍTULO 2. NOCIONES DE COMPUTACIÓN AUTONÓMICA
Desde que IBM introdujo el concepto de la CA en 2001, la compañía ha integrado numerosas características autonómicas en diversos productos, y cuenta
con un importante grupo de productos, servicios y soluciones habilitadas para autogestión. Muchos están diseñados para automatizar la localización de
problemas de infraestructura que, cuando es manual, puede consumir mucho
tiempo. La firma de analistas Enterprise Management Associates estima que
determinar la causa de un problema puede ocupar hasta el 50-80 por ciento
del tiempo de un equipo de IT, mientras que la reparación en sí sólo ocupa el
15-20 por ciento restante.
2.3.1
Novedades de IBM para AC
Las principales novedades de IBM en el mundo autonómico son:
• IBM Accelerator for Service Management for Problem Determination,
que permite a los clientes combinar, analizar y correlacionar información de eventos entre sistemas heterogéneos. Esto incluye adaptadores
de log que pueden convertir datos de registro distintos a un formato
común, proporcionando una única interfaz de usuario para tener una
visión simplificada extremo a extremo y análisis y correlación de datos
consolidados. Al poner su Tecnología Autonómica Autoadministrable al
servicio de los clientes, se puede encontrar y reparar fallas de sistemas e
interrupciones de servicio más rápidamente gracias a la automatización
de los procesos.
• Dynamic Infrastructure for my SAP Business Suite, que proporciona una
solución flexible que mejora la capacidad de los clientes de compartir
recursos entre distintas aplicaciones SAP, acelerar la implementación
de nuevas soluciones SAP, mejorar la utilización de sistemas y bajar el
costo total de propiedad. Esta oferta aprovecha el Tivoli Provisioning
Manager, que incluye tecnología autonómica autoadministrable.
También se dispone de un nuevo software autonómico en el Toolkit de Computación Autonómica, un recurso en línea donde los desarrolladores pueden
implementar rápidamente funciones autoadministrables en sus aplicaciones y
servicios. Respondiendo al feedback de los desarrolladores, el nuevo software
autonómico los ayuda a llevar la tecnología autoadministrable a aplicaciones
más grandes y complejas. Los desarrolladores pueden aprovechar código Java

35. 2.3. PROPUESTA DE SOLUCIÓN
17
en componentes para mayor flexibilidad y capacidades adicionales de filtros,
a fin de acelerar el análisis y la determinación de problemas. Al incorporar
estándares de la industria, la tecnología del Toolkit da soporte a aplicaciones
heterogéneas.
2.3.2
El Nuevo Paradigma AC
Este nuevo paradigma computacional significa el diseño e implementación de
sistemas de computación, software, almacenamiento y apoyo que deben exhibir
los siguientes principios básicos desde la perspectiva del usuario:
• Flexibilidad:
El sistema podrá manipular datos a través de una plataforma y de
unos dispositivos cuyo funcionamiento no sólo desconoce sino que
le resulta indiferente.
• Accesibilidad:
La naturaleza del SA es tal que siempre está disponible.
• Transparencia:
El sistema ejecutará sus tareas y se ajustará a las necesidades del usuario sin que el usuario deba interiorizarse en las complejidades de su
funcionamiento.
2.3.3
Estándares Relacionados con AC
IBM contribuye a impulsar los estándares en torno a la computación autonómica, colaborando con organizaciones de estándares y líderes de la industria. La
especificación Solution Installation de IBM será considerada por un grupo de
trabajo del organismo de estándares denominado Solution Deployment Descriptor (SDD), dentro de la Organization for the Advancement of Structured
Information Standards (OASIS), que está desarrollando un método estandarizado para expresar las características de instalación de software requeridas
para la gestión del ciclo de vida en ambientes distribuidos y multiplataforma.

36. 18
CAPÍTULO 2. NOCIONES DE COMPUTACIÓN AUTONÓMICA
Además, la especificación Common Base Event presentada por IBM ha
sido un aporte crítico en el estándar Web Services Distributed Management
(WSDM) recientemente ratificado por OASIS.
Los clientes y asociados ya están usando el formato Common Base Event y
la tecnología autonómica Solution Installation and Deployment, demostrando
el beneficio de la estandarización en torno a la CA. Por ejemplo, Macrovision
incorporó la tecnología Solution Installation and Deployment en su producto FLEXnet Publisher Installation Module, recientemente anunciado. Usando
esta oferta, la compañía de tecnología SAS tiene la capacidad de mantener,
instalar, configurar y administrar software en forma automática y más eficiente, y espera una reducción significativa de sus costos de gestión de IT.
El software autonómico autoadministrable de IBM y los estándares que le
dan soporte son elementos críticos de la estrategia de Gestión de Servicios de
IT de Tivoli, que se focaliza en automatizar e integrar los procesos informáticos
en toda la empresa u organización.
2.4
Beneficios Esperados
La CA se concibió para aminorar las demandas crecientes de personal altamente experimentado en las IT, reducir la complejidad y administrar la informática
en una nueva era que aprovechará mejor su potencial para soportar niveles más
altos de conocimiento en la toma de decisiones.
Los beneficios inmediatos incluirán una dependencia reducida respecto de la
intervención humana para mantener sistemas complejos acompañada por una
disminución substancial en costos. Los beneficios a largo plazo permitirán a
los individuos, a las organizaciones y a las empresas, colaborar en la resolución
de problemas complejos.
Los beneficios a corto plazo relacionados con las IT son:
• Menor experiencia y capacitación de los usuarios debido a sistemas más
sensibles e inteligentes y de tiempo real.
• Disminución de costos al escalar (ampliar) su uso.
• Potencia, almacenamiento y costos escalables, optimizando el uso tanto
para hardware como para software.

37. 2.5. CARACTERÍSTICAS DE LOS SISTEMAS DE AC
19
• Impulso al uso pleno de procesadores ociosos, incluso PCs hogareñas,
mediante sistemas de computación en red (grid computing).
• Consultas en lenguaje natural permitirán respuestas más profundas y
más exactas.
• Accesos indistintos a múltiples tipos de archivos. El uso de estándares
abiertas permitirá que los usuarios manipulen datos de todo tipo de
fuentes potenciales y re-asignarles el formato correcto “en vuelo”, es
decir, al ser transmitidos de un dispositivo a otro.
• Estabilidad. Alta disponibilidad. Altos niveles de seguridad. Menos
errores de sistema o de la red debido a la auto-reparación.
Los beneficios a largo plazo, que son los más significativos, incluyen:
• Realización de la visión de disponibilidad mediante el cambio de recursos
disponibles a sistemas de alto rango.
• Incorporación (embebida) de capacidades autonómicas en clientes o dispositivos de acceso, servidores, sistemas del almacenamiento, middleware, y la red misma.
• Construcción de sistemas autonómicos federados (multiplataforma).
• Administración de niveles de servicio extremo-a-extremo.
• Colaboración y resolución global de problemas. Los sistemas de computación distribuidos permiten compartir de una manera más inmediata la
información y la potencia de proceso, impulsando el uso de complejos
algoritmos matemáticos para resolver problemas.
• Procesos que requieren simulación masiva (pronósticos del tiempo, estudios médicos con proteínas, etc.) que precisan de procesadores que
ejecuten 24/ 7 (24 horas los 7 días de la semana) por largos períodos de
tiempo, como un año.
2.5
Características de los Sistemas de AC
Mientras la definición de CA probablemente se transformará mientras las tecnologías involucradas maduran, la lista siguiente sugiere que ocho características definen un sistema de computación autonómico (SAC):

38. 20
CAPÍTULO 2. NOCIONES DE COMPUTACIÓN AUTONÓMICA
1. Un SAC requiere “conocerse a sí mismo” (sus componentes también
deben poseer una identidad de sistema). Dado que un “sistema” puede
existir a muchos niveles, un SA requerirá un conocimiento detallado
de sus componentes, estado presente, capacidad última, y de todas sus
conexiones a otros sistemas, para gobernarse a sí mismo. Necesitará
conocer la magnitud de sus “propios” recursos, esos que puede pedir
prestado o presta, y esos que puede compartir o que debe gestionar sin
compartir.
2. Un sistema de CA debe configurarse y reconfigurarse a sí mismo bajo
condiciones variantes (y en el futuro, condiciones imprevisibles). La configuración del sistema o “setup” debe ocurrir automáticamente, así como
ajustes dinámicos a esa configuración, para manipular mejor ambientes
cambiantes.
3. Un sistema de CA nunca establece el statu quo (no permanece como
está), siempre busca maneras de perfeccionar su funcionamiento. Supervisará sus partes componentes y el flujo de carga de trabajo para
alcanzar metas predeterminadas del sistema.
4. Un sistema de CA debe ejecutar algo semejante a “curación” (reparación), debe poder recuperarse de rutinas y eventos extraordinarios que
pueden causar en algunas de sus partes un funcionamiento defectuoso.
Debe poder descubrir problemas o problemas potenciales, y entonces
hallar una manera alternativa de usar los recursos o de reconfigurar el
sistema, preservando su funcionamiento fácilmente.
5. Un mundo virtual no es menos peligroso que el mundo físico, así un
sistema de CA debe ser un experto en auto-protección. Debe descubrir, identificar y protegerse a sí mismo contra varios tipos de ataques y
mantener garantías globales de funcionamiento y de integridad.
6. Un sistema de CA debe conocer su entorno y el límite del contexto de
su actividad, y actuar de acuerdo con ello. Encontrará y generará reglas
acerca de cómo interactuar mejor con otros sistemas vecinos. Tomará
recursos disponibles, igualmente negociará el uso por parte de otros sistemas de sus elementos subutilizados, cambiando a ambos, a sí mismo y
a su ambiente en el proceso, en una palabra, adaptando.
7. Un sistema de CA no puede existir en un ambiente hermético. Dado
que es independiente en su habilidad de manejarse a sí mismo, debe
funcionar en un mundo heterogéneo e instrumentar estándares abiertos,

39. 2.6. ALGUNAS APLICACIONES CON TECNOLOGÍA CA
21
en otro palabras, un sistema de CA no puede, por definición, ser una
solución propietaria, es decir dependiente de un determinado proveedor.
8. Un sistema de CA anticipará los recursos optimizados requeridos mientras mantiene oculta su complejidad. Debe ordenar los recursos de IT
disminuyendo la brecha entre las metas de negocio o personales del usuario, y la implementación de recursos de IT necesarios para alcanzar esas
metas, sin involucrar al usuario en esta implementación de recursos.
2.6
Algunas Aplicaciones con Tecnología CA
Algunas de las aplicaciones ya disponibles que han incorporado aspectos de la
tecnología CA son las siguientes:
Autonomic Personal Computing (APC) es computación personal sobre plataformas de CA. El desafío de la APC es simplificar y acrecentar la experiencia
del usuario, ayudándolo anticipándose a sus necesidades en un entorno complejo, dinámico e incierto.
IBM ha instalado sistemas de servidores e-server que incorporan tecnologias de CA que permiten la autorrecuperacion, autoconfiguracion, autoproteccion y autooptimizacion. Esto brinda dos ventajas: reduce los gastos generales
de gestión controlando costos de soporte, e incrementa la confiabilidad de un
entorno heterogéneo de IT. El resultado brindará infraestructuras más flexibles
que requieran menor gestión, mientras se minimizan los gastos administrativos. Teniendo en cuenta que administrar un servidor suele ser más costoso
que el mismo servidor!!.
DB2 8.2 : es la segunda version DB2 que cuenta con funcionalidades de
CA.
DB2 tiene la capacidad de tomar acciones tales como avisar cuando la
base comienza a sufrir insuficiencias de espacio y agregar el espacio requerido
por sí sola. Se debe a que el monitoreo permanente se hace en automático,
el administrador de bases de datos puede dedicarse a tareas más creativas,
tales como la arquitectura de una solución; en consecuencia, la organización
requerirá de menos administradores de bases de datos, lo cual implica una
reducción hasta 65% en los costos por concepto de mano de obra calificada.
WebSphere: software que forma la base sobre la que los programadores

40. 22
CAPÍTULO 2. NOCIONES DE COMPUTACIÓN AUTONÓMICA
construyen y administran sus aplicaciones. Equipado con más avances en la
tecnología de Software basada en el lenguaje de programación Java y tecnologías de servicio de Internet, usadas para permitir que diferentes programas
compartan información y trabajen juntos.

41. 2.6. ALGUNAS APLICACIONES CON TECNOLOGÍA CA
Concepto
Auto-Configuración
Auto-Optimmización
Auto-Reparación
Auto-Protección
Computación
Clásica
Los centros de datos
corporativos tienen
múltiples fabricantes
y plataformas.
La instalación,
configuración y la
integración
de los sistemas
consumen tiempo y
lleva a cometer
posibles errores.
Los sistemas
tienen cientos
de seteos manuales
y parámetros
no lineales
sintonizados cuya
cantidad incrementa
con cada versión.
La determinación
de problemas,
en sistemas
complejos y grandes,
puede requerir
a un equipo de
programadores
durante semanas.
La detección
y la
recuperación
de ataques y
fallas en
cascada es manual.
Computación
Autonómica
La configuración
automatizada
de componentes
y sistemas siguen
políticas
de alto nivel.
El resto
de los
sistemas se ajustan
automáticamente y
de modo sencillo.
Los componentes
y sistemas
contínuamente
buscan
oportunidades
de
mejorar su propia
eficiencia.
Los sistemas
detectan,
diagnostican
y reparan
automáticamente
la localización
del software y los
problemas de hardware.
Los sistemas
se defienden
automáticamente
de los ataques o fallas.
Utilizan una
advertencia
temprana para
anticipar y
prevenir fallas
del sistema.
Tabla 2.1: Estados de enlace basados en el contexto.
23

43. Capítulo 3
Arquitectura de AC
3.1
Niveles de Maduración Autonómica
Incorporar capacidades autonómicas en un entorno informático es un proceso
evolutivo que hace posible la tecnología, pero es a fin de cuentas implementado por cada emprendimiento a través de la adopción de estas tecnologías,
soporte de procesos, y habilidades [6]. Los productos, sistemas, y entornos IT
pueden ser clasificados en los siguientes cinco niveles de maduración que muestran cómo una organización va evolucionando al hacer uso de las capacidades
autonómicas, soportando procesos y funcionalidades:
1. Nivel 1: Basic: Básico: Los profesionales de IT ejecutan todas las funciones manualmente:
• En el nivel básico, los profesionales en IT manejan cada elemento
de la infraestructura independientemente y lo levantan, monitorean
y eventualmente, lo restituyen.
2. Nivel 2: Managed: Administrado: Los análisis y planes son hechos por
los profesionales:
• En el nivel de administrado, las tecnologías del administración de
sistemas pueden usarse para recolectar información desde diferentes
sistemas sobre consolas más chicas, ayudando a reducir el tiempo
que toma colectar y sintetizar información ya que el entorno de IT
se vuelve más complejo.
25

44. 26
CAPÍTULO 3. ARQUITECTURA DE AC
3. Nivel 3: Predictive: Predictivo: Los profesionales de IT eligen las recomendaciones y la implementación:
• En el nivel predictivo, la capacidad de análisis se introduce en el
sistema para monitorear situaciones que se originan en el entorno,
y analizar las situaciones para proveer los posibles cursos de acción.
Los profesionales en IT hacen una determinación sobre qué curso
de acción tomar.
4. Nivel 4: Adaptive: Adaptable: Los profesionales de IT proveen políticas
utilizadas para generar planes automáticamente:
• En el nivel adaptable, el entorno de IT puede tomar acciones automáticamente basado en la información disponible y en el conocimiento de “qué está pasando en el entorno”. Como los análisis y las
tecnologías de los algoritmos van mejorando y el personal se vuelve
cada vez más satisfecho con las capacidades de aviso y de predicción
que brindan éstas tecnologías, los sistemas pueden evolucionar al
nivel adaptativo.
5. Nivel 5: Autonomic: Autonómico: Sistemas de política abierta:
• En el nivel autonómico, las políticas y objetivos de negocios gobiernan las operaciones de infraestructura de IT. Los profesionales en
IT interactúan con las herramientas de tecnología autonómica para
monitorear procesos de negocio, modificar objetivos, o ambos.
3.2
Arquitectura de Referencia de AC
Los conceptos autonómicos presentados en esta sección forman la base para
un enfoque común y el conjunto fundamental de terminologías requeridas en
la arquitectura de sistemas AC en un entorno heterogéneo.
3.2.1
Ciclo de Control
El arquitectura de referencia de AC comienza a partir de la premisa de que
los atributos de la implementación de la auto administración originan un ciclo de control (control loop) inteligente. Este ciclo recopila información desde

45. 3.2. ARQUITECTURA DE REFERENCIA DE AC
27
Figura 3.1: Arquitectura de referencia de AC.
el sistema, toma decisiones y entonces ajusta el sistema según sea necesario.
Un ciclo de control inteligente puede permitir al sistema disponer de atributos
de auto-configuración, auto-reparación, auto-optimización y auto- protección
descriptos anteriormente. La arquitectura describe dos tipos de componentes
de los sistemas: un administrador autonómico y uno o más recursos administrados.
Un administrador autonómico es un componente que implementa un ciclo
de control particular.
Un recurso administrado es lo que un administrador autonómico controla.
Ver Fig. 3.1 de la pág. 27, donde se muestra la relación entre los diferentes
componentes.

46. 28
CAPÍTULO 3. ARQUITECTURA DE AC
3.2.2
Administrador Autonómico
El administrador autonómico es un componente que implementa el “ciclo de
control”. La arquitectura examina el loop en sus cuatro partes. Estas partes
son:
• Monitor: Monitoreo: Alimenta el mecanismo que colecta, agrega, filtra, maneja y reporta detalles (métricas y topología) recolectados de un
recurso administrado.
• Analize: Análisis: Provee los mecanismos de asociar y modelar situaciones complejas que permiten al administrador autonómico adquirir conocimiento acerca del entorno de IT y ayudar a predecir situaciones
futuras.
• Plan: Plan: Brinda los mecanismos para estructurar la acción requerida
para lograr propósitos y objetivos.
• Execute: Ejecución: Provee mecanismos que controlan la ejecución de
un plan con consideraciones para su actualización sobre la marcha.
Las cuatro partes trabajan en conjunto para facilitar la funcionalidad del
ciclo de control. Éstas utilizan y generan conocimiento. Este conocimiento
se fundamenta en información conocida acerca del sistema y se incrementa a
medida que el administrador autonómico aprende más sobre las características
de los recursos administrados. El conocimiento es continuamente compartido
entre las cuatro partes, llegando a decisiones tomadas por las partes, con más
información. La Fig. 3.1 de la pág. 27 muestra una disposición estructural de
las partes, no un ciclo de control.
La línea gruesa que conecta a las cuatro partes debería ser pensada como un
bus de mensajes común más que como un ciclo de control. En otras palabras,
pueden haber situaciones donde la parte “Plan” pueda requerir a la parte
“Monitor” la recolección de más o menos información. Además podrían haber
situaciones donde la parte “Monitor” pueda ordenar a la parte “Plan” a crear
un nuevo Plan.

47. 3.2. ARQUITECTURA DE REFERENCIA DE AC
3.2.3
29
Recurso Administrado
El recurso administrado es un componente del sistema administrado. Puede
haber un único recurso administrado (un servidor, servidor de base de datos, o
un router) o una colección de recursos (una combinación de servidores, clusters,
o aplicaciones de negocio).
Un administrador autonómico se comunica con un recurso administrado a
través de la interfase de manejabilidad. Un touchpoint es la implementación
de la interfase de manejabilidad por un recurso administrado específico. Por
ejemplo, una base de datos puede implementar un touchpoint para comunicarse con un administrador autonómico.
3.2.4
Interfase de Manejabilidad
La interfase de manejabilidad entre un administrador autonómico y un recurso
administrado se organiza dentro de las operaciones de “sensor ” y “effector”.
En términos más simples, las operaciones sensor son típicamente usadas
para transmitir eventos o propiedades a un administrador autonómico, mientras que las operaciones effector son típicamente usadas para causar algún
tipo de cambio en un recurso administrado, tales como alterar datos o fijar
valores de propiedades. Las operaciones sensor y effector se organizan dentro
de un conjunto de estilos de interacción que formaliza y define cómo interactúan un administrador autonómico y su recurso administrado. Cada una de
las operaciones sensor y effector pueden tener dos estilos de interacción:
• Sensor retrieve-state: Sensor recuperación-estado.
• Sensor receive-notification: Sensor recepción-notificación.
• Effector perform-operation: Effector realización-operación.
• Effector call-out-request: Effector llamada-cierre-requerimiento.
Los estilos de interacción se diferencian por cómo el administrador autonómico o el recurso administrado hacen el primer contacto. Tanto en el estilo
de interacción sensor retrieve-state como en el effector perform-operation, el

48. 30
CAPÍTULO 3. ARQUITECTURA DE AC
administrador autonómico hace el primer contacto. En los estilos de interacción sensor receive-notification y effector call-out-request, es el recurso administrado el que hace el primer contacto. La combinación de las operaciones
sensor y effector forma la interfase de manejabilidad que está disponible para
un administrador autonómico.
Como muestra la Fig. 3.1 de la pág. 27, las líneas negras conectan la
sección sensor y effector del diagrama; la arquitectura promueve la idea de
que las operaciones sensor y effector están conjuntamente vinculadas. Por
ejemplo, un cambio en la configuración que ocurra a través de un effector
debería reflejarse como una notificación de cambio en la configuración a través
de la interfase sensor.
3.3
La Arquitectura AC y los Niveles de Maduración
Como se describió en Niveles de Maduración Autonómica, los niveles muestran
que los atributos de auto-administración se logran en una manera evolutiva de
introducirse en todos los aspectos de un sistema. Como un ejemplo, diferentes
partes de un administrador autonómico podrían implementarse a cada nivel
de maduración.
Las partes Monitor y Execute del administrador autonómico podrían implementarse en los niveles Basic y Managed. Así, a estos dos niveles, los
profesionales de IT serían responsables por la ejecución de las funciones de
analizar y diseñar componentes. La parte de Análisis de un administrador
autonómico puede ser suministrada en el nivel Predictive de maduración. En
este nivel, el profesional en IT sería responsable de las funciones de Plan. En
los niveles Adaptive y Autonomic, todas las partes del administrador autonómico se implementan de manera que el profesional en IT podría delegar el
trabajo al sistema.
3.4
Arquitectura AC Para Sistemas Personales (PC)
Se detallará a continuación una arquitectura para sistemas de computación
autonómica personal [19]. La arquitectura de un sistema autonómico incluye
a la de un sistema de computación personal, comienza con la arquitectura

49. 3.4. ARQUITECTURA AC PARA SISTEMAS PERSONALES (PC)
31
Figura 3.2: Arquitectura de un Elemento Autonómico.
general para sistemas autonómicos. El bloque de construcción de un sistema
autonómico está descripto en la Fig. 3.2 de la pág. 31.
La figura indicada muestra la arquitectura de un elemento autonómico
(AE). Cada AE consiste de un administrador autonómico (AM) y un conjunto
de componentes administrados. Cada componente administrado es responsable de comunicarse con eventos y otras medidas del AM local. A su vez, basado
en la entrada recibida desde cada componente administrado, el AM toma decisiones teniendo en cuenta su política, los hechos y las reglas (almacenadas
localmente en una base de datos) y comunica las directivas y sugerencias al
componente administrado.
La figura anterior marca una distinción entre el comportamiento autonómico auto-controlado (dentro de la caja gris mayor de la derecha) y el
administrador autonómico que comprende comunicaciones explícitas con un
administrador remoto. Las interfases entre un AM y su componente administrado son una parte importante de la arquitectura. Para sistemas de computación personal basados en Windows, un amplio conjunto de éstas interfases
están representadas por el Windows Management Instrumentation (WMI). La
interfase entre un AM remoto y un AE no está actualmente estandarizada.
Esta interfase debe ser descubierta y dinámicamente contenida en el so-

50. 32
CAPÍTULO 3. ARQUITECTURA DE AC
porte de auto-configuración de sistemas autonómicos, además debe ser segura
y confidencial. La figura mencionada muestra una implementación de un administrador autonómico remoto de un servicio Web (Web service) mediante el
servicio de registro Universal Description, Discovery, and Integration (UDDI).
Se aprecia a los servicios Web como una tecnología fundamental porque
ellos proveen métodos estándares para localizar, comunicar (vía XML), construir, e interactuar con servicios basados en sistemas de redes. Pero debido
a que los sistemas personales frecuentemente son móviles y ocasionalmente se
desconectan, la interfase debe soportar también el modo de uso “desconectado” (off line).
La Fig. 3.3 de la pág. 33 muestra la arquitectura de un sistema autonómico
que consiste de elementos autonómicos conectados a otro en modo local, par,
y niveles de sistemas de redes. Los recursos se muestran como cajas, los
AMs con forma de diamante, los grupos de pares (entidades similares) como
elipses, y los servidores de recursos físicos y clientes como círculos. Las flechas
representan el control ejercido por los AMs (ej., S controla a W).
En el nivel local hay un solo AM (ej., A) que es capaz de tomar decisiones
independientemente. A nivel de pares (grupo), cada AM interactúa y comparte
conocimiento e información con sus pares y puede actuar de modo cooperativo,
como si se estuviera en presencia de un administrador autonómico virtual (ej.,
W).
La idea de un administrador autonómico virtual es tener los participantes en un grupo de pares que alcance un cierto comportamiento autonómico
como si fuera dirigido por una instancia local o remota de un administrador
autonómico, aunque ninguno esté presente.
El comportamiento es una consecuencia del consenso local obtenido compartiendo conocimiento entre los pares, y actuando localmente basados en ese
conocimiento. Los elementos de una arquitectura de pares, descubrimiento,
pregunta, y unión, soportan este proceso.
Una de las aplicaciones centrales de la Computación Autonómica Personal
es cómo los administradores autonómicos en un cierto nivel más alto en el
sistema, ejercen control sobre los elementos de nivel inferior, qué elementos
autonómicos son controlados, cuánto (y cuán rápidamente) se ejerce el control,
y qué clase de control se realiza.
Se pueden identificar dos tipos de control: delegación y dirección.

51. 3.4. ARQUITECTURA AC PARA SISTEMAS PERSONALES (PC)
33
Figura 3.3: Ejemplo de dos Jerarquías de Control Autonómico.
En la delegación, un administrador autonómico local pasa el control de
algunos de los recursos que maneja a un superior. Por defecto, el control de
todos los recursos locales es delegado al AM local.
En la dirección, un administrador autonómico local recibe la información
(ej., políticas) de su superior y las implementa con respecto a sus propios
recursos. Solamente un AM está siempre en directo control de un recurso.
Las computadoras personales de hoy manejan todos sus recursos con un
solo administrador de su sistema operativo.
Es ventajoso soportar un modelo en el cual el control sobre algunos recursos
se pueda delegar a otro administrador, esto es posible con la virtualización del
cliente.
Si se piensa en las cajas de la Fig. 3.3 de la pág. 33 como máquinas
virtuales, se puede ver que dos de las máquinas virtuales del cliente A están
bajo control local completo, mientras que la tercera está bajo control del grupo
de pares. El cliente tiene dos máquinas virtuales controladas localmente y una
administrada centralmente, quizás por el departamento de soporte y servicio

52. 34
CAPÍTULO 3. ARQUITECTURA DE AC
de IT de las organizaciones.
En el caso de desconexión ocasional de un administrador autonómico, una
estrategia estática sencilla hace que el administrador remoto proporcione la
dirección de la política pero no el control en tiempo real. Un ejemplo viene de
la administración de la seguridad.
Un administrador de seguridad global remoto puede conocer los usos inter e
intra-organinzación (ej., un nuevo estilo de ataque) que un cliente desconectado
no puede descubrir hasta el momento crítico de la primera reconexión.
Por el momento, existe una carrera entre la actualización del administrador
remoto y el ataque, sugiriendo que las precauciones especiales las tome el
cliente para obtener con seguridad la directiva más reciente de seguridad antes
de recomenzar su política de seguridad normal local.
Tales estrategias soportan el estilo tradicional de la computación personal
de autonomía local considerable. Ahora se pueden discutir dos cuestiones que
se consideran fundamentales para el éxito de esta arquitectura: seguridad y
privacidad por una parte, y estabilidad por la otra.
Seguridad y privacidad: La seguridad y la privacidad son atributos de
sistema críticos. Para que una máquina solicite información confidencial de
otra máquina, necesita ser capaz de identificarse con seguridad.
Hay varias maneras de poder hacer esto, pero la más fácil (y probablemente
la más segura) es usar una par de clave privada/pública. La TCPA (Trusted
Computing Plataform Alliance) provee una manera ideal de obtener claves
privadas seguras para la identificación a nivel de máquina. Cada sistema
puede entonces identificar cualquier otra máquina usando claves registradas
mantenidas en una base de datos, como en el Administrador de Políticas de
Tivoli IBM, o usando certificados.
Una vez que finalizada la identificación, es necesario establecer una conexión segura entre las computadoras. La manera estándar de hacer esta
conexión, es mediante el Internet Protocol Security (IPSec) (Protocolo Seguro de Internet) pero también sirve el modelo cliente/servidor autenticado
Secure Socket Layer (SSL). Este provee peticiones autenticadas, transmisión
confidencial de los datos, e integridad de los datos de respuesta. Los ejecutables deben ser marcados para que puedan verificarse como provenientes de un
recurso confiable y corran en un entorno seguro.

53. 3.4. ARQUITECTURA AC PARA SISTEMAS PERSONALES (PC)
35
Un más alto nivel de administrador autonómico no debería enviar información a un administrador subordinado sin serle requerido. Cuando un sistema
está en modo de transmisión, el receptor necesita ser capaz de acelerar el funcionamiento del sistema emisor para evitar el ataque de denegación de servicio.
Para que una máquina publique la información, necesita poder determinar
si la información es confidencial. La información no confidencial debe ser
identificada explícitamente, de otra manera, todo se asume como confidencial.
Estabilidad: La meta de un sistema personal autonómico es exhibir un
comportamiento autonómico y a la vez útil para su usuario final. Cuando los
componentes autonómicos se ponen juntos en un sistema, no es un hecho que
el sistema en su totalidad exhiba comportamiento estable.
Por ejemplo, una computadora personal puede hacer una evaluación local
de que un vínculo de comunicaciones compartido tiene gran ancho de banda, basada en las características de los medios, y puede iniciar una actividad
(transmisión) de consumo de ancho de banda. Si otras computadoras personales toman la misma decisión, el enlace puede saturarse y llegar rápidamente
a ser inutilizable para todos.
Una estrategia más conservadora, por ejemplo, es diferir actividades de
consumo de ancho de banda hasta tener un registro (información) del funcionamiento del enlace, y entonces procurar un uso más agresivo del recurso; esto
puede lograr un comportamiento total mejor.
En general, se puede imaginar que el comportamiento autonómico constructivo será acotado por el contexto y la política. Qué contexto y qué políticas
(y cómo representarlas y mantenerlas) son puntos importantes para futuras
investigaciones.

55. Capítulo 4
Introducción y Tecnologías
del Autonomic Computing
Toolkit
4.1
Conceptos Generales
El Autonomic Computing Toolkit es una colección de tecnologías, herramientas, ejemplos, escenarios y documentación que se diseñó para usuarios que
quieran aprender, adaptarse, y desarrolar capacidades autonómicas en sus
productos y sistemas.
El primer lanzamiento de AC Toolkit proporciona la primera fase de tecnologías AC que habilita el desarrollo de capacidades autonómicas. El contenido
de AC Toolkit puede dividirse en cuatro categorías principales:
• Tecnologías.
• Herramientas.
• Escenarios.
• Información y documentación.
37

56. 38
CAPÍTULO 4. INTRODUC. Y TECNOLOGÍAS DEL AC TOOLKIT
4.1.1
Tecnologías
La tecnologías proporcionadas en AC Toolkit pueden ser usadas para desarrollar o mejorar ciertas capacidades en productos y sistemas. Estas capacidades
incluyen determinación de problemas, sistemas de administración comunes, y
soluciones de instalación y despliegue [6].
La determinación de problemas y capacidades autonómicas, pueden desarrollarse con Autonomic Management Engine (AME), el Generic Log Adapter, y el Log and Trace Analyzer Tool. La Integrated Solutions Console (Consola de Soluciones Integradas) es utilizada para construir, de forma efectiva,
las capacidades de administración de sistemas más comunes.
El dependency checker es una tecnología que provee capacidades autonómicas para soluciones de instalación y despliegue.
4.1.2
Herramientas
Además de proporcionar estas tecnologías, el AC Toolkit provee las herramientas necesarias para personalizar las mismas con el objetivo de que las
soluciones se puedan crear adaptándolas a las necesidades específicas de casa
usuario. Herramientas tales como Integrated Solutions Console, Resource Model Builder (RMB), y el Adapter Rule Editor Tool están incluidos para asistir
en la creación de estas soluciones personalizadas.
El AC Toolkit también provee programas de análisis de registro (log) para
varios productos IBM. Estos programas de análisis, junto con los que el usuario podrá desarrollar para sus propios productos con el Adapter Rule Editor
Tool, pueden ser usados para detectar problemas complejos en un entorno de
sistema.
4.1.3
Escenarios
También están incluidos los escenarios, que muestran cómo las tecnologías trabajan de forma conjunta y cómo pueden ser usadas en soluciones reales. Todos
los escenarios de AC Toolkit están realizados usando tecnologías y herramientas disponibles en AC Toolkit.
El primer lanzamiento de AC Toolkit, incluye un escenario para la de-

57. 4.2. USO DEL AC TOOLKIT
39
terminación de problemas, que realiza auto-reparación y dos escenarios de
instalación automatizados que realizan tareas de auto-configuración.
4.1.4
Información y Documentación
El AC Toolkit también se focaliza en educar usuarios en computación autonómica.
Se proporcionan detalles de la tecnología individual y documentación acerca del uso de las herramientas, así como documentación para ayudar a comenzar el desarrollo autonómico de soluciones personalizadas para los productos
del usuario.
4.2
Uso del AC Toolkit
Esta sección detalla lo que se puede realizar usando AC Toolkit, y cómo hacerlo.
4.2.1
Comprensión de Conceptos del AC
Antes de intentar desarrollar una solución autonómica, lo mejor es tener un
buen conocimiento de los conceptos detrás de la computación autonómica,
para lo cual es necesario releer los capítulos previos.
4.2.2
Trabajo Conjunto de las Tecnologías de AC Toolkit Para
Lograr Soluciones de Auto-Gestión
Después de comprender los conceptos básicos de computación autonómica, se
pueden utilizar los escenarios en AC Toolkit, para ver cómo estas tecnologías
trabajan conjuntamente para lograr una solución auto-gestionada.
El AC Toolkit incluye también tres escenarios: un escenario para la determinación de problemas, que realiza auto-reparación y dos escenarios de
instalación automatizados que realizan tareas de auto-configuración.
El escenario para la determinación de problemas representa un sistema

58. 40
CAPÍTULO 4. INTRODUC. Y TECNOLOGÍAS DEL AC TOOLKIT
de auto-reparación simple que usa un lazo (loop) de control inteligente para
recolectar información del sistema, analizarla, plantear respuestas apropiadas,
y hacer los ajustes necesarios para resolver problemas.
Se incluye también documentación adicional en el paquete de escenarios.
Los escenarios de instalación autónoma demuestran cómo soluciones de instalación autonómicas y tecnologías de despliegue, se pueden usar para mejorar
la comprensión e instalación de una aplicación web sencilla. Se proveen dos
escenarios, con capacidades similares, pero cada uno usa diferentes paquetes
de instalación de software del proveedor.
Esto demuestra una versatilidad y flexibilidad en la instalación de soluciones autonómicas y el despliegue de tecnologías incluidas en AC Toolkit.
4.2.3
Uso de Tecnologías del AC Toolkit Para Desarrollar Soluciones de Usuario
Tan pronto como se haya adquirido un conocimiento sobre conceptos autonómicos, y se haya experimentado cómo las tecnologías de AC Toolkit trabajan en forma conjunta, para lograr una solución auto-controlada, se puede
comenzar a desarrollar capacidades de auto-control o auto-manejo para los
productos propios, y ayudar a los clientes a incrementar el nivel de maduración autonómica en sus entornos IT.
El incremento de la maduración autonómica de los clientes significa que los
sistemas tendrán menos tiempo muerto y requerirán de menos administración
humana e intervención.
Esto puede proporcionar reducciones significativas en los costos de administración que pueden ser aplicados al desarrollo de soluciones que aumenten
el valor de los negocios. Las tecnologías disponibles en AC Toolkit pueden ser
usadas para posicionar los productos y soluciones para ayudar a los clientes a
adquirir un mayor nivel de maduración en sus entornos IT:
• La Integrated Solutions Console (Consola de Soluciones Integradas), provee la infraestructura necesaria para ayudar a consolidar la interfase de
usuario en un entorno IT heterogéneo. Esto puede ser usado para desarrollar sistemas gestionados más eficientes (nivel 2). Al agregar otras
capacidades de gestión del sistema que corran dentro de la Integrated
Solutions Console, se pueden lograr niveles de maduración mayores.

59. 4.3. TECNOLOGÍAS Y HERRAMIENTAS DEL AC TOOLKIT
41
• El Log and Trace Analyzer (LTA) puede ser usado para lograr maduración nivel 2 (managed), y los atributos de auto-reparación del nivel
3 (predictive). El LTA provee una visión correlacionada de los eventos
que ocurren en el sistema. Esto permite al personal de IT un mejor
manejo de su entorno (nivel 2). Se pueden presentar al personal de IT la
configuración y la adecuación al usuario de la base de datos de análisis
de síntomas (problemas) y la capacidad de correlación disponible con el
LTA, las directivas de resolución de problemas y opciones basadas en la
ocurrencia de eventos. Esto logra un nivel de auto-manejo (nivel 3).
• El dependency checker (verificador de pre-requisitos) disponible en el
AC Toolkit, puede ser usado para mejorar el proceso de instalación de
los productos de software. El nivel 3 de función (predictive) se puede
alcanzar mediante el desarrollo de procesos de instalación que incorporan esta tecnología. El dependency checker señalará dependencias (prerequisitos) que falten, y se podrá programar el proceso de instalación
para informar al usuario de esta situación, de esta manera, se podrá
tomar alguna acción para correctiva.
• Los componentes AME de AC Toolkit pueden ser usados para desarrollar
un nivel de adaptación del auto-manejo (nivel 4). Se puede utilizar el
RMB disponible para desarrollar capacidades efectivas de auto-manejo
para usarlas con AME.
4.3
Tecnologías y Herramientas del AC Toolkit
Las tecnologías y herramientas contenidas en el AC Toolkit pretenden asistir a
los desarrolladores de productos para comenzar con el desarrollo de capacidades autonómicas en sus productos, para ayudar a sus entornos de IT a lograr
más altos niveles de maduración.
Las tecnologías en el AC Toolkit pueden dividirse en cuatro categorías,
como muestra a continuación:
• Autonomic Managers:
— Log and Trace Analyzer Autonomic.
— Management Engine.

60. 42
CAPÍTULO 4. INTRODUC. Y TECNOLOGÍAS DEL AC TOOLKIT
— Solution Installation and Deployment Dependancy Checker.
• Managed Resource Touchpoints:
— Generic Log Adapter Touchpoints.
— Solution Installation and Deployment Touchpoints.
• Customization Tools:
—
—
—
—
Resource Model Builder.
Adapter Rule Editor.
Integrated Solutions Console Toolkit.
SMD Editor.
• User Access:
— Integrated Solutions Console.
Se proveen varios ejemplos de implementaciones de un administrador autonómico. AME incluye capacidades incorporadas para las cuatro partes del
ciclo de control del administrador autonómico (monitoreo, análisis, planificación y ejecución).
El Log and Trace Analyzer es un ejemplo de una implementación parcial
del administrador autonómico, incluyendo a las partes de monitoreo y análisis
del ciclo de control (control loop). La solución de la instalación y la tecnología de despliegue que son parte del AC Toolkit muestran otro ejemplo de un
administrador autonómico.
La Dependency Checker ejecuta la función de monitoreo de un administrador autonómico. Se suministran algunas tecnologías y herramientas para
ayudar a crear touchpoints (puntos de contacto) a los desarrolladores, los que
permiten a los recursos administrados comunicarse con el administrador autonómico.
El Generic Log Adapter es un ejemplo de tal tecnología y se incluye en el
AC Toolkit para traducir mensajes de log de productos al formato de datos de
la Common Base Event.
El AC Toolkit también contiene herramientas para permitir personalizar
implementaciones de touchpoint a un administrador autonómico y un recurso
administrado.

61. 4.4. AME
43
El RMB se usa para personalizar un AME.
El Adapter Rule Edition se usa con Generic Log Adapter.
EL SMD Editor ayuda a personalizar la instalación de la solución y las
tecnologías de despliegue.
La Integreted Solution Console Toolkit permite construir plug-ins para la
Integrated Solutions Console. El componente Integrated Solution Console provee el acceso a los usuarios a las capacidades de auto-administración.
Esta es un infraestructura basada en Web basado en tecnologías estándares
de la industria (de la disciplina).
4.4
4.4.1
AME
Introducción
El AC Toolkit incluye AME, un ejemplo de una implementación de un administrador autonómico.
AME monitorea los recursos del sistema, envía eventos agregados, y desempeña acciones correctivas para los problemas. AME constantemente monitorea
el sistema en busca de eventos para administrarlos.
AME está disponible en el AC Toolkit en el paquete AME. Un escenario
de demostración AME está incluido en el AC Toolkit. El escenario muestra
cómo AME puede monitorear una situación, detectar la situación, y proveer
una acción correctiva.
4.4.2
Modelo de Recursos AME
Definiendo un modelo de recurso por cada recurso administrado, se provee
a AME con el conocimiento requerido para administrar esos recursos. Los
modelos de recursos contienen métricas específicas, eventos, umbrales, y parámetros, los cuáles son usados para determinar la vitalidad de los recursos
junto con especificaciones para acciones correctivas en el caso de fallas.
AME provee servicios para instalar, arrancar, y parar un modelo de re-

62. 44
CAPÍTULO 4. INTRODUC. Y TECNOLOGÍAS DEL AC TOOLKIT
curso, y averigua su estado. El AC Toolkit provee una herramienta que puede
usarse para crear un modelo de recurso AME propio del usuario, el RMB.
Un ejemplo de modelo de recurso AME se proporciona en el AC Toolkit para propósitos educativos y de demostración. Cualquiera puede utilizar esta
muestra para aprender cómo se escriben los modelos de recursos de AME y
cómo quedan incluidos en el AME.
4.5
Log and Trace Analizer
El Log and Trace Analyzer (LTA) es un ejemplo de una implementación parcial
del administrador autonómico, cubriendo las partes de análisis y monitoreo
del ciclo de control. El LTA permite la visión, el análisis, y la correlación de
archivos log. Esta herramienta lo hace más fácil y rápido para eliminar errores
y para resolver problemas dentro de múltiples sistemas utilizando datos en el
formato Common Base Event y proporcionando la visualización y el análisis
especializados de los datos.
El LTA contiene un motor de análisis de log. La función de este motor
es proporcionar un algoritmo que toma un incidente que se registra en un
archivo log como un parámetro de entrada, busca coincidencias entre este
incidente basado en las reglas predefinidas y los síntomas de una base de
datos de síntomas disponible y retorna un vector de objetos que representan
las soluciones y las directivas para los síntomas coincidentes.
El LTA provee una implementación por defecto de un motor de análisis y
un conjunto de instrumentos que podrían usarse para implementar un motor
de análisis del cliente.
El AC Toolkit contiene un motor de correlación por defecto como parte del
paquete del Log and Trace Analyzer. Las capacidades incluyen el timestamp
y la correlación de registro ID. También se proporciona la capacidad de crear
el motor de correlación del cliente. El LTA está disponible en el AC Toolkit
en el paquete de GLA/LTA.
Product analizador de log: El AC Toolkit provee un programa analizador
para varios productos de IBM. Ellos están incluídos en el paquete GLA/LTA.
Estos programas analizadores junto con los desarrollados por los propios productos de log del cliente, podría usarse para depurar problemas complejos,
como el desarrollo de aplicaciones de auto-administración en un entorno de