Universidad Nacional del Nordeste
Facultad de Ciencias Exactas, Naturales y Agrimensura
Trabajo Final de Aplicación

Desar...
A mi familia y profesores
Prefacio

“la Civilización avanza al extender el número de operaciones importantes que
podemos ejecutar sin pensar en ella...
v

llo de autonomía, autodisciplina y autocontrol por parte de los alumnos. Esto
significa que, aun cuando objetivos de apr...
vi

Objetivos Logrados:

Se han alcanzado plenamente la totalidad de los objetivos planteados para
el presente trabajo.
Or...
vii

Capitulo 8 - PHP: Trata sobre las principales características del lenguaje.
Capitulo 9 - Manual MySql: Se explica el ...
viii
Índice General
1 Introducción al B-Learning
1.1 ¿Qué es B-Learning? . . . . . . . . . . . .
1.2 Surgimiento de la Modalida...
x

4 Introduc. y Tecnologías del AC Toolkit
4.1 Conceptos Generales . . . . . . . . . . . . . . .
4.1.1 Tecnologías . . . ...
ÍNDICE GENERAL

xi

5.6.4 Instalación del Paquete AC Toolkit . . . . . . . .
5.6.5 Desinstalación del Paquete AC Toolkit ....
xii

ÍNDICE GENERAL

8.3

8.2.2 Acciones del Menu . . . . . . . . . . . . . . . .
WebSphere . . . . . . . . . . . . . . . ...
ÍNDICE GENERAL

10.3 Referencia del Lenguaje . . . .
10.3.1 Sintaxis Básica . . . . .
10.3.2 Tipos de Datos . . . . .
10.3...
xiv

ÍNDICE GENERAL

Bibliografía

257

Índice de Materias

259
Índice de Figuras
2.1
2.2

Tecnologías para los emprendimientos, con innovación y productividad. . . . . . . . . . . . . ....
xvi

ÍNDICE DE FIGURAS

6.4
6.5

Portlet de control de página. . . . . . . . . . . . . . . . . . . .
Induciendo y corrigie...
Índice de Tablas
2.1

Estados de enlace basados en el contexto. . . . . . . . . . . . .

23

5.1
5.2

Espacio requerido po...
Capítulo 1

Introducción al B-Learning
1.1

¿Qué es B-Learning?

B-Learning es la abreviatura de Blended Learning, término...
2

CAPÍTULO 1. INTRODUCCIÓN AL B-LEARNING

1.2

Surgimiento de la Modalidad B-Learning

La sociedad de la información está...
1.2. SURGIMIENTO DE LA MODALIDAD B-LEARNING

3

torno al empleo de programas educativos en el ámbito universitario, podemo...
4

CAPÍTULO 1. INTRODUCCIÓN AL B-LEARNING

insustituible de poder responder con ello a las necesidades específicas de su
al...
1.2. SURGIMIENTO DE LA MODALIDAD B-LEARNING

5

Mentor:diseñador de contenidos
El mentor (o grupo de mentores) que afronta...
6

CAPÍTULO 1. INTRODUCCIÓN AL B-LEARNING

• Sugiere fuentes alternativas de consulta: además de los materiales y de
las a...
1.2. SURGIMIENTO DE LA MODALIDAD B-LEARNING

7

• Establece reglas de comunicación: en las discusiones sincrónicas y asinc...
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...
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 ap...
10

CAPÍTULO 1. INTRODUCCIÓN AL B-LEARNING

Un modelo que se hace realizable con apoyo de tecnología. Al plantearse la
mod...
Capítulo 2

Nociones de Computación
Autonómica
2.1

Introducción

Según Alfred North Whitehead “la Civilización avanza al ...
12

CAPÍTULO 2. NOCIONES DE COMPUTACIÓN AUTONÓMICA

Pero como Whitehead tan elocuentemente lo dijo hace casi un siglo, la
...
2.2. SITUACIÓN PROBLEMÁTICA

13

Figura 2.1: Tecnologías para los emprendimientos, con innovación y productividad.

2.2

S...
14

CAPÍTULO 2. NOCIONES DE COMPUTACIÓN AUTONÓMICA

Figura 2.2: Dispositivos fuera de servicio.
tiempos de crecimiento eco...
2.3. PROPUESTA DE SOLUCIÓN

15

condiciones y a las cargas de trabajo, solucionan errores y fallas ellos mismos,
y se prep...
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 i...
2.3. PROPUESTA DE SOLUCIÓN

17

en componentes para mayor flexibilidad y capacidades adicionales de filtros,
a fin de acelera...
18

CAPÍTULO 2. NOCIONES DE COMPUTACIÓN AUTONÓMICA

Además, la especificación Common Base Event presentada por IBM ha
sido ...
2.5. CARACTERÍSTICAS DE LOS SISTEMAS DE AC

19

• Impulso al uso pleno de procesadores ociosos, incluso PCs hogareñas,
med...
20

CAPÍTULO 2. NOCIONES DE COMPUTACIÓN AUTONÓMICA

