Bases de Datos en Grid

Universidad Nacional del Nordeste
Facultad de Ciencias Exactas, Naturales y Agrimensura

Trabajo Final de Aplicacin
Grid Computing
Vernica Vanessa Barrios - L.U.: 33.899

Prof. Coordinador: Agr. Castor Herrmann
Prof. Orientador: Mgter. David Luis la Red Martnez
Licenciatura en Sistemas de Informacin
Corrientes - Argentina
2006
A Mis Padres Por el Apoyo Incondicional y a La Luz Que

Ilumnina Mi Vida
Prefacio
En los ltimos tiempos han habido importantes avances tecnolgicos tanto
en las reas de cmputo como en las de almacenamiento de datos; asimismo
los requerimientos de la administracin y de los negocios en la sociedad de la
informacin y el conocimiento, hacen necesario y conveniente estudiar tecnologas que nos permitan obtener informacin til del contenido de las bases de
datos, ms all de lo evidente, y mediante el uso de tecnologas y procedimientos innovadores, tales como la utilizacin de recursos distribuidos en diferentes
entornos y localizaciones geogrficas, lo que permite la optimizacin en el uso
de los mismos y la disminucin de los costos.
Todo lo sealado precedentemente sera ficticio sino se dispusiera de las
tecnologas y metodologas que facilitaran el desarrollo de trabajos complejos.
Este trabajo se basa en el estudio del software de base que permite la
construccin de un mini-grid distribuido, incluyendo una aplicacin Web y
Grid Services.
Contempla la obtecin de informacin referente a los alumnos de la Facultad de Ciencias Exactas, Naturales y Agrimensura, a efectos de brindar
utilidad a los usuarios pertenecientes en este caso a un sector de la facultad.
Objetivo
El ojetivo inicialmente fue la creacin una aplicacin utilitaria empleando
un software de Grid Computing para asistir a los usuarios en el anlisis automtico e inteligente de informacin, brindando de esta manera acceso a la
base de datos desde la Internet, en un entorno distribuido de computacin en
grilla.
El cumplimiento del objetivo propuesto signific el pormenorizado estudio
del software de Grid Computing sobre el sistema operativo Linux, el desarrollo
de servicios web donde alojar a la aplicacion desarrollada, y la puesta en
marcha del servicio grid que diera soporte al servicio web antes mencionado.
Clasificacin del Trabajo
Utilizacin de software de base que permite el desarrollo de aplicaciones
Web multiplataforma con acceso a bases de datos distribuidas, en un entorno
de servicios web y servicios grid.
Desarrollo de una aplicacin Web para el apoyo y seguimiernto de datos de
vi
alumnos de la Facultad, permitiendo la interaccin cliente-servidor mediante

una interfaz sencilla, operando desde la WWW, accediendo a un entorno de
Grid Computing.
Etapas de Desarrollo
Se ha efectuado una amplia recopilacin bibliogrfica especfica de los
temas pertinentes a la tarea planificada y a los productos de software
que se emplearon para la concrecin del Trabajo Final.
Se realizaron las traducciones de los manuales correspondientes a la herramienta de Grid Computing Globus Toolkit, versin 4.0 para Linux.
Como consecuencia de las gestiones realizadas por el Profesor Orientador ante IBM Argentina se han recibido materiales tanto en CDs como
en libros de dicha empresa, en el marco del Scholars Program de la misma, destinado a Universidades de todo el mundo; se destacan por ser
necesarios para la realizacin del presente Trabajo Final los referentes
a productos de software tales como el WebSphere Studio Application
Developer versin 5.0 y 5.1.2, el cual incluye al Eclipse correspondiente.
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 detallado estudio del software para el desarrollo de
la aplicacin, es decir el estudio de la plataforma integrada de desarrollo
de aplicaciones Web, WebSphere Studio Application Developer, como
as tambin el estudio de la plataforma de Grid Computing empleada,
Globus Toolkit.
Se ha realizado el desarrollo de la aplicacin utilizando pginas HTML
y Servlets de Java en el marco de la herramienta WebSphere Studio
Application Developer en el entorno Linux, para su posterior migracin
al entorno de web services y Grid Computing.
Se ha realizado el correspondiente testeo de la aplicacin con el sistema
operativo Linux SuSe 8.2., utilizando una mquina como servidor y otra
como cliente ingresando a la base de datos del servidor a travs de un
navegador web en una LAN de prueba.
Una vez finalizada la aplicacin se realiz la grabacin en DVD de todo
el material correspondiente al trabajo final: una versin de la aplicacin,
vii
otra referente al libro en formato Latex y el PDF generado. Tambin se

icluy los instaladores de los productos utilizados para el desarrollo, es
decir WebSphere Studio Application Developer, Eclipse y componentes
relacionados, Globus Toolkit y MySQL.
Objetivos Logrados
Se han alcanzado plenamente la totalidad de los objetivos planteados para
el presente trabajo.
Organizacin del Informe Final
El informe final comprende un libro impreso y un DVD, adems de un
resmen y de un resmen extendido.
El libro impreso est organizado en captulos, los que se indican a continuacin:
Introduccin (cuatro captulos): presenta una visin general de los sistemas de Grid Computing, los estndares relacionados con los mismos
y la potencialidad de su empleo para resolver problemas complejos en
cuanto a la cantidad de almacenamiento y a la carga de procesamiento,
en entornos distribuidos.
Web services y grid services: seala los principales conceptos referidos a
los servicios web, resaltando la diferencia entre los mismos y los servicios
grid.
Software utilizado:
Linux: indica los principales aspectos referidos a este S.O. y a sus
herramientas.
WebSphere: presenta los principales aspectos de este entorno de
desarrollo de aplicaciones complejas.
Servlets: resume los aspectos ms destacados de estas facilidades.
Java: describe las ms destacadas caractersticas del lenguaje.
Toolkit de Grid Computing: presenta los principales aspectos de la potencialidad, la configuracin y seguridad del mismo.
Aplicacin: detalla los aspectos ms significativos de la aplicacin desarrollada utilizando las facilidades antes mencionadas.
viii
Conclusiones: presenta las conclusiones a las que se ha llegado al finalizar

el presente trabajo.
El DVD, adjunto al libro impreso, contiene lo siguiente:
Instaladores del software utilizado.
Resmenes del trabajo realizado.
Libro del informe final.
Presentacin para la defensa final.
Copia de seguridad de la base de datos de la aplicacin.
Aplicacin desarrollada.
Vernica Vanessa Barrios

Licenciatura en Sistemas de Informacin
Universidad Nacional del Nordeste
L.U.: 33899
Prof. Orientador: Mgter. David Luis La Red Martnez
Corrientes; 4 de Diciembre de 2006
ndice General
1 Introduccin
1.1 Concepto de Grid Computing . . . . . . . . . . .
1.1.1 Beneficios que Ofrece el Grid Computing
1.2 Introduccin a Grid Computing . . . . . . . . . .
1.3 Qu es y Para Qu Sirve el Grid Computing? .
1.4 Qu es GLOBUS? . . . . . . . . . . . . . . . . .
1.5 Arquitectura del Grid . . . . . . . . . . . . . . .
1.6 Aplicaciones y Servicios en Grid . . . . . . . . .
1.6.1 Supercomputacin . . . . . . . . . . . . .
1.6.2 Proceso Intensivo de Datos . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Principios de Grid Computing

2.1 Lo Que el Grid Computing Puede Hacer . . . . . . . . .
2.2 Aprovechar los Recursos Que No Siempre se Usan . . .
2.3 La Capacidad de CPU Paralela . . . . . . . . . . . . .
2.4 Las Aplicaciones . . . . . . . . . . . . . . . . . . . . . .
2.5 Los Recursos y Organizaciones Virtuales . . . . . . . . .
2.6 El Acceso a los Recursos Adicionales . . . . . . . . . .
2.7 Balanceo de Recursos . . . . . . . . . . . . . . . . . . .
2.8 Confiabilidad . . . . . . . . . . . . . . . . . . . . . . . .
2.9 Administracin . . . . . . . . . . . . . . . . . . . . . . .
2.10 Los Conceptos y Componentes del Grid . . . . . . . . .
2.10.1 Los Tipos de Recursos . . . . . . . . . . . . . . .
2.10.2 Computacin . . . . . . . . . . . . . . . . . . . .
2.10.3 Almacenamiento . . . . . . . . . . . . . . . . . .
2.10.4 Las Comunicaciones . . . . . . . . . . . . . . . .
2.10.5 El Software y las Licencias . . . . . . . . . . . .
2.10.6 El Equipo Especial, Capacidades, Arquitecturas,
lticas . . . . . . . . . . . . . . . . . . . . . . . .
ix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
y
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
Po. . .
1
1
1
2
4
7
8
11
11
12
15
15
15
17
18
19
20
21
22
23
24
25
25
26
28
28
29
NDICE GENERAL
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
2.25
2.26
2.27
2.28
2.29
2.30
2.10.7 Los Trabajos y las Aplicaciones . . . . . . . . . . . .

Scheduling, Reservacin, y Barrido . . . . . . . . . . . . . . .
Intragrid a Intergrid . . . . . . . . . . . . . . . . . . . . . . .
Construccin del Grid . . . . . . . . . . . . . . . . . . . . . .
Planificacin del despliegue . . . . . . . . . . . . . . . . . . .
2.14.1 Seguridad . . . . . . . . . . . . . . . . . . . . . . . . .
2.14.2 Organizacin . . . . . . . . . . . . . . . . . . . . . . .
Componentes del Software Grid . . . . . . . . . . . . . . . . .
2.15.1 Componentes de administracin: . . . . . . . . . . . .
2.15.2 Software Servidor . . . . . . . . . . . . . . . . . . . . .
2.15.3 Software de Sumisin . . . . . . . . . . . . . . . . . .
2.15.4 Administracin del Grid Distribuido . . . . . . . . . .
2.15.5 Schedulers . . . . . . . . . . . . . . . . . . . . . . . . .
2.15.6 Las Comunicaciones . . . . . . . . . . . . . . . . . . .
Observacin, Direccin, y Medicin . . . . . . . . . . . . . . .
Usar un Grid: Perspectivas de Usuario . . . . . . . . . . . .
2.17.1 Conectar e instalar el software de Grid . . . . . . . . .
Registrarse en el Grid . . . . . . . . . . . . . . . . . . . . . .
Solicitar y Realizar Trabajos. . . . . . . . . . . . . . . . . . .
Configuracin de Datos . . . . . . . . . . . . . . . . . . . . .
Monitoreo del Progreso y Recuperacin . . . . . . . . . . . .
Reservar recursos . . . . . . . . . . . . . . . . . . . . . . . . .
Usar un Grid: La Perspectiva de un Administrador . . . . . .
2.23.1 Planeacin . . . . . . . . . . . . . . . . . . . . . . . .
2.23.2 Instalacin . . . . . . . . . . . . . . . . . . . . . . . .
Matriculacin de Direccin . . . . . . . . . . . . . . . . . . .
Certificado de Autoridad . . . . . . . . . . . . . . . . . . . . .
Administracin de Recursos . . . . . . . . . . . . . . . . . .
Compartir Datos . . . . . . . . . . . . . . . . . . . . . . . . .
Usar un Grid:Una Perspectiva del Diseador de la Aplicacin
El Presente y el Futuro del Grid . . . . . . . . . . . . . . . .
Qu No Puede Hacer el Grid Computing? . . . . . . . . . .
3 Estndares Abiertos
3.1 Web Service: Servicios Web . . . . . .
3.2 Grid Service: Servicios Grid . . . . . .
3.3 Open Grid Service Architecture . . . .
3.4 Open Grid Services Infrastructure . .
3.5 Cules Son Los Objetivos de OGSA?
3.5.1 Arquitectura: . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
31
32
35
35
35
36
36
37
37
39
39
40
41
41
42
42
43
44
46
47
48
49
49
49
50
51
53
54
54
55
56
.
.
.
.
.
.
57
57
58
59
59
60
61
NDICE GENERAL
3.6
3.7
xi
Qu Plataformas? . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
73
4 La Enterprise Computing
75
4.1 Servicios y Computacin B2B . . . . . . . . . . . . . . . . . . . 77
4.2 Tecnologas en las Cuales se Define la OGSA . . . . . . . . . . 78
4.2.1 El Globus Toolkit . . . . . . . . . . . . . . . . . . . . . 78
4.2.2 Los Web Services . . . . . . . . . . . . . . . . . . . . . . 80
4.3 Una Arquitectura de Grid Services Abierta . . . . . . . . . . . 82
4.3.1 Virtualizacin y Orientacin de Servicio . . . . . . . . . 82
4.3.2 Semnticas de Servicio: el Grid Service . . . . . . . . . 85
4.3.3 El Rol de Ambientes Hosting . . . . . . . . . . . . . . . 89
4.3.4 Usar Mecanismos de OGSA Para Construir Estructuras
de VO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.4 Aplicacin Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . 93
5 Web Services y Grid Services
5.1 Web Services: Servicios Web . . . . . . . . . . . . .
5.1.1 Definicin y Caracterizacin de Web Services
5.2 Grid Services: Servicios Grid . . . . . . . . . . . . .
5.2.1 Servicio de Nombres (GSH y GSR) . . . . .
5.2.2 Servicio de Datos (Service Data) . . . . . . .
5.2.3 Notificaciones . . . . . . . . . . . . . . . . .
5.2.4 Ciclo de Vida . . . . . . . . . . . . . . . . .
5.2.5 Qu Ofrecen los Nuevos Grid Services . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Software Utilizado
6.1 Sistema Operativo Linux - Administracin Bsica . . . . . . . .
6.1.1 Introduccin . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2 Qu es Linux? . . . . . . . . . . . . . . . . . . . . . . .
6.1.3 Por qu Linux? . . . . . . . . . . . . . . . . . . . . . .
6.1.4 Cmo es Licenciado Linux? . . . . . . . . . . . . . . .
6.1.5 De Dnde Vienen los Recursos para el Desarrollo de
Linux? . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.6 Caractersticas Principales . . . . . . . . . . . . . . . . .
6.1.7 Ventajas de Linux frente a otros S.O. . . . . . . . . . .
6.1.8 X Window . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.9 KDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Ejecucin de Programas . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Ejecucin en el Fondo & , kill, nice y nohup . . . . . . .
97
97
97
99
100
101
102
103
104
107
107
107
108
109
109
110
111
113
114
114
128
128
xii
NDICE GENERAL
6.3
6.4
6.5
6.6
6.2.2 Comando time . . . . . . . . . . . . . . . . . .

6.2.3 Comando top . . . . . . . . . . . . . . . . . . .
6.2.4 Programas de Comandos . . . . . . . . . . . .
6.2.5 Comandos tiles para Trabajar en Red . . . .
6.2.6 Instalacin de Linux . . . . . . . . . . . . . . .
WebSphere . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1 Que es WebSphere? . . . . . . . . . . . . . . .
6.3.2 Plataforma de Software . . . . . . . . . . . . .
6.3.3 Application Server . . . . . . . . . . . . . . . .
6.3.4 Arquitecturas de Tres Niveles . . . . . . . . . .
6.3.5 La familia de Herramientas WebSphere Studio
Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.1 Desarrollando Servlets . . . . . . . . . . . . .
JAVA . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.1 Introduccin al Lenguaje . . . . . . . . . . . .
Estructura General de un Programa Java . . . . . . .
6.6.1 Conceptos Bsicos . . . . . . . . . . . . . . . .
6.6.2 Variables Dentro del Lenguaje Java . . . . . .
6.6.3 Operadores en Java . . . . . . . . . . . . . . .
6.6.4
6.6.5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
128
129
129
131
133
144
144
144
150
156
160
162
162
174
174
179
180
183
186
Estructuras de Programacin . . . . . . . . . . . . . . . 190

Clases en Java . . . . . . . . . . . . . . . . . . . . . . . 196
7 Software de Base
201
7.1 Globus Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
7.1.1 Instalacin . . . . . . . . . . . . . . . . . . . . . . . . . 202
7.2 Simple CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
8 Descripcin de la Aplicacin
8.1 Descripcin General . . . . . . . .
8.1.1 Creacin del Cliente Web .
8.1.2 Creacin del Servicio Grid .
8.1.3 Ejemplos del Cdigo Fuente
. .
. .
. .
del
. . . . .
. . . . .
. . . . .
Servicio
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
219
219
219
222
222
9 Conclusiones
231
9.1 Conclusiones Acerca del Software Utilizado . . . . . . . . . . . 231
NDICE GENERAL
xiii
Bibliografa
233
ndice de Materias
235
ndice de Figuras
1.1
1.2
1.3
1.4
1.5
1.6
Origen y Desarrollo del Grid Computing. . . . . . . . . . . . .

Aplicaciones de la Computacin en Grid. . . . . . . . . . . . .
Caractersticas de un Grid Computacional. . . . . . . . . . . .
Arquitectura del Grid. . . . . . . . . . . . . . . . . . . . . . . .
Arquitectura Actual de los Sistemas de Informacin. . . . . . .
Arquitectura Grig Computing para Sistemas de Informacin.
3
5
7
10
13
13
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
Balanceo de Recursos. . . . . . . . . . .
Balanceo de Recursos. . . . . . . . . . .
Cofiabidad en los Sistemas de Grid. . . .
Administracin en los Sistemas de Grid.
Almacenamiento en el Grid. . . . . . . .
Trabajos y Aplicaciones del Grid. . . . .
Un Grid ms Simple. . . . . . . . . . . .
Un Intergrid ms Complejo. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
22
23
24
27
30
34
34
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
La Arquitectura de OGSA. . . . . . . . . . . . . . . . . . .
La Estructura de OGSA. . . . . . . . . . . . . . . . . . . . .
Componentes de OGSI. . . . . . . . . . . . . . . . . . . . .
El OGSI y Web service. . . . . . . . . . . . . . . . . . . . .
El OGSI y el Hosting de Web service. . . . . . . . . . . . .
La Estructura de la Arquitectura de Servicio de OGSA. . .
Servicio de ncleo de Grid. . . . . . . . . . . . . . . . . . .
Ejecucin de Programas de Grid y Data Service. . . . . . .
La Ejecucin de Programas de Grid y Data Service Hosting.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
63
64
65
66
68
69
70
72
4.1
4.2
Mecanismos del Globus Toolkit. . . . . . . .

Tres Diferentes Estructuras VO, Ambiente
Virtual y Servicios Colectivos. . . . . . . . .
Ejemplo de servicio grid operando. . . . . .
. .
y
. .
. .
79
4.3
xv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . .
Hosting
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
Simple
. . . .
. . . .
92
95
xvi
NDICE DE FIGURAS
5.1
Web Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1
6.2
6.3
6.4
6.5
6.6
Barra de Acceso a Internet. . . . .

Barra de Herramientas de Kfind. .
Plataforma de WebSphere. . . . . .
Ciclo de Vida de un Servlet. . . . .
Requerimiento de un Archivo JSP.
Requerimiento de un Servlet. . . .
7.1
7.2
7.3
Configuracin. . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Compilacin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Instalacin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
8.1
8.2
Cliente Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Cliente Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
9.1
Grid Computing. . . . . . . . . . . . . . . . . . . . . . . . . . . 232
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
98
117
124
145
165
166
167
ndice de Tablas
6.1
6.2
6.3
6.4
6.5
6.6
Tipos de Variables. . . . . . . .
Categoras de Variables. . . . .
Tipos Primitivos de Variables. .
Operadores de Asignacin. . . .
Operadores Relacionales. . . . .
Precedencia de Operadores. . .
xvii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
184
184
185
187
188
190
Captulo 1
Introduccin
1.1
Concepto de Grid Computing
El concepto principal de Grid Computing es el de compartir potencia computacional [13].

Desde el momento en el que los primeros ordenadores comenzaron a conectarse a Internet, surgi la idea de unir la potencia inutilizada de cada uno
para abordar problemas a los que slo podan enfrentarse las supercomputadoras pertenecientes a organizaciones gubernamentales, universidades o grandes
multinacionales.
La tecnologa que hace esto posible se llama Grid Computing (malla de
ordenadores) y se basa en el aprovechamiento de los ciclos de procesamiento
no utilizados por los millones de ordenadores conectados a la Red. De esta
forma se consigue que puedan resolver tareas que son demasiado intensivas
para ser resueltas por una nica mquina.
1.1.1
Beneficios que Ofrece el Grid Computing
Los principales beneficios son:

Ofrecer flexibilidad para llenar las necesidades cambiantes del negocio.
Brindar alta calidad a menor costo.
1
CAPTULO 1. INTRODUCCIN
Facilitar el pronto retorno de las inversiones.

No necesitar de toda una nueva infraestructura para que funcione.
Facilitar poder de computacin / precio muy barato.
Brindar el poder de un supercomputador.
Utilizar software gratuito y usar cdigo fuente abierto.
No precisar hardware adicional, para posibilitar el incremento de la potencia de cmputo.
Brindar transparencia para el usuario que participa en el Grid.
1.2
Introduccin a Grid Computing
La idea del Grid est enfocada fundamentalmente en el acceso remoto a recursos computacionales y pretende ser un paradigma de desarrollo no centrado
en una tecnologa concreta [9].
La evolucin de grid computing se refleja en el avance de la estandarizacin
de esta tecnologa (el estndar de Globus Project es el estndar de facto)
donde se encuentra definida la arquitectura del grid, los niveles de acceso, los
requisitos, los servicios, etc.
El grid computing se enmarca dentro de la tecnologa de computacin distribuida englobando conceptos como sistemas operativos distribuidos, programacin multiprocesador, redes de ordenadores, computacin paralela, redes de
computadoras, seguridad, bases de datos, etc. De alguna manera el concepto
de grid computing da una unidad conceptual a estos problemas de manera que
todos ellos puedan verse desde una perspectiva grid.
El Grid Computing es ms que una idea ambiciosa, ya que no slo se trata
de compartir ciclos de CPU para realizar clculos complejos sino que se busca
la creacin de una infraestructura distribuida. Esta ardua tarea involucra
labores de definicin de la arquitectura general, de interconexin de diferentes
redes, de definicin de estndares, de desarrollo de procedimientos para la
construccin de aplicaciones, etc. [11].
El Grid es una idea que promete revolucionar el mundo de la computacin
y el cmo se desarrollan las aplicaciones actualmente [13].
1.2. INTRODUCCIN A GRID COMPUTING
Parece claro que Grid Computing no es una moda, y queda, todava, hay
un largo camino por recorrer desde los conceptos hasta las aplicaciones reales.
Aunque existen muchos mini-grids para el desarrollo de investigaciones no parece cercano el da en que todos los ordenadores del mundo formen un Grid
Mundial a modo de gigantesco sistema de distribucin elctrico (paradigma
del grid computing en casi todas las publicaciones sobre el tema), donde los
usuarios se conecten y tengan acceso a la capacidad de cmputo y de almacenamiento que precisen sin preocuparse de donde se genera (ver fig. 1.1 de la
pg. 3) [13].
Figura 1.1: Origen y Desarrollo del Grid Computing.
1.3
Qu es y Para Qu Sirve el Grid Computing?
El concepto de Grid Computing da idea de una gran potencia de clculo y

almacenamiento, y parece un gran avance en las ciencias de la computacin.
Existen adems una multitud de aplicaciones reales que hacen uso de minigrids, casi todas ellas estn centradas en el campo de la investigacin en el
terreno de las ciencias fsicas, mdicas y del tratamiento de la informacin.
Se ha hablado mucho de lo que ofrece y de las posibilidades del grid computing pero todava no se ha definido de manera concreta el trmino.
Un grid computacional es una infraestructura hardware y software que suministra al que la utiliza acceso seguro (dependable), consistente (consistent),
penetrante (pervasive) y barato (inexpensive), a unas elevadas capacidades
computacionales.
El concepto infraestructura se utiliza porque un grid es un conjunto de
recursos (ciclos de CPU, datos, sensores, etc.), y todos esos recursos necesitan
una interconexin hardware y un control software para que estn ensambladas
en un grid. Esta infraestructura debe proporcionar a los usuarios un servicio
seguro a todos los niveles: capacidad de cmputo, de integridad de datos, de
seguridad de acceso, etc.
El servicio debe ser consistente, basado en estndares, y de esta manera el
acceso y las operaciones sobre el grid estarn definidas por dichos estndares
evitando la heterogeneidad. La idea de penetracin no es tanto la posibilidad
de acceder a cualquier recurso del grid como que el grid llega a cualquier
sitio, de esta manera se asegura que una vez conectado desde cualquier punto
puede extraer del grid toda la potencia que requiera. Por ltimo el acceso y
uso del grid debe tener un coste econmico que le haga atractivo para que su
utilizacin se universalice.
Para terminar de definir el concepto se desgrana cada uno de los posibles
campos de aplicacin de la tecnologa grid. (ver fig. 1.2 de la pg. 5).
El anlisis lleva a definir cinco grandes reas de trabajo determinadas por
las necesidades de clculo, espacio para el almacenamiento de los datos y
tiempo de respuesta. Las reas son:
Supercomputacin distribuida
1.3. QU ES Y PARA QU SIRVE EL GRID COMPUTING?
Figura 1.2: Aplicaciones de la Computacin en Grid.
Dentro de esta rea se encuentran aquellas aplicaciones cuyas necesidades

es imposible satisfacer en un nico nodo. Estas necesidades se producen en
instantes de tiempo determinados y consumen muchos recursos, por lo que se
dice que son puntuales e intensivas. Ejemplo de este tipo de aplicaciones son
las simulaciones, las herramientas de clculo numrico, los procesos de anlisis
de datos, la extraccin de conocimiento de almacenes de datos, etc.
Sistemas distribuidos en tiempo real
En este tipo de aplicaciones se consideran aquellas que generan un flujo
de datos a alta velocidad que debe ser analizado y procesado en tiempo real.
Ejemplo de este tipo de aplicaciones son los experimentos de fsica de alta
energa, control remoto de equipos mdicos de alta precisin y precio, todos
los procesos de la denominada e-Medicine, el tratamiento de imgenes para la
visin artificial, etc.
Proceso intensivo de datos
Esta rea se centra en aquellas aplicaciones que hacen un uso intensivo
del espacio de almacenamiento. Las necesidades de almacenamiento de este
tipo de aplicaciones desbordan la capacidad de almacenamiento de un nico
nodo y los datos son distribuidos por todo el grid. Adems de los beneficios
por el incremento de espacio, la distribucin de los datos a lo largo del grid
permite el acceso a los mismos de forma distribuida. Ejemplos de este tipo de
aplicaciones son todos los sistemas gestores de bases de datos distribuidas.
Servicios puntuales
En esta rea, se olvida el concepto de potencia de clculo y capacidad de
almacenamiento, para centrarse en recursos que una organizacin puede considerar como no necesarios. De esta manera el grid ofrece a la organizacin
esos recursos sin que la organizacin deba desarrollarlos por si misma. Ejemplos de este tipo de aplicaciones son aquellas que permiten acceder a hardware
muy especfico (equipos costosos de medida o de anlisis de muestras) para la
realizacin de labores a distancia.
Entornos virtuales de colaboracin
Esta rea est relacionada directamente con el concepto de Teleinmersin,
de manera que se utilizan los enormes recursos computacionales del grid y su
naturaleza distribuida para generar entornos virtuales 3D distribuidos (ver fig.
1.3 de la pg. 7).
1.4. QU ES GLOBUS?
Figura 1.3: Caractersticas de un Grid Computacional.
1.4
Qu es GLOBUS?
Globus es un proyecto de investigacin y desarrollo enfocado a permitir la

aplicacin de los conceptos de Grid al campo cientfico.
El proyecto Globus desarrolla software capz de resolver las dificultades
tcnicas que aparecen al tratar de implementar Grid Computing.
Por ejemplo administracion de recursos y de datos, recursos de informacion,
seguridad o desarrollo de aplicaciones. Este esfuerzo a nivel de software ha
dado como resultado el Globus Toolkit, un conjunto de servicios y libreras de
software capz de soportar aplicaciones tipo Grid. El Toolkit incluye software
relacionado con seguridad, informacion y manejo de recursos e intercambio de
datos.
El software de Globus es libre y est soportado por los sistemas operativos
Linux, Solaris, IRIX, AIX, HPUX, True64,...
La arquitectura del Globus Toolkit v3 se estructura en varias
capas.
La capa inferior es el ncleo donde se encuentran las factoras de recursos,
el servicio de notificaciones, el servicio de persistencia y el servicio de ciclo de
vida. En la segunda capa se encuentran los servicios de seguridad (GSI Grid
Security Infraestructure). En la tercera capa se encuentran los servicios bsicos
como la gestin de trabajos, los servicios de directorio y monitorizacin y los
de transferencia de ficheros. En el nivel ms alto se encuentran los servicios

de gestin de grandes cantidades de datos y aquellos servicios que no son del
GT3 pero que se basan en esta arquitectura.
En esta versin se introduce el concepto de grid service que es una ampliacin de los Web Services .La idea es buscar una tecnologa de objetos
distribuidos que se adaptase a las necesidades de una aplicacin grid, y para
ello se utilizaron los Web Services, aunque estos presentan algunas limitaciones
que se superaron:
Los Web Services no mantienen el estado de una invocacin a otra, los
grid services si.
Los Web services no son transientes, es decir no se pueden crear varias
instancias de un mismo servicio segn se necesita y destruirlas cuando
ya no son necesarias, en los grid services s se puede.
Los Web Services no incluyen servicios de apoyo que han sido incluidos
en los grid services como son las notificaciones, el servicio de persistencia,
la gestin del ciclo de vida, etc.
Los grid services utilizan un enfoque de Factoras de Objetos de manera que
en lugar de tener un nico servicio compartido por todos los usuarios (como el
Web Service) se tiene un servicio-factora que crea instancias individuales del
servicio. Cuando se invoca a una operacin del servicio se accede a la instancia
y no a la factora. Adems crea una instancia por cliente, o varias por cliente
o una para varios clientes. Por ltimo la destruccin de la instancia puede
correr a cargo del cliente o de la factora.
El Globus Project (el proyecto iniciador) es el que ha proporcionado una
implementacin estndar que es utilizada por una multitud de empresas; permitiendo que los sistemas que hacen uso del grid se integren como sustento de
aplicaciones empresariales.
1.5
Arquitectura del Grid
Es una nueva arquitectura de computacin designada para direccionar las

necesidades de utilidad de computacin, lo que significa que la arquitectura
formada por Grid permite utilizar los recursos de procesamiento propios de
1.5. ARQUITECTURA DEL GRID
la compaa sin tener que invertir ms en adquirir capacidad extra de procesamiento. Es como colocar los procesadores existentes en la empresa en
el centro y enviarles a ellos los datos para procesar, esto permite que los
recursos se utilicen a medida que se necesiten.
Esta arquitectura se ha utilizado para resolver grandes problemas de computo, como procesar datos de investigaciones, simulaciones cientficas, procesamientos de datos estadsticos y simulaciones tcnicas, a diferencia del Grid
empresarial donde se ejecutan aplicaciones reales en tiempo real y se optimizan recursos informticos (es hacia donde est apuntando Oracle con Grid
Computing).
Las aplicaciones, los toolkits, las APIs, los SDK, etc. que se definen para la
computacin en Grid deben de cumplir una arquitectura general. Esta arquitectura general se articula en cinco niveles: la infraestructura, la conectividad,
la gestin del recurso, la gestin de varios recursos y el nivel de aplicacin, segn se muestra en la fig. 1.4 de la pg. 10.
Principalmente, la arquitectura propuesta es una arquitectura de protocolos que definen los mecanismos bsicos que permiten a los usuarios y a los
recursos negociar, establecer, gestionar y explotar la comparticin de recursos.
Una arquitectura abierta basada en un estndar facilita la extensibilidad, la
interoperatibilidad, la portabilidad y la comparticin de cdigo.
De esta manera la estandarizacin de los protocolos permitira estandarizar
los servicios y mejorar las capacidades del grid.
En el nivel de infraestructura se encuentran los recursos computacionales,
como son los ordenadores, los clusters, los supercomputadores, los sistemas de
almacenamiento en red, las bases de datos, etc. Tambin se incluyen en este
nivel la infraestructura de la red y sus mecanismos de gestin y control. En la
terminologa Grid la infraestructura se denomina la Fbrica y suministra los
componentes que sern compartidos.
El nivel de conectividad incluye los protocolos de comunicacin y seguridad que permiten a los recursos computacionales comunicarse. Entre estos
protocolos se encuentran: la pila de protocolos TCP/IP, el protocolo SSL, Certificados X.509. Tambin se incluyen los nuevos protocolos que se encuentran
en fase de estudio y que permitirn mejorar el rendimiento en las redes de alta
velocidad. La seguridad es un punto muy importante de la computacin en
grid por su propia naturaleza distribuida ya que se comparten recursos entre
distintas organizaciones que pueden tener distintas polticas de seguridad.
10
Figura 1.4: Arquitectura del Grid.

El nivel de recurso se centra en la gestin de un nico recurso y permite
tener informacin y control sobre el mismo. En este nivel se encuentran los
protocolos que permiten obtener la informacin de un recurso: las caractersticas tcnicas, la carga actual, el precio, etc. Tambin se encuentran los
protocolos que permiten el control del recurso: el acceso al mismo, el arranque
de procesos, la gestin, la parada, la monitorizacin, la contabilidad de uso y
la auditoria del recurso.
La capa de recursos engloba todos los servicios que permiten gestionar un
conjunto de recursos. Se encuentran los servicios de directorio, que permiten
localizar los recursos que son de nuestro inters; los schedulers distribuidos,
que permiten asignar las tareas a cada recurso; la monitorizacin y diagnstico
de la ejecucin de las distintas tareas en que se distribuyen la ejecucin de una
aplicacin; la contabilidad, que permite calcular el coste de la utilizacin de
varios recursos heterogneos, y, el acceso a datos distribuidos, que gestiona la
replicacin de datos.
El servicio de scheduler distribuido es una de las aplicaciones ms complejas de un desarrollo grid ya que existen tres scheduler distintos: el planificador
de trabajos (job scheduler) que intenta maximizar la cantidad de trabajo realizado (trabajos por unidad de tiempo), el planificador de recursos que intenta
1.6. APLICACIONES Y SERVICIOS EN GRID
11
maximizar el uso de los recursos, y, el planificador de la aplicacin que divide la aplicacin en tareas, asigna los recursos para su ejecucin y vigila el
desarrollo de los mismos.
Los dos primeros priman la eficiencia del sistema grid, mientras que el
tercero prima la eficiencia de la aplicacin.
El ltimo nivel, el de aplicacin, se centra en la definicin de protocolos que
permitan a las aplicaciones el acceso a la infraestructura del grid a travs de las
distintas capas. Segn el tipo de aplicacin puede ser necesario conectarse a
las distintas capas o acceder directamente a una de ellas, incluso directamente
a la infraestructura.
1.6
Aplicaciones y Servicios en Grid
El avance del grid computing se observa en la aplicabilidad de sus ideas en

productos comerciales y los desarrollos de compaas de software basados en
el estndar de grid.
1.6.1
Supercomputacin
Uno de los campos donde se han centrado ms los esfuerzos de compaas

comerciales es en el de la supercomputacin. Empresas con un amplio abanico de productos, ofrecen desarrollos para la instalacin de grids con altas
capacidades de cmputo.
Por ejemplo, HP conect al grid del DOE (DOE Science Grid) una mquina Linux de 9,2 teraflops . Este grid se usa para llevar a cabo simulaciones,
analizar datos y coordinar experimentos. Sobre la mquina se instala el software de Globus para permitir la gestin de recursos, el movimiento de datos y
el control de la seguridad entre los grupos de investigacin que hagan uso de
l. Los usuarios se identificarn en el grid mediante las credenciales de autenticacin del GSI (Grid Security Infraestructure), el estndar de seguridad de
Globus. El supercomputador de HP ser puesto a disposicin del grid a travs
del Globus MDS (Monitoring and Discovery Service), un catlogo seguro de
todos los recursos del grid.
En las instalaciones de Sun se llevan a cabo las simulaciones sobre aerodinmica. Su versin comercial es costosa.
12
GridSystems ha desarrollado el productor InnerGrid para la aplicacin de

la tecnologa grid en entornos empresariales, acadmicos y de investigacin.
Este software divide datos y procesos en pequeas unidades que se ajustan dinmicamente a los recursos conectados a la red. El sistema es multiplataforma
(Windows y todos los sistemas UNIX).
Esta empresa lo que hace es aprovechar los ciclos libres de CPU aumentando la capacidad de cmputo global con un bajo coste. De esta manera los
ciclos libres son utilizados por aplicaciones que consumen muchos recursos y
necesitaran de un supercomputador o por trabajos puntuales e intensivos en
una fraccin de tiempo.
La instalacin del producto en una empresa permite la utilizacin de
mquinas que han quedado obsoletas y la instalacin de nuevas mquinas sin
que se interfiera en el trabajo de la compaa, ya que el software es fcilmente
escalable.
1.6.2
Proceso Intensivo de Datos
Otra de las grandes reas de aplicacin es el almacenamiento masivo de datos.

Dentro de esta rea las nuevas versiones se centran en la aplicacin de las ideas
de Grid Computing al almacenamiento de datos. La nueva versin parte de
la arquitectura actual en la que se encuentran la mayora de los sistemas de
informacin (ver fig. 1.5 de la pg. 13).
Cada una de las capas es de uso dedicado a cada sistema de informacin.
Evidentemente, el fallo de alguno de los componentes de los tres niveles (Application Server, Database y Storage) supondra una prdida del servicio (Oracle:
Oracle Database 10g, Oracle Application Server 10g, Oracle Enterprise Manager 10g y Oracle 10g Development Tools).
Esta nueva arquitectura
basada en grid computing pretende crear granjas/factoras de almacenamiento y servidores estndares y modulares, a las que se puede aadir servidores
rpidamente. En la fig. 1.6 en la pg. 13 se detalla a grandes rasgos la
arquitectura propuesta (versin Oracle 10g.).
Las caractersticas de esta arquitectura seran:
Capacidad de balanceo de sistemas.
Alta disponibilidad.
1.6. APLICACIONES Y SERVICIOS EN GRID
13
Figura 1.5: Arquitectura Actual de los Sistemas de Informacin.
Figura 1.6: Arquitectura Grig Computing para Sistemas de Informacin.
14
Reduccin de costes.
Facilidades de administracin.
La utilizacin de esta versin permitira a una empresa mejorar sus prestaciones sin renunciar al comportamiento tradicional de los Sistemas de Informacin .
Captulo 2
Principios de Grid Computing

2.1
Lo Que el Grid Computing Puede Hacer
Cuando se despliega un Grid, se podr encontrar con un conjunto de requerimientos del cliente.
Para que las habilidades del Grid Computing se adapten mejor a esos
requerimientos, es til tener presente las razones para las que se usa el Grid
Computing.
A continuacin se describen las capacidades ms importantes del Grid
Computing.
2.2
Aprovechar los Recursos Que No Siempre se

Usan
El uso ms fcil del Grid Computing es ejecutar una aplicacin existente en

una mquina diferente [1] [11] [12] [5].
La mquina en que la aplicacin normalmente se ejecuta podra estar inusualmente ocupada debido a un pico inusual de actividad.
El trabajo en cuestin podra ejecutarse en otra parte en una mquina
ociosa en el Grid.
15
16
CAPTULO 2. PRINCIPIOS DE GRID COMPUTING
Hay dos requisitos previos a cosiderar en este apartado.

Primero, la aplicacin debe ser ejecutable remotamente.
Segundo, la mquina remota debe encontrar cualquier hardware especial,
software, o requerimientos de recursos impuestos por la aplicacin.
Por ejemplo, un trabajo en lotes (batch) que consume una cantidad significativa de tiempo procesando un conjunto de datos de entrada para producir
un conjunto de resultados, es quizs el uso ms ideal y simple para un Grid.
Si las cantidades de entradas y salidas son grandes, ms anlisis y planeacin podran requerirse para usar eficazmente el Grid para tal trabajo.
Normalmente no tendra sentido usar un procesador de palabra remotamente en un Grid, porque habra retrasos mayores y ms puntos potenciales
de fracaso.
En la mayora de las organizaciones, hay grandes cantidades de recursos
no siempre utilizados.
La mayora de las mquinas del escritorio estn ocupadas menos del 5%
del tiempo.
En algunas organizaciones, incluso las mquinas servidoras pueden estar a
menudo relativamente ociosas.
El Grid Computing provee una estructura para explorar estos recursos y
as tener la posibilidad de aumentar la eficacia de su uso.
Los recursos del procesamiento no son los nicos que pueden estar subutilizados.
A menudo, las mquinas puede tener la enorme capacidades de disco no
usadas.
El Grid Computing, ms especficamente, un Grid de datos, puede usarse
para agregar este almacenamiento no utilizado a un almacn de datos virtuales ms grandes, posiblemente configurado para lograr mejorar la calidad y
confiabilidad de cualquier mquina.
Si un trabajo batch necesita leer una cantidad grande de datos, stos datos podran reproducirse automticamente en varios puntos estratgicos en el
Grid. As, si el trabajo debe ejecutarse en una mquina remota en el Grid, los
2.3. LA CAPACIDAD DE CPU PARALELA
17
datos ya estn all y no necesitan ser movidos a ese punto remoto. Esto ofrece
claros beneficios de calidad.
Tambin, tales copias de datos pueden usarse como backups cuando las
primeras copias se daan o no estn disponibles.
Otra funcin del Grid es equilibrar mejor la utilizacin del recurso.
Una organizacin puede tener picos inesperados ocasionales de actividad
que exigen ms recursos.
Si las aplicaciones en el Grid estn habilitadas, ellos pueden moverse a las
mquinas poco utilizadas durante tales picos.
De hecho, algunas aplicaciones del Grid pueden migrar los trabajos parcialmente terminados.
En general, un Grid puede proporcionar una manera consistente de equilibrar las cargas en una coalicin de recursos ms amplia.
Esto incluye la CPU, almacenamiento, y muchos otros tipos de recursos
que pueden estar disponibles un Grid.
La administracin puede usar un Grid para ver bien los modelos de uso en
una organizacin ms grande, permitiendo una mejor planificacin al actualizar los sistemas, incrementar la capacidad , o retirar recursos de computing
que ya no se necesitan.
2.3
La Capacidad de CPU Paralela
El potencial para la capacidad de CPU paralela masiva es uno de los rasgos

ms atractivos de un Grid. Adems de necesidades cientficas puras, tal poder
de computing est conduciendo a una nueva evolucin en las industrias como
el campo bio-mdico, planeacin financiera, exploracin petrolera, etc.
El atributo comn entre tales usos es que las aplicaciones se han escrito
para usar algoritmos que pueden dividirse independientemente en partes de
ejecucin.
Una aplicacin de Grid intensiva de CPU puede pensarse como muchos
sub-trabajos ms pequeos, cada uno ejecutndose en una mquina diferente
en el Grid.
18
Si tos sub-trabajos no nesecitan comunicarse con el otro, la aplicacin se

vuelve ms escalable.
Una aplicacin absolutamente escalable, terminar diez veces ms rpido
si usa diez veces el nmero de procesadores.
A menudo existen barreras para perfeccionar la escalabilidad.
La primer barrera depende de los algoritmos usados para dividir la aplicacin entre muchas CPUs.
Si el algoritmo slo puede dividirse en un nmero limitado de partes independientes de ejecucin, entonces eso forma una barrera de escalabilidad.
La segunda barrera aparece si las partes no son completamente independientes; esto puede causar contencin que puede limitar la escalabilidad.
Por ejemplo, si todos los sub-trabajos necesitan leer y escribir desde un
archivo comn o base de datos, el acceso a ese archivo o base de datos se
vuelve un factor limitante en la escalabilidad de la aplicacin.
Otras fuentes de contencin de inter-trabajo en una aplicacin de Grid
paralela incluye latencias de comunicaciones de mensajes entre los trabajos, la
red, las capacidades de comunicacin, los protocolos de sincronizacin, el ancho
de banda de entrada-salida, los dispositivos de almacenamiento, y latencias que
interfieren con los requerimientos de tiempo real.
2.4
Las Aplicaciones
Hay muchos factores para considerar en una aplicacin de habilitacin de Grid.

Se debe entender que no todas las aplicaciones pueden transformarse para
ejecutarse en paralelo con un Grid y lograr escalabilidad.
Adems se dispone de herramientas prcticas, que los diseadores de aplicacin pueden usar para escribir una aplicacin paralela.
Sin embargo, una transformacin automtica de aplicaciones es una ciencia
nueva.
ste puede ser un trabajo difcil y a menudo puede requerir de matemtica
avanzada y de talentos de programacin, si incluso es posible en una situacin
2.5. LOS RECURSOS Y ORGANIZACIONES VIRTUALES
19
dada.
Nuevas aplicaciones intensivas de computacin se estn diseando para la
ejecucin paralela y stas sern fcilmente habilitadas para su ejecucin en
Grid.
2.5
Los Recursos Virtuales y las Organizaciones Virtuales Para la Colaboracin
Otra importante contribucin del grid es habilitar y simplificar la colaboracin

entre un grupo ms amplio de usuarios.
Usar, computacin distribuida prometa esta colaboracin y la logr en
alguna magnitud.
El Grid toma estas capacidades para un pblico an ms amplio, mientras
ofrece estndades importantes que permiten a los sistemas muy heterogneos
trabajar juntos para formar la imagen de un sistema de Grid virtual grande,
que ofrece una variedad de recursos virtuales.
Los usuarios del Grid pueden organizarse dinmicamente en un nmero
de organizaciones virtuales (VO), cada una con diferentes requerimientos de
poltica.
Estas VO pueden compartir sus recursos colectivamente como un Grid ms
grande.
Compartir, comienza con datos en forma de archivos o bases de datos.
Un Grid de datos puede extender las capacidades de varias maneras.
Primero, los archivos o bases de datos pueden ampliar muchos sistemas y
lograr mayores capacidades que en cualquier sistema simple. Tales ampliaciones pueden mejorar las tasas de transferencia de datos a travs del uso de las
tcnicas de striping.
Los datos pueden estar duplicados a travs del grid para servir como backups y pueden organizarse en o cerca de las mquinas que probablemente
necesiten los datos, junto con las tcnicas de planificacin avanzadas.
Compartir no se limita a los archivos, tambin incluye muchos otros recur-
20
sos, como equipos, software, servicios, licencias, y otros. Estos recursos son
los virtualizados para darles una interoperabilidad ms uniforme entre los
participantes heterogneos del Grid.
Los participantes y usuarios de Grid pueden ser miembros de varias organizaciones reales y virtuales.
El Grid puede ayudar a potenciar las reglas de seguridad entre ellas e implementar polticas que puedan resolver prioridades para recursos y usuarios.
Como se observa en la fig. 2.1 de la pg. 20, donde se virtualizan recursos
heterogneos y geogrficamente dispersos para cada organizacin virtual que
presenta una vista ms simple.
Figura 2.1: Balanceo de Recursos.
2.6
El Acceso a los Recursos Adicionales
Los recursos adicionales pueden proporcionarse en nmero y capacidad variable.

Por ejemplo, si un usuario necesita aumentar su ancho de banda total a
2.7.
BALANCEO DE RECURSOS
21
Internet para implementar un mecanismo de bsqueda de minera de datos,

el trabajo podra devidirse entre mquinas del Grid que tienen conexiones
independientes a Internet.
De esta manera, la capacidad total de bsqueda se multiplica, desde que
cada mquina tiene una conexin separada a Internet.
Si las mquinas hubieran compartido la conexin en Internet, no habra
habido un aumento eficz en el ancho de banda.
Algunas mquinas pueden tener instalado el software bajo licencia costoso
que los usuarios requieran.
Su trabajo puede enviarse a tales mquinas aprovechando las licencias del
software.
2.7
Balanceo de Recursos
Para aplicaciones habilitadas, el grid puede ofrecer un efectivo balanceo de

recursos mediante la planificacin de trabajos de grid en mquinas con poca
utilizacin, como se ilustra en fig. 2.2 de la pg. 22.
Esta facilidad puede mejorar invalorablemente el manejo de picos de carga
de actividad en sectores de una organizacin ms grande. Esto puede pasar
de dos maneras:
Un pico inesperado puede ser conducido a mquinas relativamente ociosas en el Grid.

Si el grid ya se utiliza totalmente, el trabajo de prioridad ms baja
que se realiza en el grid debe ser suspendido temporalmente o incluso
cancelado y realizado posteriormente para dejar lugar a un trabajo de
prioridad mayor.
Sin una infraestructura de Grid, tales decisiones de equilibrio seran difciles

de priorizar y ejecutar.
22
Figura 2.2: Balanceo de Recursos.
2.8
Confiabilidad
Los sistemas informticos convencionales high-end usan hardware caro para

aumentar la fiabilidad.
Se construyen usando chips con circuitos redundantes que brindan resultados y contienen mucha lgica para lograr una buena recuperacin ante fallas
de hardware.
Las mquinas tambin usan procesadores dobles con pluggability (conexionado en caliente) para que cuando uno de ellos falla, se lo pueda reemplazar
por el otro sin apagar el equipo.
Los sistemas de suministros de corriente elctrica y de ventilacin estn
duplicados. Los sistemas operan con fuentes especiales de energa que pueden
encender los generadores si la corriente utilizada se interrumpe. Todos esto
construye un sistema fiable, pero a un gran costo, debido a la duplicacin de
componentes de alta fiabilidad.
Los sistemas en un Grid pueden ser relativamente baratos y geogrficamente dispersos.
2.9. ADMINISTRACIN
23
As, si hay algn tipo de falla, no es probable que las otras partes del Grid
sean afectadas (ver fig. 2.3 en la pg. 23).
El software de gestin del Grid puede automticamente reenviar trabajos
a otras mquinas del Grid, cuando en una se descubre una falla.
En situaciones crticas de tiempo real, copias mltiples de trabajos importantes pueden ejecutarse en diferentes mquinas a travs del Grid.
Figura 2.3: Cofiabidad en los Sistemas de Grid.
2.9
Administracin
La meta de virtualizar los recursos en el Grid y administrar ms uniformemente

sistemas heterogneos crearn nuevas oportunidades para gestionar mejor una
infraestructura de IT ms grande, y ms dispersa.
Ser ms fcil visualizar la capacidad y utilizacin, hacindolo ms fcil
para los departamentos de IT y as controlar los gastos para recursos de computacin en una organizacin ms grande.
El Grid ofrece administracin de prioridades entre diferentes proyectos.
24
En el pasado, cada proyecto podra haber sido responsable de su propio

hardware de recurso de IT y los gastos asociados con l.
A menudo este hardware podra no estar siempre utilizado mientras otro
proyecto se encontrara en problemas, necesitando ms recursos debido a eventos inesperados.
Con una visin mayor, un Grid puede ofrecer controlar y manejar ms
fcilmente tales situaciones. Como se ilustra en la fig. 2.4 de la pg. 24, los
administradores pueden cambiar gran nmero de polticas que afectan en cmo
las diferentes organizaciones pueden compartir o competir por los recursos.
Figura 2.4: Administracin en los Sistemas de Grid.
2.10
Los Conceptos y Componentes del Grid
A continuacin se introducen varios conceptos del Grid, componentes, y trminos ms detallados.
2.10.
2.10.1
LOS CONCEPTOS Y COMPONENTES DEL GRID
25
Los Tipos de Recursos
Un Grid es una coleccin de mquinas, a veces llamado nodos, recursos,

miembros, servidores, clientes, organizadores, y muchos otros.
Todos ellos aportan grupos de recursos al Grid. Algunos recursos pueden
ser usados por todos los usuarios del Grid, mientras que otros pueden tener
restricciones especficas.
2.10.2
Computacin
El recurso ms comn lo constituyen los ciclos de cmputo proporcionados por

los procesadores de las mquinas en el Grid.
Los procesadores pueden variar en velocidad, arquitectura, plataforma de
software, y otros factores asociados, como la memoria, almacenamiento, y
conexin.
Hay tres formas primarias para aprovechar los recursos de cmputo de un
Grid.
El primero y ms simple es usarlo para ejecutar una aplicacin existente
en una mquina disponible en el grid, en lugar de localmente.
El segundo es para usar una aplicacin diseada para dividir su trabajo
de tal manera que las partes separadas pueden ejecutarse en paralelo en los
diferentes procesadores.
El tercero es ejecutar una aplicacin que precise ser ejecutada muchas veces
en muchas mquinas diferentes en el Grid. Escalabilidad es una medida de
cmo se usan eficazmente los mltiples procesadores en un Grid.
Si los procesadores realizan dos veces una aplicacin completa en la mitad
del tiempo, entonces se dice que es absolutamente escalable.
Sin embargo, puede haber lmites en la escalabilidad cuando las aplicaciones slo pueden ser divididas en un nmero limitado de partes ejecutables
separamente, o si esas partes experimentan alguna otra contencin para recursos de algn tipo de almacenamiento.
26
2.10.3
Almacenamiento
El segundo recurso ms comn en un Grid es el almacenamiento de los datos.

Un Grid que proporciona una visin integrada de almacenamiento de datos es
a veces llamado un Grid de datos.
Cada mquina en el Grid normalmente mantiene alguna cantidad de almacenamiento para uso del grid, aun temporalmente.
El almacenamiento puede ser memoria unida al procesador o almacenamiento secundario, usando el disco rgido u otros medios de almacenamiento
permanente.
La memoria unida a un procesador normalmente tiene un muy rpido
acceso pero es voltil.
Sera mejor usarlo para guadar datos y servir como un almacenamiento
temporal para las aplicaciones ejecutadas.
El almacenamiento secundario en un Grid puede usarse de manera interesante para aumentar la capacidad, la calidad, el compartir, y la fiabilidad de
los datos.
Muchos sistemas de Grid usan sistemas de archivo de red montables tales
como, Andrew File System (AFS), Network File System (NFS), Distributed
File System (DFS), o el General Parallel File System (GPFS). Estos ofrecen
diferentes grados de calidad, seguridad y fiabilidad.
La capacidad puede ser incrementada usando el almacenamiento en mltiples mquinas con un sistema de archivo unificado.
Cualquier archivo individual o base de datos pueden expandirse a varios
dispositivos de almacenamiento y mquinas, eliminando las restricciones de
mxima capacidad, a menudo impuestas por los sistemas de archivo de los
sistemas operativos.
Un sistema de archivo unificado tambin puede mantener un slo espacio
uniforme para el almacenamiento del Grid.
Esto facilita a los usuarios referenciar los datos que residen en el Grid, sin
considerar su ubicacin exacta.
De manera similar, el software especial de base de datos puede federar
2.10.
27
un conjunto de bases de datos individuales y archivos para formar bases de

datos ms amplias y ms comprensivas.
Como se observa en la fig. 2.5 de la pg. 27 el Data Striping significa
escribir o leer sucesivos datos desde o para diferentes dispositivos fsicos, solapando el acceso para un mejor rendimiento; asmismo, con tcnicas adicionales
se aumenta la fiabilidad.
Los sistemas de archivo ms avanzados en un Grid pueden duplicar automticamente conjuntos de datos, para proporcionar redundancia para mayor
fiabilidad y aumento del rendimiento.
Un scheduler de grid inteligente puede ayudar a seleccionar los dispositivos
de almacenamiento apropiados para guardar datos, basados en patrones de
uso.
Los trabajos pueden ser programados ms cerca de los datos, preferentemente en las mquinas directamente conectadas a los dispositivos del almacenamiento que guardan los datos requeridos.
Figura 2.5: Almacenamiento en el Grid.
28
2.10.4
Las Comunicaciones
El crecimiento rpido en la capacidad de comunicacin entre las mquinas

hace que el Grid computing sea prctico, comparado con el limitado ancho de
banda disponible cuando la computacin distribuda emergi por primera vez.
Por consiguiente, no debe ser una sorpresa que otro recurso importante de
un Grid sea la capacidad de comunicacin de datos. Esto incluye las comunicaciones dentro del Grid y fuera de l.
Las comunicaciones dentro del Grid son importantes para enviar trabajos
y sus datos requeridos hacia puntos dentro del Grid.
Algunos trabajos exigen procesar una cantidad grande de datos y no siempre los mismos pueden residir en la mquina que ejecuta el trabajo.
El ancho de banda disponible para tales comunicaciones frecuentemente
puede ser un recurso crtico que puede limitar la utilizacin del Grid.
El acceso de comunicacin externo a Internet, por ejemplo, puede ser valioso al construir motores de bsqueda.
Las mquinas en el Grid pueden tener conexiones a Internet externas, en
adicin a las conexiones entre las mquinas del Grid. Cuando estas conexiones
no comparten la misma ruta de comunicacin, se agregan al ancho de banda
disponible, para acceder a Internet.
A veces se necesitan rutas de comunicacin redundantes para manejar mejor fallas potenciales en la red y el execivo trfico de datos.
En algunos casos se deben utilizar redes de altas prestaciones para satisfacer demandas de trabajos que transfieren cantidades muy grandes de datos.
Un sistema de administracin de Grid puede mostrar mejor la topologa del
Grid y puede resaltar los cuellos de botella de comunicacin. Esta informacin
puede usarse para planificar las actualizaciones del hardware.
2.10.5
El Software y las Licencias
El grid puede tener el software instalado que puede ser demasiado caro para
instalar en cada mquina de ste.
2.10.
29
Usando un Grid, los trabajos que requieren este software son enviados a
mquinas particulares en las cuales este software est instalado.
Cuando las tarifas de licencia son significantes, esta aproximacin puede
ahorrar gastos importantes para una organizacin.
Algn arreglo de licencia de software permite instalarlo en todas las mquinas de un grid pero puede limitar el nmero de instalaciones que pueden usarse
simultneamente en cualquier momento.
El sofware de administracin de licencias registra cuntas copias coexistentes de ste estn usndose y previene que se ejecute un nmero mayor en
un tiempo dado .
Los schedulers de trabajo de Grid pueden configurarse para tener en cuenta
las licencias de software, opcionalmente balancendolas contra otras prioridades o polticas.
2.10.6
El Equipo Especial, Capacidades, Arquitecturas, y Polticas
Las plataformas en el Grid tendrn a menudo diferentes arquitecturas, sistemas operativos, dispositivos, capacidades, y equipos.
Cada uno de estos tems representa un tipo diferente de recurso que el Grid
puede usar con criterio para asignar trabajos a las mquinas.
Mientras algn software puede estar disponible en varias arquitecturas, por
ejemplo PowerPC y x86, tal software es a menudo diseado para ejecutar slo
un tipo particular de hardware y sistema operativo.Tales atributos deben ser
considerados al asignar recursos en el Grid.
En algunos casos, el administrador de un Grid puede crear un nuevo tipo
de recurso artificial que ser usado por el schedulers para asignar el trabajo
segn el tipo de poltica u otras restricciones. Por ejemplo, algunas mquinas
pueden disearse para slo ser usadas para investigacin mdica y otras para
slo participar en el Grid si no se usan para propsitos militares.
30
2.10.7
Los Trabajos y las Aplicaciones
Aunque varias clases de recursos en el Grid pueden compartirse y usarse,

normalmente son accedidos va la ejecucin de una aplicacin o trabajo.
Normalmente se usa el trmino aplicacin como el nivel ms alto de un
porcin de trabajo en el Grid. Sin embargo, a veces el trmino trabajo se
usa equivalentemente.
Las aplicaciones pueden dividirse en cualquier nmero de trabajos individuales, como se ilustra en la fig. 2.6 de la pg. 30; aqullas, a su vez, pueden
dividirse en sub-trabajos.
Figura 2.6: Trabajos y Aplicaciones del Grid.
2.11.
2.11
SCHEDULING, RESERVACIN, Y BARRIDO
31
Scheduling, Reservacin, y Barrido
El sistema del Grid es responsable de enviar un trabajo a una mquina dada

para ser ejecutado.
En el ms simple sistema de Grid, el usuario puede seleccionar una mquina
conveniente para realizar su trabajo y luego ejecutar una orden de Grid, que
enva el trabajo a la mquina seleccionada.
Los sistemas de Grid ms avanzados incluiran un trabajo scheduler de
algn tipo que, automticamente, encuentre la mquina ms apropiada en la
cual ejecutar cualquier trabajo dado, el cual estara esperando ser ejecutado.
Los schedulers reaccionan a la disponibilidad actual de recursos en el Grid.
El trmino scheduling no debe ser confundido con la reservacin de
recursos para mejorar la calidad de servicio.
En un scavenging (barrido) de un sistema Grid, cualquier mquina que
se vuelve ociosa (sin trabajo local que ejecutar) informara su estado al nodo
de administracin del Grid. Este nodo de administracin asignara a esta
mquina el prximo trabajo que se satisfacera por los recursos de la misma.
El scavenging normalmente es llevado a cabo de manera que no obstruya
al usuario.
Si la mquina se pone en estado de ocupada con el trabajo local no-grid,
el trabajo del grid normalmente se suspende o se demora. Esta situacin crea
de alguna manera tiempos de terminacin imprevisibles para los trabajos del
Grid, aunque no molesta a las mquinas donantes de recursos.
Para crear una conducta ms predecible, las mquinas del Grid se dedican
a menudo al Grid y no pueden ser retiradas del mismo para realizar trabajos
externos al Grid. Esto permite al scheduler computar el tiempo aproximado
de realizacin para un conjunto de trabajos, cuando sus caractersticas de
ejecucin son conocidas.
En el prximo paso, los recursos del Grid pueden reservarse por adelantado para un conjunto de trabajos designados. Esto se hace para reunir fechas
tope y garantizar la calidad de servicio.
Cuando las polticas lo permitan, los recursos reservados de antemano podran ser recogidos para ejecutar trabajos de menor prioridad, cuando no estn
32
ocupados durante un perodo de reservacin.

As, varias combinaciones de scheduler, reservacin y barrido, pueden ser
usados para utilizar un Grid ms completamente.
El scheduling y reservacin es bastante directo cuando slo un tipo de recurso, normalmente, CPU, est involucrado. Sin embargo, las optimizaciones
de Grid adicionales pueden ser logradas considerando ms recursos en proceso
de reservacin y planificacin.
Por ejemplo, sera deseable asignar trabajos de ejecucin a las mquinas
ms cercanas a los datos que estos trabajos requieren.
Esto reducira el trfico de la red y posiblemente reducira los lmites de
escalabilidad.
La planificacin ptima, considera mltiples recursos, es por ello que se
la cosidera un problema matemtico difcil. Por consiguiente, tales schedulers
pueden usar heursticas. Estas heursticas son reglas que se disean para mejorar la probabilidad de encontrar la mejor combinacin de schedulers de trabajo
y reservaciones para perfeccionar el rendimiento o cualquier otra mtrica.
2.12
Intragrid a Intergrid
Como se presenta en fig. 2.7 de la pg. 34, el grig ms simple consiste en

slo unas pocas mquinas, todas de la misma arquitectura de hardware y el
mismo sistema operativo, conectadas en una red local. Este tipo de Grid usa
sistemas homogneos, as hay menos consideraciones y pueden ser usados slo
para experimentar con el software de Grid.
Las mquinas usualmente estn en un departamento de una organizacin,
y sus usos como un Grid pueden no requerir una poltica especial de seguridad.
Debido a que las mquinas tienen la misma arquitectura y sistema operativo,
elegir software de aplicacin para dichas mquinas es generalmente sencillo.
Esto podra ser llamarlo una aplicacin de cluster en lugar de Grid .
El siguiente avance sera incluir las mquinas heterogneas. En esta configuracin, hay ms tipos de recursos disponibles. El sistema Grid puede incluir
algunos componentes de scheduling. Tambin puede lograrse el compartimiento de archivos, usando los sistemas de archivo de red.
2.12. INTRAGRID A INTERGRID
33
Las mquinas que participan en el grid pueden incluir uno de los departamentos de la misma organizacin. Tal modelo de grid tambin ser llamado
Intragrid.
Cuando el Grid se extiende a muchos departamentos, las polticas pueden
requerirse para indicar cmo el Grid debe usarse. Por ejemplo puede haber
polticas, para qu tipos de trabajo permite el Grid y cuntas veces.
Puede haber tambin una priorizacin por departamento o por tipos de
aplicaciones que deben tener acceso a los recursos del Grid.
Los datos sensibles en un slo departamento pueden necesitar ser protegido
contra el acceso de trabajos que se ejecutan para otros departamentos.
Las mquinas del Grid especializadas pueden ser agregadas para aumentar
la calidad de servicio, en lugar de depender completamente de los recursos de
barrido.
El Grid puede crecer geogrficamente en una organizacin que tiene los
medios en diferentes ciudades.
Las conexiones de comunicaciones dedicadas pueden usarse entre estas facilidades y el Grid.
En algunos casos, VPN tunneling u otras tecnologas pueden usar Internet
para conectar las diferentes componentes de la organizacin. La seguridad
aumenta una vez que los lmites de cualquier facilidad se superan.
El Grid puede crecer para ser jerrquicamente organizado para reducir la
contencin implicada por el control central, aumentando la escalabilidad.
Un Grid puede crecer, cruzar los lmites de la organizacin y puede usarse
para colaborar en los proyectos de inters comn. Esto se conoce como un
Intergrid (como se ve en la fig. 2.8 de la pg. 2.8).
Habitualmente se requieren los niveles ms altos de seguridad en esta configuracin para prevenir posibles ataques y espionajes.
El Intragrid ofrece la posibilidad de comerciar recursos a un pblico ms
amplio.
34
Figura 2.7: Un Grid ms Simple.
Figura 2.8: Un Intergrid ms Complejo.
2.13. CONSTRUCCIN DEL GRID
2.13
35
Construccin del Grid
Un Grid ad hoc puede instalarse por unos programadores en su tiempo libre,

pero como el Grid crece, y los usuarios se vuelven ms dependientes de l para
el trabajo misin-crtico, un grado de planeamiento es esencial.
Es mejor entender los requerimientos de la organizacin y escoger las tecnologas del Grid que mejor se adpten a estos requerimientos.
Esta seccin se discuti algunas consideraciones de planificacin y componentes del Grid que cumplen con los requerimientos.
2.14
Planificacin del despliegue
El uso de un Grid nace a menudo de una necesidad de incrementar recursos

de algn tipo. Por ello una de las primeras consideraciones son el hardware
disponible y cmo se conecta va una LAN o WAN.
Luego, una organizacin puede querer agregar el hardware adicional para
aumentar las capacidades del Grid. Es importante entender las aplicaciones a
ser usadas en l.
Sus caractersticas pueden afectar las decisiones de cmo escoger y configurar el hardware y sus datos conectados.
2.14.1
Seguridad
La seguridad es un factor mucho muy importante; planear y mantener un grid

computing convencional distribuido dnde el compartimiento de datos reduce
el volumen de la actividad.
En un Grid, las mquinas miembro se configuran para ejecutar los programas en lugar de slo mover datos. Esto es lo que hace un Grid potencialmente
frtil para virus y programas de Caballo de Troya.
Por esta razn, es importante entender qu componentes exactamente del
Grid deben afianzarse para detener rigurosamente cualquier clase de ataque.
Adems, es importante comprender los problemas involucrados al autenti-
36
car usuarios y ejecutar adecuadamente las responsabilidades que esto implica.
2.14.2
Organizacin
Las consideraciones tecnolgicas son importantes al desplegar un Grid. Sin

embargo, los problemas comerciales y de organizacin pueden ser igualmente
importantes.
Es primordial entender cmo los departamentos en una organizacin interactan, operan y contribuyen al todo.
Frecuentemente hay barreras construdas entre los departamentos y proyectos para proteger sus recursos, en un esfuerzo de aumentar la probabilidad
de xito.
Sin embargo, volviendo a preocuparse por algunas de estas relaciones, se
puede encontrar, que ms compartimiento de recursos a veces puede beneficiar
a la organizacin entera.
Por el ejemplo, un proyecto que se encuentra detrs del scheduler y encima
del budget no puede admitirse el lujo de conseguir los recursos requeridos para
resolver el problema.
Un Grid agregara una medida de seguridad, proporcionando un margen
extra de capacidad de recurso, necesitado para finalizar el proyecto. De manera
similar, un proyecto en sus fases tempranas cuando los recursos de computadora no estn utilizndose totalmente, puede donarlos a otros proyectos que
los necesitan.
Un Grid tambin ofrece la habilidad para la administracin de organizacin, y ver as el cuadro de prioridad ms grande y reaccionar ms rpidamente
cambiando la utilizacin del recurso, prioridades, y polticas.
2.15
Componentes del Software Grid
En esta seccin se presenta algunos de los componentes importantes que deben

discutirse antes de disear una arquitectura de Grid Computing.
2.15. COMPONENTES DEL SOFTWARE GRID
2.15.1
37
Componentes de administracin:
Cualquier sistema de Grid tiene algunos componentes de administracin.

Primero hay un componente que guarda , la muestra de los recursos disponibles para el Grid, y qu usuarios son miembros de l. Esta informacin se
usa principalmente para decidir dnde deben asignarse los trabajos del Grid.
Segundo, hay componentes de medida que determinan, las capacidades de
los nodos y su proporcin de utilizacin actual en cualquier momento dado.
Tal informacin se usa tambin para determinar la robustez del Grid, advirtiendo al personal sobre los problemas como, los paros, congestin, u over
commitment.
Esta informacin tambin es usada para determinar modelos de uso globales y estadsticas, as como para registrar y responder por el uso de recursos
del Grid.
Tercero, el software de administracin del Grid avanzado puede manejar
muchos aspectos automticamente.
Esto se conoce como autonomic computing, o computing de recuperacin orientada. Este software se recuperara automticamente de diversos
tipos de fracasos del Grid y paros, encontrando maneras alternativas de conseguir el trabajo procesado.
2.15.2
Software Servidor
Cada mquina que contribuye con recursos tpicamente necesita conectarse

como un miembro del Grid e instalar algn software que maneje el uso de los
recursos del Grid. Habitualmente, alguna clase de proceso de identificacin
y autenticacin deber realizarse antes de que una mquina pueda unirse al
Grid.
Un certificado de mando puede usarse para establecer la identidad de la
mquina donante, tambin como los usuarios y el Grid mismo.
Algunos sistemas de Grid proporcionan su propio login, mientras otros
dependen de los sistemas operativos procedentes para la autenticacin del
usuario.
38
En el ltimo caso, un sistema de mapeo ID de usuario puede ser necesario

para unir adecuadamente los derechos del usuario a las diferentes mquinas.
Esto es tpicamente mantenido de forma manual por un administrador del
Grid.
l determina qu usuario ID puede poseer qu mquina del Grid y qu
base de datos o registros.
De esta manera, cuando los trabajos del Grid se presentan a diferentes
mquinas para un usuario, donde el ID del usuario de la mquina local es
usado para determinar sus derechos.
En algunos sistemas de Grid, es posible unir el mismo sin ninguna autenticacin especial. Y en otros, es posible para cualquier usuario presentar
trabajos al Grid.
Tales sistemas pueden ser convenientes para set up pero no para despliegues
mas grandes, debido a problemas de seguridad serios que ellos ocacionaran.
El sistema de Grid hace que la informacin sobre los recursos recientemente
agregados se encuentre disponibles a lo largo de l.
La mquina donante normalmente tendr alguna clase de monitor que
determine o mida cuan ocupada est y la proporcin o cantidad de recursos
utilizados.
Esta informacin es bubbled up al software de direccin del Grid y usada
para scheduler de acuerdo con esos recursos.
En un sistema barrido de basura, esta informacin le dice al software de
direccin del Grid, cundo la mquina est ociosa y disponible para el trabajo.
Es importante que el software instalado en una mquina dada pueda aceptar un trabajo ejecutable desde un sistema de adnimistracin de Grid y ejecutarlo.
El software de gestin de Grid debe ser capaz de recibir el archivo ejecutable
o seleccionar el propio, desde copias preinstaladas en la mquina donante. ste
lo ejecuta y el resultado es enviado devuelta al cliente.
Implementaciones mas avanzadas pueden dinamicamente ajustar la prioridad de un trabajo en ejecucin suspenderlo y continuar despus, o controlarlo
con la posibilidad de continuar su ejecucin en una mquina diferente.
2.15. COMPONENTES DEL SOFTWARE GRID
39
Estos tipos de acciones pueden ser necesarios para responder a problemas

de nivelacin de carga, prioridad o cambios de poltica en el Grid.
2.15.3
Software de Sumisin
Normalmente cualquier mquina miembro del Grid puede usarse para realizar
los trabajos e iniciar sus requerimientos.
Sin embargo, en algunos sistemas de Grid, esta funcin se lleva a cabo como un componente separado, instalado en nodos de sumisin o clientes de
sumisin. Cuando un Grid se construye usando recursos especializados en lugar de recursos scavenged el software de sumisin separado es normalmente
instalado en la estacin de trabajo.
2.15.4
Administracin del Grid Distribuido
Los grid ms grandes normalmente pueden tener una topologa organizacional

o jerrquica uniendo las conexiones topolgicas. Es decir, que las mquinas
localmente conectadas con una LAN forman un cluster de mquinas. ste
puede organizarse en una jerarqua que consiste en cluster de cluster.
El trabajo involucrado en la administracin del Grid se distribuye para
aumentar su escalabilidad.
Programa un trabajo subordinado directamente a la mquina para ejecutarlo.
En cambio el trabajo se enva a un programador de menor nivel que ocupa
un conjunto de mquinas. Este se se ocupa de la asignacion de maquinas
especificas.
De la misma forma se distribuye la coleccion de informacion estadstica.
Los cluster de menor nivel reciben la informacin de actividad, la agregan
y las envan desde las mquinas individuales a los nodos de direccin de niveles
ms altos en la jerarqua.
40
2.15.5
Schedulers
La mayora de los sistemas de Grid incluyen alguna clase de software de programacin de trabajo.
Este software localiza una mquina en la cual ejecutar un trabajo de grid
que ha sido presentado por un usuario.
En los ms simples de los casos, puede asignar ciegamente los trabajos en
forma round-robin a la prxima mquina cumpliendo con los requerimientos
del recurso. Sin embargo hay ventajas al usar un scheduler ms avanzado.
Algunos schedulers llevan a cabo un sistema de prioridad de trabajo. Esto
a veces se hace usando varias colas de trabajo, cada uno con una prioridad
diferente. Cuando las mquinas del Grid estn disponibles para ejecutar los
trabajos, stos son tomados en orden de prioridad.
Varias clases de polticas son llevadas a cabo usando los programadores.
Las polticas pueden incluir los varios tipos de restricciones en los trabajos,
los usuarios, y recursos. Puede haber una poltica de que restrinja la ejecucin
de trabajos de Grid en ciertos momentos del da.
Los schedulers normalmente reaccionan a la carga inmediata del Grid.
Ellos usan la informacin de medida, sobre la utilizacin actual de mquinas
para determinar cules no estn ocupadas, antes realizar un trabajo.
Los schedulers pueden organizarse en una jerarqua.
Por ejemplo, un meta-scheduler puede enviar un trabajo a un scheduler
del cluster o a otros scheduler de menor nivel en lugar de a una mquina
individual.
Los schedulers ms avanzados supervisarn el progreso de trabajos programados conduciendo el flujo de trabajo global. Si los trabajos se pierden debido
al sistema o paros de la red, un buen scheduler reenviara automticamente el
trabajo a otra parte.
Sin embargo, si un trabajo parece estar en un loop infinito y alcanza una
interrupcin mxima, entonces no deberan reprogramarse tales trabajos.
Tpicamente, los trabajos tienen diferentes tipos de cdigos de realizacin,
algunos de los cules son convenientes para el reenvo y otros no.
2.16. OBSERVACIN, DIRECCIN, Y MEDICIN
41
Reservar los recursos en el Grid de antemano se realiza mediante un sistema reservacin.

Este es primero, un sistema basado en un calendario para reservar los
recursos con perodos de tiempo especfico y as evitar que otros reserven el
mismo recurso al mismo tiempo.
Este tambin debe poder quitar o suspender trabajos que podran estar ejecutndose en cualquier mquina o recurso, cuando el perodo de la reservacin
es alcanzado.
2.15.6
Las Comunicaciones
Un sistema de Grid puede incluir un software para ayudar a los trabajos a

comunicarse entre s.
Por ejemplo, una aplicacin puede dividirse en un gran nmero de subtrabajos. Cada uno de estos es un trabajo separado en el Grid. Sin embargo,
la aplicacin puede ser llevada a cabo por un algoritmo que requiere que los
sub-trabajos se comuniquen alguna informacin entre ellos.
Los sub-trabajos necesitan ser capaces de localizar otros sub-trabajos especficos, establecer una conexin de comunicaciones con ellos, y envar los
datos apropiados.
El estndar abierto Message Passing Interface (MPI) y cualquier otra variacin es a menudo includa como parte del sistema de Grid slo para este
tipo de comunicacin.
2.16
Observacin, Direccin, y Medicin
Se mencion que los schedulers reaccionan ante las cargas actuales en el Grid.
Habitualmente, el software servidor incluir algunas herramientas que midan la carga actual y la actividad en una mquina dada usando, las facilidades
de un sistema operativo o por medicin directa.
Este software es a veces llamado sensor de carga.
Algunos sistemas de Grid proporcionan los medios para implementar sen-
42
sores de carga personalizada en lugar de CPU o recursos del almacenamiento.

Tal informacin de medicin es til no slo para programar sino tambin
para descubrir el uso de patrones globales en el Grid.
Las estadsticas pueden mostrar tendencias que pueden sealar la necesidad de un hardware adicional. Tambin, la informacin de medicin sobre
trabajos especficos pueden ser recolectados y usarse para predecir mejor los
requerimientos de recurso del trabajo que se ejecutara la prxima vez.
Cuanto mejor sea la prediccin ms eficiente ser el trabajo del Grid.
La informacin de medicin tambin puede ser guardada con propsitos
de contabilidad, para formar la base, la ejecucin de un recurso de Grid , o
para manejar las prioridades de forma ms justa.
La informacin tambin puede ser mostrada en varios formatos para visualizar mejor actividad y utilizacin del Grid.
2.17
Usar un Grid: Perspectivas de Usuario
2.17.1
Conectar e instalar el software de Grid
Un usuario se conecta primero como un usuario de Grid, e instala el software

en su propia mquina.
l tambin puede conectar su mquina como un servidor en Grid.
Conectarse en l puede requerir la autenticacin con propsitos de seguridad.
El usuario efectivamente establece su identidad con un certificado de autoridad. Esto no debe hacerse solamente va Internet.
La autoridad hace que un certificado este disponible para las necesidades del software para asegurar as la identidad de un usuario de Grid y sus
requerimientos.
Pasos similares pueden ser requeridos para identificar la mquina donante.
El usuario tiene la responsabilidad de guardar y proteger sus credenciales
de grid.
2.18. REGISTRARSE EN EL GRID
43
Una vez el usuario y/o la mquina se autentican, el software del Grid se

proporciona al usuario para instalar en su mquina con propsitos de usar el
Grid, as como servir a ste.
Este software puede ser automticamente pre-configurado por el sistema de
administracin del Grid para conocer la direccin de comunicacin, los nodos
de direccin en el Grid e informacin de identificacin del usuario o mquina.
De esta manera, la instalacin puede realizarse haciendo un click con un
mnimo de interaccin requerida por parte del usuario.
En las instalaciones del Grid menos automatizadas, puede pedirse al usuario que identifique el nodo de direccin del mismo y posiblemente otra informacin de configuracin.
l puede escoger limitar los recursos servidos al Grid, las veces que su
mquina es utilizada por dicho Grid, y otras restricciones relacionadas con la
poltica del sistema.
El usuario tambin puede que necesite informar al administrador del Grid
que IDs de usuario son suyos en otras mquinas que existen en el Grid.
2.18
Registrarse en el Grid
Para usar el Grid la mayora de los sistemas exigen al usuario que se registre
en un sistema usando el ID de usuario que se matricula en el Grid.
Otros sistemas de Grid pueden tener su propio login de Grid ID separado
del sistema operativo.
Un registro del Grid es usualmente ms conveniente para los usuarios de
Grid. Este elimina los problemas de conexin de ID entre las diferentes mquinas.
Tambin hace que el Grid se parezca ms a una gran computadora virtual
en lugar de una conjunto de mquinas individuales.
Por ejemplo, Globus lleva a cabo un modelo de login que mantiene al
usuario registrado por una cantidad especifica de tiempo, aun cuando l se
desconecta y vuelve al sistema operativo o cuando la mquina es reanudada.
Una vez registrado el usuario puede solicitar al Grid y realizar los trabajos.
44
Algunas aplicaciones de del Grid permiten algunas funciones de solicitud

si el usuario no est conectado en l o aun cuando el usuario no este registrado
(enrolled) en el Grid.
2.19
Solicitar y Realizar Trabajos.
El usuario normalmente realizar algunas preguntas para verificar y para ver

cuan ocupado est el Grid, para ver cmo sus trabajos realizados estn progresando, y para buscar los recursos en l.
Los sistemas del Grid habitualmente proporcionan las herramientas de
lnea de orden as, como interfaces grficas de usuario (GUIs) para las preguntas.
Las herramientas de lnea de orden son especialmente tiles cuando el usuario quiere escribir una documento que automatiza una sucesin de acciones.
Por ejemplo, el usuario podra escribir un documento para que busque un
recurso disponible, realice un trabajo para l, mire el progreso del trabajo, y
presente los resultados cuando el trabajo ha terminado.
La realizacin del trabajo normalmente consiste en tres partes, aun cuando
hay slo una orden requerida.
Primero, algunos datos de entrada y posiblemente programas ejecutables
o la ejecucin de un archivo de documento, se debe enviar a la mquina para ejecutar el trabajo; enviar la entrada se llama escenario de los datos de
entrada.
Alternativamente, pueden pre-instalarse los datos y archivos del programa
en las mquinas del Grid o hacerlas accesibles va un montable sistema de
archivo de red de computadoras.
Cuando el Grid consiste en mquinas heterogneas, puede haber archivos
de programa ejecutables mltiples, cada uno compilado en diferentes plataformas de mquinas en el Grid.
Un rasgo bueno proporcionado por algunos sistemas Grid es registrar estas
versiones mltiples del programa, para que el sistema de Grid pueda escoger
automticamente una versin que se conecte correctamente a la mquina de
l, la cual ejecutar el programa.
2.19. SOLICITAR Y REALIZAR TRABAJOS.
45
Algunas tecnologas de Grid requieren que el programa y los datos de la

entrada primero se procesen o incluyan (wrappered) de alguna manera
por el sistema de Grid. Esto puede hacerse para agregar controles de ejecucin protectores alrededor de la aplicacin o simplemente recolectar todos los
archivos de datos en uno.
Segundo, el trabajo se ejecuta en la mquina del Grid.
El software de Grid que se ejecuta en la mquina donante, ejecuta el programa en un proceso a favor del usuario.
Puede usar a un ID de usuario comn en la mquina o puede usar ID de
usuario propio del usuario , dependiendo de que tecnologa de Grid se usa.
Algunos sistemas de Grid llevan a cabo un sandbox protector alrededor
del programa, para que este ltimo no cause ninguna dao a la mquina
servidora si encuentra un problema durante la ejecucin. Pueden restringirse
derechos para acceder archivos y otros recursos en la mquina del Grid.
Tercero, se envan de vuelta los resultados del trabajo al cliente.
En algunas aplicaciones, los resultados intermedios pueden ser vistos por
el usuario que realiz el trabajo.
En algunas tecnologas de Grid que no envian de vuelta automticamente los datos del resultado al usuario, deben ser explcitamente enviados al
usuario, posiblemente usando un sistema de archivo conectado a una red de
computadoras.
Los documentos tambin son tiles para realizar una serie de trabajos,
para una aplicacin espacial de parmetro, por ejemplo.
Algunos problemas del cmputo consisten en una bsqueda de resultados
deseados basados en algunos parmetros de entrada. La meta es encontrar los
parmetros de entrada que producen los mejores resultados deseados.
Para cada parmetro de entrada, un trabajo separado se ejecuta para encontrar el resultado a ese valor.
La aplicacin entera consiste en muchos trabajos como estos, los cuales
exploran los resultados un gran nmero de valores de parmetro de entrada.
Los documentos normalmente se usan para enviar los sub-trabajos, cada
uno, recibiendo sus propios valores de parmetro particular.
46
Las entradas de parmetro a veces pueden ser ms complejas, que solo

un nmero. A veces un conjunto de datos de entrada diferente representa el
parmetro input.
Los documentos ayudan a automatizar la gran variedad de problemas del
estudio espacial de parmetros.
Para entradas espaciales de parmetro ms simple, algunos productos de
grid proporcionan un GUI para realizar una serie de sub-trabajos, cada uno
con valores de parmetro de entrada diferentes.
Cuando hay un gran numero de sub-trabajos, el trabajo requerido para
recolectar los resultados y producir el resultado final es normalmente realizado
por un slo programa, mientras se ejecuta en la mquina en el momento de
realizacin del trabajo.
Si hay un gran nmero de sub-trabajos requeridos para una aplicacin, el
trabajo de compilar los resultados tambin podra ser distribuido.
Por ejemplo, el sub-trabajo que envie ms sub-trabajos al Grid sera responsable de recolectar y agregar los resultados que estos obtuvieron.
2.20
Configuracin de Datos
Los datos obtenidos por los trabajos del Grid simplemente pueden organizarse
adentro y a fuera del sistema de Grid.
Sin embargo, dependiendo de su tamao y el nmero de trabajos, este puede potencialmente agregarse a una gran cantidad de trfico de los datos. Por
esta razn, algunas ideas se dan acerca de cmo obtener el mnimo movimiento
de los datos en el Grid.
Por ejemplo, si va a haber un nmero muy grande de sub-trabajos ejecutandose en la mayora los sistemas del Grid para una aplicacin que se
ejecutara repetidamente, los datos que ellos usan pueden copiarse para cada
mquina y residir hasta la prxima vez que se ejecute una aplicacin. Esto es
mejor que usar un sistema del archivo conectado a una red de computadoras
para compartir estos datos, porque en tal sistema de archivo, los datos seran
efectivamente movidos desde una ubicacin central cada vez que la aplicacin
se ejecute.
2.21. MONITOREO DEL PROGRESO Y RECUPERACIN
47
Esto es cierto a menos que el sistema de archivo lleve a cabo una exclusiva
copia o duplique los datos automticamente.
Hay muchas consideraciones en la planificacin eficiente de la distribucin
y compartimiento de datos en un Grid.
Este tipo de anlisis es necesario para grandes trabajos para as poder
utilizar bien el grid y no crear cuellos de botella innecesarios.
2.21
Monitoreo del Progreso y Recuperacin
El usuario puede solicitar el sistema de Grid, para ver cmo su aplicacin y

sus sub-trabajos estn progresando.
Cuando el nmero de sub-trabajos crece, se vuelve mas difcil de listarlos
a todos en una ventana grfica. En cambio puede haber simplemente un slo
grfico grande de barra que puede mostrarlos.
Es ms difcil para el usuario decir si algn sub-trabajo particular no se
ejecuta apropiadamente.
Un sistema de Grid, junto con su scheduler de trabajo, proporciona a
menudo algn grado de recuperacin para sub-trabajos que fallan.
Un trabajo puede fallar debido a un:
Error de Programacin: El trabajo se detiene alguna parte con alguna
falla de programa.
Fallo de Hardware : La mquina o dispositivos que se usan dejan de
trabajar de alguna manera.
Interrupcin en las Comunicaciones: Un camino de comunicacin a la
mquina ha fallado o ha sido cargado excesivamente con otro trfico de
datos.
Lentitud Excesiva: El trabajo podra estar en un loop infinito o el progreso de trabajo normal puede ser limitado por otro proceso que se ejecuta
con una prioridad mayor.
No siempre es posible determinar automticamente si la razn del fracaso
48
de un trabajo es debido a un problema con el diseo de la aplicacin o si es

debido a los fracasos de varios tipos en la infraestructura del sistema del Grid.
Los schedulers se disean a menudo para categorizar los fracasos del trabajo de alguna manera y automticamente rehacer stos para que ellos tengan
xito, mientras se ejecuten en otra parte del Grid.
En algunos sistemas, el usuario est informado sobre cualquier fracaso del
trabajo y debe decidir si emitir una orden para intentar reejecutar los trabajos
fallados.
Las aplicaciones de Grid pueden disearse para automatizar el monitoreo y
recuperacin de sus propios sub-trabajos usando las funciones proporcionadas
por las interfaces de programacin (APIs) de aplicacin del software de sistema
de Grid.
2.22
Reservar recursos
Para mejorar la calidad de un servicio, el usuario puede acordar reservar un

conjunto de recursos por adelantado para su uso exclusivo o de mayor prioridad.
Una analoga del sistema de calendario puede usarse aqu.Tal sistema de
reservacin tambin puede usarse junto con el hardware planeado o eventos
de mantenimiento de software, cuando el recurso afectado no estn disponible
para el uso del Grid.
En un Grid de recoleccin de residuos, no es posible reservar las mquinas
especficas de antemano. En cambio, los sistemas de direccin de Grid pueden
asignar un fragmento ms grande de su capacidad para una reservacin dada
para permitir la posibilidad de que algunos de los recursos se vuelvan no
disponibles.
Esto debe hacerse junto con herramientas que han perfilado la capacidad
de trabajo de Grid para tener las estadsticas fiables sobre la habilidad de
dicho Grid y as dar la reservacin.
2.23. USAR UN GRID: LA PERSPECTIVA DE UN ADMINISTRADOR49
2.23
Usar un Grid: La Perspectiva de un Administrador
2.23.1
Planeacin
El administrador debe entender los requerimientos de la organizacin del Grid,

para elegir mejor las tecnologas del Grid, que satisfagan esos requerimientos.
Las siguientes secciones describen brevementelos pasos que el administrador
debe tomar para manejar el Grid.
Se sugiere que se comience por desplegar un pequeo Grid, para aprender
sobre su instalacin y direccin, antes de tener que confrontar los problemas
ms complicados involucrados con un Grid grande.
2.23.2
Instalacin
Primero, el sistema de Grid seleccionado debe instalarse un conjuntode mquinas apropiadamente configuradas. Estas mquinas usando redes con amplitud
suficiente para otras mquinas en el Grid.
Es importate entender los escenarios de fracaso para el sistema de Grid
dado, de manera que este continu operando aun cuando cualquiera de las
mquinas de direccin falle de alguna manera.
Las mquinas deben configurarse y conectarse para facilitar los escenarios
de recuperacin.
Cualquier base de datos crtica u otros datos esenciales para guardar la
muestra de los trabajos, los miembros del Grid, y las mquinas, stos deben
tener posibilidad de backups.
Adems, los certificados claves pblicos deben tener una copia de seguridad
y las claves privadas deben guardarse en un lugar seguro inaccesible por otros.
Despus de la instalacin, el software del Grid puede necesitar ser configurado para la direccin de la red local e IDs.
El administrador normalmente requerir el acceso base a las mquinas
conductoras en el grid.
En algunos sistemas de Grid, l necesitar tambin el acceso base a las
50
mquinas servidoras requeridas para instalar el software tambin en aquellas.

El software a ser instalado en las mquinas servidoras puede necesitar ser
personalizado que para pueda encontrar automticamente las mquinas de
direccin (management) del Grid e incluir las claves pblicas pre-instaladas
para el Grid.
Este software puede proporcionarse para servidores potenciales en un FTP
o el servidor equivalente o sea disponible en los medios de comunicacin fsicos.
Una vez, que el Grid es operacional, puede haber software de aplicacin
y datos que deben ser tambin instalados en las mquinas servidoras. Este
software puede tener restricciones especficas de autorizacin, las cuales deben
entenderse y adherirse. Algunos sistemas de Grid incluyen herramientas para
ayudar con la direccin de la autorizacin de un Grid amplio. Este puede
ayudar seguir las reglas de autorizaciones y explotar eficazmente esas autorizaciones.
2.24
Matriculacin de Direccin de Servidores y Usuarios
Una tarea contnua para el administrador del grid es dirigir a los miembros
del Grid, a las mquinas servidoras de recursos y los usuarios.
Los usuarios pueden organizarse como grupos de proyecto.
El administrador es responsable para controlar los derechos de los usuarios
en el Grid.
Las mquinas donantes pueden tener derechos de acceso que requieren
tambin la direccin.
La ejecucin de trabajos de Grid en las mquinas donantes puede hacerse
bajo un especial ID usuario de Grid a beneficio de los usuarios que realizan
los trabajos.
Los derechos de stos IDs de usuario de grid deben ser apropiadamente
puestos para que los trabajos no permitan el acceso a las partes de la mquina
donante en las cuales el usuario no esta registrado.
Cuando los usuarios se conectan al Grid, su identidad debe establecerse
positivamente y debe entrar en el certificado de autoridad.
2.25. CERTIFICADO DE AUTORIDAD
51
El usuario y sus credenciales de certificado deben ser agregadas a la lista

del usuario usando el software apropiado para el sistema de Grid desplegado.
En algunos casos, el administrador debe propagar la informacin del usuario a varias o todas las mquinas.
Tambin, cuando el sistema de Grid depende principalmente del sistema
operativo, para el login del usuario, el administrador puede necesitar para
agregar entradas para perfilar al usuario del Grid especficos sistema operativo
de IDs de usuario en las mquinas donantes.
Una actividad de registro similar normalmente se exige para registrar
mquinas donantes en el Grid.
La identidad de mquina se establece y registra con el certificado la autoridad.
El administrador del Grid debe estar un acuerdo con el administrador de
la mquina donante sobre el IDs de usuario, software, derechos de acceso, y
cualquier restriccin de poltica.
El administrador debe introducir las credenciales de identificacin de la
mquina, direcciones, y caractersticas de recurso usando el software apropiado
para registrar la mquina servidora del Grid.
En algunos casos, el administrador puede necesitar propagar esta informacin manualmente a otras mquinas en el Grid.
Los procedimientos correspondientes para quitar usuarios y mquinas deben ejecutarse por el administrador.
2.25
Certificado de Autoridad
Es crtico asegurar los ms altos niveles de seguridad en un Grid ya que ste

se disea para ejecutar un cdigo y no slo para compartir datos. As, este
puede ser frtil para virus, los Trojan horses, y otros ataques, si el sistema de
Grid se compone de alguna forma.
El certificado de autoridad para mantener una fuerte seguridad del Grid.
Una organizacin puede escoger usar un externo certificado de autoridad
u operar uno ella misma.
52
Usted debe poder confiar en el certificado de autoridad para adherirse

estrictamente a sus responsabilidades.
Las responsabilidades primarias de un certificado de autoridad son:
Identificar positivamente las entidades que piden los certificados.
Emitir, quitar, y archivar los certificados.
Proteger al servidor del certificado de autoridad.
Mantener un namespace de nombres nicos para los dueos del certificado.
El servidor firma los certificados a aqullos que necesiten autenticar entidades.
Actividad de Registracion.
Brevemente, un certificado de autoridad se basa en un sistema del encriptacin de clave pblica.
En este sistema, se generan las claves de a pares, una clave pblica y una
privada.
Cualquiera de las dos puede usarse para encriptar algunos datos, tal que
la otra se necesita descifrarlo.
La clave privada es guardada por el dueo y nunca revelada a nadie, y la
pblica es dada a cualquiera.
Un certificado de autoridad es usado para mantener estas claves pblicas
y garantizar a quienes ellas pertenecen.
Cuando un usuario usa su clave privada para encriptar algo, el receptor
usa la correspondiente clave pblica para descifrarlo.
El receptor sabe que solo la clave pblica puede descifrar el mensaje correctamente.
Sin embargo, cualquiera podra interceptar este mensaje y podra descifrarlo porque cualquiera puede conseguir la clave pblica original.
Si el creador encripta doblemente el mensaje con su clave privada y la clave
pblica del destinatario, una segura conexin de comunicacin se forma.
2.26.
ADMINISTRACIN DE RECURSOS
53
El receptor usa su clave privada para descifrar el mensaje y luego usa la

clave pblica del remitente para la segunda decriptacin.
Ahora el destinatario sabe que si el mensaje se descifra apropiadamente,
slo el remitente lo podra haber enviado y adems, este sabe que slo el
receptor al que se dirigio podr descifrarlo.
Lo bueno de todo esto es que nadie tiene que llevar en forma segura una
clave de encriptacin del remitente al receptor, como debe hacerse para los
sistemas del encriptacin convencionales, y cualquier alteracion en la comunicacin se revela.
As, este puede ser fertil para virus y, los Trojan horses, y otros ataques si
el sistema de grid se compone de alguna forma.
Un intercambio similar se usa para obtener la clave pblica de alguien
desde el certificado de autoridad, para que el usuario sepa que l ha recibido
una clave pblica inalterada para el usuario deseado.
2.26
Administracin de Recursos
Otra responsabilidad del administrador es manejar los recursos del Grid.

Esto incluye establecer los permisos para los usuarios del Grid para usar los
recursos, as como ruteo del uso del recurso y llevar a cabo un correspondiente
sistema de contabilidad o registro.
El uso de estadsticas es til en la identificacin de direcciones en una
organizacin que puede requerir la adquisicin hardware adicional, la reduccin
de hardware en exceso para reducir los costos, y ajustes de prioridades y
polticas para lograr una utilizacin ms justa o lograr mejor las metas globales
de una organizacin.
Algunos componentes del Grid, normalmente, los schedulers de trabajo,
tienen provisiones para reforzar prioridades y polticas de varios tipos.
Es responsabilidad del administrador configurarlos para el mejor logro de
los objetivos de la organizacin global.
Los administradores de licencia de software pueden usarse en un Grid para
controlar la utilizacin apropiada. stos pueden configurarse para trabajar
54
con schedulers de trabajo y para priorizar el uso de las licencias limitadas.
2.27
Compartir Datos
Para Grid pequeos, el compartir datos puede ser bastante fcil, usando los
sistemas de archivo existentes, conectados a una red de computadoras, a bases
de datos, o protocolos estndar de transferencia de datos. Cuando un Grid
crece y los usuarios se vuelven dependientes de cualquiera de los almacenes de
almacenamiento de datos, el administrador debe considerar los procedimientos
para mantener copias de seguridad y rplicas, para mejorar as la realizacion.
Todos lo que se refiere a la direccin de recursos se aplican a los datos en
el Grid.
2.28
Usar un Grid:Una Perspectiva del Diseador

de la Aplicacin
Las aplicaciones de Grid pueden categorisarse en una de las siguiente tres

categoras:
Aplicaciones que no se habilitan por usar los procesadores mltiples pero
pueden ejecutarse en diferentes maquinas.
Aplicaciones que ya son diseadas para usar los procesadores mltiples
de un conjunto del Grid.
Aplicaciones que necesitan ser modificadas o reescritas para aprovecharse
mejor un Grid.
La ltima categora es de inters para diseadores de aplicacin de Grid.
Ellos encontrarn una necesidad por las herramientas para depurar y medir la
conducta de aplicaciones del grid. Tales herramientas basadas son aun nuevas.
Puede ser til para diseadores configurar un Grid pequeo para poder
usar los depuradores en cada mquina, para as controlar y mirar los funcionamientos detallados de las aplicaciones. Ya que el proceso de depuracin
2.29.
EL PRESENTE Y EL FUTURO DEL GRID
55
puede desviar ciertas precauciones de seguridad, puede no siempre ser eficz

para permitir tal depuracin en un Grid de produccin.
Globus es ms un equipo de herramientas del diseador (toolkit) para construir componentes de grid, en lugar de un el sistema de Grid comprensivo. Este
posee los componentes bsicos necesarios para construir nuevos medios para
administrar funcionamientos del Grid, medicin, reparacin, y depuracin de
aplicaciones.
Las herramientas que conforman las interfaces de la Arquitectura de Servicios del Grid Abierta surgiendo (OGSA)sern utilizables en varios sistemas
de Grid del verndedor.
2.29
El Presente y el Futuro del Grid
El toolkit de Globus es un juego de herramientas til para construir un Grid.

Su fuerte es un modelo de alta seguridad, con una provisin para jerrquicamente colectar datos sobre el Grid, as como facilidades bsicas para implementar un simple, world-spanning grid.
El Globus crecer con el tiempo promete extenderse a travs del trabajo
de muchas organizaciones que estn desarrollando sus capacidades.
La mayora de los sistemas de Grid incluyen algn schedulers de trabajo,
pero como reas ms amplias de medicin de Grid, habr una necesidad para
ms meta-schedulers que puedan manejar colecciones de clusters diversamente
configurados y los grid ms pequeos.
Estos schedulers evolucionarn para programar bien los trabajos, considerando mltiples recursos en lugar de slo utilizacin de CPU.
Ellos tambin extendern su alcance para llevar a cabo una mejor calidad de servicio, usando reservaciones, redundancia, e historia de perfles de
trabajos y la calidad de un Grid.
Hoy, los sistemas de Grid todava estn en las fases tempranas para proporcionar un almacenamiento y compartir datos virtuales de manera fiable,
bien realizada, y automticamente recuperables.
Se vern productos que colocan esta tarea en un conjunto de Grid, creando
datos de todo tipo, y logrando una mejor calidad, integracin con la progra-
56
macin, fiabilidad, y capacidad.

El computing autnomo tiene el objetivo de hacer el trabajo del administrador ms fcil, automatizando varias tareas complicadas involucradas en
la administracin de un Grid. stos incluyen identificacin de problemas en
tiempo real y una rpida iniciacin de acciones correctivas, antes de que ellos
daen seriamemte el Grid.
La Arquitectura de Servicios de Grid Abierta (OGSA) es una norma abierta a la base de todas stas mejoras de los Grid futuros.
OGSA estandarizar las interfaces del grid que sern usadas por los nuevos
schedulers, agentes de computing tomos y cualquier otro servicio a ser desarrollado por el Grid. Este lo har ms fcil para reunir los mejores productos
de varios vendedores, aumentando el valor del Grid computing global.
2.30
Qu No Puede Hacer el Grid Computing?
El Grid no es una bala color de plata que puede tomar cualquier aplicacin y
ejectarla mil veces ms rpido sin la necesidad de comprar ms mquinas o
software.
No toda aplicacin es conveniente o capas de ejecutarse un un Grid.
Algunos tipos de aplicaciones simplemente no pueden ser puestas en forma
paralela.
En otros casos, puede tomar una gran cantidad de trabajo para modificarlos y as lograr un movimiento ms rpido.
La configuracin de un Grid puede que afecte la calidad, fiabilidad, y
seguridad de una infraestructura de organizacin de computing.
Por todas estas razones, es importante entender cmo ha evolucionado el
Grid hoy y qu caractersticas tendr en un futuro distante.
Captulo 3
Estndares Abiertos
Para entender el rol desempeado por el Grid Toolbox de IBM, primeramente
se tienen que entender ciertos factores y discutir sobre algunos de los componentes fundamentales de los que el producto depende.
3.1
Web Service: Servicios Web
Un Web service puede ser usado para construir una aplicacin identificada
por una direccin Uniform Resource Locator : Localizador Uniforme de Recursos (URL). Las interfaces y enlaces de los Web services pueden ser definidas, descriptas y descubiertas por componentes Extensible Markup Language:
Lenguaje Extensible de Marcas (XML) y pueden soportar interacciones directas con otras aplicaciones de software usando mensajes basados en XML va
protocolos basados en Internet. En trminos simples, un Web service es una
aplicacin que se llama usando una direccin de Web, pasando los parmetros
en formato XML.
Al usar XML, el Web Services Description Language: Lenguaje de Descripcin de Servicios Web (WSDL) describe una red de servicios como una
coleccin de puntos finales que operan por medio de mensajes que contienen
informacin ya sea orientada al proceso u orientada al documento. Para definir un punto final, se describen abstractamente operaciones y mensajes y
posteriormente se limitan a un protocolo de red establecido.
Anlogamente los puntos finales descriptos son agrupados en puntos fina57
58
CAPTULO 3. ESTNDARES ABIERTOS
les abstractos, normalmente llamado servicios. La funcionalidad clave de

WSDL es permitir la descripcin de productos finales y sus mensajes sin tener en cuenta los formatos de los mensajes o los protocolos de comunicacin
utilizados.
3.2
Grid Service: Servicios Grid
La tecnologa de los Grid service est basada en la Service Oriented Architecture: Arquitectura Orientada a Servicios (SOA) que define una arquitectura
donde una aplicacin se constituye de componentes independientes y cooperadores llamados servicios. Esos servicios construyen los bloques que utiliza
un modelo de objeto para crear sistemas distribuidos abiertos y habilitar a
las compaas e individuos para que creen rpidamente y en forma global sus
aplicaciones disponibles para la red. [1, Aguilar]
Los mecanismos adicionales para crear y administrar Servicios Grid son
habilitados al desarrollar un servicio nuevo que ser desplegado dentro de un
sistema OGSA. Esos mecanismos son:
Factory: Fbrica: Es una clase especial para crear dinmicamente instancias de Servicios Grid, cdigo de Servicios Grid ejecutables y esperar por
requerimientos.
Registry: Registro: Es la interfaz que habilita un conjunto de instancias de
Servicios Grid para registrar el Grid Service Handle: Manejador de Servicio
Grid (GSH ) dentro de un servicio de registro, que permita la identificacin de
servicios en ese conjunto.
Discovery: Descubrimiento: Es la interfaz que permite a los clientes del
Servicio Grid obtener informacin acerca de los servicios proporcionados.
Life cycle: Ciclo de vida: Se refiere a los estados de las instancias de
Servicios Grid entre su creacin y destruccin.
Service data: Datos del servicio: Es la coleccin estructurada de informacin que se asocia con una instancia de Servicios Grid.
Notification: Notificacin: Mecanismo por el cual una parte enva (origen
de notificacin) informacin de un cambio de estado a la parte (destino de
notificacin) que ha pedido ser notificada.
3.3. OPEN GRID SERVICE ARCHITECTURE
59
Reliable invocation: Invocacin fiable: Tcnicas que aseguran la fiabilidad de invocacin de mtodos en caso de que hayan sido creadas mltiples
instancias con Servicios Grid redundantes en el espacio.
Lo importante a tener en cuenta es que el nico contacto entre los Servicios
Grid y sus usuarios es la interfaz de servicios. Esas interfaces de servicios son
definidas por el Lenguaje de Descripcin de Servicios Web (WSDL) existente.
Varias mejoras a WSDL han sido identificadas para requerimientos de OGSI
y actualmente estn siendo agregadas al estndar WSDL.
3.3
Arquitectura de Servicios de Grid Abierta (OGSA)
El Foro Global de Grid fue formado para manejar las estandarizaciones en un

Grid Computing.
La Open Grid Services Architecture: Arquitectura de Servicios de Grid
Estndar (OGSA) del Foro Global de Grid representa una evolucin hacia
una arquitectura de sistemas basada en conceptos y tecnologas de Servicios
Web.
Es importante destacar que OGSA es una arquitectura basada en los estndares existentes de Web service, y que tambin se utiliza para definir muchos
estndares de grid.
Los estndares de Web service incluyen: XML, SOAP y WSDL.
3.4
Infraestructura de Servicios de Grid Abierta

(OGSI)
El Foro Global de Grid promueve el desarrollo de estndares para la infraestructura de un Grid Computing.
OGSI se refiere a la infraestructura base sobre la cual se construye la
OGSA. En su ncleo se encuentran las especificaciones de Servicios Grid, que
definen la interfaz estndar y conductas de un Servicio Grid, armando una
base de Web service.
60
Proporciona especificaciones tcnicas para la implementacin de cada componente de OGSA, usando Servicios Grid para definir cada interfaz. La especificacin se basa en un grupo de Servicios Web estndar, con ciertas extensiones
para WSDL y XML necesarias para los Servicios Grid.
OGSI define detalles tales como estabilidad de Servicios Web, la herencia
de interfaces de Servicios Web, notificacin asncrona, referencias a instancias
de servicios, coleccin de instancias de servicios y datos de estados de servicios.
El mundo de los Web services ha reconocido las mejoras significativas logradas para OGSA OGSI y el trabajo se encamina para incluir algunas de
esas mejoras en los Web services mismos.
3.5
Cules Son Los Objetivos de OGSA?
Objetivos:
Manejar recursos a travs de plataformas heterogneas distribuidas.

Brindar Quality of Service: calidad de servicio (QoS ). La topologa de
Grid es a menudo compleja. La interaccin de recursos del Grid es
normalmente dinmica.Es importante que el Grid proporcione servicios
robustos ocultos, tales como autorizacin, control de acceso, y delegacin.
Proveer una base comn para soluciones de administracin autnomas.
Un Grid puede contener muchos recursos, con numerosas combinaciones
de configuraciones, interacciones, y estado cambiante y modos de fallos.
Definir las interfaces abiertas publicadas. La OGSA es una norma abierta manejada por el cuerpo de normas de GGF (Global Grid Forum).
Para la interoperabilidad de diversos recursos, los Grid deben construirse en interfaces y protocolos standard.
Aprovechar los stndares de integracin de tecnologas de la industria.
[19, Unger]
3.5. CULES SON LOS OBJETIVOS DE OGSA?
61
Figura 3.1: La Arquitectura de OGSA.
3.5.1
Arquitectura:
Cuatro capas principales comprenden la arquitectura de OGSA: ver fig. 3.1

de la pg. 61.
Empezando desde la inferior, ellas son:
Recursos: los recursos fsicos y los recursos lgicos Web services ms las
extensiones de OGSI que definen servicios Grid.
Servicios de arquitectura de OGSA.
Aplicaciones Grid.
Se debe observar estas capas, una a la vez.
Capa de los recursos fsicos y lgicos
El concepto de recursos es central para OGSA y Grid Computing en general. Los recursos comprenden las capacidades del Grid, y no son limitados
a los procesadores.
Los recursos fsicos incluyen servidores, almacenamiento, y red.
62
Sobre los recursos fsicos estn los recursos lgicos. Ellos proporcionan
funcin adicional virtualizando y agregando los recursos en la capa fsica. El
propsito general del software intermedio tal como sistemas de archivos, gestores de bases de datos directorios, y gestores de flujos de trabajo (workflow)
es proporcionar estos servicios abstractos sobre el Grid fsico.
Capa de Web services
La segunda capa en la arquitectura de OGSA es la de Web services.
Aqu hay un importante principio de OGSA: Todos los recursos del Grid
(lgico y fsico) son modelados como servicios. La especificacin Abierta de
Infraestructura de Servicios de Grid (OGSI) define servicios de grid y construye sobre las tecnologas de Web services standad. OGSI aprovecha los
mecanismos de Web services como XML y WSDL para especificar interfaces
standards, conductas e interaccin para todos los recursos del Grid.
OGSI extiende la definicin de Web services para proporcionar capacidades
para una Web services dinmica, estable y manejable que se exige para modelar
los recursos del Grid.
Capa Servicios de Grid de la Arquitectura de OGSA
La capa de Web services, con sus extensiones de OGSI, provee una infraestructura base a la prxima capa de arquitectura de Grid services. El Global
Grid Forum est actualmente trabajando para definir muchos de estos servicios de Grid de arquitectura en reas como la ejecucin de programas, servicios
de datos, y servicios centrales.
Algunos ya se han definido, y algunas aplicaciones ya han aparecido. En
tanto las aplicaciones de stos servicios nuevos de arquitectura empiecen a
aparecer, OGSA se volver una arquitectura orientada al servicio ms til
(SOA).
Capa de Aplicaciones de Grid
Con el tiempo, en tanto una cantidad importante de servicios de arquitectura de Grid contine desarrollndose, aparecern las nuevas aplicaciones del
Grid que utilicen uno o ms servicios de arquitectura de ste. Estas aplicaciones comprenden la cuarta capa principal de la arquitectura de OGSA.
Se puede observar ms de cerca a los dos componentes lgicos principales
de OGSA (los Web services) ms capa de OGSI y la capa se servicios de
63
Figura 3.2: La Estructura de OGSA.

arquitectura de OGSA. Ver fig. 3.2 de la pg. 63.
El grupo de trabajo de OGSA crey que era necesario aumentar la funcionalidad de los Web services centrales para dirigir los requerimientos de
servicios de Grid. El OGSI extiende los Web services introduciendo interfaces
y convenciones en dos reas principales:
Primero, hay una naturaleza de servicios en un Grid dinmica y potencialmente transitoria. En un Grid, instancias particulares de servicios
pueden venir y pueden ir en relacin al trabajo que se enva, a los recursos que son configurados y provisionados, y a los cambios de estado
del sistema. Por consiguiente, los servicios del Grid necesitan interfaces
para manejar su creacin, destruccin, y administracin de ciclo de vida.
Segundo, hay un estado. Los servicios del Grid pueden tener atributos
y datos asociados con ellos. Esto es similar en concepto a la estructura
tradicional de programacin orientada a objetos. Los objetos tienen conducta y datos. Igualmente, los Web services tuvieron que ser extendidos
para soportar datos de estados asociados con servicios del Grid.
El OGSI presenta un modelo de interaccin para los servicios del Grid.
OGSI provee una manera uniforme a diseadores de software para planear e
interactuar con servicios del Grid al proveer interfaces para descubrimiento,
ciclo de vida, estado, administracin, creacin y destruccin, notificacin de
evento, y administracin de la referencia.
64
Figura 3.3: Componentes de OGSI.
stos se describen en la fig. 3.3 de la pg. 64.Si un diseador de software

est desarrollando un servicio de Grid o una aplicacin, el modelo de programacin de OGSI, provee un camino consistente para que el software del Grid
interacte.
Infraestructura: servicios de Grid que llevan a cabo esta interfase proporcionan una manera de crear nuevos servicios del Grid. La infraestructura
puede crear casos temporales de funcin limitada, como un scheduler que crea
un servicio para representar la ejecucin de un trabajo particular, o tambin
pueden crear servicios de ms larga vida tales como una rplica local de un
conjunto de datos frecuentemente usados. No todos los servicios de Grid se
crean dinmicamente. Por ejemplo, algunos podran ser creados como el resultado de una instancia de un recurso fsico en el Grid tales como procesador,
almacenamiento, o dispositivo de la red.
Ciclo de vida: porque los servicios del Grid pueden ser transitorios, las
instancias de servicio de ste se crean con un tiempo de vida especfico.
La vida de cualquier instancia de servicio particular puede negociarse y
puede extenderse como requieran los componentes que son dependientes o
manejan ese servicio. El mecanismo de ciclo de vida se construye para prevenir
que servicios de Grid consuman recursos indefinidamente sin requerir en gran
escala servicios distribuidos de recoleccin de residuo.
Administracin de estado: los Grid services pueden tener estado. OGSI especifica un marco para representar este estado llamado Services Data y
un mecanismo para inspeccionar o modificar lo que el estado llama Services
Data Set Find.
Adems, el OGSI requiere una mnima cantidad de estado en Service Data Elements que cada Grid service debe soportar, y requiere que todos los
65
Figura 3.4: El OGSI y Web service.
servicios implementen el Find/SetService Data portType.

Grupos de servicios: son grupos de servicios de Grid que son incluidos,
usando el Service Data, para algn propsito en particular. Por ejemplo, podran ser usados para recolectar todos los servicios que representan los recursos
en un nodo-cluster particular dentro del Grid.
Notificacin: la informacin de estado (Service Data) que se modela
para servicios Grid cambia cuando el sistema se ejecuta.Muchas interacciones
entre los servicios Grid requieren un monitoreo dinmico de estado cambiante.
La notificacin aplica un paradigma tradicional publish/subscribe para este
monitoreo.
Los servicios Grid soportan una interfase (NotificacionSource) para permitir que otros servicios Grid (NotificationSink) se subscriban a los cambios.
Mapeo: cuando las infraestructuras se usan para manejar una nueva instancia de servicios Grid, la infraestructura devuelve la identidad de los servicios instanciados recientemente. Esta identidad se compone de dos partes, un
Grid Service Handle (GSH) y un Grid Service Reference (GSR). Se garantiza
un GSH para referenciar el servicio Grid indefinidamente, mientras un GSR
puede cambiar dentro del tiempo de vida del servicio Grid. La interfase de
mapeo provee una manera de obtener un GSR dado un GSH. Esto podra
parecer simple pero, hay un grupo de problemas asociados con tal consulta.
Como se observ, la arquitectura del OGSA permite a los Web Services
66
Figura 3.5: El OGSI y el Hosting de Web service.
acomodar los requerimientos del Grid de mejor manera.

Estas mejoras son especificadas en el OGSI. Cuando las especificaciones
del OGSI finalicen y las implementaciones comiencen a aparecer, algunas organizaciones de estndares comenzaran a interesarse en incorporar la mayora
de las funcionalidades bosquejadas en el OGSI dentro de un apropiado Web
services standard. Esto es razonable.
Parte de lo que el OGSI trata en algn aspecto, no es propio del Grid
computing, pero se requiere para construir arquitecturas robustas orientadas
al servicio. Con el tiempo se espera que muchas de las funcionalidades del
OGSI se incorporen a los Web services standard. Esto se muestra en la fig.
3.4 de la pg. 65, la cual lista varios Web Services standards emergentes que
podran incorporar el OGSI.
En la misma figura se hace referencia a las mejoras de Web services como
extensiones de Web services.
El Globus Toolkit 3 es la primer implementacin en gran escala del standard
OGSI. El toolkit fue desarrollado por el proyecto Globus, una investigacin y
un proyecto de desarrollo focalizado en permitir la aplicacin de conceptos de
Grid computing a ingeniera, ciencia y comercio.
El toolkit fue escrito en lenguaje Java usando el entorno J2EE . Como el
centro de la arquitectura de Grid services el OGSI necesita ser alojado en una
plataforma de entrega que soporte a los Web services.
3.6. QU PLATAFORMAS?
67
Aunque el OGSI fue hecho en cdigo Java y alojado en un ambiente de

tiempo de ejecucin J2EE, nada impide que el OGSI sea implementado en otro
lenguaje de programacin y alojado en otros ambientes. De hecho, para que
crezca la aceptacin del OGSA el OGSI deber ser habilitado en plataforma
de alojamiento mltiple.
3.6
Qu Plataformas?
En la fig. 3.5 de la pg. 66, se observa que una implementacin Java de

OGSI puede ser potencialmente alojada en cualquiera de los ambientes J2EE
tales como JBOSS, WebSphere, o BEA Weblogic. Esta es una de las distintas
ventajas de implementar el OGSI (y para esa cuestin cualquier software) en
la tecnologa Java.
Sin embargo, plataformas alternativas como un entorno tradicional C,
C++, o C# y Microsoft .Net son factibles de alojar ambientes para el OGSI. Ya hay implementaciones iniciales para la ejecucin del OGSI en otros
ambientes, incluyendo C#/.Net y Python.
Se espera que muchas de las implementaciones del OGSI sean enviadas va
modelo de desarrollo de fuente abierta y que las implementaciones de referencia existentes (el Globus Toolkit 3) sean usadas sin modificarse en entornos
apropiados de hosting.
Idealmente, un pequeo nmero de implementaciones centrales del OGSI
(una por plataforma hosting) ser conjuntamente desarrollada con la industria
y usada en muchos productos [7, Haynos].
El OGSI es ciertamente un paso importante en el desarrollo de una arquitectura orientada al servicio para Grid.
Sin embargo, para que se desarrollen aplicaciones tiles, se necesitar implementar y distribuir un importante grupo de servicios Grid (los servicios
de arquitectura de OGSA), por iniciativas de fuente abierta como el proyecto
Globus y por compaas de software de middleware.
En este sentido, el OGSI y las extensiones que l provee para Web Services son necesarias pero insuficientes para la maduracin de la arquitectura
orientada al servicio.
En la fig. 6.4 de la pg. 165, adems se dividen los servicios de arquitectura
68
Figura 3.6: La Estructura de la Arquitectura de Servicio de OGSA.

de Grid en cuatro categoras:
Servicios centrales de Grid.
Servicios de ejecucin de programa de Grid.
Servicios de datos de Grid.
Servicios especficos de dominio.
Las primeras tres categoras representan reas de trabajo activo de investigacin de GGF o grupos de trabajo.
Con el tiempo, cuando estos servicios maduren, se podrn especificar servicios de dominio, los cuales harn uso de la funcionalidad que stos servicios
provean.
Es importante que los grupos de trabajo GGF se concentren en especificar
un amplio conjunto de servicios de Grid tiles que los vendedores de software
y diseadores podrn luego comenzar a implementar.
Los servicios centrales de Grid se componen de cuatro tipos de servicios
principales (ver fig. 3.7 de la pg. 69):
Administracin de Servicio.
69
Figura 3.7: Servicio de ncleo de Grid.

Comunicacin de Servicio.
Administracin de Polticas.
Servicio de Seguridad.
A diferencia de funciones del OGSI que estn ampliamente implementadas
como extensiones para los protocolos de Web services bsicos y un modelo
de interaccin, estos servicios centrales son realmente implementados como
servicios Grid (en la base del OGSI).
Estos servicios se consideran centrales primeramente, porque se espera que
sean ampliamente explotados por la mayora (sino todos) de los servicios de
alto nivel implementados adems para soportar la ejecucin de un programa,
o acceso de datos, o como servicios de dominio especfico.
Administracin de Servicio: provee funciones que administran los servicios de despliegue en el Grid distribuido. ste automatiza y asiste con una
variedad de tareas de instalacin, mantenimiento, monitoreo y de bsqueda
de error dentro de un sistema de Grid. ste incluye funciones para provisionar y desplegar los componentes del sistema. Tambin incluye funciones para
recolectar e intercambiar datos acerca de la operacin del Grid.
Estos datos son tiles para operaciones de manejo online y oine, e incluyen informacin acerca de errores, eventos, determinacin de un problema,
auditoria, medicin, contabilidad y pago.
70
Figura 3.8: Ejecucin de Programas de Grid y Data Service.
Comunicacin de Servicio: incluye un grupo de funciones que soportan

los mtodos bsicos para que se comuniquen los Grid services. Soportan varios
modelos de comunicacin que pueden ser combinados para permitir una efectiva comunicacin entre servicios, incluyendo mensajes encolados, notificacin
de eventos de suscripcin y publicacin, notificacin y registro (logging) de
distribucin confiable.
Servicios de Poltica: crea un marco general para creacin, administracin y conduccin de polticas y acuerdos para operacin de sistemas. Estos
incluyen seguridad de gobierno de polticas, asignacin de recursos y performance, tambin una infraestructura para servicios de consideracin de poltica para usar polticas para gobernar su operacin.
Documentos de poltica y acuerdo proveen un mecanismo para la representacin y negociacin de trminos entre los proveedores de servicios y sus
clientes (ya sea consulta de usuarios u otros servicios). Estos trminos incluyen especificaciones, requerimientos y objetivos para funcin, performance, y
calidad que los proveedores y consumidores intercambian y que luego usan
para influenciar sus interacciones.
Servicios de Seguridad: soportan, integran y unifican modelos de seguridad populares, mecanismos, protocolos y una variedad de tecnologas de
una manera que posibilita a una variedad de sistemas interoperar de forma
segura. Estos servicios de seguridad capacitan y extienden enlaces y protocolos de seguridad de Web services central y proveen mecanismos orientados al
servicio para autenticacin, autorizacin, refuerzo de confianza de la poltica,
trasformacin de credencial, etc.
71
Muestra dos Importantes Clases de Grid services (ver la fig. 3.8

de la pg. 70):
Servicios de ejecucin de programas de Grid.
Grid Data services.
Servicios de Ejecucin de Programa de Grid: mientras el OGSI y
los servicios centrales de Grid son generalmente aplicables a cualquier sistema
de computacin distribuido, la clase de ejecucin de programas de Grid es
nica, en el modelo de Grid de ejecucin de tareas distribuidas, que soporta
la computacin de alta performance, paralelismo, y colaboracin distribuida.
Los principios de programacin de trabajos y de administracin de carga implementados a esta clase de servicios y la habilidad para virtualizar recursos
en proceso, son centrales al Grid computing.
Grid Data Services: para complementar las convenciones de virtualizacin de cmputo especificada por los servicios de ejecucin de programas,
existen los servicios que forman grid data services.
Estas interfases soportan el concepto de virtualizacin de datos y provee
mecanismos relacionados con el acceso distribuido a la informacin de todo
tipo incluyendo bases de datos, archivos, documentos, almacn de contenidos
y corrientes de datos generados por las aplicaciones.
Grid data services explotar y virtualizar datos usando mtodos de ubicacin, replicacin de datos, caching y movimientos de datos de alta performance
para brindar aplicaciones que requieran Calidad de Servicio (QoS) y acceso a
travs del Grid distribuido.
Mtodos para asociar mltiples tipos de datos dispares, como tambin recursos de datos distribuidos, pueden proveer la integracin de datos almacenados bajo diferentes esquemas tales como archivos y bases de datos relacionales.
En esta categora es evidente que la OGSA localiza a los recursos de datos
de manera equivalente a los recursos de cmputo.
Los vendedores probablemente no competirn al ofrecer un amplio rango
de implementaciones de OGSI. En lugar de eso como parte del desarrollo
de las implementaciones de Web services, los vendedores, quienes ofrecern
estas implementaciones, tambin usarn directamente las implementaciones
72
Figura 3.9: La Ejecucin de Programas de Grid y Data Service Hosting.
3.7. CONCLUSIN.
73
de fuente abierta existentes provistas por organizaciones como Globus, o integrarn las implementaciones con sus productos de plataforma hosting como
WebSphere, WebLogig, Apache o Net.
Sin embargo, los servicios de arquitectura de Grid proveen algunas reas
naturales preparadas oportunamente para vendedores y organizaciones, para
competir y diferenciarse entre ellos. Esta competencia crear una economa
de proveedores de software de Grid cuya innovacin ayudar a orientar la
aceptacin de standards como OGSI/OGSA, y esto permitir a los clientes
construir sistemas fuera de los componentes interoperables.
Adems, las reas de funcionalidad en la ejecucin de programas de Grid y
servicios de datos requerirn innovacin y nuevos planteamientos, y esto acelerar la aceptacin del mercado de soluciones de Grid y proveer oportunidades
de mercado a los vendedores.
En la fig. 3.9 de la pg. 72 se observa que los servicios centrales del Grid
pueden ver una mezcla de implementaciones de referencia de fuente abierta e
implementaciones de valor agregado provistas por el vendedor (proveedor).
Muchas tecnologas en esta rea pueden ser comoditizadas, pero reas como
poltica y seguridad proveern a los vendedores una oportunidad para diferenciarse entre ellos.
Implementaciones en ambos, ejecucin de programas de Grid y data services, se espera que formen parte de implementaciones de valor agregado de
diferentes compaas. Estas reas representan oportunidades importantes para
integrar ofertas de middleware lderes dentro del marco de OGSA y permitirn
un buen ecosistema para desarrollar soluciones de Grid.
3.7
Conclusin.
Se han presentado y descripto los componentes de la estructura de OGSA.

Con la entrega de las implementaciones iniciales de OGSI, OGSA se prepara
para acelerar su entrada en la principal corriente comercial de computacin.
Si las iniciativas se refieren a organic computing (computacin orgnica),
on-demand computing (computacin bajo demanda) o adaptive computing
(computacin adaptativa), es necesario un standard comprensivo y abierto
como el OGSA (construido en tecnologa standard) para realizar computacin
heterognea distribuida en el mundo comercial.
74
OGSA Para La Integracin de Sistemas Distribuidos

Grid Computing se relaciona con colaboracin, compartimiento de datos
y otros nuevos modos de interaccin que incluyen recursos distribuidos. El
resultado es una focalizacin incrementada en la interconexin de sistemas
dentro y a travs de empresas, en la forma de redes inteligentes, equipos switching, servicios caching, servidores, sistemas de almacenamiento, o sistemas
de direccin de red de rea de almacenamiento.
Estas presiones evolucionarias generan nuevos requerimientos para la distribucin y desarrollo de la aplicacin distribuida como ser, . Las capacidades
provistas por varias plataformas pueden variar desde funciones de administracin de recursos integrados hasta integracin de bases de datos, servicios
de clustering, seguridad, direccin de carga de trabajo, y determinacin de
problemas con diferentes implementaciones, comportamientos, semnticas, y
APIs para estas funciones en diferentes plataformas. Pero en lugar de esta
diversidad, la continua descentralizacin y distribucin de software, hardware,
y recursos humanos hacen esencial que se logre la calidad de servicio deseado
(QoS )ya sea medido en termino de semnticas de seguridad comn, flujo de
trabajo distribuido, y calidad de direccin de recurso, fail over coordinado,
servicios de determinacin de problema, u otras medidas, en recursos reunidos
dinmicamente desde sistemas de empresa, sistemas de proveedor de servicio,
y sistemas de cliente.
Captulo 4
La Evolucin de Enterprise
Computing
En el pasado, la computacin era tpicamente realiza dentro de centros de
computacin de empresas altamente concentradas e integradas mientras los
sistemas distribuidos sofisticados (por ejemplo sistemas de control de comandos, sistemas de reserva, el Internet Domain Name System [16]) existieron,
estos han permanecido como entidades especializadas [16].
El crecimiento de la Internet y la emergencia de los negocios electrnicos
(e-business) sin embargo condujo a una creciente conciencia de una infraestructura IT de la empresa tambin equiparada a redes externas, recursos y
servicios. Inicialmente esta nueva fuente de complejidad era tratada como un
fenmeno central de red y se hicieron intentos para construir redes inteligentes que interceptan con centros de datos IT tradicionales de la empresa
solo en servidores de borde (edge): por ejemplo, una Web clave de empresa,
o el servidor de red privado que conecta una red de empresas a recursos de
proveedor de servicios.
La idea era que el impacto de los negocios y el Internet en una infraestructura IT centro de empresa podra as ser administrada y circunscripta.
Este intento, en general ha fallado porque la descomposicin de los servicios IT tambin ocurre dentro de las facilidades de la empresa IT. Nuevas
aplicaciones estn siendo desarrolladas para modelos de programacin (tales
como el modelo de componentes Enterprise Java Beans que asla la aplicacin
75
76
CAPTULO 4. LA ENTERPRISE COMPUTING
de la plataforma de computacin subyacente y soporta despliegues portables

a travs de plataformas mltiples.
Esta portabilidad a su vez permite que las plataformas sean seleccionadas basndose en el precio/calidad y requerimientos de QoS, en lugar de los
sistemas de operativos soportados. Adems, por ejemplo, las aplicaciones ocultas utilizadas en la Web se enfocan en recursos de servidores en lugar de en
plataformas de computador central (mainframe) tradicionales. La resultante
proliferacin de servidores de Unix y NT necesita conexiones distribuidas para
acceder a aplicaciones de legado (heredadeas) residentes en mainframe y los
datos correspondientes. El incremento de carga en esos activos ha causado
que las compaas descarguen funciones no esenciales (tal como procesador de
consulta) de sistemas de proceso de transaccin back-end a servidores mid-tier
(rango medio).
Mientras tanto, el acceso de la Web a recursos de la empresa requiere
servicio de consultas ever-faster (siempre ms rpidos), adems de administrar
la necesidad de distribuir y ocultar contenidos en los lmites de la red. El
resultado general es una descomposicin de una infraestructura interna IT
altamente integrada en una coleccin de sistemas fragmentados y heterogneos.
Las empresas luego deben reintegrar (con QoS ) estos servidores distribuidos y los recursos de datos, direccionando aspectos de navegacin, seguridad
distribuida, y distribucin de contenido dentro de la empresa, tanto como en
redes externas.
Al igual que estos desarrollos, las empresas se estn conectando agresivamente con e-negocios (e-bussines) y estn notando que se necesita una infraestructura IT altamente robusta para manejar el rpido crecimiento y su
impredecibilidad.
Las empresas ahora estn expandiendo el campo y la escala de sus proyectos de planeamiento de recurso de empresa tratando de proveer una mejor
integracin con la administracin de relaciones con el cliente, cadena de abastecimiento integrado, y sistemas centrales existentes. Estos desarrollos agregan
a las importantes presiones sobre la infraestructura de IT de la empresa.
El efecto agregado es que las calidades de servicio tradicionalmente asociado con mainframe host-central computing (computacin central alojada en
mainframe) [8] son ahora esenciales para una efectiva conduccin de los enegocios mediante recursos de cmputo distribuido, tanto dentro como fuera
de la empresa. Por ejemplo las empresas deben proveer tiempos de respuestas
4.1. SERVICIOS Y COMPUTACIN B2B
77
consistentes a los clientes, a pesar de la carga de trabajo y de las significativas

desviaciones entre promedio y utilizacin pico.
As, los clientes requieren una afectacin de recursos flexible en relacin
con las prioridades y demanda de trabajo.
Las empresas tambin deben proveer un ambiente seguro y confiable para transacciones distribuidas que fluyen a travs de un grupo de servidores
diferentes, deben entregar disponibilidad continua como la ven los usuarios
finales, y deben soportar la recuperacin de fallas para el flujo de trabajo de
negocios a travs de una red distribuida de servidores de aplicaciones y datos.
Aunque el paradigma actual para suministrar QoS a aplicaciones a travs de
la integracin vertical de servicios y componentes especficos de plataformas,
no trabaja en un ambiente distribuido hoy da: la descomposicin de infraestructuras IT monolticas no es consistente con la entrega de QoS a travs de
la integracin vertical de servicios en una plataforma dada.
Tampoco existe una capacidad distribuida efectiva de administracin de
recursos distribuidos, estando limitada por la naturaleza de la propiedad, la
inaccesibilidad a plataformas de recursos, e inconsistencia entre recursos similares a travs de un ambiente distribuido.
El resultado de estas tendencias es que los integradores de sistemas IT
se encargan de la carga de reintegrar recursos de computo distribuidos con
respecto al QoS.
Sin embargo, sin herramientas de infraestructura apropiadas, la administracin del flujo de trabajo de computo distribuido se convierte en una creciente labor intensiva, compleja y frgil como el sta de operaciones especificas
de plataforma espera la orden de inicio (fires) en disponibilidad general y
calidad y colaboracin verbal en acciones correctivas a travs de plataformas
diferentes. La situacin no es escalable (scalable), efectiva en cuanto a costo, o
sostenible frente a los cambios al ambiente de computo y carpeta de aplicacin.
4.1
Proveedores de Servicio y Computacin Negocio a Negocio
Para lograr economas de escala proveedores de e-Utilidad requiere infraestructura de servidor que puede ser fcilmente adaptado a las demandas para cubrir
78
las necesidades especificas del cliente. As hay una demanda para infraestructura IT que apoya la ubicacin de recurso dinmico de acuerdo a polticas de
acuerdos de nivel de servicio, colaboracin eficiente y reutilizacin de infraestructura IT en altos niveles de utilizacin, y seguridad distribuida desde el
borde de la red hasta aplicacin y servidores de datos, tiempos de respuesta
consistentes y altos niveles de disponibilidad, los cuales a su ves producen una
necesidad de monitoreo de calidad fin a fin y reconfiguracin de tiempo real.
Otra tendencia de industria de IT clave es cross-enterprise, colaboracin
(B2B) negocio a negocio, as como una multiorganizacin suministra administracin en cadena, va de Web virtual, y subasta de mercado electrnico.
Las relaciones de B2B son en efecto, organizaciones virtuales, aunque con requerimientos particularmente restringidos para seguridad, auditabilidad, disponibilidad, acuerdos de nivel de servicio, y flujos de proceso de transaccin
complejos.
Adems, B2B representa otra fuente de demanda para integracin de sistemas distribuidos, caracterizados a menudo por grandes diferencias entre las
tecnologas de informacin presentadas dentro de diferentes organizaciones.
4.2
4.2.1
Tecnologas en las Cuales se Define la OGSA

El Globus Toolkit
Los componentes del Toolkit que son ms relevantes al OGSA son Grid Resource Allocation y protocolos de Management (GRAM) y su servicio gatekeeper, que provee direccin y creacin de servicios confiables y seguros [8],
el Meta Directory Service (MDS-2) , que provee descubrimiento de informacin a travs de registro de estado de soft, diseo de datos, y un registro local
(GRAM reporter), y la Infraestructura de Seguridad de Grid (GSI ), que
soporta sing on (autorizacin), delegacin y mapeo de credencial.
Como se ilustra en la fig. 4.1 de la pg. 79, estos componentes proveen los
elementos esenciales de una arquitectura orientada de servicio pero con menos
generalidades que las que se logran en OGSA.
En la fig. 4.1 de la pg. 79 se observan los mecanismos del G.T. (Globus
Toolkit) seleccionado, muestra la creacin inicial de una credencial proxy y
consultas autenticadas subsecuentes a un servicio de gatekeeper remoto, resul-
4.2. TECNOLOGAS EN LAS CUALES SE DEFINE LA OGSA
79
Figura 4.1: Mecanismos del Globus Toolkit.

tado en la creacin del proceso #2 de usuario, con credencial proxy asociada
(potencialmente restringida) seguida por una consulta a otro servicio remoto.
Tambin se muestra en el registro de servicio de estado del soft va MDS-2.
El protocolo GRAM provee la creacin y conduccin remota, segura y
confiable de computaciones arbitrarias: este trmino trasciende instancias de
servicio. Los mecanismos GSI se usan para autenticacin, autorizacin, y
delegacin de credencial para computaciones remotas.
Un protocolo de compromiso de dos fases se usa para invocacin confiable
basada en tcnicas usadas en el Sistema Condor. La creacin de servicio es
manejada por un pequeo proceso confiable gatekeeper (factory en este
trabajo), mientras un GRAM reporter monitorea y publica informacin a
cerca de la identidad y estado de computaciones locales (registro).
El MDS-2 [16] provee un marco uniforme para el descubrimiento y acceso
a la configuracin de sistema e informacin de status tales como configuracin
de servidor de cmputo, status de red, o la ubicacin de conjunto de datos
replicados (discovery en este trabajo).
MDS-2 usa un protocolo de estado software, el Grid Notification Protocol,
para administracin de tiempo de vida de informacin publicada.
El protocolo GSI basado en clave pblica provee una autenticacin de
sign-on, proteccin de comunicacin, y algn apoyo inicial para delegacin
restringida. En resumen el sign-on simple permite a un usuario autenticarse
una vez y as crear una credencial proxy que un programa puede usar para
80
autenticar cualquier servicio remoto en nombre del usuario.

La delegacin permite la creacin y comunicacin a un servicio remoto
de credenciales proxy delegadas que el servicio remoto puede usar para actuar en nombre del usuario, quizs con varias restricciones; esta capacidad
es importante para operaciones anidadas. (Se pueden implementar mecanismos similares dentro del contexto de otras tecnologas de seguridad tal como
Kerberos , aunque con caractersticas potencialmente diferentes).
El GSI usa certificados X.509, un standard ampliamente utilizado para
certificados PKI, como las bases para autenticacin del usuario. El GSI define
un certificado proxy X.509 para equiparar X.509 para soportar el sign-on simple y la delegacin. Este certificado proxy es similar en concepto a un ticket
avanzado de Kerberos pero se basa puramente en tcnicas criptogrficas de
clave publica.
El GSI tpicamente usa el protocolo Transport Layer Security (TLS) (el
siguiente a SSL) para autenticacin aunque otros protocolos de autenticacin
de clave pblica podran ser usados con certificados proxy X.509. Un protocolo
de delegacin remota de certificados proxy X.509 se coloca en el tope de TLS.
Un diseo de Iternet Engineering Task Force define las estaciones de certificado proxy X.509. Los diseos del Forum Global Grid definen el protocolo
de delegacin para la creacin remota de un certificado proxy X.509 y extensiones GSS-API que permite que este API sea efectivamente usado para
programacin de Grid.
Se ha demostrado un gran apoyo a la delegacin restringida en prototipos
y es una parte critica de Proxy Certificate Profile (PERFIL) X.509. La delegacin restringida permite a una entidad delegar slo un subconjunto de sus
privilegios totales a otra entidad.
Tal restriccin es importante para reducir los efectos adversos del mal uso
de la credencial delegada (intencional o accidental).
4.2.2
Los Web Services
Los Web services standars se definen dentro de W3C y otros cuerpos standars
y forman las bases para mayores y nuevas iniciativas de la industria tales
como Microsoft (.NET ), IBM (Dynamic e-Business), y Sun (Sun ONE ). Estn
particularmente relacionados con tres de estos standars, SOAP, WSDL, and
4.2. TECNOLOGAS EN LAS CUALES SE DEFINE LA OGSA
81
WS-Inspection.
El Simple Object Acces Protocol (SOAP) provee un medio de mensajes
entre un proveedor de servicios y un consultor de servicios. SOAP es un
mecanismo de desarrollo simple para carga til de XML que define una
convenin para llamda a procedimiento remoto (RPC ) y una convencin
de mensajes.
SOAP es independiente del protocolo de transporte fundamental; las
cargas tiles de SOAP pueden ser realizadas en HTTP, FTP, Java Messaging Service (JMS), y otros similares. Se enfatiza que los Web services
pueden describir mecanismos de acceso mltiple al componente software
fundamental. El SOAP es slo un medio de formatear una invocacin
de Web services.
EL Web Services Description Language (WSDL) es un documento XML
para describir a las Web service como un conjunto de endpoints (puntos
finales) que operan en mensajes que contienen mensajes de documentos
orientados a carga til de RPC. Las interfaces service se definen abstractamente en trminos de estructura de mensajes y secuencia de intercambio de mensaje simple (u operaciones, en terminologa WSDL) y luego
unido a un protocolo de red concreto y formato de codificador de datos
para definir un endpoint. Los endpoints relacionados se unen para definir endpoints abstractos(servicios). WSDL es extensible para permitir
la descripcin de endpoints y la concreta representacin de sus mensajes
para una variedad de diferentes formatos de mensajes y protocolos de
red. Varias convenciones unidas estandarizadas se definen describiendo
cmo usar WSDL en conjunto con SOAP 1.1, HTTP GET/POST, and
MIME.
La WS-Inspection comprime un simple lenguaje XML y convenciones
relacionadas para localizar descripciones de servicios publicadas por un
proveedor de servicio. Un documento WS-Inspection Languje (WSIL)
puede contener una coleccin de descripciones de servicio y uniones a
otras fuentes de descripciones de servicio. Esta es usualmente una URL a
un documento WSDL; ocasionalmente una descripcin de servicio puede
ser una referencia para una entrada a un registro Universal Description,
Discovery, Itegration (UDDI ). Una conexin es usualmente una URL
a otro documento WS-Inspection, ocasionalmente una conexin es una
referencia a una entrada UDDI. Con WS-Inspection un proveedor de
82
servicio crea un documento WSIL y hace accesible el documento de red.

Los consultores de servicio usan mecanismo de acceso standard basados
en red (por ej. http GET ) para recuperar este documento y descubrir
qu servicios ofrece el proveedor. Los documentos WSIL pueden tambin
organizarse en diferentes formatos de ndices.
4.3
Una Arquitectura de Grid Services Abierta
Se ha fundamentado que dentro de infraestructuras IT internas de empresa,

infraestructuras IT mejoradas SP, y grids multi-organizacionales, la computacin est crecientemente relacionada con la creacin, administracin y aplicacin de conjuntos dinmicos de recursos y servicios (y personas) que se puede
llamar organizaciones virtuales.
Dependiendo del contexto, estos conjuntos pueden ser pequeos o grandes,
de corta o larga vida, institucional simple o multi-institucional y homogneos
o heterogneos. Conjuntos individuales pueden ser estructurados jerrquicamente desde sistemas ms pequeos y pueden sobreponerse en membresa.
A pesar de estas diferencias, los diseadores de aplicaciones para VOs
enfrentan requerimientos comunes cuando buscan enviar QoS ya sea medido
en trminos de semntica de seguridad comn, flujo de trabajo distribuido y
administracin de recursos, fail-over coordinada, servicios de determinacin de
problemas u otras medidas-. A travs coleccin de recursos code una coleccin
de recursos con caractersticas homogneas y a menudo dinmicas.
Se focaliza ahora en la naturaleza de estos requerimientos y los mecanismos
necesarios para utilizarlos en ambientes prcticos. Se introduce un Open Grid
Services Architecture que apoya la creacin, mantenimiento, y aplicacin de
conjunto de servicios mantenidos por VOs.
4.3.1
Virtualizacin y Orientacin de Servicio
Al describir VOs, se puede focalizar en recursos fsicos compartidos o en los

servicios soportados por estos recursos.
En OGSA, se focaliza en servicios: recursos de computacin, recursos de almacenamiento, redes, programas, bases de datos, son todos presentados como
servicios.
4.3. UNA ARQUITECTURA DE GRID SERVICES ABIERTA
83
Independientemente de su perspectiva, un requerimiento crtico en un ambiente de Grid milti-organizacional distribuido es para mecanismos que permiten interoperabilidad.
Con una visin orientada a servicio, se puede dividir el problema de interoperabilidad en dos subproblemas, la definicin de interfases de servicio y la
identificacin de los protocolos que pueden ser usados para pedir una interfase
particular (y un acuerdo en un conjunto standard de tales protocolos).
Una visin orientada a servicio permite satisfacer la necesidad de mecanismos de definicin de interfase standard, transparencia remota / local, adaptacin a servicios OS locales y semntica de servicio uniforme. Esta tambin
simplifica la virtualizacin -es decir, la encapsulacin detrs de una interfase
comn de implementaciones diversas-.
La virtualizacin permite acceso a recursos consistentes a travs de plataformas heterogneas mltiples con transparencia de ubicacin remota o local,
y permite el mapeo de instancias de recursos lgicos mltiples dentro del mismo recurso fsico y administracin de recursos dentro de un VO basado en la
composicin de recursos de menor nivel.
Una virtualizacin permite la composicin de servicios par formar servicios
ms sofisticados -sin tener en cuenta cmo estn compuestos e implementados
los servicios-.
La virtualizacin de Grid services tambin sostiene la habilidad para mapear comportamiento semntico de servicio comn sin costura dentro de facilidades de plataforma nativa.
Una virtualizacin es ms fcil si las funciones de servicio pueden ser expresadas en una forma standard, as cualquier implementacin de un servicio
puede ser pedida de la misma manera.
WSDL, el cual se adopta para este propsito, soporta un servicio de definicin de interfase diferente a los enlaces de protocolos usados para la peticin
de servicios.
WSDL permite mltiples enlaces para una interfase simple, incluyendo protocolos de comunicacin distribuidos (por ejemplo HTTP) tanto como enlaces
locales ptimos (por ejemplo IPC) para interacciones entre peticin y procesos
de servicio en el mismo host.
Otras propiedades de enlaces pueden incluir confiabilidad (y otras formas
84
de QoS ) tanto como la autenticacin y delegacin de credenciales. La eleccin de un enlace siempre deber ser transparente al cliente con respecto a
las semnticas de peticin de servicios -pero con respecto a otras cosas, por
ej. un cliente deber ser capas de elegir un enlace particular por razones de
performance-.
Las definiciones de servicio y enlace de acceso son tambin diferentes a la
implementacin de la funcionalidad del servicio.
Un servicio puede soportar implementaciones mltiples en diferentes plataformas, facilitando capas sin conexin (sin costura) no slo para facilidades
de plataforma nativa pero tambin, va la animacin de implementaciones de
servicios a ensambles de recursos virtuales.
Dependiendo de la plataforma y el contexto, se deberan usar los siguientes
enfoques de implementacin:
Se puede usar una implementacin de referencia portable, que se puede
usar a travs de mltiples plataformas para soportar el ambiente de
ejecucin (contenedor) para un servicio hosting.
En una plataforma que posee facilidades nativas especializadas para el
envi de funcionalidad de servicio, se puede mapear desde la definicin
de interfase de servicio hasta las facilidades de plataforma nativa.
Tambin se pueden usar estos mecanismos recursivamente de manera tal
que un servicio de alto nivel se construya por composicin de mltiples
servicios de bajo nivel, los cuales tambin pueden mapear facilidades
nativas o descomponer otras.
La implementacin de servicio luego enva operaciones a servicios de ms
bajo nivel.
En una plataforma que no soporta una facilidad de rastreo robusta, se
puede crear una implementacin de referencia y hospedada (hosted) en un
ambiente de ejecucin de servicio para almacenar y retener grabaciones de
registros solicitadas (on demand).
En una plataforma que ya posee una facilidad de rastreo robusta, sin embargo se puede integrar la capacidad de servicio de rastreo distribuida con
mecanismos de rastreo de plataforma nativa, y as nivelar herramientas de administracin de rastreo operacional existente, descarga auxiliar, restauracin
85
y otros, mientras se preserva semnticamente el flujo de rastreo lgico a travs

del servicio de rastreo distribuido.
Finalmente, en el caso de un servicio de ms alto nivel, los registros de rastreo obtenidos de servicios de ms bajo nivel seran combinados y presentados
como la facilidad de rastreo integrada para el servicio.
La habilidad para adaptarse a funciones de sistemas operativos en hosts
especficos es central para esta virtualizacion de comportamientos de recursos,
los registros de rastreo obtenidos de servicios de ms bajo nivel seran combinados y presentados como la facilidad de rastreo integrada para el servicio.
Un desafo importante al desarrollar estos mapeos es permitir la explotacin de capacidades nativas -ya sea concernientes al monitoreo de performance,
administracin de trabajo de carga, determinacin de problemas o refuerzo de
la poltica de seguridad de plataforma- de tal manera que el ambiente de Grid
no se convierta en el menor denominador comn de sus piezas constituyentes.
Los mecanismos de descubrimiento del Grid service son importante en este
respecto, permitiendo que servicios de alto nivel descubran qu capacidades
son soportadas por una implementacin particular de una interfase.
As, la arquitectura de servicio soporta transparencia local y remota con
respecto a la peticin y ubicacin del servicio.
Tambin permite que enlaces de protocolos mltiples faciliten la optimizacin localizada de peticin de servicios cuando el servicio es localmente hosteado con el solicitante (cliente) del servicio, tambin permite la negociacin
de protocolos para flujos de red a travs de lmites organizacionales donde se
puede elegir entre diferentes protocolos de InterGrid, cada uno optimizado con
diferentes propsitos.
Finalmente se puede observar que la implementacin de una interfase de
Grid service particular puede mapear capacidades, funciones de plataformas
no distribuidas y nativas.
4.3.2
Semnticas de Servicio: el Grid Service
Se requieren semnticas standard para interacciones de servicios, as por ejemplo diferentes servicios siguen las mismas convenciones para notificacin de
error.
86
Para este fin, el OGSA define lo que se llama un Grid service: un Web
service que provee un conjunto de interfases bien definidas y que sigue convenciones especficas, el descubrimiento de administracin de interfase, creacin
de servicio dinmico, administracin, notificacin y administracin de tiempo
de vida, la designacin de administracin de convenciones y posibilidad de
ampliacin.
Otras cuestiones importantes son: autentificacin y peticin confiable, son
vistas como conexiones de protocolo de servicio y son externas a la definicin
del Grid service central, pero deben ser dirigidas dentro de una implementacin
de OGSA completa. Esta divisin de ideas incrementa la generalidad de la
arquitectura sin comprometer la funcionalidad.
Las interfases y convenciones que definan a un Grid service se relacionan en
particular con comportamientos vinculados a la administracin de instancias
de servicios transitorios.
Participantes de VO tpicamente mantienen no meramente un conjunto esttico de servicios persistentes que manejan complejas consultas de actividades
de clientes, los que a menudo necesitan iniciar nuevas instancias de servicios
transitorios dinmicamente, los cuales luego manejan la administracin e interacciones asociadas con el estado de actividades de consultas particulares.
Cuando el estado de la actividad ya no es necesario, el servicio puede ser
destruido. Por ejemplo un sistema de videoconferencia, el establecimiento
de una sesin de videoconferencia podra incluir la creacin de instancias de
servicios en puntos intermedios para administrar flujos de datos extremo a
extremo de acuerdo a las restricciones de QoS. O, en un ambiente de servidor
de Web, instancias de servicio podran ser instanciadas dinmicamente para
proveer un tiempo de respuesta de usuario consistente administrando la carga
de trabajo de aplicacin a travs de una capacidad dinmicamente adicional.
Otros ejemplos de instancias de servicios transitorios podran ser una peticin a sobre una base de datos, una operacin de minera de datos, una
asignacin de red de banda ancha, una ejecucin de transferencia de datos y
una reserva avanzada de capacidad de proceso.
Estos ejemplos enfatizan que las instancias de servicio pueden ser entidades
extremadamente livianas creadas para administrar incluso actividades de corta
duracin. La transitoriedad tiene significativas implicaciones en cuanto a cmo
los servicios son administrados, descubiertos, designados y usados.
87
Convenciones de Posibilidad de Mejora y Protocolos de Trasporte

Los servicios dentro de un sistema complejo distribuido deben ser independientemente incrementables. Por eso la interpretacin y compatibilidad entre
servicios debe ser administrada y expresada de tal manera que los clientes
puedan descubrir no slo versiones de servicio especfico sino tambin servicios compatibles.
Adems, los servicios (y los ambientes hosting en los cuales ellos se ejecutan) deben ser capaces de incrementarse sin interrumpir la operacin de sus
clientes. Por ejemplo, una actualizacin en el ambiente hosting puede cambiar
el conjunto de protocolos de red que pueden ser usados para comunicarse con
el servicio, y una actualizacin del servicio mismo puede corregir errores o
incluso mejorar la interfase.
Adems, el OGSA define convenciones que permiten identificar cundo
un servicio cambia y cundo estos cambios son compatibles hacia atrs con
respecto a la interfase y las semnticas (pero no necesariamente protocolos de
red).
El OGSA tambin define mecanismos para refrescar el conocimiento de
un cliente acerca de un servicio, tales como qu operaciones soporta o qu
protocolos de red pueden ser usados para comunicarse con el servicio.
Una descripcin de servicio indica las conexiones de protocolo que se pueden usar para comunicarse con el servicio.
A menudo dos operaciones son deseables en tales conexiones.
Peticin de un Servicio Confiable. Los servicios interactan unos con
otros a travs del intercambio de mensajes. En sistemas distribuidos
propensos a fallas de componentes, sin embargo, no se puede garantizar
que un mensaje ha sido enviado. La existencia de un estado interno hace
que sea importante ser capaz de garantizar que un servicio ha recibido un
mensaje ya sea una vez o no. Desde este fundamento se puede construir
un amplio rango de semnticas de alto nivel, tales como transacciones.
Autenticacin. Los mecanismos de autenticacin permiten que la identidad de individuos y servicios sean establecidos por restricciones de poltica. As, a menudo se desear un protocolo de transporte que provea
una autenticacin mutua de cliente e instancia de servicio, tanto como
88
la delegacin de credenciales Proxy. Desde este fundamento se puede

construir un amplio rango de mecanismos de autorizacin de alto nivel.
Descubrimiento. Las aplicaciones requieren mecanismos para descubrir
servicios disponibles y para determinar las caractersticas de esos servicios de
tal manera que puedan configurarse a ellos mismos y sus consultas a esos
servicios apropiadamente. Se realiza este requerimiento:
Una representacin standard para service data, es decir informacin acerca de instancias de Grid service, el cual se estructura como un conjunto
de elementos designados y tipados XML llamados elementos service data,
encapsulados en un formato de contenedor standard.
Una operacin standard, FindServiceData (dentro de la interfase Grid
service requerida), para recuperar service data de instancias de Grid
service individual (pull modo de acceso; obsrvese la interfase NotificationSource para modo de acceso push).
Interfases standard para registrar informacin acerca de instancias de
Grid service con servicio de registro (Registry) y para mapeo desde manipular a referencia (HandleMap).
Creacin de servicio dinmico. La habilidad para crear dinmicamente y
administrar instancias nuevas de servicios es un principio bsico del modelo
OGSA y necesita la existencia de servicios de creacin de servicio. El modelo
OGSA define una interfase standard (Factory) y semnticas que cualquier
servicio de creacin de servicio debe proveer.
Administracin del Tiempo. Cualquier sistema distribuido debera ser capaz de administrar fallos inevitables. En un sistema que incorpora instancias
de servicio estable y transitorio, deben proveerse mecanismos para reclamar
servicios y estados asociados con operaciones de falla. Por ejemplo la terminacin de una sesin de videoconferencia podra tambin requerir la terminacin
de servicios creados en puntos intermedios para administrar el flujo. Se realiza
este requerimiento al definir dos operaciones standard:
Destruir y Establecer Tiempo de Terminacin (dentro de la interfase requerida de Grid service), para destruccin explicita y administracin de tiempo
de vida de los estados de soft de instancias de Grid service, respectivamente.
(Protocolos de Estado de Soft. [15] permite que un estado establecido en una
89
ubicacin remota pueda ser desechado finalmente, a menos que se actualice

por una corriente de mensajes subsecuentes keepalive (vivo). Tales protocolos tienen las ventajas de ser flexibles a los fallos -un simple mensaje perdido
no necesita ser la causa de un dao irrecuperable- y simple: se requiere un
mensaje de protocolo no confiable discad).
Notificacin. Una coleccin de servicios distribuidos y dinmicos debe ser
capaz de comunicar unos a otros asincrnicamente acerca de cambios interesantes de su estado. El OGSA define abstracciones comunes e interfaces de
servicio para subscripcin a (fuente de notificacin NotificationSource) y envo de (NotificationSink ) tales notificaciones de tal manera que los servicios
construidos por la composicin de servicios ms simples puedan manejar las
notificaciones (por ej. para errores) en forma standard.
La interfase NotificationSource est integrada con el service data de tal
manera que una consulta de notificacin sea expresada como una consulta
para un subsecuente envo de modo push de service data.
4.3.3
El Rol de Ambientes Hosting
La OGSA define las semnticas de una instancia de Grid service: cmo es creada, cmo se llama, cmo se determina su tiempo de vida, cmo comunicarse
con ella, etc.
Sin embargo, mientras la OGSA es prescriptiva en asuntos de comportamiento bsico, no establece requerimientos en cuanto a lo que un servicio
hace o cmo realiza ese servicio, en otras palabras, la OGSA no dirige asuntos
de implementacin de modelo de programacin, lenguaje de programacin,
implementacin de herramientas o ambiente de ejecucin.
En la prctica los Grid service se inician dentro de un ambiente de ejecucin
especifico o ambiente hosting. Un ambiente hosting particular no slo define
la implementacin de modelo de programacin, lenguaje de programacin,
herramientas de desarrollo, herramientas de depuracin, pero tambin como
una implantacin de un Grid service cumple con sus obligaciones con respecto
a la semntica del mismo.
Las aplicaciones del Grid e-cience de hoy tpicamente utilizan procesos de
sistemas de operacin nativos como su ambiente hosting, como por ejemplo,
la creacin de una nueva instancia de servicio incluyendo la creacin de un
90
nuevo proceso. En tales amientes, un servicio puede ser implementado en una

variedad de lenguajes tales como C, C++, JAVA o Fortran.
Semnticas de Grid pueden ser directamente implementadas como parte
del servicio o provista va una librera conectada. Las semnticas no son
tpicamente provistas por servicios externos, ms all de aquellos provistos
por el sistema operativo. As como por ej., funciones de administracin de
tiempo de vida, deben realizarse dentro de la aplicacin misma, si se requiere.
Los Web services, por el contrario, pueden ser implementados en contenedores ms sofisticados o ambientes hosting basados en componentes tales
como J2EE, WEBSPHERE, .NET, y SUN ONE. Tales ambientes definen un
marco (contenedor) dentro de los cuales los componentes adheridos a las interfases de ambiente standards pueden ser iniciadas y compuestas para construir
aplicaciones complejas.
Comparadas con los bajos niveles de funcionalidad provistos por ambientes
hosting nativos, ambientes hosting componente / contenedor tienden a ofrecer
programacin superior, administracin, flexibilidad y seguridad.
Consecuentemente, ambientes hosting basados en contenedor / componente son ampliamente usados para la construccin de servicios e-business. En el
contexto de la OGSA el contenedor (ambiente hosting) tiene responsabilidad
primaria de asegurar que el servicio que soporta se adhiere a la semntica de
Grid service, y as la OGSA podra motivar modificaciones o adiciones a la
interfase de contenedor / componente.
Al definir la semntica de service, la OGSA especifica interacciones entre
servicios de manera independiente de cualquier ambiente hosting. Sin embargo, implementaciones exitosas de Grid service se pueden facilitar al especificar
caractersticas de lnea base que todos los ambientes hosting deben poseer al
definir la interfase interna desde la implementacin del servicio al ambiente
de Grid Global.
Estas caractersticas luego sern presentadas en diferentes tecnologas de
implementacin (por ej. J2EE o libreras compartidas).
4.3.4
91
Usar Mecanismos de OGSA Para Construir Estructuras

de VO
Las aplicaciones y usuarios deben ser capaces de crear servicios transitorios,

descubrir y determinar las propiedades de servicios disponibles.
Las interfases de OGSA Factory, Registry, GridService, y HandleMap soportan la creacin de instancias de servicios transitorios, el descubrimiento y
la caracterizacin de la instancias de servicio asociadas con un VO.
En efecto, un servicio de registro-una instancia de servicio que soporta la
interfase de registro para el registro y operacin de FindServiceData de la interfase de Grid service, con datos de servicio apropiado, para el descubrimientodefine el conjunto de servicios asociados con una VO.
Estas interfases pueden ser usadas para construir una variedad de estructura de servicio VO, (ver en la fig. 4.2 de la pg. 92).
Un Ambiente de Ejecucin Simple. Es un conjunto de recursos ubicados
dentro de un dominio administrativo simple y soporta facilidades nativas para
la administracin de un servicio: por ej. un servidor de aplicacin J2EE ,
Microsoft .NET system o Linux cluster.
En OGSA la interfase del usuario en tal ambiente ser tpicamente estructurada como un registro, uno o ms desarrollos, y un servicio HandleMap.
Cada desarrollo es grabado en el registro, para permitir a los clientes descubrir
desarrollos disponibles.
Cuando un desarrollo recibe una consulta de un cliente para crear una
instancia de Grid service, la infraestructura de desarrollo pide capacidades
especficas de ambiente hosting para crear una instancia nueva, asignando
un handle, registra una instancia con el registro, y hace el handle disponible
para el servicio HandleMap. Las implementaciones de estos servicios mapean
directamente dentro de operaciones locales.
Ambiente Hosting Virtual. En ambientes ms complejos los recursos asociados con un VO abarcarn ambientes hosting heterogneos, geogrficamente
distribuidos (por ej., se puede observar en la fig. 4.2 de la pg. 92, que estos
recursos abarcan dos ambientes hosting simples).
Sin embargo, este ambiente hosting virtual (que corresponde quizs al conjunto de recursos asociados con una membresa de B2B) puede ser accesible
92
Figura 4.2: Tres Diferentes Estructuras VO, Ambiente Hosting Simple y Virtual y Servicios Colectivos.
para un cliente va exactamente las mismas interfases que fueron usadas para
el ambiente hosting descripto.
Se crean una o ms infraestructuras de ms alto nivel que delegan consultas de creacin a infraestructuras de bajo nivel. Similarmente se crea un
registro de ms alto nivel que conoce acerca de las infraestructuras de ms alto
nivel y las instancias de servicio que ellas han creado, tanto como cualquier
poltica especfica de VO que gobierna el uso de servicios VO.
Luego los clientes pueden usar el registro VO para encontrar infraestructuras y otras instancias de servicio asociadas con el VO y posteriormente usar
los handles devueltos por el Registro para comunicarse directamente a esas
instancias de servicio.
Las infraestructuras y Registros de ms alto nivel implementan interfases standard y as, desde las perspectivas del usuario, son indistinguibles de
cualquier otra infraestructura o Registro.
Se observa que aqu como en el ejemplo previo el handle del Registro puede
ser usado globalmente como un nombre nico para un conjunto de servicios
mantenidos por el VO. Las polticas de administracin de recursos pueden ser
definidas y reforzadas en las plataformas de servicios VO hosting, dirigindose
al VO con este nombre nico.
Operaciones Colectivas. Se puede tambin construir un ambiente hosting
4.4. APLICACIN EJEMPLO
93
virtual que provea a los participantes del VO con servicios ms sofisticados,

virtuales, colectivos o de fin a fin. En este caso el Registro mantiene la trayectoria y advierte a las infraestructuras que se crean instancias de servicios
de ms alto nivel.
Tales instancias se implementan al pedir que infraestructuras de bajo nivel
creen instancias de servicios mltiples y al componer los comportamientos de
estas instancias mltiples de servicios de menor nivel, en instancias simples de
servicios de ms alto nivel.
Estos ejemplos comentados anteriormente ilustran cmo los mecanismos
del Grid service pueden ser usados para integrar recursos distribuidos a travs de lmites multiorganizacionales virtuales y dentro de infraestructuras IT
comerciales internas. En ambos casos, una coleccin de Grid services asociados con servicio de descubrimiento apropiado pueden soportar capacidades
funcionales distribuyendo interacciones QoS a travs de fuentes de recursos
distribuidos.
Las aplicaciones y middleware pueden explotar estos servicios para la administracin de recursos distribuidos a travs de plataformas heterogneas con
transparencia remota y local y flujos optimizados localmente.
Las implantaciones de Grid service que mapean los recursos de plataforma
nativa y APIs habilitan una integracin sin conexin de Grid service de alto
nivel tales como las descriptas con componentes de plataforma fundamental.
Adems conjuntos de servicios asociados con VOs mltiple puede mapear
los mismos recursos fsicos fundamentales, con esos servicios representados
lgicamente como distintos en un nivel pero que comparten sistemas de recursos fsicos en niveles ms bajos.
4.4
Aplicacin Ejemplo
En la fig. 4.3 de la pg. 95 se muestran las etapas sucesivas de la vida de

una computacin de minera de datos, cuyo uso refleja el trabajo de invocacin de servicio remoto bsico, administracin de ciclo de vida y funciones de
notificacin:
El ambiente inicialmente se compone de (de derecha a izquierda) cuatro
ambientes hosting simples: uno que ejecuta las aplicaciones del usuario;
94
uno que encapsula los recursos de almacenamiento y cmputo (y que

soporta dos servicios de infraestructura, uno para crear reservaciones
de almacenamiento y otro para crear servicios de minera) y dos que
encapsulan servicios de bases de datos. Las Rs representan servicios
de Registro locales, un servicio de registro VO adicional presuntamente
provee informacin acerca de la ubicacin de los servicios descriptos.
La aplicacin del usuario solicita crear Grid service en las dos infraestructuras en el segundo ambiente hosting, solicitando la creacin de un
servicio de minera de datos que ejecutar la operacin de minera de
datos en su nombre y una ubicacin de almacenamiento temporal para
uso de ese cmputo. Cada consulta incluye una autenticacin mutua
del usuario y la infraestructura correspondiente (usando un mecanismo
de autenticacin descripto en el servicio de infraestructura), seguida por
la autorizacin de la consulta. Cada consulta es exitosa y resulta en
la creacin de una instancia de Grid service con algn tiempo de vida inicial. La nueva instancia de servicio de minera de datos tambin
se provee con credenciales proxy delegadas que le permite ejecutar ms
operaciones remotas en nombre del usuario.
El nuevo servicio de minera de datos creado, usa sus credenciales proxy
para consultar datos desde dos servicios de bases de datos, ubicando los
resultados intermedios en almacenamiento local. El servicio de minera de datos tambin usa mecanismos de notificacin para proveer a la
aplicacin del usuario con datos actualizados peridicamente. Mientras
tanto, la aplicacin del usuario genera consultas peridicas keepalive
para las dos instancias de servicio Grid que l ha creado.
Si la aplicacin del usuario falla por alguna razn, los cmputos de minera de datos continan, pero como ninguna parte tiene inters en sus
resultados, no se generan ms mensajes keepalive.
Debido al fracaso de la aplicacin, los mensajes keepalive cesan, as
como las dos instancias de Grid service finalmente terminan, liberando
el almacenamiento y los recursos de cmputo que existieran.
4.4. APLICACIN EJEMPLO
Figura 4.3: Ejemplo de servicio grid operando.
95
Captulo 5
Web Services y Grid Services

5.1
5.1.1
Web Services: Servicios Web

Definicin y Caracterizacin de Web Services
Un Web Service es un componente de software que se comunica con otras

aplicaciones codificando los mensaje en XML y enviando estos mensaje a travs
de protocolos estndares de Internet tales como el Hypertext Transfer Protocol
(HTTP). Intuitivamente un Web Service es similar a un sitio web que no cuenta
con un interfaz de usuario y que da servicio a las aplicaciones en vez de a las
personas. Un Web Service, en vez de obtener solicitudes desde el navegador
y retornar paginas web como respuesta, lo que hace es recibir solicitudes a
travs de un mensaje formateado en XML desde una aplicacin, realiza una
tarea y devuelve un mensaje de respuesta tambin formateado en XML.Ver
fig. 5.1 de la pg. 98.
La base fundamental de los Grid services en la implementacin de Globus
es el estndar Web services.
Web service es una tecnologa de computacin de sistemas distribuidos que
permite la creacin de aplicaciones basndose en el modelo cliente/servidor
mediante una plataforma independiente del lenguaje y utilizando protocolos
abiertos como HTTP.
Los Web services usan el protocolo SOAP (Simple Objects Access Protocol)
y gramtica XML para comunicarse, aunque el protocolo bsico de transporte
97
98
CAPTULO 5. WEB SERVICES Y GRID SERVICES
Figura 5.1: Web Service.

es HTTP para realizar las peticiones y las repuestas, aunque puede usar otros
como JMS, etc.
Mientras que las tecnologas distribuidas tales como CORBA, EJB, COM /
DCOM, etc estn orientadas a clientes y servidores muy dependientes, los Web
services estn orientados usar clientes que no tienen un conocimiento previo
del servicio hasta que se le invoca, es decir, existe un fuerte desacoplamiento
entre cliente y el servidor del servicio.
Los Web services no manejan servicios con informacin de estado (stateful),
es decir, no recuerdan valores de una llamada a otra. Sin embargo, en
entornos distribuidos contemplan en numerosas ocasiones escenarios en que s
se requiere informacin de estado. Los Servicios Grid aaden esa capacidad a
los Web Services.
Para invocar un Web Service se dan los pasos siguientes:
El cliente localiza el Web service mediante el uso de un registro UDDI
(desarrollado por IBM, permite mantener permite mantener un registro
global de los Web services)o cualquier otro sistema que permita revisar
las descripciones WSDL de los Web services.
El registro UDDI responde devolviendo una direccin URI (Universal
Resource Identifier ) que apunta a uno de los servidores que contiene el
Web service.
5.2. GRID SERVICES: SERVICIOS GRID
99
Una URI es equivalente a una URL dentro de una pgina Web. Los Web
services suelen usar URIs porque suelen estar dentro de un contenedor Web.En
URI la estructura sera: http: //sitio.com/aplicacion/servicio-web -xxxx.
El cliente sabe donde est el Web service mediante el URI, pero no sabe
como invocarlo, para lo cual pregunta al servidor Web como hacerlo.
El servidor Web le contesta con un fichero WSDL (Web Services Definition Language) que da los detalles para hacer la invocacin. Es decir,
describe el interfaz del Web service.
Una vez conocido el dnde y el cmo, se hace la invocacin.
Se puede hacer de varias formas, pero la ms comn es usar SOAP (Simple Object Access Protocol ), un protocolo que permite llamadas remotas de
servicios (programas) mediante mensajes codificados y encapsulados en XML.
El Web service contesta con la respuesta SOAP en un mensaje escrito en
gramtica XML.WSDL, API, UDDI, WSDL, SOAP sobre HTTP.
El desarrollo de Web services habitualmente no necesita considerar los
detalles SOAP y WSDL ya que las herramientas generan automticamente
unos stub o proxys que interpretan las peticiones y las enrutan al destino
adecuado.
5.2
Grid Services: Servicios Grid
Un Grid Service es una ampliacin de los Web Services, su arquitectura est

especificada por el Global Grid Forum (OGSA). Usa una tecnologa de objetos
distribuidos que se adapta a las necesidades de una aplicacin Grid, que son
los Web services, los cuales en presentaban algunas limitaciones que se fueron
superando:
Los Web services no mantienen el estado de una invocacin a otra, los
Grid services si.
Los Web services no son transientes, es decir no se pueden crear varias
instancias de un mismo servicio segn se necesita y destruirlas cuando
ya no son necesarias, en los Grid services, se puede.
100
Los Web services no incluyen servicios de soporte que han sido incluidos
en los Grid services como son las notificaciones, el servicio de persistencia, la gestin del ciclo de vida, etc.
Los Grid services utilizan un enfoque de Factoras de Objetos de manera
que en lugar de tener un nico servicio compartido por todos los usuarios (como
el Web Service) se tiene un servicio-factora que crea instancias individuales
del servicio.
Cuando se invoca a una operacin del servicio se accede a la instancia y
no a la factora. Adems se puede crear una instancia por cliente, o varias por
cliente o una para varios clientes. Por ltimo la destruccin de la instancia
puede correr a cargo del cliente o de la factora.
Los servicios Grid estn construidos utilizando Web services pero se les
incorporan una serie de mecanismos de la plataforma OGSI.
Estos mecanismos adicionales se pueden agrupar en cuatro reas:
Servicio de Nombres (Naming) , que asegura la existencia de un nombre
nico para cada instancia de
Servicio Grid, permite la localizacin de los mismos (discovering) mediante nombres.
Servicio de Datos, que gestionan los conjuntos de datos asociados a la
ejecucin de un servicio Grid
Notificacin, es decir el conjunto de interfaces para registrar y suministrar notificaciones y subscripciones. Estos son los mecanismos usados
para la comunicacin entre los componentes de una aplicacin Grid.
Ciclo de Vida, mecanismos para la creacin y destruccin de instancias
de Servicios Grid
5.2.1
Servicio de Nombres (GSH y GSR)
Los Grid services, al igual que los Web services sobre los que se basan, utilizan
URIs para localizarse.
101
Sin embargo, dentro de la terminologa OGSI, un URI de un servicio Grid

se denomina Grid Service Handler (GSH ), pero conceptualmente es lo mismo.
Adicionalmente, este GSH, al igual que un URI, debe resolverse para encontrar el servidor especfico que contiene la instancia del servicio Grid, es
decir una referencia llamada Grid Service Reference (GSR). Un GSH debe
ser nico y apuntar a una instancia de servicio Grid, pero no contiene informacin suficiente para invocar la instancia. Esta informacin esta contenida
en el GSR. Un GSR no es un puntero permanente a una instancia de servicio
Grid ya que los GSR pueden invalidarse por razones tales como, por ejemplo,
que dicha instancia se pase de un servidor a otro diferente. Esto significa que
debe haber mecanismos de actualizacin de los GSR.
5.2.2
Servicio de Datos (Service Data)
Este es uno de los conceptos ms importantes de Grid Computing. Un servicio

de datos es una coleccin estructurada de informacin que va asociada a una
instancia concreta de un Servicio Grid, es decir, es un mecanismo para exponer
los datos de estado de la instancia a los peticionarios del servicio (un cliente
u otros servidores).
Dichos peticionarios pueden hacer una query (peticin), o modificar esta
informacin en funcin del privilegio de acceso. Estos elementos de informacin se denominan Service Data Elements (SDE ) y contienen informacin de
contexto y de estado de la instancia del servicio Grid. Cada instancia de un
servicio tiene varios SDEs, de diferentes tipos.
Para suministrar la informacin adecuada para describir el interfaz de un
Stateful Web Service (por ejemplo un Servicio Grid), es necesario una descripcin de los datos de ste estado que son externamente observables, es decir,
los que son usados por un cliente que use la interfaz declarada del servicio.
Es equivalente a la declaracin de atributos en un interfaz OO (orientado
a objeto) de un IDL (Interface Definition Language). Ya que WSDL define
operaciones y mensajes para los portTypes, el estado declarado de un servicio debe ser slo externamente accedido a travs de operaciones del servicio
definidas en la interfaz de dicho servicio.
Para evitar la necesidad de definir operaciones especficas de service Data para cada SDE, el portType de los servicios suministra operaciones base
102
para manipular los SDE por nombre. Esta declaracin permite expresar los
elementos de la informacin de estado pblicamente disponibles.
La parte interna privada del estado no es parte de la interfaz y por tanto
no esta representada por una declaracin de datos del servicio.
El concepto de service Data es muy semejante al concepto de variable
pblica de instancia o de campo en lenguajes orientados a objeto tales como
Java, SmallTalk o c#.
As, por ejemplo, en Java un javabean define convenciones para las firmas
de mtodo para acceder a las propiedades y clases helper para documentar las
propiedades. El modelo OGSI usa service Data elements (SDE ) y tipos de
esquema XML (WSDL) para hacer eso mismo respectivamente, pero con la
ventaja de ser un procedimiento extensible y que permite querys complejas y
semnticas de suscripcin.
Una caracterstica muy importante de los service Data es su extensibilidad.
Los service Data definen un nuevo elemento de portType denominado service Data que permite definir service Data Elements (SDE ), asociados con
este portType. Los valores de estos SDE pueden declararse estticamente en
el portType o dinmicamente a lo largo de la vida del Web Service o Grid
Service.
Adems de los SDE estndar definidos por OGSI, existe una API para
permitir la creacin dinmica de service Data que corresponde a los datos del
WSDL de la instancia concreta del servicio Grid.
Las instancias del Servicio Grid mantienen el valor del service Data, que
pueden ser solicitadas en cualquier momento o ser asociadas a una notificacin
de aviso cuando su valor cambie.
OGSI define para esto una interfaz para hacer querys a los SDEs o subscribirse a notificaciones de aviso (que avisen de cambios en los SDE, lo cual
puede ser bastante til).
5.2.3
Notificaciones
Las notificaciones son mecanismos de comunicacin entre los componentes de

la infraestructura, permite el envo de mensajes desde una fuente de Notificacin a un Sumidero de Notificacin, segn la terminologa de OGSI (Notation
103
Source y Notation Sink ). Se trata de un mecanismo de mensajera asncrona. La mensajera asncrona tiene dos variantes: los gestores de colas, y el
mecanismo de publicacin-suscripcin a un topic (que bsicamente es una cola). La implementacin de GT gestiona el ciclo de notificaciones mediante un
mecanismo de suscripcin.
El ciclo de notificaciones tiene los siguientes:
Peticin de Suscripcin: la fuente recibe un mensaje con la localizacin
del Sumidero a donde se deben mandar los mensajes, as como un tiempo
de vida para el origen de la suscripcin. Una peticin de suscripcin
genera una instancia de servicio Grid denominada Suscripcin. Se utiliza
la definicin Notification Source portType .
Expresin de la Suscripcin: es un documento XML que describe las
reglas y el formato del mensaje de la Notificacin (destino de la notificacin, cuando debe enviarse, etc.)
Instancia del Servicio Grid de suscripcin: es una instancia de servicio
Grid que se crea durante la operacin de suscripcin y que se encarga
de gestionar las propiedades de la suscripcin.
Fuente de la Notificacin: es una instancia de servicio Grid que enva
notificaciones
Mensaje de la Notificacin: puede ser un mensaje esttico (no necesita
suscripcin) o bien sujeto a modificaciones futuras dinmicas de un SDE
(service Data Element) concreto para lo cual necesita un procedimiento
de suscripcin.
Sumidero de Notificacin: es la instancia de servicio Grid que recibe
los mensajes. La implementacin de este mecanismo de publicacinsuscripcin entre los distintos componentes se hace en el Globus Toolkit
mediante el servicio JMS (Java Messaging Services) definido dentro
del estndar J2EE. La interaccin con el cliente sigue hacindose va
SOAP/http.
5.2.4
Ciclo de Vida
El ciclo de vida de un servicio Grid est marcado por la creacin y la destruccin de la instancia de este servicio. Es una propiedad bsica de servicio Grid
104
y esta controlada por el llamado hosting environment (el sistema que aloja
a la plataforma Grid, el Globus Toolkit en este caso), pero que, sumariamente, puede ser el propio sistema operativo, un contenedor (servidor) Web, un
contenedor J2EE, etc.
Un servicio Grid soporta tambin notificaciones relativas a eventos del ciclo
de vida, lo que permite a los servicios Grid ser conscientes de la situacin de
otros servicios y tenerlo en cuenta para la dinmica de la propia aplicacin
Grid.
Para crear una instancia de un servicio Grid se hace una peticin a un
objeto Factory para que cre una instancia para el cliente, mientras que su
destruccin se hace por dos vas: la invocacin de un mtodo especfico dentro
de la instancia, o mediante un procedimiento llamado de soft-state en el que
una instancia que durante un periodo de tiempo no ha sido usada o refrescada,
termina.
El mecanismo de creacin de instancias de servicios Grid es, la invocacin
de un objeto Factory. Est definida en la especificacin OGSI y se implementa
mediante un interfaz Factory. La operacin de crear un servicio Grid devuelve
el GSH (un URI) del servicio solicitado. El GSH es resuelto en un GSR (es
decir, la descripcin completa en formato WSDL) que tiene un tiempo de
validez determinado (mientras que el GSH es permanente).
Los pasos a partir de aqu son:
El cliente localiza una Factory en el registro o servicio de nombres relativo al servicio Grid a ejecutar.
El cliente llama a una operacin dentro del Factory para crear una instancia del servicio Grid.
El factory crea la instancia.
El factory devuelve el GSH (el URI) del nuevo servicio Grid al cliente.
El cliente y el servidor interactan a travs del servicio como resultado
de la llamada inicial.
5.2.5
Qu Ofrecen los Nuevos Grid Services
Acceso a servicios desde cualquier sitio en la red.
105
Permiten la solucin de aplicacines complejas.

Menor acoplamiento y mayor granularidad.
Alquiler de sercvicios externos.
Alquiler de recursos propios.
Eso si cabe aclarar que estn en su etapa inicial.

El objetivo de los Grid services no es sustituir a als tecnologas exixtentes
sino complementarlas.
Captulo 6
Software Utilizado
6.1
6.1.1
Sistema Operativo Linux - Administracin Bsica
Introduccin
Linux es probablemente el acontecimiento ms importante del software gratuito desde el original Space War, o, ms recientemente, Emacs. Se ha convertido
en el sistema operativo para los negocios, educacin, y provecho personal. Linux ya no es slo para gurs de UNIX que se sientan durante horas frente
a la resplandeciente consola (aunque le aseguramos que un gran nmero de
usuarios pertenece a esta categora).
Linux es un clnico del sistema operativo UNIX que corre en ordenadores
107
108
CAPTULO 6. SOFTWARE UTILIZADO
Intel 80386 y 80486. Soporta un amplio rango de software, desde TEX a X

Windows, al compilador GNU C/C++, a TCP/IP. Es una implementacin de
UNIX verstil, distribuida gratuitamente en los trminos de la Licencia GNU.
Linux puede convertir cualquier PC 386 o 486 en una estacin de trabajo.
Le pondr todo el poder de UNIX en la punta de sus dedos. En los negocios
ya se instala Linux en redes enteras, usando el sistema operativo para manejar registros financieros y de hospitales, un entorno de usuario distribuido,
telecomunicaciones, etc. Universidades de todo el mundo usan Linux para
dar cursos de programacin y diseo de sistemas operativos. Y, por supuesto,
entusiastas de los ordenadores de todo el mundo estn usando Linux en casa,
para programar, entretenerse, y conocerlo a fondo.
Lo que hace a Linux tan diferente es que es una implementacin gratuita
de UNIX. Fue y an es desarrollado por un grupo de voluntarios, principalmente en Internet, intercambiando cdigo, comentando fallos, y arreglando los
problemas en un entorno abierto.
6.1.2
Qu es Linux?
Linux es un sistema operativo gratuito y de libre distribucin inspirado en el

sistema UNIX, escrito por Linus Torvalds con la ayuda de miles de programadores en Internet.
UNIX es un sistema operativo desarrollado en 1970, una de cuyas mayores
ventajas es que es fcilmente portable a diferentes tipos de ordenadores, por lo
que existen versiones de UNIX para casi todos los tipos de ordenadores, desde
PC y Mac hasta estaciones de trabajo y superordenadores. Al contrario que
otros sistemas operativos, como por ejemplo MacOS (Sistema operativo de los
Apple Macintosh), UNIX no est pensado para ser fcil de emplear, sino para
ser sumamente flexible. Por lo tanto Linux no es en general tan sencillo de
emplear como otros sistemas operativos, aunque, se estn realizando grandes
esfuerzos para facilitar su uso. Pese a todo la enorme flexibilidad de Linux y
su gran estabilidad (y el bajo costo) han hecho de este sistema operativo una
opcin muy a tener en cuenta por aquellos usuarios que se dediquen a trabajar
a travs de redes, naveguen por Internet, o se dediquen a la programacin.
Adems el futuro de Linux es brillante y cada vez ms y ms gente y ms y
ms empresas (entre otras IBM, Intel, Corel) estn apoyando este proyecto,
con lo que el sistema ser cada vez ms sencillo de emplear y los programas
sern cada vez mejores.
6.1. SISTEMA OPERATIVO LINUX - ADMINISTRACIN BSICA 109
6.1.3
Por qu Linux?
Cuando se desarroll el sistema operativo Linux, muchos pensaban que no

tendra xito. Hoy Linux cuenta con decenas de miles, si no millones, de
entusiastas usuarios, y estamos seguros de que Linux disfrutar de xito por
largo tiempo.
La lista de rasgos actuales de Linux es impresionante. Por ejemplo, corre
en un rango ms amplio de equipos PC que cualquier otro SO no-Microsoft.
Cuando usted tambin considera que Linux corre sobre computadoras Alpha de
Digital, Sun SPARC y ahora hardware Apple PowerMac, Linux igual aventaja
a otros SOs.
Adems, ofrece un ambiente fiable y estable de multitasking /multithreading en todas stas plataformas, con apoyo para SMP (multiprocesamiento
simtrico), y una amplia lista de hardware drivers para virtualmente todos los
hardware populares. Sin embargo, los factores que asegurarn el xito a largo
plazo de Linux tienen poco que ver con la lista actual de rasgos, y mucho ms
con cmo es licenciado.
6.1.4
Cmo es Licenciado Linux?
Todos estos rasgos parecen notables ms aun cuando usted considera que es
libremente distribuido bajo los trminos de la Licencia GPL. Simplemente
con poner esta licencia permite a cualquiera trabajar en Linux haciendo que
sus cambios estn disponibles bajo los mismos trminos. Esto significa que
mientras Linux puede ser (y es) vendido en una variedad de formas, puede
tambin ser bajado o ser copiado sin costo o restriccin.
La GPL no es el nico tipo de licencia de software free, y Linux se beneficia de software licenciado bajo varios otros tipos de licencias de software
libremente-distribuible.
Los cuatro tipos principales son: Software del Dominio Pblico (Public Domain Software), Shareware, derechos de propiedad de tipo-BSD, y la Licencia
Pblica General (GPL).
110
6.1.5
De Dnde Vienen los Recursos para el Desarrollo de

Linux?
Cmo puede un SO gratis que al parecer no tiene dinero detrs de l ser

competitivo con productos de las compaas de software de computadora ms
ricas del mundo?.
Las apariencias pueden engaar. Hay de hecho una porcin de dinero que
se invierte en desarrollo de Linux. Compaas comerciales de Linux como
Red Hat Software y otras, invierten directamente en Linux a travs de cdigo
que sus programadores escriben y contribuyen bajo la GPL, y dinero que es
donado a los equipos de desarrollo Linux ms importantes como la Fundacin
de Software Libre.
Linux es Construido por los Usuarios para los Usuarios

El volumen de desarrollo de Linux es consolidado por los desarrolladores que
trabajan en Linux para aplicarlo a los proyectos o aplicaciones que ellos necesitan.
Desde proyectos de super-computacin de la NASA al desarrollo de software de empresas como Empress Software, el trabajo es consolidado por los
usuarios para su propio beneficio. El hecho de que este trabajo tambin beneficia de gran forma a la comunidad usuaria de Linux es simplemente una
realidad en el verdadero sentido de esa palabra.
La historia del disco ZIP Iomega en Linux es un buen ejemplo. Grant
Guenther, el diseador en jefe de los fabricantes de bases de datos Empress
Software Inc escogi el ZIP drive como estndar para la compaa para transferir datos, encontr que ellos no tenan soporte para Linux. El tena opciones
y tena que tomar una decisin. Abandonar Linux y comprar nmeros significantes de las licencias caras de las alternativas comerciales, las que vienen
sin compiladores o cdigos fuente -dos de las valiosas caractersticas de Linux
para los desarrolladores de software- o gastar algn tiempo investigando y escribiendo su propio driver ZIP para Linux. Esto ltimo fue lo que hizo Grant.
Habindolo construido, lo anunci entonces en Internet pidiendo ayuda para
probarlo y mejorarlo. Asi, rpidamente se volvi parte del SO Linux para el
uso de cualquiera que tuviera un drive ZIP de Iomega.
6.1.6
Caractersticas Principales
El Sistema Operativo Linux presenta las siguientes caractersticas:

Multitarea: varios programas (realmente procesos) ejecutndose al mismo tiempo.
Multiusuario: varios usuarios en la misma mquina al mismo tiempo.
Multiplataforma: corre en muchas CPUs distintas.
Tiene proteccin de la memoria entre procesos, de manera que uno de
ellos no pueda colgar el sistema.
Carga de ejecutables por demanda: Linux slo lee de disco aquellas partes
de un programa que estn siendo usadas actualmente.
Poltica de copia en escritura para la comparticin de pginas entre ejecutables: esto significa que varios procesos pueden usar la misma zona
de memoria para ejecutarse.
Cuando alguno intenta escribir en esa memoria, la pgina se copia a otro
lugar. Esta poltica de copia en escritura tiene dos beneficios: aumenta
la velocidad y reduce el uso de memoria.
Memoria virtual usando paginacin (sin intercambio de procesos completos) a disco: una particin o un archivo en el sistema de archivos, o
ambos, con la posibilidad de aadir ms reas de intercambio sobre la
marcha.
La memoria se gestiona como un recurso unificado para los programas de
usuario y para el cach de disco, de tal forma que toda la memoria libre
puede ser usada para cach y ste puede a su vez ser reducido cuando se
ejecuten grandes programas.
Se realizan volcados de estado (core dumps) para posibilitar los anlisis
post-mortem, permitiendo el uso de depuradores sobre los programas no
slo en ejecucin sino tambin tras abortar stos por cualquier motivo.
Todo el cdigo fuente est disponible, incluyendo el ncleo completo y
todos los drivers, las herramientas de desarrollo y todos los programas
de usuario; adems todo ello se puede distribuir libremente.
112
Emulacin de 387 en el ncleo, de tal forma que los programas no tengan

que hacer su propia emulacin matemtica. Cualquier mquina que ejecute Linux parecer dotada de coprocesador matemtico. Por supuesto,
si el ordenador ya tiene una FPU (unidad de coma flotante), ser usada
en lugar de la emulacin, pudiendo incluso compilar el propio kernel sin
la emulacin matemtica y conseguir un pequeo ahorro de memoria.
Soporte para muchos teclados nacionales o adaptados, siendo bastante
fcil aadir nuevos dinmicamente.
Consolas virtuales mltiples: varias sesiones de login a travs de la consola entre las que se puede cambiar con las combinaciones adecuadas
de teclas (totalmente independiente del hardware de video). Se crean
dinmicamente y puedes tener hasta 64.
Soporte para varios sistemas de archivo comunes, incluyendo Minix-1,
Xenix y todos los sistemas de archivo tpicos de System V, y tiene un
avanzado sistema de archivos propio con una capacidad de hasta 4 Tb y
nombres de archivos de hasta 255 caracteres de longitud.
Acceso transparente a particiones MS-DOS (o a particiones OS/2 FAT)
mediante un sistema de archivos especial: no es necesario ningn comando especial para usar la particin MS-DOS, parece un sistema de
archivos normal de UNIX (excepto por algunas graciosas restricciones
en los nombres de archivo, permisos, y esas cosas).
Un sistema de archivos especial llamado UMSDOS que permite que Linux
sea instalado en un sistema de archivos DOS.
Soporte en slo lectura de HPFS-2 del OS/2 2.1.
Sistema de archivos de CD-ROM que lee todos los formatos estndar de
CDROM.
TCP/IP, incluyendo ftp, telnet, NFS, etc.
Appletalk disponible en el actual ncleo de desarrollo.
Software cliente y servidor Netware disponible en los ncleos de desarrollo (ya est disponible de forma Standard).
6.1.7
Ventajas de Linux frente a otros S.O.
Entre las ventajas ms destacadas de Linux se pueden mencionar las siguientes:

Linux representa la mejor variante de UNIX, al cual se le han confiado aplicaciones de misin crtica y -debido a su cdigo fuente abiertotiene una credibilidad a largo plazo que excede a muchos otros SO que
compiten con l.
La mayor parte de las aplicaciones primarias que la gente requiere cuando
se desplazan hacia Linux ya estn disponibles de manera gratuita. Entre
ellas estn los servidores de web, clientes POP, servidores de correo,
editores de texto, etc.
Un usuario avanzado del GUI de Win32 tendra que pasar por un perodo corto de aprendizaje para hacerse productivo bajo Linux.
Las virtudes de Linux incluyen: Personalizacin... Disponibilidad /
Confiabilidad... Escalabilidad / Desempeo... Interoperabilidad...
Linux est emergiendo como un sistema operativo clave dentro del mercado de servidores.
Utilizando los requerimientos actuales para servidores, Linux es una alternativa creble para los servidores desarrollados de manera comercial
en muchas aplicaciones de alto volumen.
Se puede usar en casi cualquier computadora, desde una 386.
Puede manejar mltiples procesadores. Incluso hasta 16 procesadores.
114
Libre de virus, aun no se conoce ningn virus para Linux.

Maneja discos duros de hasta 16 TeraBytes.
Se posee el apoyo de millones de usuarios a nivel mundial.
Los fabricantes de Hardware le estn dando su apoyo, como IBM y COMPAQ.
La ventaja ms contundente se encuentra en la relacin costo beneficio,
a comparacin de otros SOs.
6.1.8
X Window
X Window es el entorno grfico habitual de los sistemas UNIX. El sistema

X Window se compone de dos parte principales, el servidor X y el programa
para la gestin de las ventanas. El servidor X es el programa que se encarga
realmente de dibujar en la pantalla. Por el contrario, el gestor de ventanas,
como su nombre indica, es el encargado de crear las ventanas y gestionar su
apariencia. Debido a este modelo, la apariencia de las aplicaciones vara segn
se use uno u otro gestor de ventanas, entre los que destacan por su sencillez
de uso los entornos GNOME y KDE.
Al instalar Linux el sistema puede preguntar si se desea arrancar Linux en
modo texto o en modo grfico. Si se ha seleccionado esta ltima opcin Linux
arrancar directamente X Window, en caso contrario en la lnea de comandos
hay que escribir startx con lo cual se arranca el modo grfico. Por defecto esto
arranca el entorno grfico GNOME.
6.1.9
KDE
Partes de la pantalla
KDE es uno de los entornos grficos ms populares de Linux puesto que une
una gran facilidad de uso a un entorno bonito y agradable. Al arrancar KDE
aparece el escritorio en el que se pueden encontrar elementos similares a los
de otros entornos.
Por defecto la pantalla de KDE se divide en tres partes fundamentales:
Panel de KDE .
Escritorio.
Panel de ventanas.
El panel de KDE contiene accesos directos a las aplicaciones ms empleadas
as como dos mens.
El equivalente al men Start de Windows, esto es el men a travs del cual
se pueden ejecutar las aplicaciones. Al seleccionar este elemento se despliega
un men subdivido en distintas categoras. KDE incluye una gran cantidad
de utilidades que se integran con el entorno.
Junto a ste aparece un segundo men del KDE, en el men de ventanas
se puede acceder a todas las ventanas que estn abiertas en los distintos escritorios. Al contrario que otros entornos grficos X Windows permite organizar
las ventanas en distintos escritorios virtuales. Justo encima del panel de KDE,
aparece el escritorio, al igual que en Windows este elemento contiene conos
que permiten acceder a los elementos ms comunes como las unidades de disco
o la papelera. Por ltimo en la parte superior del escritorio aparece otra barra,
en la que aparecern botones por cada ventana que se cree.
Las ventanas en el KDE tienen un aspecto similar al de las ventanas de
Windows (al menos con el aspecto bsico), pudiendo distinguir en ellas diversas
partes: en la parte superior izquierda, aparece el cono de la aplicacin, seleccionando el cual aparece un men con las opciones bsicas de manipulacin
de ventanas: minimizar, maximizar, cerrar, as como otras no tan habituales
como enviar la ventana a otros escritorio. Junto a l y en la parte superior
central de la ventana se encuentra la barra de ttulos de la ventana. Finalmente en la parte superior derecha aparecen tres botones con las opciones de
minimizar, maximizar y cerrar. Esta es la disposicin por defecto pero como se
ver ms adelante esta disposicin puede ser adaptada a los gustos del usuario
de una forma muy sencilla. Por debajo de este elemento se extiende la barra
de mens y de herramientas y el rea de trabajo de la aplicacin.
Al igual que en Windows, KDE permite cambiar el tamao de una ventana
sin ms que acercar el ratn a un borde de la misma. En esta posicin cambia el
cursor, indicando en qu direccin podemos modificar el tamao de la ventana
en esa posicin. Si se hace clic sobre el borde y se arrastra cambiar el tamao
de la ventana.
116
Administracin de Archivos. Kfm

Una de las operaciones ms importantes que se pueden realizar con un entorno grfico es la administracin de archivos. Esto incluye investigar el sistema
de archivos, buscarlos, abrirlos para ser editados etc. KDE incluye una herramienta, el kfm, que permite realizar todas estas operaciones de una forma
sencilla.
Al kfm se puede acceder de diversas formas, bien seleccionando un enlace
a un dispositivo del sistema en el escritorio, bien seleccionando el cono del
directorio personal en el panel o en el men de KDE : Home directory.
Navegar por la Estructura de Directorios y ver el Contenido de los
Ficheros
El kfm est diseado de tal forma que su uso y funcionamiento es muy similar
al de un navegador de Internet como Microsoft Internet Explorer o Netscape
Navigator, tanto es as, que este programa es capaz de abrir y mostrar ficheros
HTML y puede ser configurado para acceder a Internet.
Los botones que aparecen en la barra que se ilustra en la figura 6.1 de
la pgina 117 , comenzando de izquierda a derecha, realizan las siguientes
acciones:
Sube al directorio padre del actual.
Vuelve al directorio o pgina Web vista anteriormente a la actual.
Vuelve al directorio o pgina Web vista posteriormente a la actual.
El botn Home vuelve al directorio personal del usuario.
El botn Reload redibuja el contenido de la ventana.
El botn Copy se emplea para copiar ficheros y directorios.
El botn Paste pega el contenido anteriormente copiado.
El botn Help muestra la ayuda que contiene el sistema sobre kfm.
El semforo o botn Stop permite parar la descarga de ficheros de Internet.
Figura 6.1: Barra de Acceso a Internet.

Crear un Nuevo Directorio
Una vez en el directorio en el que se quiere crear un nuevo directorio o carpeta
se puede hacer clic con el botn derecho del ratn y en el men contextual que
surge seleccionar New/Folder o bien seleccionar el men File/New/Flder, tras
lo que kfm abre un cuadro de dilogo preguntando por el nombre del nuevo
directorio.
Borrar un Documento o Directorio

El proceso para borrar un directorio o documento es igual de sencillo que el
anterior. Para hacerlo no hay ms que seleccionar el directorio o documento
a borrar y realizar alguna de las siguientes posibilidades segn los gustos de
cada usuario:
Hacer clic con el botn derecho del ratn sobre el elemento a borrar y
en el men contextual seleccionar Move to Trash, para mover el fichero
a la papelera (de donde se puede recuperar) o Delete, lo cual elimina
permanentemente el fichero sin que se pueda recuperar.
Seleccionar el elemento y el men Edit/Move to Trash o presionar las
teclas <ctrl>+x o bien para eliminar el fichero permanentemente Edit/
Delete o las teclas <ctrl>+supr.
Nota: Linux no dispone de ningn mtodo que permita recuperar un fichero una vez eliminado.
KDE permite mover los ficheros a una papelera, esto es a un directorio
del que pueden ser eliminados de forma definitiva o recuperados, aunque la
funcionalidad de la misma es mucho menor que la de la papelera de Windows
o MacOs.
118
Copiar y Mover un Documento o Directorio

Este proceso es muy sencillo de realizar. Para copiar o mover un fichero o
directorio (incluyendo su contenido) no hay ms que tener dos ventanas con
los directorios de origen y destino (a estos efectos el escritorio se comporta
como una carpeta ms).
Para copiar o mover un fichero o directorio no hay ms que arrastrar los
elementos a la ventana de destino. Tras esto kfm mostrar un men contextual
que nos permite copiar el elemento (Copy), moverlo (Move) o crear un enlace
(Link ) con lo cual podemos asignar un nuevo nombre o alias al fichero.
Si en cualquiera de estos casos existe un conflicto, es decir existe un fichero
o carpeta con el nombre de los que estamos creando el sistema da la posibilidad
de sustituir el fichero o cambiar el nombre del nuevo fichero de forma que no
exista el conflicto.
Enlaces de KDE
Adems de los enlaces que admite el sistema de archivos de Linux, KDE incluye un tipo de enlace similar al que existe en Windows. Este tipo de enlace
se representa por un fichero con extensin .kdelnk que contiene informacin
diversa para el uso del sistema. Existen varios tipos de estos enlaces:
File System Device, es un enlace a un dispositivo del sistema. Este tipo
de enlaces permite acceder de forma directa por ejemplo a un disquete.
Cuando se selecciona New/File System Device en el men contextual
(botn derecho) o en el men File, se abre un primer cuadro de dilogo
en el que se pide el nombre del fichero. Para este ejemplo emplearemos disquete.kdelnk. En el segundo cuadro de dilogo, seleccionando la
pestaa Device se pueden indicar las propiedades del enlace como el dispositivo /dev/fd0 (el disquete) o los conos del dispositivo cuando est
montado y cuando no lo est. Tras esto, cuando se haga clic sobre el
enlace el sistema monta el sistema de archivos del disquete y muestra
su contenido. Para sacar el disquete de forma segura hay que seleccionar con el botn derecho el enlace y en el men contextual seleccionar
Umount con lo que se garantiza que ninguna aplicacin pueda acceder
al disquete y que no haya ninguna que est accediendo en ese momento.
Tras esto se puede retirar el disquete.
FTP Url, es un enlace a un fichero al que se puede acceder a travs

del protocolo FTP de Internet. El proceso de creacin es semejante al
anterior indicando el nombre del enlace en el primer cuadro de dilogo
y la direccin del enlace (del tipo ftp://servidor/fichero) en la pestaa
URL del segundo.
Mime Type, es un enlace que representa una asociacin entre un tipo de
fichero y las aplicaciones e conos que lo van a representar. Este proceso
permite asociar un tipo de fichero a un programa.
Application, es un enlace a un programa ejecutable. El proceso de creacin es: primero se indica el nombre del enlace, y luego en la pestaa
Execute se puede elegir la aplicacin a ejecutar mediante su comando y
su cono. Hay que resaltar que al contrario que en Windows las aplicaciones de Linux no contienen un cono por lo que se les debe asignar un
fichero externo.
Internet Addres y Worl Wide Web URL, similares al tipo FTP salvo
que apunta a pginas Web.
Asociar un Nuevo Tipo de Archivo
La asociacin de un fichero a otro es un proceso sencillo puesto que lo nico
que hay que hacer es crear un enlace como se ha visto anteriormente. El
primer paso consiste en seleccionar el men Edit/Mime Types, con lo cual kfm
abre un directorio en el que se aprecian distintas categoras de ficheros como
application, image, text, etc.
Para crear una asociacin en alguna de estas categoras mencionadas anteriormente (dependiendo del tipo de fichero), se debe crear un enlace de tipo
Mime Type, tras lo que el sistema solicitar que se defina un nombre para el
nuevo enlace. En el segundo dilogo se puede definir las propiedades del nuevo
tipo, como ejemplo se asociar un fichero de Microsoft Word (extensin .doc)
con StarOce.
Pattern, en la que podemos especificar las caractersticas del tipo de
ficheros, por ejemplo *.zip, *.htm, *.gif etc. En el caso del ejemplo se
emplear *.doc.
Mime Type, en el que se define el tipo de fichero por ejemplo text/Worddocument.
120
Comment, en el que se puede indicar un texto representativo del tipo de

fichero, por ejemplo Documento de Word.
Default application, permite la seleccin de la aplicacin que emplear
el sistema para abrir el fichero, en el caso del ejemplo soce.
Propiedades de un Fichero o Directorio

kfm permite configurar los directorios de forma que se puede seleccionar una
imagen de fondo y un cono distinto del que aparece por defecto. El proceso a
seguir para realizar estos cambios es muy sencillo. Para ello hay que seleccionar
y hacer clic con el botn derecho sobre la carpeta a modificar. En el men
contextual que surge a continuacin se selecciona la opcin Properties con
lo que se muestra un cuadro de dilogo con las propiedades de la carpeta:
haciendo clic en el botn de la carpeta se abre un cuadro de dilogo en el que
se permite la seleccin de cualquier imgen como cono. Si por el contrario
modificamos las propiedades del fondo se conseguir que cambie el fondo que
muestra kfm al abrir la carpeta.
Configura kfm como Navegador de Internet

Como se ha comentado al comienzo, kfm puede actuar como un navegador
de Internet pudiendo visualizar los ficheros HTML. De hecho, cuando kfm
encuentra un directorio en el que existe un fichero llamado index.html muestra
de forma automtica el contenido del mismo.
Adems de mostrar ficheros locales, kfm puede mostrar ficheros a travs
de Internet, para lo que tiene que ser configurado de una forma muy sencilla
y similar a la de otros navegadores como Netscape Navigator, para lo que se
accede a travs del men Options/Configure Browser. En el cuadro de dilogo
que se despliega se puede introducir el proxy que emplear kfm para acceder
a Internet.
Aplicaciones Auxiliares de KDE

KDE dispone de una cantidad enorme de aplicaciones auxiliares que permiten
realizar las operaciones ms habituales de una forma muy sencilla.
konsole
Linux es un sistema Unix y como tal pone a disposicin de los usuarios la
posibilidad de comunicarse con el sistema a travs de una lnea de comandos,
el shell. Desde KDE se puede acceder al shell o consola a travs del programa
konsole.
Este programa permite configurar el aspecto de la presentacin adaptndola a los gustos del usuario, cambiando el esquema de color, las fuentes, el
tamao por defecto de la aplicacin, a travs de las distintas opciones del men
Options.
Konsole se integra con el resto de las aplicaciones de KDE mejorando su
facilidad de uso. En concreto, se pueden arrastrar ficheros y carpetas desde una
ventana del administrador de archivos hasta la consola con lo que se permite
copiar el path del fichero o cambiar al directorio que contiene un determinado
fichero.
kedit
kedit es un programa muy sencillo e intuitivo para realizar la edicin de textos
sencillos. El manejo de kedit es similar al de programas como Notepad, al que
se accede a travs del men Application/Text Editor.
kedit admite las opciones tpicas de manejo de textos como son copiar un
texto (Edit/Copy), pegar un texto (Edit/Paste) y cortar un texto (Edit/Cut),
adems de otras ms sofisticadas como insertar un fichero (Edit/Insert File),
una fecha (Edit/Insert Date), buscar un texto en el documento (Edit/Find),
reemplazar texto (Edit/Replace) o comprobar la ortografa del documento
(Edit/Spelcheck) [?, IBM].
El programa es adems muy configurable, puesto que permite definir el
idioma del texto (Options/Spellchecker ) o la fuente con la que se va a mostrar
(Options/Font).
Adems de estas opciones Kedit es un programa que permite enviar el
texto va mail, editar un fichero a travs de un servidor ftp, etc.
122
kwrite
kwrite, al igual que kedit, es un programa especializado en la manipulacin

de ficheros de texto, pero a diferencia de ste est orientado al desarrollo de
programas por lo que ofrece la posibilidad de colorear la sintaxis de los mismos empleando distintos lenguajes de programacin: C, C++, Java, HTML,
Bash, Modula 2, Ada, Python o Perl. Con kedit comparte muchas opciones de
manipulacin de texto (copiar, pegar y cortar, as como buscar y reemplazar
texto).
kdehelp
Esta aplicacin es una de las ms interesantes del KDE puesto que representa
el sistema de ayuda del mismo. Este sistema de ayuda se basa en HTML por
lo que su uso es muy sencillo y similar al de un navegador de Internet. Todas
las aplicaciones del KDE acceden a este programa para mostrar la ayuda de
los mismos. La ventana de kdehelp se divide en cuatro partes fundamentales:
la barra de mens, la barra de herramientas, la barra de direcciones, y el
contenido propiamente dicho.
Como se ha comentado anteriormente, la ayuda de KDE se basa en HTML,
por lo que est llena de vnculos que llevan de un contenido a otro. Para navegar por los documentos existen las opciones tpicas de todos los navegadores
y que encontramos tambin en kfm, esto es los botones y mens para ir a la
pgina que ha sido visitada anteriormente o con posterioridad, se pueden crear
marcadores, etc.
Una de las opciones ms interesantes de kdehelp es que permite el acceso a
las pginas del manual man de Linux, simplemente escribiendo man:<coman
do> donde comando es alguno de los comandos de Linux, podemos acceder
a la ayuda de ese comando, como ejemplo se puede probar man: ls. Dentro
de los comandos tambin se incluyen las funciones de la librera estndar de
C por lo que man: sin o man: printf mostrarn la informacin que contiene
el sistema respecto de esas funciones.
Kfind
Esta herramienta es auxiliar a kfm puesto que permite buscar un determinado
archivo en un directorio concreto. La bsqueda, al igual que en Windows, se
puede realizar siguiendo tres criterios diferentes:
Por nombre u localizacin, se conoce el nombre o parte de l y la localizacin aproximada del fichero.
Se puede centrar an ms la bsqueda si se conoce el momento en el
que se realiz la ltima modificacin. La pestaa Date Modified permite
que el usuario identifique un perodo de tiempo en el que concretar la
bsqueda.
Por ltimo se puede especificar en Advanced que la bsqueda se limite a
un determinado tipo de fichero, que el fichero contenga un determinado
texto, o que su tamao sea uno determinado.
Una vez determinados los criterios de seleccin de los ficheros se puede
indicar al programa que busque seleccionando el primer botn de la barra
de herramientas por la izquierda, o el men File/Start Search., con lo que el
programa comenzar a buscar.
La barra de herramientas de esta aplicacin contiene las siguientes funciones empezando por la izquierda, la misma se puede observar en la figura 6.2
de la pgina 124:
1. Botn para iniciar una bsqueda.
2. Botn para crear una nueva bsqueda.
3. Botn para detener bsqueda (desactivado en la imgen).
4. Botn para abrir fichero.
5. Botn para aadir a un archivo en el que se pueden agrupar varios ficheros.
6. Botn para eliminar fichero.
7. Botn de propiedades.
124
Figura 6.2: Barra de Herramientas de Kfind.

8. Botn para abrir el directorio que contiene el fichero.
9. Botn salvar resultados.
10. Botn de guardar resultados.
11. Salir.
Configuracin de KDE
Como cualquier aplicacin de Linux, KDE es altamente configurable, lo que
supone que cada usuario puede adaptar el aspecto y comportamiento de KDE
a su gusto personal. No obstante, al contrario que otras muchas aplicaciones para Linux, para configurar KDE no es necesario editar los ficheros de
configuracin a mano sino que existen una serie de herramientas grficas que
permiten estos cambios de una forma sencilla y segura.
Editor de Mens
Uno de los aspectos ms sencillos de cambiar es el men de aplicaciones del
sistema, al que se pueden aadir las aplicaciones de uso ms comn. Existe
con este fin una utilidad llamada editor de mens accesible desde el men
Utilities/Men Editor.
En realidad, el men de KDE est compuesto por dos partes principales.
Una de ellas constituye el men personal del usuario en el que puede aadir
o quitar aplicaciones. La segunda de las partes es comn a todos los usuarios
de KDE y por lo tanto slo puede ser modificada por el administrador del
sistema.
En cualquiera de los casos el proceso para crear una nueva entrada en el

men es muy sencillo. Se pulsa con el botn derecho del ratn sobre el men (o
submen) que se vaya a modificar, con lo que se despliega un men contextual
con diversas opciones:
Change, permite editar las propiedades de la entrada del men sobre la
que se haya hecho la seleccin, editando su nombre, la aplicacin que
arranca, el cono, etc.
Select item for moving, permite cambiar la posicin del un elemento del
men, para lo cual hay que hacer clic en el men y arrastrar el elemento
a su nueva posicin.
Select men for moving, igual que el anterior pero con mens completos.
New, se crea un nuevo elemento del men.
Cut, se corta un elemento del men.
Copy, se copia un elemento del men.
Paste, se pega un elemento previamente cortado o copiado.
Delete, se elimina el elemento del men seleccionado.
Tanto si se modifican las propiedades de una entrada del men existente o
se crea un nuevo elemento, el programa presenta el siguiente cuadro de dilogo:
Type, tipo del elemento creado puede ser Separator (un separador de
distintos elementos), Submenu (un submen), Application (una aplicacin), Swallow, Link (un enlace) o Device (un dispositivo), dependiendo
del tipo que se escoja la parte inferior del cuadro de dilogo cambiar
permitiendo configurar cada uno de los tipos.
File Name, el nombre del fichero en el que se va a guardar la informacin
del men (este fichero es un enlace de KDE).
Name, el nombre que aparecer en el men una vez creado el mismo.
Icon, el nombre de la imagen que aparecer en el men. Para seleccionar
una imagen se puede clicar en el botn que muestra la imagen, lo que
abrir un cuadro de dilogo en el que se puede seleccionar la imagen
deseada.
126
Mini Icon, la imgen que aparecer cuando sea necesario mostrar un

cono pequeo. Si se deja esta opcin en blanco KDE mostrar una
versin reducida de la imgen que aparezca en Icon.
Comment, un comentario que pueda ayudar a determinar qu hace esa
entrada del men.
Si lo que se est creando es un enlace a una aplicacin en la pestaa

Execute y la opcin Execute hay que escribir la lnea de comandos necesaria
para ejecutar el programa.
KDE Control Center

Esta aplicacin es la principal encargada de configurar KDE y a ella se puede
acceder de muchas formas, tanto desde el cono que aparece en el panel, como
desde cualquiera de las entradas al men Settings, en cuyo caso slo se accede
a una de las posibles opciones de configuracin. Cuando se arranca la figura
aparece una ventana dividida en dos: en la parte de la izquierda aparecen
ordenadas las diferentes categoras de configuracin (que coinciden con las categoras del men Settings), mientras que en la derecha se abrirn los distintos
cuadros de dilogo que permiten configurar KDE.
Aadir Aplicaciones al Panel

Otra de las tareas que facilita el uso de KDE es la posibilidad de aadir una
aplicacin al panel de forma que sea fcilmente accesible. El proceso a seguir es
simplemente elegir un elemento del men a travs de Panel/Add Application,
con lo que se despliega un men idntico al de KDE con las aplicaciones.
Seleccionando una cualquiera de ellas sta se aadir de forma automtica al
panel.
Para eliminarla o moverla no hay ms que hacer clic con el botn derecho
del ratn sobre el elemento a modificar y seleccionar la opcin pertinente en
el men contextual.
Otras Aplicaciones de KDE

Por ltimo se mencionarn algunas de las aplicaciones que estn disponibles
en KDE, de las que no se va a explicar su funcionamiento:
Korganizer (Applications/Organizer), es un programa que permite gestionar la agenda del usuario de una forma sencilla e incluso la
sincronizacin de datos con agendas personales como PalmPilot.
Icon Editor (Graphics/Icon Editor), es un programa de dibujo que
permite crear conos para personalizar los mens y enlaces de KDE.
Kview (Graphics/Image Viewer), es un programa que permite mostrar imgenes de todos los formatos de archivo importantes as como
realizar operaciones sencillas con ellas.
Paint (Graphics/Paint), este es un programa de dibujo bsico que
permite crear imgenes sencillas.
PS Viewer (Graphics/PS Viewer), este programa permite visualizar
ficheros con imgenes PostScript y documentos de Adobe Acrobat (.pdf).
SnapShot (Graphics/Snapshot), programa que permite la captura
de una ventana y su contenido.
El men Internet comprende una gran cantidad de programas que se
relacionan con Internet.
El men Multimedia, dispone de programas para el visualizado y
audicin de distintos ficheros multimedia, como pueden ser videos (AVI,
Quicktime, MPEG) con aKtion!, o escuchar msica.
Desktop Switching Tool (System/Desktop Switching Tool) es
una aplicacin muy til puesto que permite seleccionar cual va a ser
el entorno por defecto que arranque Linux, permite seleccionar entre
GNOME, KDE y AfterStep.
Archiver (Utilities/Archiver), es una aplicacin que permite el manejo de ficheros tar y zip de una forma sencilla.
Knotes (Utilities/Knotes), permite crear notas en el ordenador a las
que luego se puede acceder a travs del cono que se aade al panel.
128
6.2
6.2.1
Ejecucin de Programas
Ejecucin en el Fondo & , kill, nice y nohup
Para ejecutar un programa en el fondo, es decir, recuperando inmediatamente

el control del terminal, basta aadir el carcter & al final del comando de
ejecucin:
program <datos.d >resultados.r & inmediatamente aparecer en el terminal, debajo de esta lnea, un nmero que es el nmero de proceso de la
ejecucin de este programa.
Para detener definitivamente dicha ejecucin (no se puede detener temporalmente) se puede utilizar el comando kill.
La ejecucin de un programa en el fondo no impide que aparezcan en la
pantalla los mensajes de error que se produzcan (a no ser que se haya redirigido
la salida de errores), y que el programa se pare cuando se salga del sistema.
Para que el programa contine ejecutndose an cuando nosotros hayamos
terminado la sesin, hay que utilizar el comando nohup.
Si no se utilizan redirecciones todas las salidas del programa se dirigen a
un fichero llamado nohup.out. Cuando se utiliza nohup el ordenador entiende
que el usuario no tiene prisa y automticamente disminuye la prioridad de la
ejecucin.
Existe un comando, llamado nice, que permite realizar ejecuciones con baja
prioridad, es decir se le indica al ordenador que puede ejecutar de forma ms
lenta esta aplicacin si existen otras que sean ms urgentes.
6.2.2
Comando time
El comando time, precediendo a cualquier otro comando, suministra informacin acerca del tiempo total empleado en la ejecucin, del tiempo de CPU
utilizado por el programa del usuario, y del tiempo de CPU consumido en
utilizar recursos del sistema.
6.2. EJECUCIN DE PROGRAMAS
6.2.3
129
Comando top
Linux incluye una aplicacin llamada top cuya finalidad es manipular la ejecucin de programas de una forma interactiva. Esta aplicacin muestra una
lista de los procesos que se estn ejecutando.
6.2.4
Programas de Comandos
El sistema operativo Linux, al igual que otros sistemas operativos, permite

realizar programas de comandos, esto es, programas constituidos por distintos
comandos que podran teclearse interactivamente uno por uno en una terminal,
pero que es muchas veces ms cmodo agruparlos en un fichero, y ejecutarlos
con una sola instruccin posteriormente.
Cuando se ejecuta un fichero de comandos Linux abre lo que se llama un
nuevo shell, es decir un nuevo entorno para la ejecucin de los comandos. Para
que las variables del caparazn (shell) original conserven su valor en el nuevo
caparazn es necesario prepararlas con la sentencia export antes de abrir el
nuevo shell. Por ejemplo, como consecuencia de lo que se acaba de decir, si en
el interior de un fichero de comandos se cambia de directorio con el comando
cd, al acabar la ejecucin de dicho fichero volveremos automticamente al
directorio inicial.
Introduccin
Para introducir lneas de comentarios en un programa de comandos basta
comenzar dichas lneas con el caracter #. Hay que tomar la precaucin de
que este caracter no sea el primer caracter del fichero de comandos, porque
entonces el ordenador interpreta que el programa est escrito en Cshell (una
variante especial de UNIX desarrollada en la Universidad de Berkeley) y el
resultado es imprevisible. Puede ser buena prctica comenzar todos los ficheros
de comandos con una lnea en blanco.
Variables del Shell

Es una prctica habitual el utilizar nombres con letras maysculas para las
variables del caparazn.
130
El shell del Linux tiene definidas para cada usuario unas variables estndar.
Para averiguar cules son basta teclear el comando siguiente, set. Para definir
otras variables propias de cada usuario puede utilizarse el fichero .profile, que es
un fichero de comandos propio de cada usuario que se ejecuta automticamente
al hacer el login.
El comando echo imprime un determinado texto en la terminal. Un ejemplo de utilizacin de dicho comando puede ser el siguiente: echo Me gusta el
sistema operativo UNIX .
El comando echo es de gran utilidad en los ficheros de comandos. Cuando
el texto que se desea escribir en la terminal contiene alguno de los caracteres
especiales de UNIX ( * ? [ ] > >> < & ; \ ) hay que tomar precauciones
especiales desconectando su significado. Una forma de hacerlo es precediendo
dicho carcter con la barra invertida (\).
Si no se utilizara la barra invertida, el asterisco se interpretara como un
carcter de sustitucin y se imprimira el nombre de todos los ficheros del
directorio.
Otra forma de anular el significado de los caracteres especiales es encerrando el texto a escribir mediante comillas () o entre apstrofos normales ().
Los apstrofos () anulan el significado de todos los caracteres comprendidos
entre ellos. As pues, el triple asterisco lo podramos escribir con el comando,
echo ***.
Las comillas () son menos restrictivas, y anulan el significado de todos los
caracteres excepto los tres siguientes: ( \). Esto es muy importante porque si
VAR es el nombre de una variable, y VAR aparece en un comando echo entre
apstrofos se escribe VAR, mientras que si aparece entre comillas se escribe el
valor de la variable, al cumplir el carcter su cometido.
El carcter (\) tiene otros significados, adems del ya visto de anular el
significado especial de otros caracteres. As, sirve como indicador de que un
comando contina en la lnea siguiente. Cuando se utiliza en la definicin
interactiva de un comando, en la lnea siguiente aparece el prompt secundario
(>), que indica que se debe seguir tecleando el comando. Cuando en un
comando echo aparecen los caracteres (\c) y (\n) quiere decir, respectivamente,
que no se cambie de lnea y que se salte de lnea, al escribir por la pantalla.
Cuando en un comando echo aparece el nombre de otro comando encerrado entre apstrofos inversos (por ejemplo, date, who, ls, ...), el nombre de
131
dicho comando se sustituye por el resultado que genera al ejecutarse interactivamente.
Otras Posibilidades de los Ficheros de Comandos

Los ficheros de comandos tienen muchas ms posibilidades que las que se
han apuntado en esta Introduccin: pueden leer variables, preguntar por la
existencia de un fichero y por si es ejecutable o no, y admiten construcciones
lgicas del tipo IF, DO, DO WHILE, etc.
6.2.5
Comandos tiles para Trabajar en Red
Protocolos Internet (IP)

Cualquier comunicacin entre dos sistemas distantes debe resolver los dos problemas siguientes:
designacin de cada sistema (addressing), y
seleccin del camino a seguir por la comunicacin (routing).
El protocolo IP define una direccin lgica para cada red local. La direccin de una mquina concreta se forma aadiendo a la direccin de la red el
nmero que identifica a la mquina en esa red. La direccin completa tiene 32
bits, y se suele dar en la forma de 4 octetos separados por puntos (por ejemplo:
132.227.70.83). El nmero de octetos que designa a la red (izquierda) y a la
mquina (derecha) es variable, dependiendo del tamao de la red.
El camino de los mensajes (routing) se establece a travs de ciertos ordenadores, llamados pasarelas, que tienen la propiedad de pertenecer al menos
a dos redes. Existen tablas que indican cul es la pasarela de la red local a
travs de la cual se puede acceder a otras redes.
Los mensajes enviados tienen un encabezamiento con las direcciones de los
ordenadores desde y hacia. Como los mensajes se suelen enviar fragmentados por problemas de tamao, el encabezamiento lleva tambin la informacin necesaria para reconstruir el mensaje al llegar a su destino.
132
Las caractersticas principales de este nivel de comunicacin entre ordenadores son:

la conexin no es interactiva (se enva el mensaje y no se hace nada ms),
y
no se garantiza ni la llegada, ni el orden de llegada, ni la no duplicacin
de los mensajes.
Comando telnet
Permite abrir una terminal virtual en un sistema distante. Este comando no
requiere que los sistemas sean UNIX. Si el sistema tiene varias puertas, hay
que especificar por cul se desea hacer la conexin. Para salir de telnet se
emplea el comando quit (o simplemente q).
Comando ftp
Permite la transferencia de ficheros entre sistemas distantes. Supone una
conexin entre el sistema local y el sistema distante.
Los comandos de ftp que afectan a la transmisin son los siguientes:
ascii: (binary) transmisin en formato ASCII (por defecto) o binario.
quit: fin de la conexin y de ftp.
close: fin de la conexin, sin salir de ftp.
glob: activacin del mecanismo de expansin de ficheros.
open [dir_host]: abrir conexin con el sistema dir_host.
prompt: cambia de interactivo a no interactivo, y viceversa.
user username: identificacin en mquina distante.
status: informacin sobre el proceso ftp.
verbose: activacin de la opcin verbose.
6.2.6
133
Instalacin de Linux
Arranque de Linux
El primer paso es iniciar el computador con el dispositivo de arranque de
Linux, que suele ser un disco boot que contiene un pequeo sistema Linux.
Tras arrancar con el floppy, se presentar un men de instalacin de algn tipo
que guiar en el proceso de instalacin. En otras distribuciones, se mostrar
un prompt de login cuando se arranque. Aqu se suele entrar como root o
install para comenzar el proceso de instalacin. La documentacin que viene
con cada distribucin particular explica qu se necesita para arrancar Linux.
La mayora de las distribuciones de Linux utilizan un disquete o CD de
arranque que permite introducir parmetros de el hardware en tiempo de
arranque, para forzar la deteccin de los dispositivos.
El prompt de arranque se muestra siempre que se arranca con el disquete.
Para arrancar sin ms parmetros especiales, se pulsa enter en el prompt del
arranque.
Dispositivos y Particiones en Linux

Muchas distribuciones necesitan que se creen a mano las particiones de Linux
utilizando el programa fdisk. Otras pueden crearlas automticamente. En
cualquier caso, se debe conocer acerca de los nombres para los dispositivos y
las particiones en Linux.
Bajo Linux, los dispositivos y las particiones tienen nombres muy distintos
a los utilizados en otros sistemas operativos. Bajo MS-DOS, las disqueteras
se identifican como A: y B:, mientras que las particiones del disco duro se
identifican como C:, D, etc. Bajo Linux, la denominacin es algo diferente.
Los manejadores de dispositivos, que se encuentran en el directorio /dev,
se usan para comunicar con los dispositivos del sistema (como discos duros o
ratones). Por ejemplo, si se tiene un ratn en el sistema, se lo puede acceder a
travs del manejador /dev/mouse. Las disqueteras, discos duros y particiones
tienen cada uno un manejador propio. No es necesario preocuparse acerca de
la interfaz del manejador por ahora; solo es importante entender cmo son
nombrados los dispositivos con el fin de poderlos usar.
134
Creacin de las Particiones en Linux

Ahora ya se est preparado para crear las particiones de Linux con el comando
fdisk. Despus de arrancar el disquete, se ejecuta el comando fdisk tecleando
fdisk <drive> donde <drive> es el nombre de dispositivo con el que Linux
identifica el disco duro donde se quiere realizar las particiones. Por ejemplo,
si se desea ejecutar fdisk sobre el primer disco SCSI del sistema, se utiliza el
comando fdisk /dev/sda. Por defecto, fdisk acta sobre /dev/hda (el primer
disco IDE ).
Para crear particiones de Linux en ms de un disco, se ejecuta fdisk una
vez por disco.
El comando n se usa para crear una nueva particin. Casi todas las dems
opciones no deben preocupar ahora mismo. Para salir de fdisk sin salvar
cambios, se utiliza el comando q. Para salir escribiendo los cambios en la
tabla de particiones, se utiliza el comando w.
Lo primero que se debe hacer es mostrar la tabla de particiones actual y
anotar sus datos, para referencias posteriores. Se usa el comando p para esto.
Para crear una nueva particin, se utiliza el comando n.
Creacin del Espacio de Intercambio (swap)

Muchas distribuciones necesitan que se cree y active la particin de intercambio
antes de instalar el software. Si se tiene poca RAM fsica, la instalacin puede
no ir bien, a menos que se active una cierta cantidad de swap.
La distribucin Slackware necesita que se cree el rea de swap antes de la
instalacin, si se tienen 4 megabytes o menos. Si este no es el caso, el procedimiento de instalacin de Slackware puede usarse para preparar la particin
de intercambio automticamente. Si no se est seguro, se debe seguir con el
procedimiento descripto aqu.
De nuevo, algunas distribuciones de Linux preparan el rea de intercambio
automticamente, o bien mediante un men de instalacin.
Si se usan varias particiones de intercambio, se necesitar ejecutar el comando mkswap apropiado para cada particin.
Despus de preparar el rea de swap, hay que decirle al sistema que la
135
use. Normalmente, el sistema comienza a usarla automticamente durante el

arranque. Sin embargo, como an no tiene instalado el software de Linux, se
tiene que activarla a mano.
Creacin de los Sistemas de Ficheros

Antes de que se puedan usar las particiones de Linux para almacenar ficheros,
hay que crear los sistemas de ficheros en ellas. La creacin de un sistema de
ficheros es anloga a formatear una particin de MS-DOS u otros sistemas
operativos. Hay varios tipos de sistemas de ficheros disponibles en Linux.
Cada tipo de sistema de ficheros tiene su propio formato y caractersticas
(como longitud del nombre de los ficheros, tamao mximo, etc). Adems,
Linux soporta sistemas de ficheros de terceros como el de MS-DOS.
Instalacin del Software

Finalmente, ya se est preparado para instalar el software en el sistema. Cada
distribucin tiene una forma distinta de hacerlo. Muchas tienen un programa
que gua paso a paso en este proceso. En otras, se tendr que montar los
sistemas de ficheros en un directorio (como /tmp) y copiar el software a ste
a mano.
En las distribuciones en CD-ROM se puede seguir la opcin de instalar
una parte de lo que contiene en el disco duro y dejar el resto (la mayor parte)
en el CD-ROM.
Algunas distribuciones ofrecen diversos mecanismos para instalar el software. Por ejemplo, se puede instalarlo directamente desde una particin MSDOS del disco duro, en lugar de hacerlo desde los disquetes. O incluso puede
hacerlo a travs de una red TCP/IP mediante FTP o NFS.
Por ejemplo, la distribucin Slackware slo necesita que se creen las particiones con fdisk, y el espacio de intercambio con mkswap y swapon (si tiene
4 megabytes o menos de RAM ), y a continuacin que se ejecute el programa
setup, que gua mediante un men bastante autoexplicativo en la instalacin
del software. La utilizacin de setup se describe en detalle luego.
El mtodo exacto para instalar el software de Linux difiere en gran parte
segn la distribucin.
136
Creacin del Disco de Arranque o Instalacin del LILO
Cada distribucin proporciona mecanismos para arrancar Linux cuando ya

est instalado en el sistema. En la mayora de los casos se crear un disquete
boot que contiene el ncleo de Linux configurado para usar con el recin
creado sistema de ficheros raz.
Para arrancar Linux, se deber hacerlo desde ese disquete y tras el arranque
se pasar el control al disco duro. En otras distribuciones, el disco de arranque
es el propio disquete de instalacin.
La mayora de las distribuciones dan la opcin de instalar LILO en el disco
duro. LILO es un programa que se instala en el registro maestro de arranque
del disco, y est preparado para arrancar varios sistemas operativos, entre los
que se incluyen MS-DOS y Linux, permitindole al usuario elegir qu sistema
quiere arrancar en cada momento.
En el caso de la distribucin Slackware, la opcin Configure del men setup
permitir tanto crear un disquete de arranque como instalar LILO.
Con el fin de instalar LILO correctamente, se necesita conocer bastante
informacin acerca de la configuracin del disco, por ejemplo, qu particiones
contiene cierto sistema operativo, cmo arrancar cada sistema operativo, etc.
La mayora de las distribuciones, cuando se instala LILO, tratan de elegir
la mejor configuracin para ste. Aunque no es lo habitual, la instalacin
automatizada de LILO puede fallar, dejando el registro de arranque maestro
del disco inservible (aunque es difcil que sto llegue a hacer perder datos del
disco).
En concreto, si se utiliza el Boot Manager de OS/2, no se deber instalar LILO mediante el procedimiento automtico, para ello, habr que seguir
instrucciones especiales.
En muchos casos, lo mejor es usar un disquete de arranque, hasta que se
est en condiciones de configurar LILO a mano. Si el usuario es excepcionalmente confiado, puede seguir adelante con el procedimiento automtico para
instalar LILO si ste forma parte de la distribucin.
137
Otros Procedimientos de Instalacin

Algunas distribuciones proporcionan procedimientos de instalacin adicionales, permitiendo configurar diversos mdulos como el de red TCP/IP, el sistema X Window, y otros.
Procedimientos Post-Instalacin
Despus de haber completado la instalacin de Linux, se debera hacer poco
antes de que se pueda comenzar a usar el sistema. En la mayora de los casos,
se debera poder arrancar el sistema, entrar como root, y comenzar a explorar
el sistema.
Llegado este punto es una buena idea explicar cmo rearrancar y apagar el
sistema cuando se lo est usando. No se debera nunca rearrancar o apagar el
sistema Linux presionando el interruptor de reset o con el viejo Vulcan Never
Pinch (o sea, pulsando a la vez ctrl-alt-del). Por supuesto, tampoco
se debera desconectar la corriente. Como en la mayora de sistemas UNIX,
Linux lleva una cache de disco en memoria, lo que aplaza la escritura de los
datos. Es por ello que si se rearranca el sistema sin apagarlo limpiamente,
se puede corromper datos en las unidades, causando un dao impredecible.
La forma ms fcil de apagar el sistema es usar el comando shutdown.
Como ejemplo, para apagar y rearrancar el sistema de forma inmediata, se
usa el siguiente comando como root: # shutdown -r now. Esto apagar
limpiamente el sistema.
Se debe observar, sin embargo, que muchas distribuciones no proporcionan el comando shutdown en el software de instalacin. Esto significa que la
primera vez que se rearranque el sistema despus de la instalacin, se tendr
que hacer uso de la combinacin de teclas ctrl-alt-del. Despus de esto, se
deber usar siempre el comando shutdown.
Despus de que se haya tenido la oportunidad de explorar y usar el sistema,
hay varias opciones de configuracin que se debera revisar. La primera es
crear una cuenta de usuario para el usuario mismo (y, opcionalmente, para el
resto de usuarios que podran tener acceso al sistema). Todo lo que se tiene
que hacer es entrar como root, y ejecutar el programa adduser (algunas veces
useradd); ste ayudar por medio de varias preguntas a crear una nueva cuenta
de usuario.
138
Si se cre ms de un sistema de archivos para Linux, o si se est usando

una particin de swap, se puede tener que editar el fichero /etc/fstab de forma
que esos sistemas de archivo puedan estar disponibles despus de rearrancar.
Resolviendo Problemas
Casi todo el mundo se encuentra con algn tipo de problema o cuelgue cuando
intenta instalar Linux por primera vez. La mayora de las veces el problema
se debe a una simple confusin. Otras veces, sin embargo, puede ser algo ms
serio, como una equivocacin de uno de los desarrolladores, o un error del
programa.
Problemas con el Arranque

Cuando se intenta arrancar con el floppy de arranque la primera vez, se pueden
encontrar algunos problemas. Se debe observar que los siguientes no estn
relacionados con el arranque del Linux una vez instalado.
Se produce un error en el floppy u otro dispositivo durante el arranque.
El motivo ms frecuente de esta clase de problemas es que el disquete est
corrompido. Puede ser que el disquete est fsicamente daado, en cuyo caso
se tendr que volverlo a preparar sobre un nuevo disquete, o bien que los datos
fueran mal copiados al mismo, en cuyo caso debe verificarse si se consigui la
imgen del disquete de arranque correctamente. En muchos casos, basta con
volver a grabar la imgen sobre el floppy: se repiten todos los pasos y se intenta
de nuevo.
El sistema se cuelga durante el arranque o despus. Despus de que el
disquete arranque, se debe ver una serie de mensajes del ncleo, indicando
qu dispositivos se estn detectando y configurando. Despus de esto, normalmente se ver un prompt de login, que permite iniciar la instalacin (en
otras distribuciones se entra directamente en un programa de instalacin). El
sistema puede parecer colgado durante cualquiera de esos pasos. Se debe
ser paciente, la carga del disquete es lenta. Muchas veces el sistema no se
ha bloqueado, simplemente necesita tiempo. Se debe verificar que no se usa
ningn dispositivo del sistema durante algunos minutos antes de estar seguros
de que se ha bloqueado la mquina.
Despus del prompt de LILO, el sistema debe cargar el ncleo desde el
139
floppy. Esto puede llevar varios segundos; y puede verse que est sucediendo
pues la luz del floppy permanecer encendida.
Mientras el ncleo arranca, se probarn los dispositivos SCSI. Si el sistema
tiene SCSI, el sistema se bloquear durante unos 15 segundos mientras se
prueban esos dispositivos.
Una vez que el ncleo ha terminado de arrancar, se transfiere el control a
los ficheros de arranque que hay en el disquete.
Finalmente, se ver un prompt de entrada en el sistema, o bien se entrar
en un programa de instalacin.
Cualquier cosa de las comentadas ms arriba puede ser la causa del problema. Sin embargo, es posible que si el sistema se cuelgue realmente durante el
arranque, y eso puede deberse a varias cosas. En primer lugar, puede suceder
que no tenga suficiente RAM para arrancar.
La causa de la mayora de los cuelgues son las incompatibilidades del
hardware. Puede suceder que en lugar de un mensaje de error por falta de
memoria, el sistema se bloquee durante el arranque. Si esto sucede, y no sirve
ninguna recomendacin de las vistas en la seccin anterior, se debe probar
desactivando el disco RAM. Se debe tener en cuenta que Linux requiere por s
mismo un mnimo de 2 megabytes de RAM; y algunas distribuciones necesitan
4 o ms.
El sistema muestra un error como permission denied o file not found
durante el arranque. Esto es seal de que el disquete de instalacin est mal.
Si se intenta arrancar con el disquete, y ste es correcto, no deberan salir
errores de este tipo. Si se cre independientemente el disco de arranque, se
debe probar de rehacerlo para ver si esto soluciona el problema.
El sistema informa del error VFS: Unable to mount root cuando se est
arrancando. Este error indica que el sistema de ficheros raz (que se debe
encontrar en el disquete de arranque), no est. Puede ser que el disquete est
mal o que no est arrancando el sistema de forma correcta.
Si se est seguro que se ha seguido correctamente el procedimiento de
arranque, puede ser que el disquete est corrupto. Es poco corriente, por lo
que deben buscarse otras soluciones antes que intentar usar otro disquete o
cinta.
140
Problemas con el Hardware

El problema ms habitual que surge cuando se arranca Linux es la incompatibilidad con el hardware.
Aunque todo su hardware est soportado en Linux, algn conflicto de las
configuraciones puede causar extraos resultados, los dispositivos pueden no
detectarse durante el arranque, o el sistema puede bloquearse.
Es importante aislar esos problemas si se sospecha que puede ser el origen
del mal funcionamiento.
Problemas con la Instalacin del Software

Con un poco de suerte, se puede instalar el software de Linux sin problemas.
Los nicos que suelen aparecer se relacionan con los errores en los disquetes de instalacin o con el espacio disponible en los sistemas de ficheros. A
continuacin se relaciona una lista de estos problemas.
El sistema muestra errores como Read error, file not found durante
la instalacin del software. Esto es indicativo de problemas en los disquetes
o cintas de instalacin. Si se instala desde disquetes, se debe tener en cuenta
que los errores en stos son posibles. Es necesario asegurarse de que se estn utilizando disquetes nuevos o recin formateados. Muchas distribuciones
permiten instalar el software desde una particin DOS del disco duro. Esto
puede ser ms seguro y ms rpido que usar directamente los disquetes.
Si se utiliza un CD-ROM, hay que asegurarse de que el disco no tiene
rayaduras o suciedad que pudieran ser causa de errores de lectura.
La causa del problema puede estar tambin en un formato incorrecto de
los disquetes. Normalmente se exige que los disquetes estn en formato MSDOS de alta densidad (a excepcin del disquete de arranque, que suele tener
su propio formato casi siempre). Si todo esto falla, se debe intentar obtener
nuevos disquetes, bien sea pidindolos al distribuidor o construyndolos el
mismo usuario.
El sistema da errores tipo tar: read error o gzip: not in gzip format.
Este problema suele deberse a errores en los ficheros o en los propios discos
o cintas. En otras palabras, los disquetes pueden no tener errores, pero s los
datos contenidos en ellos. Por ejemplo, un error comn es obtener los ficheros
141
por las redes con modo de transferencia ASCII en lugar de binario, lo que
hace inservibles los ficheros obtenidos.
El sistema da errores como device full durante la instalacin. Esto es
un signo claro de que se est intentando instalar Linux sin espacio de disco
suficiente.
La solucin habitual es rehacer los sistemas de ficheros (mediante el comando mke2fs) lo que borrar el software parcialmente instalado. Ahora se puede
reintentar la instalacin, seleccionando menos componentes para instalar. En
otros casos, se puede necesitarse comenzar desde cero, rehaciendo particiones
y sistemas de ficheros.
El sistema informa de errores como read_intr: 0x10 durante los accesos
al disco duro. Esto suele deberse a la presencia de bloques con errores en el
disco. Sin embargo, si se reciben estos errores al utilizar mkswap o mke2fs, el
sistema puede estar teniendo problemas para acceder a su controlador. Puede
ser tanto un problema del hardware como una incorrecta especificacin de la
geometra del disco. Si utiliz la opcin hd=<cylinders>,<heads>,<sectors>
en el momento de arrancar para especificar la geometra de su disco, y lo
hizo incorrectamente, puede encontrarse con estos problemas. Tambin puede
suceder si la informacin de la CMOS acerca de la geometra del disco no es
correcta.
El sistema da errores como file not found o permission denied. Este
problema puede suceder si no estn disponibles todos los ficheros necesarios
en los disquetes de instalacin (vea el prrafo siguiente) o si hay problemas
con los permisos sobre dichos ficheros. Por ejemplo, en algunas distribuciones
de Linux existen bugs rpidamente solucionados en posteriores versiones, relacionados con los permisos. Son errores poco frecuentes. Si se sospecha que la
distribucin tiene bugs, y se est seguro de no haber hecho nada mal, se debe
contactar con el fabricante de la distribucin para informarle del bug.
Si se tiene otros extraos problemas durante la instalacin de Linux (especialmente si el software se ha obtenido va red o mdem), hay que asegurarse
de haber obtenido todos los ficheros necesarios. Por ejemplo, hay usuarios que
utilizan el comando de FTP mget *.* cuando obtienen el software va FTP.
En realidad, este comando slo obtiene todos los ficheros que contengan un
. en el nombre, y no todos lo tienen. El comando correcto a utilizar ser
mget * en vez del anterior.
142
Problemas Despus de Instalar Linux

El usuario se ha pasado una tarde instalando Linux. Despus arranc el sistema, y no pas nada. O, por el contrario, s pas algo, pero no lo que debera
pasar. Qu hace el usuario ahora?.
Problemas al Arrancar Linux desde el Floppy

Si se utiliza un disquete para arrancar Linux, puede ser que se necesite indicar
cul es la particin raz de Linux en el momento de arrancar. Esto es especialmente cierto si se utiliza el disquete de instalacin original, y no un disquete
personalizado durante la instalacin.
Problemas al Arrancar Linux desde el Disco Duro

Si se opt por instalar LILO, en lugar de crear un disquete de arranque, debe
poderse arrancar Linux desde el disco duro. Sin embargo, el procedimiento
automtico de instalacin de LILO que muchas distribuciones tienen no siempre es perfecto. Puede tener informacin incorrecta acerca del esquema de
particiones, en cuyo caso puede que se tenga que reinstalar LILO para dejarlo
todo correcto.
El sistema da el mensaje Drive not bootablePlease insert system disk.
Se obtiene este error cuando el registro maestro de arranque del disco duro
(MBR) est mal por alguna causa. Normalmente, el resto de la informacin
del disco estar intacta.
Puede entonces suceder:
1. Mientras se hacen las particiones mediante fdisk, puede haberse borrado

la particin marcada como activa. MS-DOS y otros sistemas operativos intentan arrancar desde la particin activa (esto a Linux le da
igual). Se puede entonces arrancar MS-DOS desde un disquete y ejecutar el programa FDISK para poner el flag de activo a la particin de
MS-DOS. Otro comando que se puede intentar es FDISK /MBR . Este
comando intentar reconstruir el registro maestro de arranque del disco
(MBR) para arrancar MS-DOS, borrando a LILO. Si no se va a tener
143
MS-DOS en el disco duro, se necesitar arrancar despus Linux desde

un disquete e intentar instalar LILO de nuevo.
2. Si cre particiones para MS-DOS utilizando la versin de fdisk para
Linux, puede obtenerse este error. Las particiones de MS-DOS slo
deben crearse utilizando el comando FDISK de MS-DOS. (Esto afecta
tambin a otros sistemas operativos.) La mejor solucin es empezar
desde el principio y reparticionar los discos correctamente, o simplemente
borrar y rehacer particiones utilizando la versin apropiada de fdisk.
3. El procedimiento de instalacin de LILO puede no haber funcionado
bien. En este caso, se debe arrancarse Linux desde un disquete (si lo
tiene) o desde el medio de arranque original. En cualquiera de los dos
casos deberan proporcionarse opciones para especificar la particin raz
de Linux para arrancar. Se debe mantener pulsada la tecla shift o ctrl
durante el arranque y pulsar tab en el men de arranque para ver las
opciones.
Cuando se arranca desde el disco duro, MS-DOS (u otro) arranca en lugar
de hacerlo Linux. En primer lugar, hay que asegurarse de que se instal LILO
mientras se instalaba el softwarede Linux. Si no, el sistema arrancar MS-DOS
(u otro).
6.3
6.3.1
WebSphere
Que es WebSphere?
WebSphere es una plataforma de Software para e-business.

IBM WebSphere es una plataforma de IBM para desarrollo y gestin de
sitios web y aplicaciones destinadas al comercio electrnico.
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 estndares abiertos de mercado.
WebSphere es ideal para todas las fases de un e-business, comenzando
desde pequeos sitios Web a mega sitios.
La fig. 6.3 de la pg. 145 representa la plataforma virtual de WebSphere.
6.3.2
Plataforma de Software
La complejidad creciente de los aplicativos de e-business crea muchos desafos.

Es necesario conseguir que los aplicativos le permitan comercializar rpida-
6.3. WEBSPHERE
Figura 6.3: Plataforma de WebSphere.
145
146
mente, con contenido relevante y personalizado.

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 ms actualizadas habilidades de programacin para
acompaar el ciclo de vida del e-business.
Se necesita una plataforma completa, escalable y flexible que proporcione
soporte a la construccin y diseminacin 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.
El ambiente de desarrollo del software WebSphere:
Da soporte al desarrollo y cambios rpidos de nuevos aplicativos utilizando un paradigma de desarrollo basado en reglas, permitiendo que
todos utilicen el mismo ambiente y reduciendo costes de entrenamiento.
Proporciona cdigo pre-construido, pre-testeado.
Proporciona herramientas especializadas para pgina Web y desarrollo
de mdulos migrables.
Adicionalmente, servicios basados en estndares Web permiten mezclar y
combinar componentes funcionales de diferentes orgenes de tal forma que se
puede proveer nuevos procesos y servicios al mercado rpida y eficientemente.
La capacidad de un portal de negocios tiene importancia crtica para permitir que las personas interacten y transaccionen de forma personalizada con
diversos recursos de negocios. Empieza dejando a la medida los ambientes
de usuarios para sus necesidades especficas, integrndolo entonces con otros
usuarios para permitir colaboracin en tiempo real, y con los diversos ambientes de TI.
Todo esto permite que las personas trabajen en conjunto de forma ms
productiva mientras actan sobre la informacin 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
6.3. WEBSPHERE
147
ventas para tratar los desafos encontrados en ambientes de clientes y socios

comerciales.
Al expandir el ambiente de usuario para permitir que las personas accedan
a la informacin y acten en cualquier lugar, en cualquier momento, usando
su eleccin de dispositivos y mecanismos de interaccin significa acceso on
demand y las familias WebSphere Everyplace y WebSphere Voice, son software
para expandir aplicaciones de e-business a dispositivos mviles, permitiendo
interaccin 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 geogrficas.
Con el software With WebSphere Commerce, se establecen relaciones ms
estrechas, ms 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
continen maana.
Con el IBM WebSphere Commerce Business Edition, se puede optimizar
procesos de negocio a travs de la automatizacin e integracin con sus aplicativos para los negocios principales, consigue el mayor impacto por el menor
coste y el ROI ms rpido, fortalece las relaciones de negocios con clientes y
contratistas, y disemina un e-business verdaderamente global.
WebSphere for Commerce - Soluciones B2C
El software WebSphere Commerce le permite ir a la lnea de las ventas online
a los consumidores.
Crea campaas de marketing dinmicas, fija como objetivo diferentes segmentos de mercado, elabora promociones de producto personalizadas, y mejora el servicio a clientes. Esta solucin ayuda a crear rpidamente y mantener
eficientemente un sitio interactivo, de alto volumen. Un sitio que atraiga consumidores y los haga volver, obteniendo rpido retorno de inversin.
La solucin WebSphere Commerce proporciona:
148
Personalizacin sofisticada del B2B para ayudar a administrar las relaciones de negocio.
Tecnologa de ventas asistidas para conducir a los clientes y contratistas
a travs de la agrupacin de requisitos y del proceso de seleccin del
producto.
Herramientas de cooperacin online y de formacin de equipo virtual
para mejorar la eficacia de contratistas comerciales, canal y clientes.
Administracin integrada de contrato para soportar contratos complejos
y polticas de negocio.
Administracin de pedidos anticipado resultando en capacidades de optimizacin 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 integracin del WebSphere Commerce y WebSphere Portal permite que las
empresas se dirijan a mltiples sectores con necesidades de personalizacin positivas de soluciones de comercio tanto para las reas B2B o B2C. Actualmente,
muchas empresas crean sitios separados para cada divisin, lo que demanda
mucho tiempo y cuesta caro.
El abordaje racionalizado proporciona rpido retorno de inversin al eliminar la necesidad de que la empresa mantenga mltiples sitios. Las empresas
tambin aumentan la eficiencia de interacciones con clientes y contratistas, lo
que mejora la retencin del cliente.
Los productos IBM WebSphere Commerce y WebSphere Portal proporcionan un nico punto de interaccin con informacin dinmica 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:
6.3. WEBSPHERE
149
Ambientes B2B: organizar eficientemente informacin online, servicios

y aplicativos para contratistas de negocio y proveedores a lo largo de
mltiples 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, informacin y servicios desde la Web y de dispositivos inalmbricos, as como
acceso consolidado a catlogos mltiples.
Con un portal de e-commerce integrado, se les puede ofrecer a los clientes, contratistas y proveedores acceso 24x7 a los aplicativos online - rpida y
fcilmente.
WebSphere for Commerce-Soluciones Digital Media

Empresas de medios con volmenes crecientes de activos digitales -fotos, vdeo
clips, archivos en audio, ilustraciones e imgenes animadas- enfrentan nuevas
exigencias reguladoras y el desafo de colocar esos activos disponibles online.
El software IBM WebSphere permite administrar estos activos digitales ms
eficazmente, alcanzando clientes en todos el mundo a travs 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 tecnologa Java.
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 mrgenes de beneficios.
WebSphere ofrece un amplio portafolio de soluciones clasificadas en tres
reas crticas:
Infraestructura y herramientas de Desarrollo (Fundation & Tools):
Application server.
150
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.
Integracin de negocio (Business Integration):
WebSphere Business Integrator.
WebSphere MQ Integrator.
6.3.3
Application Server
6.3. WEBSPHERE
151
La plataforma de alto desempeo y extrema escalabilidad para diseminar

aplicativos dinmicos de e-business, WebSphere Application Server, Versin
4.0, proporciona las funciones esenciales de e-business de manipulacin de
transacciones y ampliacin de datos back-end del negocio y aplicativos para la
Web. La plataforma ayuda a construir aplicativos que ejecutan esas funciones
con seguridad slida, fiabilidad y escalabilidad.
Application Server. Advanced Edition

La Edicin Avanzada es la oferta del principal servidor de aplicativo dirigido
a desarrolladores profesionales de tecnologa Java que necesitan funcionalidad
de servicios J2EE y Web para aplicativos dinmicos de e-business.
La Edicin Avanzada del WebSphere Application Server Versin 4.0, est
disponible en tres configuraciones distintas:
Edicin Avanzada:
Proporciona integracin slida a las bases de datos, middleware orientado
a mensajes, y sistemas preexistentes y aplicativos, en conjunto con soporte de
agrupacin. Esta configuracin se ajusta a la mayora de los escenarios de la
empresa e interesa a los negocios que necesitan construir aplicativos altamente
transaccionales, administrables, disponibles y escalables que ofrecen seguridad
distribuida y administracin remota.
Edicin Avanzada del Single Server:

Proporciona el mismo modelo de programacin esencial J2EE y Web Services con administracin simplificada. Esta configuracin interesa a departamentos, negocios de tamao mediano y aplicativos piloto que necesitan un
coste bajo, opcin de ejecucin rpida, distribucin de carga de trabajo o
administracin remota asociados a administracin de multi-servidor.
Edicin Avanzada del IBM WebSphere Application Server V4.0, para

Linux en zSeries:
152
La Edicin Avanzada del WebSphere Application Server V4.0, para Linux

en zSeries contina cumpliendo el compromiso de IBM en cuanto a mantener
cobertura amplia para plataformas para el WebSphere Application Server.
Este producto WebSphere tiene la combinacin potente de un conjunto de
dispositivos rico y soporte a estndares abiertos del WebSphere Application
Server y el ambiente operacional familiar del sistema operativo Linux.
Tambin contiene los recursos de administracin, alta fiabilidad, y la intensa velocidad de comunicacin de datos internos del hardware de la plataforma
zSeries.
Application Server. Enterprise Edition
La Edicin empresarial del IBM WebSphere Application Server Versin 4.1, en
conjunto con IBM WebSphere Studio Application Developer Integration Edition, ofrece una combinacin potente de tiempo de ejecucin y herramienta
que permite integrar activos IT existentes, mejorar la productividad del desarrollador y crear y mantener aplicativos de e-business flexibles.
Juntos, el IBMs WebSphere Application Server 4.1 Enterprise Edition y
el WebSphere Studio Application Developer Integration Edition ofrecen ahora
a los desarrolladores la capacidad de:
Coreografiar visualmente y componer servicios de la Web y componentes
de aplicativo J2EE a travs de una interfase de simple drag-and-drop.
Construir potentes adaptadores de aplicativo basados en J2EE Connector Architecture (JCA) para integrar sistemas back-end con servicios
Web y aplicativos J2EE.
Crear una paleta de componentes de aplicativos que puede ser rpidamente montada para desarrollar nuevos aplicativos fcilmente publicada
como servicio Web.
Evitar la repeticin del desarrollo y diseminacin de aplicativos debido a
condiciones cambiantes del mercado, separando las polticas del negocio
de la lgica de aplicativos esenciales.
Obtener una infraestructura completa de servicios Web que impulse un
ambiente nico, eficaz en cuanto a coste de tiempo de ejecucin del
servidor de aplicativo administrativo y operacional.
6.3. WEBSPHERE
153
Application Server. Standard Edition

La Edicin Estndar para desarrolladores de la web y autores de contenido
incluye mejoras de facilidad de uso en toda su extensin, comprendiendo un
Quick Installation que elimina conjeturas en cuanto al Enhanced Java, impulsando el Software Development Kit del Java 2 V1.2.2 en todos los sistemas
operativos soportados.
Servidor HTTP
IBM WebSphere Application Server trabaja con un servidor HTTP para manejar las peticiones de servlets y otros contenidos dinmicos desde las aplicaciones Web.
El servidor HTTP y el servidor de aplicaciones se comunican utilizando
el plug-in HTTP de WebSphere para el servidor HTTP. El plug-in HTTP
utiliza un archivo de configuracin XML de fcil lectura para determinar si la
peticin la debe gestionar el servidor Web o el servidor de aplicaciones. Utiliza
el protocolo HTTP estndar para comunicarse con el servidor de aplicaciones.
Tambin se puede configurar para implementar seguridad en el servidor
HTTP, si fuera necesario. El plug-in HTTP est disponible para los servidores
Web ms conocidos.
Servidor de Aplicaciones
El servidor de aplicaciones colabora con el servidor Web intercambiando peticiones de clientes y respuestas de aplicaciones. Puede definir varios servidores
de aplicaciones, cada uno de ellos ejecutndose en su propia Mquina Virtual
Java (JVM).
Contenedor de EJB
El contenedor de EJB proporciona los servicios de tiempo de ejecucin necesarios para desplegar y gestionar componentes EJB, de ahora en adelante
conocidos como enterprise beans. Es un proceso de servidor que maneja peticiones para beans de sesin y beans de entidad.
154
Los enterprise beans (dentro de los mdulos EJB) instalados en un servidor de aplicaciones no se comunican directamente con el servidor; en su lugar,
el contenedor de EJB ofrece una interfaz entre los enterprise beans y el servidor. Juntos, el contenedor y el servidor proporcionan el entorno de tiempo de
ejecucin del bean.
El contenedor proporciona muchos servicios de bajo nivel, incluido el soporte de hebras y transacciones. Desde un punto de vista administrativo, el
contenedor gestiona el almacenamiento y la recuperacin de datos para los
beans que contiene. Un solo contenedor puede gestionar ms de un archivo
JAR de EJB.
Contenedor Web
Los servlets y los archivos JSP (Java Server Pages) son componentes del servidor que se utilizan para procesar peticiones de clientes HTTP como, por
ejemplo, navegadores Web. Se encargan de la presentacin y el control de
la interaccin del usuario con los datos de aplicacin subyacentes y la lgica
empresarial. Tambin pueden generar datos formateados, como XML, para
que los utilicen otros componentes de aplicacin.
El contenedor Web procesa servlets, archivos JSP y otros tipos de inclusiones de servidor. Los servlets anteriores a J2EE se ejecutarn en un motor
de servlets. Cada contenedor Web contiene automticamente un nico gestor
de sesiones.
Cuando se manejan los servlets, el contenedor Web crea un objeto de
peticin y un objeto de respuesta, e invoca el mtodo de servicio de servlets.
El contenedor Web invoca el mtodo destroy() del servlet cuando corresponda
y descarga el servlet, y despus la JVM ejecuta la recoleccin de basura.
Contenedor de Clientes de Aplicaciones

Los clientes de aplicaciones son programas Java que se ejecutan normalmente
en un sistema de sobremesa con una interfaz grfica de usuario (GUI) . Tienen
acceso a toda la gama de componentes y servicios de servidor J2EE.
El contenedor de clientes de aplicaciones maneja programas de aplicaciones de Java que acceden a los beans enterprise, Java Database Connectivity
6.3. WEBSPHERE
155
(JDBC) y las colas de mensajes de Java Message Service. El programa Cliente

de aplicaciones J2EE se ejecuta en las mquinas cliente.
Este programa sigue el mismo modelo de programacin Java que otros
programas Java; no obstante, el cliente de aplicaciones J2EE depende del
tiempo de ejecucin del cliente de aplicaciones para configurar su entorno de
ejecucin, y utiliza el espacio de nombres JNDI (Java Naming and Directory
Interface) para acceder a los recursos.
Contenedor de Applets
Un applet es una clase Java de cliente que se ejecuta normalmente en un
navegador Web, pero que tambin se pueden ejecutar en otros dispositivos y
aplicaciones de cliente.
Los applets se utilizan a menudo junto con pginas HTML para mejorar
la experiencia de usuario que ofrece el navegador Web. Tambin se pueden
utilizar para pasar parte de la carga de trabajo de proceso del servidor al
cliente.
El contenedor de applets maneja applets de Java incorporados en documentos HTML (HyperText Markup Language) que residen en una mquina
cliente remota respecto al servidor de aplicaciones. Con este tipo de cliente,
el usuario accede a un bean enterprise en el servidor de aplicaciones mediante
el applet de Java en el documento HTML.
Sistema Principal Virtual

Un sistema principal virtual es una configuracin que permite que una nica
mquina de sistema principal parezca varias mquinas de sistema principal.
Los recursos asociados con un sistema principal virtual no pueden compartir
datos con recursos asociados con otro sistema principal virtual, incluso si los
sistemas principales virtuales comparten la misma mquina fsica.
Los sistemas principales virtuales permiten al administrador asociar aplicaciones Web con un sistema principal particular configurado para la mquina
que ejecuta la aplicacin.
156
6.3.4
Arquitecturas de Tres Niveles
WebSphere Application Server proporciona la capa de la lgica de aplicacin

en una arquitectura de tres niveles, lo que permite a los componentes de cliente
interactuar con los recursos de datos y las aplicaciones heredadas.
De manera colectiva, las arquitecturas de tres niveles son modelos de programacin que permiten la distribucin de la funcionalidad de la aplicacin
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 coleccin discreta de bases de datos, gestores de recursos y aplicaciones de sistema principal (nivel tres).
Primer nivel:
La responsabilidad de la presentacin y la interaccin 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 facturacin y el envo.
Segundo nivel (capa de la lgica de aplicacin):
Los procesos del segundo nivel se conocen normalmente como la
capa de la lgica de aplicacin. Estos procesos gestionan la lgica
empresarial de la aplicacin y pueden acceder a los servicios del
tercer nivel.
6.3. WEBSPHERE
157
La capa de la lgica de aplicacin es donde se produce la mayor

parte del trabajo de los procesos.
Varios componentes de cliente pueden acceder simultneamente a
los procesos del segundo nivel, por lo que esta capa de la lgica de
aplicacin debe gestionar sus propias transacciones.
Si varios clientes intentan realizar un pedido del mismo artculo,
del que slo queda uno, la capa de la lgica de aplicacin debe
determinar quin tiene derecho a ese artculo, actualizar la base
de datos para reflejar la compra e informar a los otros clientes de
que el artculo ya no est disponible. Sin una capa de la lgica de
aplicacin, 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 artculo se coloca
en un carro de compra, para evitar que los dems clientes consideren
la posibilidad de compra.
La separacin 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 gestin de conexiones ms elocuente.
Tercer nivel:
Los servicios del tercer nivel estn protegidos del acceso directo de
los componentes de cliente al residir en una red segura.
La interaccin debe producirse a travs de los procesos del segundo
nivel.
Los tres niveles deben poder comunicarse entre ellos. Los protocolos abiertos estndar y las API expuestas simplifican esta comunicacin. Los componentes de cliente se pueden escribir en cualquier lenguaje de programacin
como, por ejemplo, Java o C++, y se puedan ejecutar en cualquier sistema
operativo, siempre que pueden comunicarse con la capa de la lgica de aplicacin.
De la misma forma, las bases de datos del tercer nivel pueden tener cualquier diseo, siempre que la capa de la lgica de aplicacin pueda consultarlas
y manipularlas. La clave de esta arquitectura es la capa de la lgica de aplicacin.
158
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 desempeo, extremadamente escalable
para aplicaciones de e-business dinmicos.
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 rpidamente 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 modernizacin de la empresa es proporcionada
por herramientas especializadas de desarrollo de la familia WebSphere Studio
y a travs 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, rpidamente! extiende los aplicativos de host a la Web
y proporciona software para la creacin y diseminacin de nuevos aplicativos para host de acceso a e-business, sin necesidad de cambios a los propios
6.3. WEBSPHERE
159
aplicativos existentes.
Tanto si se necesita una simple entrega de pgina Web, darle un nuevo aspecto a un aplicativo preexistente, o crear soluciones Java sofisticadas, el IBM
WebSphere Host Integration Solution permite rpida y flexiblemente integrar
datos crticos de la empresa la Web.
El WebSphere Host Publisher proporciona la manera ms rpida, ms fcil
para implementar e-business mediante la ampliacin 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 caractersticas de disponibilidad, hacen del Host
Publisher la solucin ideal para diseminaciones de nuevos e-business. Tanto
si su objetivo es coste menor o mayores ganancias a travs de diseminaciones
Web-to-Host o a travs del desarrollo de nuevos aplicativos para e-business.
Las caractersticas clave son:
Proporciona integracin 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 fcil consolidacin de mltiples aplicativos en un aplicativo
compuesto nico o pgina Web para presentacin a usuarios de la Web.
Se integra con la Edicin Avanzada del WebSphere Application Server
e incluye el WebSphere Studio para proporcionar una solucin 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 tecnologas 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 inversin en Host Publisher utilizando objetos de
integracin basados en estndares 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.
160
Puede ser implementado sin programacin utilizando una simple interface grfica 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 tecnologa 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.
6.3.5
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 distribucin
de los elementos de una pgina web usando Java Server Pages (JSPs), HTML,
Java Script, y DHTML, ayudando adems, a un rpido desarrollo de aplicaciones de comercio electrnico con contenido dinmico. Una fcil integracin
entre WebSphere Studio, Java VisualAge, y WebSphere Application Servers
hace que la comunicacin y el trabajo en grupo para la creacin de aplicaciones de comercio electrnico basadas en Web, sea mucho ms sencillo.
La familia IBM WebSphere Studio, consta de una serie de productos basados en Eclipse, que es una plataforma de cdigo 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
comn de herramientas, por ejemplo para el desarrollo Java y Web. La diferencia entre estos productos radica en las herramientas de conector que estn
disponibles en cada configuracin.
WebSphere Studio es un nico entorno de desarrollo completo diseado
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 integracin de aplicaciones.
Con varias configuraciones disponibles, as como extensiones de IBM y de
terceros, la familia WebSphere Studio permite a los desarrolladores utilizar un
6.3. WEBSPHERE
161
nico entorno de desarrollo diseado para satisfacer sus necesidades especficas.

Esta visin 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 estn construyendo pginas 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 diseadores
Web novatos crear y publicar sitios Web al tiempo que incorpora lo ltimo en
tecnologa Web, incluyendo Java Script, HTML dinmico y hojas de estilo en
cascada.
El entorno completo y fcil de utilizar de la familia WebSphere Studio
permite construir aplicaciones Java, adaptadores de aplicaciones y servicios
Web. Tambin puede integrar la aplicacin 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
homognea en menor tiempo, la familia WebSphere Studio proporciona configuraciones para el desarrollo rpido de aplicaciones que utilizan el poder de la
automatizacin de lgica empresarial para proporcionar sistemas de empresa
altamente configurables y escalables con una codificacin manual mnima.
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 gestin y arquitecto
de sistemas.
6.4
6.4.1
Servlet
Desarrollando Servlets
Los servlets son programas de Java que construyen respuestas dinmicas para
el cliente, tal como pginas Web. Los servlets reciben y responden a las
demandas de los clientes Web, normalmente por HTTP.
Los servlets son ms eficientes que los programas (CGI) porque son cargados de una sola vez en la memoria, y cada demanda es manejada por un hilo
de la mquina virtual de Java, no por el sistema operativo.
Adems los servlets son escalables, dando soporte para una multi-aplicacin
de configuracin del servidor. [?, IBM Press]
Permiten utilizar datos cach, acceso a informacin de base de datos, y
compartir datos con otro servlets, archivos JSP y (en algunos ambientes) con
los bean empresariales.
Principios de Codificacin de Servlet

Para crear un servlet de HTTP, es necesario extender las clases:
javax.servlet.HttpServlet y sustituir cualquier mtodo que se desee implementar en el servlet. Por ejemplo, un servlet reemplaza el mtodo doGet para
manejar las demandas Get de los clientes.
El HttpServletRequest representa los requerimientos de un cliente. Este
objeto da acceso al servlet, a la informacin incluida como datos en formato
6.4. SERVLET
163
HTML, encabezados HTTP, etc.

El HttpServletResponse representa la respuesta del servlet.
El servlet usa este objeto para devolverle datos al cliente como errores
de HTTP (200, 404, y otros), encabezados de respuesta (Content-Type, SetCookie, y otros), y datos de salida para escribir cadenas de salida de respuesta
o salida impresa.
El principio de un servlet podra parecerse al siguiente ejemplo:
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.util.*;
public class MyServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException{
Ciclo de Vida del Servlet

Las clases javax.servlet.http.HttpServlet definen mtodos tales como:
Iniciar un servlet.
Solicitar servicios.
Quitar un servlet del servidor.
stos son conocidos como mtodos del ciclo de vida y son llamados en la
siguiente secuencia:
Se construye el servlet.
Se inicializa con el mtodo INIT.
Se manejan llamadas de los clientes al mtodo de servicio.
164
Se saca el servlet de servicio.

Se destruye con el mtodo destruir.
Se finaliza el servlet y la basura es recolectada.
En la fig. 6.4 de la pg. 165 se puede apreciar grficamente el Ciclo de
Vida de un Servlet.
Instanciacin e Inicializacin
El motor del servlet (la funcin del Servidor de Aplicaciones que procesa servlets, archivos JSP, y otros tipos de server-side incluyendo codificacin) crea
una instancia del servlet. El motor del servlet crea el objeto de configuracin
del servlet y lo usa para pasar los parmetros de inicializacin del servlet al
mtodo INIT. La inicializacin de los parmetros persiste hasta que el servlet se destruye y es aplicada a todas las invocaciones de ese servlet hasta
destruirse.
Si la inicializacin tiene xito, el servlet est disponible para el servicio. Si
la inicializacin falla, el motor del servlet descarga el servlet. El administrador
puede inhabilitar una aplicacin y el servlet para el servicio. En tales casos,
la aplicacin y el servlet permanecen inhabilitados hasta que el administrador
los habilite.
Servicio de Demanda
Una demanda del cliente llega al servidor de aplicaciones. El motor del servlet
crea un objeto demanda y un objeto respuesta. El motor del servlet invoca
al mtodo de servicio del servlet, procesa el requerimiento y usa mtodos del
objeto respuesta para crear la respuesta para el cliente.
El mtodo de servicio recibe informacin sobre el requerimiento del objeto
demanda, procesa el requerimiento, y usa los mtodos del objeto respuesta
para crear la contestacin para el cliente. El mtodo de servicio puede invocar
otros mtodos para procesar el requerimiento, tales como doGet (), doPost (),
o mtodos del usuario.
6.4. SERVLET
165
Figura 6.4: Ciclo de Vida de un Servlet.
166
Figura 6.5: Requerimiento de un Archivo JSP.

Terminacin
El motor del servlet invoca al mtodo destroy () del servlet cuando apropia
y descarga el servlet. La Mquina Virtual de Java realiza la recoleccin de
basura despus de la destruccin del servlet.
Cuando el contenedor Web ya no necesita que el servlet o una nueva instancia del servlet se recarguen, invoca al mtodo destroy () del servlet. El
contenedor Web tambin puede llamar al mtodo destroy () si el motor necesita conservar recursos o una llamada pendiente a un mtodo service () del
servlet excediendo el timeout. La Mquina Virtual de Java realiza recoleccin
de basura despus del destroy.
Modelos de Acceso JSP

Se puede acceder a los archivos JSP de dos maneras:
El browser enva un requerimiento para los archivos JSP.
Los archivos JSP acceden a los beans u otros componentes que generan
contenido dinmico para ser enviado al browser como se muestra en la fig. 6.5
de la pg. 166.
Cuando el servidor Web recibe un requerimiento para un archivo JSP, el
servidor enva ese requerimiento al servidor de aplicaciones. El servidor de
aplicaciones analiza el archivo JSP y genera cdigo fuente de Java que se
compila y se ejecuta como un servlet.
6.4. SERVLET
167
Figura 6.6: Requerimiento de un Servlet.

El requerimiento se enva a un servlet que genera contenido dinmico y
llama a un archivo JSP para enviar el contenido a un browser, como se muestra
en la fig. 6.6 de la pg. 167.
Este modelo de acceso facilita la generacin de contenido separado del
despliegue de contenido.
El servidor de aplicaciones proporciona un juego de mtodos en el objeto
HttpServiceRequest object y el objeto HttpServiceResponse. Estos mtodos
permiten una invocacin de servlet para colocar un objeto (normalmente un
bean) en un objeto demanda y pasa ese requerimiento a otra pgina (normalmente un archivo JSP) para el despliegue. La pgina invocada recupera el
beans del objeto demanda y genera el HTML que recibe el cliente.
Procesadores JSP
Cada procesador de JSP es un servlet que se puede adherir a una aplicacin
Web para manejar todos los requerimientos JSP pertenecientes a la misma.
168
Cuando se instala el Application Server en un servidor Web, la configuracin del servidor Web pasa los requerimientos HTTP para los archivos JSP
(archivos con la extensin .jsp) al Application Server.
El procesador de JSP crea y compila un servlet desde cada archivo JSP.
El procesador produce estos archivos para cada JSP:
Archivos Java que contienen el cdigo del lenguaje Java para el servlet.
Archivos de clase que se compilan en el servlet.
El procesador de JSP pone los archivos .java, y .class en un camino especfico al procesador. Los archivos .java y .class tienen el mismo nombre de
archivos. El procesador usa una convencin de denominacin que incluye el
agregado de subrayado de los caracteres y un sufijo para el nombre del archivo
JSP.
Por ejemplo, si el nombre del archivo JSP es simple.jsp, los archivos generados son: _simple_xjsp.java y _simple_xjsp.class.
Como todos los servlets, un servlet generado desde un archivo JSP se extiende desde javax.servlet.http.HttpServlet. El cdigo Java de servlet contiene
declaraciones de importacin para las clases necesarias y una declaracin de
paquete, si la clase del servlet es parte de un paquete.
Si el archivo JSP contiene sintaxis de JSP (como directivas y scriptlets), el
procesador de JSP convierte la sintaxis de JSP al cdigo Java equivalente. Si
el archivo JSP contiene etiquetas HTML, el procesador agrega el cdigo Java
a fin de que el servlet realice la salida de HTML carcter por carcter.
Compilacin Batch de Archivos JSP

WebSphere Application Server proporciona un compilador batch de JSP. Al
usar la funcin del compilador batch de archivos JSP, se habilitan respuestas
ms rpidas al requerimiento inicial del cliente para los archivos JSP en el
servidor Web de produccin.
El compilador batch ahorra recursos del sistema y proporciona seguridad en
el servidor de aplicaciones, especificando cundo el servidor est chequeando
un archivo de clase o recompilando un archivo JSP. El servidor de aplicaciones
6.4. SERVLET
169
supervisar la compilacin de los archivos JSP para cambios, y automticamente compilar y recargar los archivos JSP, siempre que el servidor de aplicaciones descubra que el archivo JSP ha cambiado. Modificando este proceso,
se puede ahorrar tiempo y recursos consumidos por las compilaciones y asegurar que se tenga el control de la compilacin de los archivos JSP. Tambin es
til como una manera rpida al sincronizar todos los archivos JSP para una
aplicacin.
Desarrollando Aplicaciones
Para WebSphere Application Server, las aplicaciones son combinaciones de
bloques que trabajan conjuntamente para el logro de una funcin de la lgica
comercial. Las aplicaciones Web son grupos de uno o ms servlets, ms el
contenido esttico.
Aplicaciones Web = servlets + archivos JSP + archivos XML + archivos
HTML + grficos.
El modelo de programacin de WebSphere Application Server est basado
en la plataforma Java de Sun (J2SE). El ambiente J2SE soporta la base para
construir redes centrales de aplicaciones empresariales para correr sobre una
variedad de sistemas. El software J2SE consiste en los Java SDK Standard
Edition y el Java Runtime Environment (JRE) Standard Edition.
Fases de Inicializacin y de Terminacin
Un motor del servlet crea una instancia de un servlet en los siguientes momentos:
Automticamente en el arranque de la aplicacin, si esa opcin se configura para el servlet.
En la primera demanda del cliente para el servlet despus del arranque
de la aplicacin.
Cuando el servlet se vuelve a cargar.
El mtodo INIT ejecuta slo una vez durante la vida del servlet. Ejecuta
cuando el motor del servlet carga el servlet. Con el Application Server se
170
puede configurar el servlet para ser cargado cuando comienza la aplicacin o

cuando un cliente accede por primera vez al servlet. El mtodo INIT no se
repite a menos que muchos clientes accedan al servlet.
El mtodo destroy () ejecuta slo una vez durante la vida del servlet. Eso
pasa cuando el motor del servlet detiene el servlet. Tpicamente, se detienen
servlets como parte del proceso de detener la aplicacin.
Rasgos de Java Servlet API

Algunos puntos de inters del Java Servlet API son:
Un despachador de requerimientos asociado a cada recurso (servlet).
Un despachador de requerimientos de recursos que pueden procesar demandas HTTP (como servlets y archivos JSP) y los archivos relacionados a
esos recursos (como HTML esttico y GIFs). El motor del servlet genera un
solo despachado de requerimiento por cada servlet o JSP cuando se produce
una instanciacin. El despachador recibe el pedido del cliente y despacha la
demanda al recurso.
Un contexto del servlet para la aplicacin.
Patrones y Guas de Servlets/JSP
En esta seccin se proporciona las pautas especficas sobre cmo organizar una
aplicacin que usa servlets y JSPs.
Patrones Servlet/JSP.
Con este modelo es posible organizar una aplicacin Web en el servlets y
JavaServer Pages de manera tal que es fcil de mantener el cdigo.
Motivacin.
6.4. SERVLET
171
Para aplicaciones que requieren modelado complejo sobre el nodo del servidor de aplicacin Web, no es fcil definir la granularidad de servlets y cmo
interactan los servlets. Pero sin un buen diseo para el servlets y JSP es
difcil mantener la aplicacin.
Adems en la fase del anlisis de un proyecto, usa casos y diagramas de
transicin de estados ampliamente usados para describir el resultado de la fase
del anlisis. Podra ser til trazar esos resultados en el diseo e implementacin
de la fase.
En un caso se puede contemplar el servlet como el evento central y procesa
todas las demandas del cliente. Ejecuta la accin necesaria para ese evento
y enva el requerimiento a uno (de muchos) JavaServer Page por desplegar el
resultado. Usando esta solucin, puede ser difcil de desarrollar ese servlet.
As como es responsable para un conjunto de casos de uso, se puede tener que
llevar a cabo mucha lgica en ese servlet.
En otro caso se puede tener tantos servlets como JavaServer Pages y encadenarlos. Esto significa que un servlet obtiene un requerimiento, ejecuta la
accin correcta, y llama al JavaServer Page especfico para ese servlet, para
desplegar el resultado. Un requerimiento de ese JSP entonces obtiene otro servlet, y as sucesivamente. Ser difcil mantener muchos servlets y JSP, puede
confundirse al intentar entender el flujo de la aplicacin.
Una solucin que tiene una granularidad entre esos extremos es dividiendo la aplicacin en estados diferentes. Se intenta transferir un diagrama de
transicin de estados (por ejemplo, modelado con RationalRose) en pginas
HTML, servlets y JavaServer Pages.
Applicabilidad.
Este modelo puede usarse en toda aplicacin servlet /JSP. Es recomendable este modelo sobre todo en las aplicaciones Web complejas donde muchas
pginas Web y transiciones de pginas tienen que ser desarrolladas.
Componentes.
Los componentes en esta estructura son:
172
Servlet: un requerimiento dado recoge los datos requeridos para el

despliegue de un estado dado o invoca la accin que causa una transicin fuera del estado. Esta responsabilidad lo hace el controlador
en un Modelo-Vista-Controlador (MVC) basado en la aplicacin.
JavaServerPage: es el indicador de la generacin de cdigo HTML
para un resultado del requerimiento dado.
Wrapper de Tareas: encapsula el acceso al proceso empresarial de
negocios (datos back-end y funcin). Esta funcin realiza el modelo
de wrapper de tareas en una aplicacin MVC.
Pginas HTML: en caso de contenido esttico y transiciones de estado, no es necesario tecnologas complejas. Un indicador de estado
esttico de pgina HTML.
Colaboradores.
Un flujo de aplicacin Web puede capturarse en un diagrama de transicin
de estado (que es, a propsito, una documentacin buena para el flujo de la
aplicacin). Un diagrama de transicin de estado contiene nombres de estado
conectados con los nombres de las ramas.
La solucin,es trazar cada componente del diagrama de transicin de estado
a un componente de la arquitectura de e-business para que pueda manejarse
mediante WebSphere Aplication Server.
Se separa en el diagrama los estados estticos y los estados dinmicos.
Las transiciones de estado estticos son inherentes. Como ellos son estticos en el controlador y en las transiciones, se puede codificar un estado como
una pgina HTML que debe ser nombrado despus del estado: < el Estado
>.html.
Cuando hereda estados dinmicos, es un tanto ms dificultoso. Conforme
a la arquitectura e-business, se divide el estado en modelo, vista y controlador.
Controlador.
El servlet acta como el controlador de estado en este escenario. Esto
significa que se captura un servlet por estado dinmico. Nombrando la convencin, el servlet es llamado despus del estado: < State>Servlet. Haciendo
esto se consigue un mtodo fcil de documentacin.
6.4. SERVLET
173
Pensando sobre cada interaccin entre el navegador y el servidor de aplicaciones Web (por ejemplo, el servlet) como una sola unidad de trabajo, de
slo lectura o de actualizacin. Hay dos flujos bsicos de modelos de control,
ambos, llevado a cabo por el servlet. Uno se ocupa del despliegue para un
estado dado, y el otro maneja las acciones que causan un cambio de estado.
Despliegue de Patrones.
Este modelo normalmente se manifiesta dentro de HTML como un link,
resultando en un requerimiento Get. El flujo de control para este modelo es:
El servlet invoca el mtodo apropiado de slo lectura en el modelo
de estado (ese es el wrapper de la tarea) y selecciona el JSP para
ocuparse del resultado.
El servlet inicializa el objeto de datos asociado con el JSP, carga el
resultado y coloca la vista del bean en un atributo HttpRequest.
El servlet remite la demanda al JSP escogido.
La Pgina de JavaServer genera el cdigo del HTML.
El servlet enva el requerimiento al JSP seleccionado.
El JSP genera el cdigo HTML.
Vistas.
Las vistas se implementan como un JSP.
Cosecuencias.
Usando este modelo, es posible conseguir un acercamiento bueno para disear una aplicacin Web, mediante la utilizacin de servlets, JSPs, wrapper
de tareas y pginas HTML.
6.5
6.5.1
JAVA
Introduccin al Lenguaje
Java es un lenguaje orientado a objetos. Esto significa que posee ciertas

caractersticas que hoy da se consideran estndares en los lenguajes OO:
Objetos.
Clases.
Mtodos.
Subclases.
Herencia simple.
Enlace dinmico.
Encapsulamiento.
Para programar orientado a objetos es necesario primero disear un conjunto de clases. La claridad, eficiencia y mantenibilidad del programa resultante
depender principalmente de la calidad del diseo de clases. Un buen diseo
de clases significar una gran economa en tiempo de desarrollo y mantencin.
Lamentablemente se necesita mucha habilidad y experiencia para lograr
diseos de clases de calidad. Un mal diseo de clases puede llevar a programas
OO de peor calidad y de ms alto costo que el programa equivalente no OO
[?, Castillo-Cobo-Solares].
Por qu entonces la ventaja de programar en un lenguaje OO, si se requiere
una experiencia que probablemente una persona nunca tendr el tiempo de
prctica para llegar a obtenerla. La respuesta a este interrogante es que Java es
un lenguaje multiparadigma (como muchos otros lenguajes de programacin).
No se necesita hacer un diseo de clases para programar una aplicacin de mil
lneas.
Entonces otro interrogante podr ser por qu no programar con otro lenguaje ms simples, como puede ser Visual Basic, si no se necesita que sea
OO. La respuesta a esto es la gran ventaja de un lenguaje OO, que son las
6.5. JAVA
175
bibliotecas de clases que se pueden construir para la aplicacin [?, Joyanes

Aguilar-Zahonero Martnez]. Una biblioteca de clases cumple el mismo objetivo de una biblioteca de procedimientos en una lenguaje como C. Sin embargo:
Una biblioteca de clases es mucho ms fcil de usar que una biblioteca de
procedimientos, incluso para programadores sin experiencia en orientacin a
objetos. Esto se debe a que las clases ofrecen mecanismos de abstraccin ms
eficaces que los procedimientos.
Se puede distinguir entre varios tipos de programadores en Java:
El diseador de clases: es el encargado de definir qu clases ofrece
una biblioteca y cul es la funcionalidad que se espera de estas clases. Esta persona tiene que ser muy hbil y de mucha experiencia.
Un diseo equivocado puede conducir a clases que son incomprensibles para los clientes de la biblioteca.
El programador de clases de biblioteca: slo programa las clases
especificadas por el diseador de clases. Esta persona debe entender
orientacin a objetos, pero no requiere mayor experiencia en diseo
de clases.
El cliente de bibliotecas: es el programador de aplicaciones. l slo
usa las clases que otros han diseado y programado. Como en el
caso anterior necesita entender orientacin a objetos y conocer la
biblioteca que va usar, pero no necesita mayor experiencia.
Tanto programadores de clases como clientes de bibliotecas pueden llegar
a convertirse en buenos diseadores de clases en la medida que adquieran
experiencia, comparando los diseos de las bibliotecas que utilicen.
Por lo tanto es importante destacar que no se necesita gran experiencia en
diseo orientado a objetos para poder aprovechar las ventajas de la orientacin
a objetos [?, Joyanes Aguilar].
Bibliotecas de Clases Estndares de Java

Toda implementacin de Java debe tener las siguientes bibliotecas de clases:
Manejo de archivos.
176
Comunicacin de datos.
Acceso a la red Internet.
Acceso a bases de datos.
Interfaces grficas.
La interfaz de programacin de estas clases es estndar, es decir en todas
ellas las operaciones se invocan con el mismo nombre y los mismos argumentos.
Java es Multiplataforma
Los programas en Java pueden ejecutarse en cualquiera de las siguientes plataformas, sin necesidad de hacer cambios:
Windows/95 y /NT.
Power/Mac.
Unix (Solaris, Silicon Graphics, ...).
La compatibilidad es total:
A nivel de fuentes: el lenguaje es exactamente el mismo en todas las
plataformas.
A nivel de bibliotecas: en todas las plataformas estn presentes las mismas
bibliotecas estndares.
A nivel del cdigo compilado: el cdigo intermedio que genera el compilador
es el mismo para todas las plataformas. Lo que cambia es el intrprete del
cdigo intermedio.
Caractersticas del Lenguaje Java

Robustez
En Java no se pueden cometer los cuatro errores que se mencionarn a
continuacin:
6.5. JAVA
177
Java siempre chequea los ndices al acceder a un arreglo.

Java realiza chequeo de tipos durante la compilacin (al igual que C).
En una asignacin entre punteros el compilador verifica que los tipos sean
compatibles.
Adems, Java realiza chequeo de tipos durante la ejecucin (cosa que C y
C++ no hacen). Cuando un programa usa un cast para acceder a un objeto
como si fuese de un tipo especfico, se verifica durante la ejecucin que el
objeto en cuestin sea compatible con el cast que se le aplica. Si el objeto no
es compatible, entonces se levanta una excepcin que informa al programador
la lnea exacta en donde est la fuente del error.
Java posee un recolector de basuras que administra automticamente la
memoria. Es el recolector el que determina cundo se puede liberar el espacio
ocupado por un objeto. El programador no puede liberar explcitamente el
espacio ocupado por un objeto.
Java no posee aritmtica de punteros, porque es una propiedad que no se
necesita para programar aplicaciones. En C slo se necesita la aritmtica de
punteros para programa malloc/free o para programar el ncleo del sistema
operativo.
Por lo tanto Java no es un lenguaje para hacer sistemas operativos o
administradores de memoria, pero s es un excelente lenguaje para programar
aplicaciones.
Flexibilidad
Java combina flexibilidad, robustez y legibilidad gracias a una mezcla de
chequeo de tipos durante la compilacin y durante la ejecucin. En Java se
pueden tener punteros a objetos de un tipo especfico y tambin se pueden
tener punteros a objetos de cualquier tipo. Estos punteros se pueden convertir
a punteros de un tipo especfico aplicando un cast, en cuyo caso se chequea en
tiempo de ejecucin de que el objeto sea de un tipo compatible.
El programador usa entonces punteros de tipo especfico en la mayora de
los casos con el fin de ganar legibilidad y en unos pocos casos usa punteros
a tipos desconocidos cuando necesita tener flexibilidad. Por lo tanto Java
combina la robustez de Pascal con la flexibilidad de Lisp, sin que lo programas
pierdan legibilidad en ningn caso.
178
Administracin Automtica de la Memoria

En Java los programadores no necesitan preocuparse de liberar una porcin
de memoria cuando ya no lo necesitan. Es el recolector de basuras el que
determina cundo se puede liberar la memoria ocupada por un objeto.
Un recolector de basuras es un gran aporte a la productividad. Se ha
estudiado en casos concretos que los programadores han dedicado un 40% del
tiempo de desarrollo a determinar en qu momento se puede liberar un trozo
de memoria.
Adems este porcentaje de tiempo aumenta a medida que aumenta la
complejidad del software en desarrollo. Es relativamente sencillo liberar correctamente la memoria en un programa de 1000 lneas. Sin embargo, es difcil
hacerlo en un programa de 10000 lneas. Y se puede postular que es imposible
liberar correctamente la memoria en un programa de 100000 lneas.
Para entender mejor esta afirmacin, se podra suponer que se realiz un
programa de 1000 lneas hace un par de meses y ahora se necesita hacer algunas
modificaciones. Ahora, para esta altura ya se habrn olvidado gran parte de
los detalles de la lgica de ese programa y no ser sencillo determinar si un
puntero referencia un objeto que todava existe, o si ya fue liberado. Peor an,
supngase que el programa fue hecho por otra persona y evale cun probable
es cometer errores de memoria al tratar de modificar ese programa.
Volviendo al caso de un programa de 100000 lneas. Este tipo de programas los desarrolla un grupo de programadores que pueden tomar aos en
terminarlo. Cada programador desarrolla un mdulo que eventualmente utiliza objetos de otros mdulos desarrollados por otros programadores. Entonces,
quin libera la memoria de estos objetos, cmo se ponen de acuerdo los programadores sobre cundo y quin libera un objeto compartido, o cmo probar el
programa completo ante las infinitas condiciones de borde que pueden existir
en un programa de 100000 lneas.
Es inevitable que la fase de prueba dejar pasar errores en el manejo de memoria que slo sern detectados ms tarde por el usuario final. Probablemente
se incorporarn otros errores en la fase de mantenimiento.
Resumiendo, se puede concluir que: todo programa de 100000 lneas que
libera explcitamente la memoria tiene errores latentes, sin un recolector de
basuras no hay verdadera modularidad y un recolector de basuras resuelve
todos los problemas de manejo de memoria en forma trivial.
6.6. ESTRUCTURA GENERAL DE UN PROGRAMA JAVA
179
El interrogante sera cul es el impacto de un recolector de basura en el

desempeo de un programa. El sobrecosto de la recoleccin de basuras no es
superior al 100%. Es decir si se tiene un programa que libera explcitamente la
memoria y que toma tiempo X, el mismo programa modificado de modo que
utilice un recolector de basuras para liberar la memoria tomar un tiempo no
superior a 2X. Este sobrecosto no es importante si se considera el peridico
incremento en la velocidad de los procesadores.
El impacto de un recolector de basura en el tiempo de desarrollo y en la
confiabilidad del software resultante es muchos ms importante que la prdida
en eficiencia.
6.6
Estructura General de un Programa Java
En el siguiente ejemplo se presenta la estructura habitual de un programa

realizado en cualquier lenguaje orientado a objetos u OOP (Object Oriented
Programming), y en particular en el lenguaje Java:
import java.awt.*;
import java.lang.String;
import java.lang.Integer;
import java.awt.event.WindowEvent;
import java.util.*;
import java.awt.TextField;
public class Simu extends Frame implements ActionListener,ItemListener{
MenuBar barra;
m1 =new Menu(Archivo);
barra.add(m1);
m2 =new Menu(Ver);
barra.add(m2);
....
public static void main(String argv [ ]){
Simu menus = new Simu();
180
menus.setTitle(Simulacin de Redes);
menus.setVisible(true);
}
}
Aparece una clase que contiene el programa principal Simu (aquel que
contiene la funcin main()) y algunas clases de usuario (las especficas de
la aplicacin que se est desarrollando) que son utilizadas por el programa
principal. La aplicacin se ejecuta por medio del nombre de la clase que
contiene la funcin main(). Las clases de Java se agrupan en packages, que
son libreras de clases. Si las clases no se definen como pertenecientes a un
package, se utiliza un package por defecto (default) que es el directorio activo.
6.6.1
Conceptos Bsicos
Clase
Una clase es una agrupacin de datos (variables o campos) y de funciones
(mtodos) que operan sobre esos datos. A estos datos y funciones pertenecientes a una clase se les denomina variables y mtodos o funciones miembro. La
programacin orientada a objetos se basa en la programacin de clases [?, Joyanes]. Un programa se construye a partir de un conjunto de clases.
Una vez definida e implementada una clase, es posible declarar elementos
de esta clase de modo similar a como se declaran las variables del lenguaje (int,
double, String). Los elementos declarados de una clase se denominan objetos
de la clase. De una nica clase se pueden declarar o crear numerosos objetos.
La clase es lo genrico: es el patrn o modelo para crear objetos. Cada objeto
tiene sus propias copias de las variables miembro, con sus propios valores, en
general distintos de los dems objetos de la clase. Las clases pueden tener
variables static, que son propias de la clase y no de cada objeto [?, Bosz].
Ejemplo:
public abstract class FuncionActivacion implements Cloneable,Serializable{

/*constructor sin argumentos que permite la herencia */
181
public FuncionActivacion () {
}
}
Herencia
La herencia permite que se puedan definir nuevas clases basadas en clases
existentes, lo cual facilita reutilizar cdigo previamente desarrollado. Si una
clase deriva de otra (extends) hereda todas sus variables y mtodos. La clase
derivada puede aadir nuevas variables y mtodos y/o redefinir las variables
y mtodos heredados.
En Java, a diferencia de otros lenguajes orientados a objetos, una clase slo
puede derivar de una nica clase, con lo cual no es posible realizar herencia
mltiple en base a clases. Sin embargo es posible simular la herencia mltiple
en base a las interfaces.
Interface
Una interface es un conjunto de declaraciones de funciones. Si una clase implementa (implements) una interface, debe definir todas las funciones especificadas por la interface. Una clase puede implementar ms de una interface,
representando una forma alternativa de la herencia mltiple.
Una interface puede derivar de otra o incluso de varias interfaces, en cuyo
caso incorpora todos los mtodos de las interfaces de las que deriva.
Ejemplo: La clase TangenteHiperblica se extiende de la clase FuncinActivacin que implementa la interface Serializable.
/*funcin de activacin tangente hiperblica */
public class TangenteHiperbolica extends FuncionActivacion implements Serializable{
/*constructor sin argumentos */
public TangenteHiperbolica () {
}
}
182
Package
Un package es una agrupacin de clases. Existen una serie de packages incluidos en el lenguaje.
Adems el programador puede crear sus propios packages. Todas las clases
que formen parte de un package deben estar en el mismo directorio.
Los packages se utilizan con las siguientes finalidades:
1. Para agrupar clases relacionadas.
2. Para evitar conflictos de nombres. En caso de conflicto de nombres
entre clases importadas, el compilador obliga a cualificar en el cdigo los
nombres de dichas clases con el nombre del package.
3. Para ayudar en el control de la accesibilidad de clases y miembros.
Por las razones citadas, durante la etapa de Diseo del Software desarrollado, se ha decido crear dos paquetes, calculos e interfase, utilizando la sentencia
package.
package myprojects.simu;
import myprojects.calculos.*;
import myprojects.interfase.*;
La Jerarqua de Clases de Java (API)

Durante la generacin de cdigo en Java, es recomendable y casi necesario
tener siempre a la vista la documentacin on-line del API de Java 1.1 o Java
1.2. En dicha documentacin es posible ver tanto la jerarqua de clases, es
decir la relacin de herencia entre clases, como la informacin de los distintos
packages que componen las libreras base de Java.
Es importante distinguir entre lo que significa herencia y package. Un
package es una agrupacin arbitraria de clases, una forma de organizar las
clases. La herencia sin embargo consiste en crear nuevas clases en base a otras
ya existentes. Las clases incluidas en un package no derivan en general de la
misma clase.
183
En la documentacin on-line se presentan ambas visiones: Package Index

y Class Hierarchy. La primera presenta la estructura del API de Java
agrupada por packages, mientras que en la segunda aparece la jerarqua de
clases. Hay que resaltar el hecho de que todas las clases en Java son derivadas
de la clase java.lang.Object, por lo que heredan todos los mtodos y variables
de sta.
Si se selecciona una clase en particular, la documentacin muestra una
descripcin detallada de todos los mtodos y variables de la clase. A su vez
muestra su herencia completa (partiendo de la clase java.lang.Object).
6.6.2
Variables Dentro del Lenguaje Java
Una variable en Java es un identificador que representa una palabra de memoria que contiene informacin. El tipo de informacin almacenado en una
variable slo puede ser del tipo con que se declar esa variable.
En Java hay dos tipos principales de variables:
1. Variables de tipos primitivos. Estn definidas mediante un valor nico
y almacenan directamente ese valor siempre que pertenezca al rango de
ese tipo. Por ejemplo una variable int almacena un valor entero como
1, 2, 0, -1, etc. Esto significa que al asignar una variable entera a otra
variable entera, se copia el valor de la primera en el espacio que ocupa
la segunda variable.
2. Variables referencia. Las variables referencia son referencias o nombres
de una informacin ms compleja: arrays u objetos de una determinada
clase. Una referencia a un objeto es la direccin de un rea en memoria
destinada a representar ese objeto. El rea de memoria se solicita con
el operador new. Al asignar una variable de tipo referencia a objeto a
otra variable se asigna la direccin y no el objeto referenciado por esa
direccin. Esto significa que ambas variables quedan referenciando el
mismo objeto. En Java una variable no puede almacenar directamente
un objeto, como ocurre en C y C++. Por lo tanto cuando se dice en
Java que una variable es un string, lo que se quiere decir en realidad es
que la variable es una referencia a un string.
Desde el punto de vista de su papel dentro del programa, las variables
pueden ser:
184
1. Variables miembro de una clase: Se definen en una clase, fuera de cualquier mtodo; pueden ser tipos primitivos o referencias.
2. Variables locales: Se definen dentro de un mtodo o ms en general
dentro de cualquier bloque entre llaves {}. Se crean en el interior del
bloque y se destruyen al finalizar dicho bloque. Pueden ser tambin tipos
primitivos o referencias.
En la tabla 6.1 de la pgina 184 se muestra una declaracin, el nombre de
la variable introducida y el tipo de informacin que almacena la variable.
Declaracin
int i;
String s;
int a [];
int[]b;
Identificador
i
s
a
b
Tipo
entero
referencia a string
referencia a arreglo de enteros
referencia a arreglo de enteros
Tabla 6.1: Tipos de Variables.

En la tabla 6.2 de la pgina 184 se muestran las dos grandes categoras de
tipos para las variables en Java.
Tipos Primitivos
int, short, byte, long
char, boolean
float, double
Referencias a Objetos
Strings
Arreglos
otros objetos
Tabla 6.2: Categoras de Variables.

En la tabla 6.3 de la pgina 185 se indica para cada tipo primitivo el
nmero de bits que se emplea en su representacin y el rango de valores que
se puede almacenar en las variables de estos tipos.
Se dice que un tipo A es de mayor rango que un tipo B si A es un superconjunto de B. Esto quiere decir que las variables de tipo B siempre se pueden
asignar a variables de tipo A (eventualmente con prdida de significancia).
Por ejemplo int es de mayor rango que short, que a su vez es de mayor
Tipo
int
short
byte
long
boolean
char
float
double
Bits
32
16
8
64
1
16
32
64
Rango
231 ..231 1
215 ..215 1
27 ..27 1
263 ..263 1
n/a
n/a
IEEE
IEEE
185
Ejemplos
0,1,5,-120,...
0,1,5,-120,...
0,1,5,-120,...
0,1,5,-120,...
false, true
a,A,0,*,...
1.2
1.2
Tabla 6.3: Tipos Primitivos de Variables.

rango que byte. Float y double son de mayor rango que int. Double es de
mayor rango que float.
Esto se puede quedar resumido de la siguiente manera:
double > float > long > int > short > byte
Visibilidad y Vida de las Variables

Se entiende por visibilidad, mbito o scope de una variable, la parte de la
aplicacin donde dicha variable es accesible y por lo tanto puede ser utilizada
en cualquier expresin. En Java todos las variables deben estar incluidas en
una clase. En general las variables declaradas dentro de unas llaves {}, es
decir dentro de un bloque, son visibles y existen dentro de estas llaves. Por
ejemplo las variables declaradas al principio de una funcin existen mientras
se ejecute la funcin; las variables declaradas dentro de un bloque if no sern
vlidas al finalizar las sentencias correspondientes a dicho if y las variables
miembro de una clase (es decir declaradas entre las llaves {} de la clase pero
fuera de cualquier mtodo) son vlidas mientras existe el objeto de la clase.
Las variables miembro de una clase declaradas como public son accesibles
a travs de una referencia a un objeto de dicha clase utilizando el operador
punto (.). Las variables miembro declaradas como private no son accesibles
directamente desde otras clases. Las funciones miembro de una clase tienen
acceso directo a todas las variables miembro de la clase sin necesidad de anteponer el nombre de un objeto de la clase. Sin embargo las funciones miembro
186
de una clase B derivada de otra A, tienen acceso a todas las variables miembro de A declaradas como public o protected, pero no a las declaradas como
private. Una clase derivada slo puede acceder directamente a las variables y
funciones miembro de su clase base declaradas como public o protected. Otra
caracterstica del lenguaje es que es posible declarar una variable dentro de un
bloque con el mismo nombre que una variable miembro, pero no con el nombre de otra variable local. La variable declarada dentro del bloque oculta a la
variable miembro en ese bloque. Para acceder a la variable miembro oculta
ser preciso utilizar el operador this.
Uno de los aspectos ms importantes en la programacin orientada a objetos (OOP) es la forma en la cual son creados y eliminados los objetos. La
forma de crear nuevos objetos es utilizar el operador new. Cuando se utiliza
el operador new, la variable de tipo referencia guarda la posicin de memoria
donde est almacenado este nuevo objeto. Para cada objeto se lleva cuenta
de por cuntas variables de tipo referencia es apuntado. La eliminacin de
los objetos la realiza el denominado garbage collector, quien automticamente
libera o borra la memoria ocupada por un objeto cuando no existe ninguna
referencia apuntando a ese objeto. Lo anterior significa que aunque una variable de tipo referencia deje de existir, el objeto al cual apunta no es eliminado
si hay otras referencias apuntando a ese mismo objeto.
6.6.3
Operadores en Java
Java es un lenguaje rico en operadores, que son casi idnticos a los de C/C++.
Estos operadores se describen brevemente a continuacin.
Operadores Aritmticos
Son operadores binarios (requieren siempre dos operandos) que realizan las
operaciones aritmticas habituales: suma (+), resta (-), multiplicacin (*),
divisin (/) y resto de la divisin (%).
Operadores de Asignacin
Los operadores de asignacin permiten asignar un valor a una variable. El
operador de asignacin por excelencia es el operador igual (=). La forma
187
general de las sentencias de asignacin con este operador es:

variable = expression;
Java dispone de otros operadores de asignacin. Se trata de versiones

abreviadas del operador (=) que realizan operaciones acumulativas sobre
una variable.
La siguiente tabla 6.4 de la pgina 187, muestra estos operadores y su
equivalencia con el uso del operador igual (=).
Operador
+=
-=
=*
=/
%=
Utilizacin
op1 + = op2
op1 - = op2
op1 * = op2
op1 / = op2
op1% = op2
ExpresinEquivalente
op1 = op1 + op2
op1 = op1 - op2
op1 = op1 * op2
op1 = op1 / op2
op1 = op1 % op2
Tabla 6.4: Operadores de Asignacin.
Operadores Unarios
Los operadores ms (+) y menos (-) unarios sirven para mantener o cambiar
el signo de una variable, constante o expresin numrica. Su uso en Java es
el estndar de estos operadores.
Operadores Incrementales
Java dispone del operador incremento (++) y decremento (). El operador
(++) incrementa en una unidad la variable a la que se aplica, mientras que ()
la reduce en una unidad. Estos operadores se pueden utilizar de dos formas:
1. Precediendo a la variable (por ejemplo: ++i). En este caso primero se
incrementa la variable y luego se utiliza (ya incrementada) en la expresin en la que aparece.
188
2. Siguiendo a la variable (por ejemplo: i++). En este caso primero se

utiliza la variable en la expresin (con el valor anterior) y luego se incrementa.
En muchas ocasiones estos operadores se utilizan para incrementar una
variable fuera de una expresin. En este caso ambos operadores son equivalente. Si se utilizan en una expresin ms complicada, el resultado de utilizar
estos operadores en una u otra de sus formas ser diferente. La actualizacin
de contadores en bucles for es una de las aplicaciones ms frecuentes de estos
operadores.
Operadores Relacionales
Los operadores relacionales sirven para realizar comparaciones de igualdad,
desigualdad y relacin de menor o mayor. El resultado de estos operadores
es siempre un valor boolean (true o false) segn se cumpla o no la relacin
considerada. La siguiente tabla 6.5 de la pgina 188 muestra los operadores
relacionales de Java.
Operador
>
>=
<
<=
==
! =
Utilizacin
op1 > op2
op1 >= op2
op1 < op2
op1 <= op2
op1 == op2
op1 != op2
El resultado es true
si op1 es mayor que op2
si op1 es mayor o igual que op2
si op1 es menor que op 2
si op1 es menor o igual que op2
si op1 y op2 son iguales
sio p1 y op2 son diferentes
Tabla 6.5: Operadores Relacionales.

Estos operadores se utilizan con mucha frecuencia en las bifurcaciones y
en los bucles, que se vern luego.
Ejemplo de Operadores Incrementales y Operadores Relacionales en un
mtodo.
public void cambiarParesEntrenamiento(double[ ] paresEntrenamiento){
189
/* inicializacin de sus valores a partir de los valores pasados como argumentos */

for(int i = 0; i< paresEntrenamiento.length; i++)
{for(int j = 0; j< numeroNeuronasEntrada; j++)
{entradaEntrenamiento[i][j] = paresEntrenamiento[i][j];
}
for(int j = 0; j< numeroSalidas; j++)
{salidaEntrenamiento[i][j] =
paresEntrenamiento[i][j+numeroNeuronasEntrada];
}
}
}
Operador de Concatenacin de Cadenas de Caracteres (+)

El operador ms (+) se utiliza tambin para concatenar cadenas de caracteres. Por ejemplo, para escribir una cantidad con un rtulo puede utilizarse la
sentencia:
editor.append(Error Obtenido: + String.valueOf(imprimoError) + \n);

editor.append(Iteraciones:+ String.valueOf(imprimoIteraciones) + \n);
editor.append(Inicio: + horaInicial.toString() + \n);
editor.append(Final: + horaFinal.toString() + \n);
Se observa que el operador de concatenacin se utiliza dos veces para construir la cadena de caracteres que se desea imprimir. Las variables imprimoErrror, imprimoIteraciones, horaInicial, horaFinal son convertidas en cadena
de caracteres para poder concatenarlas.
190
Precedencia de Operadores
El orden en que se realizan las operaciones es fundamental para determinar
el resultado de una expresin. Por ejemplo, el resultado de x/y*z depende de
qu operacin (la divisin o el producto) se realice primero. La tabla 6.6 de
la pgina 190 muestra el orden en que se ejecutan los distintos operadores en
una sentencia, de mayor a menor precedencia.
Nombre
Postfijos
Unarios
De creacin
Multiplicativo
Adicin
Shift
Relacional
Igualdad
AND
Or Excluyente
Or Incluyente
Logico AND
Logico OR
Condicional
Asignacin
Sintxis
[ ] .(params) expr++ expr++expr expr +expr -expr !
(type) expr
*/%
+<< >> >>>
<> <= >= instanceof
== ! =
&
^
|
&&
||
?:
= += -= *= /= %= &= ^= |= <<= >>= >>>=
Tabla 6.6: Precedencia de Operadores.
En Java, todos los operadores binarios, excepto los operadores de asignacin, se evalan de izquierda a derecha. Los operadores de asignacin se
evalan de derecha a izquierda, lo que significa que el valor de la izquierda se
copia sobre la variable de la derecha.
6.6.4
Estructuras de Programacin
Las estructuras de programacin o estructuras de control permiten tomar decisiones y realizar un proceso repetidas veces. Son los denominados bifurcaciones y bucles. En la mayora de los lenguajes de programacin, este tipo de
191
estructuras son comunes en cuanto a concepto, aunque su sintaxis vara de un

lenguaje a otro. La sintaxis de Java coincide prcticamente con la utilizada
en C/C++, lo que hace que para un programador de C/C++ no suponga
ninguna dificultad adicional.
Sentencias o Expresiones
Una expresin es un conjunto variables unidos por operadores. Son rdenes
que se le dan al computador para que realice una tarea determinada.
Una sentencia es una expresin que acaba en punto y coma (;). Se permite
incluir varias sentencias en una lnea, aunque lo habitual es utilizar una lnea
para cada sentencia. A continuacin se muestra un ejemplo de una lnea
compuesta de tres sentencias:
i = 0; j = 5; x = i + j;
Comentarios
Existen dos formas diferentes de introducir comentarios entre el cdigo de Java
(en realidad son tres, como pronto se ver). Son similares a la forma de realizar comentarios en el lenguaje C/C++. Los comentarios son tremendamente
tiles para poder entender el cdigo utilizado, facilitando de ese modo futuras
revisiones y correcciones. Adems permite que cualquier persona distinta al
programador original pueda comprender el cdigo escrito de una forma ms
rpida. Se recomienda acostumbrarse a comentar el cdigo desarrollado. De
esta forma se simplifica tambin la tarea de estudio y revisin posteriores.
Java interpreta que todo lo que aparece a la derecha de dos barras //
en una lnea cualquiera del cdigo es un comentario del programador y no
lo tiene en cuenta. El comentario puede empezar al comienzo de la lnea o
a continuacin de una instruccin que debe ser ejecutada. La segunda forma
de incluir comentarios consiste en escribir el texto entre los smbolos /* */
. Este segundo mtodo es vlido para comentar ms de una lnea de cdigo.
Por ejemplo:
// Esta lnea es un comentario
int a=1; // Comentario a la derecha de una sentencia
192
// Esta es la forma de comentar ms de una lnea utilizando

// las dos barras. Requiere incluir dos barras al comienzo de cada lnea
/* Esta segunda forma es mucho ms cmoda para comentar un nmero elevado de lneas ya que slo requiere modificar el comienzo y el final. */
En Java existe adems una forma especial de introducir los comentarios

(utilizando /***/ ms algunos caracteres especiales) que permite generar automticamente la documentacin sobre las clases y packages desarrollados por el
programador. Una vez introducidos los comentarios, el programa javadoc.exe
(incluido en el JDK) genera de forma automtica la informacin de forma similar a la presentada en la propia documentacin del JDK. La sintaxis de estos
comentarios y la forma de utilizar el programa javadoc.exe se puede encontrar
en la informacin que viene con el JDK.
Bifurcaciones
Las bifurcaciones permiten ejecutar una de entre varias acciones en funcin
del valor de una expresin lgica o relacional. Se tratan de estructuras muy
importantes ya que son las encargadas de controlar el flujo de ejecucin de un
programa. Se exponen dos variantes del de tipo if.
Bifurcacin If Esta estructura permite ejecutar un conjunto de sentencias
en funcin del valor que tenga la expresin de comparacin. Ejemplo: se
ejecuta si la expresin de comparacin (error < errorMinimo) tiene valor true:
protected void comprobarNuevoMinimo() {
if (error < errorMinimo)
{errorMinimo = error;
vectorDisMinimo = (double[ ])(vectorDis.clone());
} /* fin del if */
}
Las llaves {} sirven para agrupar en un bloque las sentencias que se han
de ejecutar, y no son necesarias si slo hay una sentencia dentro del if.
193
Bifurcacin If Else
Anloga a la anterior, de la cual es una ampliacin. Las sentencias incluidas
en el else se ejecutan en el caso de no cumplirse la expresin de comparacin
(false),
Ejemplo:
public double decirSalidaActual(int indiceEtapa) {
if(pila != null)
{return pila[indiceEtapa];}
else
{System.out.println(Fallo: Pila no creada);
return 0;
}
}
Bucles
Un bucle se utiliza para realizar un proceso repetidas veces. Se denomina
tambin lazo o loop. El cdigo incluido entre las llaves {} (opcionales si el
proceso repetitivo consta de una sola lnea), se ejecutar mientras se cumpla
unas determinadas condiciones. Hay que prestar especial atencin a los bucles
infinitos, hecho que ocurre cuando la condicin de finalizar el bucle (booleanExpression) no se llega a cumplir nunca. Se trata de un fallo muy tpico,
habitual sobre todo entre programadores poco experimentados.
Bucle While En el siguiente ejemplo se muestra que se ejecutar la sentencia fin++ mientras la expresin (capas.charAt(fin)!=, && capas.charAt(fin)!=1) sea verdadera.
for (int j=0; j < numeroCapas; j++)
{int fin = principio;
try {
while (capas.charAt(fin) != , && capas.charAt(fin) != -1)
194
{fin++;
}
}
}
Bucle For A continuacin se podr apreciar la utilizacin del bucle for:

/* calcular el nuevo vector de diseo */
for (int i = 0; i < vectorDis.length; i++)
{vectorDis[i] = vectorDis[i] + learningRate * S[i];
}
La sentencia int i = 0 (inicializacin) se ejecuta al comienzo del for, e

i++ (incremento) despus de vectorDis[i] = vectorDis[i] + learningRate * S[i]
(sentencia). La expresin booleana (vectorDis.length) se evala al comienzo
de cada iteracin; el bucle termina cuando la expresin de comparacin toma
el valor false.
Bucle do While Es similar al bucle while pero con la particularidad de que
el control est al final del bucle (lo que hace que el bucle se ejecute al menos
una vez, independientemente de que la condicin se cumpla o no). Una vez
ejecutados las sentencias, se evala la condicin: si resulta true se vuelven a
ejecutar las sentencias incluidas en el bucle, mientras que si la condicin se
evala a false finaliza el bucle.
do{
/* calcular el gradiente del vector fijar el vector de diseo */
problema.fijoVector(vectorDis);
/* incrementar el contador de iteraciones*/
step++;
} while (error > errorDeseado && step < iteracionesMaximas);
195
/* ... hasta que el error sea menor o igual que el deseado o */

/* se alcance el nmero de iteraciones pasado como argumento */
problema.fijoVector(vectorDis);
Sentencia Return Una forma de salir de un bucle es utilizar la sentencia

return. Esta sentencia sale tambin de un mtodo o de una funcin. En el
caso de que la funcin devuelva alguna variable, este valor se deber poner a
continuacin del return.
public double devuelveErrorMinimo()
{return errorMinimo;
}
Bloque Try{...} Catch{...} Finally{...} Java incorpora en el propio lenguaje la gestin de errores. El mejor momento para detectar los errores es
durante la compilacin. Sin embargo prcticamente slo los errores de sintaxis son detectados en esta operacin. El resto de los problemas surgen durante
la ejecucin de los programas.
En el lenguaje Java, una Exception es un cierto tipo de error o una condicin anormal que se ha producido durante la ejecucin de un programa.
Algunas excepciones son fatales y provocan que se deba finalizar la ejecucin
del programa. En este caso conviene terminar ordenadamente y dar un mensaje explicando el tipo de error que se ha producido. Otras excepciones, como
por ejemplo no encontrar un fichero en el que hay que leer o escribir algo,
pueden ser recuperables. En este caso el programa debe dar al usuario la
oportunidad de corregir el error (dando por ejemplo un nuevo path del fichero
no encontrado).
Los errores se representan mediante clases derivadas de la clase Throwable,
pero los que tiene que chequear un programador derivan de Exception (java.lang.Exception que a su vez deriva de Throwable). Existen algunos tipos
de excepciones que Java obliga a tener en cuenta. Esto se hace mediante el
uso de bloques try, catch y finally.
El cdigo dentro del bloque try est vigilado: Si se produce una situacin
anormal y se lanza como consecuencia una excepcin, el control pasa al bloque
196
catch que se hace cargo de la situacin y decide lo que hay que hacer. Se pueden
incluir tantos bloques catch como se desee, cada uno de los cuales tratar un
tipo de excepcin. Finalmente, si est presente, se ejecuta el bloque finally,
que es opcional, pero que en caso de existir se ejecuta siempre, sea cual sea el
tipo de error.
En el caso en que el cdigo de un mtodo pueda generar una Exception
y no se desee incluir en dicho mtodo la gestin del error (es decir los bucles
try/catch correspondientes), es necesario que el mtodo pase la Exception al
mtodo desde el que ha sido llamado. Esto se consigue mediante la adicin de
la palabra throws seguida del nombre de la Exception concreta, despus de la
lista de argumentos del mtodo. A su vez el mtodo superior deber incluir
los bloques try/catch o volver a pasar la Exception. De esta forma se puede ir
pasando la Exception de un mtodo a otro hasta llegar al ltimo mtodo del
programa, el mtodo main().
6.6.5
Clases en Java
Las clases son el centro de la Programacin Orientada a Objetos (OOP Object Oriented Programming). Algunos conceptos importantes de la POO
son los siguientes:
1. Encapsulacin: Las clases pueden ser declaradas como pblicas (public)
y como package (accesibles slo para otras clases del package). Las
variables miembro y los mtodos pueden ser public, private, protected
y package. De esta forma se puede controlar el acceso y evitar un uso
inadecuado.
2. Herencia: Una clase puede derivar de otra (extends), y en ese caso hereda
todas sus variables y mtodos. Una clase derivada puede aadir nuevas
variables y mtodos y/o redefinir las variables y mtodos heredados.
3. Polimorfismo: Los objetos de distintas clases pertenecientes a una misma
jerarqua o que implementan una misma interface pueden tratarse de
una forma general e individualizada, al mismo tiempo. Esto facilita la
programacin y el mantenimiento del cdigo.
Caractersticas Importantes de las Clases
197
A continuacin se enumeran algunas caractersticas importantes de las clases:

1. Todas las variables y funciones de Java deben pertenecer a una clase.
No hay variables y funciones globales.
2. Si una clase deriva de otra (extends), hereda todas sus variables y mtodos.
3. Java tiene una jerarqua de clases estndar de la que pueden derivar las
clases que crean los usuarios.
4. Una clase slo puede heredar de una nica clase (en Java no hay herencia
mltiple). Si al definir una clase no se especifica de qu clase deriva, por
defecto la clase deriva de Object. La clase Object es la base de toda la
jerarqua de clases de Java.
5. En un fichero se pueden definir varias clases, pero en un fichero no puede
haber ms que una clase public. Este fichero se debe llamar como la clase
public que contiene con extensin *.java. Con algunas excepciones, lo
habitual es escribir una sola clase por fichero.
6. Si una clase contenida en un fichero no es public, no es necesario que el
fichero se llame como la clase.
7. Los mtodos de una clase pueden referirse de modo global al objeto de
esa clase al que se aplican por medio de la referencia this.
8. Las clases se pueden agrupar en packages, introduciendo una lnea al
comienzo del fichero (package packageName;). Esta agrupacin en packages est relacionada con la jerarqua de directorios y ficheros en la que
se guardan las clases.
Mtodos o Funciones Miembros

Mtodos de Objeto Los mtodos son funciones definidas dentro de una
clase. Salvo los mtodos static o de clase, se aplican siempre a un objeto
de la clase por medio del operador punto (.). Dicho objeto es su argumento
implcito. Los mtodos pueden adems tener otros argumentos explcitos que
van entre parntesis, a continuacin del nombre del mtodo.
198
La primera lnea de la definicin de un mtodo se llama declaracin o

header; el cdigo comprendido entre las llaves {} es el cuerpo o body del
mtodo. Considrese el siguiente ejemplo:
imprimoError=algor.devuelveErrorMinimo();
public double devuelveErrorMinimo()
{return errorMinimo;
}
La Clase Object
Como ya se ha dicho, la clase Object es la raz de toda la jerarqua de clases
de Java. Todas las clases de Java derivan de Object.
La clase Object tiene mtodos interesantes para cualquier objeto que son
heredados por cualquier clase. Entre ellos se pueden citar los siguientes:
1. Mtodos que pueden ser redefinidos por el programador:
clone(): Crea un objeto a partir de otro objeto de la misma clase. El
mtodo original heredado de Object lanza una CloneNotSupportedException. Si se desea poder clonar una clase hay que implementar
la interface Cloneable y redefinir el mtodo clone(). Este mtodo
debe hacer una copia miembro a miembro del objeto original. No
debera llamar al operador new ni a los constructores.
equals(): Indica si dos objetos son o no iguales. Devuelve true si
son iguales, tanto si son referencias al mismo objeto como si son
objetos distintos con iguales valores de las variables miembro.
toString(): Devuelve un String que contiene una representacin del
objeto como cadena de caracteres, por ejemplo para imprimirlo o
exportarlo.
finalize(): Este mtodo ya se ha visto al hablar de los finalizadores.
2. Mtodos que no pueden ser redefinidos (son mtodos final ):
getClass(): Devuelve un objeto de la clase Class, al cual se le
pueden aplicar mtodos para determinar el nombre de la clase, su
199
super-clase, las interfaces implementadas, etc. Se puede crear un

objeto de la misma clase que otro sin saber de qu clase es.
notify(), notifyAll() y wait(): Son mtodos relacionados con los
threads (hilos).
Captulo 7
Software de Base
7.1
Globus Toolkit
Antes de comenzar la instalacin se han tenido en cuenta las siguientes consideraciones en cuento:
Hardware
El Globus Toolkit 3 a instalar est creado sobre Java y cdigo C para UNIX.
Por tanto se requerir de un hardware capaz de ejecutar esta plataforma. En
nuestro caso se ha optado por un PC basado en arquitectura Pentium con un
sistema operativo Linux. Considerando un espacio en disco de al menos 512
Mb.
Software
Globus Toolkit 4 tiene unas dependencias de software importantes. Para su
instalacin y ejecucin, la mquina necesita el software JDK 1.3.1 o superior,
recomendando disponer de la versin 1.4 como el usado en esta documentacin.En ambos casos, la raz del directorio del JDK ser referenciado por la
variable $JAVA_HOME.
Otro software necesario es Jakarta Ant 1.5 o superior, referenciando la raz
de su directorio en el sistema mediante la variable $ANT_HOME, y Jakarta
ORO. Jakarta Ant es un software imprescindible en la instalacin, que permite
crear y usar ficheros makefiles complejos y puede ser usado tanto en UNIX
como en Windows.
201
202
CAPTULO 7. SOFTWARE DE BASE
Por otra parte, Jakarta ORO es un complemento que le permite trabajar

con expresiones regulares a Ant y se instala copiando la librera jakarta-oro2.0.7.jar que se encuentra en la instalacin de Jakarta ORO, al directorio
$ANT_HOME/lib. Tambin se requiere es Junit 3.8.1, para ello tan slo se
debe de copiar en el directorio $ANT_HOME/lib el fichero junit.jar de dicho
software. En el caso de usar la versin 1.3.1 se necesita una instalacin de las
JAAS library por separado.
7.1.1
Instalacin
La instalacin se realizar sobre dos mquina, como ejemplo para la instalacin

slo se tendr en cuenta una de ellas, se necesitar entonces de un usuario
local que ser el encargado de instalar y administrar el software Globus, en
este ejemplo se usar el
usuario local globusad perteneciente al grupo local globus.
Es importante crear un grupo local slo para los administradores del software Globus, dado que permitir una mayor flexibilidad en la administracin.
Mientras no se indique lo contrario, todos los pasos se realizarn con el usuario
administrador de Globus.
Pasos a Seguir :
Crear el directorio gt4 y ponerle permisos para globus:
mkdir /opt/gt4
chown globus:globus /opt/gt4
Setear variables de entorno: mcedit /etc/profile
y agregar abajo las siguiente lneas:
export JAVA_HOME=/opt/java
export ANT_HOME=/opt/ant
export GLOBUS_LOCATION=/opt/gt4
export PATH=$PATH:$JAVA_HOME/bin:$ANT_HOME/bin
7.1. GLOBUS TOOLKIT
203
Loguearse como Globus e instalar Globus:

a. ir al directorio home del usuario globus
b. tar -zxvf /root/downloads/gt4.....tar.gz
c. entrar al directorio /home/globus/gt4....
d. tipear ./configure prefix=$GLOBUS_LOCATION
Ver fig. 7.1de la pg. 203.
Figura 7.1: Configuracin.
e. tipear make install (Ver fig. 7.2 de la pg.204 ).
f. tipear make (Ver fig. 7.3 de la pg. 204 ).
Una vez finalizada la misma, deber crear el Certificado de Autoridad

(CA).
204
Figura 7.2: Compilacin.
Figura 7.3: Instalacin.
7.2. SIMPLE CA
7.2
205
Simple CA
Una ves finalizada la instalacin del Globus Toolkit se debe llevar a cabo los
paso necesario para lograr la seguridad en nuestro grid.
Se utiliza como mtodo de seguridad al Simple CA. Consiste en certificar
usuarios y hosts del Grid mediante una Autoridad Certificante (AC). Esto es,
cada host y usuario que deseen utilizar algn servicio del Grid del proyecto
debe generar un certificado propio el cual ser firmado por la AC del proyecto.
La AC es un sistema de control centralizado para administrar certificados
digitales. Cada AC firma su propio certificado y ste es distribuido de manera
confiable.
Cada certificado posee:
Nombre (identifica a la persona o al objeto que el certificado representa)
Clave Pblica (perteneciente a la persona u objeto)
Identidad de la AC (que certifica que la clave pblica y la identidad
de la persona u objeto son correctas)
Firma digital de la AC
Cmo obtener un certificado?:
El usuario/host genera su propia clave pblica y privada con un
programa provisto por la AC
El usuario/host le enva a la AC las clave pblica generada para
que sta la firme
La AC:
confirma la identidad del usuario/host.
firma el certificado.
enva el certificado firmado al usuario/host.
Luego el usuario con estos certificados puede acceder a todos los servicios
del Grid a travs de un solo punto de validacin.
Cmo funciona GSI (Infraestructura de Seguridad del Grid)?:
206
Se debe conocer el nombre del certificado otorgado:

grid-cert-info -subject
Informarle a la gente que nos va a aceptar cul es nuestro nombre
de certificado para que ellos lo agreguen en sus propios files de
autorizacin:
/etc/grid-security/grid-mapfile
A partir del certificado recibido iniciar el proxy:
grid-proxy-init
grid-proxy-info subject
Cada persona que acepte nuestro certificado aceptar nuestro proxy,
solo se tiene que crear una vez y el mismo tendr un tiempo limitado
de vida.
Dnde se guardan los certificados de un Host?:
/etc/grid-security
hostcert_request.pem (0644 - clave pblica que se enva a la AC
para que la misma enve la clave pblica firmada).
hostcert.pem (0644 - clave pblica firmada).
hostkey.pem (0400 - clave privada).
Dnde se guardan los certificados de un usuario?:
$HOME/.globus
usercert_request.pem (0644 - idem host).
usercert.pem (0644 - idem host).
userkey.pem (0400 - idem host).
Quines utilizan estos certificados?:
7.2. SIMPLE CA
207
Todas las aplicaciones del Grid:

Para enviar a ejecutar procesos (condor-submit).
Para transferir archivos (GRAM, GridFTP, RLS, etc.).
Para consultar servicios de informacin.
Procedimiento para crear una Autoridad Certificante

Requisitos
Instalar Globus Toolkit
Actores
root
globus
Obtencin de la Autoridad Certificate 1. Ejecutar, como usuario GLOBUS, el siguiente script:
globus@lsc:~$ $GLOBUS_LOCATION/setup
/globus/setup-simple-ca
WARNING: GPT_LOCATION not set, assuming:
GPT_LOCATION=/opt/gt4
CertificateAuthoritySetup
This script will setup a Certificate Authority for signing Globus

users certificates. It will also generate a simple CA package
that can be distributed to the users of the CA.
208
The CA information about the certificates it distributes will

be kept in:
/home/globus/.globus/simpleCA/
The unique subject name for this CA is:
cn=Globus Simple CA, ou=simpleCA-caro, ou=GlobusTest, o=Grid
Do you want to keep this as the CA subject (y/n) [y]: y
Enter the email of the CA (this is the email where certificate

requests will be sent to be signed by the CA): aguicaro@hotmail.com
The CA certificate has an expiration date. Keep in mind that
once the CA certificate has expired, all the certificates
signed by that CA become invalid. A CA should regenerate
the CA certificate and start re-issuing ca-setup packages
before the actual CA certificate expires. This can be done
by re-running this setup script. Enter the number of DAYS
the CA certificate should last before it expires.
[default: 5 years (1825 days)]:
Enter PEM pass phrase: XXXXX
Verifying - Enter PEM pass phrase: XXXXX
7.2. SIMPLE CA
creating CA config package...done.

A self-signed certificate has been generated
for the Certificate Authority with the subject:
/O=Grid/OU=GlobusTest/OU=simpleCA-caro/OU=dc.uba.ar
/CN=Globus Simple CA
If this is invalid, rerun this script
/opt/gt4/setup/globus/setup-simple-ca
and enter the appropriate fields.
The private key of the CA is stored in

/home/globus/.globus/simpleCA/private/cakey.pem
The public CA certificate is stored in

/home/globus/.globus/simpleCA/cacert.pem
The distribution package built for this CA is stored in

globus_simple_ca_fc935898_setup-0.18.tar.gz
This file must be distributed to any host wishing to request

certificates from this CA.
CA setup complete.
209
210
The following commands will now be run to setup the security

configuration files for this CA:
$GLOBUS_LOCATION/sbin/gpt-build \
globus_simple_ca_fc935898_setup-0.18.tar.gz
$GLOBUS_LOCATION/sbin/gpt-postinstall
setup-ssl-utils: Configuring ssl-utils package

Running setup-ssl-utils-sh-scripts...
********************************************************
Note: To complete setup of the GSI software you need to run the
following script as ROOT to configure your security configuration
directory:
/opt/gt4/setup/globus_simple_ca_fc935898_setup/setup-gsi
For further information on using the setup-gsi script, use the -help
option. The -default option sets this security configuration to be
the default, and -nonroot can be used on systems where root access is
not available.
*********************************************************
setup-ssl-utils: Complete
2. Finalizar como usuario ROOT la configuracin del GSI
globus$ su -
7.2. SIMPLE CA
211
root# export GLOBUS_LOCATION=/opt/gt4

root# /opt/gt4/setup/globus_simple_ca_fc935898_setup/setup-gsi
setup-gsi: Configuring GSI security
Making /etc/grid-security...
mkdir /etc/grid-security
Making trusted certs directory: /etc/grid-security/certificates/
mkdir /etc/grid-security/certificates/
Installing /etc/grid-security/certificates/grid-security.conf.fc935898...
Running grid-security-config...
Installing Globus CA certificate into trusted CA certificate directory...
Installing Globus CA signing policy into trusted CA certificate directory...
setup-gsi: Complete
Procedimiento para certificar un HOST/USUARIO
Requisitos
Instalar Globus Toolkit.
Obtener el programa para generar claves de la AC del Grid al que se
quiere acceder.
Datos
Host a certificar: master.
Usuario a certificar: mcarri.
Autoridad certificante: lsc.dc.uba.ar.
Script /opt/ gt4/ sbin/ gpt-build globus_simple_ca_fc935898_setup0.18.tar.gz.
212
Actores
root (de la AC).
globus (usuario administrador de la AC).
usuario (mcarri).
Pasos en comn para certificar Usuarios o Hosts 1. Como usuario
GLOBUS del host master pedir a la AC el script para generar claves (en este
caso como se tiene acceso a la AC se copia remotamente).
2. Instalar el programa certificador en el host master.
/opt/gt4/sbin/gpt-build globus_simple_ca_fc935898_setup-0.18.tar.gz
/opt/gt4/sbin/gpt-postinstall
running /opt/gt4/setup/globus/./setup-ssl-utils.fc935898..
[ Changing to /opt/gt4/setup/globus/. ]
setup-ssl-utils: Configuring ssl-utils package
Running setup-ssl-utils-sh-scripts...
*********************************************************
Note: To complete setup of the GSI software you need to run the
following script AS ROOT to configure your security configuration
directory:
/opt/gt4/setup/globus_simple_ca_fc935898_setup/setup-gsi
For further information on using the setup-gsi script, use the -help
option. The -default option sets this security configuration to be
the default, and -nonroot can be used on systems where root access is
not available.
*********************************************************
7.2. SIMPLE CA
213
setup-ssl-utils: Complete
..Done
WARNING: The following packages were not set up correctly:
globus_simple_ca_fc935898_setup-noflavor-pgm
Check the package documentation or run postinstall -verbose to see
what happened
3. Completar la configuracin como usuario ROOT.
su /opt/gt4/setup/globus_simple_ca_fc935898_setup/setup-gsi
setup-gsi: Configuring GSI security
Making /etc/grid-security...
mkdir /etc/grid-security
Making trusted certs directory: /etc/grid-security/certificates/
mkdir /etc/grid-security/certificates/
Installing /etc/grid-security/certificates//grid-security.conf.fc935898...
Running grid-security-config...
Installing Globus CA certificate into trusted CA certificate directory...
Installing Globus CA signing policy into trusted CA certificate directory...
setup-gsi: Complete
4. Certificacin del HOST master como usuario ROOT.
4.1. Como usuario ROOT en el host master ejecutar:
grid-cert-request -host master
A private host key and a certificate request has been generated
with the subject:
214
/O=Grid/OU=GlobusTest/OU=simpleCA-lsc.dc.uba.ar/CN=host/master
The private key is stored in /etc/grid-security/hostkey.pem
The request is stored in /etc/grid-security/hostcert_request.pem
Please e-mail the request to the Globus Simple CA dfslezak@dc.uba.ar
You may use a command similar to the following:
cat /etc/grid-security/hostcert_request.pem | mail dfslezak@dc.uba.ar
Only use the above if this machine can send AND receive e-mail. if not,
please
mail using some other method.
Your certificate will be mailed to you within two working days.
If you receive no response, contact Globus Simple CA at
dfslezak@dc.uba.ar
4.2. Como autoridad certificante de la mquina lsc.dc.uba.ar, usuario
GLOBUS, se firma el certificado.
ssh globus@lsc.dc.uba.ar
globus@lsc$ cd /tmp
globus@lsc$ grid-ca-sign -in hostcert_request.pem -out hostsigned.pem
To sign the request
please enter the password for the CA key:
The new signed certificate is at: /home/globus/
.globus/simpleCA//newcerts/15.pem
4.3. Desde el host master, se toma el certificado ya firmado del lsc.dc.uba.ar
y se ubica en /etc/ grid-security/
(en un caso normal este archivo tambin se recibe por mail desde la autoridad certificante).
7.2. SIMPLE CA
215
root# cd /etc/grid-security
root# scp globus@lsc.dc.uba.ar:/tmp/hostsigned.pem ./hostcert.pem
root# chown root.root /etc/grid-security/hostcert.pem
root# chmod 0400 /etc/grid-security/hostkey.pem
4.4. Limpiar el directorio /tmp en el servidor lsc.dc.uba.ar.
5. Certificacin del USUARIO mcarri.
5.1. Se ejecuta como usuario mcarri el script grid-cert-request.
[mcarri@master mcarri]$ grid-cert-request -force -cn Carolina Leon Carri
/home/mcarri/.globus/usercert_request.pem already exists
/home/mcarri/.globus/usercert.pem already exists
/home/mcarri/.globus/userkey.pem already exists
A certificate request and private key is being created.
You will be asked to enter a PEM pass phrase.
This pass phrase is akin to your account password,
and is used to protect your key file.
If you forget your pass phrase, you will need to
obtain a new certificate.
Generating a 1024 bit RSA private key
............++++++
..++++++
writing new private key to /home/mcarri/.globus/userkey.pem
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
A private key and a certificate request has been generated with the subject:
216
/O=Grid/OU=GlobusTest/OU= simple CA-lsc.dc.uba.ar/CN=Carolina Leon

Carri
If the CN=Carolina Leon Carri is not appropriate, rerun this
script with the -force -cn Common Name options.
Your private key is stored in /home/mcarri/.globus/userkey.pem
Your request is stored in /home/mcarri/.globus/usercert_request.pem
Please e-mail the request to the Globus Simple CA dfslezak@dc.uba.ar
You may use a command similar to the following:
cat /home/mcarri/.globus/usercert_request.pem | mail dfslezak@dc.uba.ar
Only use the above if this machine can send AND receive e-mail. if not,
please
mail using some other method.
Your certificate will be mailed to you within two working days.
If you receive no response, contact Globus Simple CA at dfslezak@dc.uba.ar
5.2. Se enva el certificado para firmar a la AC del lsc.dc.uba.ar (en este
caso se copia con scp, si no se enva por mail).
< br>$ scp usercert_request.pem globus@lsc.dc.uba.ar:/tmp
Password:
usercert_request.pem 100% 1396 2.4MB/s 00:00
5.3. Como autoridad certificante de lsc.dc.uba.ar, usuario globus, se firma
el certificado del usuario Carolina Aguilar.
ssh globus@lsc.dc.uba.ar
cd /tmp
grid-ca-sign -in usercert_request.pem -out usersigned.pem
To sign the request
7.2. SIMPLE CA
217
please enter the password for the CA key:

The new signed certificate is at: /home/globus/.globus/simpleCA//
newcerts/16.pem
Nota: Tambin queda en /tmp/usersigned.pem
5.4. Se toma el certificado firmado desde el host master como usuario
mcarri y se deja en $HOME/.globus
cd .globus.
scp globus@lsc.dc.uba.ar:/tmp/usersigned.pem ./usercert.pem
5.5. Limpiar el directorio temporal en lsc.dc.uba.ar.
globus@lsc$ cd /tmp
globus@lsc:/tmp$ rm usercert_request.pem usersigned.pem
6. Agregar el nuevo usuario en el grid-mapfile de la autoridad certificante
lsc.dc.uba.ar para que pueda acceder a servicios de dicha mquina.
El archivo /etc/grid-security/grid-mapfile se edita como root.
Este archivo tendr la equivalencia entre el nombre que figura en el certificado y el nombre unix de usuario.
ssh root@lsc.dc.uba.ar
cd /etc/grid-security
vi grid-mapfile
Importante:
Para saber el nombre que figura en el certificado, ejecuar como el
usuario de interes:
grid-cert-info -subject
Para saber el nombre de usuario unix, ejecutar como el usuario:
whoami
218
Ejemplo de una entrada en el archivo grid-mapfile:

/O=Grid/OU=GlobusTest/OU=simpleCA-lsc.dc.uba.ar/CN=Carolina Aguilar mcarri
7. Para verficiar que todo este bien, ejecutar en el master como usuario
mcarri:
grid-proxy-init -debug -verify
User Cert File: /home/mcarri/.globus/usercert.pem
User Key File: /home/mcarri/.globus/userkey.pem
Trusted CA Cert Dir: /etc/grid-security/certificates
Output File: /tmp/x509up_u501
Your identity: /O=Grid/OU=GlobusTest/OU=simpleCA-lsc.dc.uba.ar/
CN=Carolina Leon Carri
Enter GRID pass phrase for this identity:
Creating proxy .......................++++++++++++
.++++++++++++
Done
Proxy Verify OK
Your proxy is valid until: Tue Apr 25 04:38:53 2006
8. Finalmente se prueba el GridFTP desde el host master como usuario
mcarri
globus-url-copy gsiftp://lsc.dc.uba.ar/etc/group file:///home/ mcarri/ tmp/
borrar
Captulo 8
Descripcin de la Aplicacin
8.1
Descripcin General
El presente trabajo se basa en el estudio el Grid Computing y el software de

base
Globus Toolkit, que permite el desarrollo de servicios grid, para cliente
Web con base de datos distribuida.
El trabajo consta de tres pasos que se detallan a continuacin:
Instalacin y Configuracin del Software de base.
Creacin del Cliente Web.
Creacin del Servicio Grid.
Teniendo en cuenta que la instalacin ya se ha realizado para ambas mquinas que conforman este mini-grid, se detallarn los pasos necesarios para hacer
funcional dicho Grid.
8.1.1
Creacin del Cliente Web
El objetivo es realizar un cliente Web desarrollado en Java, en el cual el usuario

(personal de alumnado) pueda contar con un medio de ayuda para saber que
219
220
CAPTULO 8. DESCRIPCIN DE LA APLICACIN
Figura 8.1: Cliente Web

utilidades brinda este mini-grid. De esta manera el usuario incrementar su
productividad, reduciendo los tiempos de respuesta en la bsqueda realizada.
En la siguiente fig. 8.1 de la pg. 220 se puede observar la pgina principal
cliente Web, perteneciente al rea de alumnado de la Facultad de Ciencias
Exactas,Naturales y Agrimensura.
Mdulos del cliente:
El cliente Web consiste en dos mdulos sencillos:
Ayuda.
Buscador (Acceso a Internet)1 .
1
El cdigo completo del cliente web y de la aplicacin se encuentra en el DVD adjunto al

libro.
8.1. DESCRIPCIN GENERAL
Figura 8.2: Cliente Web
221
222
8.1.2
Creacin del Servicio Grid
En cuanto al objetivo de realizar un servicio Grid desarrollado tambin en Java

y de manera automtica, es para construir un servicio que pueda ser accedido
travs de una URL. En trminos simples un servicio Grid es una aplicacin
que se llama usando dicha direccin, pasando parmetros XML.
La generacin automtica de los archivos a travs de la herramienta permitir la creacin del GAR, es decir del servicio Grid funcional.
8.1.3
Ejemplos del Cdigo Fuente del Servicio
deploy-server.wsdd:
<?xml version=1.0 encoding=UTF-8?>
<deployment name=defaultServerConfig
xmlns=http://xml.apache.org/axis/wsdd/
xmlns:java=http://xml.apache.org/axis/wsdd/providers/ java
xmlns:xsd=http://www.w3.org/2001/XMLSchema>
<service name=examples/ProvisionDirService provider = Handler
use=literal style=document>
<parameter name=className value = org.merrill.examples. services.
provisiondir. impl. ProvisionDirService/>
<wsdlFile>share/schema/ examples/ ProvisionDirService/ ProvisionDir
_ service.wsdl< / wsdlFile>
<parameter name=allowedMethods value = */>
<parameter name=handlerClass value = org. globus. axis. providers.
RPCProvider/>
<parameter name=scope value = Application/>
<parameter name=providers value = GetRPProvider Destroy Provider />
<parameter name=loadOnStartup value =true/>
223
</service>
</deployment>
deploy-jndi-config.xml:
<?xml version=1.0 encoding=UTF-8?>
<jndiConfig xmlns=http://wsrf.globus.org/jndi/config>
<service name=examples/ProvisionDirService>
<resource name=home type= org. globus. wsrf. impl. Service Resource Home>
<resourceParams>
<parameter>
<name>factory</name>
<value>org.globus.wsrf.jndi.BeanFactory</value>
</parameter>
</resourceParams>
</resource>
</service>
</jndiConfig>
ProvisionDirQNames.java:
package org.merrill.examples.services.provisiondir.impl;
import javax.xml.namespace.QName;
public interface ProvisionDirQNames {
public static final String NS = http://examples.merrill.org/provisiondir/
ProvisionDirService;
224
public static final QName RESOURCE_PROPERTIES = new QName

(NS,
ProvisionDirResourceProperties);
public static final QName RESOURCE_REFERENCE = new QName
(NS,
ProvisionDirResourceReference);
/* Insert ResourceProperty Qnames here. */
public static final QName RP_CWD = new QName (NS, Cwd);

}
ProvisionDirService.java:
package org.merrill.examples.services.provisiondir.impl;
import java.rmi.RemoteException;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
import org.globus.wsrf.Resource;
import org.globus.wsrf.ResourceProperties;
import org.globus.wsrf.ResourceProperty;
import org.globus.wsrf.ResourcePropertySet;
import org.globus.wsrf.impl.ReflectionResourceProperty;
import org.globus.wsrf.impl. SimpleResourcePropertySet;
import org.merrill.examples.provisiondir. ProvisionDirService. ChangeC-
225
wdResponse;
import org.merrill.examples.provisiondir. ProvisionDirService. ListDirArrayResponse;
public class ProvisionDirService implements Resource, ResourceProperties
{
/* Resource Property set */
private ResourcePropertySet propSet;
/* Insert resource properties here. */
private String cwd;
/* Constructor. Initializes RPs */

public ProvisionDirService()
throws RemoteException {
this.propSet = new SimpleResourcePropertySet(

ProvisionDirQNames.RESOURCE_PROPERTIES);
try {
/* Initialize Resource Properties here.*/
ResourceProperty cwdRP = new ReflectionResourceProperty(
ProvisionDirQNames.RP_CWD,
Cwd,
this);
this.propSet.add(cwdRP);
setCwd(/root/workspace);
226
} catch (Exception e) {
throw new RuntimeException(e.getMessage());
}
}
throw new RuntimeException(e.getMessage());
}
}
public ListDirArrayResponse listDir() throws RemoteException {
//java.io.File currentDir = new java.io.File(cwd);
//List listaAlumnos = new ArrayList();
///listaAlumnos.add(Pepe);
String[] alumnos;
try {
int cantidad=0;
Class.forName(com.mysql.jdbc.Driver);
Connection conn = DriverManager.getConnection (jdbc:mysql:// localhost:3306/ alumno,root, );
Statement stm = conn.createStatement();
ResultSet rs = stm.executeQuery (SELECT count(*) as cantidad from
unne);
227
if(rs.next())
cantidad = rs.getInt(cantidad);
alumnos = new String[cantidad];
rs = stm.executeQuery(SELECT * from unne);

int i=0;
while(rs.next()){
alumnos[i]=rs.getString (anio_in) + @ + rs.getString (carrera)
+ @ + rs.getString(sexo) + @ + rs.getString (luniv) +
@ + rs.getString (domiciliop);
i++;
}
throw new RemoteException (Error: + e.getMessage());
}
return new ListDirArrayResponse(alumnos);

}
public ListDirArrayResponse listA() throws RemoteException {

//java.io.File currentDir = new java.io.File(cwd);
228
//List listaAlumnos = new ArrayList();

///listaAlumnos.add(Pepe);
String[] alumnos;
try {
int cantidad=0;
Class.forName(com.mysql.jdbc.Driver);
Connection conn = DriverManager.getConnection (jdbc:mysql:// localhost:3306/ alumno,root, );
Statement stm = conn.createStatement();
ResultSet rs = stm.executeQuery (SELECT count(*) as cantidad from
unne);
if(rs.next())
cantidad = rs.getInt(cantidad);
alumnos = new String[cantidad];
rs = stm.executeQuery(SELECT luniv from unne);

int i=0;
while(rs.next()){
alumnos[i]=rs.getString(luniv);
i++;
}
229
throw new RemoteException(Error: + e.getMessage());
}
return new ListDirArrayResponse(alumnos);

}
public ChangeCwdResponse changeCwd (String newCwd) throws RemoteException {

setCwd(newCwd);
return new ChangeCwdResponse();
}
/* Insert get/setters for Resource Properties here.*/
public String getCwd() {
return cwd;
}
public void setCwd(String cwd) {
this.cwd = cwd;
}
/* Required by interface ResourceProperties */

public ResourcePropertySet getResourcePropertySet() {
return this.propSet;
}
230
Captulo 9
Conclusiones
9.1
Conclusiones Acerca del Software Utilizado
Se ha podido comprobar las grandes ventajas de la utilizacin del software

Globus Toolkit v.4 , el cual permite la aplicacin (servicios grid) de los conceptos del Grid.
La contribucin de tecnologas adicionales ha permitido desarrollar un
cliente Web con WebSphere Application Developer v5.1.2 y MySQL , bajo
Linux SuSe 8.2, utilizando Java v.1.4, esto ha dado como resultado el cliente
Web sencillo, eficiente y sobre todo totalmente transparente.
Otras facilidades otorgadas por tecnologas adicionales como Sun Java SDK
V1.4.2 , Eclipse IDE, Sysdeo Eclipse Tomcat Launcher Plug-in V3.0, globusbuild-service (GT4), en configuracin y coordinacin con el Globus Toolkit v4
ha dado como resultado los servicios Grid (GAR).
La creacin del cliente Web como el servicio Grid, fueron la bases para
lograr el objetivo inicial, la construccin de un mini-Grid distribuido (ver fig.
9.1 de la pg. 232); se puede comprobar que el cliente ver atendidas sus
peticiones gracias al servicio grid, ofrecido por el Globus Toolkit.
Se destaca la potencialidad de esta tecnologa que emerge, ya que brinda
a quien la utiliza la resolucin de tareas complejas e intensivas, imposibles de
ser resueltas por una nica mquina.
Es por ello que distintas Universidades estn interesadas y en plena inves231
232
CAPTULO 9. CONCLUSIONES
Figura 9.1: Grid Computing.

tigacin, porque aunque existan muchos mini-grids, no est lejano el da en
que se logre un grid mundial donde los usuarios se conecten y accedan a toda
la potencia que requieran.
Asimismo se pudo apreciar las facilidades del Scientific WorkPlace para
escribir libros, por la calidad del producto obtenido, la automatizacin en el
manejo de ndices, la gestin dinmica de espacios, listas de figuras, de tablas,
referencias dinmicas a objetos, bibliografa, etc.
Lneas futuras de accin:
Si bien la potencialidad de las tecnologas analizadas es amplia, se han
identificado las siguientes lneas futuras de accin como prioritarias:
Simulacin, proceso de calculo numrico, de anlisis de datos.
Tratamiento de imgenes para la visin artificial.
Generacin de entornos virtuales 3D distribudos.
GridFTP, etc.
Bibliografa
[1] L. Joyanes Aguilar. Cibersociedad. Mac Graw-Hill, 1997.
[2] Viktors Berstis. Fundamentals of Grid Computing. IBM, USA, 2002.
[3] James A. O Brien. Sistemas de Informacin Gerencial. Editorial Nomos
S.A., Argentina, 2003.
[4] Arun K. Iyengar Marcos Novaes Li Zhang Catherine H. Crawford, Daniel
M. Dias. Commercial Applications of Grid Computing. IBM, USA, 2003.
[5] H.imrod D. Abramson, R. Giddy Sosic. The Grid: Blueprint for a New
Computing Infrastructure. IEEE, USA, 1995.
[6] A. Gonzlez del Alba Baraja; V. Yague Galaup; L. Joyanes Aguilar. Impacto de las Tecnologas en la Gestin de los Sistemas de Informacin en
II Congreso Internacional de Sociedad de la Informacin y del Conocimiento. McGraw Hill, Madrid-Espaa, 2003.
[7] Matt Haynos. The Physiology of the Grid:A visual of Open Grid Services
Architecture. IBM, 2003.
[8] C. Kesselman I. Foster. The Grid: Blueprint for a New Computing Infrastructure. 1998.
[9] J.ick S. Tuecke I. Foster, C. Kesselman. The Physiology of the Grid:
An Open Grid Services Architecture for Distributed Systems Integration.
Global Grid Forum, USA, 2002.
[10] R. Gutierrez I. Foster B. Ginsburg O. Larsson I. Lopez, G. Follen. Using
CORBA and Globus to Coordinate Multidisciplinary Aeroscience Applications. NASA, USA, 2000.
[11] T. Durniak P. Herman J. Karuturi C. Woods C. Gilman J. Barry, M. Aparicio. Enterprise Distributed Computing Workshop. IEEE, USA, 1998.
233
234
BIBLIOGRAFA
[12] H. Bivens S. Humphreys R. Rhea J. Beiriger, W. Johnson. Constructing

the ASCI Grid. IEEE, USA, 2000.
[13] Q. Peng D.P. Schissel M. Thompson I. Foster M. Greenwald D. McCune
K. Keahey, T. Fredian. The Anatomy of the Grid: Enabling Scalable
Virtual Organizations. 2002.
[14] MIT. Technology Review. MIT, USA, 2004.
[15] S. Mullender. The Physiology of the Grid:Distributed Systems. IBM, 2003.
[16] Moore Chung Bowen Nick, J.M. The Physiology of the Grid:Cluster Technology. IBM, 2003.
[17] A. Keahey K. Kohn S. McInnes S. Parker R. Armstrong, D. Geist Gannon.
The Grid: Blueprint for a New Computing Infrastructure. IEEE, USA,
1999.
[18] I. Foster C. Kesselman S. Tuecke J. Volmer V. Welch R. Butle, D. Engert.
Design and Deployment of a National - Scale Authentication Infrastructure. IEEE, USA, 2000.
[19] Jay Unger. The Physiology of the Grid:A visual of Open Grid Services
Architecture. IBM, 2003.
[20] A. Skjellum W. Gropp, E. Lusk. Portable Parallel Programming with the
Message Passing Interface. IEEE, USA, 1994.
[21] Colin J. White. IBM Enterprise Analytics for the Intelligent e-Business.
IBM Press, USA, 2001.
ndice de Materias
AFS, 26
ambiente hosting
rol, 89
API (Application Programming Interface), 182
Aplicaciones del Grid Computing
Entornos Virtuales, 6
Proceso Intensivo de Datos, 6
Servicios Puntuales, 6
Sistemas Distribuidos en Tiempo Real, 6
Supercomputacin Distribuida,
4
Aplicaciones y Servicios, 11
GridSystems, 12
HP, 11
Sun, 11
Appletalk
Appletalk, 112
Applets
contenedor de, 155
applets, 159
arquitectura de grid
semnticas de servicio, 85
arquitecturas
tres niveles de, 156
Autoridad Certificante, 205
bifurcaciones, 192
if, 192
if else, 193
bloque try, catch, finally, 195
browsers, 159
bubbled up, 38
bucles, 193
do while, 194
for, 194
while, 193
C/C++, 191
certificado de autoridad, 51
Clase, 180
clase
caractersticas, 196
clase en Java, 196
clase object, 198
clases de grid services, 71
grid data service, 71
servicios de ejecucin de programas de grid, 71
Clientes POP
Clientes POP, 113
Comandos para Internet, 131
Comando ftp, 132
Comando telnet, 132
Protocolos Internet (IP), 131
comentarios, 191
computacin negocio a negocio, 77
concepos y componentes
trabajos y aplicaciones, 30
B2B, 78, 148

B2C, 148
bibliotecas
de clases, 175
235
236
conceptos y componentes, 24
almacenamientos, 26
Comunicaciones, 28
comunicaciones
externa, 28
interna, 28
equipos,capacidades,arquitecturas
y polticas, 29
software y licencias, 28
tipos, 25
computacin, 25
configuracin de datos, 46
contenedor
cliente de aplicaciones de, 154
EJB de, 153
Web, 154
Content-Type, 163
core dumps
core dumps, 111
cpu paralela, 17
algoritmos, 17
primer barrera, 18
segunda barrera, 18
Data Striping, 27
destroy, 166
DFS, 26
DHTML, 160
digitales
activos, 149
doGet, 162
doGet (), 164
doPost (), 164
download, 149
e-commerce, 147
Ejecucin de Programas, 128
Comando time, 128
Comando top, 129
ejemplo de
NDICE DE MATERIAS
bifurcacin if, 192

bifurcacin if else, 193
bucle for, 194
bucle while, 193
clase, 180
comentario, 191
do while, 194
interface, 181
lnea compuesta por tres sentencias, 191
mtodo, 198
operadores incrementales y relacionales, 188
sentencia return, 195
encapsulacin, 196
enterprise beans, 153
Enterprise Computing
evolucin, 75
escalabilidad, 25
estndares, 57
ciclo de vida, 58
descubrimiento, 58
fbrica, 58
Grid Services, 58
invocacin fiable, 59
notificacin, 58
OGSA, 59
OGSI, 59
registro, 58
Web Services, 57
estructuras de programacin, 190
expresin, 191
find/setservice data porttype, 65
FPU
FPU, 112
FTP, 50
gar, 231
GGF, 60, 68
NDICE DE MATERIAS
Globus, 66, 202

Globus Project, 2
Globus Toolkit, 78
GNU
Licencia GNU, 108
GPFS, 26
GRAM, 78
Grid Computing, 1
Arquitectura, 8
Conectividad, 9
Infraestructura, 9
Recurso, 10
Recursos, 11
Beneficios, 1
concepto, 1
grid computing
componentes, 36
administracin del grid distribuido, 39
cominicaciones, 41
de administracin, 37
observacin, direccin y medicin, 41
schedulers, 40
software de sumisin, 39
software sevidor, 37
construccin, 35
grid de datos
capacidades, 19
grid service handle, 65
grid service reference, 65
grid services
Mecanismos Adicionales, 100
Ciclo de Vida, 103
Notificacin, 102
Servicio de Datos, 101
Servicio de Nombres, 100
GSH, 58
GSI, 78, 80, 205
237
GSS-API, 80
GUI, 44, 154
hardware, 201
herencia, 181, 182, 196
heursticas, 32
HTML, 159
HttpServletRequest, 162
HttpServletResponse, 163
IDE, 160
INIT, 163, 164
instalacin
del software, 202
instanciacin e inicializacin, 164
interface, 181
intragrid a intergrid, 32
compatimiento de archivos, 32
IT, 23, 152
J2EE, 66, 151
Java, 175, 176
caractersticas, 176
conceptos, 174
conceptos bsicos, 180
estructura general de un programa, 179
flexibilidad de, 177
introduccin a, 174
Jerarqua de clases en, 182
javax.servlet.HttpServlet, 162
JCA, 152
JDBC, 155, 159
JDK, 192
JNDI, 155
JSP, 154
compilacin batch de, 168
modelos de, 166
procesadores, 167
JSPs, 160
JVM, 153
238
KDE, 114
Administracin de Archivos. Kfm,
116
Asociar un Nuevo Tipo de Archivo, 119
Borrar un Directorio, 117
Copiar y Mover un Directorio, 118
Crear un Nuevo Directorio,
117
Directorios y Contenido de Ficheros, 116
Enlaces de KDE, 118
Propiedades de un Fichero,
120
Aplicaciones Auxiliares, 120
kdehelp, 122
kedit, 121
Kfind, 123
konsole, 121
kwrite, 122
Configuracin de KDE, 124
tilde nadir Aplicaciones al Panel, 126
Editor de Mens, 124
KDE Control Center, 126
Otras Aplicaciones, 127
Partes de la Pantalla, 114
Escritorio, 115
Panel de KDE, 115
Panel de ventanas, 115
X Windows, 115
Kerberos, 80
Licencia GPL
Licencia GPL, 109
Linux
Caractersticas Principales, 111
Instalacin, 133, 137
Arranque de Linux, 133
NDICE DE MATERIAS
Dispositivos y Particiones en
Linux, 133
Espacio de Intercambio (sawp), 134
Instalacin de Software, 135
Instalacin del Lilo, 136
Problemas al Arrancar desde
el Disco Duro, 142
Problemas al Arrancar desde
el Floppy, 142
Problemas con el Arranque,
138
Problemas con el Hardware,
140
Problemas con el Software, 140
Problemas Despus de Instalar Linux, 142
Procedimientos Post-Instalacin,
137
Resolviendo Problemas, 138
Sistemas de Ficheros, 135
Linux, 107
Recursos para el Desarrollo, 110
mtodos, 197
de la clase object, 198
de objeto, 197
Mac
Mac, 108
MacOS, 108
MDS-2, 78
memoria
administrador automtico de la,
178
middleware, 151
Minix-1
Minix-1, 112
monitoreo del progreso y recuperacin, 47
MPI, 41
NDICE DE MATERIAS
multi servidor, 151

multitasking /multithreading
multitasking /multithreading, 109
NFS, 26
OGSA, 55, 58, 59, 82, 86, 90
aarquitectura
capa de web services, 62
arquitectura, 61
capa de aplicaciones, 62
capa de recursos lgicos y fsicos, 61
capa de servicios, 62
interfase
administracin, 64
ciclo de vida, 64
objetivos, 60
tecnologas, 78
OGSI, 59, 66
interfase
grupo de servicio, 65
infraestructura, 64
mapeo, 65
notificacin, 65
interfases, 63
OOP, 179, 196
operadores, 186
aritmticos, 186
de asignacin, 186
de concatenacin de cadenas de
caracteres, 189
incrementales, 187
precedencia de, 190
racionales, 188
unarios, 187
organizaciones y recursos virtuales
para colaboracin, 19
package, 182
packages, 180
239
perspectiva del administrador, 49

tilde nador, 54
perspectivas de usuario, 42
perspectivas del administrador
instalacin, 49
planeacin, 49
PKI, 80
planificacin del despliegue, 35
organizacin, 36
seguridad, 35
plataforma
de software, 144
plug-in, 153
polimorfismo, 196
post-mortem
post-mortem, 111
producto
familias del, 158
Programas de Comandos
Introduccin, 129
Variables del Shell, 129
puggability, 22
QoS, 60, 76, 82
Quick Installation, 153
recursos, 25
recursos adicionales, 20
Red Hat Software
Red Hat Software, 110
registrarse en el grid, 43
reservacin, 31
return
do while, 195
RIO, 160
RPC, 81
sandbox, 45
scavening, 31
sematicas de servicios
240
convenciones de protocolos de
trasporte, 87
sentencia, 191
Server
Application, 150
Advanced Edition, 151
Enterprise Edition, 152
Standard Edition, 153
server-side, 164
servicio
de demanda, 164
servicios centrales del grid, 68
administracin, 69
comunicacin, 70
poltica, 70
seguridad, 70
servidor
de aplicaciones, 153
HTTP, 153
servise data set find, 64
servlet, 162
ciclo de vida del, 163
codificacin de, 162
desarrollo, 162
motor del, 164
servlets, 154
Set-Cookie, 163
simple
CA, 205
SmartPhone, 159
SMP, 109
SOA, 58, 62
SOAP, 81
software, 182, 201
de base, 201
Software free
Fundacin de Software Libre,
110
Software free, 109
NDICE DE MATERIAS
string, 183
System V
System V, 112
TCP/IP
TCP/IP, 108
TLS, 80
UDDI, 81
UMSDOS
UMSDOS, 112
UNIX
UNIX, 107
URL, 57
variable
clasificacin, 183
local, 184
miembro de una clase, 184
referencia, 183
variables
miembro, 185
tipo primitivo, 183
visibilidad y vida de las, 185
virtual
sistema principal, 155
virtualizacin y orientacin de servicio, 82
VO, 91
VOs
organizaciones virtuales, 82
VPN tunneling, 33
VT, 159
W3C, 80
Web
aplicaciones, 169
services, 80
Web Services, 151
web services
definicin, 97
NDICE DE MATERIAS
Grid Services, 99
Invocacin, 98
WebSphere
para el comercio, 144
WebSphere Commerce, 146
WebSphere Everyplace, 147
WebSphere for Commerce
soluciones de portal, 148
soluciones digital media, 149
WebSphere for commerce
soluciones B2B, 147
soluciones B2C, 147
WebSphere Host Integration, 158
WebSphere Host Publisher, 159
WebSphere Portal, 146
WebSphere Studio, 158
la familia de herramientas, 160
WebSphere Transcoding Publisher,
159
WebSphere Voice, 147
wizard, 160
WSDL, 57, 58, 81, 83
WSIL, 81
X Windows
X Windows, 114
X.509, 80
Xenix
Xenix, 112
XML, 57, 81, 159
ZIP Iomega
ZIP Iomega, 110
241

Bases de Datos en Grid

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Bases de Datos en Grid

Cargado por

Copyright:

Formatos disponibles

Universidad Nacional del Nordeste

Facultad de Ciencias Exactas, Naturales y Agrimensura

Vernica Vanessa Barrios - L.U.: 33.899

A Mis Padres Por el Apoyo Incondicional y a La Luz Que

alumnos de la Facultad, permitiendo la interaccin cliente-servidor mediante

otra referente al libro en formato Latex y el PDF generado. Tambin se

Conclusiones: presenta las conclusiones a las que se ha llegado al finalizar

Vernica Vanessa Barrios

2 Principios de Grid Computing

2.10.7 Los Trabajos y las Aplicaciones . . . . . . . . . . . .

6.2.2 Comando time . . . . . . . . . . . . . . . . . .

Estructuras de Programacin . . . . . . . . . . . . . . . 190

Origen y Desarrollo del Grid Computing. . . . . . . . . . . . .

Mecanismos del Globus Toolkit. . . . . . . .

Barra de Acceso a Internet. . . . .

Cliente Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Grid Computing. . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Concepto de Grid Computing

El concepto principal de Grid Computing es el de compartir potencia computacional [13].

Beneficios que Ofrece el Grid Computing

Los principales beneficios son:

Facilitar el pronto retorno de las inversiones.

Introduccin a Grid Computing

1.2. INTRODUCCIN A GRID COMPUTING

Figura 1.1: Origen y Desarrollo del Grid Computing.

Qu es y Para Qu Sirve el Grid Computing?

El concepto de Grid Computing da idea de una gran potencia de clculo y

1.3. QU ES Y PARA QU SIRVE EL GRID COMPUTING?

Figura 1.2: Aplicaciones de la Computacin en Grid.

Dentro de esta rea se encuentran aquellas aplicaciones cuyas necesidades

Figura 1.3: Caractersticas de un Grid Computacional.

Globus es un proyecto de investigacin y desarrollo enfocado a permitir la

de transferencia de ficheros. En el nivel ms alto se encuentran los servicios

Arquitectura del Grid

Es una nueva arquitectura de computacin designada para direccionar las

1.5. ARQUITECTURA DEL GRID

Figura 1.4: Arquitectura del Grid.

1.6. APLICACIONES Y SERVICIOS EN GRID

Aplicaciones y Servicios en Grid

El avance del grid computing se observa en la aplicabilidad de sus ideas en

Uno de los campos donde se han centrado ms los esfuerzos de compaas

GridSystems ha desarrollado el productor InnerGrid para la aplicacin de

Proceso Intensivo de Datos

Otra de las grandes reas de aplicacin es el almacenamiento masivo de datos.

1.6. APLICACIONES Y SERVICIOS EN GRID

Figura 1.5: Arquitectura Actual de los Sistemas de Informacin.

Figura 1.6: Arquitectura Grig Computing para Sistemas de Informacin.

Principios de Grid Computing

Lo Que el Grid Computing Puede Hacer

Aprovechar los Recursos Que No Siempre se

El uso ms fcil del Grid Computing es ejecutar una aplicacin existente en

CAPTULO 2. PRINCIPIOS DE GRID COMPUTING

Hay dos requisitos previos a cosiderar en este apartado.

2.3. LA CAPACIDAD DE CPU PARALELA

La Capacidad de CPU Paralela

El potencial para la capacidad de CPU paralela masiva es uno de los rasgos

CAPTULO 2. PRINCIPIOS DE GRID COMPUTING

Si tos sub-trabajos no nesecitan comunicarse con el otro, la aplicacin se

Hay muchos factores para considerar en una aplicacin de habilitacin de Grid.

2.5. LOS RECURSOS Y ORGANIZACIONES VIRTUALES

Los Recursos Virtuales y las Organizaciones Virtuales Para la Colaboracin

Otra importante contribucin del grid es habilitar y simplificar la colaboracin

CAPTULO 2. PRINCIPIOS DE GRID COMPUTING

Figura 2.1: Balanceo de Recursos.