Construcción de ambientes virtuales bajo un

enfoque distribuido utilizando servlets.

Autor: David O. Andino O.

Profesor Guía: Domingo Hernández.

Proyecto de Grado presentado ante la ilustre Universidad de los Andes

como requisito final para optar al título de Ingeniero de Sistemas.

UNIVERSIDAD DE LOS ANDES

FACULTAD DE INGENIERIA
ESCUELA DE SISTEMAS
(Abril, 2002)
 Indice
pag

Capítulo I

Introducción

I.1.- 1
Antecedentes.....................................................................................
I.2.- Problema 3
planteado...........................................................................
I.3.- Objetivos generales........................................................................... 3
I.3.1.- Objetivos específicos.................................................................. 3
I.4.- 4
Metodología......................................................................................
I.4.1.- Fase I: Revisión bibliográfica de los 4
servlets...............................
I.4.2.- Fase II: Búsqueda de las plataformas de trabajo.......................... 4
I.4.3.- Fase III: Instalación y pruebas de la 4
plataforma...........................
I.4.4.- Fase IV: Prueba de ejemplos de 5
servlets......................................
 5
I.4.5.- Fase V: Prueba de comunicación con servlets..............................
5
I.4.6.- Fase VI: Prueba de comunicación utilizando hilos
(threads)......
I.4.7.- Fase VII: Revisión bibliográfica de Java 6
3D................................
I.4.8.- Fase VIII: Selección del sistema operativo de 6
trabajo.................
I.4.9.- Fase IX: Prueba de ejemplos en Java 6
3D.....................................
I.4.10.- Fase X: Creación del escenario................................................. 7
I.4.11.- Fase XI: Problema del envió de objetos 3D por 7
red...................
I.4.12.- Fase XII: Distribución de los procesos...................................... 7
I.5.- Alcance............................................................................................. 8
I.6.- Resultados esperados........................................................................ 9
9
I.7.- Contenido del informe.......................................................................

Capítulo II

Marco teórico
II.1.- Introducción a los 11
servlets................................................................
II.2.- Ventaja del servlet sobre el tradicional 13
CGI.....................................
II.3.- ¿Qué es el JSWDK?........................................................................ 15
II.4.- Reconocimiento de la arquitectura del paquete servlet..................... 16
II.5.- El ciclo de vida de un servlet........................................................... 18
20
II.6.- Hilos de Control..............................................................................
21
II.7.- Introducción a Java3D.....................................................................
22
II.7.1.- ¿Qué es el API 3D de Java?.....................................................
23
II.8.- El API Java 3D................................................................................
24
II.8.1.- El escenario gráfico Java 3D.....................................................
27
II.8.2.- La clase SimpleUniverse...........................................................
II.8.2.1.- Ejemplo de uso de la clase 29
“SimpleUniverse”.................
31
II.9.- Iluminación en Java 3D....................................................................
33
II.9.1.- Modelo de Color.......................................................................
34
II.10.- Sistemas distribuidos.....................................................................
34
II.10.1.- Definición de un sistema de cómputo
distribuido...................
38
II.10.2.- Modelos de computación distribuida.....................................
38
II.10.2.1.- Modelo de minicomputadora.....................................
39
II.10.2.2.- Modelo de workstation……………………………...
II.10.2.3.- Modelo workstation- 40
server………………………….
 41
II.10.2.4.- Modelo de pool de procesadores...............................
43
II.10.2.5.- Modelo híbrido.........................................................
44
II.11.- TDSO (Técnica de Desarrollo de Sistemas de
Objetos).................

Capítulo III

Diseño y especificaciones
III.1.- Entidades de la escena.................................................................... 46
III.1.1.- Entorno de paredes, techo y piso............................................ 47
III.1.1.1.- Las paredes................................................................. 48
III.1.1.2.- El techo y piso............................................................. 49
III.1.1.3.- Arbol de escena para el entorno................................... 50
III.1.2.- La 51
silla....................................................................................
III.1.2.1.- La base........................................................................ 51
III.1.2.2.- La columna base.......................................................... 52
III.1.2.3.- El 52
asiento.....................................................................
III.1.2.4.- Columnas del 52
respaldo.................................................
III.1.2.5.- El respaldo.................................................................. 53
III.1.2.6.- Arbol de escena para la silla........................................ 53
III.1.3.- La computadora..................................................................... 54
III.1.4.- El ventilador........................................................................... 57
III.1.5.- Las lámparas.......................................................................... 58
 III.1.6.- La 58
columna.............................................................................
III.1.7.- El escritorio............................................................................ 59
III.2.- Interacciones en el 60
ambiente...........................................................
III.3.- Modelado del sistema distribuido................................................... 61
III.3.1.- Especificación formal en TDSO de los componentes
utilizados en la implantación del ambiente virtual 61
distribuido....................
61
III.3.1.1.- Especificación formal de un servlet..............................

III.3.2.- Diseño y especificación de la arquitectura distribuida

para la construcción del ambiente 67
virtual..............................................................

III.3.3.- Estructura de clases creadas para la implantación del

programa.................................................................................................. 73
76
III.3.4.- El modelo de distribución.......................................................

Capítulo IV

Implementación y pruebas
IV.1.- Creación del objeto silla (ChairServlet).......................................... 77
IV.1.1 Problema de envío de objetos tridimensionales por 85
red.............
IV.2.- Creación del objeto paredes 89
(WallServlet)......................................
IV.3.- Implantación del programa 90
principal...............................................
IV.4.- Interacciones con el 94
ambiente.........................................................
IV.5.- Análisis de los tiempos de respuesta de los 96
servlets........................

Capítulo V

Conclusiones y recomendaciones
V.1.- 101
Recomendaciones............................................................................
Bibliografía

Anexos
Anexo #1.- Threads de Control
Anexo #2.- Cubo de colores
Anexo #3.- Clase SceneConnection
Anexo #4.- Clase SceneConstructor
Anexo #5.- Clase FirstServer
Anexo #6.- Clase VentilatorBehavior
Anexo #7.- Resultado de la primera prueba
 RESUMEN

La necesidad de desarrollar sistemas que ayuden a resolver tareas

complejas a impulsado a la investigación de mejores técnicas de distribución
y optimización de los recursos con que se dispone para la solución de los
problemas. Uno de estos recursos, que será utilizado para el desarrollo del
presente trabajo, son los servlets, los cuales han alcanzado una gran
popularidad en los ultimos años por su eficiencia en el manejo de peticiones
bajo web, y, Java 3D el cual es utilizado para la creación de ambientes
tridimensionales. El problema consiste en cómo un ambiente virtual puede ser
contruido dinámicamente distribuyendo, en diferentes estaciones de trabajo,
objetos tridimensionales que serán creados por medio de servlets y mostrar
cómo es posible utilizar los servlets para poder manipular el envío y recepción
de información de objetos de cualquier tipo.

Considerando esto, el proyecto se desarrollo en cinco (5) fases: una

primera fase dedicada al análisis de los antecedentes y el problema planteado,
así como la metodología utilizada para el desarrollo del trabajo y los
resultados que se esperan obtener, una segunda fase, que consiste en una
revisión bibliográfica cuyo objetivo es recopilar información acerca de los
elementos básicos utilizados en el desarrollo, una tercera fase, destinada al
diseño de cada uno de los objetos tridimensionales que compondrán la escena,
así como la arquitectura del ambiente distribuido, una cuarta fase, dedicada a
un enfoque general de la implantación del sistema distribuído y por último
una quinta fase que consiste en el análisis de los resultados obtenidos junto
con algunas reflexiones y conclusiones.
Descriptores:
- Procesamiento electrónico de dos – Procesos distribuidos.
- Java (Lenguaje de programación para computadora).
Cota: QA76.9A53
 AGRADECIMIENTOS

Debo expresar mis más sinceros agradecimientos:

 Al profesor Domingo Hernández, por el valioso apoyo al conducir la

realización del presente trabajo.

 A Giselle, Jorge y familia por ayudarme en todo momento y darme su

apoyo incondicional para la culminación de éste proyecto.

 A todas aquellas personas que de alguna u otra forma contribuyeron

para la culminación de éste trabajo.
 DEDICATORIA

En la obtención de éste título universitario, es mi deseo señalar algunas

personas que sirvieron de estímulo e inspiración para el logro de ésta meta:

 A mi Padre Dios, por estar presente en mi vida en todo momento y ser

mi ayuda y mi sostén dándome las fuerzas siempre para seguir
adelante, sabiendo que me guiará por el mejor camino.

 A mis padres, por su amor y apoyo incondicional que me han dado

desde el primer momento, y por ello, no hay palabras que puedan
expresar lo que significan para mi.

 A mi hermanita Giselle, por su ayuda, apoyo, estímulo y amistad.

Sobran las palabras para expresar mi más sincera gratitud porque sin
ti no lo hubiera podido lograr.Gracias.

 A Jorge, por guiarme por el buen camino de la verdad y ayudarme y

apoyarme de forma incondicional. ¡Gracias cuñado!.

 A mis hermanos, Francisco e Isabel porque siempre han sido un canal

de bendición para mi vida. Este triunfo es también de ustedes.

 A mis cuñados y sobrinos, por tan solo el hecho de estar presentes.

Gracias.
 A mis amigos en la universidad, ustedes saben quienes son, no hay
palabras cómo expresar su apoyo y ayuda. Le doy gracias a Dios
porque se que fue él quien me permitó conocerles y pasar junto a
ustedes momentos inolvidables. Su amistad a sido una de las cosas más
significativas en mi vida. Gracias por todo lo que han hecho por mi
desde la más pequeña hasta la más grande, han sido y seguirán siendo
una gran bendición para mi vida.
Capítulo I: Introducción.

En el presente capítulo se muestra un breve antecedente de los medios

que serán utilizados para la creación del proyecto, así como el problema que lo
justifica.

También se presentan los objetivos que se desean alcanzar y los

distintos pasos utilizados para la creación del sistema distribuido. Por último,
se definen cuales son los límites o alcances que se tendrán y los resultados que
se espera que acontezcan y se incluye una breve información de los capítulos
posteriores a éste así como, un pequeño resumen del contenido de cada uno.

I.1 Antecedentes.

En estos últimos tiempos, la necesidad de utilizar la arquitectura

cliente/servidor se ha incrementado, debido al crecimiento de sistemas
basados en web empleadas en aplicaciones comerciales y académicas. En esta
aplicación se utilizan lenguajes modernos tales como Java TM
, uno de los
lenguajes de programación más difundido y que ocupa una de las primeras
posiciones en las empresas de software. En esta plataforma de programación,
se han incorporado nuevas herramientas que permiten conectar aplicaciones
“web” con procesos. Este es el caso de los “servlets”, los cuales surgen como
la respuesta a la demanda de eficiencia y mejora de estos recursos que los
programas en redes y en principio los tradicionales programas CGI (Common
Gateway Interface) no proporcionan y más bien limitan y en ocasiones hasta
dificultan el trabajo.
 La empresa sun microsystem, se valió del enfoque de reutilización del
software para crear una herramienta valiosa en Java, para la programación en
redes. El JSWDK (JavaServer Web Development Kit) es un ejemplo didáctico
del uso de recursos ya creados, donde se incluye un pequeño servidor web,
gratis, fácil de configurar y en donde se pueden crear buenas aplicaciones
utilizando “servlets”. Un servlet, no es más que una aplicación en Java que
permite la interacción con un sitio web o con un programa determinado.

El uso del lenguaje Java se ha extendido a muchas áreas de la

computación, encontrándose entre ellas la creación de ambientes virtuales. Los
ambientes virtuales son una opción que a toda persona gusta y que por lo tanto
son bastante utilizados para visualizar con detalle las características propias de
un objeto, un ambiente e incluso un universo o cosas tan pequeñas como un
átomo, virus o bacterias. La creación de ambientes gráficos en dos y tres
dimensiones son una de las tareas más llamativas en el mundo de la
informática y que se ha llevado bastante tiempo en su avance e investigación,
lo que conocemos como computación gráfica. Para implantar aplicaciones en
ésta área existen un conjunto de herramientas ampliamente conocidas, como
son: 3Dstudio Max, VRML, Open Inventor basado en OpenGL y otros. En
éste contexto, Java TM
ha emprendido una considerable labor como lo es la
creación de Java 3D la cual implementa una serie de clases encapsuladas en
un paquete y a su vez es un software que actualiza el JDK (Java Development
Kit) para poder compilar y ejecutar aplicaciones en tres dimensiones.

En el estudio e implementación de objetos tridimensionales, los cálculos

consumen mucho tiempo de ejecución así como el pintado de los objetos. Es
por ello que las computadoras utilizadas para éste propósito deben tener alta
velocidad de procesamiento y, para el caso de Java 3D se requiere una gran
capacidad de memoria para soportarlo.

I.2 Problema planteado.

La visualización de ambientes virtuales involucra un alto costo

computacional, por lo que el enfoque de distribuir sus cálculos ha tomado
mucha fuerza en las últimas dos décadas. Hoy en día existe el enfoque de
conexión de aplicaciones distribuidas en web usando Java “servlets”, para
interacciones con bases de datos. Se pretende probar que los “servlets” pueden
también ser utilizados en la distribución de procesos de cálculo en
computación gráfica.

Con ello, se desea verificar su eficiencia

distribuyendo objetos tridimensionales para
crear una escena virtual utilizando como
herramienta Java 3D.

I.3 Objetivos generales.

 Distribuir procesos de cálculos y
visualización de objetos 3D, de ambientes
virtuales basado en Java “servlets”.

I.3.1 Objetivos específicos.

Estudiar lo relacionado a los “servlets”.

Estudiar formas de distribuir procesos con
“servlets”.
Identificar los objetos que pueden ser
distribuidos.
Estudiar la creación de ambientes virtuales
con Java 3D.
Probar la distribución de un escenario en
Java 3D utilizando “servlets”.

I.4 Metodología.
 I.4.1 Fase I: Revisión bibliográfica de los
“servlets”.

Se investigó la introducción a los

“servlets”, la arquitectura del paquete servlet,
la interacción con los clientes, las peticiones y
respuestas, el manejo de peticiones “GET” y
“POST”, los problemas con los “Threads”
(Hilos), las formas de comunicación entre
“servlets”, las formas de comunicación desde
un programa de aplicación vía URL.

I.4.2 Fase II: Búsqueda de las plataformas de trabajo.

Se procedió a indagar las plataformas encargadas de ejecutar

aplicaciones con “servlets” y en que sistema operativo están disponibles.

I.4.3 Fase III: Instalación y pruebas de la plataforma.

 Al conocer que plataforma es la indicada, que para nuestro caso es el
JSWDK, se procedió a la instalación del mismo, y a la configuración del
servidor web. Se realizaron pruebas de diversas páginas web para comprobar
la forma de trabajo del servidor.

I.4.4 Fase IV: Prueba de ejemplos de “servlets”.

Se procedió a probar los diferentes casos de ejecuciones de “servlets”.

Desde una aplicación sencilla como un “Hola mundo”, hasta “servlets” que
manejan peticiones “GET” y “POST”, sesiones y “cookies” probando sus
funcionalidades y características así como su forma de ejecución en los
servidores web.

Las pruebas realizadas se hicieron de modo individual en formas de

páginas web. Probando así mismo el modo de llamar a varios “servlets” desde
una misma página.

I.4.5 Fase V: Prueba de comunicación con “servlets”.

Se indagó la alternativa de comunicarse con un servlet desde un

programa de aplicación sencillo, de tal forma que el programa se conectara al
servlet y este le diera una respuesta. Luego se investigó otra forma de
comunicación que permitiera enviar datos al servlet que no fueran de tipo form
data que es la forma regular de codificación de datos desde una página web
hacia un programa de aplicación. Generalmente estos datos vienen codificados
y deben ser decodificados.

I.4.6 Fase VI: Prueba de comunicación utilizando Hilos (Threads).

Se hizo la prueba de comunicación desde un programa de aplicación

hacia varios “servlets” en distintos computadores distribuyendo la
comunicación con hilos y enviando y recibiendo objetos sencillos a través de
ellos.

I.4.7 Fase VII: Revisión bibliográfica de Java 3D.

Se estudiaron los ambientes virtuales, lógica de cálculo, formas de

trabajo y la teoría de modelos de iluminación. Así mismo, se estudió la
arquitectura de las clases de Java 3D, lógica de trabajo, creación de
geometrías, la interacción en Java 3D, animación e iluminación.

I.4.8 Fase VIII: Selección del sistema operativo de trabajo.

Java 3D es todavía una versión beta. La versión seleccionada para el

proyecto es la 1.2.1.03 basada en Opengl para Windows, dado que solo existe
para Solaris y Windows y la versión en Solaris no se ejecuta en Linux. De
acuerdo a esto, se decidió que dado el objetivo que se debe cumplir para el
proyecto, se utiliza el JSWDK y el Java 3D para el sistema operativo
Windows.

I.4.9 Fase IX: Prueba de ejemplos en Java 3D.

 Se realizaron una serie de pruebas de distintos objetos tridimensionales,
desde cubos, conos, cilindros y esferas hasta geometrías complejas que no
incluyen a ninguno de los anteriores. Se probó la interacción con estos objetos
y el uso de estos para crear escenarios sencillos. Se crearon eventos
personalizados para los objetos y la manipulación de estos.

