Apuntes Libro Java

Tareas y Multarea
Considerando el entorno multithread ( multihilo , multitarea ,
multihilvanado ) , cada thread ( hilo , tarea , ujo de control del programa )
representa un proceso individual ejecutándose en un sistema . A veces se
les llama procesos ligeros o contextos de ejecución . El autor recuerda al
lector que cuando se re ere a tarea , se re ere a un hilo de ejecución , a un
thread y del mismo modo , cuando se re ere a multitarea se re ere a
multithread . Generalmente , cada tarea controla un único aspecto dentro de
un programa , como puede ser supervisar la entrada en un determinado
periférico o controlar toda la entrada / salida del disco . Todas las tareas
comparten los mismos recursos , al contrario que los procesos , en donde
cada uno tiene su propia copia de código y datos ( separados unos de
otros ) .

Hay que distinguir multitarea de multiproceso . El multiproceso se re ere a

dos programas que se ejecutan " aparentemente " , a la vez , bajo el control
del Sistema Operativo . Los programas no necesitan tener de que las tareas
se ejecutan " aparentemente " a la vez , dentro de un mismo programa . de
que el usuario desce que se ejecuten a la vez . Multitarea se re ere a que
dos o mis Se usa " aparentemente " en ambos casos , porque normalmente
las plataformas tienen una sola CPU , con lo cual , los procesos no se
ejecutan en realidad " concurrentemente " , sino que comparten la CPU .

En plataformas con varias CPU , es posible que los procesos se ejecuten

realmente a la vez . Tanto en multiproceso como en multitarca ( multihilo ) , el
Sistema Operativo se encarga de que se genere la ilusión de que todo se
ejecuta a la vez. Sin embargo , la multitarea puede producir programas que
realicen más trabajo en la misma cantidad de CPU está compartida entre
tareas de un tiempo que el multiproceso , debido a que operativo , el
programador no puede intervenir en el planteamiento de su ejecución mismo
proceso . Además , como el multiproceso está implementado a nivel de
sistema mientras que en el caso de la multitarca , como el programa debe
ser disc ado para esta es que el desarrollador tenga que

Un programa de ujo único , tarea única o mono - hilo ( single - thread )

utiliza un único ujo de control ( thread ) para controlar su ejecución .
Muchos programas no necesitan la potencia o utilidad de múltiples tareas .
Sin necesidad de especi car explicitamente que se quiere un único ujo de
control , muchos de los applets y aplicaciones son de ujo único .

Página 1 de 8
fi
fl
fl
fi
fi
fi
fi
fl
fl
fi
fl
fi
fi
 Servlets
Los servlets son clases normales Java que se crean cuando se necesitan y
se destruyen cuando ya no se van a usar más . Los servlets se ejecutan en
una caja restringida , mediante un motor especial , que es el encargado de la
creación y destrucción de cada uno de los servlets de la aplicación Web ,
mediante los métodos init ( ) y destroy ( ) , respectivamente . Este motor de
servlets es la implementación de la especi cación Servlet y es el
responsable de mantener el ciclo de vida del servlet , y se puede usar solo o
en combinación con un servidor Web .

Al crear un servlet extendiendo la clase HttpServlet , la clase debe

colocarse en el directorio / WEB - INF / classes de la aplicación Web .
La instancia del serviet será generada por el motor en dos casos :

1. Cuando se indica al motor especi camente que cargue el servlet al

iniciarse la aplicación . Para ello , en el descriptor de la aplicación ,
web.xml , se ha de colocar un valor distinto de cero en el atributo load -
on - startup .

2. Si el servlet no está cargado en la zona restringida de ejecución

previamente , el motor lo cargará cuando reciba la primera petición
destinada a ese servlet . El API Servlet es claro y simple .

Un servlet es una clase Java que implementa la interfaz Servlet , que los
siguientes métodos :

• service ( ) , es el corazón de los servlets . El servidor invoca al método

para ejecutar respuestas . Acepta como parámetros objetos
ServletRequest , que encapsulan la petición del cliente , y
ServletResponse , que disponen de métodos para devolver información al
cliente .

• init ( ) , es el lugar donde se inicializa el servlet . Es un método que

