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=“&quot;C:\ACComponents \ISC \Runtime \AppServer \bin \showlog.bat&quot; &quot;C:\ACComponents \ISC \Runtime \AppServer\logs\activity.log&quot; &quot;C:\Program Files \PdScenario_Home \activity.txt&quot;” 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&iacute;\n”); ?> 2. <? echo (”esta es la m&aacute;s simple, una instrucci&oacute;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&ntilde;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:&nbsp;</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:&nbsp;</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:&nbsp;</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:&nbsp;</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 &nbsp;</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:&nbsp;</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: &nbsp;”. $muestra.”&nbsp; 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 &nbsp; </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