Luego se realizaron programas que incluyeran modelos de sombreado e

iluminación, pruebas de brillo y el uso de distintos objetos de iluminación
encargados de suministrar la luz.

I.4.10 Fase X: Creación del escenario.

A partir de los conocimientos obtenidos en Java 3D, se comenzó a

seleccionar un escenario virtual sencillo, dado que lo que se desea es probar la
distribución con “servlets”. Ante ello se seleccionó el modelo de una oficina.

Para la creación del escenario, el programa se diseñó, de tal forma, que

luego fuera sencillo distribuirlo con “servlets”, creando los objetos por
separado y añadiéndolos dinámicamente en la escena virtual.

I.4.11 Fase XI: Problema del envío de objetos 3D por red.

Se investigó la manera de poder enviar los objetos tridimensionales por

la red. Este problema será detenidamente analizado más adelante en el
capítulo IV Implementación y pruebas.
I.4.12 Fase XII: Distribución de los procesos.

Por último se dispusieron diversos “servlets” que se encargaran de

enviar un objeto en especial por la red y por medio de un programa de
aplicación que se comunicara con ellos, distribuyendo las tareas con hilos se
construyó el escenario virtual. El tiempo de envío y respuesta de cada servlet
fue registrado.
I.5 Alcance.

En éste proyecto se pretende llegar a lo siguiente:

 El uso de ambientes tridimensionales es con el fin de evaluar la

veracidad y eficiencia de la distribución con “servlets” y para poder
visualizar las respuestas de cada servidor. Esto no quiere decir que
no se puedan distribuir procesos con otros tipos de objetos. De hecho
se mostrará como se puede hacer esto.
 La forma de distribución que se utiliza no es la única. Existen cientos
de formas para poder limitar las respuestas de los servidores. El
modelo seleccionado es el de minicomputadora para los casos de
prueba. Éste modelo se explica en la sección II.10.2.1 del capítulo II.
 Para nuestro caso cada servlet se dedica a un objeto en especial. Pero
eso no quiere decir que el servlet no pueda llamar a otro para
construir una escena específica y que este no pueda ser llamado por
el programa de aplicación. La forma de distribución puede ser tan
compleja como se quiera pero nos limitamos a lo básico.
 El escenario virtual que se construye es sencillo y en nuestro caso es
una oficina. Nos limitamos al diseño de un ambiente sencillo porque
 el objetivo de la tesis es probar una plataforma distribuida basado en
Java3D sobre “servlets”.
 La aplicación de texturas y formas geométricas complejas se dejan
como adiciones para el ambiente. No necesariamente tienen que
estar presentes.
 Demostrar que los objetos construidos de manera distribuida pueden
ser incluidos dinámicamente en la escena virtual.

I.6 Resultados esperados.

Se desea que la evaluación de la distribución con “servlets”, teniendo

como aplicación la creación de una escena tridimensional utilizando como
herramienta Java 3D, sea exitosa, dado la potencialidad de los “servlets”.
Probando, de éste modo, todas las dificultades que se puedan presentar y las
limitaciones de los “servlets”, así como de los procesos que se quieran
distribuir y como resultado se obtenga la escena que en principio se diseñó.
Por medio de esto, tener la idea general de cómo distribuir los procesos que se
deseen.

I.7 Contenido del informe.

El informe contiene los capítulos siguientes:

 Capítulo II: Revisión bibliográfica. En este capítulo se muestran algunas

definiciones importantes, tales como una introducción al mundo de los
“servlets” y de Java 3D, un panorama general del API (Interfaces de
 Programación Aplicables o biblioteca de clases) de cada uno de ellos y el
modo de funcionamiento.
 Capítulo III: Diseño y Especificaciones. Se muestran los caminos
tomados para lograr el objetivo. En el caso de Java 3D se señala como
fueron diseñados los ambientes virtuales y el árbol de diseño, la forma de
distribución entre otras cosas.
 Capítulo IV. Implementación y Pruebas. Se explica paso a paso la forma
en que fue programado el sistema. Se describiren algunas especificaciones
importantes referentes a Java y como generalizar la distribución de objetos
con “servlets”.
 Capítulo V. Conclusiones y Recomendaciones. Se presentará un análisis
general de los resultados obtenidos al final del proyecto incluyendo ciertas
ventajas y desventajas referentes a la forma de diseño del sistema y algunas
recomendaciones necesarias para su uso y mejoramiento.
 Bibliografía. Se presenta los sitios web y los libros utilizados para la
investigación e implementación del sistema.
 Anexos. Se incluyen el código fuente de cada uno de los servidores,
programas de pruebas y programas principales.

Capítulo II: Marco teórico.

En el presente capítulo se muestran las

bases teóricas, conceptos y definiciones tanto
de Java Servlets como de Java 3D. Esto es
 necesario para el conocimiento previo de la
visión tradicional de cada uno de ellos, dado
que hasta ahora se han visto solo por
separado.

Se introduce al funcionamiento básico de Java Servlets, el JSWDK y el

contenido del paquete. Así mismo, se presenta la visión general del API de los
servlets. Con respecto a Java 3D, se muestra un resumen completo del
contenido general del paquete, así como su lógica de creación de mundos
virtuales.

Solo se mostrarán las definiciones y conceptos básicos de ambos. Es de

suponerse que se requiere un cierto conocimiento de Java los cuales no se
mostrarán en este capítulo. Para más información se anexa la dirección web de
consultas, tutoriales y cursos en http://java.sun.com.

II.1 Introducción a los Servlets.

Los “Servlets” son módulos que extienden los servidores orientados a petición - respuesta, como los
servidores web compatibles con Java. Por ejemplo, un “servlet” podría ser responsable de tomar los
datos de un formulario de entrada de pedidos en formato HTML y aplicarle la lógica de negocios
utilizada para actualizar la base de datos de pedidos de la compañía como se muestra en la figura 2-1.
 figura 2-1. Envío de datos desde un sitio web hacia un “servlet” que modifica una tabla en una base de
datos de inventario.

Los “servlet”s son para los servidores lo que los applets son para los navegadores. Sin embargo, al
contrario que los applets, los “servlets” no tienen interface gráfica de usuario.

Los Servlets son la respuesta de la tecnología de Java a la programación

en CGI. Estos son programas que se ejecutan en un servidor web y son muy
utilizados por las siguientes razones:

 Las páginas web, por lo general, están basadas en la entrada de datos

de un usuario. Por ejemplo, un buscador web genera sus páginas
dinámicamente de acuerdo a la palabra que se desea encontrar.
 Los datos cambian frecuentemente. Por ejemplo los reportes del tiempo
o las páginas de noticias titulares podrían crearse dinámicamente, quizás
devolviendo una página construida previamente si ésta todavía está
vigente.

 Las páginas web utilizan información de bases de datos incorporadas o

otros tipos de recursos. Por ejemplo se podría utilizar para construir una
página web en una tienda en línea que liste precios actuales y número de
 productos en reserva. Es decir, la página web cambia a medida que
cambian los datos en la base de datos. Esto lo hace primordialmente
dinámica. Estas páginas son muy frecuentes en sitios web virtuales que
interactuan con bases de datos reales.

II.2 Ventaja del “servlet” sobre el tradicional CGI.

Los Java servlets son han demostrado ser eficientes, fáciles de usar,
portables y económicos comparado con el tradicional CGI y que muchas
alternativas parecidas al CGI. A continuación se explican esas ventajas:

 Eficiencia. Con el CGI tradicional, un nuevo proceso es iniciado por cada

petición que realice el usuario. Si el programa CGI hace una operación
relativamente rápida, la sobrecarga para iniciar el proceso puede dominar
el tiempo de ejecución. Con servlets, el Java Virtual Machine ( Máquina
Virtual de Java) lo aloja en la memoria principal, y cada petición es
cargada en un ligero hilo de Java, el cual no representa un peso para el
procesador y para el sistema operativo. Similarmente, en un programa CGI
tradicional, si hay N peticiones simultáneas a un mismo programa,
entonces el código del CGI es cargado en memoria N veces, lo cual no
ocurre para el “servlet” dado que habrían N hilos pero solamente una
singular copia de la clase “servlet”.

 Conveniencia. Si se es programador en Java, se cuenta con una buena

herramienta para crear aplicaciones Web sin tener necesidad de aprender
PERL, por ejemplo. Con los servlets hay una extensa infraestructura para
 codificar y decodificar formas de datos HTML (HiperText Meta
Language), leer e incluir cabeceras HTTP (HiperText Transfer Protocol),
cargar “cookies” y muchas otras utilidades.

 Poderoso. Con los servlets se pueden hacer cosas que son difíciles o hasta
imposibles con los CGIs regulares. El “servlet” puede conversar con el
servidor web (los programas CGI regulares no pueden hacerlo). Esto
simplifica operaciones que se necesitan para cargar imágenes y otros datos
guardados en lugares estándares. Los servlets también pueden
intercambiar información entre ellos, y realizar cosas muy útiles como
hacer más fácil implantaciones de interconexiones a bases de datos.

 Portable. Los servlets son escritos en Java y por lo tanto siguen las reglas
de estandarización API. Consecuentemente los servlets escritos en un
servidor web como “I-Planet Enterprise Server” pueden correr
virtualmente sin cambios en “Apache”, “Microsoft IIS” o “WebStar”. Los
servlets son soportados directamente en las distintas plataformas
utilizando conexión de tipo “plug-in”.

Los servlets han sido limitados solo a nivel de web y han sido utilizados
para capturar datos desde una página web y por medio de estos interactuar
con una Base de datos, viéndolo desde este punto de vista no hay diferencia
con un programa CGI. Muchos, hoy día, siguen pensando que los servlets solo
sirven como “una mejor opción para realizar estas aplicaciones en Java”.
Pero los servlets son más que eso, con ellos se puede crear aplicaciones
distribuidas muy complejas como también muy sencillas. No solo son una
mejora ante los programas CGI son también una mejora ante los tradicionales
programas distribuidos que basan su comunicación en sockets.

II.3 ¿Qué es el JSWDK?.

El JSWDK (JavaServerTM Web Development Kit) es la implantación de

referencia para el JSP ( Java Server Pages ) y el API de Java TM Servlet. El
JSWDK es en realidad un archivo comprimido que contiene los códigos
fuentes de los paquetes javax.servlet para JavaTM Servlet y el javax.servlet.jsp
para el JSP, así como la documentación API de cada paquete que sirve como
guía al programador. También incluye un simple servidor web el cual resulta
muy sencillo de configurar y puede ser usado para probar las aplicaciones
hechas con servlets o JSP.

Al momento de descomprimir el archivo que contiene el JSWDK es

necesario reconfigurar el CLASSPATH (una variable de entorno reconocida
por el compilador la cual contiene información de paquetes y clases
indispensables para aplicaciones en Java) añadiéndole la dirección de los
nuevos paquetes para poder realizar aplicaciones con servlets. De éste modo
resultará más sencillo al momento de compilar. Para mayor información
acerca del JSWDK y la configuración de su servidor web se puede consultar
en http://java.sun.com o en el archivo README.txt que viene con el paquete.

II.4 Reconocimiento de la arquitectura del paquete “servlet”.

 El paquete javax.servlet proporciona clases e interfaces para escribir
servlets. La arquitectura de este paquete se describe a continuación:

 La interfaz servlet.

La abstracción central en el API Servlet es la interfaz Servlet. Todos los

servlets implementan esta interfaz, bien directamente o, comúnmente,
extendiendo una clase que lo implante como el HttpServlet. En la figura 2-2
notamos la jerarquía de herencia al realizarse una aplicación con servlets. El
servlet “MyServlet” es una aplicación personalizada la cual debe heredar (o
extender) de la clase HttpServlet.

figura 2-2. Ejemplo de herencia para un “servlet”.

 Interacción con el cliente.

Cuando un “servlet” acepta una llamada de un cliente éste recibe dos
objetos como son:
 “ServletRequest”, que encapsula la comunicación desde el cliente al
servidor.
  “ServletResponse”, que encapsula la comunicación de vuelta desde el
servlet hacia el cliente.

El “ServletRequest” y “ServletResponse” son interfaces definidas en

el paquete javax.servlet.

 Interfaz ServletRequest.

La interfaz “ServletRequest” permite al “servlet” acceder a:

 Información, como los nombres de los parámetros pasados por el

cliente, el protocolo (esquema) que está siendo utilizado por el cliente, y
los nombres de la estación remota que ha realizado la petición y la del
servidor que la ha recibido.

 El flujo de entrada, “ServletInputStream”. Los Servlets utilizan este

flujo (stream) para obtener los datos desde los clientes que utilizan
protocolos como los métodos POST y PUT del HTTP.

Las interfaces que extienden la interfaz “ServletRequest” permiten al

“servlet” recibir más datos específicos del protocolo. Por ejemplo, la interfaz
“HttpServletRequest” contiene métodos para acceder a información de
cabecera específica HTTP.

 Interfaz ServletResponse.
 La interfaz ServletResponse le da al “servlet” los métodos para
responder al cliente.

 Permite al “servlet” seleccionar la longitud del contenido y el tipo

“MIME” de la respuesta.

 Proporciona un flujo de salida, “ServletOutputStream”, y un

“Writer” a través del cual el “servlet” puede responder datos por medio
de una página web.

II.5 El ciclo de vida de un “servlet”.

Cada “servlet” tiene un ciclo de vida el cual se muestra en la figura 2-3 y se describe a continuación:

1. Un servidor carga e inicializa el “servlet”.

2. El “servlet” maneja cero o más peticiones para cualquier

cantidad de clientes, dependiendo la aplicación.

3. El servidor elimina el “servlet”. (Algunos servidores sólo

cumplen este paso cuando se desconectan).

-1
 Código del Cargar
servlet
Servidor

Soportando
Código del
servlet las
peticiones Cliente -2
de los
clientes
Cliente

Código del descargar -3

servlet
Servidor

figura 2-3. Ciclo de vida de un “servlet”.

Se puede observar la forma cómo un “servlet” es procesado en el

momento de ser llamado por el cliente. En primera instancia el servidor recibe
la petición del cliente de solicitar servicios del “servlet”. El “servlet” es
cargado directamente en memoria principal, es decir, el “servlet” se
inicializará una sola vez, al ejecutar un procedimiento llamado init().

La ventaja de esto, es que el “servlet”, después de cargado en memoria,

puede ser accedido casi inmediatamente, aunque dependiendo de la aplicación
tarde quizás la primera vez, al momento de inicializar.

Después de cargado en memoria, el “servlet” tiene la capacidad de

atender y responder peticiones venidas desde la red. Dependiendo de la forma
de diseño, el “servlet” puede atender a n clientes disparando un thread (hilo)
de proceso por cada uno, o bien, puede atender a un solo cliente manteniendo
a los demás en espera del servicio, resolviendo de ese modo el problema de la
concurrencia.
 Al final, cuando el “servlet” termina sus servicios, dependiendo del
servidor en el cual éste siendo accedido, puede o destruirse o esperar hasta
que el servidor web sea desactivado. Para el caso del JSWDK el “servlet”
solo se destruye a menos que el servidor se desconecte.

II.6 Hilos de Control.

Un hilo es un flujo secuencial de control dentro de un programa. Todos los programadores están
familiarizados con la escritura de programas secuenciales.

En los programas secuenciales existe un principio, una secuencia de

ejecución y un final. En un momento dado durante la corrida del programa hay
un sólo punto de ejecución.

Un thread (hilo) es similar a los programas secuenciales descritos arriba:

un sólo hilo también tiene un principio, una secuencia y un final. Sin embargo,
un hilo por sí mismo no es un programa. Un hilo solo se ejecuta por medio de
un proceso o programa asignado.

No hay nada nuevo en el uso de un sólo hilo en una aplicación. El juego

real no está sobre los hilos secuenciales individuales, sino sobre la posibilidad
de que un solo programa ejecute varios hilos a la vez en los que se realicen
diferentes tareas.

El navegador HotJava es un ejemplo de una aplicación multi-hilo.

Dentro del navegador HotJava tiene la capacidad de visualizar una página
mientras se descarga un applet o una imagen, se ejecuta una animación o se
escucha un sonido, se imprime una página en segundo plano mientras se
descarga una nueva página. Algunos textos utilizan el nombre proceso de poco
peso en lugar de hilo.

Como un flujo secuencial de control, un hilo debe conseguir algunos de

sus propios recursos dentro de un programa en ejecución. (Debe tener su
propia pila de ejecución y contador de programa, por ejemplo). El código que
se ejecuta dentro de un hilo trabaja sólo en éste contexto. Así, algunos textos
utilizan el término contexto de ejecución como un sinónimo para los hilos.

En el anexo #1 se profundiza sobre la estructura de los hilos y se muestran algunos ejemplos realizados
en Java.

II.7 Introducción a Java3D.

El API Java 3D es una interfaz para escribir programas que muestran e interactuan con gráficos
tridimensionales. Java 3D es una extensión estándar del JDK 2 de Java. El API Java 3D proporciona una
colección de constructores de alto nivel para crear y manipular geometrías 3D y estructuras para dibujar
esta geometría. Java 3D proporciona las funciones para creación de imágenes, visualizaciones,
animaciones y programas de aplicaciones gráficas 3D interactivas.

II.7.1 ¿Qué es el API 3D de Java?.

El API 3D de Java es un árbol de clases