acepta como parametro un objeto de tipo ServletCon g , que contiene la
con guración del servidor , y se garantiza que solamente se llamará una
vez durante la vida del servlet .

• destroy ( ) , libera el servlet , se llama cada vez que el servlet debe ser
descargado ; por ejemplo , debido a que hay que cargar una nueva
versión del servlet . Todos los sistema bloqueados por init ( ) son liberados
al invocar este método y te garantiza que solamente se llamará una vez
durante la vida del servlet .

Página 2 de 8
fi
fi
fi
fi
 LA CLASE HTTPSERVLET
La clase HttpServlet es una clase que implementa la interfaz Servlet
incorporando además métodos especí cos para servidores Web . Un uso
tipico de HttpServlet es el procesamiento de formularios html . Pero antes de
poder escribir el primer servlet , es necesario tener unas nociones básicas
sobre el protocolo HTTP HyperText Transfer Protocol , que es el protocolo
de comunicaciones que se utiliza para que un cliente , un navegador , por
ejemplo , envíe peticiones a un servidor Web . HTTP es un protocolo
orientado a petición - respuesta .

Una petición HTTP está formada por unos campos de cabecera y un

cuerpo , que puede estar vacío . Una respuesta HTTP contiene un código de
resultado y de nuevo una cabecera y un cuerpo El método service ( ) de la
clase HttpServlet lanza diferentes peticiones a distintos métodos Java para
sistemas de petición diferentes .

La clase HttpSession
Independientemente de la técnica utilizada , lo que está claro es que hay
que almacenar los datos de la sesión en algún sitio . Una buena opción es el
objeto HttpSession que puede almacenar los datos de la sesión en el
servidor . Para utilizar este objeto es necesario obtener un objeto de la
sesión , leerlo y escribirlo , y eliminarlo cuando se cierre la sesión o después
de un cierto tiempo si la sesión no se ha cerrado expresamente . La
persistencia del objeto es válida en el contexto de la aplicación Web , por lo
que puede ser compartida por varios servlets . Un servlet puede acceder a
objetos almacenados en otro servlet .

Estos objetos , también llamados atributos , pueden estar disponibles para

otros servlets dentro del ámbito de la petición , sesión o aplicación . El
objeto HttpSession almacena y accede a la información de la sesión que
controla el servlet , por lo que no es necesario que esta información sea
manipulada en código .

Los métodos más interesantes de esta clase son los que se describen a
continuación;

• getId ( ) , devuelve una cadena conteniendo el identi cador único

asignado a la sesión . Es el utilizado en la reescritura de URI . para
identi car a esa sesión

Página 3 de 8
fi
fi
fi
• isNew ( ) , devuelve true si el cliente no ha establecido ya una sesión . Si
el cliente tiene deshabilitados los Cookies , la sesión será nueva en cada
petición

• setAttribute ( ) , asigna un objeto a la sesión , utilizando un nombre

determinado

• getAttribute ( ) , devuelve el objeto asignado a la sesión , identi cado por

el nombre que se indique

• setMaxInactiveInterval ( ) , especi ca el tiempo máximo que ha de pasar

entre peticiones consecutivas del cliente para que la sesión se dé como
no válida . Un número negativo como argumento de este método hará que
nunca se invalide la sesión

• invalidate ( ) , elimina la sesión actual y libera todos los objetos que

estuviesen asociados a ella

Páginas JSP
La tecnología JavaServer Pages ( JSP ) ha sido introducida para ayudar a los
diseñadores y desarrolladores de aplicaciones Web a separar la lógica de la
presentación , de la lógica de la aplicación ; es decir , para permitir separar
el contenido dinámico del contenido estático de una página HTML .

Utilizando esta tecnología es posible cambiar el diseño de la página sin

necesidad de que haya que tocar el código que genera el contenido de esa
página . La tecnología JSP es una tecnología de servidor , es decir , que
todo su proceso se realiza en el servidor , lo cual permite que otros
componentes como JavaBeans o Enterprise JavaBeans ( EJB ) puedan
interacturar con las páginas JSP.

Los pasos fundamentales en la comunicación entre un servlet y una página

JSP para proporcionar información al cliente .

