Desarrollo de una Aplicación de B-Learning Para el Aprendizaje del Autonomic Computing.

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
A mi familia y profesores
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-
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.
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.
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.
viii
Í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
.
.
.
.
.
.
.
.
.
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
Í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
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
Í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
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
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
Í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
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
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
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
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.
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.
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.
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.
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.
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.
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.
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
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.
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
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
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.
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
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.
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.
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):
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,
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
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.
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
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
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
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.
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.
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
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
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-
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.
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
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.
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.
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
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-
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
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.
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.
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.
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-
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
4.6. INST. DE LA SOLUCIÓN Y TECNOLOG. DE DESPLIEGUE
45
sistema de multiproducto.
4.6
Instalación de la Solución y Tecnologías de Despliegue
La instalación de la solución y las tecnologías de despliegue son también parte
del AC Toolkit.
A través de escenarios basados en instalación de aplicaciones de software
de líderes de la industria, el AC Toolkit muestra cómo éstas tecnologías pueden
usarse para mejorar las tareas de instalación y despliegue. Una tecnología que
se introduce en esta versión está en el área de chequeo de dependencia.
Chequeador de Dependencia: Este es otro ejemplo de una implementación
parcial de un administrador autonómico. El chequeador de dependencia implementa la parte de análisis de un administrador autonómico. El chequeador
de dependencia es llamado por el código de instalación de la aplicación para
validar las dependencias codificadas en un Solucion Module Descriptor (SMD).
Regresa una respuesta verdadera o falsa basado tanto en la existencia o no
de dependencia. Este está al nivel del código de instalación de la aplicación
para determinar la acción de esa respuesta. Las acciones apropiadas podrían
ser, no hacer caso de la condición y continuar la instalación, registrar un
mensaje, exhibir un panel al usuario, o terminar el proceso de la instalación.
Editor SMD: El Editor SMD es una herramienta usada para crear XML
que describe la unidad instalable (IU) y sus dependencias asociadas. Este XML
provee el conocimiento que el chequeador de dependencia usa para analizar
sistemas de dependencias efectivamente.
Se puede editar un SMD existente o empezar de cero.
4.7
Adaptador Genérico de Log
El Generic Log Adapter (GLA) o Adaptador Genérico de Log: es un ejemplo
de una tecnología que ayuda a un producto a crear un modelo de touchpoint
de un recurso AC. El GLA provee la habilidad de tomar un archivo log de un
producto de IBM o no, y convertir los mensajes al formato de datos Common
46
CAPÍTULO 4. INTRODUC. Y TECNOLOGÍAS DEL AC TOOLKIT
Base Event, así que el producto puede convertirse en un recurso administrado.
El GLA traduce las entradas de log de productos al Common Base Events
para uso de un administrador autonómico. El AC Toolkit incluye el GLA como
una tecnología para ayudar a los productos a adaptarse a la Arquitectura de
Referencia Autonómica sin requerir que el producto cambie la manera de crear
los archivos log.
Un run time (software de tiempo de ejecución) GLA sencillo puede usarse para analizar los archivos log de múltiples productos mientras las reglas
han sido definidas para cada formato de mensaje. El adaptador incluye un
manipulador que pasa la información Common Base Event al administrador
autonómico mediante la interfase de manejabilidad.
El GLA está disponible en el AC Toolkit en el paquete GLA/LTA. Un
escenario que muestra el GLA en una aplicación de auto-reparación se incluye
en el AC Toolkit.
En este escenario, GLA lee archivos log de productos actuales en tiempo
real. Usando un conjunto de reglas del programa analizador suministrado
para los productos del escenario, el adaptador traduce cada mensaje log al
formato Common Base Event. El GLA se muestra en el paquete de Problem
Determination Scenario.
Adapter Rule Editor o Editor de Reglas del Adaptador : Esta herramienta
se usa en conjunto con el GLA. Provee la herramienta para crear las reglas
de análisis específicas que son usadas por el GLA en tiempo de ejecución para
crear objetos Common Base Event. El Adapter Rule Editor está disponible
en el AC Toolkit en el paquete GLA/LTA.
4.8
Consola de Soluciones Integradas
Integrated Solutions Console o Consola de Soluciones Integradas: El objetivo
central de la Consola de Soluciones Integradas (ISC) es crear una plataforma sobre la que los productos IBM o no-IBM puedan construir interfases de
usuario administrativas.
Estandarizar los productos para ejecutar sobre la plataforma ISC les da
una apariencia y sensación más común y un comportamiento más constante,
porque se usan bloques de construcción comunes.
4.8. CONSOLA DE SOLUCIONES INTEGRADAS
47
Los administradores pueden interactuar con múltiples productos IBM o
no-IBM desde una consola basada en navegación.
ISC se basa en el WebSphere Portal, así las funciones administrativas son
manipuladas a través de portlets, o componentes, dentro de un sistema único.
Cuando un administrador agrega nuevo software, sus funciones administrativas
y archivos de ayuda son agregados al sistema administrativo común.
El ISC Toolkit es el entorno de desarrollo para crear plug-ins ISC y se
incluye en el paquete ISC. Incluye el run time (tiempo de ejecución) ISC, el
Integrated Solutions Console Developer Info Center o Centro de Información
de Desarrollo de Consolas de Soluciones Integradas y un plug-in ISC para
WebSphere.
Un componente de plug-in específico de ISC se provee en el AC Toolkit para
soportar el Problem Determination Scenario o Escenario de Determinación de
Problema.
La consola de AC Toolkit se configura para responder a los scripts de
modelo de recurso AME. Estos scripts ajustan los parámetros de estado según
van sucediendo situaciones, manteniendo informados a los administradores
sobre la condición de sus productos.
Además funciona como un ejemplo de cómo podrían ser creados los plug-ins
para otras aplicaciones de administración de productos de usuario específicos.
La consola AC Toolkit es solamente un ejemplo instructivo e ilustra sólo una
metodología posible. El componente ISC provee un completo conjunto de
documentación para el run time (tiempo de ejecución) así como también para
el ISC Toolkit.
Capítulo 5
Escenarios e Instalación de
AC Toolkit
5.1
Objetivos
Uno de los principales objetivos del AC Toolkit es proveer una muestra, fácil de
entender, de cómo las tecnologías del AC Toolkit pueden usarse para resolver
problemas del mundo real. Éstas muestras se proveen como una colección de
escenarios que se enfocan sobre atributos específicos de un entorno de AC.
Los tres escenarios incluidos en el AC Toolkit son simples representaciones
de típicos puntos de preocupación del cliente que puede gestionarse usando tecnologías AC. El propósito de éstos escenarios es demostrar cómo trabajan los
componentes del AC Toolkit en conjunto con el objeto de resolver problemas
del mundo real. Estos escenarios se sustentan con documentación y pueden ser
usados como ejemplos para ayudar a desarrollar una solución autonómica [6].
5.2
Escenario de Determinación de Problema
El escenario de Determinación de Problema muestra el atributo de autoadministración que el AC aporta a un entorno informático. Para que un
sistema sea auto-reparable, necesita ser capaz de reconocer que ha ocurrido
un problema, determinar la causa, y entonces tomar la acción adecuada para
49
50
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
corregir el problema. Un método de lograr esto es a través de archivos log
existente de un producto. Una de las tecnologías de AC Toolkit usada en el
escenario es el GLA que convierte eventos de archivos de log de productos al
formato de datos Common Base Event.
El escenario de Determinación del Problema muestra cómo un administrador autonómico, representado aquí por AME, puede ser usado para detectar
una situación de error entre dos productos IBM analizando los archivos de
log/trace (seguimiento/rastreo) y aplicando una acción correctiva.
El escenario usa dos productos IBM interactuando mutuamente para mostrar cómo se detecta y resuelve un problema común basado en Web. Se incluye
un producto sencillo de base de datos para ejecutar consultas básicas con acceso a bases de datos. La pregunta se origina desde una aplicación Web, también
incluida en el paquete del escenario.
El ISC es otra tecnología del AC Toolkit que se usa en este escenario. El
escenario incluye una consola de administración construida con la tecnología
ISC. Éste es usado para arrancar y terminar el escenario y además provee
un método de inducción de condición de falla y capacidades de monitoreo de
estado. La consola de administración arranca el escenario en un estado estable
mostrando la operación normal de los dos productos. Entonces, éste permite
inducir una falla de base de datos que es reconocida desde los archivos log de
las aplicaciones Web.
El modelo de recursos AME incluidos se programa para identificar la falla
de la base de datos. Después de que la situación haya sido detectada por
AME, la acción correctiva es emitida al recurso administrado. Cada fase de
la operación del ciclo de control se muestra en el panel de estados de la consola administrativa. Después de que haya sido corregida, la aplicación Web
comienza a funcionar otra vez y el escenario regresa al estado estable.
El escenario de Determinación del Problema ilustra el uso de las tecnologías en el AC Toolkit para llevar a cabo las siguientes tareas:
• Transformar un producto de archivo log en un formato de datos Common
Base Event.
• Personalizar AME con modelos de recursos.
• Mantener la comunicación entre el administrador autonómico y los recursos administrados.
5.3. ESCENARIO DE INSTALACIÓN AUTOMÁTICA
51
• Construir una consola administrativa usando la tecnología ISC.
• Construir un sistema funcional sencillo capaz de auto administrarse.
Después de ejecutar y observar el escenario de Determinación del Problema,
se puede aplicar la misma técnica para los propios productos y diseñar las
soluciones propias para la determinación de un problema.
5.3
Escenario de Instalación Automática
Los atributos de auto-configuración pueden mostrarse usando la solución de
instalación y tecnologías de despliegue disponibles en el AC Toolkit.
Los beneficios y versatilidades de la solución de instalación y tecnologías
de despliegue autonómicas se muestran proporcionando dos escenarios usando
dos diferentes productos de software de instalación proveídos por diferentes
fabricantes.
El propósito de los escenarios es demostrar los conceptos que respaldan a
la solución de instalación y tecnologías de despliegue mostrando la instalación
de un paquete de software basado el Web.
Cada escenario consiste de código, junto con un paquete descriptor que
explica el contenido y pre-requisitos. Éste paquete descriptor se llama “unidad
instalable” (UI o IU en inglés), y múltiples unidades son agrupadas dentro de
módulos de la solución.
La instalación de software de aplicación lee el archivo descriptor ejecutando
la instalación actual y chequea una base de datos de software y hardware
instalado para determinar si todos los pre-requisitos han sido encontrados. En
caso de que se disponga de ellos, el software es instalado y su información es
agregada a la base de datos. Si no fuera así, el instalador corrige el problema
localizando el software requerido e instalándolo para satisfacer los requisitos
necesarios.
Se proveen dos escenarios basados en dos generadores de instaladores de
aplicaciones de software. Un escenario usa ISMP desde el InstallShield como el
software generador, mientras que el otro escenario usa InstallAnywhere desde
Zero G. El escenario generador de instaladores contiene el run time (tiempo
52
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
de ejecución) de la solución de instalación y de despliegue, así como también
el necesario autoarranque.
5.4
El Paquete AC Toolkit
El contenido del AC Toolkit es muy amplio y variado para ser descargado
íntegramente; por lo tanto, gran cantidad de contenido había estado sin ser
aprovechado dentro de un puñado de paquetes fáciles de obtener. Este paquete
ayuda a tomar el contenido correcto sin tener que conocer todos los detalles
específicos del AC Toolkit y se evita bajar más contenido del que uno quiere
o necesita.
Los siguientes paquetes están disponibles en el AC Toolkit:
• Autonomic Computing Information.
• AME.
• RMB.
• Integrated Solutions Console.
• Solution Installation and Deployment.
• Generic Log Adapter and Log and Trace Analyzer.
• Problem Determination Scenario.
• Solution Installation and Deployment Scenario Using ISMP.
• Solution Installation and Deployment Scenario Using InstallAnywhere.
Las siguientes secciones describen, en detalle, cada uno de los paquetes
disponibles.
5.4.1
AC Information
Este paquete contiene todo lo pertinente a las referencias de AC, documentación, y tutoriales que describen al AC Toolkit. Es un buen punto de comienzo
para aquellos que quieren llegar a saber más sobre AC y AC Toolkit:
5.4. EL PAQUETE AC TOOLKIT
53
• Contenido del Paquete: Este paquete incluye sólo documentación.
• Pre requisitos: Este paquete no tiene pre requisitos.
• Paquetes Relacionados: Esta documentación describe el AC Toolkit de
manera general.
5.4.2
AME
Este paquete contiene el componente AME :
• Contenido del Paquete: Este paquete incluye:
— AME V1.0.
— Documentación (AME 1.0 Developer’s Guide).
• Pre requisitos: Este paquete no tiene pre requisitos.
• Paquetes relacionados: Los siguientes paquetes están relacionados:
— Problem Determination Scenario: Muestra una solución autonómica actual e incluye las API’s estandarizadas.
— RMB: Requerido si se desea modificar las funciones del AME.
5.4.3
RMB
Este paquete contiene el componente RMB.
• Contenido del Paquete: Este paquete incluye:
— RMB V1.2.
— Requiere el Workbench V2.1.2 basado en “Eclipse”.
• Pre requisitos: Este paquete no tiene pre requisitos.
• Paquetes relacionados: Los siguientes paquetes están relacionados:
— AME.
— Problem Determination Scenario.
54
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
5.4.4
Integrated Solutions Console
Este paquete contiene el componente de ISC.
• Contenido del Paquete: Este paquete incluye:
— Integrated Solutions Console run time V5.0.1.
— Integrated Solutions Console V5.0.1.
— Eclipse V2.1.1.
— EMF V1.1.0.
• Pre requisitos: ISC requiere que el sistema tenga una entrada DNS y
que pueda determinarse el nombre del host. Si el sistema no tiene una
entrada DNS, se puede actualizar la siguiente en el archivo de hosts:
127.0.0.1.nombre.del.servidor, donde nombre.del.servidor es el
nombre del servidor si no se tiene una entrada DNS para el servidor.
• Paquetes relacionados: El paquete Problem Determination Scenario muestra cómo puede crearse y usarse un plug-in de ISC para administrar una
real solución de auto-administración.
5.4.5
Solution Installation and Deployment
Este paquete contiene la solución de instalación y tecnologías de despliegue.
• Contenido del Paquete: Este paquete incluye:
— Solution Installation and Deployment Run Time V1.1.
— SMD Editor V1.0.
— Documentación sobre cómo usar Solution Installation and Deployment para desplegar sistemas simples y complejos:
∗ Solution Installation and Deployment Technology Overview v1.1.
∗ Solution Installation and Deployment Developer’s Guide v1.1.
∗ Solution Installation and Deployment Release Notes v1.1.
• Pre requisitos: SMD Editor requiere Eclipse y EMF.
5.4. EL PAQUETE AC TOOLKIT
55
• Paquetes relacionados: Los siguientes paquetes están relacionados:
— Solution Installation and Deployment Scenario using ISMP.
— Solution Installation and Deployment Scenario using Zero G.
5.4.6
Generic Log Adapter and Log Trace Analyzer
Este paquete contiene el Generic Log Adapter y el Log and Trace Analyzer
Tool.
• Contenido del Paquete: Este paquete incluye:
— Generic Log Adapter Run Time V1.3.
— Rule Editor V1.3.
— Product Rules V1.3.
— Log and Trace Analyzer para AC V1.3.
— Eclipse V2.1.1.
— EMF V1.1.0.
• Pre requisitos: JDK 1.3.1 o superior se requiere para usar este paquete.
• Paquetes relacionados: El paquete Problem Determination Scenario muestra cómo el Generic Log Adapter es usado en tiempo real para una solución autonómica.
5.4.7
Problem Determination Scenario
Este paquete contiene el Problem Determination Scenario.
• Contenido del Paquete: Este paquete incluye:
— Modelo de recurso Canonical Situation Monitor.
— Integrated Solutions Console plug-in for Problem Determination
Scenario.
— Script para automación para Problem Determination Scenario.
56
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
— Ejemplo de una aplicación WebSphere Application Server.
— Configuración de archivos GLA-LTA para Problem Determination
Scenario.
— Base de Datos Cloudscape.
— Clases Java de ayuda para la interfase de manejabilidad.
— IBM Autonomic Computing Toolkit Problem Determination Log/Trace
Scenario Guide.
• Pre requisitos Importantes: Los pre requisitos enumerados a continuación se requieren para la instalación de una funcionalidad del escenario
de determinación de problemas. No obstante, una nueva opción de instalación permite dejar de lado la instalación de los pre requisitos para
poder ir viendo los archivos del escenario. Esta instalación permite la
extracción y la vista de los archivos pero no es una instalación de escenario funcional. Para cambios posteriores en una instalación funcional, se
requiere una desinstalación y una reinstalación del paquete PDScenario.
— Se deben tener los siguientes componentes instalados para poder
usar este paquete:
— AME V1.0.
— Integrated Solutions Console V5.0.1.
— Generic Log Adapter and Log and Trace Analyzer for Autonomic
Computing V1.3.
— El modelo de recurso proporcionado con el Problem Determination
Scenario requiere de un archivo fuente abierto llamado Regular Expression for Java gnu-regexp.jar v1.1.1 o superior.
• Paquetes Relacionados: Este paquete usa tecnologías contenidas en los
siguientes paquetes:
— Paquete AME.
— Paquete RMB.
— Paquete GLA y LTA.
5.4. EL PAQUETE AC TOOLKIT
5.4.8
57
Solution Installation and Deployment Scenario Usando
ISMP
Este paquete contiene el escenario de la solución de instalación y de despliegue
usando ISMP.
• Contenido del Paquete: Este paquete incluye:
— Solution Installation and Deployment Run Time V.1.1.
— InstallShield ISMP V5.0.
— ISMP V5.0 Run Time.
— Descriptor XML.
— Solution Installation and Deployment Using ISMP.
• Pre requisitos: El Editor SMD requiere Eclipse y EMF.
• Paquetes Relacionados: Los siguientes paquetes están relacionados:
— Solution Installation and Deployment Scenario.
— Solution Installation and Deployment Scenario using InstallAnywhere.
5.4.9
Solution Installation and Deployment Scenario Using InstallAnywhere
Este paquete contiene la instalación de la solución y el escenario de despliegue
usando InstallAnywhere.
• Contenido del Paquete: Este paquete incluye:
— Solution Installation and Deployment Run Time.
— Zero G InstallAnywhere.
— Descriptor XML.
— Solution Installation and Deployment Using InstallAnywhere.
• Pre requisitos: SMD Editor requiere Eclipse y EMF.
58
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
• Paquetes relacionados: Los siguientes paquetes están relacionados:
— Solution Installation and Deployment Scenario.
— Solution Installation and Deployment Scenario using ISMP.
5.5
Descarga del Paquete AC Toolkit
Cuando se está listo para probar una herramienta, tecnología, o escenario del
AC Toolkit, se necesitará decidir qué paquete se requiere, se deberá asegurar
que se cuenta con los pre requisitos necesarios, y descargar el código desde el
sitio Web developerWorks: www.ibm.com/developerworks/autonomic/
Para descargar el código, se deben ejecutar los siguientes pasos:
1. Ir a la página principal del AC Toolkit. Esta página ayuda a decidir qué
paquete o paquetes se desea descargar.
2. Leer la lista de pre requisitos y asegurarse de que éstos están instalados
en el sistema.
3. Cuando todo esté listo para la descarga, ir a la página de descargas.
4. Hacer cick sobre el link del paquete seleccionado.
Si existiera algún inconveniente con este proceso, enviar una pregunta al
foro de ayuda. La primera vez que se usa el foro se debe crear una identificación
de usuario y una clave, pero se debe volver a usar esta misma identificación
cada vez que se envía una pregunta al foro.
5.6
Instalación del Paquete AC Toolkit
Esta sección describe la instalación del paquete AC Toolkit.
5.6.1
Vista General de la Instalación
Los paquetes del AC Toolkit generalmente son instalados de la misma manera
para mayor consistencia. Así mismo, algunos paquetes contienen sólo un com-
5.6. INSTALACIÓN DEL PAQUETE AC TOOLKIT
59
ponente, mientras que otros contienen múltiples componentes, lo cuál implica
que la instalación se presente de diferentes modos.
Los paquetes son archivos ejecutables que ejecutan sus propias instalaciones; esto ayuda a crear instalaciones consistentes y minimiza errores de
usuario. La información de la registración es logeada dentro del registro cuando se instala el paquete. Esta información registrada es usada para futuras
instalaciones y chequeos de pre requisitos.
5.6.2
Prerequisitos
Los siguientes ítems son requeridos para correr el AC Toolkit:
• Procesador Intel Pentium II (Pentium III 500 MHz o superior recomendado).
• 512 MB de RAM (768 MB de RAM recomendado).
• Espacio en disco requerido:
— Espacio en disco para instalación como se muestra en la Tabla 5.1
de la pág. 60 y en la Tabla 5.2 de la pág. 61.
— Espacio en disco adicional para el despliegue de recursos.
— Espacio en disco adicional requerido si se descarga la imagen electrónica para la instalación de esta tecnología1 .
• Monitor con resolución de 800 x 600 (1024 x 768 recomendado).
• Uno de los siguientes navegadores Web para uso del ISC y la visualización, tanto de las licencia de uso como de la ayuda en línea:
— Para Linux y sistemas AIX, Netscape 7.
— Para sistemas Windows:
∗ Microsoft Internet Explorer 6.x y 7.
∗ Mozilla 1.0.2.
1
EL mínimo espacio en disco puede reducirse si las características opcionales y los entornos
de run time (tiempo de ejecución) no son instalados.
60
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
• Java con el path del sistema actualizado y la variable JAVA_HOME,
actualizada. Las siguientes JVMs son soportadas:
— IBM Java 2 Standard Edition V1.4.1 JRE or Developer Kit.
— Sun Java 2 Platform, Standard Edition (J2SE) V1.4.1 (J2SE) JRE
or SDK.
Componentes
AME
GLA/LTA
Integrated Solution Console
Problem Determination Scenario
Solution Installation and Deployment
InstallAnywhere Scenario
Solution Installation and Deployment
ISMP Scenario
Total
Espacio requerido
12 MB
235 MB
224 MB
27 MB
228 MB
316 MB
1024 MB
Tabla 5.1: Espacio requerido por instalaciones Linux y AIX.
5.6.3
Plataformas Soportadas
Todos los componentes del AC Toolkit requieren una de las siguientes plataformas:
• Componentes run time (tiempo de ejecución) y escenarios:
— IBM AIX V5.2.
— Red Hat Enterprise Linux V2.1 (en Intel 32).
— SuSe Linux Enterprise Server V8 (en Intel 32).
— Microsoft Windows 2000 Server (Service Pack 3 o superior).
— Microsoft Windows 2000 Advanced Server (Service Pack 3 o superior).
• Facilidades:
5.6. INSTALACIÓN DEL PAQUETE AC TOOLKIT
Componentes
AME
GLA/LTA
Integrated Solution Console
RMB
Problem Determination Scenario
Solution Installation and Deployment
Development
Solution Installation and Deployment
InstallAnywhere Scenario
Solution Installation and Deployment
ISMP Scenario
Total
61
Espacio requerido
12 MB
235 MB
235 MB
55 MB
27 MB
25 MB
228 MB
315 MB
1132 MB
Tabla 5.2: Espacio requerido por instalaciones Windows.
— Microsoft Windows 2000 Server (Service Pack 3 o superior).
— Microsoft Windows 2000 Advanced Server (Service Pack 3 o superior).
— Microsoft Windows XP (Service Pack 1).
5.6.4
Instalación del Paquete AC Toolkit
Para instalar el paquete AC Toolkit, se deben realizar los siguientes pasos:
1. Verificar los requerimientos de sistema necesarios para ejecutar el paquete.
2. Doble cliquear en el archivo ejecutable para comenzar la instalación.
Aparece el panel Welcome.
3. Cliquear Next. Si el paquete ya está instalado en el sistema, un mensaje
de advertencia aparecerá indicando que una versión previa está instalada
y pregunta si se desea proseguir. Para proseguir, realizar uno de los
siguientes pasos:
• Cliquear Cancel en la ventana del mensaje de advertencia para
abortar la nueva instalación y mantener la instalación previa.
62
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
• Cliquear Yes para continuar la instalación.
4. Aceptar los términos del panel de Licencia y cliquear Next. El panel
Install Location muestra la ubicación por defecto de la instalación. El
panel Feature List lista los detalles de la instalación.
5. Realizar una de las siguientes acciones: aceptar la ubicación por defecto
o reemplazarla por otra. Cliquear Next para instalar en esa ubicación.
6. Cuando se completa la instalación, una nueva ventana de mensaje informa que el proceso ha finalizado. Cliquear Finish para salir del asistente
de instalación2 .
5.6.5
Desinstalación del Paquete AC Toolkit
Para desinstalar el paquete AC Toolkit, realizar los siguientes pasos:
1. Doble click en el archivo ejecutable Uninstall.exe situado en el directorio
de instalación. Aparece el panel de Welcome.
2. Cliquear Next. Se muestran detalles de la desinstalación.
3. Cliquear Next para desintalar el paquete de la máquina. Cuando se
completa la desinstalación, aparece una ventana de mensaje final.
4. Cliquear Finish para salir del asistente de desinstalación.
5.7
Instalación de la ISC
Esta sección describe cómo instalar ISC.
5.7.1
Antes de Comenzar
Antes de comenzar el proceso de instalación de la ISC, de deben ejecutar los
siguientes pasos:
2
Se recomienda que se ejecute una instalación a la vez.
5.7. INSTALACIÓN DE LA ISC
63
1. Desinstalar cualquier versión anterior de la ISC.
2. Opcionalmente, borrar todos los directorios temporales antes de proceder
con la instalación de la Integrated Solutions Console.
5.7.2
Requerimientos Para la Instalación de la ISC
1. Previo a la instalación de este escenario debe ser instalado uno de los
siguientes paquetes JRE 1.4.1 :
• IBM Java 2 Standard Edition V1.4.1 JRE o Developer Kit.
• Plataforma Sun Java 2, Standard Edition (J2SE) V1.4.1 (J2SE)
JRE o SDK2.
2. La instalación del ISC requiere como mínimo 275 MB de espacio libre en
la unidad %tmp% en Windows y 550 MB de espacio libre en la unidad
$tmp para AIX y Linux .
3. Chequeo de una dirección IP estática.
La ISC asume que el sistema de host está usando una dirección IP estática
en lugar de una dirección IP asignada dinámicamente. Por lo tanto, se debe
configurar la máquina usando una dirección IP estática. Si se instala la ISC
para el uso de sólo una persona y ningún otro usuario necesitará acceder a
la instalación ISC, se debe configurar el sistema a fin de que el puerto IP se
mapee al nombre de host cualificado completamente.
Para facilitar el mapeo, se agrega las siguientes líneas al archivo de hosts.
Por ejemplo, en Windows el archivo de hosts se localiza en C:\ WINNT\
system32\ drivers\ etc\ host:
127.0.0.1 localhost
127.0.0.1 nombre.del.servidor.
1. Chequear los múltiples adaptadores siguiendo los siguientes pasos:
• En Windows, cliquear Settings → Control Panel. Se despliega
la ventana del Panel de Control. Cliquear Network and Dial-up
Connections. Se despliega la ventana de Conexiones de Redes y
Dial-up.
64
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
• En el menú principal, cliquear Advanced → Advanced Settings.
Se despliega la ventana de Configuraciones Avanzadas.
• En la lista Connections, verificar que el adaptador de red adecuado está primero en la lista. Si el adaptador no está primero,
seleccionarlo y usar el teclado de flechas para moverlo al principio
de la lista. Ejecutar la instalación después de finalizar este procedimiento.
2. Si se usa el IBM JRE/JDK 1.4.1 como la JVM predeterminada, ejecutar los siguientes pasos antes de proceder con la instalación de la ISC
para Windows; esto habilita al instalador de la ISC a usar el Java embebido con el paquete instalado ISC. Se debe observar que el directorio
%TEMP% \ISCImage se crea durante la instalación y se borra después
de la instalación.
(a) Abrir la ventana de comando.
(b) Tipear: SET PATH=%TEMP% \ISCImage \RuntimeExt \ewase
\windows \java \bin; %PATH% y presionar Enter.
(c) Tipear ISC_Win32.exe y presionar Enter para comenzar la instalación de la ISC.
(d) Después de completarse la instalación, cerrar la ventana.
3. El Toolkit ISC puede ser instalado sobre Windows XP, sin embargo,
durante la instalación, se reporta un error que expresa que el ISC runtime
no pudo ser instalado. Aparece un aviso para continuar.
• Se selecciona Continuar para instalar sin el runtime.
• Se selecciona Cancel para abandonar la instalación.
5.7.3
Instalación de la ISC
Para instalar la ISC, ejecutar los siguientes pasos:
La Fig. 5.1 de la pág. 65 muestra la ventana de Bienvenida que aparece
en la pantalla con el nombre del producto y la corporación. Cliquear Next.
La ventana de Licencia aparece mostrando la licencia. Ver Fig. 5.2 de la
pág. 65.
5.7. INSTALACIÓN DE LA ISC
Figura 5.1: Ventana de bienvenida a la ISC.
Figura 5.2: Ventana de licencia de la ISC.
65
66
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
Figura 5.3: Ventana de información de la ubicación de la instalación de la
ISC.
Seleccionar el botón de ellección: I accept the terms in the license
agreement y cliquear Next. Ver Fig. 5.2 de la pág. 5.2. Aparece la ventana de información de la instalación, la cual brinda información acerca de la
ubicación de la instalación. Ver Fig. 5.3 de la pág. 66.
Ingresar la ubicación donde la ISC será instalada o aceptar la ubicación
que se muestra como predeterminada. Cliquear Next para continuar con la
ventana de Cuentas de Administrador de la ISC. Ver Fig. 5.4 de la pág. 67.
Se debe ingresar el nombre de usuario del servidor del portal de la ISC
y la contraseña como muestra en la Fig. 5.4 de la pág. 67. Este nombre de
usuario y contraseña se requerirán para ingresar a la consola. Cliquear Next.
Completar el nombre del host y cliquear Next. Ver Fig. 5.5 de la pág. 67.
Completar la localización de los puertos disponibles o aceptar los predeterminados. Cuando se finaliza con la primer ventana (ver Fig. 5.6 de la
pág. 68), cliquear Next para pasar a la segunda ventana de puertos, también
disponibles (ver Fig. 5.7 de la pág. 68).
5.7. INSTALACIÓN DE LA ISC
Figura 5.4: Ventana de cuentas de administrador de la ISC.
Figura 5.5: Nombre del host y localización del puerto.
67
68
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
Figura 5.6: Localizaciones de puertos nuevos - ventana 1.
Figura 5.7: Localizaciones de puertos nuevos - ventana 2.
5.7. INSTALACIÓN DE LA ISC
69
Figura 5.8: Ventana de plug-ins del WSphere Application Developer.
La ventana mostrada en la Fig. 5.8 de la pag. 69 ofrece la opción de
instalar WebSphere Studio Application Developer plug-ins durante esta instalación. Seleccionar la caja de verificación si los plug-ins de WebSphere Studio
Application Developer necesitan estar instalados. Cliquear Next.
Si se selecciona la caja de verificación mostrada en la Fig. 5.8 de la pág.
69, aparece la ventana mostrada en la Fig. 5.9 de la pág. 70. Ingresar el
directorio donde será instalado el WebSphere Studio Application Developer y
cliquear Next.
La ventana de resumen de la ISC muestra detalladamente la localización de
la instalación, características seleccionadas, y el tamaño total de la instalación
(ver Fig. 5.10 de la pág. 71). Verificar la información y cliquear Next.
La Fig. 5.11 de la pág. 71 y la Fig. 5.12 de la pág. 72 muestran el
porcentaje de terminación del proceso de instalación. Cuando el proceso se
completa, cliquear Next.
Cuando aparece la última ventana mostrada en la Fig. 5.13 de la pág. 72,
cliquear Finish (el proceso final de instalación puede tomar varios minutos).
70
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
Figura 5.9: Ventana de localización de instalación del WebSphere Studio Application Developer.
5.7. INSTALACIÓN DE LA ISC
71
Figura 5.10: Ventana de localización e información de la instalación de la ISC.
Figura 5.11: Proceso de extracción de la ISC.
72
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
Figura 5.12: Proceso de finalización de la ISC.
Figura 5.13: Ventana del proceso final de la instalación de la ISC.
5.8. ARRANCAR Y DETENER LA ISC
5.7.4
73
Desinstalar la ISC
Para desinstalar la ISC, se deben ejecutar los siguientes pasos:
1. Para Windows:
(a) Ir a Start → Settings → Control Panel.
(b) Doble click sobre el ícono de Add/Remove Programs.
(c) Elegir IBM Integrated Solutions Console en la lista de aplicaciones y cliquear el botón Change/Remove para desinstalar la
ISC.
(d) Reiniciar el sistema.
2. Para Linux y AIX :
(a) Ir a la carpeta: uninst2.
(b) Doble click sobre el archivo: uninstaller.bin.
(c) Reiniciar el sistema.
5.8
Arrancar y Detener la ISC
Después de una instalación exitosa, el programa de instalación de la ISC,
arranca automáticamente a la ISC y su sistema de ayuda. Cuando la máquina
se reinicia, el servidor del portal de la ISC está en estado de detención. La
ISC no funciona si el portal del servidor ISC no está activado.
Para arrancar la ISC y su sistema de ayuda:
1. Abrir la ventana de comando en el sistema donde está instalada la ISC.
2. Ejecutar los siguientes comandos para arrancar el servidor:
• Para sistemas Windows, tipear: la_raiz_isc \Runtime \AppServer
\bin \startServer.bat ISC_Portal y presionar Enter.
• Para AIX, Linux, y sistemas Solaris, tipear: la_raiz_isc /Runtime
/AppServer /bin /startServer.sh ISC_Portal y presionar Enter.
74
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
Figura 5.14: Windows.
Para cualquier sistema, la_raiz_isc es el directorio raíz de la instalación
de la ISC.
3. Ejecutar los siguientes comandos para arrancar el sistema de ayuda de
la ISC :
• Para sistemas Windows, tipear: la_raiz_isc \Runtime \PortalServer
\ISCEclipse \StartEclipse.bat y presionar Enter.
• Para AIX, Linux, y sistemas Solaris, tipear: la_raiz_isc /Runtime
/PortalServer /ISCEclipse /StartEclipse.sh y presionar Enter.
Para cualquier sistema, la_raiz_isc es el directorio raíz de la instalación
de la ISC.
5.8.1
Secuencia Gráfica de Arranque y Detención de la ISC
En la Fig. 5.14 de la pág. 74, la Fig. 5.15 de la pág. 75 y la Fig. 5.16 de la
pág. 75, se muestra gráficamente la secuencia de pasos necesaria para arrancar
y detener la ISC.
Para Windows:
• El arranque directo está enlazado al archivo startISCServers.bat que abre
startServerISC_Portal&server1 desde la ubicación de la ISC.
Para Linux :
5.8. ARRANCAR Y DETENER LA ISC
Figura 5.15: Linux.
Figura 5.16: AIX.
75
76
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
• El arranque directo está enlazado al archivo startiscervers.sh que abre
ISC_Portal&server1 desde la ubicación de la ISC.
Para AIX :
• El arranque directo está enlazado al archivo startiscervers.sh que abre
ISC_Portal&server1 desde la ubicación de la ISC.
En AIX, los productos son instalados por el usuario raíz. Como resultado,
los accesos directos solamente están accesibles para el usuario raíz. Si otros
usuarios necesitan acceder al producto y a los accesos directos, se necesita
cambiar manualmente los permisos. Después de que los accesos directos son
agregados a cada usuario, se debe actualizar las aplicaciones de escritorio
para ver el acceso directo en el administrador de aplicaciones ejecutando los
siguientes pasos:
1. Abrir el Application Manager → Desktop Tools.
2. Doble click sobre: Reload Desktop Applications.
3. Regresar al Application Manger. Ahora está disponible el acceso directo
(shortcut) del IBM Autonomic Computing Toolkit.
Para detener la ISC y su sistema de ayuda:
1. Abrir una ventana de comando en el sistema donde fue instalada la ISC.
2. Ingresar los siguientes comandos para detener el servidor :
• Para sistemas Windows, tipear: la_raiz_isc \Runtime \AppServer
\bin \stopServer.bat ISC_Portal y presionar Enter.
• Para sistemas AIX, Linux, y Solaris, tipear: la_raiz_isc /Runtime
/AppServer /bin /stopServer.sh ISP_Portal y presionar Enter.
Para cualquier sistema la_raiz_isc es el directorio raíz para la instalación de la ISC.
3. Ejecutar el siguiente comando para detener el sistema de ayuda:
5.9. INSTALAR EL PLUG-IN DE LA ISC
77
• Para sistemas Windows, tipear: la_raiz_isc \Runtime \PortalServer
\ISCEclipse \StopEclipse.bat y presionar Enter.
• Para sistemas AIX, Linux, y Solaris, tipear: la_raiz_isc /Runtime
/PortalServer /ISCEclipse /StopEclipse.sh y presionar Enter.
Para cualquier sistema, la_raiz_isc es el directorio raíz para la instalación de la ISC.
5.9
Instalar el Plug-in de la ISC para el Desarrollador de Aplicaciones
El programa de instalación de la ISC provee una opción para instalar el plugin de la ISC para el WebSphere Studio Application Developer V5.0. El plugin de la ISC incluye un asistente y un editor que hace fácil la creación de un
archivo component.xml y agrega ese archivo a un proyecto de aplicación portlet
existente.
Antes de instalar el plug-in, instalar el WebSphere Studio Application Developer V 5.0. Una vez que el Application Developer está instalado, el plug
está incluído cuando se instala la Integrated Solutions Console Toolkit. Para
usar el plug-in se necesita además el WebSphere Portal Toolkit, versión 4.2.5
o 4.3.
El plug-in provee documentación de ayuda que describe cómo usar el asistente y el editor, y cómo ejecutar manualmente algunas tareas que el plugin no hace automáticamente. Para ver la documentación, cliquear Help →
Help Contens en la barra de herramientas para WebSphere Studio Application Developer. La ayuda se muestra en una ventana separada. Cliquear la
documentación de Integrated Solutions Console a la izquierda del esquema de
navegación. Luego cliquear el subtópico que se desea ver.
5.10
Verificación de la Instalación
Para verificar que la ISC se ha instalado satisfactoriamente:
1. Usar el navegador para abrir la URL de la ISC : http: //nombre .del
.servidor :isc_port /ibm /console, donde nombre.del.servidor es el nom-
78
CAPÍTULO 5. ESCENARIOS E INSTALACIÓN DE AC TOOLKIT
bre del host para la instalación de la ISC y isc_port es el puerto para
la ubicación de la ISC durante la instalación. Especificar el nombre
del protocolo (http) en la URL, porque la URL contiene un número de
puerto. Este número de puerto se encuentra en la_raiz_isc \Runtime
\isc.properties. Dónde la_raiz_isc es el directorio raíz para la instalación de la ISC.
2. Iniciar sesión como administrador de la ISC. Especificar la ID del usuario
configurado durante la instalación del Toolkit. La ID del usuario por
defecto es iscadmin.
3. Cliquear la opción Settings. Se muestra el esquema de navegación de
los escenarios.
4. Cliquear User and Group Management. La página se muestra en el
área de trabajo.
5. Para ver la ayuda para los portlet en la página, cliquear el ícono de ayuda
portlet (el símbolo ?). El tópico de ayuda de usuarios Manage muestra
grupos en una ventana separada. Cerrar la ventana.
6. En la barra de herramientas de la ISC, cliquear Help. Se inicia una
ventana separada y se muestra un marco (frame) de navegación para
acceder a la Integrated Solutions Console Basics de la ISC y al Integrated
Solutions Console Developer InfoCenter.
7. Para cerrar sesión de la consola, click Log off en la barra de herramientas. Se muestra la página de Login.
5.11
Resolver Problemas de Instalación
Proceder con el siguiente chequeo si ocurren problemas durante la instalación
de la ISC :
1. Verificar que se completaron todas las instrucciones de instalación.
2. Asegurarse de que están instalados los prerequisitos correctos.
3. Asegurarse de que son correctas todas las configuraciones (tales como
ID de usuario y contraseñas).
5.11. RESOLVER PROBLEMAS DE INSTALACIÓN
79
4. Chequear los mensajes de error en los archivos log de instalación.
5. Si el problema no ha sido resuelto, desinstalar la ISC y entonces instalarla nuevamente.
Capítulo 6
Escenario de Determinación
de Problemas
6.1
Introducción al escenario de Determinación de
Problemas
El escenario de determinación de problemas presenta un sistema de autoadministración simple que usa un ciclo de control inteligente para recolectar
información del sistema, analizarla, planificar una respuesta apropiada y luego
hacer los ajustes necesarios para resolver problemas [9].
Este escenario muestra las tecnologías específicas que estructuran un sistema de auto-reparación, y muestra cómo trabajan en conjunto para lograr
un nivel adaptativo (nivel 4 de los niveles de maduración autonómica) de la
auto-administración.
El escenario sirve como vehículo educacional para introducir el atributo
de auto-reparación de un entorno autonómico, así como también proveer una
demostración de las tecnologías involucradas que actualmente logran que esto
suceda.
Examinar este escenario establecerá las bases que permitirán comenzar con
la creación de sistemas de auto-reparación propios.
Este escenario demuestra la interacción entre un administrador autonómico
y un recurso administrado, como se define según la arquitectura de referencia
81
82CAPÍTULO 6. ESCENARIO DE DETERMINACIÓN DE PROBLEMAS
AC.
El recurso administrado produce datos Common Base Event desde archivos log de múltiples productos usando el Generic Log Adapter (GLA) que
está incluido en el AC Toolkit. Los datos del Common Base Event formateados se usan para comunicar la información del archivo log al administrador
autonómico en un formato común y uniforme.
El escenario muestra cómo la información del archivo log del recurso administrado fluye al administrador autonómico a través del uso de un “sensor”,
mientras el administrador autonómico analiza los datos y emite una acción
correctiva a través del uso de un “effector”.
La implementación de un administrador autonómico usada en este escenario es el Autonomic Management Engine (AME).
Para este escenario se ha construido especialmente un modelo dedicado de
recursos AME.
AME, con el uso del recurso modelo, detecta un error por el análisis de
datos de archivos log para condiciones específicas. Además, el escenario contiene una consola de administración, la cual ha sido desarrollada para el uso
de la Integrated Solutions Console incluída en el AC Toolkit.
Este sirve como ejemplo de cómo una consola de control puede ser construída para administrar componentes múltiples de un sistema autonómico.
Este escenario usa información de archivos log de productos estándar para
detectar, analizar, y corregir un problema común que involucra a múltiples
productos que interactúan.
El escenario muestra una depuración y una resolución más bien en un
sistema, que en un producto individual, lo cual es más útil en un entorno de
IT heterogéneo complejo. Con esto, se puede aplicar esos mismos conceptos
y técnicas para comenzar con la creación de una solución de auto-reparación
usando los productos propios.
Para este escenario se ha construido especialmente un modelo dedicado de
recursos AME.
AME, con el uso del recurso modelo, detecta un error por el análisis de
datos de archivos log para condiciones específicas. Además, el escenario contiene una consola de administración, la cual ha sido desarrollada para el uso
de la Integrated Solutions Console incluída en el AC Toolkit.
6.1. INTRODUCCIÓN AL ESCENARIO DE DETERMINACIÓN DE PROBLEMAS83
Este sirve como ejemplo de cómo una consola de control puede ser construída para administrar componentes múltiples de un sistema autonómico.
Este escenario usa información de archivos log de productos estándar para
detectar, analizar, y corregir un problema común que involucra a múltiples
productos que interactúan.
El escenario muestra una depuración y una resolución más bien en un
sistema, que en un producto individual, lo cual es más útil en un entorno de
IT heterogéneo complejo.
Con esto, se puede aplicar esos mismos conceptos y técnicas para comenzar con la creación de una solución de auto-reparación usando los productos
propios.
Supuestos: El escenario requiere un cierto nivel de familiaridad con los
conceptos y terminologías del AC.
Para entender los conceptos presentados en este escenario es necesario un
nivel introductorio de comprensión de los elementos esenciales de la arquitectura de referencia AC de IBM, incluyendo administradores autonómicos y
recursos administrados.
Limitaciones: este escenario está restringido para ejecutarse en una máquina simple.
Se dispone de una versión con la ejecución del escenario de determinación
del problema que usa Netscape Navigator V 7.0 y superior sobre Linux y AIX.
El resultado esperado cuando se invoca el link View Web Application en el
plug-in componente de la ISC es una nueva ventana que se abre para mostrar
el estado de la consulta ejecutada.
Los usuarios de Netscape Navigator 7.0 y superior necesitarán abrir la
aplicación en una nueva ventana.
El modelo de recurso suministrado con el escenario Problem Determination
requiere un archivo fuente abierto llamado Regular Expression for Java gnuregexp.jar V1.1.1 o superior.
84CAPÍTULO 6. ESCENARIO DE DETERMINACIÓN DE PROBLEMAS
6.2
Componentes y Diseño de Escenario
El escenario Problem Determination muestra un ciclo de control autonómico
operando sobre dos productos IBM, WebSphere Application Server - Express
y el Administrador de Base de Datos de la base Cloudscape, cada cual con su
información del producto de salida a un archivo log.
La base de datos se carga con datos de ejemplo. Se incluye una aplicación
Web para que se ejecute sobre WebSphere Application Server y se configura
para leer continuamente los datos de ejemplo desde la base de datos Cloudscape.
Como la aplicación Web hace consultas de la información de base de datos,
la información de eventos de salida de los productos consultan sus archivos
logs.
Estos archivos log de salida son la base para la creación de un sistema de
auto-reparación en este escenario.
Cuando un producto como IBM WebSphere Application Server - Express
envía información de un archivo log a un administrador autonómico para una
acción de análisis y corrección, el producto se convierte en un recurso administrado.
Administradores Autonómicos controlan los Recursos Administrados.
Para que el administrador autonómico sea capaz de analizar los datos del
archivo log, éstos deben estar según el formato de datos del Common Base
Event.
Puesto que los productos usados en este escenario no producen datos en el
archivo log en este formato, es necesario utilizar la tecnología del Generic Log
Adapter (GLA) para facilitar la conversión.
GLA fue seleccionada para ilustrar cómo los productos pueden participar
en la auto-reparación sin tener que modificar el producto.
El propósito del GLA en este escenario es recibir dinámicamente los archivos log de los productos y convertirlos en tiempo real al formato de datos del
Common Base Event.
Una vez que está en el formato de datos del Common Base Event, el GLA
se configura para pasar la información al administrador autonómico para su
6.2. COMPONENTES Y DISEÑO DE ESCENARIO
85
Figura 6.1: Diseño del escenario de determinación del problema.
análisis usando un estilo de interacción sensor estándar.
El administrador autonómico utiliza los datos del Common Base Event y
analiza los datos log usando un modelo de recurso dedicado, buscando eventos
específicos.
Después de que se ha detectado un evento, el administrador autonómico
emite una acción correctiva sobre el recurso administrado apropiado.
La administración y el control del escenario son manejadas por un componente plug-in impuesto a la Integrated Solutions Console (ISC) que fue creada
para el escenario Problem Determination.
6.2.1
Diseño del Escenario Problem Determination
El diseño del escenario Problem Determination puede ser dividido en los siguientes cuatro bloques como se muestra en la Fig. 6.1 de la pág. 85.
Autonomic Manager (Administrador Autonómico): AME es la implementación usada en este escenario para representar un administrador autonómico.
AME se comunica con el recurso administrado usando una serie de interfases sensor y effector.
Recurso Administrado: WebSphere Application Server - Express es el recurso administrado en este escenario.
86CAPÍTULO 6. ESCENARIO DE DETERMINACIÓN DE PROBLEMAS
Figura 6.2: Arquitectura de un escenario de determinación del problema.
Se ha creado una sencilla aplicación Web, haciendo referencia al Cloudscape
WebApp, que se ejecuta en WebSphere Application Server, interactuando con
la base de datos Cloudscape.
El GLA se usa para convertir mensajes log del WebSphere Application
Sever al formato de datos del Common Base Event, de esta manera se provee
una implementación de un tuchpoint de un recurso administrado.
Base de Datos Cloudscape: El recurso administrado interactúa con la
Cloudscape.
La base de datos Cloudscape se usa para inducir un error detectable en
este escenario1 .
Interfase de Usuario: La interfase de usuario para este escenario es la
Integrated Solutions Console.
Un estilo de plug-in específicamente desarrollado para este escenario permite ver y controlar la demostración del escenario.
Estos componentes pueden dejar de funcionar en algún momento como se
1
Cloudscape no es un recurso administrado. Para simplificar, Cloudscape se agrupa con
WebSphere Application Server (ver la Fig. 6.2 de la pág. 86).
6.3. COMPONENTES DEL ESCENARIO DE DP
87
muestra en la Fig. 6.2 de la pág. 86.
6.3
Componentes del Escenario de Determinación
del Problema
Esta sección describe los distintos componentes de este escenario.
AME : AME usa un modelo de recurso para monitorear el estado del recurso
administrado monitoreando el archivo de mensajes del Common Base Event
para detectar una condición de error.
El modelo de recurso creado específicamente para el escenario busca una
condición de error en el producto Cloudscape y determina la acción correctiva
apropiada.
Un programa Java inicia AME y ejecuta las siguientes acciones:
1. Si se ejecuta el escenario por primera vez:
(a) Instala el modelo de recurso (denominado CanonicalSituationMonitor).
(b) Crea una instancia del modelo de recurso.
(c) Inicia la instancia del modelo de recurso.
2. Si el escenario ha sido usado al menos una vez el programa Java arranca
la instancia del modelo de recurso que ya está instalado.
Una vez iniciada la instancia del modelo de recurso, éste se encarga de
detectar y reparar un problema.
El programa Java AME periódicamente chequea la existencia de un archivo
denominado: STOP_AME en el directorio de instalación del PD Scenario, el
programa finaliza si encuentra el archivo.
6.3.1
Componentes del Recurso Administrado
Cloudscape WebApp es una aplicación Web similar a una aplicación tradicional
que puede ser manipulada para demostrar el ciclo cerrado. Puede ser dividida
88CAPÍTULO 6. ESCENARIO DE DETERMINACIÓN DE PROBLEMAS
en dos partes:
1. Database (Base de Datos): Una base de datos de prueba sobre Cloudscape. Esto es una base de datos muy sencilla con sólo una tabla con
múltiples columnas y filas. Los datos se insertan en la tabla cuando ésta
se crea.
2. Web Application (Aplicación Web): La aplicación Web consiste de un
servlet (pequeño programa de aplicación ejecutado por un servidor) que
dispara múltiples consultas SELECT a la base de datos Cloudscape.
Base de Datos Cloudscape
La base de datos Cloudscape se puede iniciar de dos modos:
• Modo Embebido: Cuando una aplicación arranca una instancia de Cloudscape dentro de su Java Virtual Machine (JVM), la aplicación es indicada
para ejecutar en un entorno embebido. En este entorno, solamente una
aplicación puede acceder a una base de datos a la vez y no ocurren
accesos en red. La carga del driver embebido arranca el Cloudscape.
• Modo Cliente-Sevidor (modo en red): Cuando múltiples aplicaciones se
conectan a Cloudscape a través de la red, ejecutan en un entorno cliente/servidor. Cloudscape ejecuta embebido en un contexto de servidor
que permite múltiples conexiones de red.
El AC Toolkit usa Cloudscape en modo cliente-servidor.
Para arrancar y parar el servidor de red se usan archivos de lote del escenario.
El servidor usa el número del puerto por defecto (1527).
Un script del escenario se usa para crear e incrementar la base de datos a
ser usada por la aplicación Web.
Aplicación Web Cloudscape
La aplicación Web se despliega sobre WebSphere Application Server - Express.
El servlet conecta a la base de datos en el método init().
6.3. COMPONENTES DEL ESCENARIO DE DP
89
Una fuente de datos se define en el servidor de la aplicación, y éste es usado
por el servlet para conectar a la base de datos.
En el método doView()/doPost(), se ejecutan un gran número de consultas
SELECT sobre la base de datos.
Todos los mensajes mostrados por el servlet serán definidos en archivos
apropiados.
Los siguientes scripts son usados para instalar y administrar recursos sobre
WebSphere Application Server:
• Install Application (Instalar Aplicación): Para instalar la aplicación Web
sobre WebSphere Application Server - Express.
• Uninstall Application (Desinstalar Aplicación): Para desinstalar la aplicación Web desde WebSphere Application Server - Express.
• Configure Data Source (Configurar Fuente de Datos): Para configurar
fuente de datos Cloudscape sobre WebSphere Application Server - Express.
• Remove Data Source (Quitar Fuente de Datos): Para suprimir la configuración de una fuente de datos desde WebSphere Application Server Express.
• Stop/Start Application (Arrancar y Parar una Aplicación): Para arrancar y parar la aplicación Web sobre WebSphere Application Server Express.
Analizar Mensajes Log con el GLA
El run time tiempo de ejecución del GLA analiza el archivo log (activity.log) del WebSphere Application Server y convierte los mensajes log al
formato del Common Base Event para pasar al administrador autonómico
usando un estilo de interacción estandarizado.
El tiempo de ejecución del GLA requiere un archivo de configuración PDScenarioContext.adaptor.
Este archivo anuncia al run time la ubicación del archivo log (activity.log)
del WebSphere Application Server y dónde dejar los mensajes del Common
90CAPÍTULO 6. ESCENARIO DE DETERMINACIÓN DE PROBLEMAS
Base Event y define las reglas para convertir mensajes log al formato del
Common Base Event.
Las secciones importantes del adaptador desde la perspectiva del escenario
de determinación del problema se describen a continuación:
La clase executableClass (com.ibm.etools.logging. adaptor. outputters. ReceiveNotificationOutputter ) usa la administración API.
Esta clase envía los objetos Common Base Event al administrador (com.ibm.autonomic.scenario.
pd. manager. PDAutonomicManagerTouchpointSupport) usando RMI en lugar de grabar directamente en el Common Base Event a un archivo de salida.
En el escenario, el administrador graba el objeto del Common Base Event
al archivo de salida.
<hga:Component description=“CBE File Outputter”
executableClass=“com.ibm.etools.logging. adaptor. outputters. ReceiveNotificationOutputter”
implementationCreationDate=“2003-10-07T12:00:00”
implementationVersion=“1.0.0”
implementationVersionDescription=“A simple CBE outputter that takes a CBE
and writes it to a file”
loggingLevel=“60”
name=“CBEFileOutputter”
role=“outputter”
roleCreationDate=“2003-10-07T12:00:00”
roleVersion=“1.0.0”
roleVersionDescription=“initial release”
uniqueID=“AdaptorCBEOutputterID3”/>
El siguiente código informa al run time GLA, la ubicación del archivo log
del WebSphere Application Server.
6.3. COMPONENTES DEL ESCENARIO DE DP
91
El convertidor dice al GLA cómo convertir el archivo log de actividad del
binario al formato de texto:
<cc:Sensor description=““ maximumBlocking=”5”
type=“SingleFileSensor”
uniqueID=“sensorID3”>
<sensor:SingleFileSensor
converter=“"C:\ACComponents \ISC \Runtime \AppServer \bin \showlog.bat"
"C:\ACComponents \ISC \Runtime \AppServer\logs\activity.log"
"C:\Program Files \PdScenario_Home \activity.txt"”
directory=“C:\Program Files\PdScenario_Home\”
fileName=“activity.txt” />
</cc:Sensor>
El propósito de la siguiente regla de análisis es conseguir el nombre de la
aplicación Web desde un mensaje log:
<parser:RuleAttribute name=“application”
index=“0”>
<SubstitutionRule match=“.* \s+[aA]pplication \s*.*: \s*(.*)”
positions=“$h(‘PrimaryMessage’)”
substitute=“$1” />
<SubstitutionRule substitute=“UNKNOWN”/>
</parser:RuleAttribute>
La siguiente regla de análisis se usa para detectar si el escenario de la
aplicación Web ha arrancado:
<parser:RuleAttribute index=“1070522678551”
name=“situationQualifier”>
<SubstitutionRule match=“.*WSVR0200I:.*”
92CAPÍTULO 6. ESCENARIO DE DETERMINACIÓN DE PROBLEMAS
positions=“$h(‘PrimaryMessage’)”
substitute=“START INITIATED”/>
<SubstitutionRule match=“.*WSVR0221I:.*”
positions=“$h(‘PrimaryMessage’)”
substitute=“START COMPLETED”/>
<SubstitutionRule match=“.*WSVR0001I:.*”
positions=“$h(‘PrimaryMessage’)”
substitute=“START COMPLETED”/>
</parser:RuleAttribute>
El siguiente código se usa para detectar la condición de error:
parser:RuleElement index=“0”
name=“ConnectSituation”>
- <parser:RuleAttribute index=“0”
name=“successDisposition”>
<SubstitutionRule match=“.*DSRA0080E:.*”
positions=“$h(‘PrimaryMessage’)”
substitute=“UNSUCESSFUL” />
<SubstitutionRule match=“.*CONM7007I:.*”
positions=“$h(‘PrimaryMessage’)”
substitute=“UNSUCESSFUL” />
<SubstitutionRule match=“.*J2CA0056I:.*”
positions=“$h(‘PrimaryMessage’)”
substitute=“UNSUCESSFUL” />
<SubstitutionRule match=“.*SRVE0026E:.*”
6.3. COMPONENTES DEL ESCENARIO DE DP
positions=“$h(‘PrimaryMessage’)”
substitute=“UNSUCESSFUL” />
</parser:RuleAttribute>
- <parser:RuleAttribute index=“0”
name=“reasoningScope”>
<SubstitutionRule match=“.*DSRA0080E:.*”
positions=“$h(‘PrimaryMessage’)”
substitute=“INTERNAL” />
<SubstitutionRule match=“.*CONM7007I:.*”
positions=“$h(‘PrimaryMessage’)”
substitute=“INTERNAL” />
<SubstitutionRule match=“.*J2CA0056I:.*”
positions=“$h(‘PrimaryMessage’)”
substitute=“INTERNAL” />
<SubstitutionRule match=“.*SRVE0026E:.*”
positions=“$h(‘PrimaryMessage’)”
substitute=“INTERNAL” />
</parser:RuleAttribute>
- <parser:RuleAttribute index=“0”
name=“situationDisposition”>
<SubstitutionRule match=“.*DSRA0080E:.*”
positions=“$h(‘PrimaryMessage’)”
substitute=“CLOSED” />
<SubstitutionRule match=“.*CONM7007I:.*”
93
94CAPÍTULO 6. ESCENARIO DE DETERMINACIÓN DE PROBLEMAS
positions=“$h(‘PrimaryMessage’)”
substitute=“CLOSED” />
<SubstitutionRule match=“.*J2CA0056I:.*”
positions=“$h(‘PrimaryMessage’)”
substitute=“CLOSED” />
<SubstitutionRule match=“.*SRVE0026E:.*”
positions=“$h(‘PrimaryMessage’)”
substitute=“CLOSED” />
</parser:RuleAttribute>
</parser:RuleElement>
Interfase de Usuario
El control del escenario PD es proveído por la ISC. Un plug-in desarrollado
por el usuario provee una interfase de usuario para ejecutar y ver el escenario
de determinación del problema.
Esquema de páginas de la ISC
La Fig. 6.3 de la pág. 95 ilustra el panel de navegación del plug-in del
componente del escenario de AC.
Se proveen dos páginas:
1. Página de descripción: esta página se despliega cuando se selecciona
Scenario Description. Esta página da una detallada descripción del escenario Problem Determination. Tiene solamente un portlet, el cual
muestra una página JSP que contiene la descripción del escenario. La
página JSP mostrada está basada en el escenario local. No hay panel de
ayuda en línea disponible para esta página.
2. Página de Control: esta página se despliega cuando se selecciona Scenario Control. Esta página permite ejecutar y controlar el escenario.
Consiste de tres portlets ordenados como se muestra en la Fig. 6.4 de la
pág. 95. Hay un panel de ayuda en línea disponible para cada portlet.
6.3. COMPONENTES DEL ESCENARIO DE DP
Figura 6.3: Panel de navegación de la ISC.
Figura 6.4: Portlet de control de página.
95
96CAPÍTULO 6. ESCENARIO DE DETERMINACIÓN DE PROBLEMAS
Página de Control
Hay tres portlets en la página de control para controlar el escenario que
ejecutan tres tipos de operaciones:
Configuración del escenario: cuando se ejecuta este comando, el escenario
se configura y arranca en el background.
• Las siguientes operaciones son ejecutadas en el background:
— Arrancar el servidor de red del Cloudscape.
— Arrancar la aplicación Web.
— Arrancar el run time GLA.
— Arrancar AME y el modelo de recurso.
— Nota: Las siguientes actividades son llevadas a cabo cuando el escenario está instalado:
∗ Instalar recursos (aplicaciones Web y fuente de datos) sobre
WebSphere Aplication Server.
∗ Instalar componentes AC sobre la ISC.
∗ Crear la base de datos Cloudscape.
Condición inducida: Cuando se ejecuta este commando la condición e error
se induce y se muestra el ciclo (ver Fig. 6.5 de la pág. 97).
Cierre de escenario: Las siguientes operaciones se ejecutan en segundo
plano (background) para detener el escenario:
• Detener AME y el modelo de recurso.
• Detener el tiempo de ejecución de GLA.
• Detener la aplicación Web.
• Detener el servidor de red de Cloudscape.
El portlet de Control hace la registración de los procesos de cada operación
en un archivo en la ubicación apropiada.
Cada operación graba en el mismo archivo en modo de sobreescritura.
6.3. COMPONENTES DEL ESCENARIO DE DP
97
Figura 6.5: Induciendo y corrigiendo una condición de error.
Esto significa que en un momento dado, sólo están disponibles los mensajes
correspondientes a la última operación.
Cada una de las operaciones permitidas es un hipervínculo utilizable que
estará disponible o no según el contexto.
Contexto
Inicial
Arranque
Detención
Inicio del Escenario
Habilitado
deshabilitado
Habilitado
Condición Inducida
Deshabilitado
Habilitado
Deshabilitado
Fin del Escenario
Deshabilitado
Habilitado
Deshabilitado
Tabla 6.1: Estados de enlace basados en el contexto.
Capítulo 7
Instalación de la Solución y
Despliegue Usando
InstallAnywhere
7.1
Introducción a la Instalación de la Solución y
Escenario de Despliegue
La instalación de la solución y el escenario de despliegue apuntan al aspecto
de autoconfiguración de la computación autonómica. Hay cinco niveles de
maduración autonómica: básico, administrado, predictivo, adaptativo, y autonómico. La solución del escenario de instalación y despliegue aspira a ser
predictivo por naturaleza (nivel 3), habilitan el proceso de instalación del software para requerir menos la intervención del usuario. El proceso de instalación
puede predecir y alertar cuando falta una dependencia clave. Este comportamiento predictivo enriquece la confiabilidad y facultad de mantenibilidad de
los sistemas.
R
El escenario instala el servidor de aplicación WebSphere
Application
Server - Express Web y una página Web estática. El servidor WebSphere
Application Server - Express puede iniciarse y detenerse para mostrar que
todas las partes han sido instaladas. La página Web puede desplegarse para
mostrar que todos los archivos requeridos han sido instalados.
99
100
CAPÍTULO 7. INSTALACIÓN DE LA SOLUCIÓN
7.2
Beneficios de las Tecnologías de Instalación de
la Solución y de Despliegue
La incapacidad de identificar, validar, y actuar sobre las interdependencias de
software y prerequisitos a través de una infraestructura completa puede causar
fallas en la instalacion y configuración. Esto puede resultar en un esfuerzo
adicional significativo en rehacer el trabajo y en la pérdida de confianza en los
productos y soluciones.
Estas fallas tienen un impacto negativo en los negocios por el costo adicional de manejar el problema, diagnóstico y la solución en centros de llamadas,
centros de soporte, y laboratorios de desarrollo, para no mencionar la pérdida
de la satisfacción del cliente. Hay además una pérdida de prestigio para los
clientes causada por la demora o falla en el despliegue de sus infraestructuras
de IT.
La instalación de la solución autonómica y las tecnologías de despliegue
permiten soluciones de software a ser desplegadas y soportadas con una reducida intervención humana creando los siguientes servicios comunes:
• Una infraestructura común para garantizar una experiencia de despliegue
más simple y consistente.
• Un paquete común para minimizar el número de instancias del software
instaladas con una empresa. Estas instancias pueden ser usadas para
nuevas instalaciones, actualizaciones y mantenimiento.
• Descriptores de despliegue comunes describen las capacidades de instalación y requerimientos de dependencia para un paquete de software
determinado. Usar descriptores comunes apuntando a productos individuales para ser integrados fácilmente en paquetes de software. Estos
descriptores ayudan a disminuir fallas que resultan de la incompatibilidad de las dependencias y reducen la complejidad del paquete, despliegue
y mantenimiento de una solución completa.
• Herramientas comunes reducen el costo y complejidad de construcción,
desplegando y manteniendo soluciones de software.
• Tecnlogías comunes de chequeo de dependencias para direccionar la configuración especifica y administrar cambios relacionados a las experiencias de los clientes.
7.3. DISEÑO DEL ESCENARIO Y DE LOS COMPONENTES
101
Usando esta tecnología, se puede planificar consistentemente un despliegue
de una solución IBM o de otro proveedor en menos tiempo con menos recursos.
A través de este escenario, se tratará acerca de la instalación de la solución autonómica y de las tecnologías de despliegue y se familiarizará con los
conceptos y formatos de las tecnologías. Se verá un ejemplo de cómo se puede
empaquetar una solución propia de software usando estas tecnologías y empezar a darse cuenta de los beneficios de un proceso de instalación predictivo.
Describiendo la solución anticipadamente se pueden reducir las dificultades de
los clientes.
7.3
Diseño del Escenario y de los Componentes
La solución de la instalación del AC Toolkit y el escenario de despliegue demuestra cómo puede usarse la instalación de la solución autonómica y las
tecnologías de despliegue para mejorar el proceso de instalación para una solución de software.
Los componentes de la solución del software se describen en formato XML.
Los componentes de una solución son referidos como unidades instalables
(IUs). Una solución podría estar constituída por solamente una IU o múltiples IUs. Los descriptores IU incluyen dependencias físicas (atributos de
hardware o programas de software), dependencias de costumbres, y acciones
de archivos a ser ejecutadas (crear directorios, copiar archivos, etc.).
El escenario usa ISMP para instalar la aplicación de servidor WebSphere
Application Server-Express y una página Web estática dentro del archivo del
sistema, en la ubicación que se especifique. El paquete de instalación está en
forma de una solución de instalación y el paquete del módulo de solución de
despliegue. El paquete contiene el archivo XML, descriptor del módulo de la
solución (PackageSM.xml) y los archivos que son para instalarse.
El archivo ejecutable de instalación contiene la instalación de la solución
y el tiempo de ejecución del despliegue. La instalación de la solución y el
tiempo de ejecución del despliegue deben ser incluídos en caso de que éste aún
no se encuentre en el sistema en tiempo de ejecución. En primer instancia,
la instalación lógica de las solución (en este caso, usando ISMP) no hace el
chequeo de la existencia de la instalación de la solución y el tiempo de ejecución
de despliegue.
102
CAPÍTULO 7. INSTALACIÓN DE LA SOLUCIÓN
Si éste no se encuentra allí, la instalación de la solución y el tiempo de
ejecución del despliegue serán cargados en el sistema. La lógica de la instalación indica la ubicación del archivo del paquete y lo pasa a la instalación
de la solución y el tiempo de ejecución del despliegue. La instalación de la
solución y tiempo de ejecución de despliegue lee el descriptor XML y chequea
las dependencias que se especifican en el descriptor.
La lógica de la instalación, para el propósito de esta demostración, imita
los resultados de dependencias en un panel de control, así se puede ver qué ha
sido chequeado. La demostración, lo que hace es contener una dependencia
fallida entonces, son posibles dependencias tanto fallidas como exitosas. En
este caso, la dependencia fallida es un chequeo del usuario y no un problema,
y continúa la instalación.
Después del chequeo de dependencias, la lógica de instalación lee el descriptor XML para encontrar qué directorios deben crearse y qué archivos serán
instalados. Entonces, los archivos son extraídos desde el paquete y copiados al
sistema de archivos en la ubicación que fue especificada. La lógica de la instalación entonces muestra una página de finalización, indicando que el proceso
de instalación ha terminado.
7.4
Instalación y Escenario de Despliegue para ISMP
e InstallAnywhere
Prerrequisitos: los siguientes ítems son requeridos:
R
PentiumII (Pentium III 500 Mhz o superior recomen1. Procesador Intel
dado).
2. 512MB de RAM (768 de RAM Recomendado).
3. Espacio asignado en unidad de disco:
• 228 MB de unidad de disco para instalación.
• Espacio de disco adicional para abastecer recursos.
• Espacio adicional requerido si se bajan imágenes electrónicas para
la instalación de esta tecnología.
7.4. INSTALACIÓN Y ESCENARIO DE DESPLIEGUE
103
Plataformas Soportadas: La solución de la instalación y el escenario de
despliegue soporta las siguientes plataformas:
• IBM AIX V5.2.
• Red Hat Enterprise Linux V2.1 (en Intel 32).
• SuSe Linux Enterprise Server (en Intel 32).
• Microsoft Windows 2000 Server.
• Microsoft Windows 2000 Advanced Server.
Instalar el escenario: para instalar el escenario, ejecutar los siguientes
pasos:
• Para Install Anywere: Doble-click al archivo ejecutable (SI_IAScenario_
win32.exe para Windows, SI_IAScenario_aix.bin para AIX, y SI_ IAScenario_ linux.bin para Linux) que es descargado del sitio Web del Autonomic Computing Toolkit. Se abre la ventana de Bienvenida.
• Para ISMP: Doble-click al archivo ejecutable (SI_ ISMPScenario_ win32.
exe para Windows, SI_ IAScenario_aix.bin para AIX, y SI_ ISMPScenario_ linux.bin para Linux) que es descargado del sitio Web del Autonomic Computing Toolkit. Se abre la ventana de Bienvenida.
• Click Next. Si el escenario aún está instalado en el sistema, aparece un
mensaje de error. Para corregir este problema, se ejecutan los siguientes
pasos:
— Cliquear Cancel en la ventana de mensaje de error.
— Cliquear Yes para salir.
— Ir a “Desinstalar el escenario” y ejecutar el procedimiento apropiado
para desinstalar el escenario.
— Ir al primer paso para empezar nuevamente el proceso de instalación.
• Aceptar los términos en el panel de Licencia y cliquear Next. El panel
de Localización muestra la ubicación por defecto. El panel de la lista de
características lista los detalles de la instalación. Cambiar la ubicación
de la instalación si la ubicación por defecto no es la apropiada.
104
CAPÍTULO 7. INSTALACIÓN DE LA SOLUCIÓN
• Cliquear Next para mostrar el panel de información resúmen.
• Cliquear Next para iniciar la instalación.
• Sobre el panel que aparece cuando se completa la instalación, cliquear
Finish.
Desinstalar el Escenario: para desinstalar el escenario, se deben ejecutar
los siguientes pasos tanto para plataformas Linux como para Windows.
• Ir a Start →Settings →Panel de Control.
• Doble Click sobre el ícono Agregar/Quitar programas.
• Para Install Anywhere: Seleccionar IBM Solution Install - Install Anywhere Scenario en la lista de aplicaciones y cliquear el botón Change/Remove para desinstalar el escenario.
• Para ISMP: Seleccionar IBM Solution Install - InstallShield MultiPlatform Scenario en la lista de aplicaciones y cliquear el botón Change/Remove para desinstalar el escenario.
Linux
Para desinstalar el escenario en un sistema donde se ejecuta Linux, ejecutar
los siguientes pasos:
• Desde una interfase de línea de comando, ir a <installLocation>_uninst.
• Doble clic en el archivo uninstall.jar. Aparece el panel de Bienvenida.
• Cliquear Next. Se despliega una panel y aparecen los detalles de la
desinstalación.
• Cliquear Next.
• Cliquear Finish cuando el proceso de desinstalación de haya completado.
7.5. EJECUTAR LA SOLUCIÓN Y ESCENARIO PARA IA
7.5
7.5.1
105
Ejecutar la Instalación de la Solución y Escenario de Despliegue para InstallAnywhere
Iniciar y Detener el Escenario
Durante la instalación del paquete de instalación de la solución y escenario de
despliegue, se crea un nuevo directorio para mantener los archivos del escenario usados para ejecutar la demostración. El directorio <installLocation>/
SolutionInstall/ IAScenario contiene el ejecutable usado para arrancar el escenario.
Para arrancar el escenario, ejecutar los siguientes pasos:
1. Doble click al instalador IA del escenario ubicado en el directorio (install_ ia.exe for Windows, install_ ia.bin for Linux and AIX) para iniciar
el escenario. Inicia el asistente de instalación, el cuál presenta el panel
de introducción para el escenario.
2. Cliquear Next para proceder al panel que indica que la instalación chequeará la presencia de la instalación de la solución y tiempo de ejecución
de despliegue.
3. Cliquear Next para ejecutar el chequeo e instalación de la instalación de
la solución y tiempo de ejecución de despliegue si éste no está presente.
El próximo panel pide al usuario que seleccione una instalación de la
solución y paquete de despliegue para instalar. El nombre del paquete
en el escenario es install_ win.zip para Windows, install_ linux.zip para
Linux, y install_ aix.zip para AIX. El paquete del escenario se encuentra
en el mismo directorio del instalador IA del escenario; <installLocation>
/SolutionInstall/ IAScenario.
4. Cliquear Next para mostrar el panel de ubicación de la instalación. El
panel muestra el directorio donde el paquete del escenario será instalado.
Ingresar el nombre del directorio si se quiere cambiar la ubicación por
defecto.
5. Cliquear Next para mostrar el panel de información del chequeador de
dependencias. Éste panel informa que el instalador apunta a consultar el
sistema por información que necesita para determinar si una instalación
puede completarse satisfactoriamente.
106
CAPÍTULO 7. INSTALACIÓN DE LA SOLUCIÓN
6. Cliquear Next para ejecutar el chequeador de dependencias. Los resultados del chequeador se muestran en el próximo panel. Una lista de las
dependencias que fueron chequeadas se listan y también si el chequeo
aprobó o falló.
7. Cliquear Next para seguir al próximo panel de información que indica
que la pérdida de dependencias ha sido detectada.
8. Cliquear Next para proceder al panel de resumen de la preinstalación.
9. Cliquear Next para invocar la instalación actual de los archivos del escenario desde paquete. Cuando se completa la instalación, el panel final
muestra indicaciones de los resultados de la instalación.
10. Cliquear Done para salir del escenario.
Para detener el escenario, cliquear Cancel en cualquier punto durante el
proceso de instalación.
7.5.2
Verificar los resultados del escenario
Después de que el panel de instalación ha sido cerrado, el software instalado
puede verificarse. Para mostrar la página Web estática, abrir el navegador
Web y seleccionar el archivo AC_SI.htm del directorio en la ubicación especificada durante la instalación. La instalación de la solución y la página Web
de despliegue se mostrará en el navegador.
Además se puede verificar la instalación iniciando WebSphere Application
Server - Express.
Se puede entonces emitir un arranque de servidor server1 desde el directorio
binario desde la línea de comando para arrancar WebSphere Application Server
- Express.
Se debe ver el mensaje “listo para e-business” indicando que WebSphere
Application Server - Express ha iniciado. Para detener el WebSphere Application Server - Express server, emitir la detención del servidor server1 desde
la línea de comando.
7.5. EJECUTAR LA SOLUCIÓN Y ESCENARIO PARA IA
7.5.3
107
Personalizar el Escenario
El paquete del escenario incluye dos partes: el instalador InstallAnywhere
(install_ia.exe para Windows y el install_ia_linux.bin para Linux) y el paquete de instalación (install_win.zip para Windows y el install_linux.zip para
Linux).
Para hacer cambios al escenario, se deben cambiar los paquetes de instalación. El instalador siempre permanece igual, entonces al descargar nunca
cambia. Cuando se hacen cambios al escenario, arrancar con un simple cambio. Por ejemplo, usar el editor para cambiar la cantidad de memoria requerida
para ejecutar la instalación. Cambiarlo a valores superiores al que existe en
la máquina que está siendo usada.
Cuando se reemplaza el archivo packagedSM.xml en la instalación del archivo zip, reiniciar el escenario. La instalación no será satisfactoria porque
el chequeo de capacidad (memoria) no será satisfactorio. Otro simple ejemplo podría ser cambio de las dependencias (chequear por diferentes requerimientos de memorias o espacios en discos). El hacer esto, edita el archivo
packagedSM.xml en la instalación del archivo zip.
Igualmente, pueden hacerce cambios más significativos. Se pueden agregar
o borrar archivos desde el paquete de instalación. Estos cambios requieren edición de archivos packagedSM.xml desde el archivo zip de instalación y agregar
o remover el correspondiente archivo desde el archivo zip de instalación.
7.5.4
Usar el Editor SMD
El Editor SMD provee una gráfica, con una forma de trabajo orientada a
objetos con un archivo packagedSM.xml. Este provee de actualizaciones y
crea capacidades. Se instala como un plug-in en Eclipse o IBM WebSphere
Studio Workbench. El Editor SMD sigue la sintaxis de un módulo de solución
y IU.
Se pueden agregar o quitar IUs, chequeos, y archivos y directorios desde el
archivo XML. Se pueden cambiar valores usados en el chequeo para comparar
contra valores diferentes (por ejemplo, para chequear por más o menos espacio
en disco). Además se puede usar el editor para crear un nuevo archivo XML.
108
CAPÍTULO 7. INSTALACIÓN DE LA SOLUCIÓN
Depurar el Escenario
Si algunos resultados no son como los esperados, chequear los logs que aparecen
en el directorio especificado en el entorno variable TEMP (o directorio de
almacenamiento temporal por defecto).
Además poner atención a los mensajes emitidos sobre la pantalla durante
el proceso de instalación. Si se ha cambiado algo en el packagedSM.xml o en
el archivo zip de instalación, examinarlos cuidadosamente para asegurar que
contienen exactamente lo que se desea.
Hay también una manera de rastear la actividad dentro de la instalación
de la solución y tiempo de ejecución de despliegue.
7.6
7.6.1
Ejecutar la Instalación de la Solución y Escenario de Despliegue para ISMP
Iniciar y Detener el Escenario
Durante la instalación de la solución y paquete del escenario de despliegue, un
nuevo directorio se crea para mantener los archivos del escenario usados para
la demostración. El directorio: <installLocation>/ SolutionInstall/ ISMPScenario contiene el ejecutable usado para iniciar el escenario.
Para iniciar el escenario, ejecutar los siguientes pasos:
1. Doble click en el instalador ISMP del escenario ubicado en el directorio <installLocation>/ SolutionInstall/ ISMPScenario (install_ismp.exe
for Windows, install_ismp.bin for Linux and AIX) para comenzar el escenario. Se inicia el asistente de instalación, el cual instala la instalación
de la solución y tiempo de ejecución de despliegue para usarse con el
escenario.
2. Cliquear OK para aceptar la instalación del tiempo de ejecución. Aparece el panel de bienvenida indicando que el asistente del InstallShield
instalará el IBM Solution Installation y Deployment Demo-ISMP en la
PC.
3. Cliquear Next para continuar. El próximo panel solicita la ubicación y
7.6. EJECUTAR LA SOLUCIÓN Y ESCENARIO PARA ISMP
109
el archivo que representa al paquete del escenario a instalar. El nombre del paquete en el escenario es: install_win.zip para Windows, install_linux.zip para Linix, e install_aix.zip para AIX. El paquete del
escenario se ubica en el mismo directorio que el instalador ISMP del
escenario; <installLocation>/SolutionInstall/ISMPScenario.
4. Cliquear Next para mostrar el panel de características describiendo lo
que se instalará. Asegurarse de que la caja de verificación está seleccionada en SI AC Demo Feature.
5. Cliquear Next para continuar. El panel siguiente solicita el directorio
donde el paquete del escenario se instalará. Ingresar el nombre del directorio si se desea cambiar la ubicación por defecto.
6. Cliquear Next para activar la instalación del escenario del paquete. Se
presenta un panel de estado que indica qué chequeador de dependencia
es referente a la ejecución del paquete del escenario.
7. Cliquear OK para iniciar el chequeo de dependencias. Los resultados del
chequeador de dependencia se muestran en el próximo panel. Una lista
de las dependencias que fueron chequeadas son listadas y también según
si aprueba o falla el chequeo.
8. Cliquear Next para seguiral panel de resumen de preistalación.
9. Cliquear Finish para salir del escenario.
Para detener el escenario, cliquear Cancel en cualquier punto durante el
proceso de instalación.
7.6.2
Verificar los Resultados del Escenario
Después de que el panel de instalación ha sido cerrado, el software instalado
puede ser verificarse. Para mostrar la página Web estática, abrir el navegador
Web y seleccionar el archivo AC_SI.htm desde el directorio en la ubicación
especificada durante la instalación. La instalación de la solución y la página
Web de despliegue se mostrará en el navegador.
Además se puede verificar la instalación iniciando el WebSphere Application Server - Express.
110
CAPÍTULO 7. INSTALACIÓN DE LA SOLUCIÓN
Se puede entonces emitir startserver server1 desde el directorio de archivos desde una línea de comando para iniciar WebSphere Application Server Express. Se verá el mensaje ”ready for e-business) indicando que Web Sphere
Application Server - Express se ha iniciado. Para detener el WebSphere Application Server - Express, emitir stopserver server1 desde la línea de comando.
7.6.3
Personalizar el Escenario
El paquete del escenario incluye dos partes: el instalador ISMP (install_ismp.
exe para Windows e install_ismp.bin para Linux y AIX) y el paquete de
instalación (install_win.zip para Windows e install_linux.zip para Linux, e
install_aix.zip para AIX).
Para hacer cambios al escenario, se deben cambiar los paquetes de instalación. El instalador siempre permanece igual, entonces al descargar nunca
cambia. Cuando se hacen cambios al escenario, arrancar con un simple cambio. Por ejemplo, usar el editor para cambiar la cantidad de memoria requerida
para ejecutar la instalación. Cambiarlo a valores superiores al que existe en
la máquina que está siendo usada.
Cuando se reemplaza el archivo packagedSM.xml en la instalación del archivo zip, reiniciar el escenario. La instalación no será satisfactoria porque
el chequeo de capacidad (memoria) no será satisfactorio. Otro simple ejemplo podría ser cambio de las dependencias (chequear por diferentes requerimientos de memorias o espacios en discos). El hacer esto, edita el archivo
packagedSM.xml en la instalación del archivo zip.
Igualmente, pueden hacerce cambios más significativos. Se pueden agregar
o borrar archivos desde el paquete de instalación. Estos cambios requieren edición de archivos packagedSM.xml desde el archivo zip de instalacion y agregar
o remover el correspondiente archivo desde el archivo zip de instalación.
Capítulo 8
Ejemplos con Tecnologías A-C
8.1
DB2 Universal database
(DB2 UDB)DB2 Universal Database, es una base de datos universal. Es
completamente escalable, veloz y confiable. Corre en modo nativo en casi todas
111
112
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
las plataformas, como Windows NT, Sun Solaris, HP-UX, AIX, y OS/2 [16].
• Características y funciones:
— DB2 UDB es el producto principal de la estrategia de Data Management de IBM.
— DB2 UDB es un sistema para administración de bases de datos relacionales (RDBMS) multiplataforma, especialmente diseñada para
ambientes distribuidos, permitiendo que los usuarios locales compartan información con los recursos centrales.
• Integridad:
DB2 UDB incluye características de integridad, asegurando la protección
de los datos aún en caso de que los sistemas sufran un colapso; y de seguridad,
permitiendo realizar respaldos en línea con distintos grados de granularidad,
sin que esto afecte la disponibilidad de acceso a los datos por parte de los
usuarios.
• Múltiples usos:
Provee la capacidad de hacer frente a múltiples necesidades, desde procesamiento transaccional de misión crítica (OLTP), hasta análisis exhaustivo de
los datos para el soporte a la toma de decisiones (OLAP).
• Escalabilidad:
Sus características distintivas de escalabilidad le permiten almacenar información en un amplio rango de equipos, desde una PC portátil hasta un
complejo ambiente de mainframes procesando en paralelo.
• Web enabled para e-business:
Incluye tecnología basada en Web que permite generar aplicaciones en las
Intranets y responder a las oportunidades de negocios disponibles en Internet.
Además, DB2 UDB provee soporte a Java.En la figura 8.1 de la pág.113 se
grafica el almacenamiento de documentos XML mediante DB2.
8.1. DB2 UNIVERSAL DATABASE
Figura 8.1: Almacenamiento de Documentos XML en DB2.
113
114
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
• Facilidad de instalación y uso:
La primera versión de DB2 para NT fue reconocida en el mercado como
una base de datos muy poderosa, pero difícil de instalar y usar. En esta
versión (DB2 UDB), IBM agregó muchas herramientas gráficas para facilitar
el uso tanto de usuarios, como administradores y desarrolladores. Incluye guías
para operaciones como instalación, configuración de performance, setup, etc.
Además, se agregaron herramientas para facilitar las tareas de integración con
otras bases de datos, tecnologías de networking y desarrollo de aplicaciones [7].
• Universalidad:
DB2 UDB es la única base de datos realmente universal, es multiplataforma
(16 plataformas - 10 no IBM), brinda soporte a un amplio rango de clientes,
soporta el acceso de los datos desde Internet y permite almacenar todo tipo
de datos incluyendo texto, audio, imágenes y video o cualquier otro definido
por el usuario.
8.1.1
Funciones Complementarias
• Conectividad.
Las herramientas de conectividad permiten acceder a los datos más allá de
donde ellos se encuentren. El slogan “cualquier cliente, a cualquier servidor,
en cualquier red” está completamente sustentado por la funcionalidad que sus
herramientas ofrecen. EL DB2 Connect permite acceder a los datos de DB2 en
mainframe o AS/400, desde Windows NT, Windows 95 / 98, OS/2 o cualquiera
de los Unix soportados. Además, el producto Datajoiner posibilita acceder de
forma única y transparente a los datos residentes en Oracle, Sybase, Informix,
Microsoft SQL Server, IMS, VSAM y otros.
• Data Warehousing.
DB2 UDB provee la infraestructura necesaria para soportar el proceso de
toma de decisiones en cualquier tamaño y tipo de organización. Está dirigido
a resolver la problemática a nivel departamental (Data Marts), ya que un
8.1. DB2 UNIVERSAL DATABASE
115
Figura 8.2: Esquema Conceptual de los Almacenes de Datos.
único producto provee la capacidad para acceder a datos en Oracle, Sybase,
Informix, Microsoft SQL Server, VSAM o IMS, además de la familia DB2.
Permite de forma totalmente gráfica acceder, transformar y distribuir los datos
automáticamente y sin programar una línea de código.En la figura 8.2 de la
pág. 115 se refleja el Esquema Conceptual de Almacenes de Datos en DB2 [16].
• Data Mining.
DB2 UDB posibilita el análisis orientado al descubrimiento de información escondida en los datos, realizando modelización predictiva, segmentación
de la base de datos, análisis de vínculos, o detección de desviaciones. Incluye las siguientes técnicas: clustering (segmentación), clasificación, predicción,
descubrimiento asociativo, descubrimiento secuencial de patrones y secuencias
temporales. Todas las técnicas mencionadas permiten realizar segmentación
de clientes, detección de fraudes, retención de clientes, ventas cruzadas, etc.
• Partición Simple sobre un Único Procesador.
Este entorno se basa en memoria y disco, conteniendo una única CPU.
Este ambiente ha sido denominado de diversas maneras : base de datos aislada
116
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
(standalone database), base de datos cliente/servidor (client/server database),
base de datos serial (serial database), sistema uniprocesador (uniprocessor
system), y entorno nodo simple/ no paralelo (single node/non-parallel).
La base de datos en este ambiente sirve para cubrir todas las necesidades
de un departamento o de una pequeña oficina de una empresa donde los datos y los recursos del sistema (incluyendo un único procesador o CPU) son
administrados por un único administrador de la base.
• Capacidad y Escalabilidad.
A este ambiente se le pueden agregar mas discos. Al tener uno o más
servidores de entrada-salida para mas de un disco permite que más de una
operación de entrada-salida ocurra al mismo tiempo.
Un sistema de procesador único esta limitado por la cantidad de espacio
en disco que pueda manejar dicho procesador. Sin embargo, como la carga de
trabajo aumenta, una sola CPU puede llegar a ser insuficiente para satisfacer
las peticiones solicitadas por los usuarios, aún sin importar cuántos discos y/o
memoria adicional hayan sido agregados [8].
Si se ha alcanzado la máxima capacidad o escalabilidad, se podría considerar cambiarse a un sistema de partición única con múltiples procesadores. A
continuación se describe esta configuración.
— Partición Simple con Múltiples Procesadores
Este entorno se compone de varios procesadores de igual potencia dentro
de la misma máquina, llamándose a este ambiente Sistema Simétrico Multiprocesador (symmetric multi-processor o SMP). Los recursos tales como espacio
de disco y memoria son compartidos. En esta máquina se encuentran más
discos y memoria en comparación a una base de datos de partición simple, en
el ambiente de procesador único.
Este entorno es de fácil administración, debido a que todo esta ubicado en
una sola máquina y además los discos y memoria están compartidos.
Con varios procesadores disponibles, diferentes operaciones de la base de
datos pueden ser completadas significativamente más rápido que en bases de
datos asignadas a un solo procesador. DB2 también puede dividir el trabajo
8.2. TIVOLI MONITORING
117
de una consulta simple entre los procesadores disponibles para mejorar la
velocidad de procesamiento.
Otras operaciones de la base de datos, tales como el resguardo (backup)
y creación de índices sobre datos existentes pueden también aprovechar la
ventaja de trabajar con múltiples procesadores.
∗ Capacidad y Escalabilidad
En este entorno se pueden agregar más procesadores. Sin embargo, es
posible que los distintos procesadores traten de acceder al mismo dato en el
mismo tiempo, lo cual generará la aparición de limitaciones a medida que las
operaciones de se incrementen. Con discos y memoria compartidos, se puede
efectivamente compartir todos los datos de la base.
Una aplicación en un procesador puede estar accediendo un dato al mismo
tiempo que otra aplicación lo hace en otro procesador, causando así que la
segunda aplicación espere para acceder a ese dato.
Se puede incrementar la capacidad de entrada-salida de la partición de la
base de datos asociada a un procesador, así como también el número de discos.
También se pueden establecer servidores de entrada-salida para repartir las
solicitudes de entrada-salida. Al tener uno o mas servidores de entrada-salida
para cada disco permite que una o mas operaciones de entrada-salida tengan
lugar al mismo tiempo.
Si se ha alcanzado la máxima capacidad o escalabilidad, se puede considerar la idea de cambiar la base a un sistema de partición múltiple, descrito a
continuación.
8.2
8.2.1
Tivoli Monitoring
Administrador de Servicios Tívoli
Se usa el administrador de Servicios Tívoli para:
• Suministrar datos de la configuración inicial de los servicios Tívoli después de bajarlos a la máquina.
118
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
• Iniciar y detener los componentes del Software IBM Tivoli Monitoring
que se ejecuta como servicios de Windows NT.
También se puede hacer lo siguiente:
• Activar o desactivar el rastreo de logueos para un servicio Tivoli, si es
necesario.
• Editar variables para un servicio Tivoli, si es necesario.
• Cambiar componentes por defecto de la configuración del Java para IBM
Tivoli Monitoring que usa Java, si se desea.
8.2.2
Acciones del Menu
Las siguientes opciones aparecen entre las acciones del menú de los Manage
Tivoli Services:
• Start Service
Arranca un programa o servicio Tivoli seleccionado. Se debe configurar un
servicio Tivoli antes de iniciar el servicio.
• Stop Service
Detiene un servicio Tivoli seleccionado. Un servicio Tivoli debe estar en
ejecución antes de poder detenerlo.
• Status Icons:
Los íconos ubicados en el extremo izquierdo del panel principal del Manage
Tivoli Service muestra visualmente los estados de los servicios instalados, como
ser:
El componente está configurado y listo para iniciar.
8.2. TIVOLI MONITORING
119
El componente está desconfigurado. Se debe completar la configuración
para poder iniciar el componente.
EL componente está en ejecución.
• Recycle Service (Servicio Reprocesado)
Esta acción detiene, y luego reinicia un servicio Tivoli
• Change Startup
Esta acción se usa para ajustar la configuración por defecto para un servicio
Tivoli, si fuera necesario.
Esta configuración es mostrada en la columna de carga de inicio del panel
principal del Manage Tivoli Service.
• Change Startup Parms
Esta acción se usa para ajustar los parámetros por defecto de la columna
de carga de inicio para un servicio Tivoli seleccionado, si fuera necesario.
IBM Customer Support puede guiar en cuanto al uso de esta acción si el
sistema tiene un requerimiento especial.
— Set Default For All Agents
Si está disponible, esta acción activa el panel Configuration Default para
un programa o servicio Tivoli seleccionado.
Los valores especificados en este panel se usan como valores de configuración por defecto para un programa o servicio Tivoli que esté instalado en la
máquina.
Dependiendo de los componentes IBM Tivoli Monitoring que se instalan,
este menú de selección puede estar no disponible.
• Configure Using Defaults
120
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
Esta acción comienza el proceso de configuración para un servicio desconfigurado. Cuando comienza la configuración, se debería incitar a cargar la
información de configuración.
— Unconfigure:
Esta acción quita la entrada del servicio seleccionado desde el registro de Windows NT. Los servicios son solamente definidos a través
del registro de Windows NT, así es que esta acción deshabilita el
servicio.
Al desconfigurar un servicio previamente configurado, la configuración es eliminada.
— Configure Advanced
Si el servicio seleccionado aún no está configurado, esta acción permitirá acceder al panel de configuración avanzada del servicio Tivoli
que lo requiera. Si el servicio seleccionado ya está configurado, se
debe elegir: Actions > Reconfigure.
Usar la acción de Configuración Avanzada cuando se actualiza a
partir de una versión anterior.
Esta opción del menú no está disponible con todos los componentes
IBM Tivoli Montoring.
• Create Instance
Esta acción permite crear y configurar una instancia del programa o servicio seleccionado para monitorear un subsistema especificado. Las Instancias
son creadas usando Templete.
— Template
El nombre Template puede aparecer en la columna Task/Subsystem del
panel principal del Manage Tivoli Service.
Un Template es usado por Manage Tivoli Service como un maestro, o
cortador de cookies, a partir de la cual un instancia del servicio es creado.
Un template se usa solamente para la configuración y no puede ser iniciado
o cambiado de ninguna otra manera. Solamente instancias de servicios Tivoli
o programas configurados desde el template pueden ser iniciados o modificados
de otras maneras.
8.2. TIVOLI MONITORING
121
Se puede remover un servicio Tivoli o programa configurado desde un template seleccionando: Advanced>Remove Instance
— Inactive
El nombre Inactive puede aparecer en la columna Task/Subsystem del
panel principal del Manage Tivoli Services.
Manage Tivoli Services usa un ”inactive” solo para configuración y no
puede iniciarse o cambiarse en ningun otro camino. Solo se puede arrancar o
modificar instancias de los servicios Tivoli seleccionados o programas configurados desde el ”inactive” en otros caminos.
Se puede quitar el servicio Tivoli seleccionado o programa configurado a
partir de una ”inactive” seleccionando:
Advanced —>Remove Instance
Reconfigure
Esta accion configura un servicio que había sido configurado previamente.
Si el servicio está siendo ejecutado, éste es detenido primero. Entonces el
panel de configuración se muestra para la inspeccion y edición.
Cuando se reconfigura un servicio, la configuración previa se guarda
Actions, Advanced menu
Las siguientes acciones están disponibles en el menu Action>Advanced del
Manage Tivoli Service.
Configure Advanced
Si el servicio seleccionado no está configurado, esta acción permitirá acceder al panel de configuración avanzada de un servicio Tivoli que requiere
configuración avanzada. Si el servicio seleccionado ya está configurado, se
debe elegir: Action>Reconfigure.
Usar la acción de la configuración avanzada cuando se actualiza desde una
versión previa.
Esta opción del menú no está disponible con todos los componentes del
IBM Tivoli Monitoring.
122
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
Unconfigure
Esta acción remueve la entrada del servicio seleccionado desde el registro
de Windows NT. Estos servicios están exclusivamente definidos para Windows
NT a traves del registro, por lo tanto esta acción deshabilita el servicio.
Al desconfigurar un servicio, se borra la configuración que se haya hecho
previamente.
Remove Instance
Esta acción quita una instancia de un servicio o programa Tivoli. El servicio se crea usando la acción: Create Instance.
Edit Trace Parms
Esta acción permite activar o desactivar el transcurso de ejecución de un
servicio seleccionado.
Los logs se escriben en el directorio \Logs.
La ayuda al Cliente de IBM puede instruir a cerca del ajuste de esos
parámetros si se requiere información adicional para resolver el problema.
View Trace Log
Esta acción permite ver el log trazado del error de un servicio, si ha sido
creado un trace log.
Si no ha sido creado un trace log, seleccionando esta accion muestra un
mensaje similar al siguiente:
Trace Log File: path\filename.log not found.
Edit Variables
Esta acción permite acceder a las variables IBM Tivoli Monitoring para
un servicio seleccionado. Las variables que se proporcionen aquí se escriben
en el registro de Windows NT.
IBM Customer Support muestra cómo ajustar estas variables si el sistema
tiene requerimientos especiales.
Edit ENV File
8.2. TIVOLI MONITORING
123
Esta acción permite acceder al archivo de configuración de servicio Tivoli
seleccionado.
IBM Customer Support puede guiar a través de un proceso ajuste de este
archivo si el sistema tiene requerimientos especiales.
Set Network Adapter
Si hay instalados múltiples tarjetas de red en la máquina, se debe usar esta
acción para configurar una variables del sistema para identificar la tarjeta de
red para programar.
Add application support to the Tivoli Enterprise Monitoring Server
El Tivoli Enterprise Monitoring Server es un componente de IBM Monitoring.
Si no se agrega un soporte de aplicación del Tivoli Enterprise Monitoring Server durante la instalación, se puede hacer posteriormente usando esta
acción.
Si está disponible, esta acción arranca el panel de Add application support
to the TEMS. Se puede seleccionar los componentes cuyos datos se quieren
agregar al soporte de aplicación en los cuadros del Tivoli Enterprise Monitoring
Server. Si no se está seguro de lo que se va a seleccionar, seleccionar todo.
Caution: Durante la instalación, si se ha iniciado el agregado de soporte
de aplicación al Server Monitoring Enterprise remoto al final, hay q asegurarse
de que el Hub Tivoli Enterprise Monitoring Server está configurado y ejecutando antes de proceder con ésta operación sobre el Remote Tivoli Enterprise
Monitoring Server, si no, el proceso puede colgarse (fallar).
Ciertos productos requieren que el Tivoli Enterprise Monitoring Server sea
reiniciado después de agregar el soporte de aplicación. Reiniciar siempre el
Tivoli Enterprise Monitoring Server después del agregado de un soporte de
aplicación, si un mensaje emergente así lo sugiere.
Dependiendo de los componentes del IBM Tivoli Monitoring que se hayan
instalado, éste menú de selección puede ser que no esté disponible.
Browse Settings
Muestra la información de configuración para un programa seleccionado.
Se puede usar la configuración del navegador para fines de depuración.
124
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
About Services
Esta acción muestra información del nivel de construcción para un programa seleccionado. Puede usarse con fines de depuración.
Configure Java App
Esta acción se usa para ajustar los parámetros en tiempo de ejecución del
programa Java que fue ejecutado, si es necesario. Esto efectuará la ejecución
del programa Java.
Java Version
Esta acción se usa para ajustar la configuración por defecto de la version
del Java para un componente de IBM Tivoli Monitoring que usa Java, si es
necesario.
Se puede editar la ubicación de las librerías asignadas para una versión
Java.
Exit - Cierra Manage Tivoli Services.
Options menu
En el menú Options del Manage Tivoli Services aparecen las siguientes
opciones:
User Options
Permite ajustar las características visuales, tales como: tamaño de la fuente
y color, de la información que aparece en el Manage Tivoli Services.
Enable Tivoli Enterprise Monitoring Server Mode
La version del Manage Tivoli Monitoring está pre-configurada en el modo
apropiado para los componentes del IBM Tivoli Monitoring instalado.
Tivoli Enterprise Monitoring Server es un componente de IBM Tivoli Monitoring.
View menu
Las siguientes alternativas aparecen en el menú del Manage Tivoli SErvice.
Se debe clickear sobre algunos de ellos para ver la información sobre un
tópico.
8.2. TIVOLI MONITORING
125
Toolbar
Los siguientes íconos copiados de la barra de herramientas Tivoli Services
Toolbar son frecuentemente usados:
Start Service
Stop Service
Recycle Service
Change Startup
Browse Settings
Help Topics
You can choose display the toolbar icons by selecting or de-selecting the
Toolbar item from the View menu.
Se pueden elegir ver las los iconos de la barra de herramientas seleccionando
o des-seleccionando el item Toolbar desde el menú View.
Status Bar
La barra de estado (Status Bar) muestra mensajes informativos. Se ubica
en el extremo inferior del panel principal del Manage Tivoli Service.
Se puede seleccionar o des.seleccionar el item: Status Bar desde el menú
View.
Refresh - Actualiza el panel principal del Manage Tivoli Services.
Sorting
Se puede clasificar los contenidos de cualquier columna del panel principal
del Tivoli Services cliqueando en el encabezamiento de la columna.
Se debe seleccionar View>Refresh para volver a la pantalla por defecto.
Windows menu
Los siguientes opciones aparecen en el menú del Manage Tivoli Service
Windows
Hay que cliquear una opción de abajo para ver información de un tópico.
126
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
Open Remote View
Si se tiene acceso y autoridad sobre Windows NT Administrator, una
máquina Windows NT remota con ésta version del Manage Tivoli Service
instalado, se peden ejecutar las siguientes acciones usando el Manage Tivoli
Service remotamente.
Start Service
Arranca un programa o servicio Tivoli seleccionado.
Se debe configurar un servicio Tivoli antes de poder arrancar el servicio.
Stop Service
Detiene un servicio Tivoli seleccionado
Un servicio Tivoli debe ejecutarse antes de poder detener el servicio.
Browse Settings
Muestra información de la configuración para un programa seleccionado.
Se puede usar la configuración del navegador para propósitos de depuración.
Si se experimenta un problema, e debe proveer esta información al IBM
CUstomer Support.
Close View
Cierra una vista remota abierta.
Next View
Muestra otra vista, si están abiertas más de una vista.
Local Computer - Es el default. Manage Tivoli Service es completamente
funcional en una computadora local.
Help menu
Las siguientes opciones aparecen en el menú Help del Manage Tivoli Service.
Se selecciona una de las opciones a continuación, para mostrar información
de ese tópico.
Help Topics
8.2. TIVOLI MONITORING
127
Muestra la información de ayuda online disponible para esta version de
Manage Tivoli Services.
About Manage Tivoli Services
Muestra información sobre ésta version del Manage Tivoli Services, se puede usar esta información para propositos de depuración.
Si se experimenta un problema, hay que proveer esta información al Soporte de Software de IBM.
Consejos:
Para usar Manage Tivoli Services:
Destacar un tema sobre la Gestión de Servicios de Tivoli en el panel principal y luego seleccionar la acción que se desea ejecutar.
Sorting
Se puede ordenar el contenido de cualquier columna de los Servicios de
Tivoli del panel principal haciendo clic en el encabezado de columna.
Seleccionar lo siguiente para volver a la pantalla por defecto:
View>Refresh
Multi-Selecting
El panel principal del Manage Tivoli Services soporta multiselección para
muchas acciones. Por ejemplo, la manera más rápida de detener todos los
servicios en funcionamiento es:
1- Mantener pulsada la tecla Shift y seleccionar del primer al ultimo item
listado (a continuación soltar la tecla Shift).
Todos los components están resaltados ahora.
2- Cliquear el ícono Stop.
Los servicios se detienen uno por uno.
Acciones Rápidas:
Doble click sobre: Para realizar la siguiente acción:
Un servicio no configurado Configurar usando valores predeterminados
128
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
Un servicio configurado Arrancar Servicio
Un servicio en ejecución Detener Servicio
Color Gris de los elementos del Menú:
Una tarea está de color gris o no disponible, por las siguientes razones:
. la tarea ya ha sido realizada. Por ejemplo, detener Servicio no está
disponible si el servicio está aún detenido.
. la tarea está fuera de secuencia. Inicio de servicios no está disponible
hasta que el servicio está configurado.
. la tarea no es válida para el elemento seleccionado. Por ejemplo las
mayoría de las tareas no están disponibles para los elementos cuyo Subsistema/Tarea son: Java, Template o Inactivo.
8.3
8.3.1
WebSphere
Introducción a WebSphere
• WebSphere es una plataforma de Software para e-business.
• IBM WebSphere es una plataforma de IBM para desarrollo y gestión de
sitios web y aplicaciones destinadas al comercio electrónico.
8.3. WEBSPHERE
129
Figura 8.3: Plataforma de WebSphere.
• WebSphere posee una amplia gama de servidores y aplicaciones para
proporcionar todo tipo de capacidades de negocio y ayuda al desarrollo
de las aplicaciones.
• La Plataforma de Software WebSphere está compuesta por un conjunto
de herramientas de e-business integradas y basadas en estándares abiertos de mercado.
• WebSphere es ideal para todas las fases de un e-business, comenzando
desde pequeños sitios Web a mega sitios.
La figura 8.3 de la pág. 129 representa la plataforma virtual de WebSphere.
Aumentando el Desempeño del e-business
Distribuye carga de trabajo entre los servidores sin interrupción del servicio
a los visitantes del sitio de la Web.
130
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
Provee servicios a cliente de calidad superior y mejor desempeño del sitio
Web.
El extraordinario crecimiento de la web ha hecho que una infraestructura
fiable, disponible y escalable sea más necesaria que nunca. Una interrupción,
aunque sea breve, o reducción de servicio puede causar que los clientes web,
cada vez más sofisticados y exigentes, se dirijan inmediatamente a la competencia.
Cuando clientes frustrados pueden abandonar un sitio web con un click,
las nociones tradicionales sobre lealtad de clientes se ven severamente desafiadas. Por eso, los propietarios de contenido necesitan una infraestructura en la
web que sea capaz de proporcionar excelentes tiempos de respuesta de forma
consistente, tratar flash crowds (multitud de visitas rápidas) y reconocer los
clientes leales con tratamiento preferente.
La plataforma de software WebSphere proporciona una completa gama de
habilidades que permiten a los clientes la entrega de altos niveles de servicio a
todos los visitantes del sitio en la web. Administra cargas pico en los servidores
web, mantiene la disponibilidad del sitio en la web, y reconoce contenido
de solicitudes de la web para calidad-de-servicio mejor. También permite la
diferenciación de niveles de servicio con base en el tipo de cliente.
Bases y Herramientas para Construir, Diseminar y Hacer Crecer su
e-business
e-business es parte integral del éxito del negocio principal de hoy. Actualmente las empresas necesitan respuesta de base de alta calidad para rápidamente
construir e implementar aplicaciones para e-business on demand de alto desempeño.
El ambiente de TI del e-business debe ser construido sobre una sólida Base
y con Herramientas que sean integradas y que tengan desempeño confiable.
Los tiempos de detención del sistema y los problemas de desempeño crean un
riesgo real para el negocio. Este riesgo se multiplica debido a la diversidad de
los ambientes de TI.
Corporaciones de mayor porte pueden tener amplia diversidad dentro de
su propia empresa. Corporaciones de menor porte encontrarán diversidad al
dividirse más allá de las fronteras de su empresa hacia el resto de su cadena
8.3. WEBSPHERE
131
de valor. El software IBM WebSphere ayuda a reducir este riesgo del negocio.
8.3.2
La Integración en el e-business on demand
En el núcleo del e-business on demand se encuentra la integración de negocios,
que comprende lo siguiente:
• Transformarse en un negocio on demand requiere construir una infraestructura dinámica basada en procesos de negocio críticos estrechamente
integrados y racionalizados.
• Procesos eficientemente conectados en toda la compañía y con las de
socios comerciales claves, proveedores y clientes.
• Procesos de negocio integrados que proporcionan flexibilidad, la capacidad de responder inmediatamente a casi todas las demandas de clientes,
oportunidad de mercado o amenaza externa.
Para obtener esta flexibilidad, la clave es una estrategia de integración bien
planificada, basada en una plataforma robusta. Una plataforma para:
• Automatizar y administrar procesos de la cadena de valor.
• Cortar drásticamente tiempos de ciclo y costos.
• Dar más velocidad al time-to-market.
• Aumentar la agilidad del negocio frente a las presiones competitivas.
Las compañías que evolucionan hacia el e-business on demand hacen del
WebSphere Business Integration el principio básico de su estrategia de integración. WebSphere proporciona una sólida base de integración con las capacidades completas de e-business que se necesitan en una era on demand.
Estas cinco capacidades incluyen:
• Modelar : diseñar, simular y planificar procesos de negocio.
• Integrar: vincular personas, procesos, aplicaciones, sistemas y datos.
132
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
• Conectar : expandir procesos a sus clientes y socios.
• Monitorear: controlar y rastrear procesos de negocio.
• Administrar: revisar, analizar y mejorar procesos y desempeño.
8.3.3
Plataforma de Software
La complejidad creciente de los aplicativos de e-business crea muchos desafíos.
Es necesario conseguir que los aplicativos le permitan comercializar rápidamente, con contenido relevante y personalizado [17].
Los aplicativos deben ser escalables, fiables y se deben integrar completamente con los sistemas back-end para proteger las inversiones existentes. El
equipo debe poseer las más actualizadas habilidades de programación para
acompañar el ciclo de vida del e-business.
Se necesita una plataforma completa, escalable y flexible que proporcione
soporte a la construcción y diseminación de aplicativos de e-business. Las
soluciones de software WebSphere ofrecen las herramientas necesarias para
alcanzar los objetivos de e-business.
Al proporcionar un banco de trabajo abierto que integre y simplifique
diferentes tareas, roles y herramientas, el software WebSphere ayuda a que el
equipo desarrolle, entregue y administre los aplicativos de e-business [11].
El ambiente de desarrollo del software WebSphere:
• Da soporte al desarrollo y cambios rápidos de nuevos aplicativos utilizando un paradigma de desarrollo basado en reglas, permitiendo que
todos utilicen el mismo ambiente y reduciendo costes de entrenamiento.
• Proporciona código pre-construido, pre-testeado.
• Proporciona herramientas especializadas para página Web y desarrollo
de módulos migrables.
Adicionalmente, servicios basados en estándares Web permiten mezclar y
combinar componentes funcionales de diferentes orígenes de tal forma que se
puede proveer nuevos procesos y servicios al mercado rápida y eficientemente.
8.3. WEBSPHERE
133
La capacidad de un portal de negocios tiene importancia crítica para permitir que las personas interactúen y transaccionen de forma personalizada con
diversos recursos de negocios. Empieza dejando a la medida los ambientes
de usuarios para sus necesidades específicas, integrándolo entonces con otros
usuarios para permitir colaboración en tiempo real, y con los diversos ambientes de TI.
Todo esto permite que las personas trabajen en conjunto de forma más
productiva mientras actúan sobre la información que necesitan. La capacidad
del portal de negocios es proporcionada por la familia WebSphere Portal y la
familia WebSphere Commerce es un conjunto de soluciones eficaces del lado de
ventas para tratar los desafíos encontrados en ambientes de clientes y socios
comerciales [2] [12].
Al expandir el ambiente de usuario para permitir que las personas accedan
a la información y actúen en cualquier lugar, en cualquier momento, usando
su elección de dispositivos y mecanismos de interacción significa acceso on
demand y las familias WebSphere Everyplace y WebSphere Voice, son software
para expandir aplicaciones de e-business a dispositivos móviles, permitiendo
interacción de voz natural con aplicaciones y datos.
WebSphere for Commerce - Soluciones B2B
Hoy, el e-commerce consiste en realizar negocios con sus clientes, proveedores
y contratistas comerciales sin encontrar dificultades de tiempo, limitaciones
organizacionales o fronteras geográficas.
Con el software With WebSphere Commerce, se establecen relaciones más
estrechas, más productivas con sus clientes y contratistas comerciales en todos
los puntos de contacto. Impulsa los procesos existentes reduzciendo sus costes.
Facilita que sus clientes y contratistas comerciales hagan negocios hoy y que
continúen mañana.
Con el IBM WebSphere Commerce Business Edition, se puede optimizar
procesos de negocio a través de la automatización e integración con sus aplicativos para los negocios principales, consigue el mayor impacto por el menor
coste y el ROI más rápido, fortalece las relaciones de negocios con clientes y
contratistas, y disemina un e-business verdaderamente global.
134
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
WebSphere for Commerce - Soluciones B2C
El software WebSphere Commerce le permite ir a la línea de las ventas online
a los consumidores.
Crea campañas de marketing dinámicas, fija como objetivo diferentes segmentos de mercado, elabora promociones de producto personalizadas, y mejora el servicio a clientes. Esta solución ayuda a crear rápidamente y mantener
eficientemente un sitio interactivo, de alto volumen. Un sitio que atraiga consumidores y los haga volver, obteniendo rápido retorno de inversión.
La solución WebSphere Commerce proporciona:
• Personalización sofisticada del B2B para ayudar a administrar las relaciones de negocio.
• Tecnología de ventas asistidas para conducir a los clientes y contratistas
a través de la agrupación de requisitos y del proceso de selección del
producto.
• Herramientas de cooperación online y de formación de equipo virtual
para mejorar la eficacia de contratistas comerciales, canal y clientes.
• Administración integrada de contrato para soportar contratos complejos
y políticas de negocio.
• Administración de pedidos anticipado resultando en capacidades de optimización de operaciones.
• Capacidades multi-culturales para llegar a clientes globales.
• Capacidades avanzadas de inteligencia de negocios para decisiones fundamentas del e-business.
WebSphere for Commerce-Soluciones de Portal
La integración del WebSphere Commerce y WebSphere Portal permite que las
empresas se dirijan a múltiples sectores con necesidades de personalización positivas de soluciones de comercio tanto para las áreas B2B o B2C. Actualmente,
muchas empresas crean sitios separados para cada división, lo que demanda
mucho tiempo y cuesta caro.
8.3. WEBSPHERE
135
El abordaje racionalizado proporciona rápido retorno de inversión al eliminar la necesidad de que la empresa mantenga múltiples sitios. Las empresas
también aumentan la eficiencia de interacciones con clientes y contratistas, lo
que mejora la retención del cliente.
Los productos IBM WebSphere Commerce y WebSphere Portal proporcionan un único punto de interacción con información dinámica y personalizada,
aplicativos, procesos y personas, que son esenciales para construir portales
exitosos para el B2B y B2C.
Con el portal habilitado para el comercio, se puede crear un ambiente
personalizado de comercio provechoso para ambos ambientes, B2B y B2C:
• Ambientes B2B: organizar eficientemente información online, servicios
y aplicativos para contratistas de negocio y proveedores a lo largo de
múltiples divisiones en un portal.
• Ambientes B2C o de ventas al por menor: obtener ventas cruzadas e
impulsar los beneficios, mediante la oferta de acceso a productos, información y servicios desde la Web y de dispositivos inalámbricos, así como
acceso consolidado a catálogos múltiples.
Con un portal de e-commerce integrado, se les puede ofrecer a los clientes, contratistas y proveedores acceso 24x7 a los aplicativos online - rápida y
fácilmente.
WebSphere for Commerce-Soluciones Digital Media
Empresas de medios con volúmenes crecientes de activos digitales -fotos, vídeo
clips, archivos en audio, ilustraciones e imágenes animadas- enfrentan nuevas
exigencias reguladoras y el desafío de colocar esos activos disponibles online.
El software IBM WebSphere permite administrar estos activos digitales más
eficazmente, alcanzando clientes en todos el mundo a través de la Web.
IBM WebSphere Commerce para Medios Digitales permite almacenar, buscar, ver, administrar, colaborar, comprar, vender y hacer download de activos
digitales, alcanzando clientes en todo el mundo por la Web. Esta nueva oferta
de servicio de e-commerce combina el software WebSphere Commerce aprobado por la industria con las capacidades del IBM Content Manager, reforzado
por la tecnología Java.
136
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
WebSphere Commerce para Medios Digitales permite enriquecer la experiencia del consumidor y la interfase de compra B2B, creando nuevas relaciones
con clientes al mismo tiempo en que fortalece las existentes y ayudando a generar y aumentar ganancias así como sus márgenes de beneficios.
WebSphere ofrece un amplio portafolio de soluciones clasificadas en tres
áreas críticas:
• Infraestructura y herramientas de Desarrollo (Fundation & Tools):
— Application server.
— WebSphere studio:
∗ IBM WebSphere Studio Site Developer.
∗ IBM WebSphere Studio Application Developer.
∗ IBM WebSphere Studio Application Developer Integration Edition.
∗ IBM WebSphere Studio Enterprise Developer.
∗ IBM WebSphere Studio Homepage Builder.
— Host Access.
• Alcance y experiencia con el usuario (Business Portals):
— WebSphere Portal.
— WebSphere Everyplace.
— WebSphere Commerce.
• Integración de negocio (Business Integration):
— WebSphere Business Integrator.
— WebSphere MQ Integrator.
8.3.4
Arquitecturas de Tres Niveles
WebSphere Application Server proporciona la capa de la lógica de aplicación
en una arquitectura de tres niveles, lo que permite a los componentes de cliente
interactuar con los recursos de datos y las aplicaciones heredadas.
8.3. WEBSPHERE
137
De manera colectiva, las arquitecturas de tres niveles son modelos de programación que permiten la distribución de la funcionalidad de la aplicación
entre tres sistemas independientes, normalmente:
• Componentes de cliente que se ejecutan en estaciones de trabajo locales
(nivel uno).
• Procesos que se ejecutan en servidores remotos (nivel dos).
• Una colección discreta de bases de datos, gestores de recursos y aplicaciones de sistema principal (nivel tres).
Primer nivel:
— La responsabilidad de la presentación y la interacción con el usuario
reside en los componentes del primer nivel. Estos componentes de
cliente permiten al usuario interactuar con los procesos del segundo
nivel de forma segura e intuitiva. WebSphere Application Server da
soporte a varios tipos de clientes.
— Los clientes no acceden directamente a los servicios del tercer nivel.
Por ejemplo, un componente de cliente proporciona un formulario
en el que el cliente solicita los productos.
— El componente de cliente entrega este pedido a los procesos del
segundo nivel, que comprueban las bases de datos del producto y
realizan las tareas necesarias para la facturación y el envío.
Segundo nivel (capa de la lógica de aplicación):
— Los procesos del segundo nivel se conocen normalmente como la
capa de la lógica de aplicación. Estos procesos gestionan la lógica
empresarial de la aplicación y pueden acceder a los servicios del
tercer nivel.
— La capa de la lógica de aplicación es donde se produce la mayor
parte del trabajo de los procesos.
— Varios componentes de cliente pueden acceder simultáneamente a
los procesos del segundo nivel, por lo que esta capa de la lógica de
aplicación debe gestionar sus propias transacciones.
138
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
— Si varios clientes intentan realizar un pedido del mismo artículo,
del que sólo queda uno, la capa de la lógica de aplicación debe
determinar quién tiene derecho a ese artículo, actualizar la base
de datos para reflejar la compra e informar a los otros clientes de
que el artículo ya no está disponible. Sin una capa de la lógica de
aplicación, los componentes de cliente acceden a la base de datos
del producto directamente.
— La base de datos es necesaria para gestionar sus propias conexiones,
normalmente bloqueando un registro que se está procesando. El
bloqueo se puede realizar simplemente cuando un artículo se coloca
en un carro de compra, para evitar que los demás clientes consideren
la posibilidad de compra.
— La separación del segundo y el tercer nivel reduce la carga en los
servicios del tercer nivel, puede mejorar el rendimiento general de
la red y permite una gestión de conexiones más elocuente.
Tercer nivel:
— Los servicios del tercer nivel están protegidos del acceso directo de
los componentes de cliente al residir en una red segura.
— La interacción debe producirse a través de los procesos del segundo
nivel.
Los tres niveles deben poder comunicarse entre ellos. Los protocolos abiertos estándar y las API expuestas simplifican esta comunicación. Los componentes de cliente se pueden escribir en cualquier lenguaje de programación
como, por ejemplo, Java o C++, y se puedan ejecutar en cualquier sistema
operativo, siempre que pueden comunicarse con la capa de la lógica de aplicación.
De la misma forma, las bases de datos del tercer nivel pueden tener cualquier diseño, siempre que la capa de la lógica de aplicación pueda consultarlas
y manipularlas. La clave de esta arquitectura es la capa de la lógica de aplicación.
8.3. WEBSPHERE
8.3.5
139
Familias del Producto
El ambiente operativo principal debe ser una base confiable que permita de forma segura, transacciones e implementaciones de servicios en la Web
de forma abierta. En otras palabras, debe ser una infraestructura abierta,
basada en servicios, como la proporcionada por la familia del WebSphere Application Server, un mecanismo de alto desempeño, extremadamente escalable
para aplicaciones de e-business dinámicos.
En el caso en que nuevas aplicaciones tengan que ser desarrolladas, estas
necesitan ser creadas de forma que capturen el conocimiento de negocio de
forma eficaz, y construidas para integrarse, de manera que se ajusten rápidamente al ambiente existente, y a impulsarlo. Esta capacidad de desarrollo de
aplicaciones es proporcionada por la familia WebSphere Studio.
Las inversiones existentes en sistemas y aplicaciones, tan dispares cuanto
puedan ser, deben ser utilizadas por el e-business para bajar costos y preservar
inversiones. Esta capacidad de modernización de la empresa es proporcionada
por herramientas especializadas de desarrollo de la familia WebSphere Studio
y a través de la familia WebSphere Host Integration, que es software destinado
a impulsar y extender los activos legados para nuevas soluciones de e-business.
El WebSphere Host Integration Solution puede llevar sus aplicativos preexistentes a la Web, ¡rápidamente! extiende los aplicativos de host a la Web
y proporciona software para la creación y diseminación de nuevos aplicativos para host de acceso a e-business, sin necesidad de cambios a los propios
140
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
aplicativos existentes.
Tanto si se necesita una simple entrega de página Web, darle un nuevo aspecto a un aplicativo preexistente, o crear soluciones Java sofisticadas, el IBM
WebSphere Host Integration Solution permite rápida y flexiblemente integrar
datos críticos de la empresa la Web.
El WebSphere Host Publisher proporciona la manera más rápida, más fácil
para implementar e-business mediante la ampliación del alcance de aplicativos
a los usuarios de browsers en la web y nuevos aplicativos WebSphere, sin alteraciones a aplicativos existentes. Amplio soporte a aplicativos preexistentes
y escalabilidad, seguridad, y características de disponibilidad, hacen del Host
Publisher la solución ideal para diseminaciones de nuevos e-business. Tanto
si su objetivo es coste menor o mayores ganancias a través de diseminaciones
Web-to-Host o a través del desarrollo de nuevos aplicativos para e-business.
Las características clave son:
• Proporciona integración Web con Terminal Virtual 3270, 5250(VT), Java
Database Connectivity (JDBC) y aplicativos Java host sin necesidad de
cambios al propio aplicativo existente.
• Permite la fácil consolidación de múltiples aplicativos en un aplicativo
compuesto único o página Web para presentación a usuarios de la Web.
• Se integra con la Edición Avanzada del WebSphere Application Server
e incluye el WebSphere Studio para proporcionar una solución completa
para la entrega de datos del host a usuarios de la Web y para nuevos
aplicativos WebSphere para e-business.
• Opera con el Websphere Transcoding Publisher para extender datos del
host a tecnologías penetrantes como los dispositivos SmartPhone y asistentes digitales personales.
• Proporciona una amplia gama de opciones de acceso al Host: HTML a
browsers de la Web, XML Gateway para aplicativos Java, y Host Publisher Integration Objects reutilizables para aplicativos de Java applets
aplicativos.
• Ayuda a impulsar la inversión en Host Publisher utilizando objetos de
integración basados en estándares abiertos de la industria que se pueden
reutilizar en nuevos aplicativos de e-business, reduciendo el coste y los
riesgos asociados al desarrollo de nuevos aplicativos.
8.3. WEBSPHERE
141
• Puede ser implementado sin programación utilizando una simple interface gráfica del tipo wizard (asistente).
• Remote Integration Objects (RIO) permite que Integration Objects sean
ejecutados en el servidor Host Publisher para ser accedido por aplicativos
con tecnología Java siendo ejecutados en cualquier lugar de la red.
• El XML Gateway torna datos existentes de aplicativos de host disponibles para aplicativos cliente o Business Partner Java en un formato
XML.
• El 3270/5250 HTML Mapper proporciona un emulador HTML de nivel
de entrada load-and-go dentro de una ventana de browser de la Web.
8.3.6
La familia de Herramientas WebSphere Studio
WebSphere Studio proporciona un conjunto de herramientas para facilitar el
desarrollo de aplicaciones Web. Posee un entorno visual para la distribución
de los elementos de una página web usando Java Server Pages (JSPs), HTML,
Java Script, y DHTML, ayudando además, a un rápido desarrollo de aplicaciones de comercio electrónico con contenido dinámico. Una fácil integración
entre WebSphere Studio, Java VisualAge, y WebSphere Application Servers
hace que la comunicación y el trabajo en grupo para la creación de aplicaciones de comercio electrónico basadas en Web, sea mucho más sencillo.
La familia IBM WebSphere Studio, consta de una serie de productos basados en Eclipse, que es una plataforma de código abierto para crear herramientas de desarrollo de aplicaciones. Cada producto de la familia WebSphere
Studio presenta el mismo entorno de desarrollo integrado (IDE) y una base
común de herramientas, por ejemplo para el desarrollo Java y Web. La diferencia entre estos productos radica en las herramientas de conector que están
disponibles en cada configuración.
WebSphere Studio es un único entorno de desarrollo completo diseñado
para satisfacer todas las necesidades de desarrollo, desde interfaces Web a
aplicaciones del lado del servidor, desde el desarrollo individual a desarrollos
avanzados en equipo, desde el desarrollo Java a la integración de aplicaciones.
Con varias configuraciones disponibles, así como extensiones de IBM y de
terceros, la familia WebSphere Studio permite a los desarrolladores utilizar un
142
CAPÍTULO 8. EJEMPLOS CON TECNOLOGÍAS A-C
único entorno de desarrollo diseñado para satisfacer sus necesidades específicas.
Esta visión general describe las siguientes configuraciones:
• IBM WebSphere Studio Site Developer.
• IBM WebSphere Studio Application Developer.
• IBM WebSphere Studio Application Developer Integration Edition.
• IBM WebSphere Studio Enterprise Developer.
• IBM WebSphere Homepage Builder.
Tanto para los usuarios que estén construyendo páginas Web como para
los grandes equipos que construyan aplicaciones Web avanzadas, la familia
WebSphere Studio proporciona herramientas y asistentes para simplificar las
tareas de desarrollo Web. El entono incluye una interfaz intuitiva de tipo WYSIWYG (....lo que se ve es lo que se obtiene....) que permite a los diseñadores
Web novatos crear y publicar sitios Web al tiempo que incorpora lo último en
tecnología Web, incluyendo Java Script, HTML dinámico y hojas de estilo en
cascada.
El entorno completo y fácil de utilizar de la familia WebSphere Studio
permite construir aplicaciones Java, adaptadores de aplicaciones y servicios
Web. También puede integrar la aplicación con sistemas de fondo utilizando herramientas visuales para crear adaptadores de aplicaciones y desarrollar
componentes de GUI Java (Swing y AWT) mediante el Editor visual para
Java.
Para construir aplicaciones J2EE complejas y escalables con una calidad
homogénea en menor tiempo, la familia WebSphere Studio proporciona configuraciones para el desarrollo rápido de aplicaciones que utilizan el poder de la
automatización de lógica empresarial para proporcionar sistemas de empresa
altamente configurables y escalables con una codificación manual mínima.
Esta familia de productos ofrece un entorno de desarrollo integrado que
abarca todos los cometidos de desarrollo de e-Business: desarrollador Web,
desarrollador Java, programador de empresa, analista de gestión y arquitecto
de sistemas.
Capítulo 9
WebSphere Application
Server
9.1
Introducción
El WebSphere Application Server representa una familia de software para servidores de aplicaciones. Permite a las empresas responder a los mercados
cambiantes sin migrar a tecnologías diferentes preservando las inversiones hechas en tecnología previamente disponible en la organización, soporta normas
abiertas vigentes en las organizaciones, proporciona soporte pleno a la plataforma abierta Java 2 y Java 2 Enterprise Edition (J2EE) y también provee
soporte para servicios bajo normas abiertas en la Web [2, IBM Press].
9.2
WebSphere Application Server
Se caracteriza por su flexibilidad para adaptarse a cambios en los mercados y
en los objetivos comerciales.
Construyendo aplicaciones en esta robusta plataforma, se pueden integrar
diversos ambientes de las IT(Information Technology: Tecnología de Información), para aprovechar al máximo las inversiones existentes.
Se pueden instalar aplicaciones comerciales existentes para su acceso desde
la Web y escalar estas aplicaciones para adecuarlas a las necesidades de los
143
144
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
Figura 9.1: WebSphere para e-bussines.
cambios y de la demanda.
En la figura 9.1 de la página 144 se puede observar la plataforma del
Software de WebSphere para e-bussines.
9.3
Fundamentos
Los fundamentos básicos están constituidos por los servicios de aplicaciones
Web y la integración.
Permite habilitar en la Web el comercio electrónico de manera rápida,
fiable y flexible y proporciona el software central para desplegar, integrar y
manejar las aplicaciones del e-business.
Permite la integración de aplicaciones desarrolladas con WebSphere y otras
desarrolladas con plataformas de diferentes proveedores. Tales aplicaciones
9.3. FUNDAMENTOS
145
pueden ir desde las presentaciones dinámicas en la Web hasta los sistemas
sofisticados de procesamiento de transacciones.
A su vez, el soporte de middleware de MQSeries proporciona mensajería fiable y asíncrona para más de treinta y cinco plataformas, utilizables en
aplicaciones de negocios.
Asimismo se incluyen importantes herramientas para la administración
de contenidos tendientes a facilitar la gestión de información basada en la
Internet.
Las principales características de sus componentes son las siguientes:
• WebSphere Everyplace Suite.
— Amplía las aplicaciones del e-business por nuevos carriles de comunicación.
— Entrega contenidos existentes a los nuevos dispositivos.
— Agrega soporte para nuevas tecnologías cuando ellas se desarrollan.
• WebSphere Portal Server.
— Construye los portales Web de la organización atendiendo las necesidades de empleados, socios comerciales y clientes.
— Los usuarios pueden conectarse al portal y recibir una página Web
personalizada con acceso a la información y aplicaciones Web necesarias.
• WebSphere Personalization Server.
— Arma sitios Web, Intranet, o Extranet, que entregan páginas Web
personalizadas para cada visitante del sitio.
• WebSphere Transcoding Publisher.
— Transforma datos a través de formatos múltiples, leguajes de marcadores y dispositivos.
— Adapta, reformatea, y filtra contenidos para hacerlos convenientes
para la computación invasiva (pervasive computing).
146
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
— Brinda mejor acceso a las compañías, a clientes, socios comerciales,
y empleados móviles utilizando diversos dispositivos.
• WebSphere Voice Server.
— Rápidamente desarrolla y despliega soluciones del e-business habilitadas para voz.
— Extiende el uso de aplicaciones Web a clientes que sólo tienen acceso
telefónico.
Otros módulos importantes permiten mejorar ampliamente la habilidad de
manejar altos volúmenes de tráfico para el sitio Web con alta disponibilidad y
buenos tiempos de respuesta (deployment: despliegue):
• WebSphere Site Analyzer.
Proporciona análisis para:
— Web Corporativa, respecto de visitantes, tendencias, usos y contenidos.
— WebSphere Commerce Suite, respecto de reportes diversos.
• WebSphere Edge Server.
Proporciona una solución integrada para:
— Balanceo de carga para redes LAN y WAN.
— Ruteo con calidad de servicio basado en contenido.
— Filtrado y ocultamiento de contenido Web para entornos de servidores de múltiples vendedores.
La figura 9.2 de la página 147 muestra la estructura macroscópica del
WebSphere Application Server.
9.4. WEBSPHERE DEVELOPMENT ENVIRONMENT
147
Figura 9.2: WebSphere Application Server.
9.4
WebSphere Development Environment
WebSphere Studio es el entorno de desarrollo de aplicaciones para el WebSphere Application Server. Puede usarse para crear páginas Web personales, que
sirven de interfase hacia el usuario final para las aplicaciones del e-business.
WebSphere Studio proporciona una colección de herramientas necesarias en
el desarrollo de páginas HTML y puede ser integrado con otras herramientas
de desarrollo.
VisualAge para Java es un ambiente de desarrollo integrado que da soporte
al ciclo completo del desarrollo de programas Java. Aunque no es formalmente
una parte de WebSphere Application Server Advanced Edition, VisualAge para
Java está linealmente integrado con el entorno WebSphere Application Server.
Esta integración les permite a diseñadores de VisualAge desarrollar, desplegar, y probar sus programas Java sin salir de VisualAge. También ayuda
a manejar la complejidad del ambiente empresarial y es capaz de automatizar
rutinas.
148
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
9.5
Conceptos del WebSphere Application Server
Este apartado proporciona una introducción a los siguientes conceptos:
• e-business.
• La Familia de WebSphere.
• Computación Distribuida de WebSphere Application Server.
• Componentes de WebSphere Application Server.
9.5.1
e-business
Aunque las personas usan la red para una serie de propósitos diferentes, los
negocios la utilizan principalmente para proporcionar productos, servicios, e
información a sus clientes, proveedores, y empleados.
Cuando los primeros negocios se movieron hacia la Web, era suficiente
proporcionar un pequeño número de páginas Web estáticas, que enumeraban
los productos y servicios para la venta, suministrando al mismo tiempo un
número telefónico, de tal manera que les permitiera ordenar esos productos y
servicios [14, IBM Press].
El negocio que proporcionaba servicios de información (como las compañías de software), fue uno de los primeros en ingresar a la nueva modalidad,
permitiendo que sus productos (información o software), fueran descargados
directamente desde la Web.
Cuando la Web creció y se desarrollaron nuevas tecnologías, las páginas
Web estáticas no fueron suficientes. En respuesta, las empresas construyeron
sitios Web activos para que los clientes pudieran pedir los productos directamente, que los clientes y los proveedores pudieran comunicarse con la empresa
y que los empleados pudieran comunicarse entre sí.
9.5.2
La Familia WebSphere y las Soluciones Para el e-business
La familia WebSphere fue diseñada para ayudar a los usuarios a comprender la
promesa del e-business. Es un grupo de productos de software, que contribuye
9.5. CONCEPTOS DEL WEBSPHERE APPLICATION SERVER
149
con los clientes que desarrollan y manejan sitios Web de alto rendimiento e
integra aquellos sitios Web, con nuevos o existentes sistemas de negocios noWeb. Sus enfoques están dirigidos a los siguientes tipos de empresas:
• Empresas que quieren usar las últimas tecnologías para establecer una
Web poderosa o mejorar su Web actual.
• Empresas que quieren un desarrollo distribuido con sistemas de negocios
y sus aplicaciones.
• Empresas que quieren integrar su Web actual con sistemas no-Web y sus
aplicaciones.
WebSphere Application Server
Permite a los clientes lograr sus metas del e-business y está disponible en tres
ediciones:
• WebSphere Application Server Standard Edition (también llamado Standard Application Server), combina la portabilidad del servidor de aplicaciones de negocios con el rendimiento y manejabilidad de tecnologías de
Java, para ofrecer una plataforma que permita diseñar aplicaciones Web
basadas en Java. Habilita interacciones poderosas con bases de datos
empresariales y sistemas de transacción.
• WebSphere Application Server Advanced Edition ( también llamado Advanced Application Server), construído en base al Standard Application
Server. Introduce capacidades de servidor para aplicaciones basadas en
la Especificación Enterprise JavaBeans de Sun Microsystems y provee
ciertos soportes, integrando las aplicaciones Web a otras no-Web de los
sistemas de negocios.
• WebSphere Application Server Enterprise Edition (también llamado Enterprise Application Server), basado en el Advanced Application Server, ofrece una solución robusta para acrecentar las aplicaciones del ebusiness en ambientes de la empresa. Combina TXSeries, IBM’s worldclass en el ambiente de aplicaciones transaccionales (consistiendo en
Enicna y CICS), con capacidad de integración negocio-proceso del Component Broker.
150
9.5.3
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
Computación Distribuida y WebSphere Application Server
El WebSphere Application Server proporciona un ambiente para la computación distribuida.
Computación Cliente-Servidor de Tres Niveles
Una manera común de organizar la ejecución del software en sistemas distribuidos, es separar funcionalidad en dos partes: clientes y servidores. Un
cliente es un programa que utiliza servicios de otros programas llamados servidores. El cliente hace una demanda por un servicio, y un servidor realiza
ese servicio.
La funcionalidad del servidor involucra a menudo alguna clase de dirección
del recurso, en la que un servidor sincroniza y maneja el acceso al recurso,
respondiendo a las demandas del cliente, con datos o información de estado.
El programa cliente maneja típicamente las interacciones del usuario y a
menudo datos requeridos o comienza la modificación de algunos datos bajo el
requerimiento y la responsabilidad de un usuario.
Por ejemplo, un cliente puede proporcionar la forma en que un usuario
(una persona que usa el browser de la Web, por ejemplo), puede ordenar un
producto. El cliente envía esta información de orden al servidor que verifica
la base de datos del producto y realiza las tareas de facturación y de envío.
Un solo servidor es usado típicamente por múltiples clientes. Por ejemplo,
docenas o centenares de clientes pueden interactuar con un pequeño número
de servidores que controle el acceso a las bases de datos.
Un diseño común de sistemas cliente-servidor usa tres niveles: un cliente
con el que interactúa el usuario, un servidor de aplicaciones que contiene la
lógica comercial de la aplicación, y un administrador del recurso que guarda
datos.
Si se cambia la base de datos utilizada, el servidor puede tener que ser
modificado, no así el cliente.
Hay normalmente menos copias del servidor que del cliente, y los servidores
están a menudo en sitios que son más fáciles de actualizar, (por ejemplo, en
9.5. CONCEPTOS DEL WEBSPHERE APPLICATION SERVER
151
Figura 9.3: Arquitectura Cliente-Servidor de Tres Niveles.
máquinas centrales en lugar de PC’s que operan en el escritorio del usuario),
por lo tanto el procedimiento de actualización también se simplifica. Además,
este enfoque proporciona seguridad adicional, ya que sólo los servidores, no
los clientes, necesitan acceder a los datos controlados por el administrador del
recurso.
En la figura 9.3 de la página 151 se pueden observar los tres niveles de la
arquitectura cliente-servidor.
WebSphere Application Server proporciona un nivel intermedio en esta
arquitectura, permitiendo clientes-applets, clientes de Visual Basic, clientes
de C++, etc., que actúan recíprocamente con los recursos (bases de datos
relacionales, MQSeries, etc.) y otras aplicaciones existentes.
9.5.4
WebSphere Application Server, Standard and Advanced
Editions
El WebSphere Application Server Advanced Edition y el WebSphere Application Server Standard Edition, proporcionan muchas herramientas poderosas
152
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
para la empresa, permitiendo construir soluciones complejas para el e-business.
¿Cuál es la Diferencia Entre WebSphere Application Server Standard y Advanced Edition?
Hay varias diferencias mayores entre WebSphere Application Server Standard
Edition y Websphere Application Server Advanced Edition:
• Websphere Application Server Advanced Edition soporta el desarrollo y
uso de los beans empresariales escritos en la especificación Enterprise JavaBeans (EJB) de Sun Microsystems. El WebSphere Application Server
Standard Edition no soporta el desarrollo de beans empresariales.
• Websphere Application Server Advanced Edition soporta la copia de modelos de servidor de aplicaciones que hacen fácil reproducir los servidores
de aplicaciones a través de múltiples nodos, mejorando su disponibilidad.
WebSphere Application Server Standard Edition no permite réplicas.
• WebsphereApplicationServerAdvancedEdition soporta un ambiente de múltiples máquinas para los servidores y servlets. El WebSphere Application
Server Standard Edition soporta sólo un ambiente de una única máquina para los servidores y servlets. Ambas ediciones soportan el acceso de
múltiples máquinas para los clientes.
Las interfases administrativas de los servidores de aplicaciones, difieren
un tanto como consecuencia de las diferencias en funcionalidad. La interfase
de WebSphere Application Server Advanced Edition no puede usarse para administrar un ambiente WebSphere Application Server Standard Edition y la
interfase de Standard Edition no puede usarse para administrar WebSphere
Application Server Advanced Edition.
Websphere Application Server Advanced Edition
El Websphere Application Server Advanced Edition proporciona las siguientes
facilidades:
• Herramientas para el desarrollo de sitios Web activos a través del uso de
servlets de Java y JavaServer Pages (JSP). Esta funcionalidad también
está disponible en la Standard Edition.
9.5. CONCEPTOS DEL WEBSPHERE APPLICATION SERVER
153
• Herramientas para el desarrollo y el despliegue de los beans empresariales
escritas en la especificación de EJB. Los beans empresariales pueden
actuar como un puente entre el sitio Web y los sistemas informáticos
no-Web.
• Una interfase gráfica del usuario(GUI), la Consola administrativa de
WebSphere, para administrar los componentes del ambiente de WebSphere Application Server Advanced Edition. Esta funcionalidad también
está disponible en la Standard Edition.
• Un conjunto de programas de interfase de aplicación (APIs), para generar y validar la presentación del standard universal para la escritura
de documentos de hipertexto (XML). Esta funcionalidad también está
disponible en la Standard Edition.
The WebSphere Application Server Advanced Edition Environment
El WebSphere Application Server Advanced Edition contiene los siguientes
componentes que pueden combinarse para crear un poderoso sistema multinivel basado en Java, que pone énfasis en un sitio Web cliente:
• Aplicaciones basadas en Browser.
Permite a los usuarios enviar y recibir información desde los sitios Web
usando el Protocolo de Transferencia de Hipertexto (HTTP). Hay tres tipos
generales de aplicaciones basadas en browser: Applets de Java, servlets de
Java, y JavaServer Pages (JSP).
• Servicios Web.
Excepto para los applets de Java, los cuales están restringidos por la seguridad interna de Java, las aplicaciones basadas en browser requieren que
un servidor Web sea instalado en al menos una máquina en el entorno de
WebSphere Application Server Advanced Edition.
• Servidores de Aplicaciones y beans empresariales.
154
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
El WebSphere Application Server contiene uno o más beans empresariales que encapsulan la lógica comercial y los datos usados y compartidos por
aplicaciones de EJB. Los beans empresariales instalados en un servidor de
aplicaciones no se comunican directamente con el servidor. Un contenedor
EJB brinda una interfase entre los beans empresariales y el servidor de aplicaciones, proporcionando servicios de bajo nivel tal como el soporte de hilos de
ejecución, soporte de las transacciones, y administración del almacenamiento
de los datos y de la recuperación.
• Aplicaciones Java.
Pueden interactuar directamente con un servidor de aplicaciones usando
Java mediante RMI/IIOP (Invocación de métodos remotos: Remote Method
Invocation/ Internet InterORB Protocol: Protocolo de Comunicación entre
ORBs (Agente de Petición de Objeto: Object Request Broker)en Internet).
• Fuente de Datos.
Hay dos tipos de beans empresariales: beans de sesión que encapsulan por
tiempo determinado tareas y objetos de las especificaciones cliente, y beans
de entidades, que encapsulan datos permanentes o persistentes. El servidor de
aplicaciones guarda y recupera estos datos persistentes en una base de datos.
• Extensiones del modelo de programación WebSphere.
Estas herramientas proporcionan la reusabilidad de la lógica de los programas de Java de la empresa.
• Administración del servidor y administración de interfase.
El administrador del servidor maneja servlets, archivos JSP, beans empresariales, y servidores de aplicaciones. Esta administración es dirigida por el
administrador de WebSphere Application Server quien hace uso de la consola
administrativa de WebSphere.
• La figura 9.4 de la página 155 muestra los componentes del ambiente de
WebSphere Application Server Advanced Edition [17, IBM].
9.5. CONCEPTOS DEL WEBSPHERE APPLICATION SERVER
155
Figura 9.4: Componentes del Ambiente de WebSphere Advanced Edition.
Applets y Servlets de Java
Los applets de Java son aplicaciones que corren en un browser y extienden las
capacidades del mismo. Los applets de Java pueden ser diseñados usando los
paquetes normales encontrados en el Java2 SDK o usando los componentes
del Java Fundation Classes (JFC). Para que un applet de Java corra dentro
de un browser, los browser deben soportar las clases usadas dentro del applet;
sin embargo, la mayoría de los browsers pueden actualizarse para dar soporte
al último SDK instalado mediante los plug-ins del browser.
Los servlets de Java corren en un servidor Java habilitado y amplían las
capacidades del mismo. Son programas de Java que usan los Java Servlet API,
las clases asociadas y los métodos. Además del Java Servlet API, los servlets
pueden usar clases de paquetes de Java que amplían y se agregan al API.
Pueden diseñarse applets de Java para actuar recíprocamente con servlets de
Java, sin embargo esto no es obligatorio. Los servlets amplían las capacidades
del servidor Web creando un entorno para el suministro de servicios de requerimiento y respuesta sobre la Web. Cuando un cliente envía una demanda al
servidor, el servidor puede enviar la información de la demanda a un servlet,
éste puede realizar la contestación y el servidor la envía nuevamente al cliente.
156
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
Al contrario de los programas de la Common Gateway Interface (CGI), los
cuales requieren un proceso entero para manejar las peticiones de los usuarios,
los servlets pueden tratar las peticiones de los usuarios usando hilos. Esta
capacidad hace a los servlets mucho más eficaces que los programas de CGI.
Los servlets pueden cargarse automáticamente cuando el servidor Web
arranca, o pueden ser cargados la primera vez que un cliente pide sus servicios.
Después de estar cargado, el servlet continúa corriendo, esperando por las
demandas adicionales del cliente.
Los servlets realizan una amplia gama de funciones; por ejemplo, un servlet
puede:
• Crear y devolver una página Web HTML entera que contenga contenido
dinámico basado en la naturaleza de la demanda del cliente.
• Crear una porción de una página Web HTML (un fragmento de HTML)
que puede estar incrustado en una página HTML existente.
• Comunicarse con otros recursos del servidor, incluso con los bancos de
datos y aplicaciones basadas en Java.
• Manejar las conexiones con clientes múltiples, aceptando la entrada y
transmitiendo resultados a los mismos.
• Abrir una nueva conexión del servidor a un applet en el browser y mantener la conexión abierta, permitiendo la transferencia de muchos datos
en una sola conexión. El applet también puede comenzar una conexión
entre el browser del cliente y el servidor, permitiendo a ambos mantener
fácilmente y eficazmente una conversación.
• Depurar los datos por tipo del MIME para un procedimiento especial,
tal como conversión de imagen.
• Suministrar procedimientos hechos a medida a cualquier rutina del servidor normal; por ejemplo, un servlet puede modificar cómo un usuario
se autentica.
Páginas del Servidor Java
El WebSphere Application Server Advanced Edition soporta un poderoso y
nuevo enfoque hacia el contenido dinámico de las páginas Web: JavaServer
9.5. CONCEPTOS DEL WEBSPHERE APPLICATION SERVER
157
Pages (JSP). Los JSP funcionan en el servidor de aplicaciones basado en la
especificación de Sun Microsystems JavaServer Pages.
Los archivos JSP son similares en algunas formas al servidor que incluye
un HTML estático, porque ambos incrustan funcionalidad del servlet en la
página Web. Sin embargo, en un servidor, una llamada a un servlet está
incluida dentro de una etiqueta especial del servlet; en JSP, el código del
servlet de Java (u otro código de Java) está directamente incluido en la página
HTML.
Una de las muchas ventajas de JSP es que permite separar eficazmente el
código HTML, de la lógica comercial en las páginas Web. Se puede utilizar
a JSP para acceder a componentes reutilizables, como servlets, Java beans,
beans empresariales y aplicaciones Web basadas en Java.
Servidores Web
El servidor Web permite el enlace de comunicaciones entre las aplicaciones
basadas en browser y los otros componentes de WebSphere Application Server
Advanced Edition, el cual contiene un servlet basado en Java que es independiente de su servidor Web y de su sistema operativo subyacente.
WebSphere Application Server Advanced Edition soporta muchos de los
más ampliamente usados servidores Web.
Servidores de Aplicaciones y Beans Empresariales
Un servidor de aplicaciones suministra un ambiente run-time para los beans
empresariales, manipulando tareas de programación de bajo nivel como la
administración de transacciones, nombrando, y dando seguridad.
Hay dos tipos de beans empresariales:
• Bean de entidad que encapsula datos permanentes, como los que se guardan en una fuente de datos, tal como una base de datos o un sistema de
archivos, y métodos asociados para manipular esos datos. En la mayoría
de los casos, un bean de entidad debe accederse de manera transaccional. En algunos casos los beans de entidad son exclusivos, y pueden ser
accedidos por usuarios múltiples.
158
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
Por ejemplo, puede encapsularse la información de una cuenta bancaria en
un bean de entidad. Un bean empresarial de cuenta podría contener un ID de
cuenta, un tipo de cuenta (cuenta corriente o caja de ahorro), y un saldo.
• Bean de sesión que encapsula una o más tareas comerciales y datos
temporarios asociados con un cliente particular. A diferencia de los datos
en un bean de entidad, los datos en un bean de sesión no se guardan en
una fuente de datos permanente y no causan ningún daño si estos datos
se pierden. No obstante, un bean de sesión puede actualizar datos en
una base de datos fundamental, normalmente accediendo a un beans de
entidad. Por esta razón, un bean de sesión puede ser una transacción.
Cuando se crea, las instancias de un bean de sesión son idénticas, sin
embargo algunos beans de sesión pueden guardar datos semipermanentes que
los hacen únicos en ciertos puntos de su ciclo de vida. Un bean de sesión
siempre está asociado con un solo cliente.
Por ejemplo, la tarea asociada con la transferencia de fondos entre dos
cuentas del banco puede encapsularse en un bean de sesión, dicha transferencia
de beans empresariales podría encontrar dos instancias de una cuenta de beans
empresariales (usando el ID de cuenta), y entonces se puede substraer una
cantidad especificada de una cuenta y agregar la misma cantidad a otra cuenta.
Antes de que un bean empresarial pueda instalarse en un servidor de aplicaciones, el mismo debe desplegarse. Durante el despliegue, varias aplicaciones
de clases específicas del servidor se generan. El descriptor de despliegue contiene atributos y especificaciones de entorno, que definen cómo el servidor de
aplicaciones invoca la funcionalidad del beans empresarial.
Cada bean empresarial (de sesión y de entidad), debe tener un descriptor
de despliegue que contiene especificaciones usadas por el servidor de aplicaciones; estos atributos pueden ser a menudo un conjunto completo de beans
empresariales o métodos individuales en el bean.
El WebSphere Application Server Advanced Edition proporciona herramientas para crear descriptores de despliegue y desplegar los beans empresariales.
9.5. CONCEPTOS DEL WEBSPHERE APPLICATION SERVER
159
Extensiones del Modelo de Programación WebSphere
Las extensiones del modelo de programación WebSphere son utilidades de
propósito general, diseñadas para proveer funciones comunes de manera reutilizable.
Hay dos juegos de herramientas en el ambiente de WebSphere Application
Server Advanced Edition para programadores de Java, ellos son el paquete de
comandos y el paquete distribuido por excepción.
El paquete de comandos proporciona una manera de distribución de aplicaciones para manejar en forma conjunta todas las demandas remotas, reduciendo el número de invocaciones remotas individuales. Las invocaciones remotas
son caras, por lo tanto el paquete de comandos puede ayudar a mejorar el
rendimiento de aplicaciones distribuidas. Además, proporciona una manera
genérica de confección de demandas y una manera común de emitir una orden, local o remotamente, independientemente del servidor de aplicaciones.
Cualquier servidor (un beans empresarial, un servidor JDBC, etc.) puede ser
el objetivo de un comando.
El paquete distribuido por excepción ayuda a administrar las excepciones
en aplicaciones distribuidas. Al escribir aplicaciones distribuidas complejas,
se selecciona un grupo de excepciones. Una opción es administrar cada excepción explícitamente, capturando cada una por nombre. Esto asegura que
la información sobre la excepción original no se pierde, pero puede llevar a
códigos inmanejables como a un número de incrementos de excepciones.
La otra opción es adoptar una estrategia para arrojar una excepción cuando
se toma cualquiera de un grupo. Esta opción permite mantener manejable el
número de excepciones, pero se pierde información acerca de la excepción
particular.
El paquete distribuido por excepción permite encadenar una sucesión de
excepciones en un objeto. Con una cadena de excepciones, se puede enviar
una excepción en contestación a otra, sin perder las excepciones anteriores.
También se puede recuperar excepciones en cadena.
160
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
Figura 9.5: Arquitectura de WebSphere Application Server Advanced Edition.
9.6
Arquitectura de WebSphere
En este apartado se analizan los componentes dentro de WebSphere Application Server, tal como el servidor de aplicaciones, el contenedor Web, el
contenedor EJB, y los componentes de la arquitectura J2EE.
La figura 9.5 de la página 160 muestra la arquitectura de WebSphere Application Server, Advanced Edition y sus componentes.
9.6.1
Servidor de Aplicaciones
El servidor de aplicaciones colabora con el servidor Web para regresar las
respuestas correspondientes a los requerimientos de los clientes. El código de
la aplicación incluye servlets, JSPs, EJBs, y sus clases soportadas ejecutando
en un servidor de aplicaciones.
Siguiendo con los componentes de la arquitectura J2EE, los servlets y JSPs
se ejecutan en un contenedor Web, y EJBs se ejecuta en un contenedor EJB.
9.6. ARQUITECTURA DE WEBSPHERE
161
En WebSphere Advanced Edition se pueden definir servidores de aplicaciones múltiples, cada uno ejecutándose en su propia JVM (Máquina Virtual de
Java), como así también el servidor administrativo.
Default Server (Servidor Predefinido)
Un servidor predefinido de aplicaciones es comúnmente llamado “Default Server”, configurado durante la instalación predefinida de WebSphere Application
Server. El Servidor predefinido, como cualquier otro servidor de aplicaciones
se ejecuta en el contenedor Web y en el contenedor EJB.
9.6.2
HTTP Server y Plug-in
El WebSphere Application Server trabaja con un servidor de HTTP, o servidor
Web, manipula peticiones dinámicas, como servlets, de las aplicaciones Web.
El servidor de HTTP y el servidor de la aplicación, se comunican usando
el WebSphere HTTP plug-in para el servidor de HTTP.
El HTTP plug-in aprovecha la configuración de archivo de fácil lectura
de XML, para determinar si una petición debe ser manejada por el servidor
Web o por el servidor de aplicaciones. Usa el protocolo de HTTP normal para
comunicarse con el servidor de aplicaciones. También puede configurarse para
usar HTTPS seguro, si es preciso.
El HTTP plug-in está disponible para los servidores Web más conocidos,
incluso el Servidor HTTP de IBM, Apache, Microsoft IIS, y iPlanet de Netscape.
9.6.3
Embedded HTTP Server (Servidor HTTP Incluído)
Un rasgo bueno de WebSphere es el servidor de HTTP incluido dentro del
servidor de aplicaciones. Este servidor Web es muy útil para propósitos de
prueba o desarrollo pero no debe usarse en ambientes de producción. Por
razones de performance y seguridad, se debe usar un servidor Web y plug-in
HTTP para el servidor Web en un ambiente de producción.
162
9.6.4
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
Virtual Hosts (Hosts Virtuales)
Un host virtual es una configuración que permite a una sola máquina host
aparentar ser múltiples máquinas hosts. Permite que una sola máquina física
configure y administre independientemente varias aplicaciones administradas.
No está asociado a un nodo particular (máquina). Es una configuración, diferente de un “objeto vivo”, indicando que puede crearse, pero no arrancarse o
detenerse.
Cada host virtual tiene un nombre lógico y una lista de uno o más seudónimos de DNS por los cuales es conocido. Un seudónimo de DNS es el nombre
TCP/IP del host y el número del puerto que use la petición del servlet, por
ejemplo su nombre Host:80.
El WebSphere Application Server proporciona un host virtual predefinido, denominado “el default_host”, con algunos seudónimos comunes, como
el IP de la máquina, nombre corto del host, y el nombre del host completo. El seudónimo comprende la primera parte del camino para el acceso a un recurso, como un servlet. Por ejemplo, localhost:80 en la petición
http://localhost:80/servlet/snoop.
Los hosts virtuales le permiten al administrador aislar y manejar independientemente los múltiples grupos de recursos en la misma máquina física.
9.6.5
Servidor de Grupos
Un servidor de grupos es una facilidad para crear copias adicionales, casi idénticas de un servidor de aplicaciones y sus contenidos. Es una representación
lógica del servidor de aplicaciones.
Un servidor de grupos tiene la misma estructura y atributos que el servidor
de aplicaciones. Puede incluir contenedores Web, contenedores EJB, servlets,
EJBs, y otro recursos.
El servidor de grupos permite ver y modificar cualquier propiedad asociada
con estos objetos lógicos. Pero el servidor de grupos no está asociado con
ningún nodo físico en particular, ningún servidor de grupos corresponde a
ningún proceso real de servidor ejecutando en ningún nodo.
Una vez creado un servidor de grupos, se puede crear clones de ese servidor
de tal manera que los servidores de grupos también ayuden en la administra-
9.6. ARQUITECTURA DE WEBSPHERE
163
ción de los clones. Por ejemplo, cambiando el servidor de grupos cambiarán
todos los clones y arrancando un servidor de grupos arrancarán todos los clones.
9.6.6
Clones
Clonar es el proceso de crear un servidor de grupos basado en uno existente.
Los clones son en todos los sentidos idénticos al servidor de grupos del que
fueron creados. Los clones creados a partir de diferentes servidores de grupos,
representan los servidores de aplicaciones que se procesan en los nodos físicos.
Los clones del servidor de aplicaciones pueden estar contenidos en una sola
máquina, con lo cual se puede escalar verticalmente o pueden distribuirse en
diferentes máquinas permitiendo escalar horizontalmente.
Pueden usarse clones para la administración del workload, con lo cual un
requerimiento de un recurso del servidor puede ser manejado por cualquiera
de los clones del servidor.
Modificando el servidor de grupos automáticamente propaga los cambios a
todos los clones cuando ellos se reinician. Si un clon se modifica directamente,
no es idéntico a su servidor de grupos. Sin embargo, continúa siendo parte de
él a menos que sea desvinculado del servidor de grupos.
9.6.7
Contenedor Web
El contenedor Web de WebSphere procesa servlets, archivos JSP. Los servlets
pre-J2EE podrían ejecutarse en un motor de servlet. Cada contenedor Web
contiene automáticamente a un solo administrador de sesiones.
Al manejar servlets, el contenedor Web crea un objeto de requerimiento y
un objeto de respuesta invocando un método de servicio del servlet. El contenedor Web invoca al método destroy () del servlet cuando asigna y descarga
el servlet, después de que el JVM realiza la recolección de basura.
El contenedor Web proporciona el PageListServlet para llamar a Java Server Page (JSP) por su nombre. El PageListServlet utiliza la información de
configuración de JSP nombrando a un Uniform Resource Identifier: Identificador Uniforme de Recurso (URI), este URI especifica un archivo JSP en el
164
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
módulo Web.
La configuración del contenedor Web proporciona información sobre los
componentes del servidor de aplicaciones que manejan las peticiones servlet
hechas por el servidor Web. El administrador específico del contenedor Web
incluye las siguientes propiedades:
• Nombre del servidor de aplicaciones donde se ejecutan los contenedores
Web.
• Número y tipo de conexiones entre el servidor Web y el contenedor Web.
• Dispositivo para la conexión externa del contenedor Web.
La Consola Administrativa de WebSphere o la consola administrativa Web
se pueden utilizar para revisar las configuraciones del contenedor Web. Cada
runtime del servidor de aplicaciones tiene un contenedor Web lógico que se
puede modificar pero no se puede crear o eliminar.
Módulo Web
Un módulo Web representa una aplicación Web. Se usa para agrupar servlets
y archivos JSP, así como el contenido estático de las páginas HTML, en una
sola unidad.
Los módulos Web se guardan en documentos de archivos Web o en archivos
WAR (.war), como son los documentos de archivos standards de JSP.
Un módulo Web contiene uno o más servlets, archivos de JSP entre otros.
También contiene un descriptor de despliegue que declara el contenido del
módulo, guardado en un archivo de XML, llamado Web.xml.
El descriptor de despliegue contiene información sobre la estructura y dependencias de los componentes Web en el módulo y describe cómo estos serán
usados en el runtime.
Un modulo Web puede utilizarse como una aplicación stand-alone, o como
una combinación con otros módulos (otros módulos Web, módulos EJB, o
ambos) para crear una aplicación J2EE y se instala y corre en un Contenedor
Web.
9.6. ARQUITECTURA DE WEBSPHERE
9.6.8
165
EJB Container (Contenedor EJB)
El contenedor EJB porciona todos los servicios del runtime necesarios para
desplegar y manejar los EJBs. Es un proceso del servidor que maneja las
peticiones para los beans de sesión y beans de entidad.
Los beans empresariales (dentro de los módulos de EJB) se instalan en el
servidor de aplicaciones pero no se comunican directamente con el servidor;
en cambio, un contenedor EJB proporciona una interfaz entre el EJB y el
servidor. Juntos, el contenedor y el servidor proporcionan el ambiente de
runtime para el bean.
El contenedor proporciona muchos servicios de bajo nivel, incluyendo threading ( manejo de hilos) y soporte de transacción. Desde el punto de vista
administrativo, el contenedor maneja el almacenamiento y recuperación de los
datos para los beans contenidos. Un contenedor puede soportar más de un
archivo EJB JAR.
Módulo de EJB
Un módulo de EJB se usa para configurar uno o más beans empresariales en
una sola unidad desplegable. Un módulo de EJB se guarda en un archivo
estándar de Java (JAR), contiene uno o más beans empresariales desplegables
y un descriptor de almacenamiento desplegable en un archivo de XML.
9.6.9
El Modelo Administrativo WebSphere
En la figura 9.8 de la página 171 se puede apreciar el modelo administrativo
de WebSphere.
Un dominio administrativo es un juego de uno o más nodos que comparten
un depósito administrativo en la forma de una base de datos relacional. Un
dominio administrativo es el espacio lógico que contiene las configuraciones
para varios objetos en el ambiente de WebSphere.
Un nodo es una máquina física que ejecuta un servidor de aplicaciones y
un servidor administrativo.
Cada servidor administrativo en el dominio guarda sus datos administra-
166
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
Figura 9.6: Modelo Administrativo de WebSphere.
tivos en una memoria compartida.
El usuario de interfase administrativa, fuera del dominio administrativo,
se comunica con los servidores administrativos que usan IIOP (completar) o
HTTP. WebSphere Advanced Edition usa la consola administrativa de Java e
IIOP en tanto que WebSphere Advanced Edition Single Server usa la consola
administrativa de HTTP Web.
Los recursos de WebSphere en un nodo, están representados como recursos
administrativos en el dominio administrativo de WebSphere.
9.6.10
Servidor Administrativo
El servidor administrativo es el sistema de administración de runtime, es un
componente de WebSphere. Es responsable de la administración del runtime,
seguridad, coordinación de la transacción, y dirección del workload. En la
mayoría de los casos, el servidor administrativo corre en todos los nodos en un
dominio administrativo WebSphere y controla la interacción entre cada nodo
y el proceso del servidor de aplicaciones en el dominio.
9.6. ARQUITECTURA DE WEBSPHERE
167
El servidor administrativo de WebSphere proporciona los administradores
con una sola vista del sistema de aplicaciones y recursos, como JSPs, servlets,
y EJBs, que podrían desplegarse por las múltiples plataformas en un ambiente
distribuido.
Administrar recursos en una máquina remota es tan fácil como administrarlos en una máquina local.
9.6.11
Almacenamiento Administrativo
WebSphere guarda toda la información de configuración del runtime para un
dominio en un solo almacén persistente. Esa base de datos se nombra por
defecto WAS. Toda la administración tienen lugar a través de la manipulación
de los objetos en el almacenamiento administrativo.
Los lugares de depósito pueden almacenarse en DB2, Oracle, Informix,
Servidor MS SQL, o Sybase.
En el Server Edition este depósito de datos se almacena en una configuración de archivo XML.
En el diagrama se muestra un solo nodo que ejecuta todos los procesos,
y esto es común en ambientes pequeños de producción. Es completamente
razonable configurar la base de datos en un servidor remoto, y en ambientes
de producción se recomienda que sea usado de ese modo.
9.6.12
Interfases Administrativas
El Servidor Administrativo de WebSphere proporciona los servicios usados
para el control de recursos y el desempeño de las tareas en la base de datos
administrativa. Supervisa y configura recursos administrativos así como detener y arrancar los servidores, lo cual es facilitado a través de cuatro interfases,
como se muestra en la figura 9.7 de la página 168.
Las dos interfases, gráfica y líneas de comando se complementan bastante
bien entre ellas. Se pueden usar las interfases gráficas interactivamente administrando el ambiente de WebSphere. Se puede usar las herramientas de líneas
de comando para configuración automática.
168
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
Figura 9.7: Interfases Administrativas.
Consola Administrativa de Java
Normalmente conocida como la consola administrativa de WebSphere o simplemente como “admin console”, esta interfase gráfica del usuario se usa principalmente para la administración del dominio administrativo WebSphere. Esta
soporta un amplio rango de actividades administrativas de WebSphere Advanced Edition. La consola administrativa puede ejecutarse en uno de los nodos,
en los que el servidor administrativo está corriendo, o puede invocarse en un
nodo remoto que sea asistente de un servidor administrativo.
En Windows se accede a la consola administrativa pulsando el botón Start
> Progams > IBM WebSphere > Application Server > Administrator’s Console. En sistemas UNIX se invoca el script de adminclient.sh encontrada en
<WAS_HOME>/bin para habilitar la consola administrativa. Por defecto la
consola administrativa conecta al servidor administrativo vía puerto 900.
9.6. ARQUITECTURA DE WEBSPHERE
169
La Consola Administrativa Web
La consola administrativa Web es como un editor de configuración que corre
en un Web browser.
Proporciona la oportunidad de trabajar con WebSphere Application Server
Advanced Edition Single Server de configuración de Servidor en código XML.
Esta sencilla GUI basada en Web está disponible solo en WebSphere AEs.
La consola administrativa Web, puede ser activada en la máquina local
tecleando el URL siguiente en un Web-Browser: http://localhost:9090/admin.
La configuración que se carga por defecto está contenido en el servidorcfg.xml, que se encuentra en el <WAS_HOME>/config directory. Una configuración diferente de archivo puede cargarse en la Web una vez que la consola
administrativa está abierta en el browser.
Sin embargo, cualquier otro archivo de la configuración escogido puede
pasarse como un parámetro en el browser URL para que se cargue en startup.
El browser URL debe ser el siguiente:
http://localhost:9091/admin/edit?configFile=C:/temp/foo.xml
Esto cargará foo.xml del directorio C:/temp.
WebSphere Control Program (El Control de Programa de WebSphere)
El WeSphere Control Program es una herramienta de líneas de comando administrativa que está disponible en la Edición Avanzada. También opera en
modo interactivo. Se puede usar el WebSphere Control Program para administrar recursos del dominio tal como definir, configurar, manejar, importar y
exportar configuraciones, y ejecutar diagnósticos de operaciones. Está basado
en TCL.
TCL simboliza el Tool Command Language. Es un recurso libre y hay
también una versión de Java de TCL llamada Java Control Language (JACL).
El lenguaje TCL tiene una sintaxis simple y programable, y puede usarse en
modo stand-alone o en aplicaciones embebidas.
TCL es extensible y las extensiones TCL de WebSphere Control Program,
170
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
proveen un grupo de comandos para la manipulación de objetos WebSphere.
XMLConfig
XMLConfig es otra herramienta administrativa de líneas de comando disponible con WebSphere Advanced Edition. XMLConfig ofrece al administrador
de WebSphere la posibilidad de importar y exportar (exportación total o parcial) la configuración de datos en el almacenamiento administrativo. Se puede
usar esta herramienta para hacer múltiples cambios al repositorio de administración sin tener que repetir manualmente los cambios usando la consola
administrativa. También se lo puede usar para generar un nuevo plug-in de
configuración de archivos con la nueva opción generatePluginCfg.
XMLConfig no es una herramienta interactiva y no puede usarse para
recuperar información de estado de WebSphere.
DrAdmin
La herramienta de comando DrAdmin está disponible en todas las ediciones
de WebSphere Application Server y se usa principalmente para detectar errores. Se localiza en el <WAS_HOME>/bin directory y puede usarse para
diagnosticar problemas cuando otras herramientas fallan.
9.6.13
Referencia Rápida para la Administración
El modelo administrativo para las Ediciones Avanzadas y Normales se resume
en la figura 9.8 de la página 171.
Como se ha mostrado anteriormente, y en las vistas del árbol de la consola administrativa y otras herramientas administrativas gráficas, el dominio
administrativo de WebSphere está compuesto por varios tipos de recursos,
organizados en una jerarquía de contenidos relacionados.
9.6.14
Discusión
Los nodos administrativos contienen uno o más servidores de aplicación, y
varios recursos que transcienden los servidores de aplicaciones (tales como
9.6. ARQUITECTURA DE WEBSPHERE
Figura 9.8: Modelo de Administración.
171
172
CAPÍTULO 9. WEBSPHERE APPLICATION SERVER
aquellos relacionados al soporte JDBC),
o están separados de los servidores de aplicación (como servidores genéricos). Los plug-ins de WebSphere para los servidores Web soportados también
requieren administración.
Finalmente, pueden establecerse grupos de servidores lógicos para distribuir la carga de trabajo entre múltiples servidores de aplicaciones clonados.
Una aplicación empresarial consiste en módulos EJB, módulos Web, y
clientes de la aplicación. Puede residir en cualquier servidor de aplicaciones.
Una aplicación instalada en múltiples servidores de aplicaciones puede estar
ejecutándose en algunos servidores, pero detenido en otros. Debido a la posible
mezcla de estados de sus instancias, no es significante decir si una aplicación
(como la colección de todas sus instancias) está corriendo o se detuvo. Por
consiguiente, una aplicación empresarial es una entidad estática.
Por el contrario, el EJB, la Web, y los módulos de clientes de aplicaciones que comprenden cada aplicación empresarial son verdaderamente objetos
activos, cada uno de los cuales tiene un estado válido.
Un grupo de servidores es una entidad estática que consiste en uno o más
clones. Normalmente, algunos clones están corriendo mientras otros no. Por
ende, no es significativo asignar un estado al grupo de servidores global.
9.6.15
¿Qué son los Recursos?
El término recurso se usa para describir un juego lógico de propiedades que
puede ser administrado como soporte de sesión que usa el servicio de Administración de Sesión. El rango de los recursos se extiende desde objetos complejos,
que pueden arrancarse y pueden detenerse, como servidores de aplicaciones,
hasta simples ambientes de grupos, como las propiedades de configuración
para el soporte de transacción.
Por ejemplo, un servidor de aplicaciones contiene varios servicios. El servidor de aplicaciones es representado en la vista del árbol de la consola administrativa, no así los servicios individuales. Cada servicio tiene un juego de
propiedades que se pueden configurar.
Capítulo 10
PHP (Hypertext
Preprocessor)
10.1
Introducción a la Programación Php
[20]PHP es uno de los lenguajes de lado servidor más extendidos en la web.
Nacido en 1994, se trata de un lenguaje de creación relativamente creciente
que ha tenido una gran aceptación en la comunidad de webmasters debido
sobre todo a la potencia y simplicidad que lo caracterizan.
Es un lenguaje “Open Source” interpretedo de alto nivel, especialmente
pensado para desarrollos web y el cual puede ser embebido en páginas HTML
y ejecutado en el servidor.
PHP permite embeber pequeños fragmentos de código dentro de la página
HTML y realizar determinadas acciones de una forma fácil y eficaz sin tener
que generar programas programados íntegramente en un lenguaje distinto al
HTML. Por otra parte, y es aquí donde reside su mayor interés con respecto a
los lenguajes pensados para los CGI, PHP ofrece un sinfín de funciones para
la explotación de bases de datos de una manera llana, sin complicaciones.
173
174
CAPÍTULO 10. PHP
10.2
¿Qué se puede hacer con PHP?
PHP puede hacer cualquier cosa que se pueda hacer con un script CGI, como procesar la información de formularios, generar páginas con contenidos
dinámicos, o enviar y recibir cookies. Y esto no es todo, se puede hacer mucho
más.
Existen tres campos en los que se usan scripts escritos en PHP:
• Scripts del lado del servidor. Este es el campo más tradicional y el
principal foco de trabajo. Se necesitan tres cosas para que esto funcione.
El intérprete PHP (CGI ó módulo), un servidor web y un navegador.
Es necesario correr el servidor web con PHP instalado. El resultado del
programa PHP se puede obtener a través del navegador, conectándose
con el servidor web.
• Scripts en la línea de comandos. Puede crearse un script PHP y correrlo
sin ningún servidor web o navegador. Solamente se necesita el intérprete
PHP para usarlo de esta manera. Este tipo de uso es ideal para scripts
ejecutados regularmente desde cron (en *nix o Linux) o el Planificador
de tareas (en Windows). Estos scripts también pueden ser usados para
tareas simples de procesamiento de texto.
• Escribir aplicaciones de interfaz gráfica. Probablemente PHP no sea el
lenguaje más apropiado para escribir aplicaciones gráficas, pero si coconoce bien PHP, y si se quisiera utilizar algunas características avanzadas
en programas clientes, puede utilizarse PHP-GTK para escribir dichos
programas. También es posible escribir aplicaciones independientes de
una plataforma. PHP-GTK, que es una extensión de PHP.
PHP puede ser utilizado en cualquiera de los principales sistemas operativos del mercado, incluyendo Linux, muchas variantes Unix (incluyendo
HP-UX, Solaris y OpenBSD), Microsoft Windows, Mac OS X, RISC OS
y probablemente alguno más. PHP soporta la mayoría de servidores
web de hoy en día, incluyendo Apache, Microsoft Internet Information
Server, Personal Web Server, Netscape e iPlanet, Oreilly Website Pro
server, Caudium, Xitami, OmniHTTPd, WebSphere Smash y muchos
otros. PHP tiene módulos disponibles para la mayoría de los servidores,
para aquellos otros que soporten el estándar CGI, PHP puede usarse
como procesador CGI.
10.2. ¿QUÉ SE PUEDE HACER CON PHP?
175
De modo que, con PHP se tiene la libertad de elegir el sistema operativo y el servidor de su gusto. También tiene la posibilidad de usar
programación procedimental o programación orientada a objetos. Aunque no todas las características estándar de la programación orientada
a objetos están implementadas en la versión actual de PHP, muchas bibliotecas y aplicaciones grandes (incluyendo la biblioteca PEAR) están
escritas íntegramente usando programación orientada a objetos.
Con PHP no se encuentra limitado a resultados en HTML. Entre las
habilidades de PHP se incluyen: creación de imágenes, archivos PDF y
películas Flash (usando libswf y Ming) sobre la marcha. También puede
presentar otros resultados, como XHTM y archivos XML. PHP puede
autogenerar éstos archivos y almacenarlos en el sistema de archivos en
vez de presentarlos en la pantalla.
Quizás la característica más potente y destacable de PHP es su soporte
para una gran cantidad de bases de datos. Escribir un interfaz vía web
para una base de datos es una tarea simple con PHP. Las siguientes
bases de datos están soportadas actualmente:
• Adabas D
• dBase
• Empress
• FilePro (read-only)
• Hyperwave
• IBM DB2
• Informix
• Ingres
• InterBase
• FrontBase
• mSQL
• Direct MS-SQL
• MySQL
176
CAPÍTULO 10. PHP
• ODBC
• Oracle (OCI7 and OCI8)
• Ovrimos
• PostgreSQL
• Solid
• Sybase
• Velocis
• Unix dbm
También cuenta con una extensión DBX de abstracción de base de datos
que permite usar de forma transparente cualquier base de datos soportada por
la extensión. Adicionalmente, PHP soporta ODBC (el Estándar Abierto de
Conexión con Bases de Datos), asi que puede conectarse a cualquier base de
datos que soporte tal estándar.
PHP también cuenta con soporte para comunicarse con otros servicios
usando protocolos tales como LDAP, IMAP, SNMP, NNTP, POP3, HTTP,
COM (en Windows) y muchos otros. También se pueden crear sockets puros.
PHP soporta WDDX para el intercambio de datos entre lenguajes de programación en web. Y hablando de interconexión, PHP puede utilizar objetos Java
de forma transparente como objetos PHP Y la extensión de CORBA puede
ser utilizada para acceder a objetos remotos.
PHP tiene unas características muy útiles para el procesamiento de texto,
desde expresiones regulares POSIX extendidas o tipo Perl hasta procesadores
de documentos XML. Para procesar y acceder a documentos XML, soporta los
estándares SAX y DOM. Puede utilizar la extensión XSLT para transformar
documentos XML.
Si se usa PHP en el campo del comercio electrónico, se encontrarán muy
útiles las funciones Cybercash, CyberMUT, VeriSign Payflow Pro y CCVS
para los programas de pago.
Cuenta con muchas otras extensiones muy interesantes, las funciones del
motor de búsquedas mnoGoSearch, funciones para pasarelas de IRC, utilidades
de compresión (gzip, bz2), conversión de calendarios, traducción.
10.3. REFERENCIA DEL LENGUAJE
10.3
Referencia del Lenguaje
10.3.1
Sintaxis Básica
177
Para interpretar un archivo, php símplemente interpreta el texto del archivo
hasta que encuentra uno de los carácteres especiales que delimitan el inicio
de código PHP. El intérprete ejecuta entonces todo el código que encuentra,
hasta que encuentra una etiqueta de fin de código, que le dice al intérprete que
siga ignorando el código siguiente. Este mecanismo permite embeber código
PHP dentro de HTML: todo lo que está fuera de las etiquetas PHP se deja
tal como está, mientras que el resto se interpreta como código.
Hay cuatro conjuntos de etiquetas que pueden ser usadas para denotar
bloques de código PHP. De estas cuatro, sólo 2 (<?php. . .?> y <script
language=”php”>. . .</script>) están siempre disponibles; el resto pueden
ser configuradas en el fichero de php.ini para ser o no aceptadas por el intérprete. Mientras que el formato corto de etiquetas (short-form tags) y el estilo
ASP (ASP-style tags) pueden ser convenientes, no son portables como la versión de formato largo de etiquetas. Además, si se pretende embeber código
PHP en XML o XHTML, será obligatorio el uso del formato <?php. . .?>
para la compatibilidad con XML.
Las etiquetas soportadas por PHP son:
1. <?php echo(”si quieres servir documentos XHTML o XML, haz como
aquí\n”); ?>
2. <? echo (”esta es la más simple, una instrucción de
procesado SGML \n”); ?>
<?= expression ?> Esto es una abreviatura de ”<? echo expression ?>”
3. <script language=”php”>
echo (”muchos editores (como FrontPage) no aceptan instrucciones de
procesado”);
</script>
4. <% echo (”Opcionalmente, puedes usar las etiquetas ASP”); %>
<%= $variable; # Esto es una abreviatura de ”<% echo . . .” %>
178
CAPÍTULO 10. PHP
El método primero, <?php. . .?>, es el más conveniente, ya que permite
el uso de PHP en código XML como XHTML.
El método segundo no siempre está disponible. El formato corto de etiquetas está disponible con la función short_tags() (sólo PHP 3), activando
el parámetro del fichero de configuración de PHP short_open_tag, o compilando PHP con la opción —enable-short-tags del comando configure. Aunque
esté activa por defecto en php.ini-dist, se desaconseja el uso del formato de
etiquetas corto.
El método cuarto sólo está disponible si se han activado las etiquetas ASP en
el fichero de configuración.
10.3.2
Tipos de Datos
PHP soporta los ocho tipos primitivos.
Cuatro tipos escalares:
1. boolean
2. integer
3. float (número de punto flotante, también conocido como double)
4. string
Dos tipos compuestos:
1. array
2. object
Y finalmente dos tipos especiales:
1. resource
2. Null
10.3. REFERENCIA DEL LENGUAJE
10.3.3
179
Variables
En PHP las variables se representan con un signo de dólar seguido por el
nombre de la variable. El nombre de la variable es sensible a minúsculas y
mayúsculas.
Los nombres de variables siguen las mismas reglas que otras etiquetas en
PHP. Un nombre de variable válido tiene que empezar con una letra o un
carácter de subrayado (underscore), seguido de cualquier número de letras,
números y caracteres de subrayado. Como expresión regular se podría expresar
como: ’[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*’. 1
De forma predeterminada, las variables siempre se asignan por valor. Esto
significa que cuando se asigna una expresión a una variable, el valor completo
de la expresión original se copia en la variable de destino. Esto quiere decir
que, por ejemplo, después e asignar el valor de una variable a otra, los cambios
que se efectúen a una de esas variables no afectará a la otra.
PHP también ofrece otra forma de asignar valores a las variables: asignar
por referencia. Esto significa que la nueva variable simplemente referencia (en
otras palabras, “se convierte en un alias de” ó “apunta a”) la variable original.
Los cambios a la nueva variable afectan a la original, y viceversa.
<?php
$var = ’Roberto’;
$Var = ’Juan’;
echo ”$var, $Var”; // imprime ”Roberto, Juan”
$4site = ’aun no’; // inválido; comienza con un número
$_4site = ’aun no’; // válido; comienza con un carácter de subrayado
$täyte = ’mansikka’; // válido; ’ä’ es ASCII (Extendido) 228
?>
Para asignar por referencia, simplemente se antepone un signo ampersand
(&) al comienzo de la variable cuyo valor se está asignando (la variable fuente).
Por ejemplo, el siguiente segmento de código produce la salida ’Mi nombre es
1
$this es una variable especial que no puede ser asignada.
180
CAPÍTULO 10. PHP
Bob’ dos veces:
<?php
$foo = ’Bob’; // Asigna el valor ’Bob’ a $foo
$bar = &$foo; // Referenciar $foo vía $bar.
$bar = ”Mi nombre es $bar”; // Modificat $bar...
echo $foo; // $foo también se modifica.
echo $bar;
?>
Algo importante a tener en cuenta es que sólo las variables con nombre
pueden ser asignadas por referencia.
<?php
$foo = 25;
$bar = &$foo; // Esta es una asignación válida.
$bar = &(24 * 7); // Inválida; referencia una expresión sin nombre.
function test() {
return 25;
}
$bar = &test(); // Inválido.
?>
No es necesario inicializar variables en PHP, sin embargo, es una muy
buena práctica. Las variables no inicializadas tienen un valor predeterminado
de acuerdo a su tipo - FALSE, cero, una cadena vacía o una matriz vacía.
Depender del valor predeterminado de una variable sin inicializar es problemático al incluír un archivo en otro que use el mismo nombre de variable.
10.3. REFERENCIA DEL LENGUAJE
181
Variables variables
A veces es conveniente tener nombres de variables variables. Dicho de otro
modo, son nombres de variables que se pueden definir y usar dinámicamente.
Una variable normal se establece con una sentencia como:
<?php
$a = ’hola’;
?>
Una variable variable toma el valor de una variable y lo trata como el
nombre de una variable. En el ejemplo anterior, hola, se puede usar como el
nombre de una variable utilizando dos signos de dólar. Es decir:
<?php
$$a = ’mundo’;
?>
En este momento se han definido y almacenado dos variables en el árbol
de símbolos de PHP: $a, que contiene ”hola”, y $hola, que contiene ”mundo”.
Es más, esta sentencia:
<?php
echo ”$a ${$a}”;
?>
produce el mismo resultado que:
<?php
echo ”$a $hola”;
?>
esto quiere decir que ambas producen el resultado: hola mundo.
Variables Desde Fuentes Externas
Formularios HTML (GET y POST)
182
CAPÍTULO 10. PHP
Cuando se envía un formulario a un script PHP, las variables de dicho
formulario pasan a estar automáticamente disponibles en el script gracias a
PHP. Por ejemplo, consideremos el siguiente formulario:
Ejemplo 10.1 Variables de formulario simples:
<form action=”foo.php” method=”post”>
Nombre: <input type=”text” name=”username” /><br />
Email: <input type=”text” name=”email” /><br />
<input type=”submit” name=”submit” value=”¡Enviarme!” />
</form>
Dependiendo de su configuración y preferencias personales, existen muchas
maneras de acceder a los datos de formularios HTML. Algunos ejemplos:
Ejemplo 10.2 Acceso a datos de un formulario simple HTML POST:
<?php
// Disponible desde PHP 4.1.0
echo $_POST[’username’];
echo $_REQUEST[’username’];
import_request_variables(’p’, ’p_’);
echo $p_username;
// Ya no está disponible desde PHP 6. A partir de PHP 5.0.0, estas variables
// predefinidas largas pueden ser deshabilitadas con la directiva
// register_long_arrays.
echo $HTTP_POST_VARS[’username’];
// Disponible si la directiva de PHP register_globals = on. A partir de
// PHP 4.2.0 el valor predeterminado de register_globals = off.
10.3. REFERENCIA DEL LENGUAJE
183
// Usar o depender de este método no es recomendable.
echo $username;
?>
Usar un formulario GET es similar excepto en el uso de variables predefinidas, que en este caso serán del tipo GET. GET también se usa con
QUERY_STRING (la información despues del símbolo ’ ?’ en una URL). Por
ejemplo http://www.example.com/test.php?id=3 contiene datos GET que son
accesibles con $_GET [’id’].
10.3.4
Constantes
Una constante es un identificador para expresar un valor simple. Como el
nombre sugiere, este valor no puede variar durante la ejecución del script.
(Las constantes especiales __FILE__ y __LINE__ son una excepción a
esto, ya que actualmente no lo soin). Una constante es sensible a mayúsculas
por defecto. Por convención, los identificadores de constantes suelen declararse
en mayúsculas
El nombre de una constante sigue las mismas reglas que cualquier etiqueta
en PHP. Un nombre de constante válido empieza con una letra o un caracter
de subrayado, seguido por cualquier número de letras, números, o subrayados.
Se podrían expresar mediante la siguiente expresión regular: [a-zA-Z_\x7f\xff][a-zA-Z0-9_\x7f-\xff]*
Sintaxis
Se puede definir una constante usando la función define(). Una vez definida,
no puede ser modificada ni eliminada .
Solo se puede definir como constantes valores escalares (boolean, integer,
float y string ).
Para obtener el valor de una constante solo es necesario especificar su
nombre. A diferencia de las variables, no se tiene que especificar el prefijo
$. Tambien se puede utilizar la función constant(), para obtener el valor
de una constante, en el caso de que queramos expresarla de forma dinámica
usa la función get_defined_constants() parar obtener una lista de todas las
184
CAPÍTULO 10. PHP
constantes definidas.2
Si se usan constantes todavia no definidas, PHP asume que se está haciendo referencia al nombre de la constante en si. Se lanzará un error de nivel
E_NOTICE si esto sucede. se debe usar la función defined() para comprobar
la existencia de dicha constante.
Estas son las diferencias entre constantes y variables:
• Las constantes no son precedidas por un símbolo de dolar ($)
• Las contantes solo pueden ser definidas usando la función() define , nunca
por simple asignación
• Las constantes pueden ser definidas y accedidas sin tener en cuenta las
reglas de alcanze del ámbito.
• Las constantes no pueden ser redefinidas o eliminadas despues de establecerse; y
• Las constantes solo puede albergar valores escalares.
Ejemplo 10.3 Definiendo Constantes:
<?php
define(”CONSTANT”, ”Hello world.”);
echo CONSTANT; // outputs ”Hello world.”
echo Constant; // outputs ”Constant” and issues a notice.
?>
Constantes predefinidas
PHP ofrece un largo número de constantes predefinidas a cualquier script en
ejecución. Muchas de estas constantes, sin embargo, son creadas por diferentes
extensiones, y solo estarán presentes si dichas extensiones están disponibles,
bien por carga dinámica o porque han sido compiladas.
2
Las contantes y las variables (globales) se encuentran en un espacio de nombres distinto.
Esto implica que por ejemplo TRUE y $TRUE son diferentes.
10.3. REFERENCIA DEL LENGUAJE
10.3.5
185
Operadores
La precedencia de un operador indica qué tan “cerca” se agrupan dos expresiones. Por ejemplo, en la expresión 1 + 5 * 3, la respuesta es 16 y no 18,
ya que el operador de multiplicación (“*”) tiene una mayor precedencia que
el operador de adición (“+”). Los paréntesis pueden ser usados para marcar
la precedencia, si resulta necesario. Por ejemplo: (1 + 5) * 3 evalúa a 18.
Si la precedencia de los operadores es la misma, se utiliza una asociación de
izquierda a derecha.
En la tabla 10.1 de la pág.186 se muestra una lista de las precedencias de
los operadores, con aquellos de mayor precedencia listados al comienzo de la
tabla. Los operadores en la misma línea tienen la misma precedencia, en cuyo
caso su asociatividad decide el orden para evaluarlos.
Existen operadores de aritmética, de asignación, bit a bit, de comparación, de control de errores de ejecución, de incremento/decremento, de lógica,
cadenas, matrices y de tipo.
Un operador es algo a lo que usted entrega uno o más valores (o expresiones,
en jerga de programación) y produce otro valor (de modo que la construcción
misma se convierte en una expresión). Así que puede pensar sobre las funciones
o construcciones que devuelven un valor (como print) como operadores, y en
aquellas que no devuelven nada (como echo) como cualquier otra cosa.
Existen tres tipos de operadores:
En primer lugar se encuentra el operador unario, el cual opera sobre un
único valor, por ejemplo (el operador de negación) o ++ (el operador de
incremento).
El segundo grupo se conoce como operadores binarios; este grupo contiene
la mayoría de operadores que soporta.
El tercer grupo consiste del operador ternario: ?:. Éste debe ser usado para
seleccionar entre dos expresiones, en base a una tercera, en lugar de seleccionar
dos sentencias o rutas de ejecución. Rodear las expresiones ternarias con
paréntesis es una muy buena idea.
186
CAPÍTULO 10. PHP
Figura 10.1: Precedencia de Operadores
10.3. REFERENCIA DEL LENGUAJE
10.3.6
187
Estructuras de Control
Todo script PHP se compone de una serie de sentencias. Una sentencia puede
ser una asignación, una llamada a función, un bucle, una sentencia condicional
e incluso una sentencia que no haga nada (una sentencia vacía). Las sentencias
normalmente acaban con punto y coma. Además, las sentencias se pueden
agrupar en grupos de sentencias encapsulando un grupo de sentencias con
llaves. Un grupo de sentencias es también una sentencia.
Algunas de las sentencias que control son: if, else, elseif, while, do..while,
for, foreach, break, continue, switch, declare, return, require, include, require_once, include_once.
Estructura IF
[10]IF es una estructura de control utilizada para tomar decisiones según
se cumpla una condición (o varias) o no. Su estructura básica es la siguiente:
if(condición/es){
acción a realizar;
}
else{
acción a realizar en caso de que no se cumpla;
}
Ejemplo básico:
if($edad>=18){
Comprar cerveza;
}
else{
echo ”No puedes comprar cerveza porque no tienes 18 años”;
}
e incluso se puede realizar condicionales mas completas como el siguiente
caso:
188
CAPÍTULO 10. PHP
if(($edad>=18)&&($dinero>0)){
Puedes comprar cerveza porque tienes 18 y tu dinero es mayor que 0;
}
else{ echo ”O no tienes dinero o no tienes los 18” ;
}
Estructura SWITCH
Toma distintas decisiones en función de distintos estados de la variable.
Su sintaxis es la siguiente:
switch(expresión){ case valor1:
sentencia a ejecutar cuando la expresión tiene como valor valor1
break
case valor2:
sentencia a ejecutar cuando la expresión tiene como valor valor2
break
case valor3:
sentencia a ejecutar cuando la expresión tiene como valor valor3
break
default:
sentencia que se ejecutar por defecto cuando no se cumpla ninguna de las condiciones anteriores
Bucle FOR
El bucle for se usa para repetir una misma operación un número determinado de veces. Su sintaxis es la siguiente:
for(inicialización;condición;actualización){
10.3. REFERENCIA DEL LENGUAJE
189
sentencia a ejecutar mientras se cumpla la condición
}
El bucle for esta compuesto de 3 partes:
• Inicialización: Se ejecuta tan solo al iniciar por primera vez el bucle.En
esta parte se suele colocar la variable que contara el numero de veces
que se repite el bucle.
• Condición: Es la condición que se evaluara cada vez que se inicie el
bucle.Esta condición es la que determina la duración del bucle.
• Actualización: Sirve para indicar los cambios que queremos ejecutar en
las variables cada vez que se ejecuta el bucle.
Un ejemplo de su uso seria el siguiente:
for($i=1;i<=10;i++){
echo ”El número actual es”.$i;
}
De esta forma escribiría todos los números contenidos entre 0 y 10.
Bucles WHILE y DO WHILE
Bucle WHILE
Este bucle se usa cuando queremos repetir la ejecución de unas sentencias
un número indefinido de veces. Su sintaxis es la siguiente:
while(condición){
sentencia a ejecutar
}
Para entender mejor el uso de while nos serviremos del siguiente ejemplo:
while($color != ”rojo”){
color= dame un color;
190
CAPÍTULO 10. PHP
}
Este es un ejemplo de lo que se puede hacer con while. En este caso siempre
y cuando el color no sea rojo nos dirá que introduzcamos un color.
Bucle DO...WHILE
Este bucle se usa cuando no sabemos el número de veces que va a ejecutarse
un bucle pero lo que si tenemos claro es que por lo menos una vez si que se
ejecutara la accion.Su sintaxis es la siguiente:
do{
sentencia del bucle
}while(condicion)
BREAK y CONTINUE
BREAK
Se usa para detener el bucle y dejar de interpretar el código que sigue
después de el break
CONTINUE
Sirve para volver al principio del bucle desde cualquier parte del bucle.
10.3.7
Funciones en PHP
Una de las herramientas mas importantes en cualquier lenguaje de programación son las funciones. Una función consiste en un conjunto de rutinas y
acciones que a lo largo del script van a ser ejecutadas multitud de veces agrupados en una FUNCION y desde cualquier punto del script puede ser llamada
y ejecutada. A su vez, esta función puede recibir parámetros externos de los
cuales dependa el resultado de una función.
Las funciones deben ser colocadas siempre antes de realizar la llamada a
la función (como es lógico). La sintaxis de una función es la siguiente:
10.3. REFERENCIA DEL LENGUAJE
191
function nombre(parámetros){
instrucciones de la función
}
para llamar a la función sería de la siguiente forma:
nombre(parámetros)
Un ejemplo para entender el uso de funciones es el siguiente:
Crear una función que realice la suma de dos números y muestre el resultado
function sumar($sumando1,$sumando2){
$ suma=$sumando1+$sumando2
echo $sumando1.”+”.$sumando2.”=”.$suma;
}
sumar(5,6)
Un hecho relevante que cabe destacar es que las variables que se declaran
dentro de la función solo existirán o tendrán dicho valor dentro de la función.
Existen casos en los cuales no se sabe el número de parámetros que serán
pasados a la función y en estos casos se deben usar las funciones creadas al
efecto como son:
func_num_args() Numero de parámetros que se le han pasado a la función
func_get_args() Devuelve un elemento de los que forman la lista de argumentos
Capítulo 11
Sistema de Gestión de Base
de Datos
11.1
¿Por qué MySQL?
MySQL es un sistema gestor de base de datos muy utilizado en la actualidad
por, entre otros, los siguientes motivos:
• Rapidez.
• Posibilidad de trabajar en diferentes plataformas.
• Múltiples formatos de tablas para cada necesidad.
• Seguridad.
• Gran estabilidad.
• Administración simple.
• Soporte técnico (con el licenciamiento comercial).
Desde hace algún tiempo, se ha ido dando una particular unión entre esta
base de datos y el lenguaje de programación PHP, por ese motivo MySQL se
utiliza mayormente en sitios Web.
193
194
CAPÍTULO 11. SISTEMA DE GESTIÓN DE BASE DE DATOS
11.1.1
Obtención de MySQL
MySQL puede obtenerse de forma completamente libre a través de cualquier
tipo de distribución: revistas, Internet, copias de CD provistas por amigos,
etcétera.
Pero sin dudas una de las formas más utilizadas es acceder al sitio en
Internet de MySQL (www.mysql.com) y desde allí descargar la versión más
adecuada con respecto al sistema sobre el cual desarrollamos nuestras aplicaciones. Esta es una buena forma de tener acceso a la última versión del
programa.
MySQL esta disponible, entre otros, para los siguientes sistemas operativos:
• Linux
• Windows (9x, Me, NT, 2000, XP)
• Solaris
• BSD (FreeBSD, NetBSD, OpenBSD, BSD/OS)
• Mac OS X
• Novell NetWare (6.0 o superior)
• OS/2
• BeOS
• RISC OS
• SGI IRIX 6.5x
• AS/400
11.2
Principales Características
• Portabilidad y parte interna
— Escrito en C y C++; testeado en un amplio rango de compiladores
diferentes.
11.2. PRINCIPALES CARACTERÍSTICAS
195
— Trabaja sobre diferentes plataformas
— APIs para C, C++, Eiffel, Java, Perl, PHP y Pyton
— Multithreaded, lo que significa que puede utilizar múltiples CPUs
si están disponibles.
— Tablas B-tree muy veloces con compresión de indices
— Joins de tablas muy veloces
— Tablas hash residentes en memoria; se usan como tablas temporales
— Las funciones de SQL se implementan mediante una biblioteca de
clases muy optimizada.
• Tipos de Datos
— Muchos tipos de columnas soportados: enteros con signo y sin signo
de 1, 2, 3, 4 y 8 bytes, FLOAT, DOUBLE, CHAR, VARCHAR,
TEXT, BLOB, DATE, TIME, DATETIME, TIMESTAMP, YEAR,
SET y ENUM.
— Registros de longitud fija y variable
— Todas las columnas tiene valores por omisión
— Comandos y Funciones
— Soporte de función y operador tanto en el SELECT como en el
WHERE..Por ejemplo:
mysql> SELECT CONCAT(nombre, ” ”, apellido)
FROM nombre_tabla
WHERE ingresos > 1000 and edad > 30;
— Soporte completo de cláusulas GROUP BY y ORDER BY.
— Soporta funciones de grupo: COUNT( ), COUNT(DISTINCT ),
AVG( ), STD( ), SUM( ), MAX( ), MIN( ).
— Soporta outer join (sintaxis ANSI SQL y ODBC)
— Se permiten alias de tablas y columnas como en el estándar SQL92.
— Las sentencias DELETE, INSERT, UPDATE, REPLACE devuelven el número de filas que fueron cambiadas (afectadas).
196
CAPÍTULO 11. SISTEMA DE GESTIÓN DE BASE DE DATOS
— El comando (específico de MySQL) puede se usado para recuperar
información sobre bases de datos, tablas e índices. El comando
EXPLAIN se usa para determinar cómo resuelve una consulta el
optimizador.
— Los nombres de funciones no generan conflictos con nombres de
columnas o tablas. Por ejemplo, ABS es un nombre válido de columna. La única restricción es que a un llamado de función siga
inmediatamente un ’(’.
— Se pueden mezclar tablas de diferentes bases de datos en la misma
consulta.
• Seguridad
— Un sistema de passwords y privilegio, muy flexible y seguro, y que
permite verificación basada en host. Las passwords son seguras
porque todo el tráfico de claves se encripta al conectarse al servidor.
• Escalabilidad y Límites
— Maneja grandes bases de datos (se puede citar usuarios con bases
de datos de 50.000.000 de registros, otros que usan 60.000 tablas).
— Se permiten hasta 32 índices por tabla. Cada índice puede consistir
de 1 a 16 columnas. La amplitud máxima de índice es de 500 bytes.
• Conectividad
Los clientes pueden conectarse al Servidor usando:
— Sockets TCP/IP
— Sockets UNIX
— Named Pipes (NT)
— Soporte ODBC para Win32
• Parámetros locales
— El servidor puede proveer mensajes de error a los clientes en muchos
idiomas.
— Completo soporte para diferentes juegos de caracteres, incluyendo
ISO-8859-1 (Latin), alemán, ujis, y otros.
11.3. TIPOS DE DATOS
197
— Todos los datos son salvados en el juego de caracteres elegido.
— El ordenamiento (sort) es realizado de acuerdo con el juego de caracteres elegido.
• Clientes y herramientas
Incluye myisamchk, un utilitario muy veloz que permite chequear, optimizar y reparar tablas. Toda la funcionalidad de mysiamchk también está
disponible a través de la interface SQL.
11.3
Tipos de Datos
Se utilizan para definir los tipos de datos de las columnas de una tabla al
crearla. MySQL sopota una gran variedad de datos, uno para cada necesidad.
11.3.1
Cadena de Caracteres
Los subtipos de datos existentes aquí son CHAR, VARCHAR, BLOB, TEXT,
ENUM, y SET.
CHAR y VARCHAR
Son muy similares, quizás la diferencia mas notable es la forma de almacenamiento: cuando definimos una columna tipo CHAR de tamaño N, e
ingresamos un valor (de menos de N caracteres) en esa columna, MySQL rellenará con espacios lo que sobra, mientras que si hacemos lo mismo con una
columna de tipo VARCHAR, en este caso no se rellenara con espacios. Cuando obtenemos información a través de una consulta SQL, no obtenemos los
espacios sobrantes: MySQL los remueve. Si se ingresa una cadena de mayor
cantidad de caracteres que el tamaño prefijado al definir la columna, la cadena
se truncara al límite.
Por defecto, las comparaciones (en cualquiera de los dos tipos de datos)
son insensibles a mayúsculas y minúsculas.
198
CAPÍTULO 11. SISTEMA DE GESTIÓN DE BASE DE DATOS
BLOB y TEXT
Se usan para cadenas con un rango que dependerá del tamaño que queramos almacenar.
La diferencia entre ambos es que TXT permite comparar dentro de su
contenido sin distinguir mayúsculas y minúsculas, y BLOB las distingue. Otra
diferencia podría ser su uso, TXT tiende a ser usado para cadenas de texto
plano (sin formato) mientras que BLOB se usa para objetos binarios, o sea
cualquier tipo de datos o información, desde un archivo de texto con todo su
formato hasta imágenes, archivos de sonido o video.
BLOB (es un acronimo de Binary Large OBjet, objeto binario de gran
tamaño) se subdivide en cuatro tipos que difieren solo en la capacidad maxima
de almacenamiento.
Con TEXT sucede lo mismo e incluso, hay correspondencia entre la capacidad máxima de almacenamiento de unos y otros.
11.3. TIPOS DE DATOS
199
Divisiones de Blob
TinyBlob
Blob
MediumBlob
LongBlob
Divisiones de Text
TinyText
Text
MediumText
LongText
Limite de carateres
255
65535
16777215
4294967295
Tabla 11.1: BloB y Text
Enum
Este tipo puede seleccionar su valor únicamente de una lista finita (máxima
de 65.535 elementos) de opciones definidas por el usuario, y otras dos por
defecto (índice 0 que significa error-por ingresos fuera de rango, por ejemploy esta representado por ””, e índice NULL). Por ejemplo:
Definiendo columna de tipo ENUM (”argentina”, ”mexico”, ”paraguay”):
CREATE TABLE user (
nombre enum (’juan’, ’pedro’) NOT NULL,
200
CAPÍTULO 11. SISTEMA DE GESTIÓN DE BASE DE DATOS
pais enum (’argentina, ’paraguay’, ’mexico’),
};
SET
Similar a ENUM en su funcionamiento, solo que que aquí se puede seleccionar ninguno o mas de un valor de la lista (hasta 64, los muestra separados
por comas).
Al ser ENUM semejante a una lista podemos realizar consultas tales como:
SELECT * FROM nom_tabla WHERE set_col LIKE ’%values%’;
SELECT * FROM nom_tabla WHERE set_col = ’val1, val2’;
Donde val1 y val2 son opciones de la lista.
11.3.2
Numéricos
Se definen los subtipos DECIMAL (o NUMERIC, o DEC), INTEGER (o
INT), TINYINT, BIT, BOLL, MEDIUMINT, BIGINT, SMALLINT, FLOAT,
y DOUBLE (o DOUBLE PRECISION, o REAL).
Todos los tipos numéricos pueden definirse en dos parámetros opcionales:
UNSIGNED (impide que los campos numéricos acepten signos negativos, es
decir, solo se aceptaran el cero y los valores positivos) y ZEROFILL (completa
con ceros a la izquierda hasta la longitud máxima). La forma de uso es:
TIPO_DATO [UNSIGNED] [ZEROFILL]
POR EJEMPLO,
INT(4) UNSIGNED ZEROFILL
Si tenemos almacenado el numero 12, al hacer un SELECT se mostrara
0012. Si tenemos almacenado el numero -12, al hacer un SELECT se mostrara
0000.
11.3. TIPOS DE DATOS
201
TinyInt[(M)]
M es el número de dígitos que serán visibles al mostrar el contenido del
campo. Si el campo que se va a mostrar sobrepasa los M dígitos, se mostraran
M dígitos.Si se omite o se sobrepasa la capacidad de TINYINT, se toma la
cantidad máxima soportada por este tipo de dato.
Si se define con signo va desde -128 a 127. Sin signo (UNSIGNED) va
desde 0 hasta 255.
Bit
Es un TINYINT de un digito (TINYINT(1)).
Bool
202
CAPÍTULO 11. SISTEMA DE GESTIÓN DE BASE DE DATOS
Es un TINYINT de un digito (TINYINT(1)).
SmallInt
M es el número de dígitos que serán visibles al mostrar el contenido del
campo. Si el campo que se va a mostrar sobrepasa los M dígitos, se mostraran
M dígitos.
Si se omite o se sobrepasa la capacidad de SMALLINT, se toma la cantidad
máxima soportada por este tipo de dato.
Si se define con signo va desde -32768 a 32767. Sin signo (UNSIGNED) va
desde 0 hasta 65535.
MediumInt[(M)]
M es el campo de dígitos que serán visibles al mostrar el contenido del
campo. Si el campo que se va a mostrar sobrepasa los M dígitos, se mostraran
M dígitos. Si se omite o se sobrepasa la capacidad de SMALLINT, se toma la
cantidad máxima soportada por este tipo de dato.
Si se define con signo va desde -8388608 a 8388607. Sin signo (UNSIGNED)
va desde 0 hasta 16777215.
Int[(M)]
M es el campo de dígitos que serán visibles al mostrar el contenido del
campo. Si el campo que se va a mostrar sobrepasa los M dígitos, se mostraran
M dígitos. Si se omite o se sobrepasa la capacidad de SMALLINT, se toma la
cantidad máxima soportada por este tipo de dato.
11.3. TIPOS DE DATOS
203
Si se define con signo va desde -2147483648 a 2147483647. Sin signo (UNSIGNED) va desde 0 hasta 4294967295.
Integer[(M)]
Sinónimo de INT.
BigInt[(M)]
M es el campo de dígitos que serán visibles al mostrar el contenido del
campo. Si el campo que se va a mostrar sobrepasa los M dígitos, se mostraran
M dígitos. Si se omite o se sobrepasa la capacidad de SMALLINT, se toma la
cantidad máxima soportada por este tipo de dato.
Si se define con signo va desde -9223372036854775808 a 9223372036854775807.
Sin signo (UNSIGNED) va desde 0 hasta 18446744073709551615.
Todas las funciones matemáticas trabajan internamente con valores BIGINT.
Float[(M,D)]
Sirven para definir números con coma, con menos precisión que DOUBLE.
M es el número de dígitos que serán visibles al mostrar el contenido del
campo. Si el campo que se va a mostrar sobrepasa los M digitos, se mostraran
M digitos.
EL rango de posibles valores va de -3.402823466E+38 a -1.175494351E-38,
0, y desde 1.175494351E-38 hasta 3.402823466E+38.
Double Precision[(M,D)]
Sinónimo de DOUBLE.
Real[(M,D)]
Sinónimo de DOUBLE.
Decimal[(M[,D])]
Aquí el número es almacenado internamente como una cadena de caracteres
(un carácter por cada digito). Ni el separador decimal (,) ni el signo menos
(-) para números negativos son parte de M.
Si no se le da ningún argumento por defecto M es igual a 10, tomando un
204
CAPÍTULO 11. SISTEMA DE GESTIÓN DE BASE DE DATOS
rango de -9999999999 a 9999999999 para números con signo.
Y por defecto, D es igual a 0.
Dec[(M[,D])]
Sinónimo de DECIMAL.
11.4
Tipos de Tablas
Cuando se trabaja con MySQL existe la opción de poder variar el tipo de tabla
después de creada (salvo con las tablas del sistema llamadas MySQL y test,
que por defecto son MYISAM y no se recomienda modificarlas).
Para indicar el tipo de tabla al crearla usamos la siguiente sintaxis:
CREATE TABLE tabla1 (
Campo1 INT(4) UNSIGNED,
Campo2 VARCHAR(25) NOT NULL
) TYPE=MYISAM;
Si se omite la opción TYPE= por defecto se crea una tabla MYSAM.
La opción TYPE es soportada hasta la versión 4.x de MySQL (dejara de
usarse a partir de la 5). La opción ENGINE fue añadida en la versión 4.0.1.8
(para las series 4.x) y en la 4.1.2 (para las versiones 4.1), y será usada en lugar
de TYPE.
CREATE TABLE tabla2 (
Campo1 INT(4) UNSIGNED,
Campo2 VARCHAR(25) NOT NULL
) ENGINE=MYISAM;
Si se intenta crear un tipo de tabla no disponible en nuestra versión, MySQL optará por crear una tabla tipo MyISAM.
11.4. TIPOS DE TABLAS
11.4.1
205
ISAM
En un principio MySQL empezó utilizando este tipo de tablas y, actualmente,
se las considera en desuso.
Entre sus desventajas figura el hecho de no poder transportar ficheros
entre maquinas con distintas arquitectura (tiene un formato distinto para cada
arquitectura / sistema operativo, lo cual resulta mas rápido, pero presenta el
problema de la incompatibilidad) y el de no manejar ficheros de tablas a 4
Gigabytes.
Los índices se guardan en archivos .ISAM y los datos en archivos .ISD.
MySQL recomienda actualizar este tipo de tablas hacia las de tipo MyISAM,
esto puede hacerse con la siguiente instrucción SQL:
ALTER TABLE nombre_de_la_tabla TYPE = MYSAM;
11.4.2
MYSAM
Es el tipo de tabla por defecto en MySQL desde la versión 3.23 y esta basada
sobre las tablas ISAM, por supuesto que ofreciendo más opciones que éstas.
Cuando se usan estas tablas, los datos se almacenan físicamente en dos
archivos: uno que tiene la extensión .MYI (MYISAM INDEX) en donde se
almacenan los índices, y otro .MYD (MYISAM DATA) donde se almacenan
los datos.
Proveen un almacenamiento independiente: se pueden copiar tablas de una
maquina a otra de distinta plataforma.
Si estamos trabajando con MySQL en forma local, normalmente, se podrá
ver en el propio equipo que estos archivos se almacenan en una carpeta que
tiene por nombre una base de datos (estas carpetas están en el directorio data
dentro del directorio en donde se instalo MySQL, allí hay una carpeta por
cada base de datos). Esto vales también para otros tipos de tablas.
Además:
• Soportan archivos de gran tamaño (63 bits, ficheros d etablas superiores
a 4 Gigas) en comparación con los que soportaban las ISAM.
206
CAPÍTULO 11. SISTEMA DE GESTIÓN DE BASE DE DATOS
• Optimizadas para sistemas operativos de 64 bits.
• Posibilidad de indexar campos BLOB y TEXT.
• Se permiten valores NULL en columnas indexadas.
• Cada tabla guarda un registro que indica si fue cerrada correctamente o
no, y al iniciar MySQL existe la opción de indicarle que se verifique ese
registro, y se repare la tabla de ser necesario, de forma automática
• Si se encontro un error, trata de repararlo de forma rapida ordenando
los registros de la tabla. Si persiste el error, ahora se vuelve a crear el
archivo que contiene la tabla. Y si persiste el error, si intenta repararlo
escribiendo los registros sin un ordenamiento.
Las tablas diseñadas con la herramienta phpmyadmin son todas de tipo=MYISAM
11.4.3
BerkeleyDB
Estas tablas pueden ser usadas independientemente de MySQL: estan desarrolladas por otra empresa (Sleepycat) y MySQL ofrece una interfaz para trabajar
con ellas como una posibilidad más.
• Soportan operaciones COMMIT o ROLLBACK.
• Este tipo de TST (Transactions Safe Tables).
Normalmente, para instalarlas hay que buscar una versión de MySQL que
incluya soporte para este tipo de tablas, y habilitar la opción al momento de
la instalacion.
En el archivo en donde se guardan los datos tambien se guarda la ruta a
ese mismo archivo, de modo que no es posible cambiar la base de directorio.
11.4.4
InnoDB
Estas tablas, al igual que las BerkeleyDB, son TST: este término significa
Transactions Safe Tables, o tablas para transacciones seguras. Las tablas tipo
11.4. TIPOS DE TABLAS
207
TST son menos rápidas y ocupan mas memoria, pero a cambio ofrecen mayor
seguridad frente a fallos durante la consulta.
Además las tablas InnoDB tienen las siguientes características:
• Proveen la posibilidad de transacciones seguras. ACID (Atomicidad;
Consistencia; Separación, en ingles Isolation y Durabilidad).
• Atomicidad. Consultas tratadas como una sola, de tal forma que solo se
ejecutan cuando todas ellas tienen éxito, en caso de que alguna falle no
se ejecuta ninguna.
• Consistencia. Solo datos validos pueden ser escritos en la base de datos.
• Separación. Las transacciones que tengan lugar simultáneamente deben
ejecutarse aisladas unas de otras hasta que finalizan.
• Durabilidad. Cuando una transacción se completa exitosamente, los
cambios son permanentes y no se podrá volver atrás.
• Soporta operaciones COMMIT y ROLLBACK (beneficio propio de ser
TST)
Recuperación ante fallos.
• Soporta FOREGIN KEY (claves foráneas). Primera vez que se da esto
en MySQL.
• Bloqueo a nivel de fila.
• Permite realizar copias de seguridad mientras la base esta funcionando.
• Gran eficacia en el procesamiento de grandes volúmenes de información.
• No permite crear claves sobre columnas de tipo BLOB o TEXT.
• Una tabla no puede tener más de 1000 columnas.
• Al borrar todas las filas de una tabla las borra una por una -lo que produce problemas relacionados a la velocidad. Hasta ahora puede truncar
tablas.
208
CAPÍTULO 11. SISTEMA DE GESTIÓN DE BASE DE DATOS
11.4.5
¿En qué casos usar cada una?
Como siempre, la respuesta depende de lo que tengamos que hacer.
Las tablas que normalmente se usan hoy en día son las MyISAM, pero
pronto (quizás muy pronto) se comenzaran a usar las INNODB, especialmente
por la posibilidad de crear relaciones entre tablas (fundamental en el modelo
relacional) y ofrecer mayores prestaciones respecto de la seguridad, además de
las transacciones.
Las ISAM están prácticamente en desuso (incluso la empresa que desarrolla
MySQL admite la posibilidad de que en su versión 5 ya no estén disponibles),
y las demás tiene usos muy específicos e incluso compatibles con otros tipos:
la clave esta en estudiar los problemas que se necesita solucionar, y ver en
cada caso que conviene.
11.5
Seguridad
Un sistema de passwords y privilegio, muy flexible y seguro, y que permite
verificación basada en host. Las passwords son seguras porque todo el tráfico
de claves se encripta al conectarse al servidor.
Escalabilidad y Límites
Maneja grandes bases de datos (se puede citar usuarios con bases de datos
de 50.000.000 de registros, otros que usan 60.000 tablas).
Se permiten hasta 32 índices por tabla. Cada índice puede consistir de 1
a 16 columnas. La amplitud máxima de índice es de 500 bytes,
Conectividad
Los clientes pueden conectarse al Servidor usando:
• Sockets TCP/I
• Sockets UNIX
• Named Pipes (NT)
• Soporte ODBC para Win32
11.6. BACKUP DE BASE DE DATOS
11.6
209
Backup de Base de Datos
Este comando provisto por MySQL permite hacer una copia de los archivos
de las tablas sobre las cuales queremos hacer un backup.
Actualmente, solo admite trabajar con tablas de tipo MyISAM.
LA forma de utilizar este comando es escribiéndolo, desde el prompt de
MySQL se detalla en el siguiente código:
Mysql > backup table nombre_tabla to ruta;
Donde nombre_tabla es el nombre de la tabla (podemos ingresar mas de
una, separando los nombres con comas) y ruta es el directorio en donde se
guardara la copia.
Al terminar de ejecutar el comando podremos ver una tabla que nos dará
distintas informaciones acerca del estado de la operación (si fallo, si se realizo
con existo, advertencias, y demás).
Habrá un registro por cada tabla que hayamos dado como argumento al
comando.
Este comando bloquea la tabla sobre la que se esta haciendo una copia de
seguridad. Aquí aparece el problema potencial que podría surgir con respecto
a la consistencia de los datos, ya que cuando, por ejemplo, el comando se
dispone a realizar el backup de la ultima tabla, las anteriores podrían haber
cambiado.
mysql > backup table alumnos to ’c:\back’;
11.6.1
Conectar a MySQL desde PHP
En la primera línea del script nos encontramos con la función mysql_connect(),
que abre una conexión con el servidor MySQL en el Host especificado (en este caso la misma máquina en la que está alojada el servidor MySQL, localhost). También debemos especificar un usuario (nobody, root, etc.), y si fuera
necesario un password para el usuario indicado (mysql_connect(”localhost”,
”root”, ”clave_del_root”)). Si la conexión ha tenido éxito, la función mysql_connect() devuelve un identificar de dicha conexión (un número) que es
almacenado en la variable $link, sino ha tenido éxito, devuelve 0 (FALSE).
210
CAPÍTULO 11. SISTEMA DE GESTIÓN DE BASE DE DATOS
Con mysql_select_db() PHP le dice al servidor que en la conexión
$link nos queremos conectar a la base de datos mydb. Podríamos establecer
distintas conexiones a la BD en diferentes servidores, pero nos conformaremos
con una.
La siguiente función mysql_query(), es la que hace el trabajo duro,
usando el identificador de la conexión ($link), envía una instrucción SQL al
servidor MySQL para que éste la procese. El resultado de ésta operación es
almacenado en la variable $result.
Finalmente, mysql_result() es usado para mostrar los valores de los
campos devueltos por la consulta ($result). En este ejemplo mostramos los
valores del registro 0, que es el primer registro 0, que es el primer registro, y
mostramos el valor de los campos especificados.
<html>
<body>
<?php
$link = mysql_connect(”localhost”, ”root”);
mysql_select_db(”sis_exa”, $link);
$result = mysql_query(”SELECT * FROM usuarios”, $link);
echo ”Nombre: ”.mysql_result($result, 0, ”nombre”).”<br>”;
echo ”Usuario: ”.mysql_result($result, 0, ”usuario”).”<br>”;
echo ”Clave :”.mysql_result($result, 0, ”clave”).”<br>”;
echo ”E-Mail :”.mysql_result($result, 0, ”email”).”<br>”;
?>
</body>
</html>
Capítulo 12
Descripción de la Aplicación
12.1
Análisis
Se ha realizado un análisis para el desarrollo adecuado del trabajo realizado.
Este análisis utilizó como metodología la de UML (Lenguaje Unificado de
Modelado), y la herramienta elegida fue Entreprise Architect.
Se amplian en las siguientes secciones la definición de UML, y se agregan
contenidos de la herramienta CASE seleccionada.
12.1.1
UML (Lenguaje Unificado de Modelado)
¿Qué es UML?
El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones
y diagramas estándar para modelar sistemas orientados a objetos, y describe
la semántica escencial de lo que estos diagramas y símbolos significan.
Mientras que han habido muchas notaciones y métodos usados para el
diseño orientado a objetos, ahora los modeladores sólo tienen que aprender
una única notación.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de
tware, sistemas de hardware, y organizaciones del mundo real.
211
212
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
UML ofrece nueve diagramas en los cuales modelar: sistemas.
• Diagramas de Casos de Uso para modelar los procesos ”business”.
• Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
• Diagramas de Colaboración para modelar interacciones entre objetos.
• Diagramas de Estado para modelar el comportamiento de los objetos en
el sistema.
• Diagramas de Actividad para modelar el comportamiento de los Casos
de Uso, objetos u operaciones.
• Diagramas de Clases para modelar la estructura estática de las clases en
el sistema.
• Diagramas de Objetos para modelar la estructura estática de los objetos
en el sistema.
• Diagramas de Componentes para modelar componentes.
• Diagramas de Implementación para modelar la distribución del sistema.
UML es una consolidación de muchas de las notaciones y conceptos más
usadas orientados a objetos. Empezó como una consolidación del trabajo de
Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las
metodologías orientadas a objetos más populares.
En 1996, el Object Management Group (OMG), un pilar estándar para la
comunidad del diseño orientado a objetos, publicó una petición con propósito
de un metamodelo orientado a objetos de semántica y notación estándares.
UML, en su versión 1.0, fue propuesto como una respuesta a esta petición
en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso
de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron
al OMG un documento revisado de UML, llamado UML versión 1.1.
Este documento fue aprobado por el OMG en Noviembre de 1997. El OMG
llama a este documento OMG UML versión 1.1. Así comenzó UML a ocupar
su lugar en la sociedad del diseño orientado a objetos mejorando su versión
gradualmente.
12.1. ANÁLISIS
213
UML ofrece notación y semántica estándar
UML es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema.
Previamente, un diseño orientado a objetos podría haber sido modelado
con cualquiera de la docena de metodologías populares, causando a los revisores tener que aprender las semáticas y notaciones de la metodología empleada
antes que intentar entender el diseño en sí.
Ahora con UML, diseñadores diferentes modelando sistemas diferentes pueden sobradamente entender cada uno los diseños de los otros.
UML no es un Método
Aun así, UML no preescribe un proceso o método estándar para desarrollar
un sistema. Hay varias metodologías existentes; entre las más populares se
incluyen las siguientes:
• Catalysis: Un método orientado a objetos que fusiona mucho del trabajo reciente en métodos orientados a objetos, y además ofrece técnicas
específicas para modelar componentes distribuidos.
• Objetory: Un método de Caso de Uso guiado para el desarrollo, creado
por Ivar Jacobson.
• Shlaer/Mellor : El método para diseñar sistemas de tiempo real, puesto
en marcha por Sally Shlaer y Steven Mellor, quienes continúan actualizando su método continuamente.
• Fusion: Desarrollado en Hewlett Packard a mediados de los noventa como primer intento de un método de diseño orientado a objetos estándar.
Combina OMT y Booch con tarjetas CRC y métodos formales.
• OMT: La Técnica de Modelado de Objetos fue desarrollada por James
Rumbaugh y otros, y publicada en el libro de gran infuencia ”Diseño
y Modelado Orientado a Objetos”. Un método que propone análisis y
diseño ”iterative”, más centrado en el lado del análisis.
• Booch: Parecido al OMT, y también muy popular.
214
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
Además, muchas organizaciones han desarrollado sus propias metodologías
internas, usando diferentes diagramas y técnicas con orígenes varios.
Ejemplos son el método Catalyst por Computer Sciences Corporation (CSC)
o el Worlwide Solution Design and Delivery Method (WSDDM) por IBM. Estas metodologías difieren, pero generalmente combinan análisis de flujo de
trabajo, captura de los requisitos, y modelado de negocio con modelado de
datos, con modelado de objetos usando varias notaciones (OMT, Booch, etc),
y algunas veces incluyendo técnicas adicionales de modelado de objetos como
Casos de Uso y tarjetas CRC. La mayoría de estas organizaciones están adoptando e incorporando el UML como la notación orientada a objetos de sus
metodologías.
Algunos modeladores usarán un subconjunto de UML para modelar ”what
they’re after”, por ejemplo simplemente el diagrama de clases, o solo los diagramas de clases y de secuencia con Casos de Uso. Otros usarán una swite
más completa, incluyendo los diagramas de estado y actividad para modelar
sistemas de tiempo real, y el diagrama de implementación para modelar sistemas distribuidos. Aun así, otros no estarán satisfechos con los diagramas
ofrecidos por UML, y necesitarán extender UML con otros diagramas como
modelos relacionales de datos y ”CRC cards”.
Una vuelta por un caso de uso
Una vez más, UML es una notación, no un método.
UML por incluir los diagramas de casos de uso, se le considera estar dotado
de una aproximación al diseño centrada en el problema con los casos de uso.
El Diagrama de Caso de Uso nos da el punto de entrada para analizar los
requisitos del sistema, y el problema que necesitamos solucionar.
Modelado de Casos de Uso
El modelado de Casos de Uso es la técnica más efectiva y a la vez la más
simple para modelar los requisitos del sistema desde la perspectiva del usuario.
Los Casos de Uso se utilizan para modelar cómo un sistema o negocio funciona
actualmente, o cómo los usuarios desean que funcione. No es realmente una
aproximación a la orientación a objetos; es realmente una forma de modelar
procesos.
Es, sin embargo, una manera muy buena de dirigirse hacia el análisis de
sistemas orientado a objetos. Los casos de uso son generalmente el punto de
12.1. ANÁLISIS
215
partida del análisis orientado a objetos con UML.
El modelo de casos de uso describe la funcionalidad propuesta del nuevo
sistema. Un caso de uso representa una unidad discreta de interacción entre
un usuario (humano o máquina) y el sistema.
Es una unidad simple de trabajo significativo; por ejemplo, ”Registrarse en
el sistema”, ”Logearse en el Sistema”, ”Modificar Preguntas’ son todos casos
de uso.
Actores: Un actor es un usuario del sistema. Incluye usuarios humanos y
otros sistemas computarizados. Un actor usa un caso de uso para desempeñar
alguna porción de trabajo que es de valor para el negocio. El conjunto de
casos de uso al que un actor tiene acceso define su rol global en el sistema y
el alcance de su acción.
Incluye:
• Pre-condiciones que deben ser verdaderas antes de que el caso de uso
se ejecute, por ejemplo, ”Registrarse en el Sistema” debe preceder
a ”Modificar Preguntas”.
• Post-condiciones que deben ser verdaderas una vez que el caso de
uso se ejecutó, por ejemplo ”La pregunta ha sido modificada”.
Organización de Diagramas de Casos de Uso Durante el análisis de negocio
(business) del sistema, se puede desarrollar un modelo de caso de uso para este
sistema, y construir paquetes para representar los varios dominios de negocio
(business) del sistema.
Se puede descomponer cada paquete con un Diagrama de Caso de Uso que
contenga los Casos de Uso de un dominio, con interacciones de actor.
Analizando el sistema de autoevaluación, consideramos al profesor y al
alumno como los actores, en esta situación el diagrama se presentaría según
la Fig. 12.1 de la pág. 216
Cada caso de uso para un actor se presentaría como la Fig.12.2 de la pág.
216 lo muestra para el profesor, donde el caso de uso es ”Registrarse en el
Sistema”.
216
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
Figura 12.1: Diagrama de Casos de Usos-Actores
Figura 12.2: Diagrama de Casos de Uso-Caso de Uso
12.1. ANÁLISIS
12.1.2
217
Herramienta CASE (Ingeniería de Software Asistida
por Computador): Entreprise Architect
Es una herramienta que combina el poder de la última especificación UML
2.1 con alto rendimiento, interfaz intuitiva, para traer modelado avanzado al
escritorio, y para el equipo completo de desarrollo e implementación. Presenta
un amplio conjunto de caracterísitcas.
Enterprise Architect complementa a un equipo de trabajo, como ser analistas, evaluadores, administradores de proyectos, personal del control de calidad,
equipo de desarrollo y otros.
Sus principales características:
• Alta capacidad
Enterprise Architect es una herramienta comprensible de diseño y análisis
UML, cubriendo el desarrollo de software desde el paso de los requerimientos a través de las etapas del análisis, modelos de diseño, pruebas y mantenimiento.
EA es multi-usuario.
Diseñada para ayudar a construir software robusto y fácil de mantener.
Ofrece salida de documentación flexible y de alta calidad. El manual de
usuario está disponible en línea.
• Velocidad, estabilidad y buen rendimiento
El Lenguaje Unificado de Modelado provee beneficios significativos para
ayudar a construir modelos de sistemas de software rigurosos y donde es posible
mantener la trazabilidad de manera consistente. Enterprise Architect soporta este proceso en un ambiente fácil de usar, rápido y flexible.
• Trazabilidad de extremo a extremo
218
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
Enterprise Architect provee trazabilidad completa desde el análisis de requerimientos hasta los artefactos de análisis y diseño, a través de la implementación y el despliegue. Combinados con la ubicación de recursos y tareas
incorporados, con esto las áreas de Administradores de Proyectos y Calidad estarías contarían con la información que ellos necesitan para entregar proyectos
en tiempo y forma.
• Construido sobre las bases de UML 2.1
Las bases de Enterprise Architect están construidas sobre la especificación
de UML 2.0 y usa sus perfiles para extender el dominio de modelado, mientras que la Validación del Modelo asegura integridad. Combina Procesos de
Negocio, Información y Flujos de trabajo en un modelo.
• Soporte para los todos diagramas de UML.
— Diagramas Estructurales:
∗
∗
∗
∗
∗
∗
Clase
Objeto
Compuesto
Paquete
Componente
Despliegue
— Diagramas de Comportamiento:
∗
∗
∗
∗
∗
∗
∗
Casos de Uso
Comunicación
Secuencia
Descripción de la Interacción
Actividad
Estado
Tiempo
— Extendidos:
∗ Análisis (actividad simple)
∗ Personalizado (para requisitos, cambios, UI)
12.1. ANÁLISIS
219
Figura 12.3: Actor
Figura 12.4: Caso deUso - Enterprise Arquitect
Es una herramienta que ayuda a administrar la complejidad con otras herramientas para rastrear las dependencias, soporte para modelos muy grandes,
Líneas Base por cada punto del tiempo.
Entreprise Architect diagramando un Caso de Uso
Los actores se representan como muñecos, Fig.12.3 de la pág. 219. Los
casos de uso en elipses, Fig. 12.4 de la pág. 219.
Cada caso de uso tiene una descripción que describe la funcionalidad que
se construirá en el sistema propuesto. Un caso de uso puede ”incluir” la
funcionalidad de otro caso de uso o ”extender” a otro caso de uso con su
propio comportamiento.
Un Caso de Uso puede incluir la funcionalidad de otro como parte de su
procesamiento normal.
Generalmente se asume que los casos de uso incluidos se llamarán cada vez
que se ejecute el camino base.
220
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
Un ejemplo puede ser un profesor que intentará modifcar las preguntas
de un exámen si se ha logeado en el sistema, en esta situaciòn el Caso de
Uso ”Modificar preguntas” estará incluido en el Caso de Uso ”Logear en el
Sistema”.
Un Caso de Uso puede ser incluido por uno o más casos de uso, ayudando
así a reducir la duplicación de funcionalidad al factorizar el comportamiento
común en los casos de uso que se reutilizan muchas veces.
Un Caso de Uso puede extender el comportamiento de otro Caso de Uso;
típicamente cuando ocurren situaciones excepcionales.
Por ejemplo, si el profesor desea consultar estadísticas de exámenes aprobados deberá primero ”Consultar Estadísticas”.
Observando el análisis del sistema de autoevaluación el Diagrama de Casos
de Uso según la Enterprise Architect se ve como lo muestra la Fig. 12.5 de la
pág. 221.
12.2
Desarrollo del Sistema
Para realizar el desarrollo de este trabajo se utilizó un software de base, previamente estudiado; que permite dasarrollar aplicaciones de tipo Web multiplataforma con acceso a base de datos.
Esta aplicación Web se refiere a la autoevaluación de alumnos sobre temas
referidos a Autonomic Computing.
Esta autoevaluación consistirá en cuestionarios tipo multiple choisse relacionados con temas sobre Autonimic Computing contenidos en la aplicación,
lo que nos permite definir a este trabajo también como Aplicación basada en
b-learning.
De esta manera se pretende que el alumno adquiera conocimientos sobre
ésta tecnología y pueda autoevaluarse, registrando y organizando la información en el momento del examen, de manera eficiente en una base de consulta
para el alumno y el profesor, quien podrá observar así el nivel del alumno, en
cada tema evaluado.
La Aplicación fue desarrollada en Php, correrá en la plataforma Windows
mediante el uso de software multiplataforma.
12.2. DESARROLLO DEL SISTEMA
Figura 12.5: Diagrama de Casos de Uso - Enterprise Arquitect
221
222
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
Figura 12.6: Inicio de la Aplicación
La página de inicio de sesión de la Aplicación se muestra en la Fig. 12.6
de la pág. 222.
Módulos del Sistema de Autoevaluación
El sistema consiste básicamente en tres módulos bien definidos:
1. Alumnos.
2. Administrador.
3. Apuntes.
El módulo de Alumnos
Contiene las opciones necesarias para el tratamiento específico de cada
alumno.
Estas opciones tienen el siguiente tratamiento en el sistema:
• Identificación del Alumno: Se refiere a la página donde el alumno debe
ingresar su usuario y clave para que se pueda verificar si existe o no.
12.2. DESARROLLO DEL SISTEMA
223
Figura 12.7: Menú de Alumno
Estas opciones tienen el siguiente tratamiento en el sistema: Fig.12.7 pág.
223
• Examen Virtual —> Comenzar examen: El alumno puede seleccionar un
tema para rendir, haya rendido o no previamente. Fig. 12.8 pág. 226
• Examen Virtual —> Ver promedio de notas: muestra un promedio de
calificaciones sobre el total de exámenes rendidos.
• Datos Personales —> Modificar: donde el alumno tiene la opción de ver
sus datos y actualizarlos si desea.
• Datos Personales —> Cambiar Clave: donde el alumno tiene la opción
de cambiar su clave personal.
• Ver Material: es la sección donde el alumno puede bajar el material de
lectura. Fig. 12.9 pág. 224
Las opciones que tiene un usuario con el perfil de Administrador son:
Fig.12.11 de la pág. 226
• Loguearse en el sistema con su nombre de usuario y clave.
224
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
Figura 12.8: Selección por Temas
Figura 12.9: Material de Lectura
12.2. DESARROLLO DEL SISTEMA
225
Figura 12.10: Agregar Tema Nuevo
• Administrar Temas: alta, baja, modificaciones. Fig. 12.10 de la pág.
225
• Administrar Preguntas: alta, baja, modificaciones.
• Administrar Respuestas: alta, baja, modificaciones. Fig.12.12 pág. 226
12.2.1
Estructuras de Datos Utilizadas
Las estructuras utilizadas por la aplicación y las distintas tablas utilizadas se
dan a conocer en esta sección, las mismas hacen uso del motor de base de
datos multiplataforma MySQL.
Tablas
• Usuarios: contiene la información necesaria referente a los usuarios registrados en el sistema. Está compuesta por los siguientes campos de
datos:
226
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
Figura 12.11: Menú del Administrador
Figura 12.12: Agregar Respuestas
12.2. DESARROLLO DEL SISTEMA
227
— Id: campo autonumérico
— user: contiene el nombre de usuario del sistema.
— pass: contiene la clave de acceso al sistema.
— nombre: contiene el nombre del usuario (alumno o profesor administrador).
— apellido: contiene el nombre del usuario (alumno o profesor administrador).
— matricula: número de libreta universitaria en caso de ser alumno,
número de legajo en caso de ser profesor.
— email: dirección de correo electrónico.
— nivel: campo identificador de nivel de acceso o tipo de usuario
(alumno o profesor administrador).
• Tema: Contiene la información referente a los distintos temas que conforman siguientes campos de datos:
— CODTEMA: Contiene el número de tema.
— DESC_TEMA: Contiene la descripción de el tema.
• Preguntas: Contiene la información referente a las distintas preguntas a
utilizar en los cuestionarios. Está compuesta por los siguientes campos
de datos:
— idp: Contiene un número autogenerado para las preguntas, que es
utilizado de clave por el sistema.
— codtema: Contiene el número de tema al que corresponde la pregunta.
— preguntas: Contiene la descripción de la pregunta.
• Respuestas: Contiene la información referente a las respuestas opcionales de cada pregunta que podría utilizarse en los cuestionarios. Está
compuesta por los siguientes campos de datos:
— idr: Contiene un número autogenerado para las distintas respuestas,
que el sistema utiliza de clave.
— idp: Contiene el número correspondiente a la pregunta a la cual
pertenece la respuesta.
228
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
— respuesta: descripción de la respuesta.
• Corresponde: Contiene la relación entre las preguntas con sus respuestas
verdaderas.
— si: contiene valor booleano verdadero o falso.
— idp
— idr
• Evaluacion: Contiene la información referente a los resultados obtenidos
por cada autoevaluación. Está compuesta por los siguientes campos de
datos:
— id: autonumérico.
— matricula
— fecha: fecha en que se hizo la autoevaluación.
— hora: hora en que se hizo la autoevaluación.
— tema
— nota: calificación obtenida en la autoevaluación.
12.2.2
Código Fuente Utilizados: Ejemplos
Alta login
<?php
@session_start();
if (isset($_SESSION[’id’])) {
$session = true;
include(”../Conex.php”);
$link = conectarse();
?>
<!— prueba Boton —>
<SCRIPT LANGUAGE=JAVASCRIPT1.2>
12.2. DESARROLLO DEL SISTEMA
229
function mOvrl(src) {
if (!src.contains(event.fromElement)) {
src.style.cursor = ’hand’;
}}
function mOutl(src) {
if (!src.contains(event.toElement)) {
src.style.cursor = ’default’;
}}
</script>
<?php
function boton($funsion,$leyenda)
{ ?>
<p style=”margin-top: 10; margin-bottom: 10”>
<table width=”141” height=”26” border=”0” cellpadding=”0” cellspacing=”0”>
<tr>
<td width=”5” height=”26” align=”left” valign=”top”>
<img src=”PIXEL.GIF” width=”5” height=”26”></td>
<td width=”696” align=”left” valign=”top”>
<table width=”136” height=”26” border=”0” cellpadding=”0” cellspacing=”0”>
<tr>
<td width=”30” height=”26” align=”left” valign=”top”>
<img src=”misc_inferior_01.gif” width=”30” height=”26”></td>
<td width=”102” height=”26” align=”left” valign=”top” background=”misc_inferior_02.gif”>
<table width=”100” height=”26” border=”0” cellpadding=”0” cellspacing=”0”>
230
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
<tr>
<td align=”center” onClick=”JavaScript:<?php print $funsion ?>” onMouseOut=”mOutl(this);”
onmouseover=”mOvrl(this);” valign=”middle” class=”texto4b”>
<font face=’Verdana’ color=”#FFFFFF” size=”1”><b> <?php print $leyenda
?></b></font></a></td>
</tr>
</table>
</td>
<td width=”20” height=”26” align=”left” valign=”top”>
<img src=”misc_inferior_03.gif” width=”34” height=”26”></td>
</tr>
</table>
</td>
</tr>
</table>
</p>
<?php }?>
<!— Fin prueba Boton —>
<body bgcolor= ”#FFFFFF”>
<center>
<table>
<body >
<div >
<div id=”topbar”>
12.2. DESARROLLO DEL SISTEMA
231
<center>
<table width=”100%” height=”60” bgcolor = ”white”>
<tr >
<td width=”5%” align=”left” height=”50”>
</td>
<td width=”80%” align=”right” height=”50”class=”banner”> <marquee direction=”left” class=”style9”>
<b>
<img border=”0” src=”logo.jpg”WIDTH=100 HEIGTH=50></td>
</font></b>
</marquee></td>
</tr>
</table>
</div>
<tr>
<td width=”100%” bgcolor=”#14BEBE” height=”58” colspan=”2”>
<p align=”center”><font face=”Arial” size=”2”>Administrador/a. </font>
<font face=’Verdana’ size=’2’ color=”#1A1AC4”><b> <?php echo $_SESSION[’nombre’].” ,
”. $_SESSION[’apellido’]?></b></font>
</td>
</tr>
</table>
<br><br>
<Font Size= 4 Color=black><center><b>Cargue los Datos del Usuario</b></center></font>
232
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
<br>
<FORM ACTION=”alta_login.php” METHOD=”POST”>
<table width=”99%” border=”0” align=”center” cellpadding=”3” cellspacing=”0”>
<tr>
<td width=”17%”>Nombre de Usuario</td>
<td width=”83%”>
<input name=”user” type=”text” id=”user” class=”color” style= ”background;
border: 1px solid #184297;”>
<span style=”color:#990000”>*</span></td>
</tr>
<tr>
<td>Contraseña</td>
<td>
<input name=”pass” type=”password” id=”pass” class=”color” style= ”background; border: 1px solid #184297;”>
<span style=”color:#990000”>*</span></td>
</tr>
<tr>
<td>Matricula</td>
<td>
<input name=”lu” type=”text” id=”lu” class=”color” style=”background; border: 1px solid #184297;”>
<span style=”color:#990000”>*</span></td>
</tr>
<tr>
<td>Email</td>
12.2. DESARROLLO DEL SISTEMA
233
<td>
<input name=”email” type=”text” id=”email” class=”color” style= ”background;
border: 1px solid #184297;”>
<span style=”color:#990000”>*</span></td>
</tr>
<tr>
<td>Nombre</td>
<td>
<input name=”nombre” type=”text” id=”nombre” class=”color” style= ”background; border: 1px solid #184297;”>
<span style=”color:#990000”>*</span></td>
</tr>
<tr>
<td>Apellido</td>
<td>
<input name=”apellido” type=”text” id=”apellido” class=”color” style= ”background; border: 1px solid #184297;”>
<span style=”color:#990000”>*</span></td>
</tr>
<tr>
<td height=”32”></td>
<td>
<input name=”registro” type=”submit” id=”registro” value=”Grabar”>
</td> <br><br> </tr>
<tr>
234
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
<td colspan=”2”><font size=”1” face=”Georgia, Times New Roman, Times,
serif”> (*) Registros Obligatorios </font></td>
</tr>
</table>
</form>
<?php
if ($HTTP_SERVER_VARS[’REQUEST_METHOD’] == ’POST’) {
$user =$_POST[user];
$pass = $_POST[pass];
$lu = $_POST[lu];
$nombre = trim($_POST[nombre]);
$apellido = Trim($_POST[apellido]);
$email = trim($_POST[email]);
require ”../funciones/funcion_validoemail.php”;
require ”../funciones/funcion_validonro.php”;
require ”../funciones/funcion_validoletra.php”;
if(empty($_POST[’user’])){
echo ”<font size=4 color=#000000><b>Error: </b></font>”;
echo”<font size=4 color=#000080>Debe Cargar el Nombre de Usuario</font><br>”;
$senia = 0;
}else{
if ((empty($_POST[’pass’])) || (empty($_POST[’nombre’])) || (empty($_POST[’apellido’]))
||
(empty($_POST[’lu’])) || (empty($_POST[’email’]))){
echo ”<font size=4 color=#000000><b>Error: </b></font>”;
12.2. DESARROLLO DEL SISTEMA
235
echo”<font size=4 color=#000080>Debe Completar los Campos: (*) Obligatorios para Grabar </font><br>”;
$senia = 0;
}else{
if (validoemail($email)== 0){
$senia = 0;
echo ”<center><b>”;
echo ”mail Incorrecto”;
echo ”</b></center>”;
echo ”<br>”;
}else{
if (validonro($lu)== false){
$senia = 0;
echo ”<center><b>”;
echo ”Matricula Debe ser Numerico”;
echo ”</b></center>”;
echo ”<br>”;
}else{
if (((validoletra($nombre)== false)) || ((validoletra($apellido)== false))){
$senia = 0;
echo ”<center><b>”;
echo ”Los Nombres o Apellidos No Pueden ser Numeros ”;
echo ”</b></center>”;
echo ”<br>”;
}else{
236
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
$consist = mysql_query(”select * from usuarios where matricula = ’$lu’ ”,$link);
if (mysql_num_rows($consist)!=0){
echo ”<font size=4 color=#000000><b>Error: </b></font>”;
echo”<font size=4 color=#000080>El Usuario ya Existe</font><br>”;
$senia = 0;
}else{
$sql=”INSERT INTO usuarios (user,pass,nombre,apellido,matricula, email,nivel,nivel_desc)”;
$sql.= ”VALUES (’$user’,’$pass’,’$nombre’,’$apellido’,’$lu’,’$email’,’1’,’Usuario’)”;
$rs = mysql_query($sql);
if (!$rs){
$x= mysql_error();
die(”<center><b>Ocurrio un Error en la base de Datos:”. $x.”</b></center>”);
}else{
$senia = 1;
echo ”<font size=4 color=#000000><b>Ok: </b></font>”;
echo ”<font size=4 color=#000080>Usuario Grabado con Exito</font><br>”;
}
}//Fin consist
}//fin valido nombre apellido
}//fin valido dni
}//fin valido EMAIL
}}
?>
<center>
12.2. DESARROLLO DEL SISTEMA
237
<FORM ACTION=”abm_login.php” METHOD=”POST”>
<INPUT TYPE=”submit” value=”Volver al Menu Usuarios” >
</form>
</center>
<br><br>
<?php
$con_det= mysql_query(”select * from usuarios order by apellido ”,$link);
if (mysql_num_rows($con_det)!=0){
echo”<table width=100% bordercolor = #FF0000 align=center>”;
echo”<tr bgcolor=#00AAD5>”;
echo”<td align=center><b><font color= #161695 size=2>Lu</font><b></td>”;
echo”<td align=center><b><font color= #161695 size=2> Apellido y Nombre
</font><b></td>”;
echo”<td align=center><b><font color= #161695 size=2>Email</font></b></td>”;
echo”<td align=center><b><font color= #161695 size=2>Usuario</font></b></td>”;
echo”<td align=center><b><font color= #161695 size=2>Password</font></b></td>”;
echo ”</tr>”;
while($det = mysql_fetch_array($con_det)){
if($det[’nivel’] == ’1’){
echo ”<tr bgcolor=#AAD4FF>”;
echo ”<td align=center><font size=2>”.$det[’matricula’].”</font></td>”;
echo ”<td align=left><font size=2>”.$det[’apellido’].”, ”.$det [’nombre’].”</font></td>”;
echo ”<td align=left><font size=2>”.$det[’email’].”</font></td>”;
echo ”<td align=left><font size=2>”.$det[’user’].”</font></td>”;
238
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
echo ”<td align=left><font size=2>”.$det[’pass’].”</font></td>”;
echo”</tr>”;
} //fin detalle nivel
}//fin while
echo”</table>”;
}
}else {//no hay post
$con_det= mysql_query(”select * from usuarios order by apellido ”,$link);
if (mysql_num_rows($con_det)!=0){
echo”<table width=100% bordercolor = #FF0000 align=center>”;
echo”<tr bgcolor=#00AAD5>”;
echo”<td align=center><b><font color= #161695 size=2>Lu</font><b></td>”;
echo”<td align=center><b><font color= #161695 size=2>Apellido y Nombre
</font> <b></td>”;
echo”<td align=center><b><font color= #161695 size=2>Email</font></b></td>”;
echo”<td align=center><b><font color= #161695 size=2>Usuario</font></b></td>”;
echo”<td align=center><b><font color= #161695 size=2>Password</font></b></td>”;
echo ”</tr>”;
while($det = mysql_fetch_array($con_det)){
echo ”<tr bgcolor=#AAD4FF>”;
echo ”<td align=center><font size=2>”.$det[’matricula’].”</font></td>”;
echo ”<td align=left><font size=2>”.$det[’apellido’].”, ”.$det[’nombre’].”</font></td>”;
echo ”<td align=left><font size=2>”.$det[’email’].”</font></td>”;
echo ”<td align=left><font size=2>”.$det[’user’].”</font></td>”;
12.2. DESARROLLO DEL SISTEMA
echo ”<td align=left><font size=2>”.$det[’pass’].”</font></td>”;
echo”</tr>”;
}//fin while
echo”</table>”;
}
}//fin autoproceso
mysql_close($link);
?>
</body>
<?
} else {
session_unset();
$session = false;
?>
<h1>No Tiene Permitido Acceder a la Pagina</h1>
<?
}
?>
</html>
Alta de una pregunta
<?php
@session_start();
if (isset($_SESSION[’id’])) {
239
240
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
$session = true;
include(”../Conex.php”);
$link = conectarse();
?>
<!— prueba Boton —>
<SCRIPT LANGUAGE=JAVASCRIPT1.2>
function mOvrl(src) {
if (!src.contains(event.fromElement)) {
src.style.cursor = ’hand’;
}
}
function mOutl(src) {
if (!src.contains(event.toElement)) {
src.style.cursor = ’default’;
}
}
</script>
<?php
function boton($funsion,$leyenda)
{ ?>
<p style=”margin-top: 10; margin-bottom: 10”>
<table width=”141” height=”26” border=”0” cellpadding=”0” cellspacing=”0”>
<tr>
<td width=”5” height=”26” align=”left” valign=”top”>
12.2. DESARROLLO DEL SISTEMA
241
<img src=”PIXEL.GIF” width=”5” height=”26”></td>
<td width=”696” align=”left” valign=”top”>
<table width=”136” height=”26” border=”0” cellpadding=”0” cellspacing=”0”>
<tr>
<td width=”30” height=”26” align=”left” valign=”top”>
<img src=”misc_inferior_01.gif” width=”30” height=”26”></td>
<td width=”102” height=”26” align=”left” valign=”top” background= ”misc_inferior_02.gif”>
<table width=”100” height=”26” border=”0” cellpadding= ”0” cellspacing=”0”>
<tr>
<td align=”center” onClick=”JavaScript:<?php print $funsion ?> ” onMouseOut=”mOutl(this);”
onmouseover=”mOvrl(this);” valign=”middle” class=”texto4b”>
<font face=’Verdana’ color=”#FFFFFF” size=”1”><b> <?php print $leyenda
?></b></font></a></td>
</tr>
</table>
</td>
<td width=”20” height=”26” align=”left” valign=”top”>
<img src=”misc_inferior_03.gif” width=”34” height=”26”></td>
</tr>
</table>
</td></tr>
</table>
</p>
<?php }?>
242
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
<!— Fin prueba Boton —>
<body bgcolor= ”#FFFFFF”>
<!— prueba titluo —>
<center>
<table>
<body >
<div >
<div id=”topbar”>
<center>
<table width=”100%” height=”60” bgcolor = ”white”>
<tr >
<td width=”5%” align=”left” height=”50”>
</td>
<td width=”80%” align=”right” height=”50”class=”banner”> <marquee direction=”left” class=”style9”>
<b>
<img border=”0” src=”logo.jpg”WIDTH=100 HEIGTH=50></td>
</font></b>
</marquee></td>
</tr>
</table>
</div>
<tr>
<td width=”100%” bgcolor=”#14BEBE” height=”58” colspan=”2”>
<p align=”center”><font face=”Arial” size=”2”>Administrador/a </font>
12.2. DESARROLLO DEL SISTEMA
243
<font face=’Verdana’ size=’2’ color=”#1A1AC4”><b><?php echo $_SESSION[’nombre’].” , ”. $_SESSION[’apellido’]?></b></font>
</td></tr>
</table><br><br>
<center>
<Font Size= 3 Color=black><center><b> Elija el Tema para Agregar la Pregunta </b></center></font>
<br><br>
<?
$param_tema =$_POST[’param_tema’];
?>
<form method=”post” action=”alta_pregunta.php”>
<br>
<table><tr><td><select name =”param_tema”>
<?
if ($HTTP_SERVER_VARS[’REQUEST_METHOD’] != ’POST’) {
$con_empre= mysql_query(”select * from tema ”,$link);
while($res_empre = mysql_fetch_array($con_empre)){
echo ”<option value = ”.$res_empre[’CODTEMA’].”>”;
echo $res_empre[’DESC_TEMA’].”</option>”;
} }else{
$id_empre=$_POST[’param_tema’];
$con_empre= mysql_query(” select * from tema ”,$link);
while($res_empre = mysql_fetch_array($con_empre)){
if ($id_empre == $res_empre[’CODTEMA’]) {
244
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
echo ”<option value=”.$res_empre[’CODTEMA’].” SELECTED> ” .$res_empre
[’DESC_TEMA’].”</option>”;
}else {
echo ”<option value=”.$res_empre[’CODTEMA’].”> ” .$res_empre [’DESC_TEMA’].”</option>”;
}}}
?>
</select></td>
</tr>
</table>
<br><br>
<center>
<INPUT TYPE=”submit” VALUE=”Consultar”>
</center>
</FORM>
<?
if (!(empty($_POST[’param_tema’]))){
?>
<FORM ACTION=”alta_pregunta.php” METHOD=”POST”>
<br><br>
<input type=”hidden” name=”param_tema” value=<? echo $param_tema ?>
>
<Font Size= 3 Color=”#0000AA”><center><b>Agregue Pregunta al Tema</b></center></font>
<br>
12.2. DESARROLLO DEL SISTEMA
245
<table width=”60%” align=”center”>
<tr>
<td><font size= 3 color =”#2D2DAD”><b>Descripcion  </b></font></td>
<td align=left><textarea rows =”3” cols = ”30” style=”overflow:auto; border:
1px solid #184297;”
name=”preg” id=”preg” class=”color” ></textarea></td>
</tr>
</table>
<center>
<br>
<INPUT TYPE=”submit” value=”Grabar” >
<INPUT TYPE=”reset” VALUE=”Limpiar”></center>
</FORM>
<br><br>
<FORM ACTION=”abm_pregunta.php” METHOD=”POST”>
<input type=”hidden” name=”param_tema” value=<? echo $param_tema ?>
>
<INPUT TYPE=”submit” value=”Volver al Menu Preguntas” >
</form>
</center>
<br><br>
<?
if ($HTTP_SERVER_VARS[’REQUEST_METHOD’] == ’POST’) { //autoproceso
246
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
$preg=$_POST[’preg’];
//$param_tema =$_POST[’param_tema’];
if (!(empty($_POST[’preg’]))){
$sql= ”INSERT INTO preguntas (codtema,preguntas)”;
$sql.= ”VALUES (’$param_tema’,’$preg’)”;
$rs = mysql_query($sql);
if (!$rs){
$x= mysql_error();
die(”<center><b>Ocurrio un Error en la base de Datos:”. $x.”</b></center>”);
}else{
echo ”<center><font size=4 color=#000000><b>Ok: </b></font>”;
echo ”<font size=4 color=#000080>Tema Grabado con Exito</font></center><br><br>”;
}
}else{
echo”<center><font size=3 color=#B90F3A><b>Debe Completar la Descripcion de la Pregunta </b> </font><br></center><br>”;
}
$con_det= mysql_query(”select * from preguntas where codtema =’$param_tema”’,$link);
$cant = mysql_num_rows($con_det);
12.2. DESARROLLO DEL SISTEMA
247
$muestra = $cant;
echo ”<center><font size=3 color=#032EAD><b> Este Tema Posee:  ”.
$muestra.”  Preguntas.
<br> Para Evaluar, el Tema Debe Tener Como Minimo: 10 Preguntas </b>
</font></center><br>”;
if (mysql_num_rows($con_det)!=0){
echo”<table width=100% align=center>”;
echo”<tr>”;
echo”<td bgcolor=#4CCBCB align=center><b>Codigo</b></td>”;
echo”<td bgcolor=#4CCBCB align=center><b>Preguntas del Tema</b></td>”;
echo”</tr>”;
while($det = mysql_fetch_array($con_det)){
echo ”<tr>”;
echo ”<td bgcolor=#7BD0FA align=left><font size=2>”.$det[’idp’].”</font></td>”;
echo ”<td bgcolor=#7BD0FA align=left><font size=2>”.$det[’preguntas’].”</font></td>”;
echo”</tr>”;
}
echo”</table>”;
}
}else {//no hay post
$con_det= mysql_query(”select * from preguntas where codtema =’$param_tema”’,$link);
if (mysql_num_rows($con_det)!=0){
248
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
echo”<table width=100% align=center>”;
echo”<tr>”;
echo”<td bgcolor=#4CCBCB align=center><b>Codigo</b></td>”;
echo”<td bgcolor=#4CCBCB align=center><b>Preguntas del Tema</b></td>”;
echo”</tr>”;
while($det = mysql_fetch_array($con_det)){
echo ”<tr>”;
echo ”<td bgcolor=#7BD0FA align=left><font size=2>”.$det[’idp’].”</font></td>”;
echo ”<td bgcolor=#7BD0FA align=left><font size=2>”.$det[’preguntas’].”</font></td>”;
echo”</tr>”;
}
echo”</table>”;
}
}//fin autoproceso
}else{
?>
<br><br><br>
<center>
<FORM ACTION=”abm_pregunta.php” METHOD=”POST”>
<input type=”hidden” name=”param_tema” value=<? echo $param_tema ?>
>
<INPUT TYPE=”submit” value=”Volver al Menu Preguntas” >
12.2. DESARROLLO DEL SISTEMA
249
</form>
</center>
<?
}
mysql_close($link);
?>
</body>
<center><font face=”Arial, Helvetica, sans-serif” color=”#FFFFFF” size=”2”>
<b>Laura Regnet: Desarrollo en PHP</b></font></center>
<?
} else {
session_unset();
$session = false;
?>
<h1>No Tiene Permitido Acceder a la Pagina</h1>
<?
}
?>
</html>
Calificación
<?
$pregunta = $_POST[’preg’];
$p = sizeof($pregunta);
// echo ”<br>”;
250
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
// echo ’<pre>’;
// print_r($_POST[’preg’]);
// echo ’</pre>’;
// echo ”<br>”;
$conta = $_POST[’conta’];
$c = sizeof($conta);
$paro = ”n”;
for($r=0;$r<sizeof($conta);$r++){
if (empty ($_POST[$r])){
$muestra[$r] = 0;
$paro = ”s”;
}else{
$muestra[$r] = $_POST[$r];
}
//echo $ver [$r];
$muestra[$r] = $_POST[$r];
}
for($j=0;$j<sizeof($pregunta);$j++){
$preg[] = (isset($_POST[’preg’])?$_POST[’preg’]:NULL);
}
for($j=0;$j<sizeof($conta);$j++){
//echo ’<pre>’;
$respDada[] = (isset($_POST[$r])?$_POST[$r]:NULL);
//print_r ($respDada);
12.2. DESARROLLO DEL SISTEMA
// echo ’</pre>’;
}
$matricula = (isset($_POST[’mat’])?$_POST[’mat’]:NULL);
if ($paro == ”s”) {
?>
<br><br><br><br><br><br><center>
<center><h2><font face=”Times New Roman” color=”#D22852” >
Debe Seleccionar Alguna Respuesta Por cada Pregunta,
<br> para que se le Pueda Calificar   </font></center>
<?
}else{
if(!$preg||!$respDada||!$matricula){
echo ”<p>Acceso invalido</p>”;
}
else{
$conexion = mysql_connect(”localhost”,”root”,”root”);
if(!$conexion){
echo ”<p>Error: No se puede conectar al servidor<br>\n”;
echo ”<a href=\”Index.php\”> Regresar al home ese</a> </p>\n”;
}
else{
$bd = mysql_select_db(”tflaura”,$conexion);
if(!$bd){
echo ”<p>Error: No se pudo seleccionar la bd<br>\n”;
251
252
CAPÍTULO 12. DESCRIPCIÓN DE LA APLICACIÓN
echo ”<a href=\”Index.php\”> Regresar al home</a> </p>\n”;
}
else{
$calif=0;
$consulta = mysql_query(”select nombre from usuarios where matricula=’$matricula”’,
$conexion);
echo ”<br><br><br><center>”;
echo ”<h2> Calificacion </h2>\n”;
echo ”<p> Alumno ”.mysql_result($consulta,0,’nombre’).” matricula $matricula</p>\n”;
echo ”</center>”;
for($i=0;$i<sizeof($pregunta);$i++){
//for($x=0;$x<sizeof($muestra);$x++){
$pre = $pregunta[$i];
// echo ”pregunta::”. $pre;
// echo ”<br>”;
$mu = $muestra[$i];
// echo ”Respuesta::”. $mu;
// echo ”<br>”;
$consulta = mysql_query(”select * from corresponde where idp=
’$pre’ and idr =’$mu’ and sipi= 1”,$conexion);
if (mysql_num_rows($consulta)!=0){
// echo ”-SI-”;
12.2. DESARROLLO DEL SISTEMA
253
$calif+=1;
}ELSE{
// echo ”-NO-”;
}
//}
}
// mysql_query(”update usuarios set calif=’$calif’, presento=1 where matricula=
’$matricula”’,$conexion);
mysql_Close($conexion);
echo ”<center>”;
echo ”<p>Ha obtenido una calificacion ”.($calif>=7?”aprobatoria”:”reprobatoria”).”
de $calif</p>”;
echo ”<p><a href=\”Index.php\”> Regresar </a> </p>\n”;
echo ”</center>”;
} }}}
?>
Capítulo 13
Conclusión
13.1
Conclusiones del Trabajo realizado
Cabe concluir este trabajo haciendo referencia a la importancia de las tecnologías para los métodos actuales de enseñanza-aprendizaje.
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 con
la posibilidad de disponer de un profesor como supervisor de los cursos (blearning).
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, 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.
Este éste sistema desarrollado se presenta como una experiencia diferen255
256
CAPÍTULO 13. CONCLUSIÓN
te 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.
Para esta aplicación se ha realizado un análisis con Diagramas de Casos de
Uso (metodología UML), utilizando Enterprise Architect como herramienta
CASE, los cuales se han aprendido a manejar para este trabajo comprobando
que su implementación hace más sencillo el desarrollo.
Con respecto a las tecnologías y software utilizados se ha podido comprobar
sus potenciales beneficios con respecto al soporte multiplataforma, indispensables por su eficiencia y rapidez al momento de desarrollar la aplicación con Php
y MySql, bajo Windows XP Service Pack 2, para implementarla en entorno
Windows.
Php sirve para crear todo tipo de aplicaciones Web.
Se debe hacer mención a la facilidad de manejo de Scientific WorkPlace
para redactar un libro, por la automatización en el manejo de estructucas
propias como índices, gestión dinámica de espacios, imágenes y referencias
bibliográficas y de figuras.
13.2
Líneas Futuras de Acción
Se pretende que el presente trabajo sea utilizado como punto de partida para:
• Incorporar otras metodologías de autoevaluación.
• Profundizar el análisis de gestión.
• Incorporar criptografía en la gestión de claves, esquematizando la seguridad.
• Desarrollar nuevas páginas para el ingreso de comentarios del alumno.
• Incorporar links específicos a sitios relacionados con Autonimic Computing.
Bibliografía
[1] L. Joyanes Aguilar. Cibersociedad. Mac Graw-Hill, 1997.
[2] Bart Jacob Carla Sadtler, John Ganci. WebSphere Product Family Overview and Architecture. IBM Press, USA, 2004.
[3] Lage F. Graus G. Britos P. García Martínez R. Cataldi Z.,
FigueroaÑ.
El rol delprofesor en la modalidad b-lerning.
http://www.itba.edu.ar/capis/webcapis/RGMITBA/comunicacionesrgm/CIESyNT2005-T192.pdf., Argentina, 2005.
[4] J. Kephart; D. Chess. The Vision of Autonomic Computing. IBM Corporation, Estados Unidos, 2003.
[5] IBM Autonomic Computing. Autonomic problem determination: A first
step toward self-healing computing systems. IBM Corporation, Estados
Unidos, 2003.
[6] IBM Autonomic Computing. Autonomic Computing Toolkit User’s Guide. IBM Corporation, Estados Unidos, 2004.
[7] IBM Corporation. IBM DB2 Universal Database para Windows Guía
Rápida de Iniciación Versión 7. IBM Press, USA, 2000.
[8] IBM Corporation. IBM DB2 Universal Database Suplemento de Instalación y Configuración Versión 7. IBM Press, USA, 2000.
[9] IBM Corporation. Problem Determination Log/Trace Scenario Guide Second Edition. IBM Corp., USA, 2004.
[10] Php Documentation Group. Manual de PHP. Philip Olson, Web, 2008.
[11] IBM. WebSphere Comerse V5.5 Architecture. IBM Press, USA, 2003.
257
258
BIBLIOGRAFÍA
[12] Aitor Imaz Javier García de Jalón, José Ignacio Rodríguez. Aprenda
Servlets de Java como si estuviera en Segundo. Universidad de Navarra,
San Sebastian, 1999.
[13] Mariño Sonia Itatí López María Victoria. Desarrollo y evaluación de
un modelo b-learning de enseñanza-aprendizaje en una asignatura de la
carrera de Sistemas. Departamento de Informática FaCENA UNNE, Argentina, 2007.
[14] Ali Arsanjani Mark Endrei, Jenny Ang. Patterns: Service Oriented Architecture and Web Services. IBM Press, USA, 2004.
[15] N.Ñegroponte. El Mundo Digital. Ediciones B, Barcelona-España, 1995.
[16] IBM Press. IBM DB2 Warehouse Manager Guía de Instalación Version
7. IBM Press, USA, 2001.
[17] Rudyanto Linngar Saida Davies, Surech Amujuri. WebSphere Business
Integration Pub/Sub Solutions. IBM Press, USA, 2004.
[18] L. Small. ABCs of the Autonomic Computing Toolkit. IBM Corporation,
Estados Unidos, 2004.
[19] D. F. Bantz; C. Bisdikian; D. Challener; J. P. Karidis; S. Mastrianni;
A. Mohindra; D. G. Shea; M. Vanover. Autonomic Personal Computing.
IBM Corporation, Estados Unidos, 2003.
[20] www.manualdephp.com.
Manual
de
PHP.
http://www.manualdephp.com/manualphp/estructuras-control.html,
Web, 2008.
Índice de Materias
AC
tecnologías y soluciones, 39
uso, 40
Uso de, 39
accesibilidad
del paradigma AC, 17
Adapter Rule Editor
Editor de Reglas del Adaptador, 46
administración
de interfase, 154
del servidor, 154
administrador
autonómico, 27, 28
análisis, 28
ejecución, 28
monitoreo, 28
plan, 28
administrador autonómico
virtual, 32
administrativo
almacenamiento, 167
servidor, 166
AE
elemento autonómico, 31
AIX, 63, 73, 112
AM
administrador autonómico, 31
AME, 41, 43, 53, 82, 85, 87
Autonomic Management Engine, 38
APC
arquitectura, 25, 30
arquitectura de referencia, 26
estándares, 17
niveles
maduración, 30
niveles de maduración, 25
adaptable, 26
administrado, 25
autonómico, 26
básico, 25
predictivo, 26
paradigma, 17
AC Information, 52
AC Toolkit
Autonomic Computing Toolkit,
37
conceptos generales, 37
descarga, 58
desinstalación, 62
escenarios, 38, 49
herramientas, 38
información y documentación,
39
instalación, 58, 61
instalación de soluciones y tecnologías de despliegue, 45
paquete, 52
plataformas soportadas, 60
tecnologías, 38
tecnologías y herramientas, 41
259
260
ÍNDICE DE MATERIAS
autonomic personal computing,
21
API, 90
APIs, 153
aplicaciones
Java, 154
applets, 140, 155
arquitecturas
tres niveles de, 136
autogestión
tecnología de, 15
autonomic computing, 11, 12
Autonomic Computing Toolkit, 37
Component Broker, 149
computación
cliente-servidor de tres niveles,
150
distribuida, 150
computación autonómica, 12
nociones, 11
personal, 30
conectividad
herramientas de, 114
contenedor
EJB, 165
Web, 163
B-Learning, 1
B2B, 135
B2C, 135
base de datos
Segmentación de la, 115
bases y herramientas
para su e-business, 130
bean
de entidad, 157
de sesión, 158
beans
empresariales, 153
beneficios de la CA
a corto plazo, 18
a largo plazo, 19
browser
aplicaciones basadas en, 153
browsers, 140
Data Marts, 114
Datajoiner
El producto, 114
DB2
Introducción a, 111
Universal Database, 111
DB2 Connect, 114
dependency checker
verificador de pre-requisitos, 41
desviaciones
Detección de, 115
DHTML, 141
digitales
activos, 135
DNS, 54, 162
download, 135
DrAdmin, 170
CA
computación autonómica, 12
CASE
herramientas case, 217
CGI, 156
client/server database, 116
clones, 163
e-business, 148
las soluciones para el, 148
Web enabled para, 112
e-business on demand
integración en el, 131
e-commerce, 133
effector, 29
EJB
ÍNDICE DE MATERIAS
módulo de, 165
escenario
tilde no, 84
de determinación de problemas,
49
de instalación automática, 51
determinación de problemas, 81
componentes, 87
SID, 57
estabilidad, 35
flash crowds, 130
flexibidad
del paradigma AC, 17
fuente de datos, 154
Generic Log Adapter, 38
GLA, 55, 82, 84, 89
Generic Log Adapter, 45
GLA/LTA, 55
granularidad
grados de, 112
grid computing, 19
GUI, 153
Horn
Paul, 12
hosts virtuales, 162
HP-UX, 112
HTML, 140
HTTP server y plug-in, 161
IBM, 12, 16
Data Management de, 112
IDE, 141
IMS, 114
Informix, 114
InstallAnywhere, 51
Integrated Solutions Console, 38
Consola de Soluciones Integradas, 46
261
interfase
de manejabilidad, 29
interfases administrativas, 167
Internet, 13
Intranets, 112
IPSec
Internet Protocol Security, 34
ISC, 54, 85
arrancar y detener, 73
desinstalación, 73
instalación, 62, 64
instalación de plug in, 77
requerimientos para la instalación, 63
resolución de problemas de instalación, 78
secuencia gráfica de arranque y
detención, 74
verificación de la instalación, 77
ISMP, 51, 57
IT, 14
information technologies
tecnologías de la información,
11
Java, 16, 87, 112
JDBC, 140, 172
JFC, 155
JSPs, 141
JVM, 64
Linux, 63, 73
log and trace
registro y seguimiento, 44
Log and Trace Analyzer Tool, 38
LTA, 55
Log and Trace Analizer, 44
Macrovision, 18
mentor, 3
Microsoft SQL Server, 114
262
ÍNDICE DE MATERIAS
middleware, 14
MIME, 156
modelización predictiva, 115
MQSeries, 145
multiplataforma, 15, 114
Multiprocesador
Sistema Simétrico, 116
NT
Windows, 112
OASIS
Organization for the Advancement of Structured Information Standards, 17
OLAP, 112
OLTP, 112
on demand
bajo demanda
a pedido, 15
Oracle, 114
OS/2, 112
OS/400, 112
paquete
de comandos, 159
distribuido, 159
PDS
PDScenario, 55
Php, 173
constantes, 183
estructuras de control, 187
funciones, 190
operadores, 185
sintaxis, 177
tipos de datos, 178
variables, 179
plataforma, 131
de software, 132
privacidad, 34
Problem Determination Scenario
Escenario de Determinación de
Problema, 47
producto
familias del, 139
RDBMS, 112
recurso
administrado, 27, 29
recursos, 172
redes
auto-diagnosticadas, 12
auto-gestionadas, 12
transparentes, 12
RIO, 141
RMB, 44, 53
RMI, 90
RMI/IIOP, 154
SA
sistemas autonómicos, 14
SAC
sistema de computación autonómica, 19
SAS, 18
SDD
Solution Deployment Descriptor, 17
seguridad, 34
sensor, 29
serial database, 116
servicio Web, 32
servicios
Web, 153
servidor
de aplicaciones, 160
de grupos, 162
HTTP incluido, 161
predefinido, 161
servidores
de aplicaciones y
ÍNDICE DE MATERIAS
beans empresariales, 157
genéricos, 172
Web, 157
servlet, 88
servlets, 155
SID, 54
SIDS
Solution Installation and Deployment Scenario, 57
single node/non-parallel, 116
SmartPhone, 140
SMD
editor, 45
Solucion Module Descriptor
Descriptor de Módulo de Solución, 45
SMP, 116
Solaris, 73
SSL
Secure Socket Layer, 34
standalone database, 116
Sun
Solaris, 112
Sybase, 114
TCPA
Trusted Computing Plataform
Alliance, 34
TIC, 2
Tivoli, 34
monitoring, 117
Toolkit, 17
touchpoint, 29
transparencia
del paradigma AC, 17
UDDI
Universal Description, Discovery,
and Integration, 32
UI
263
unidad instalable, 51
UML, 211
uniprocessor system, 116
UNIX, 168
vínculos
análisis de, 115
VSAM, 114
VT, 140
WAS, 167
Web
módulo, 164
WebSphere
Application Server, 143
arquitectura de, 160
Edge Server, 146
Everyplace Suite, 145
para el comercio, 128
Personalization Server, 145
Portal Server, 145
programación, 154
Site Analyzer, 146
Studio, 147
Transcoding Publisher, 145
Voice Server, 146
WebSphere Commerce, 133
WebSphere Everyplace, 133
WebSphere for Commerce
soluciones de portal, 134
soluciones digital media, 135
WebSphere for commerce
soluciones B2B, 133
soluciones B2C, 134
WebSphere Host Integration, 139
WebSphere Host Publisher, 140
WebSphere Portal, 133
WebSphere Studio, 139
la familia de herramientas, 141
264
WebSphere Transcoding Publisher,
140
WebSphere Voice, 133
Whitehead
Alfred North, 11
Windows, 63, 73, 74, 76, 77
wizard, 141
WMI
Windows Management Instrumentation, 31
workload, 163
WSDM
Web Services Distributed Management, 18
XML, 140
XML config, 170
ÍNDICE DE MATERIAS