Java que sirven como interface para sistemas
 que permite visualizar gráficos
tridimensionales anexando un sistema de
sonido. El programador trabaja con
constructores de alto nivel para crear y
manipular objetos geométricos en 3D. Estos
objetos geométricos residen en un universo
virtual, que luego se visualiza o pinta. El API
está diseñado con flexibilidad para crear
universos virtuales precisos de una amplia
variedad de tamaños.

A pesar de toda esta funcionalidad, el API es sencillo de usar. Los

detalles de visualización se manejan automáticamente. Aprovechándose de los
hilos de Java, el visualizador de Java 3D es capaz de pintar en paralelo. El
visualizador también puede optimizarse automáticamente para mejorar el
rendimiento del pintado de objetos.

Un programa Java 3D crea instancias de objetos Java 3D y los sitúa en

una estructura de datos que representa el escenario gráfico. Este escenario
gráfico es una composición de objetos 3D en una estructura de árbol que
especifica completamente el contenido de un universo virtual, y cómo va a ser
visualizado.

Los programas Java 3D pueden escribirse para ser ejecutados como

aplicaciones individuales o como applets en navegadores que hayan sido
extendidos para soportar Java 3D, o ambos.

Java 3D es gratis como la mayoría de las aplicaciones de Java y por lo

tanto se puede descargar desde http://java.sun.com/products/java-media/3d
donde se puede decidir para cual sistema operativo se desea desarrollar la
aplicación. Solo existe para Windows o Solaris.

Para poder realizar aplicaciones en Java

3D es necesario tener el JDK instalado. Es
recomendable y necesario las versiones
superiores al 1.2.1. Luego de contar con el
JDK se procede a instalar la actualización del
Java 3D para el JDK. Juntamente con la
actualización, Java 3D incluye una serie de
demos.
 II.8 Arquitectura del paquete Java 3D.

Todo programa Java 3D está, al menos, parcialmente ensamblado por

objetos del árbol de clases Java 3D. Esta colección de objetos describe un
universo virtual, que va a ser visualizado. El API define unas 100 clases
presentadas en el paquete javax.media.j3d.

Hay cientos de campos y métodos en las

clases del API Java 3D. Sin embargo, un
sencillo universo virtual que incluya
animación puede construirse con unas pocas
clases. Este capítulo describe un conjunto
mínimo de objetos y sus interacciones para
pintar un universo virtual.

Además del paquete o unidad principal de Java 3D, se usan otros

paquetes para escribir programas Java 3D. Uno de estos paquetes es
com.sun.j3d.utils el que normalmente se refiere a clases de utilidades de Java
3D. El paquete de las clases centrales incluye sólo las clases de menor nivel
necesarias en la programación Java 3D.
 Las clases de utilidades son adiciones convenientes y poderosas al
paquete principal. Estas clases se dividen en cuatro categorías: cargadores de
contenidos, ayudas para la construcción del escenario gráfico, clases de
geometría y utilidades de conveniencia.

Al utilizar las clases de utilidades se reduce significativamente el

número de líneas de código en un programa Java 3D. Además de las clases del
paquete principal y el de utilidades de Java 3D, todo programa 3D usa clases
de los paquetes estándares java.awt y javax.vecmath. El paquete java.awt
define el "Abstract Windowing Toolkit" (AWT). Las clases AWT crean una
ventana para mostrar la visualización del escenario gráfico. El paquete
javax.vecmath define clases de vectores matemáticos para puntos, vectores,
matrices y otros objetos matemáticos.

II.8.1 El escenario gráfico Java 3D.

Un universo virtual Java 3D se crea desde

un escenario gráfico y este se forma usando
ejemplares de clases Java 3D. El escenario
gráfico se construye ensamblando diferentes
objetos que definen la geometría, los sonidos,
 las luces, la localización, la orientación y la
apariencia de los objetos visuales.
La estructura de datos empleada para representar un escenario gráfico es
el árbol, el cual está compuesto de nodos y arcos. Un nodo es un elemento
dato y un arco es una relación entre elementos datos. Los nodos en un
escenario gráfico son los ejemplares de las clases de Java 3D. Los arcos
representan dos tipos de relaciones entre ejemplares, como son: la relación
padre-hijo y la de referencia.

La relación padre-hijo se representa por medio de un nodo llamando un

nodo “Group”, el cual, puede tener cualquier número de hijos, pero sólo un
padre. Un nodo hoja sólo puede tener un padre y no puede tener hijos. La otra
relación es la de referencia. Una referencia asocia un objeto
“NodeComponent” con un nodo del escenario gráfico. Los objetos
“NodeComponent” definen la geometría y los atributos de apariencia usados
para pintar los objetos visuales.

Sólo hay un “camino” desde la raíz hasta el escenario gráfico de cada

nodo hoja. Todo “camino hacia un escenario gráfico” en Java 3D especifica
completamente la información de estado de su hoja. Esta información incluye,
la localización, la orientación y el tamaño del objeto visual. El visualizador
Java 3D se aprovecha de este hecho y repinta las hojas en el orden que él
determina más eficiente. El programador en Java 3D normalmente no tiene
control sobre el orden de visualizado de los objetos.
 Las representaciones gráficas de un escenario gráfico pueden servir
como herramienta de diseño y/o documentación para los programas en Java
3D. Los escenarios gráficos se dibujan usando símbolos gráficos estándares
como se ve en la figura 2-4. A la izquierda se tiene los objetos de tipo “Nodo”
y “Nodo Componentes” y a la derecha tenemos el tipo de relación que algunos
nodos tienen entre sí. Como se dijo, la relación más utilizada es la de padre-
hijo el cual incluye el nodo “VirtualUniverse”. Este tipo de relación es la
utilizada para la creación de éste proyecto. Los programas en Java 3D podrían
tener más objetos que los que hay en su escenario gráfico.

figura 2-4. Símbolos para el árbol de

escena.
 El escenario gráfico es una representación concisa del programa
(asumiendo que se siguió la especificación).

II.8.2 La clase “SimpleUniverse”.

El constructor de la clase “SimpleUniverse” crea un escenario gráfico

que incluye un objeto la clase “VirtualUniverse” (Universo virtual), un objeto
de la clase “Locale” (Localización), y una rama de vista gráfica completa. En
la figura 2-6 se muestra la estrutura de una aplicación donde se involucra a un
objeto de la clase “SimpleUniverse”. Este objeto utiliza indirectamente los
objetos “View” y “ViewPlatform” de la unidad o paquete central de Java 3D.

El paquete com.sun.j3d.utils.universe
contiene SimpleUniverse, ViewingPlatform, y
clases Viewer de conveniencia.
figura 2-6. Estructura de un escenario gráfico
utilizando la clase SimpleUniverse.

Para utilizar los objetos de la clase SimpleUniverse se siguen los

siguientes pasos:

1. Crear un objeto “Canvas3D”.

2. Crear un objeto “SimpleUniverse” que referencia al objeto
“Canvas3D” anterior.
 Personalizar el objeto “SimpleUniverse”.
3. Construir la rama de contenido.
4. Compilar la rama de contenido gráfico.
5. Insertar la rama de contenido gráfico dentro del objeto “Locale” de
“SimpleUniverse”.
 El objeto SimpleUniverse crea una rama de vista gráfica completa para
un universo virtual. Esta rama incluye un plano de imagen. Un plano de
imagen es el rectángulo conceptual donde se proyecta el contenido para
formar la imagen visualizada. El objeto “Canvas3D”, proporciona es usado
como plano de imagen. Esto se puede observar en la figura 2-7, en la que se
muestra la relación que existe entre el plano de imagen, la posición del ojo, y
el universo virtual. La posición del ojo está detrás del plano de imagen. El
pintado puede ser entendido como una proyección de los objetos visuales
sobre el plano de imagen. Esta idea se ilustra con los cuatro proyectores de la
imagen (líneas punteadas).

Por defecto, el plano de imagen está centrado en el origen de

SimpleUniverse. La orientación por defecto es mirando hacia abajo el eje Z.
Desde esta posición, el eje X es una línea horizontal que atraviesa el plano de
imagen con los valores positivos hacia la derecha. El eje Y es una línea
vertical que atraviesa el centro del plano de imagen, con los valores positivos
arriba. Consecuentemente, el punto (0,0,0) es el centro del plano de imagen.
 figura 2-7. Relación entre el plano de imagen,
la posición del ojo del usuario y el universo
virtual.

II.8.2.1 Ejemplo de uso de la clase “SimpleUniverse”.

Para explicar cómo funciona desde el

punto de vista práctico una aplicación que
requiera el uso de la clase “SimpleUniverse”
se presentará la visualización de un cubo de
colores. En la figura 2-8 se puede observar el
árbol que se debe construir para visualizarlo.
Las siglas “BG” hacen referencia a un nodo
“BranchGroup” el cual es el nodo encargado
de contener la escena, “TG” simboliza al nodo
“TransformGroup” que permitirá que el cubo
 rote unos cuantos grados los cuales se
especifican con un objeto llamado
“Transform3D” el cual almacena información
de rotación y ubicación en el universo virtual y
“ColorCube” es el cubo de colores que
deseamos visualizar.

figura 2-8. Arbol de escena para un cubo de

colores.
 Teniendo éste escenario gráfico, resulta
sencillo pasarlo al código fuente en Java 3D
dado que la relación padre – hijo ya se
encuentra representada y todo lo que queda es
interpretarlo. El código fuente de dicha
representación se encuentra en el anexo #2
donde se puede observar cada uno de los pasos
descritos anteriormente para la construcción
de un ambiente gráfico usando la clase
“SimpleUniverse”.

En la figura 2-9 se observa una vista de

ejemplo para el cubo de colores tomando como
base el árbol de escena presentado en la figura
2-8.
figura 2-9. Vista del cubo de colores rotado.

II.9 Iluminación en Java 3D.

En el mundo real, los colores que percibimos son una combinación de las características físicas del
objeto, de las características de las fuentes de luz, de las posiciones relativas de los objetos a las fuentes
de luz, y del ángulo desde el cual se ve el objeto. Java 3D utiliza un modelo de iluminación para
aproximar la física del mundo real. El resto de esta sección explica el modelo de iluminación de Java 3D
en términos generales.

La ecuación del modelo de iluminación depende de tres vectores: la superficie normal (N), la dirección
de la luz (L), y la dirección al ojo del espectador (E) además de las características materiales del objeto
y de las características de la luz. La figura 2-10 muestra los tres vectores para dos vértices de una
superficie esférica. Los vectores para cada vértice pueden tener distintas direcciones dependiendo de las
especificaciones de la escena.
 figura 2-10. Relación entre los vectores de luz
(L), del observador (E) y de la normal a la
superficie (N).

Los modelos de iluminación se calculan en tiempo de ejecución cuando

los vectores L y E varían. Por lo tanto, cada vértice de la esfera
potencialmente se visualiza con una sombra diferente.

El modelo de iluminación incorpora tres tipos de reflexiones de luz del mundo real como son: reflexión
del ambiente, reflexión difusa, y brillo. La reflexión del ambiente resulta de la luz ambiente, luz
constante de bajo nivel, en una escena. La reflexión difusa es la reflexión normal de una fuente de luz
desde un objeto visual. Las reflexiones brillantes, son aquellas reflexiones sobre-iluminadas de una
fuente de luz sobre un objeto, que ocurren en ciertas situaciones.

La figura 2-11 muestra una esfera y un plano visualizados por Java 3D.
Los tres tipos de reflexión se pueden ver en la esfera. La parte más oscura de
la esfera exhibe sólo la reflexión ambiente. El centro de la esfera está
iluminado por la luz difusa y ambiente. Con una esfera azul y una luz blanca,
la reflexión difusa es azul. La parte más brillante de la esfera es el resultado de
la reflexión brillante con reflexiones ambiente y difusa.

figura 2-11. Acción de los tres tipos de

reflexiones en la esfera.

II.9.1 Modelo de Color.

El modelo del color no está basado en la

física. Java 3D modela el color de las luces y
los materiales como una combinación de rojo,
verde, y azul. El color blanco, como el color de
la luz o del material, es la combinación de los
tres componentes con la intensidad máxima.
Cada luz produce un solo color de luz
especificado por una tupla RGB ( Red, Green,
Blue). El modelo de iluminación se aplica a
cada uno de los componentes del color RGB.
Por ejemplo, una bola roja en presencia de
una luz azul no será visible puesto que la luz
azul no se refleja desde un objeto rojo. En
realidad, el color es una combinación de
muchas longitudes de onda de la luz, no solo
tres. El modelo de color RGB representa
muchos colores, pero no todos.

II.10 Sistemas distribuidos.

 Como éste proyecto, pretende construir
ambientes virtuales por medio del uso de
“servlets” distribuidos, se dará una pequeña
revisión a los conceptos básicos y a las
arquitecturas de distribución de procesos más
comunes.

II.10.1 Definición de un sistema de cómputo distribuido.

La idea fundamental de un sistema distribuido (SD) es que

constituye una combinación de computadoras y sistemas de transmisión de
mensajes bajo un solo punto de vista lógico, a través del cual, los elementos
de cómputo resuelven tareas en forma colaborativa. Se puede aseverar que el
sistema constituye un ente capaz de procesar información debido a dos
características esenciales:

1. El sistema consiste de una cantidad de computadoras cada una de las

cuales tiene su propio almacenamiento, dispositivos periféricos y
potencia computacional.
2. Todas las computadoras están adecuadamente interconectadas.

Por medio del sistema operativo adecuado, las computadoras mantienen

su capacidad de procesamiento de tareas local, mientras constituyen
elementos colaborativos de procesamiento en el ambiente distribuido. El
elemento de interconexión indica que debe existir el mecanismo de transporte
de información entre los componentes, de manera que sea factible el
intercambio de mensajes entre nodos cooperativos, de forma tal, que no
se violente la transparencia de una transacción. Se puede decir entonces
que un ambiente distribuido también incluye las siguientes características:

1. Una variedad de componentes que incluyen tanto plataformas de

cómputo como las redes de interconexión que transportan mensajes
entre ellas unificadas en un solo ambiente de procesamiento.
2. La transparencia, como resultado de la abstracción apropiada de los
componentes del sistema. Con respecto a la transparencia, no
siempre es posible mantenerla estrictamente en todos los casos.
Algunas ocasiones es necesario el establecimiento de ciertas
distinciones entre los usuarios y los operadores del ambiente
computacional, debido a las tareas especificas o generales que éstos
deben realizar.

Existen ciertos factores que han propiciado el auge tan elevado de los
sistemas distribuidos dentro del procesamiento de las organizaciones
modernas en el mundo, en particular Tanenbaum se refiere a algunos de
ellos como:

 Avances en tecnología de cómputo.

 Desarrollo de las redes locales de alta velocidad (LAN).
 Desarrollo de redes de área amplia (WAN).
 A los que se podrían agregar: la creación y proliferación de las redes de
interconexión, que permiten el acoplamiento de sistemas de procesamiento y
periféricos, así como la aparición de software con una mejor ingeniería, lo
cual permite el escalamiento y actualización hacia nuevas capacidades y
prestaciones de acuerdo a las necesidades de desempeño de las
aplicaciones actuales.

Muchos autores hacen la distinción entre los sistemas distribuidos,

elaborados para que trabajen con ellos varios usuarios en forma simultánea y
los sistemas paralelos, que pretenden lograr la máxima velocidad de
ejecución en una tarea determinada. Esta distinción ha tenido mucha
controversia, por lo que el consenso general ha determinado usar “sistema
distribuido” en sentido amplio, donde varios CPU’s trabajan
“intercomunicados entre sí” de manera cooperativa.

Por lo que respecta a la comparación de

un sistema distribuido contra la operación de
una sola PC, las dos ventajas esenciales son
la compartición de periféricos/recursos y la
distribución de carga de las aplicaciones.
 En el primer caso, se logra tener acceso a
equipos sofisticados o especializados que al
ser usados concurrentemente por varias
personas permiten aplicar criterios de
economía de escala para su asignación y
adquisición desde el punto de vista económico.

En cuanto al segundo punto, a través de un

ambiente distribuido se logra mejorar la carga
de trabajo de ciertos equipos o servicios, de
manera tal que se
balancea adecuadamente el nivel de desempeño y aplicación de componentes
de hardware y software, maximizando el uso de los sistemas de acuerdo a la
demanda de los usuarios.

Sin embargo, frente a todas las ventajas, existen desventajas importantes

que deberían ser resueltas de la mejor manera posible antes de considerar un
estado maduro de tales sistemas en lo que respecta al uso difundido de
ellos dentro de las aplicaciones cotidianas de las organizaciones
modernas. Los tres principales señalados también por Tanenbaum son:
  El software.
 Las redes de interconexión.
 La seguridad.

El software se considera una problemática importante dado que para un

SD es importante tomar en cuenta que éste debe ser de un tipo y capacidades
muy especiales, hecho específicamente para administrar y operar sobre un
ambiente disperso. En este rubro, la mayor parte de los sistemas
desarrollados están pensados para operar sobre una computadora ya sea
centralizada o bien, monousuario, dejando de lados las problemáticas de
sincronización, control y distribución de carga que aparecen en los ambientes
distribuidos.

Las redes de interconexión son relevantes porque a través de ellas

fluyen los mensajes y paquetes de comunicación entre los diferentes
procesadores involucrados en la tarea, y de fallar éstas, los procesos
asociados pueden dañarse o interrumpirse.