1. La petición del usuario llega al servlet , que procesa .

2. El resultado se almacena en un bean , el objeto Sesión
3. El servlet envía la respuesta a la página JSP
4. La página JSP obtiene los datos del bean y los formatea para su
presentación en el navegador

El uso de beans hace posible que otras páginas JSP puedan acceder a la
misma información ; no obstante , también es posible utilizar el objeto
Session , tal como se hace en el ejemplo que se presentará , en aras de que

Página 4 de 8
fi
fi
 la aplicación sea lo más simple posible . Si el lector se encontrase en el
mundo real , debería utilizar beans y almacenar

Applet
La de nición más extendida de applet , muy bien resumida en su día por
Patrick Naughton , indica que un applet es " una pequeña aplicación
accesible en un servidor Internet , que se transporta por la red , se instala
automáticamente y se ejecuta in situ como parte de un documento web " .
Claro que así la de nición establece el entorno ( Internet , Web , etc. ) .

En realidad , un applet es una aplicación pretendidamente corta ( nada

impide que ocupe más de un gigabyte , a no ser el pensamiento de que se
va a transportar por la red y una mente sensata ) basada en un formato
grá co sin representación independiente : es decir , se trata de un elemento
a embeber en otra aplicaciones ; es un componente en su sentido estricto .

Un ejemplo en otro ámbito de cosas podria ser el siguiente : imagínese el

lector una empresa que cansada de empezar siempre a codi car desde cero
, diseña u formulario con los datos básicos de una persona ( nombre ,
dirección , etc. ) . Este formulario no es un diálogo por sí mismo , pero se
podría integrar en diálogos de clientes , proveedores , empleados , etc. El
hecho de que se integre estática ( embebido en un ejecutable ) o
dinámicamente ( intérpretes , librerías , DLLs , etc. ) no afecta a absoluto a la
esencia de su comportamiento como componente con el cual construir
diálogos con sentido autónomo . Pues bien , así es un applet .

Lo que ocurre es que , dado que no existe una base adecuada para soportar
aplicaciones industriales Java en las que insertar estas miniaplicaciones
( aunque todo se va andando y ya se pueden encontrar aplicaciones d este
tipo en intranets ) , los applets se han construido mayoritariamente , y con
gra acierto comercial ( a las pruebas hay que remitirse ) , como pequeñas
aplicaciones interactivas , con movimiento , luces y sonido ... en Internet .

SERIALIZACIÓN DE OBJETOS
Uno de los aspectos básicos en los que se apoya RMI es en la persistencia
de objetos , es decir , en que los objetos no se destruyan y puedan ser
enviados entre máquinas en un entorno distribuido .

En muchas aplicaciones , la persistencia de los datos se controla a través de

cheros de texto o bases de datos comerciales , dependiendo de la
complejidad de la aplicación y de los recursos puestos a disposición de los
programadores . Para aplicaciones sencillas , los cheros de texto son
su cientemente válidos , porque son exibles , es muy fácil trabajar con

Página 5 de 8
fi
fi
fi
fi
fi
fl
fi
fi
 ellos y no están limitados a su uso por un solo programa . Sin embargo , no
son nada amigos de los objetos .

Cuando el formato de un chero se complica un poco más allá de una

simple tabla o una lista de parámetros ( lo que ocurre en casi todas las
aplicaciones orientadas a objetos ) , el código para manejar estos cheros se
vuelve farragoso y consume mucho tiempo del programador . Al otro lado
del espectro están las bases de datos relacionales y orientadas a objetos
que funcionan muy bien con programas que requieran caracteristicas de
bases de datos : transacciones , bloqueo de registros , indices , etc. Pero
generalmente son muy caras , pueden llegar a ser di ciles de manejar y
exigen grandes conocimientos .

Actualmente se tiende a implementar la persistencia con bases de datos : Si

un diseño requiere estados en que hay que guardar datos , entonces se
asume que las bases de datos son la elección . En muchos casos , todo
esto es un chero con formato orientado a objetos integrado en el propio
entorno de programación .

Una situación similar existe también en el entorno de la programación