1. Un SAC requiere “conocerse a sí mismo” (sus componentes también
deb...
2.6. ALGUNAS APLICACIONES CON TECNOLOGÍA CA

21

en otro palabras, un sistema de CA no puede, por definición, ser una
soluc...
22

CAPÍTULO 2. NOCIONES DE COMPUTACIÓN AUTONÓMICA

construyen y administran sus aplicaciones. Equipado con más avances en...
2.6. ALGUNAS APLICACIONES CON TECNOLOGÍA CA

Concepto
Auto-Configuración

Auto-Optimmización

Auto-Reparación

Auto-Protecc...
Capítulo 3

Arquitectura de AC
3.1

Niveles de Maduración Autonómica

Incorporar capacidades autonómicas en un entorno inf...
26

CAPÍTULO 3. ARQUITECTURA DE AC

3. Nivel 3: Predictive: Predictivo: Los profesionales de IT eligen las recomendaciones...
3.2. ARQUITECTURA DE REFERENCIA DE AC

27

Figura 3.1: Arquitectura de referencia de AC.

el sistema, toma decisiones y en...
28

CAPÍTULO 3. ARQUITECTURA DE AC

3.2.2

Administrador Autonómico

El administrador autonómico es un componente que impl...
3.2. ARQUITECTURA DE REFERENCIA DE AC

3.2.3

29

Recurso Administrado

El recurso administrado es un componente del siste...
30

CAPÍTULO 3. ARQUITECTURA DE AC

administrador autonómico hace el primer contacto. En los estilos de interacción sensor...
3.4. ARQUITECTURA AC PARA SISTEMAS PERSONALES (PC)

31

Figura 3.2: Arquitectura de un Elemento Autonómico.

general para ...
32

CAPÍTULO 3. ARQUITECTURA DE AC

porte de auto-configuración de sistemas autonómicos, además debe ser segura
y confidenci...
3.4. ARQUITECTURA AC PARA SISTEMAS PERSONALES (PC)

33

Figura 3.3: Ejemplo de dos Jerarquías de Control Autonómico.
En la...
34

CAPÍTULO 3. ARQUITECTURA DE AC

de IT de las organizaciones.
En el caso de desconexión ocasional de un administrador a...
3.4. ARQUITECTURA AC PARA SISTEMAS PERSONALES (PC)

35

Un más alto nivel de administrador autonómico no debería enviar in...
Capítulo 4

Introducción y Tecnologías
del Autonomic Computing
Toolkit
4.1

Conceptos Generales

El Autonomic Computing To...
38

CAPÍTULO 4. INTRODUC. Y TECNOLOGÍAS DEL AC TOOLKIT

4.1.1

Tecnologías

La tecnologías proporcionadas en AC Toolkit pu...
4.2. USO DEL AC TOOLKIT

39

terminación de problemas, que realiza auto-reparación y dos escenarios de
instalación automat...
40

CAPÍTULO 4. INTRODUC. Y TECNOLOGÍAS DEL AC TOOLKIT

de auto-reparación simple que usa un lazo (loop) de control inteli...
4.3. TECNOLOGÍAS Y HERRAMIENTAS DEL AC TOOLKIT

41

• El Log and Trace Analyzer (LTA) puede ser usado para lograr maduraci...
42

CAPÍTULO 4. INTRODUC. Y TECNOLOGÍAS DEL AC TOOLKIT

— Solution Installation and Deployment Dependancy Checker.
• Manag...
4.4. AME

43

El RMB se usa para personalizar un AME.
El Adapter Rule Edition se usa con Generic Log Adapter.
EL SMD Edito...
44

CAPÍTULO 4. INTRODUC. Y TECNOLOGÍAS DEL AC TOOLKIT

curso, y averigua su estado. El AC Toolkit provee una herramienta ...
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
B learnin
Upcoming SlideShare
Loading in...5
×

B learnin

752

Published on

trabajo enfocado al b-learning

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
752
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "B learnin"

  1. 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
  2. 2. A mi familia y profesores
  3. 3. 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-
  4. 4. 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.
  5. 5. 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.
  6. 6. 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.
  7. 7. viii
  8. 8. Í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 . . . . . . . . .
  9. 9. 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
  10. 10. Í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
  11. 11. 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
  12. 12. Í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
  13. 13. xiv ÍNDICE GENERAL Bibliografía 257 Índice de Materias 259
  14. 14. Í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
  15. 15. 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
  16. 16. Í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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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.
  21. 21. 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.
  22. 22. 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.
  23. 23. 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.
  24. 24. 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.
  25. 25. 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.
  26. 26. 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.
  27. 27. 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
  28. 28. 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.
  29. 29. 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
  30. 30. 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
  31. 31. 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.
  32. 32. 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
  33. 33. 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.
  34. 34. 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.
  35. 35. 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):
  36. 36. 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,
  37. 37. 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
  38. 38. 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.
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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.
  43. 43. 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.
  44. 44. 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
  45. 45. 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
  46. 46. 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-
  47. 47. 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.
  48. 48. 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
  49. 49. 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.
  50. 50. 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.
  51. 51. 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
  52. 52. 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-
  53. 53. 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
  54. 54. 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.
  55. 55. 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.
  56. 56. 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.
  57. 57. 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-
  58. 58. 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

×