Finalmente, la cuestión de la seguridad aparece también como un

elemento a considerar, dado que si cualquier usuario tiene acceso a través de
una imagen lógica a todos los elementos y periféricos que integran un SD,
también puede leer información o datos de otras personas (por lo menos en
forma potencial).

II.10.2 Modelos de computación distribuida.

 Existen varios modelos fundamentales que se usan para la creación de
sistemas de cómputo distribuido, los cuales se clasifican en diferentes
categorías:

 Modelo de minicomputadora.
 Modelo de workstation.
 Modelo workstation-server.
 Modelo de pool de procesadores e híbrido.

Enseguida se presentan brevemente, junto con las notas distintivas

esenciales.

II.10.2.1 Modelo de minicomputadora.

Es simplemente la extensión del modelo de equipo centralizado. Este

esquema consiste de varias minicomputadoras conectadas por una red de
comunicación. Cada minicomputadora tiene su propio grupo de usuarios
quienes pueden tener acceso a otros recursos no presente en su sistema a
través de la red de datos.

Este modelo se usa cuando existe necesidad de compartir recursos de

diferentes tipos a través de acceso remoto.
 figura 2-12. Modelo de minicomputadora.

II.10.2.2 Modelo de workstation.

 Consiste en varias estaciones de trabajo (workstations) interconectadas
por una red, como lo muestra la figura 2-11, cada usuario se “da de alta” en
su computadora de inicio o “computadora home” y luego desde ahí puede

enviar trabajos para ejecución. Cada estación tiene su propio disco duro, y su
propio sistema de archivos. La implementación mostrada tiene la desventaja
de que se puede desperdiciar tiempo de procesamiento si una o más
computadoras no están haciendo uso de su CPU. Si el sistema determina que
la estación del usuario no posee la suficiente capacidad de proceso para una
tarea, transfiere el trabajo de forma automática hacia el equipo que tiene
menos actividad en ese momento y por último se regresa la salida del trabajo a
la estación del usuario.

figura 2-13. Modelo de Workstation.

II.10.2.3 Modelo workstation-server.

 Este se ilustra en la figura 2-12. Posee
varias microcomputadoras y varias estaciones
de trabajo (algunas de las cuales pueden ser
estaciones sin disco duro, o diskless)
comunicadas mediante red. Ahora que existe
la potencialidad de tener estaciones sin disco,
el sistema de archivos a usar por estas
computadoras puede ser el de una
computadora completa o alguno compartido
de las diferentes minicomputadoras del
sistema. Algunas otras microcomputadoras
se pueden usar para proveer otros tipos de
servicios, como base de datos, impresión,
etc. Estas máquinas cumplen ahora nuevas
tareas especializadas para proveer y
administrar acceso a los recursos, en la
 jerga común se les llama servidores
(servers).

figura 2-14. Modelo Workstation-Server.

II.10.2.4 Modelo de pool de procesadores.

Este se basa en el hecho de que los usuarios en promedio no

requieren capacidad de procesamiento durante un buen rato, pero existen
instantes en los que la actividad y los programas que ejecutan demandan
potencia de trabajo en alto grado. A diferencia del modelo anterior en el
que cada persona tiene su servidor asignado, en éste se dispone de un conjunto
(pool) de servidores que son compartidos y asignados conforme a demanda.
Cada procesador en el conjunto tiene su propia memoria y ejecuta un
programa de sistema o de aplicación que le permite participar en el
ambiente de cómputo distribuido.
 Se puede apreciar en la figura 2-13, que el modelo no soporta la
conexión de estaciones directamente a los servidores, sino solo por
medio de la red de interconexión. Las terminales usadas pueden ser
estaciones sin disco o terminales gráficas como X terminals.

Se tiene instalado un servidor especial llamado “de ejecución” el

cual se dedica a la administración y asignación de recursos conforme a
la demanda. Cuando se recibe una solicitud de una persona, este equipo
asigna temporalmente el número de servidores que deberán ser dedicados
al trabajo de tal petición, y luego de atenderla regresan para ser liberados y
quedar a disposición de la siguiente tarea. Otra diferencia importante con
otros
esquemas, es que aquí no existe el concepto de “computadora home”, de
manera que el usuario no se da de alta en alguna máquina en particular, pero sí
percibe al sistema como un todo.
 figura 2-15. Modelo pool de servidores.

Comparado con el modelo de Workstation-Server, el de Pool de Servers

permite una mejor utilización del poder de cómputo disponible en el ambiente
distribuido, dado que dicho poder computacional esta disponible para todos a
diferencia de Workstation-Server, donde varios equipos pueden estar
desocupados en algún momento pero su capacidad no se puede asignar a otros.
Por otra parte, esta metodología provee gran flexibilidad ya que el sistema se
puede expandir agregando procesadores que operarán como servidores
adicionales para soportar una carga extra de trabajo originada por incremento
en el número de usuarios o por la implantación de nuevos servicios.

Sin embargo, este modelo no se considera recomendado para

programas de cálculo complejo como aplicaciones intensivas de alto
rendimiento o aplicaciones basadas en gráficas. Esto se debe principalmente
a la lentitud de las redes de conexión que se utilizan para la comunicación
entre procesos. Para este tipo de tareas se considera mejor el modelo
Workstation-Server.

II.10.2.5 Modelo híbrido.

De los cuatro modelos descritos anteriormente, el de Workstation-

Server es el más ampliamente utilizado para la construcción de sistemas de
cómputo distribuido. Esto se debe a que un usuario promedio solamente
ejecuta tareas interactivas simples como editar archivos, enviar correos
electrónicos, etc. El modelo se ajusta perfectamente a especificaciones
tan sencillas.
 Para ambientes donde hay grupos de usuarios de mayor potencia
que realizan tareas masivas con alta necesidad de poder computacional el
modelo Pool de servidores es más adecuado.

El modelo híbrido permite combinar las mejores características de

Workstation-Server y Pool, esencialmente agregando a la red de estaciones de
trabajo un Pool de servidores que pueden ser asignados dinámicamente para
trabajos que son muy extensos para máquinas individuales o que necesitan
varios equipos concurrentemente para una ejecución adecuada.

Esta variante tiene la ventaja de garantizar el nivel de respuesta a trabajos interactivos dado que permite
la ejecución en la misma computadora de la persona que lo solicita. Por otra parte, su principal
desventaja estriba en que el costo de implantación se eleva puesto que requiere mayor número de
componentes para su construcción.

II.11 TDSO (Técnica de Desarrollo de Sistemas de Objetos).

TDSO es la técnica utilizada en éste proyecto para la especificación formal de los objetos creados
para el sistema. Este método fue desarrollado por la profesora Isabel Besembel [Besembel 99] y
presenta una serie de normas algorítmicas basadas en la integración de dos métodos de desarrollo de
sistemas programados. Uno es el método deductivo MEDEE propuesto por el investigador francés Jean
F. Dufourd como un método que engloba todas las tareas básicas de diseño de software, y la
metodología OMT de Rumbaugh et al, especialmente diseñada para modelar sistemas orientados por
objetos.

En rasgos generales, la técnica consiste en una serie de tablas que contienen el análisis, diseño y
documentación del objeto como tal. Uno de ellos es conocido como el universo de la clase el cual
engloba la declaración de los atributos y la especificación sintáctica de todos lo métodos presentes en el
objeto y así mismo se coloca al lado la información de éstos de acuerdo a su tipo ( transformación,
consulta, convertidor, etc) y su utilidad.
 Lo que más caracteriza a la técnica es la implementación de los métodos presentes en el objeto.
Dicha implementación se colocará en una tabla la cual tendrá un encabezado con el nombre del método,
así como las precondiciones y poscondiciones que sean necesarias para que el método se use de manera
correcta. Luego se colocará el cuerpo del método en un lado y en el otro la documentación de las
variables utilizadas en el desarrollo. Al final se colocan una serie de casos de pruebas del método como
modo de información.

Capítulo III. Diseño y especificaciones.

 En este capítulo se presentará la
identificación de los objetos tridimensionales
que intervienen en la escena, así como el
modelado general de los objetos y las
interacciones permitidas en la escena ya
construida. Dado que Java 3D no maneja
unidades de medida establecidas, tomamos
como referencia las unidades de
desplazamiento (ud), para la construcción de
las escenas virtuales.

Así mismo, en éste capítulo se mostrará el algoritmo de distribución

utilizado junto con la estructura general de cada uno de los servlets
empleados.

III.1 Entidades en la escena.

Para el diseño de la oficina virtual, se seleccionó los objetos más

sobresalientes contenidos en ella y se utilizó para su construcción objetos
“primitivos”, los cuales existen en todo lenguaje de programación de
ambientes tridimensionales, tales como cajas, cilindros, conos y esferas. Las
entidades principales de la escena son:

1. El entorno de paredes, techo y piso.

2. La silla.
3. La computadora.
4. El ventilador.
5. Las lámparas.
6. La columna.
7. El escritorio.

Dado que estos objetos serán construidos en Java 3D, uno de los
requerimientos, es el modelado del árbol de la escena para cada uno de ellos.
Este árbol es diseñado de forma tal que sea sencillo poderlo visualizar al ser
enviado por la red. Como cada objeto es una escena distinta, y cada escena es
dinámicamente agregada al universo virtual, entonces cada objeto tiene un
árbol de escena. Sin embargo, el diseño de estos árboles no es necesariamente
el mejor. Si se dispusiera a crear la oficina sin utilizar un enfoque distribuido,
el diseño podría ser completamente distinto. A continuación se describirá la
especificación de cada uno de ellos.

III.1.1 Entorno de paredes, techo y piso.

Se creó un entorno general, de tal modo que un solo objeto ( en este

caso un servlet) se encargara de crear las paredes laterales y trasera, el techo y
el piso de la oficina.
 Este entorno define el espacio de trabajo, y es la entidad más
importante. Todo el resto del ambiente de la oficina depende de su ubicación y
sus dimensiones. Uno de sus requerimientos, es que sea un espacio cómodo
para la visualización de todos los demás objetos contenidos en ella, así como
para su navegación.

Para la creación de las paredes, el techo y el piso, se utilizaron objetos

primitivos de cajas. A pesar de que al principio del diseño pareciera que cada
objeto se tratara de manera distinta, en realidad todos al final componen una
escena, que posteriormente se asignará dinámicamente al universo virtual.

III.1.1.1 Las paredes.

Cada pared lateral es un objeto tipo caja de 0.1 ud de ancho, 1.6 ud de

alto y 8 ud de profundidad como se muestra en la figura 3-1. Estas
dimensiones bien podrían corresponder a una escala específica en el mundo
real. Sin embargo, fueron elegidas por ser cómodas para visualizar y por
mostrar un espacio bastante aceptable.

Cada una de las paredes laterales ( izquierda y derecha) se ubican en el

punto (-3,0,0) y (3,0,0) en el universo virtual respectivamente.

Así mismo, la pared trasera de la oficina tiene dimensiones: 6 ud de

ancho, 1.7 ud de alto y 0.1 ud de profundidad, de forma tal que coincidiera
con las dimensiones y la ubicación de las paredes laterales y se encuentra
ubicado en la posición (0,0,-4) del universo virtual.

A las paredes no se le asignó alguna textura en especial, dado que de

por sí, ya dan el realismo que se necesita. Sin embargo, el color de cada pared
es el mismo y es el resultado de la combinación de colores en la forma RGB
( Red, Green, Blue).

1.6 ud

8 ud

0.1 ud

figura 3-1. Forma de una de las paredes laterales.

III.1.1.2 El techo y piso.
 El techo también es un objeto tipo caja cuyas dimensiones son: 6.1 ud
de ancho, 0.1 ud de alto y 8 ud de profundidad y se encuentra ubicado en la
posición (0,0.85,0). Así mismo el piso tiene dimensiones de 6.1 ud de ancho,
0.5 ud de alto y 8 ud de profundidad y esta ubicado en la posición (0,-0.8,0).
Si detallamos estos dos objetos nos daremos cuenta que en ancho y
profundidad son idénticos, pero en altura no. Eso es debido a que se quiere dar
el efecto de que el piso es como una tabla. La altura de éste es casi
despreciable. El entorno al ser construido, más bien pareciera una pequeña
caja, abierta por uno de sus lados, dado que no se creó una pared frontal para
que, de éste modo, pudiéramos apreciar el contenido de la oficina desde lejos.

III.1.1.3 Árbol de escena para el entorno.

De acuerdo a lo visto en el capítulo II, el nodo BG ( BranchGroup) es el

nodo principal, que contiene la escena, tal como un nodo raíz. Los nodos TG
(TransformGroup) son aquellos que contienen características propias del
objeto tridimensional tales como su ubicación, interacciones, etc. Este árbol
será creado por uno de los servlets, y será asignado dinámicamente al objeto
“SimpleUniverse”, esto se explicará con detalle mas adelante. La figura 3-2
muestra el árbol para ésta escena.

BG

TG TG TG TG TG
 Piso Techo
Pared Pared
Derecha Izquierda Pared

Trasera

figura 3-2. Árbol de escena del entorno de la oficina

III.1.2. La silla.

La silla es un objeto compuesto de cilindros y cajas, los cuales dan la

sensación de un asiento reclinado. Cada una de las dimensiones de los objetos
primitivos que componen la silla fueron tomados proporcionalmente a las
dimensiones del espacio disponible en el entorno de la oficina.

Para su diseño es mejor guiarse desde abajo hacia arriba. La silla esta
compuesta de una base con dos patas, la columna de la base, el asiento, dos
pequeñas columnas que sostendrán el respaldo y por último el respaldo. A
continuación se muestran las especificaciones de cada uno de estos objetos:

III.1.2.1 La base.

Esta compuesta por dos objetos tipo caja. Estos objetos son de la misma
dimensión de 0.03 ud de ancho, 0.03 ud de alto y 0.5 ud de profundidad. Se
encuentran en la misma ubicación (-1,-0.7,1) rotados 90 grados entre si en el
eje Y, tal como muestra la figura 3-3. El color elegido para las patas es el
negro.
 90º

figura 3-3. Esqueleto de la base de la silla

III.1.2.2 La columna base.

La columna de la base es un cilindro cuyo radio es de 0.015 ud y una

altura de 0.2 ud. la ubicación del cilindro es en el punto (-1,0.6,1) y el color
de la columna de la base es el negro. En la figura 3-4, se observa la forma de
la base completa de la silla.

figura 3-4. Esqueleto de la base completa de la silla

III.1.2.3 El asiento.

El asiento es un objeto tipo caja con dimensiones 0.4 ud de ancho, 0.08 ud de alto y 0.36 de
profundidad. La ubicación de éste es en la posición (-1, -0.5,1) del universo virtual. El color del asiento
es el rojo.
III.1.2.4 Columnas del respaldo.

Las columnas del respaldo son dos cilindros con las mismas
dimensiones de 0.015 ud de radio y 0.35 ud de alto. Cada cilindro esta rotado
en el eje Z -15 grados. El color de las columnas es el negro y están
ubicadas en los puntos (-0.83,-0.3,0.9) y ( -0.83,-0.3,1.1) respectivamente.
III.1.2.5 El respaldo.

El respaldo es un objeto tipo caja con dimensiones 0.04 ud de ancho

0.26 ud de alto y 0.4 ud de profundidad. Su ubicación es en el punto ( -0.82,
-0.2,1) y el color de su entorno es el rojo.

En la figura 3-5 se puede apreciar lo que sería el esqueleto aproximado

de la silla.
 figura 3-5. Esqueleto de la silla

III.1.2.6 Árbol de escena para la silla.

A continuación se muestra como sería el modelado del árbol de escena para la silla. Como se
expresó, el diseño de los árboles varía. Pero para que el diseño sea transparente los nodos de tipo TG
(TransformGroup) los acoplamos a la misma altura. En la figura 3-6 se observa el árbol para la silla.

BG

TG TG TG TG TG TG TG

Respaldo

Pata1
Pata2 asiento Columnar
esp2

Columna
base Columna
resp1

figura 3-6. Árbol de escena para la silla.

III.1.3 La computadora.

La computadora es el resultado de la combinación de objetos tales como una esfera, un cono y

objetos tipo caja.

A continuación mostramos en la tabla 3-1 con las especificaciones de cada objeto.

 Nombre Tipo Descripción Medidas Posición Color

Pantalla Esfera Dá el efecto 0.13 de radio X =-1, Negro

oblicuo de la Y=-0.05
pantalla. Z =-1.2

Entorno Caja Cubre por la Ancho = 0.04 X =-1.11, Blanco

Izquierdo izquierda la Y=-0.05
Alto = 0.26
pantalla. Z =-1.2
Pdad = 0.26

Entorno Caja Cubre por la Ancho = 0.04 X =-0.89 Blanco

Derecho Derecha la Y=-0.05
Alto = 0.26
pantalla. Z =-1.2
Pdad = 0.26

Entorno de Caja Cubre por Ancho = 0.26 X =-1, Blanco

Arriba encima la Y=0.06
Alto = 0.04
pantalla Z =-1.2
Pdad = 0.26

Entorno de Caja Cubre por Ancho = 0.26 X =-1, Blanco

Abajo debajo de la Y=-0.16
Alto = 0.04
pantalla. Z =-1.2
Pdad = 0.26