distribuida . Los sockets son exibles y muy fáciles de utilizar , al igual que
los cheros , pero presentan los mismos problemas que éstos cuando se
transmiten formatos de datos complejos .

La serialización de objetos en Java proporciona una solución intermedia

para salvar objetos en cheros y transmitirlos a través de la red . Incluso en
grandes proyectos que utilicen bases de datos comerciales o
comunicaciones middleware , puede ser un formato válido para cheros
auxiliares o comunicaciones variadas .

Tanto RMI como el API de los JavaBeans utilizan la serialización para

guardar y transmitir objetos . Por lo tanto , en toda aplicación Java en que se
vea involucrada la persistencia o distribución de objetos , la serialización es
una poderosa herramienta de programación .

La serialización de objetos en Java permite escribir y leer objetos en streams

, cheros o sockets . Esta circunstancia proporciona a los programadores
una forma sencilla de guardar tanto objetos individuales como grandes
estructuras de objetos en cheros , o enviarlos a través de la red . Desde la
perspectiva del programador , gran parte de este trabajo se realiza
automáticamente .

El mecanismo de serialización mantiene control sobre los tipos de los

objetos , las referencias entre ellos y muchos detalles de cómo están
almacenados los datos .

Página 6 de 8
fi
fi
fi
fi
fi
fi
fl
fi
fi
fi
 El API de serialización está muy estructurado , de tal modo que en muchos
casos se puede manejar directamente con facilidad , mientras permite
realizar acondicionamientos muy complejos en caso necesario .

La interfaz Serializable no tiene métodos que deban ser implementados ;

sin embargo , cualquier campo de datos que implemente esta interfaz
también debe ser serializable . Por ejemplo todos los tipos básicos como
int , String , Array , Vector o Hashtable son serializables .

Bu ers
Los bu ers corresponden fundamentalmente a una forma sencilla de
representar un array de bytes .
Para añadir datos a un bu er se utiliza el método put ( ) del propio bu er , o
el método read ( ) de los canales .
La lectura de datos se realiza a través del método get ( ) , o llamando al
método write ( ) de los canales .

Todos los bu ers tienen cuatro propiedades básicas , que se describen a

continuación .
1. Capacidad . Ésta es una propiedad que no se puede modi car una vez
que se haya creado el bu er . Indica el contenido máximo de datos
asignado a ese bu er .

2. Limite . Es una marca de n de bu er , que se puede desplazar dentro

de un bu er con capacidad ya determinada para permitir cambiar
dinámicamente el tamaño de la parte utilizable del bu er . Por defecto ,
corresponde al mismo valor que la capacidad . No se puede leer y
escribir en el bu er más allá del límite y no se puede mover el límite más
allá , obviamente , de la capacidad del bu er .

3. Posición . Corresponde a la localización dentro del bu er donde se

realizará la siguiente acción relativa de lectura o escritura . Todas estas
operaciones de lectura / escritura pueden realizarse de forma absoluta ,
especi cando un desplazamiento desde el origen del bu er , o de forma
relativa , referida a la posición actual . Funciona de forma semejante a un
puntero en un archivo o a un cursor en una tabla de base de datos .

4. Marca . Es una posición etiquetada en el bu er . Siempre debe estar

situada antes de la posición actual y puede utilizarse el método reset ( )
para volver a ella . Por defecto , no hay ninguna marca de nida ,
entendiendo que siempre existe una marca implícita asignada a la
posición cero .

Página 7 de 8
ff
fi
ff
ff
ff
ff
ff
ff
fi
ff
ff
ff
ff
ff
ff
ff
fi
fi
ff
Un problema siempre presente con los procesos de entrada / salida
tradicionales en Java es el no poder interactuar con los ujos de datos
binarios De Fuentes que no sean Java . El mapeo de caracteres es
adecuado para aplicaciones basadas en texto , como un servidor HTTP ,
pero cuando se trata de imágenes , sonido , vídeo o incluso datos
numéricos , Java siempre ha tenido problemas en el control ,
fundamentalmente debido a la característica multiplataforma de Java . Un
ejemplo claro es el orden de los bytes ; por ejemplo , a la hora de manipular
un dato de tipo short , formado por dos bytes , para

Página 8 de 8
fl