Entorno de Caja Cubre por Ancho = 0.26 X =-1, Blanco

Atrás detrás de la Y=-0.05
Alto = 0.26
pantalla. Z =-1.31
Pdad = 0.04
 Entorno Caja Da la Ancho = 0.04 X =-1.12, Blanco
Izquierdo 1 impresión del Y=-0.05
Alto = 0.26
ancho del Z =-1.08
Pdad = 0.06
monitor por la
Izquierda.

Entorno Caja Dá la Ancho = 0.04 X =-0.88, Blanco

Derecho 1 impresión del Y=-0.05
Alto = 0.26
ancho del Z =-1.08
Pdad = 0.06
monitor por la
Derecha.

Entorno Caja Dá la Ancho = 0.28 X =-1, Blanco

Arriba 1 impresión del Y=-0.08
Alto = 0.04
ancho del Z =-1.08
Pdad = 0.06
monitor por
arriba.

Entorno Caja Dá la Ancho = 0.28 X =-1, Blanco

Abajo 1 impresión del Y=-0.18
Alto = 0.04
ancho del Z =-1.08
Pdad = 0.06
monitor por
abajo.

Soporte Cono Es el soporte Radio = 0.11 X =-1, Blanco

de la base Y=-0.19
Alto = 0.1
debajo del Z =-1.2
monitor.

Base Monitor Caja Es la base del Ancho = 0.24 X =-1, Blanco

monitor Y=-0.24
Alto = 0.02
 Pdad = 0.24 Z =-1.2

CPU Caja Muestra la Ancho = 0.1 X =-1.3, Blanco

impresión del Y=-0.09
Alto = 0.3
Case Z =-1.2
Pdad = 0.26

CD Caja Es la unidad Ancho = 0.08 X =-1.295, Gris

de CD Y=-0.04
Alto = 0.03
Z =-1.055
Pdad = 0.02

Floppy Caja Es la unidad Ancho= 0.6 X =-1.295 Gris

de disco 3 ½ Alto = 0.04 Y = -0.08

Pdad = 0.02 Z =-1.055

tabla 3-1. Especificaciones de los objetos que componen la computadora

Al tener las especificaciones propias de cada objeto de la computadora, el árbol de escena se

construye de forma similar a los anteriores.

III.1.4 El ventilador.

El ventilador está compuesto de dos paletas de tipo caja, las cuales están ubicadas en el mismo
punto y rotadas en el eje Y 90 grados entre si. Así mismo, contiene un soporte de tipo cilindro que se puede
reconocer como el sostenedor de las paletas. También tiene la columna soporte de donde estará colgado el
ventilador y el soporte del techo que es un objeto de tipo cono.

Las especificaciones de la escena ventilador se muestran en la tabla 3-2

 Nombre Tipo Descripción Medidas Posición Color

Paleta 1 y 2 Caja Las paletas del Ancho = 0.1 X =0 Blanco

ventilador Y=0.4
Alto = 0.01
Z =0
Pdad = 0.8

Soporte Cilindro Es el soporte Radio = 0.1 X =0 Blanco

de las paletas Y=0.4
Alto = 0.03
del ventilador Z =0

Columna Cilindro Es la columna Radio = 0.01 X =0 Blanco

que sostiene el Alto = 0.3 Y=0.55
ventilador Z =0
desde el techo.

Sostenedor Cono Es la base del Radio = 0.05 X =0 Blanco

ventilador que Alto = 0.05 Y=0.7
lo mantiene Z =0
unido al techo

tabla 3-2. Especificaciones de los objetos que componen el ventilador.

III.1.5 Las lámparas.

Se hace referencia a las lámparas de la oficina, a aquellas que están presentes en el techo, estas
están formadas básicamente por objetos de tipo caja con dimensiones: 1 ud de ancho, 0.05 ud de alto, y 1.2
ud de profundidad. Se crearon 4 lámparas del mismo tipo distribuyéndolas equidistantes a las 4 esquinas
del techo de la oficina.

III.1.6 La columna.
 La columna es en sí, un cilindro que une el techo y el piso. El cilindro tiene dimensiones 0.2 ud de
radio y 1.6 ud de alto. De éste modo la columna cubre toda la altura de la oficina. Y se encuentra ubicada
en el punto (1,0,-2.5) de la escena.

III.1.7 El escritorio.

El escritorio está compuesto completamente de puros objetos tipo caja, los cuales nos presentan un
diseño de una mesa de trabajo bastante amplia en dos secciones.

Las especificaciones del escritorio se muestran a continuación en la tabla 3-3.

Nombre Descripción Medidas Posición

Lateral Es el entorno izquierdo de soporte del Ancho = 0.05 X = -2

Izquierdo escritorio. Y= -0.5
Alto = 0.6
Z =0
Pdad = 4

Lateral Es el entorno derecho de soporte del Ancho = 0.05 X =0.4

Derecho escritorio Y=-0.5
Alto = 0.6
Z =0
Pdad = 4

Trasero Es el entorno trasero de soporte del Ancho = 3 X =-0.5

escritorio. Y=-0.5
Alto = 0.6
Z =-1.975
Pdad = 0.05

Lateral Es el respaldo por encima de la base en Ancho = 0.4 X =-2

Izquierdo el lado izquierdo. Y=-0.2
Alto = 0.02
Arriba Z =0
Pdad = 4

Lateral Es el respaldo por encima de la base en Ancho = 0.4 X =0.4

Derecho
 Arriba el lado derecho. Alto = 0.02 Y=-0.2

Pdad = 4 Z =0

Trasero Es el respaldo por encima de la base en Ancho = 2 X =-0.8

Arriba 1 la parte de atrás para la primera Y=-0.2
Alto = 0.02
sección. Z =-1.8
Pdad = 0.4

Trasero Es el respaldo por encima de la base en Ancho = 0.4 X =0.8

Arriba 2 la parte de atrás para la segunda Y=-0.2
Alto = 0.02
sección. Z =-1.8
Pdad = 0.4

Respaldo Es el segundo respaldo de la primera Ancho = 2.36 X =-0.788

Trasero 1 sección en la parte de atrás. Y=-0.4
Alto = 0.02
Z =-1.55
Pdad = 0.8

Respaldo Es el segundo respaldo de la segunda Ancho = 0.56 X =0.7125

Trasero 2 sección en la parte de atrás. Y=-0.4
Alto = 0.02
Z =-1.55
Pdad = 0.8

Respaldo Es el segundo respaldo para las Ancho = 1.2 X =0.4

lateral secciones 1 y 2 en el lado izquierdo. Y=-0.4
Alto = 0.02
izquierdo Z =0.2
Pdad = 2.6

tabla 3-3. Especificaciones de los objetos que componen el escritorio

III.2 Interacciones en el ambiente.

El escenario virtual creado solo admite tres tipos de interacciones con el usuario:
1. La primera es encender y apagar las luces que intervienen en la escena. Esta acción se ejecuta al pulsar
clic con el ratón. En la escena existen 4 puntos de luz principales, dado que existen 4 lámparas, de los
cuales solo se apagan 3. El cuarto punto de luz se deja encendido para poder visualizar la escena con
mínima iluminación.
2. Las segunda interacción es encender y apagar el ventilador, la misma se ejecuta al pulsar cualquier
“tecla imprimible” ( entiéndase por tecla imprimible, a cualquiera que haga referencia a números o
letras ).
3. La tercera y última interacción es la de recorrido en el ambiente por medio de las teclas la navegación
( las cuatro flechas del teclado).

III.3 Modelado del sistema distribuido.

Para la creación del ambiente virtual por medio de la distribución de procesos basado en servlets,
se debe introducir primero una visión general de la estructura de un servlet y luego se mostrará como se
distribuyeron cada uno de éstos para poder construir la escena.

III.3.1 Especificación formal en TDSO de los componentes utilizados en la implantación del ambiente
virtual distribuido.

En la implantación del ambiente distribuido se requiere de la especificación de los servlets que

intervienen en él, así como los programas que son necesarios para la comunicación y creación del escenario
virtual.

III.3.1.1 Especificación formal de un servlet.

Un servlet, no es más que una clase que hereda de otra, y que de acuerdo a la forma de diseño que
se disponga puede servir para responder ante un formulario desde una página web o para procesar objetos
complejos que nos permitan acoplar información.

El camino más sencillo para distribuir objetos utilizando “servlets”, es pensar en éstos como si
fueran servidores de petición - respuesta construidos bajo el enfoque de “sockets”. Así, si éste quiere leer
un dato cualquiera desde la red esperará hasta recibirlo y si en vez de recibir desea enviar, debe existir
algún programa o medio receptor.
 La estructura general de un servlet se especifica en la tabla 3-4:

ServletObjeto extiende de HttpServlet

Atributos privados Ob: es el objeto el cual se desea distribuir. El

mismo es personalizado y no solo se limita a
Ob : Objeto a distribuir
uno. Pueden existir varios de distinto tipo.

Operaciones : puede ser uno o varios

Operaciones públicas
métodos públicos o privados que procesan
información del objeto. Como ejemplo

//cualquier tipo de operación pública puede ser comunicaciones con bases de

personalizada. datos, construcción del o los objetos como

tal, etc.
Operaciones(Parámetros);

Service : es el método base de servicio del

//operaciones comunes, propias de los
servlet. Antes de ejecutar cualquier servicio
servicios..
como doPost o doGet éste se ejecuta
service( HttpServletRequest request, primero.
HttpServletResponse response );

Init: es el método de iniciación del servlet,

init(); éste se puede considerar como otro
destroy(); constructor. Este método si se quiere puede
o no ser re-escrito.

doPost( HttpServletRequest request,

HttpServletResponse response ); Destroy: este método es llamado cada vez
que el servlet termina sus servicios. Puede
 ser o no sobrescrito y puede ser utilizado
para terminar, por ejemplo, alguna
doGet( HttpServletRequest request,
comunicación interna con una base de
HttpServletResponse response );
datos.

DoPost: este método se encarga de procesar

el servicio de recepción y envío de datos por
medio del método post.

DoGet: este método se encarga de procesar

el servicio de recepción y envío de datos por
medio del método get.

tabla 3-4. Especificación general de un servlet en TDSO

A parte de todas los métodos públicos o privados que deseemos realizar para nuestra clase como
parte del diseño, lo más importante es escoger cual o cuales métodos de servicios del servlet necesitamos
sobrescribir. Los métodos pueden ser elegidos según la elección del programador.

En nuestro caso, seleccionamos el método service por ser la función base del servicio. El diseño
interno de comunicación con el cliente para el sistema distribuido, es más parecido a la programación en
sockets que otra cosa.

A continuación se muestra en la tabla 3-5 la cual es la especificación en TDSO de la re-escritura

del método service:

service( HttpServletRequest request, HttpServletResponse response)

{preCond: Exista un medio emisor} {postCond: Exista un medio
receptor}

//iniciando comunicación. Pidiendo permiso EntradaFlujoObjetos,

de lectura SalidaFlujoObjetos: estas clases son las
encargadas de la lectura y escritura de
EntradaFlujoObjetos efo =
nuevaDir( request.obtenerEntradaFlujoObjet objetos complejos por medio de archivos o
en nuestro caso una red.
os() );

ObjetoPer: es un objeto personalizado

ObjetoPer ob =
creado por el diseñador. Éste objeto debe ser
(ObjetoPer)efo.obtenerObjeto();
serializado para poder ser leído o escrito.

Efo.cerrar();

//procesar la información del objeto

//pidiendo permiso de escritura.

SalidaFlujoObjetos sfo =
nuevaDir( response.obtenerSalidaFlujoObjet
os() );

sfo.escribirObjeto( ob );

sfo.cerrar();
 tabla 3-5. Especificación en TDSO de la re-escritura del método “service”.

Ahora que se tiene el esquema general de la redefinición del método service, podemos tener una
idea de cómo una aplicación podría comunicarse con el servlet. Generalmente esta clase de aplicaciones
utiliza direcciones y objetos URL para poder iniciar la comunicación e intercambio de información. En la
tabla 3-6 mostramos una aplicación de ejemplo que se comunica con un servlet cuyo método service esté
redefinido y el servlet efectúe cambios en el objeto para que luego éste sea devuelto al programa de
aplicación.

Programa de prueba de comunicación

{preCond: Exista el servlet receptor y el objeto} {postCond: objeto modificado}

ObjetoPer ob = nuevaDir ObjetoPer; EntradaFlujoObjetos,

SalidaFlujoObjetos: estas clases son las
ob.asignarDatos();
encargadas de la lectura y escritura de
objetos complejos por medio de archivos o
ob.mostrarDatos(); en nuestro caso una red.

ConexionURL url = ObjetoPer: es un objeto personalizado

nuevaConexion( ServletDir ); creado por el diseñador. Éste objeto debe ser
serializado para poder ser leído o escrito.

//pidiendo permiso de escritura.

SalidaFlujoObjetos sfo = ob.asignarDatos(): es un método

nuevaDir( url.obtenerSalidaFlujoObjetos() ); personalizado de la clase ObjetoPer el cual

permite asignar valores a los atributos de la
clase.
//enviando datos al servlet ob.mostrarDatos(): este método permite
mostrar sea en pantalla o en ventanas el
sfo.escribirObjeto( ob );
contenido de los atributos del objeto.
sfo.cerrar();

ConexiónURL: éste objeto se encarga de la

comunicación vía url y abre la conexión con
el servidor remoto. La dirección está dada

// Pidiendo permiso de lectura por el ServletDir, una variable de tipo

cadena que indica la dirección url del
EntradaFlujoObjetos efo =
servlet.
nuevaDir( url.obtenerEntradaFlujoObjetos()
);

// leyendo datos cambiados

ob = (ObjetoPer)efo.obtenerObjeto();

efo.cerrar();

ob.mostrarDatos();

url.cerrarConexion();

tabla 3-6. Especificación en TDSO de una aplicación que permite la comunicación con un servlet.

Básicamente el programa de ejemplo especificado en la tabla 3-6, crea un objeto personalizado

llamado “ob”, al cual se le asignan una serie de valores que servirán para ser procesados por el servlet, cuya
dirección está especificada por la variable de tipo cadena ServletDir. De éste modo, el servlet tomará los
datos, los procesará y cambiará sus valores para luego enviarlos nuevamente al programa de aplicación. Así
cuando el programa reciba el objeto modificado mostrará sus datos y cerrará la conexión.

A simple vista, pareciera no tener sentido enviar un objeto y recibirlo modificado, pero es tan solo
una visión general de cómo un servlet puede comportarse como si fuera un servidor basado en el enfoque de
“sockets”, claro que con mayores ventajas que ellos.

III.3.2 Diseño y especificación de la arquitectura distribuida para la construcción del ambiente

virtual.

Habiendo observado la forma general de comunicación con los servlets a través de un programa de
aplicación, podemos construir un sistema donde cada servlet se encargue literalmente de crear un objeto
3D, como una silla o un escritorio, el cual será enviado por la red a una aplicación que lo reciba y lo ingrese
dinámicamente al universo virtual.

Dado que existen siete distintas entidades tridimensionales que componen la oficina, cada una de
ellas será creada por diferentes servlets. La disposición de los servlets será en cuatro servidores, tal como se
muestra en la figura 3-7.

Servidor 1 Servidor 2 Servidor 3 Servidor 4

Silla
Columna Computadora

Escritorio Ventilador
Paredes lamparas

figura 3-7. Disposición de los servlets en los servidores.

La forma de distribuir los servlets en los servidores no es única. Otra forma de diseño podría ser,
disponer de siete servidores en vez de cuatro, en vista de que son siete objetos distintos. Lo que se desea, es
evaluar la calidad de desempeño de un servlet en particular frente a un proceso lo suficientemente
“pesado”. Un objeto tridimensional puede llevar un considerable tiempo de cálculo en cuanto a ubicación,
forma, tamaño y distribución del color. Cada entidad que compone la oficina está formado por más de un
objeto tridimensional básico (entiéndase por objeto 3D básico, aquellos que son cubos, conos, cilindros o
esferas), por lo que se considera que para crear una entidad en especial, así como el transporte de toda esa
información por la red permite evaluar la robustez de un servlet.

La forma de diseño de cada uno de los servlets es similar. Lo único que cambia es el contenido de
la escena que será transportada por la red. De éste modo, sólo es necesario conocer como diseñar uno de
ellos y todos los demás pueden ser creados de la misma manera. A continuación se muestra en las tablas 3-
7, 3-8 y 3-9 la especificación formal del servlet encargado de crear el entorno de la oficina (las paredes, el
techo y el piso), y la implantación de cada método respectivamente:

ServletParedes extiende de HttpServlet

CrearApariencia: es la función encargada

de asignar la apriencia de color y material
Operaciones públicas
del cual está compuesto el objeto.

CrearApariencia(Color s, Color d):

Apariencia
service( HttpServletRequest request,
HttpServletResponse response );
Service : es el método base de servicio del
servlet. Este se comporta como la base de la
comunicación con el cliente y crea la entidad
tridimensional.
 tabla 3-7. Especificación del servlet que crea el entorno de la oficina.

crearApariencia( Color s, Color d) : Apariencia

{preCond: } {postCond: devuelve un objeto de

tipo apariencia }

Apariencia ap = nuevaDir Apariencia; Apariencia: objeto encargado de tener las

especificaciones del material del objeto, así
Material m = nuevaDir Material;
como las propiedades de los polígonos que
m.asignarColorEspecular(s);
componen el objeto 3D.
m.asignarColorDifuso(d);

m.asignarBrillo(50);
Material: objeto que tiene las propiedades
ap.asignarMaterial(m); de color y textura y especificaciones del
objeto.

devolver ap;

tabla 3-8. Método que se encarga de crear la apariencia de cada objeto que compone la entidad.

Service( HttpServletRequest request, HttpServletResponse response)

{preCond: Exista un medio emisor} {postCond: Exista un medio

receptor}
Color azul = nuevaDir Color( 0f,0f,1f); SalidaFlujoObjetos: Es la
Color celesteLigero = nuevaDir Color(0.35f, 0.4f, 0.6f); encargada de la escritura de
Color colorParedes = nuevaDir Color(0.9f,0.9f,0.65f);
Color blanco = nuevaDir Color ( 1f,1f,1f ); objetos complejos por medio de
archivos o en nuestro caso una
//diseñando el objeto 3D red.
Transformacion t = nuevaDir;
t.trasladar( nuevaDir Vector( -3f, 0f, 0f));
GrupoTransformación grupoIzquierdo = nuevaDir
Transformación: es el objeto
GrupoTransformación(t);
encargado de definir
Caja paredIzquierda = NuevaDir Caja( 0.05f, 0.8f, 4f , coordenadas de ubicación,
Caja.GENERAR_NORMALES, crearApariencia(blanco, rotación o traslado dinámico de
colorParedes) ); un objeto 3D.
grupoIzquierdo.agregarHijo(paredIzquierda);

t.trasladar( NuevaDir Vector3f( 3f, 0f, 0f)); GrupoTransformación: es el

GrupoTransformacion grupoDerecho = NuevaDir objeto de tipo Grupo de Java3D
GrupoTransformacion(t); encargado de contener
Caja paredDerecha = NuevaDir Caja( 0.05f, 0.8f, 4f , información de tipo
Caja.GENERAR_NORMALES, crearApariencia(blanco,
colorParedes) ); transformación para el objeto
grupoDerecho.agregarHijo(paredDerecha); 3D.

t.trasladar( NuevaDir Vector3f( 0f, 0f, -4f));

GrupoTransformacion grupoTrasero = NuevaDir Caja: crea un objeto tipo caja
GrupoTransformacion(t);
el cual recibe el ancho, alto y
Caja paredTrasera = NuevaDir Caja(3f, 0.85f, 0.05f ,
Caja.GENERAR_NORMALES, crearApariencia(blanco, profundidad, así como opciones
colorParedes) ); grupoTrasero.agregarHijo(paredTrasera); de creación y apariencia.

t.trasladar( NuevaDir Vector3f( 0f, 0.85f, 0f));

GrupoTransformacion grupoTecho = NuevaDir Mapa: es el objeto parecido a
GrupoTransformacion(t);
Caja techo = NuevaDir Caja( 3.05f, 0.05f, 4f ,
una tabla hash el cual contiene
Caja.GENERAR_NORMALES, crearApariencia(blanco, la información del árbol de
celesteLigero) ); escena de la entidad.
grupoTecho.agregarHijo(techo);

t.trasladar( NuevaDir Vector3f( 0f, -0.80f, 0f)); Escena: es el objeto que

GrupoTransformacion grupoPiso = NuevaDir
GrupoTransformacion(t); contiene toda la escena y sus
Caja piso = NuevaDir Caja( 3.05f, 0.025f, 4f , especificaciones y que será
Caja.GENERAR_NORMALES, crearApariencia(blanco, azul) ); añadido al universo virtual
grupoPiso.agregarHijo(piso);

Escena bg = NuevaDir Escena();

agregarHijo: es un método
bg.agregarHijo(grupoIzquierdo);
bg.agregarHijo(grupoDerecho); propio de los objetos tipo grupo
bg.agregarHijo(grupoTrasero); que permite añadir un nuevo
bg.agregarHijo(grupoTecho); hijo al árbol de escena.
bg.agregarHijo(grupoPiso);

Fondo fondo = NuevaDir Fondo();

trasladar: se encarga de
 fondo.setColor(1.0f, 1.0f, 1.0f); trasladar el objeto
fondo.setApplicationBounds(NuevaDir BoundingSphere()); tridimensional a las
bg.agregarHijo(fondo);
coordenadas especificadas por
//fin del diseño el vector tridimensional.
//creación del mapa de escena.
Mapa map = NuevaDir Mapa(10);
map.poner("Izquierda", grupoIzquierdo); Vector: crea un nuevo vector
map.poner("Izquierda", paredIzquierda );
tridimensional.
map.poner("Derecha", grupoDerecho);
map.poner("Derecha", paredDerecha);
map.poner("Atras", grupoTrasero);
map.poner("Atras", paredTrasera); Fondo: es el fondo del entorno
map.poner("Arriba", grupoTecho); de la escena.
map.poner("Arriba", techo);
map.poner("Abajo", grupoPiso);
map.poner("Abajo", piso);

//pidiendo permiso de escritura.

SalidaFlujoObjetos sfo =
nuevaDir( response.obtenerSalidaFlujoObjetos() );

sfo.escribirObjeto( bg, map );

sfo.cerrar();

tabla 3-9. Método principal de comunicación del servlet con el cliente.

El programa principal se diseñó a partir de hilos de control que se encargan de comunicarse con
cada uno de los servlets en los diferentes servidores. En la figura 3-8 se muestra la acción de los hilos entre
el programa principal que administra la comunicación y los servlets y se puede observar la relación con la
figura 3-7.

Programa

principal

Universo Virtual

Hilo 1 Hilo 2 Hilo 3 Hilo 4 Hilo 5 Hilo 6 Hilo 7

 Servidor 1 Servidor 2 Servidor 3 Servidor 4

Silla
Columna Computadora

Escritorio Ventilador
Paredes lámparas

figura 3-8. Estructura de comunicación con los servlets.

En la figura 3-8 se puede observar que cada hilo de control tiene predefinido un servidor en
especial y un servlet que responderá con un objeto de la oficina. Esto se nota por los colores de las flechas.
Por ejemplo el hilo 1 debe conectarse al servidor 1 hacia el servlet paredes, el hilo 2 debe conectarse al
servidor 2 hacia el servlet columna y así sucesivamente. Cuando cada servlet responda, devolverá la escena
que será dinámicamente agregada al universo virtual. El tiempo de respuesta de cada servlet es registrado
así como de cada servidor y posteriormente se le agrega al universo virtual las propiedades de cada escena.

Así en la figura 3-8 no solo se tiene la estructura del programa principal sino también del sistema
distribuido. La forma de distribuir el proceso de construcción de la oficina permite visualizar la respuesta
dinámica de cada servidor. Pero la distribución se podría limitar a que siga un patrón en especial, sea a
nivel de servlets o a nivel de hilos de control. Por ejemplo un servlet podría esperar hasta que otro responda
para enviar la escena que le corresponde, o también darle prioridades a los hilos para que se ejecuten. El
camino más sencillo sin embargo, es enviar las peticiones por medio de todos los hilos y que
dinámicamente según responda cada servidor, se asignen las escenas al universo.

III.3.3 Estructura de clases creadas para la implantación del programa.

 Para la implantación del sistema distribuido se crearon una serie de clases con funciones
específicas para mejorar la estructura de comunicación y recepción de los objetos que envían los distintos
servlets. En la tabla 3-10 se muestran todas las clases que participan en el programa principal, así como una
breve información de la función que desempeña cada una:

Clases creadas para la implantación del sistema distribuido

VirtualScene: es la clase que contiene el programa

principal encargado de administrar la comunicación
- VirtualScene y los tiempos de respuesta de cada servidor.
- SceneConnetion
- SceneConstructor SceneConnection: esta clase se encarga de la
comunicación con el servlet que se le indique, así
- FirstServer
como la lectura de la escena que será asignada al
- SecondServer universo virtual.
- ThirdServer
- FourthServer SceneConstructor: se encarga de contener una serie
- VentilatorBehavior de funciones que permitan incluir propiedades al
ambiente virtual.
- LightsBehavior

XxxServer: son clases que efectúan la comunicación

con cada servidor según su servlet. Estas leen e
incluyen la escena al universo virtual.

XxxBehavior: son clases encargadas de contener el

tipo de evento que se ejecutará en la oficina.

tabla 3-10. Clases que intervienen en la implantación del sistema distribuido.

En la figura 3-9 se muestra la relación que existe entre cada clase al momento de ejecutarse el
programa principal. La forma de diseño de la comunicación con cada servlet según su servidor no es la
única y no se descarta la posibilidad de la creación de una mejor estructura para el programa principal.

VirtualScene

Hilo 1 Hilo 2 Hilo 3 Hilo 4 Hilo 5 Hilo 6 Hilo 7

 FirstServer SecondServer ThirdServer FourthServer

SceneConnection Añadiendo SceneConstructor

propiedades al
objeto

Conexión con los Objeto de la Ingresando el

servidores oficina objeto

Servlet remoto Universo virtual

figura 3-9. Interacción de las clases que intervienen en el sistema distribuido.

La clase “VirtualScene” es la clase principal de administración de la comunicación con cada

servlet según su servidor, así como la inicialización del “Universo virtual” y cada hilo. El “Universo
virtual” es pasado como referencia a las clases “XxxServer” las cuales se encargarán de la comunicación e
inserción de propiedades a la escena leida. Cada “XxxServer” utiliza para la comunicación y la lectura un
objeto SceneConnection y toma el tiempo inicial y final de la comunicación. Así mismo, el objeto leído es
pasado a la clase SceneConstructor la cual incluirá propiedades como rotación, traslación o eventos ( estos
últimos por medio de las clases “XxxBehavior”). Luego de agregar los toques finales al objeto
tridimensional se dispone a ingresarlo al “Universo virtual”, el cual se encargará de mostrar el objeto en el
plano de imagen.

III.3.4 El modelo de distribución.

El esquema de distribución al que más se asemeja al momento de realizar las pruebas es al

“modelo de minicomputadora”, pero esto depende de cómo se quieran distribuir las computadoras. Para el
caso de las pruebas realizadas, dos de los servidores se encuentran en el cubículo del profesor tutor, junto
con el programa principal y los otros dos servidores se encuentran en el laboratorio 114 de la facultad de
ingeniería. De modo tal, que cuando cuando se ejecute la comunicación con algún servlet del laboratorio
114, se debe pasar primero por el servidor de la red local para luego ingresar a la red de la universidad, la
cual enrutará la petición hacia el servidor del laboratorio y por último a la estación que contiene el servlet.
Según éste esquema, se puede intuir que por lo visto en el capítulo anterior el modelo es muy parecido al
de minicomputadora.

Capítulo III. Diseño y especificaciones.

En este capítulo se presentará la

identificación de los objetos tridimensionales
que intervienen en la escena, así como el
 modelado general de los objetos y las
interacciones permitidas en la escena ya
construida. Dado que Java 3D no maneja
unidades de medida establecidas, tomamos
como referencia las unidades de
desplazamiento (ud), para la construcción de
las escenas virtuales.

Así mismo, en éste capítulo se mostrará el algoritmo de distribución

utilizado junto con la estructura general de cada uno de los servlets
empleados.

III.1 Entidades en la escena.

Para el diseño de la oficina virtual, se seleccionó los objetos más

sobresalientes contenidos en ella y se utilizó para su construcción objetos
“primitivos”, los cuales existen en todo lenguaje de programación de
ambientes tridimensionales, tales como cajas, cilindros, conos y esferas. Las
entidades principales de la escena son:

8. El entorno de paredes, techo y piso.

 9. La silla.
10.La computadora.
11.El ventilador.
12.Las lámparas.
13.La columna.
14.El escritorio.

Dado que estos objetos serán construidos en Java 3D, uno de los
requerimientos, es el modelado del árbol de la escena para cada uno de ellos.
Este árbol es diseñado de forma tal que sea sencillo poderlo visualizar al ser
enviado por la red. Como cada objeto es una escena distinta, y cada escena es
dinámicamente agregada al universo virtual, entonces cada objeto tiene un
árbol de escena. Sin embargo, el diseño de estos árboles no es necesariamente
el mejor. Si se dispusiera a crear la oficina sin utilizar un enfoque distribuido,
el diseño podría ser completamente distinto. A continuación se describirá la
especificación de cada uno de ellos.

III.1.1 Entorno de paredes, techo y piso.

Se creó un entorno general, de tal modo que un solo objeto ( en este

caso un servlet) se encargara de crear las paredes laterales y trasera, el techo y
el piso de la oficina.

Este entorno define el espacio de trabajo, y es la entidad más

importante. Todo el resto del ambiente de la oficina depende de su ubicación y
sus dimensiones. Uno de sus requerimientos, es que sea un espacio cómodo
para la visualización de todos los demás objetos contenidos en ella, así como
para su navegación.

Para la creación de las paredes, el techo y el piso, se utilizaron objetos

primitivos de cajas. A pesar de que al principio del diseño pareciera que cada
objeto se tratara de manera distinta, en realidad todos al final componen una
escena, que posteriormente se asignará dinámicamente al universo virtual.

III.1.1.1 Las paredes.

Cada pared lateral es un objeto tipo caja de 0.1 ud de ancho, 1.6 ud de

alto y 8 ud de profundidad como se muestra en la figura 3-1. Estas
dimensiones bien podrían corresponder a una escala específica en el mundo
real. Sin embargo, fueron elegidas por ser cómodas para visualizar y por
mostrar un espacio bastante aceptable.

Cada una de las paredes laterales ( izquierda y derecha) se ubican en el

punto (-3,0,0) y (3,0,0) en el universo virtual respectivamente.

Así mismo, la pared trasera de la oficina tiene dimensiones: 6 ud de

ancho, 1.7 ud de alto y 0.1 ud de profundidad, de forma tal que coincidiera
con las dimensiones y la ubicación de las paredes laterales y se encuentra
ubicado en la posición (0,0,-4) del universo virtual.
 A las paredes no se le asignó alguna textura en especial, dado que de
por sí, ya dan el realismo que se necesita. Sin embargo, el color de cada pared
es el mismo y es el resultado de la combinación de colores en la forma RGB
( Red, Green, Blue).

1.6 ud

8 ud

0.1 ud

figura 3-1. Forma de una de las paredes laterales.

III.1.1.2 El techo y piso.

El techo también es un objeto tipo caja cuyas dimensiones son: 6.1 ud

de ancho, 0.1 ud de alto y 8 ud de profundidad y se encuentra ubicado en la
posición (0,0.85,0). Así mismo el piso tiene dimensiones de 6.1 ud de ancho,
0.5 ud de alto y 8 ud de profundidad y esta ubicado en la posición (0,-0.8,0).
Si detallamos estos dos objetos nos daremos cuenta que en ancho y
profundidad son idénticos, pero en altura no. Eso es debido a que se quiere dar
el efecto de que el piso es como una tabla. La altura de éste es casi
despreciable. El entorno al ser construido, más bien pareciera una pequeña
caja, abierta por uno de sus lados, dado que no se creó una pared frontal para
que, de éste modo, pudiéramos apreciar el contenido de la oficina desde lejos.

III.1.1.3 Árbol de escena para el entorno.

De acuerdo a lo visto en el capítulo II, el nodo BG ( BranchGroup) es el

nodo principal, que contiene la escena, tal como un nodo raíz. Los nodos TG
(TransformGroup) son aquellos que contienen características propias del
objeto tridimensional tales como su ubicación, interacciones, etc. Este árbol
será creado por uno de los servlets, y será asignado dinámicamente al objeto
“SimpleUniverse”, esto se explicará con detalle mas adelante. La figura 3-2
muestra el árbol para ésta escena.

BG

TG TG TG TG TG

Piso Techo
Pared Pared
Derecha Izquierda Pared

Trasera
figura 3-2. Árbol de escena del entorno de la oficina

III.1.2. La silla.

La silla es un objeto compuesto de cilindros y cajas, los cuales dan la

sensación de un asiento reclinado. Cada una de las dimensiones de los objetos
primitivos que componen la silla fueron tomados proporcionalmente a las
dimensiones del espacio disponible en el entorno de la oficina.

Para su diseño es mejor guiarse desde abajo hacia arriba. La silla esta
compuesta de una base con dos patas, la columna de la base, el asiento, dos
pequeñas columnas que sostendrán el respaldo y por último el respaldo. A
continuación se muestran las especificaciones de cada uno de estos objetos:

III.1.2.1 La base.

Esta compuesta por dos objetos tipo caja. Estos objetos son de la misma
dimensión de 0.03 ud de ancho, 0.03 ud de alto y 0.5 ud de profundidad. Se
encuentran en la misma ubicación (-1,-0.7,1) rotados 90 grados entre si en el
eje Y, tal como muestra la figura 3-3. El color elegido para las patas es el
negro.

90º
figura 3-3. Esqueleto de la base de la silla

III.1.2.2 La columna base.

La columna de la base es un cilindro cuyo radio es de 0.015 ud y una

altura de 0.2 ud. la ubicación del cilindro es en el punto (-1,0.6,1) y el color
de la columna de la base es el negro. En la figura 3-4, se observa la forma de
la base completa de la silla.

figura 3-4. Esqueleto de la base completa de la silla

III.1.2.3 El asiento.

El asiento es un objeto tipo caja con dimensiones 0.4 ud de ancho, 0.08 ud de alto y 0.36 de
profundidad. La ubicación de éste es en la posición (-1, -0.5,1) del universo virtual. El color del asiento
es el rojo.

III.1.2.4 Columnas del respaldo.

 Las columnas del respaldo son dos cilindros con las mismas
dimensiones de 0.015 ud de radio y 0.35 ud de alto. Cada cilindro esta rotado
en el eje Z -15 grados. El color de las columnas es el negro y están
ubicadas en los puntos (-0.83,-0.3,0.9) y ( -0.83,-0.3,1.1) respectivamente.
III.1.2.5 El respaldo.

El respaldo es un objeto tipo caja con dimensiones 0.04 ud de ancho

0.26 ud de alto y 0.4 ud de profundidad. Su ubicación es en el punto ( -0.82,
-0.2,1) y el color de su entorno es el rojo.

En la figura 3-5 se puede apreciar lo que sería el esqueleto aproximado

de la silla.

figura 3-5. Esqueleto de la silla

III.1.2.6 Árbol de escena para la silla.

 A continuación se muestra como sería el modelado del árbol de escena para la silla. Como se
expresó, el diseño de los árboles varía. Pero para que el diseño sea transparente los nodos de tipo TG
(TransformGroup) los acoplamos a la misma altura. En la figura 3-6 se observa el árbol para la silla.

BG

TG TG TG TG TG TG TG

Respaldo

Pata1
Pata2 asiento Columnar
esp2

Columna
base Columna
resp1

figura 3-6. Árbol de escena para la silla.

III.1.3 La computadora.

La computadora es el resultado de la combinación de objetos tales como una esfera, un cono y

objetos tipo caja.

A continuación mostramos en la tabla 3-1 con las especificaciones de cada objeto.

Nombre Tipo Descripción Medidas Posición Color

Pantalla Esfera Dá el efecto 0.13 de radio X =-1, Negro

 oblicuo de la Y=-0.05
pantalla. Z =-1.2

Entorno Caja Cubre por la Ancho = 0.04 X =-1.11, Blanco

Izquierdo izquierda la Y=-0.05
Alto = 0.26
pantalla. Z =-1.2
Pdad = 0.26

Entorno Caja Cubre por la Ancho = 0.04 X =-0.89 Blanco

Derecho Derecha la Y=-0.05
Alto = 0.26
pantalla. Z =-1.2
Pdad = 0.26

Entorno de Caja Cubre por Ancho = 0.26 X =-1, Blanco

Arriba encima la Y=0.06
Alto = 0.04
pantalla Z =-1.2
Pdad = 0.26

Entorno de Caja Cubre por Ancho = 0.26 X =-1, Blanco

Abajo debajo de la Y=-0.16
Alto = 0.04
pantalla. Z =-1.2
Pdad = 0.26

Entorno de Caja Cubre por Ancho = 0.26 X =-1, Blanco

Atrás detrás de la Y=-0.05
Alto = 0.26
pantalla. Z =-1.31
Pdad = 0.04

Entorno Caja Da la Ancho = 0.04 X =-1.12, Blanco

Izquierdo 1 impresión del Y=-0.05
Alto = 0.26
ancho del
 monitor por la Pdad = 0.06 Z =-1.08
Izquierda.

Entorno Caja Dá la Ancho = 0.04 X =-0.88, Blanco

Derecho 1 impresión del Y=-0.05
Alto = 0.26
ancho del Z =-1.08
Pdad = 0.06
monitor por la
Derecha.

Entorno Caja Dá la Ancho = 0.28 X =-1, Blanco

Arriba 1 impresión del Y=-0.08
Alto = 0.04
ancho del Z =-1.08
Pdad = 0.06
monitor por
arriba.

Entorno Caja Dá la Ancho = 0.28 X =-1, Blanco

Abajo 1 impresión del Y=-0.18
Alto = 0.04
ancho del Z =-1.08
Pdad = 0.06
monitor por
abajo.

Soporte Cono Es el soporte Radio = 0.11 X =-1, Blanco

de la base Y=-0.19
Alto = 0.1
debajo del Z =-1.2
monitor.

Base Monitor Caja Es la base del Ancho = 0.24 X =-1, Blanco

monitor Y=-0.24
Alto = 0.02
Z =-1.2
Pdad = 0.24

CPU Caja Muestra la Ancho = 0.1 X =-1.3, Blanco

impresión del Y=-0.09
 Case Alto = 0.3 Z =-1.2

Pdad = 0.26

CD Caja Es la unidad Ancho = 0.08 X =-1.295, Gris

de CD Y=-0.04
Alto = 0.03
Z =-1.055
Pdad = 0.02

Floppy Caja Es la unidad Ancho= 0.6 X =-1.295 Gris

de disco 3 ½ Alto = 0.04 Y = -0.08

Pdad = 0.02 Z =-1.055

tabla 3-1. Especificaciones de los objetos que componen la computadora

Al tener las especificaciones propias de cada objeto de la computadora, el árbol de escena se

construye de forma similar a los anteriores.

III.1.4 El ventilador.

El ventilador está compuesto de dos paletas de tipo caja, las cuales están ubicadas en el mismo
punto y rotadas en el eje Y 90 grados entre si. Así mismo, contiene un soporte de tipo cilindro que se puede
reconocer como el sostenedor de las paletas. También tiene la columna soporte de donde estará colgado el
ventilador y el soporte del techo que es un objeto de tipo cono.

Las especificaciones de la escena ventilador se muestran en la tabla 3-2

Nombre Tipo Descripción Medidas Posición Color

Paleta 1 y 2 Caja Las paletas del Ancho = 0.1 X =0 Blanco

ventilador Y=0.4
Alto = 0.01
 Pdad = 0.8 Z =0

Soporte Cilindro Es el soporte Radio = 0.1 X =0 Blanco

de las paletas Y=0.4
Alto = 0.03
del ventilador Z =0

Columna Cilindro Es la columna Radio = 0.01 X =0 Blanco

que sostiene el Alto = 0.3 Y=0.55
ventilador Z =0
desde el techo.

Sostenedor Cono Es la base del Radio = 0.05 X =0 Blanco

ventilador que Alto = 0.05 Y=0.7
lo mantiene Z =0
unido al techo

tabla 3-2. Especificaciones de los objetos que componen el ventilador.

III.1.5 Las lámparas.

Se hace referencia a las lámparas de la oficina, a aquellas que están presentes en el techo, estas
están formadas básicamente por objetos de tipo caja con dimensiones: 1 ud de ancho, 0.05 ud de alto, y 1.2
ud de profundidad. Se crearon 4 lámparas del mismo tipo distribuyéndolas equidistantes a las 4 esquinas
del techo de la oficina.

III.1.6 La columna.

La columna es en sí, un cilindro que une el techo y el piso. El cilindro tiene dimensiones 0.2 ud de
radio y 1.6 ud de alto. De éste modo la columna cubre toda la altura de la oficina. Y se encuentra ubicada
en el punto (1,0,-2.5) de la escena.
III.1.7 El escritorio.

El escritorio está compuesto completamente de puros objetos tipo caja, los cuales nos presentan un
diseño de una mesa de trabajo bastante amplia en dos secciones.

Las especificaciones del escritorio se muestran a continuación en la tabla 3-3.

Nombre Descripción Medidas Posición

Lateral Es el entorno izquierdo de soporte del Ancho = 0.05 X = -2

Izquierdo escritorio. Y= -0.5
Alto = 0.6
Z =0
Pdad = 4

Lateral Es el entorno derecho de soporte del Ancho = 0.05 X =0.4

Derecho escritorio Y=-0.5
Alto = 0.6
Z =0
Pdad = 4

Trasero Es el entorno trasero de soporte del Ancho = 3 X =-0.5

escritorio. Y=-0.5
Alto = 0.6
Z =-1.975
Pdad = 0.05

Lateral Es el respaldo por encima de la base en Ancho = 0.4 X =-2

Izquierdo el lado izquierdo. Y=-0.2
Alto = 0.02
Arriba Z =0
Pdad = 4

Lateral Es el respaldo por encima de la base en Ancho = 0.4 X =0.4

Derecho el lado derecho. Y=-0.2
Alto = 0.02
Arriba Z =0
Pdad = 4

Trasero Es el respaldo por encima de la base en Ancho = 2 X =-0.8

Arriba 1 la parte de atrás para la primera
 sección. Alto = 0.02 Y=-0.2

Pdad = 0.4 Z =-1.8

Trasero Es el respaldo por encima de la base en Ancho = 0.4 X =0.8

Arriba 2 la parte de atrás para la segunda Y=-0.2
Alto = 0.02
sección. Z =-1.8
Pdad = 0.4

Respaldo Es el segundo respaldo de la primera Ancho = 2.36 X =-0.788

Trasero 1 sección en la parte de atrás. Y=-0.4
Alto = 0.02
Z =-1.55
Pdad = 0.8

Respaldo Es el segundo respaldo de la segunda Ancho = 0.56 X =0.7125

Trasero 2 sección en la parte de atrás. Y=-0.4
Alto = 0.02
Z =-1.55
Pdad = 0.8

Respaldo Es el segundo respaldo para las Ancho = 1.2 X =0.4

lateral secciones 1 y 2 en el lado izquierdo. Y=-0.4
Alto = 0.02
izquierdo Z =0.2
Pdad = 2.6

tabla 3-3. Especificaciones de los objetos que componen el escritorio

III.2 Interacciones en el ambiente.

El escenario virtual creado solo admite tres tipos de interacciones con el usuario:

4. La primera es encender y apagar las luces que intervienen en la escena. Esta acción se ejecuta al pulsar
clic con el ratón. En la escena existen 4 puntos de luz principales, dado que existen 4 lámparas, de los
cuales solo se apagan 3. El cuarto punto de luz se deja encendido para poder visualizar la escena con
mínima iluminación.
5. Las segunda interacción es encender y apagar el ventilador, la misma se ejecuta al pulsar cualquier
“tecla imprimible” ( entiéndase por tecla imprimible, a cualquiera que haga referencia a números o
letras ).
6. La tercera y última interacción es la de recorrido en el ambiente por medio de las teclas la navegación
( las cuatro flechas del teclado).

III.3 Modelado del sistema distribuido.

Para la creación del ambiente virtual por medio de la distribución de procesos basado en servlets,
se debe introducir primero una visión general de la estructura de un servlet y luego se mostrará como se
distribuyeron cada uno de éstos para poder construir la escena.

III.3.1 Especificación formal en TDSO de los componentes utilizados en la implantación del ambiente
virtual distribuido.

En la implantación del ambiente distribuido se requiere de la especificación de los servlets que

intervienen en él, así como los programas que son necesarios para la comunicación y creación del escenario
virtual.

III.3.1.1 Especificación formal de un servlet.

Un servlet, no es más que una clase que hereda de otra, y que de acuerdo a la forma de diseño que
se disponga puede servir para responder ante un formulario desde una página web o para procesar objetos
complejos que nos permitan acoplar información.

El camino más sencillo para distribuir objetos utilizando “servlets”, es pensar en éstos como si
fueran servidores de petición - respuesta construidos bajo el enfoque de “sockets”. Así, si éste quiere leer
un dato cualquiera desde la red esperará hasta recibirlo y si en vez de recibir desea enviar, debe existir
algún programa o medio receptor.

La estructura general de un servlet se especifica en la tabla 3-4:

 ServletObjeto extiende de HttpServlet
Atributos privados
Ob : Objeto a distribuir
Operaciones públicas
//cualquier tipo de operación pública
personalizada.
Operaciones(Parámetros);
//operaciones comunes, propias de los
servicios..
service( HttpServletRequest request,
HttpServletResponse response );
init();
destroy();
doPost( HttpServletRequest request,
HttpServletResponse response );
doGet( HttpServletRequest request,
HttpServletResponse response );
Ob: es el objeto el cual se desea distribuir. El
mismo es personalizado y no solo se limita a
uno. Pueden existir varios de distinto tipo.
Operaciones : puede ser uno o varios
métodos públicos o privados que procesan
información del objeto. Como ejemplo
puede ser comunicaciones con bases de
datos, construcción del o los objetos como
tal, etc.
Service : es el método base de servicio del
servlet. Antes de ejecutar cualquier servicio
como doPost o doGet éste se ejecuta
primero.
Init: es el método de iniciación del servlet,
éste se puede considerar como otro
constructor. Este método si se quiere puede
o no ser re-escrito.
Destroy: este método es llamado cada vez
que el servlet termina sus servicios. Puede
ser o no sobrescrito y puede ser utilizado
para terminar, por ejemplo, alguna
comunicación interna con una base de
 datos.

DoPost: este método se encarga de procesar

el servicio de recepción y envío de datos por
medio del método post.

DoGet: este método se encarga de procesar

el servicio de recepción y envío de datos por
medio del método get.

tabla 3-4. Especificación general de un servlet en TDSO

A parte de todas los métodos públicos o privados que deseemos realizar para nuestra clase como
parte del diseño, lo más importante es escoger cual o cuales métodos de servicios del servlet necesitamos
sobrescribir. Los métodos pueden ser elegidos según la elección del programador.

En nuestro caso, seleccionamos el método service por ser la función base del servicio. El diseño
interno de comunicación con el cliente para el sistema distribuido, es más parecido a la programación en
sockets que otra cosa.

A continuación se muestra en la tabla 3-5 la cual es la especificación en TDSO de la re-escritura

del método service:

service( HttpServletRequest request, HttpServletResponse response)

{preCond: Exista un medio emisor} {postCond: Exista un medio

receptor}
//iniciando comunicación. Pidiendo permiso EntradaFlujoObjetos,
de lectura SalidaFlujoObjetos: estas clases son las
encargadas de la lectura y escritura de
EntradaFlujoObjetos efo =
nuevaDir( request.obtenerEntradaFlujoObjet objetos complejos por medio de archivos o
en nuestro caso una red.
os() );

ObjetoPer: es un objeto personalizado

ObjetoPer ob =
creado por el diseñador. Éste objeto debe ser
(ObjetoPer)efo.obtenerObjeto();
serializado para poder ser leído o escrito.

Efo.cerrar();

//procesar la información del objeto

//pidiendo permiso de escritura.

SalidaFlujoObjetos sfo =
nuevaDir( response.obtenerSalidaFlujoObjet
os() );

sfo.escribirObjeto( ob );

sfo.cerrar();

tabla 3-5. Especificación en TDSO de la re-escritura del método “service”.

 Ahora que se tiene el esquema general de la redefinición del método service, podemos tener una
idea de cómo una aplicación podría comunicarse con el servlet. Generalmente esta clase de aplicaciones
utiliza direcciones y objetos URL para poder iniciar la comunicación e intercambio de información. En la
tabla 3-6 mostramos una aplicación de ejemplo que se comunica con un servlet cuyo método service esté
redefinido y el servlet efectúe cambios en el objeto para que luego éste sea devuelto al programa de
aplicación.

Programa de prueba de comunicación

{preCond: Exista el servlet receptor y el objeto} {postCond: objeto modificado}

ObjetoPer ob = nuevaDir ObjetoPer; EntradaFlujoObjetos,

SalidaFlujoObjetos: estas clases son las
ob.asignarDatos();
encargadas de la lectura y escritura de
objetos complejos por medio de archivos o
ob.mostrarDatos(); en nuestro caso una red.

ConexionURL url = ObjetoPer: es un objeto personalizado

nuevaConexion( ServletDir ); creado por el diseñador. Éste objeto debe ser
serializado para poder ser leído o escrito.

//pidiendo permiso de escritura.

SalidaFlujoObjetos sfo = ob.asignarDatos(): es un método

nuevaDir( url.obtenerSalidaFlujoObjetos() ); personalizado de la clase ObjetoPer el cual

permite asignar valores a los atributos de la
clase.
//enviando datos al servlet

sfo.escribirObjeto( ob );
ob.mostrarDatos(): este método permite
sfo.cerrar(); mostrar sea en pantalla o en ventanas el
contenido de los atributos del objeto.
 ConexiónURL: éste objeto se encarga de la
comunicación vía url y abre la conexión con
el servidor remoto. La dirección está dada
// Pidiendo permiso de lectura
por el ServletDir, una variable de tipo
EntradaFlujoObjetos efo = cadena que indica la dirección url del
nuevaDir( url.obtenerEntradaFlujoObjetos() servlet.
);

// leyendo datos cambiados

ob = (ObjetoPer)efo.obtenerObjeto();

efo.cerrar();

ob.mostrarDatos();

url.cerrarConexion();

tabla 3-6. Especificación en TDSO de una aplicación que permite la comunicación con un servlet.

Básicamente el programa de ejemplo especificado en la tabla 3-6, crea un objeto personalizado

llamado “ob”, al cual se le asignan una serie de valores que servirán para ser procesados por el servlet, cuya
dirección está especificada por la variable de tipo cadena ServletDir. De éste modo, el servlet tomará los
datos, los procesará y cambiará sus valores para luego enviarlos nuevamente al programa de aplicación. Así
cuando el programa reciba el objeto modificado mostrará sus datos y cerrará la conexión.

A simple vista, pareciera no tener sentido enviar un objeto y recibirlo modificado, pero es tan solo
una visión general de cómo un servlet puede comportarse como si fuera un servidor basado en el enfoque de
“sockets”, claro que con mayores ventajas que ellos.
III.3.2 Diseño y especificación de la arquitectura distribuida para la construcción del ambiente
virtual.

Habiendo observado la forma general de comunicación con los servlets a través de un programa de
aplicación, podemos construir un sistema donde cada servlet se encargue literalmente de crear un objeto
3D, como una silla o un escritorio, el cual será enviado por la red a una aplicación que lo reciba y lo ingrese
dinámicamente al universo virtual.

Dado que existen siete distintas entidades tridimensionales que componen la oficina, cada una de
ellas será creada por diferentes servlets. La disposición de los servlets será en cuatro servidores, tal como se
muestra en la figura 3-7.

Servidor 1 Servidor 2 Servidor 3 Servidor 4

Silla
Columna Computadora

Escritorio Ventilador
Paredes lamparas

figura 3-7. Disposición de los servlets en los servidores.

La forma de distribuir los servlets en los servidores no es única. Otra forma de diseño podría ser,
disponer de siete servidores en vez de cuatro, en vista de que son siete objetos distintos. Lo que se desea, es
evaluar la calidad de desempeño de un servlet en particular frente a un proceso lo suficientemente
“pesado”. Un objeto tridimensional puede llevar un considerable tiempo de cálculo en cuanto a ubicación,
forma, tamaño y distribución del color. Cada entidad que compone la oficina está formado por más de un
objeto tridimensional básico (entiéndase por objeto 3D básico, aquellos que son cubos, conos, cilindros o
esferas), por lo que se considera que para crear una entidad en especial, así como el transporte de toda esa
información por la red permite evaluar la robustez de un servlet.
 La forma de diseño de cada uno de los servlets es similar. Lo único que cambia es el contenido de
la escena que será transportada por la red. De éste modo, sólo es necesario conocer como diseñar uno de
ellos y todos los demás pueden ser creados de la misma manera. A continuación se muestra en las tablas 3-
7, 3-8 y 3-9 la especificación formal del servlet encargado de crear el entorno de la oficina (las paredes, el
techo y el piso), y la implantación de cada método respectivamente:

ServletParedes extiende de HttpServlet

CrearApariencia: es la función encargada

de asignar la apriencia de color y material
Operaciones públicas
del cual está compuesto el objeto.

CrearApariencia(Color s, Color d):

Apariencia
service( HttpServletRequest request,
HttpServletResponse response );
Service : es el método base de servicio del
servlet. Este se comporta como la base de la
comunicación con el cliente y crea la entidad
tridimensional.

tabla 3-7. Especificación del servlet que crea el entorno de la oficina.

crearApariencia( Color s, Color d) : Apariencia

 {preCond: } {postCond: devuelve un objeto de
tipo apariencia }

Apariencia ap = nuevaDir Apariencia; Apariencia: objeto encargado de tener las

especificaciones del material del objeto, así
Material m = nuevaDir Material;
como las propiedades de los polígonos que
m.asignarColorEspecular(s);
componen el objeto 3D.
m.asignarColorDifuso(d);

m.asignarBrillo(50);
Material: objeto que tiene las propiedades
ap.asignarMaterial(m); de color y textura y especificaciones del
objeto.

devolver ap;

tabla 3-8. Método que se encarga de crear la apariencia de cada objeto que compone la entidad.

Service( HttpServletRequest request, HttpServletResponse response)

{preCond: Exista un medio emisor} {postCond: Exista un medio

receptor}

Color azul = nuevaDir Color( 0f,0f,1f); SalidaFlujoObjetos: Es la

Color celesteLigero = nuevaDir Color(0.35f, 0.4f, 0.6f); encargada de la escritura de
Color colorParedes = nuevaDir Color(0.9f,0.9f,0.65f);
Color blanco = nuevaDir Color ( 1f,1f,1f ); objetos complejos por medio de
archivos o en nuestro caso una
//diseñando el objeto 3D red.
Transformacion t = nuevaDir;
t.trasladar( nuevaDir Vector( -3f, 0f, 0f));
GrupoTransformación grupoIzquierdo = nuevaDir
Transformación: es el objeto
GrupoTransformación(t); encargado de definir
coordenadas de ubicación,
Caja paredIzquierda = NuevaDir Caja( 0.05f, 0.8f, 4f ,
Caja.GENERAR_NORMALES, crearApariencia(blanco, rotación o traslado dinámico de
colorParedes) ); un objeto 3D.
grupoIzquierdo.agregarHijo(paredIzquierda);

GrupoTransformación: es el
t.trasladar( NuevaDir Vector3f( 3f, 0f, 0f));
objeto de tipo Grupo de Java3D
GrupoTransformacion grupoDerecho = NuevaDir
GrupoTransformacion(t); encargado de contener
Caja paredDerecha = NuevaDir Caja( 0.05f, 0.8f, 4f , información de tipo
Caja.GENERAR_NORMALES, crearApariencia(blanco, transformación para el objeto
colorParedes) ); 3D.
grupoDerecho.agregarHijo(paredDerecha);

t.trasladar( NuevaDir Vector3f( 0f, 0f, -4f));

GrupoTransformacion grupoTrasero = NuevaDir Caja: crea un objeto tipo caja
GrupoTransformacion(t); el cual recibe el ancho, alto y
Caja paredTrasera = NuevaDir Caja(3f, 0.85f, 0.05f , profundidad, así como opciones
Caja.GENERAR_NORMALES, crearApariencia(blanco, de creación y apariencia.
colorParedes) ); grupoTrasero.agregarHijo(paredTrasera);

t.trasladar( NuevaDir Vector3f( 0f, 0.85f, 0f));

GrupoTransformacion grupoTecho = NuevaDir Mapa: es el objeto parecido a
GrupoTransformacion(t); una tabla hash el cual contiene
Caja techo = NuevaDir Caja( 3.05f, 0.05f, 4f , la información del árbol de
Caja.GENERAR_NORMALES, crearApariencia(blanco,
escena de la entidad.
celesteLigero) );
grupoTecho.agregarHijo(techo);

t.trasladar( NuevaDir Vector3f( 0f, -0.80f, 0f)); Escena: es el objeto que

GrupoTransformacion grupoPiso = NuevaDir contiene toda la escena y sus
GrupoTransformacion(t); especificaciones y que será
Caja piso = NuevaDir Caja( 3.05f, 0.025f, 4f ,
Caja.GENERAR_NORMALES, crearApariencia(blanco, azul) );
añadido al universo virtual
grupoPiso.agregarHijo(piso);

Escena bg = NuevaDir Escena(); agregarHijo: es un método

bg.agregarHijo(grupoIzquierdo); propio de los objetos tipo grupo
bg.agregarHijo(grupoDerecho); que permite añadir un nuevo
bg.agregarHijo(grupoTrasero);
bg.agregarHijo(grupoTecho); hijo al árbol de escena.
bg.agregarHijo(grupoPiso);

trasladar: se encarga de
Fondo fondo = NuevaDir Fondo(); trasladar el objeto
fondo.setColor(1.0f, 1.0f, 1.0f);
tridimensional a las
fondo.setApplicationBounds(NuevaDir BoundingSphere());
bg.agregarHijo(fondo); coordenadas especificadas por
el vector tridimensional.
//fin del diseño
//creación del mapa de escena.
Mapa map = NuevaDir Mapa(10); Vector: crea un nuevo vector
map.poner("Izquierda", grupoIzquierdo);
map.poner("Izquierda", paredIzquierda );
tridimensional.
 map.poner("Derecha", grupoDerecho);
map.poner("Derecha", paredDerecha);
map.poner("Atras", grupoTrasero); Fondo: es el fondo del entorno
map.poner("Atras", paredTrasera); de la escena.
map.poner("Arriba", grupoTecho);
map.poner("Arriba", techo);
map.poner("Abajo", grupoPiso);
map.poner("Abajo", piso);

//pidiendo permiso de escritura.

SalidaFlujoObjetos sfo =
nuevaDir( response.obtenerSalidaFlujoObjetos() );

sfo.escribirObjeto( bg, map );

sfo.cerrar();

tabla 3-9. Método principal de comunicación del servlet con el cliente.

El programa principal se diseñó a partir de hilos de control que se encargan de comunicarse con
cada uno de los servlets en los diferentes servidores. En la figura 3-8 se muestra la acción de los hilos entre
el programa principal que administra la comunicación y los servlets y se puede observar la relación con la
figura 3-7.

Programa

principal

Universo Virtual

Hilo 1 Hilo 2 Hilo 3 Hilo 4 Hilo 5 Hilo 6 Hilo 7

Servidor 2 Servidor 3 Servidor 4

 Servidor 1

Silla
Columna Computadora

Escritorio Ventilador
Paredes lámparas

figura 3-8. Estructura de comunicación con los servlets.

En la figura 3-8 se puede observar que cada hilo de control tiene predefinido un servidor en
especial y un servlet que responderá con un objeto de la oficina. Esto se nota por los colores de las flechas.
Por ejemplo el hilo 1 debe conectarse al servidor 1 hacia el servlet paredes, el hilo 2 debe conectarse al
servidor 2 hacia el servlet columna y así sucesivamente. Cuando cada servlet responda, devolverá la escena
que será dinámicamente agregada al universo virtual. El tiempo de respuesta de cada servlet es registrado
así como de cada servidor y posteriormente se le agrega al universo virtual las propiedades de cada escena.

Así en la figura 3-8 no solo se tiene la estructura del programa principal sino también del sistema
distribuido. La forma de distribuir el proceso de construcción de la oficina permite visualizar la respuesta
dinámica de cada servidor. Pero la distribución se podría limitar a que siga un patrón en especial, sea a
nivel de servlets o a nivel de hilos de control. Por ejemplo un servlet podría esperar hasta que otro responda
para enviar la escena que le corresponde, o también darle prioridades a los hilos para que se ejecuten. El
camino más sencillo sin embargo, es enviar las peticiones por medio de todos los hilos y que
dinámicamente según responda cada servidor, se asignen las escenas al universo.

III.3.3 Estructura de clases creadas para la implantación del programa.

Para la implantación del sistema distribuido se crearon una serie de clases con funciones
específicas para mejorar la estructura de comunicación y recepción de los objetos que envían los distintos
servlets. En la tabla 3-10 se muestran todas las clases que participan en el programa principal, así como una
breve información de la función que desempeña cada una:
 Clases creadas para la implantación del sistema distribuido

VirtualScene: es la clase que contiene el programa

principal encargado de administrar la comunicación
- VirtualScene y los tiempos de respuesta de cada servidor.
- SceneConnetion
- SceneConstructor SceneConnection: esta clase se encarga de la
comunicación con el servlet que se le indique, así
- FirstServer
como la lectura de la escena que será asignada al
- SecondServer universo virtual.
- ThirdServer
- FourthServer SceneConstructor: se encarga de contener una serie
- VentilatorBehavior de funciones que permitan incluir propiedades al
ambiente virtual.
- LightsBehavior

XxxServer: son clases que efectúan la comunicación

con cada servidor según su servlet. Estas leen e
incluyen la escena al universo virtual.

XxxBehavior: son clases encargadas de contener el

tipo de evento que se ejecutará en la oficina.

tabla 3-10. Clases que intervienen en la implantación del sistema distribuido.

En la figura 3-9 se muestra la relación que existe entre cada clase al momento de ejecutarse el
programa principal. La forma de diseño de la comunicación con cada servlet según su servidor no es la
única y no se descarta la posibilidad de la creación de una mejor estructura para el programa principal.

VirtualScene

Hilo 1 Hilo 2 Hilo 3 Hilo 4 Hilo 5 Hilo 6 Hilo 7

FirstServer SecondServer ThirdServer FourthServer

 SceneConnection Añadiendo SceneConstructor
propiedades al
objeto

Conexión con los Objeto de la Ingresando el

servidores oficina objeto

Servlet remoto Universo virtual

figura 3-9. Interacción de las clases que intervienen en el sistema distribuido.

La clase “VirtualScene” es la clase principal de administración de la comunicación con cada

servlet según su servidor, así como la inicialización del “Universo virtual” y cada hilo. El “Universo
virtual” es pasado como referencia a las clases “XxxServer” las cuales se encargarán de la comunicación e
inserción de propiedades a la escena leida. Cada “XxxServer” utiliza para la comunicación y la lectura un
objeto SceneConnection y toma el tiempo inicial y final de la comunicación. Así mismo, el objeto leído es
pasado a la clase SceneConstructor la cual incluirá propiedades como rotación, traslación o eventos ( estos
últimos por medio de las clases “XxxBehavior”). Luego de agregar los toques finales al objeto
tridimensional se dispone a ingresarlo al “Universo virtual”, el cual se encargará de mostrar el objeto en el
plano de imagen.

III.3.4 El modelo de distribución.

El esquema de distribución al que más se asemeja al momento de realizar las pruebas es al

“modelo de minicomputadora”, pero esto depende de cómo se quieran distribuir las computadoras. Para el
caso de las pruebas realizadas, dos de los servidores se encuentran en el cubículo del profesor tutor, junto
con el programa principal y los otros dos servidores se encuentran en el laboratorio 114 de la facultad de
ingeniería. De modo tal, que cuando cuando se ejecute la comunicación con algún servlet del laboratorio
114, se debe pasar primero por el servidor de la red local para luego ingresar a la red de la universidad, la
cual enrutará la petición hacia el servidor del laboratorio y por último a la estación que contiene el servlet.
Según éste esquema, se puede intuir que por lo visto en el capítulo anterior el modelo es muy parecido al
de minicomputadora.
Capítulo V: Conclusiones y recomendaciones.

Java, en un principio, fue diseñado con el

fin de presentarse como una alternativa más
sencilla para la programación bajo redes,
aparte de que se cuenta con un lenguaje que,
por ser estrictamente de objetos, brinda la
facilidad de manipulación y documentación.
 De acuerdo a esto, se han desarrollado una
gran variedad de paquetes que salen al
mercado, con el objetivo de ofrecer a quienes
los usen, tan solo una mejor alternativa para
solucionar tareas complejas, y uno de esos
paquetes que ha alcanzado una buena
popularidad son los servlets.

Los servlets, han demostrado ser ventajosos por múltiples razones. Su

uso bajo el enfoque de objetos, facilita considerablemente el pase de
información en el entorno de redes que, en otros lenguajes de programación,
costaría mucho trabajo poder realizarlo. Así mismo, se demuestra que, son
bastante eficientes utilizándolos bajo un ambiente distribuido, de tal modo,
que se puede contar con una herramienta que permita procesar información
por medio de peticiones de web, y a su vez, tener la capacidad de interactuar
con algún programa de aplicación estático o remoto, aparte de que, tiene la
capacidad de controlar sus accesos concurrentes cosa que en lenguajes como
“C”, se debería implantar como otra aplicación.

En éste proyecto solo se pudo observar el uso de los servlets bajo un

enfoque distribuido para crear un ambiente virtual. Dado que no existían
muchas limitantes, la distribución de los objetos tridimensionales que
componen el ambiente se hizo de una manera sencilla. Sin embargo, los
servlets responden relativamente lenta la primera vez que se ejecutan, pero
luego el tiempo de respuesta desciende de forma considerable.

Esto podría ser desventaja para el diseño de algunos desarrolladores de

software, pero todo depende de la aplicación que se desee crear, de todas
formas los servlets son tan solo una dentro de muchas alternativas en la
programación bajo redes.

Por otra parte, Java 3D, en comparación con otros lenguajes de

desarrollo de ambientes virtuales, como VRML, demuestra ser ventajoso por
la inclusión dinámica de objetos tridimensionales en su escenario virtual y lo
que también resultó ser una ventaja para la realización de éste proyecto pero,
por otro lado, es relativamente lento al momento de ejecutarse y requiere de
computadoras que tengan gran capacidad de memoria para poder contener una
escena, lo que resulta como una gran desventaja comparado con su antecesor
Opengl.

Sin embargo, si se es programador en Java resulta sencillo desarrollar

aplicaciones en éste paquete porque tan solo hay que conocer su modo de
trabajo, a pesar de que todavía está en desarrollo. Actualmente salió al
mercado la versión 1.3 de Java 3D, el cual, incluye el paquete scenegraph.io
que permite la manipulación de escenas virtuales por medio de archivos,
soluciona los problemas de memoria que tenía la versión anterior y presenta
una mayor variedad de utilerías que facilitan la creación de escenas complejas.

V.1 Recomendaciones.
 Basándose en los resultados obtenidos en el proyecto se pueden tomar
las siguientes recomendaciones:

1. Usar las nuevas versiones de Java 3D facilitaría

considerablemente la programación del sistema sin tener que
utilizar recursos de otros programas como en el caso de Java 3D
Fly Through.

2. Se pueden crear ambientes virtuales distribuídos muy complejos

con múltiples usos, en bases de datos, áreas de chat, tiendas
virtuales y otros, en donde se pueda enviar y recibir información
por medio de objetos visuales creados dinámicamente.
 Bibliografía

Referencias a Internet:

http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/
http://216.147.98.109/support_cp_java.html
http://java.sun.com/docs/books/tutorial/servlets/index.html
http://java.programacion.net/servlets_basico/index.php
http://java.programacion.net/threads/index.php
http://java.programacion.net/3d/index.php
http://delta.cs.cinvestav.mx/~adiaz/sis-dis/slides.html
http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/SO7.htm