Buscar
Social
Ofertas laborales ES
miércoles
sep192001

Especificaciones para J2EE

Sun lleva unos dias haciendo pýblicas varias de las nuevas especificaciones de J2EE.


Entre ellas estan, por ejemplo, J2EE 1.3, EJB 2.0, Connector 1.0, y los tutoriales "oficiales" de varios de ellos, como J2EE y JMS.
martes
sep182001

Tomcat 4.0 Final

El regenerado Tomcat, casi complemente reescrito esta aquí por fin.

Esta nueva versrión implementa las especificaciones de Servlets 2.3 y de JSP 1.2, siendo la implementacrión de referencia.


Al parecer en esta nueva versrión no solo se han esmerado en el servidor en sý, si no tambrión en la documentacrión, en la que aparecen unos cuantos nuevos documentos de administracrión.
domingo
sep162001

Serializacrión en Java


Serialización de objetos en Java


Fecha de creación: 10.9.2001

Revisión 1.1 (27.10.2001)

Emili Miedes de Elías
emiedes@iti.upv.es

Copyright (c) 2002, Emili Miedes de Elías. Este documento puede ser distribuido solo bajo los términos y condiciones de la licencia de Documentación de javaHispano v1.0 o posterior (la última versión se encuentra en /licencias/).



Introducción



La serialización de un objeto consiste en obtener una secuencia de bytes que represente el estado de dicho objeto. Esta secuencia puede utilizarse de varias maneras (puede enviarse a través de la red, guardarse en un fichero para su uso posterior, utilizarse para recomponer el objeto original, etc.).



Estado de un objeto



El estado de un objeto viene dado, básicamente, por el estado de sus campos. Así, serializar un objeto consiste, básicamente, en guardar el estado de sus campos.
Si el objeto a serializar tiene campos que a su vez son objetos, habrá que serializarlos primero. Éste es un proceso recursivo que implica la serialización de todo un grafo (en realidad, un árbol) de objetos.
Además, también se almacena información relativa a dicho árbol, para poder llevar a cabo la reconstrucción del objeto serializado.



En ocasiones puede interesar que un atributo concreto de un objeto no sea serializado. Esto se puede conseguir utilizando el modificador transient, que informa a la máquina virtual de Java de que no nos interesa mantener el valor de ese atributo para serializarlo o hacerlo persistente.



Ejemplo:


public class MiFecha
{
protected int n;
protected Date fecha;
protected transient long s;
...
}




En este ejemplo, los atributos n y fecha serán incluídos en la secuencia de bytes resultante de serializar un objeto de clase MiFecha. El atributo s no será incluído, por tener el modificador transient.


Objetos serializables. Interfaz Serializable



Un objeto serializable es un objeto que se puede convertir en una secuencia de bytes. Para que un objeto sea serializable, debe implementar la interfaz java.io.Serializable.
Esta interfaz no define ningún método. Simplemente se usa para marcar aquellas clases cuyas instancias pueden ser convertidas a secuencias de bytes (y posteriormente reconstruídas).
Objetos tan comunes como String, Vector o ArrayList implementan Serializable, de modo que pueden ser serializados y reconstruídos más tarde.



Para poder serializar un objeto no hay más que declarar el objeto como serializable:


public class MiClase implements java.io.Serializable



El sistema de ejecución de Java se encarga de hacer la serialización de forma automática.


Ejemplos


Almacenamiento de objetos



Es posible utilizar los mecanismos de serialización disponibles para serializar un objeto guardándolo en un fichero y para realizar el proceso inverso, recuperándolo desde el fichero.


FileOutputStream fos = new FileOutputStream("fichero.bin");
FileInputStream fis = new FileInputStream("fichero.bin");
ObjectOutputStream out = new ObjectOutputStream(fos);
ObjectInputStream in = new ObjectInputStream(fis);

ClaseSerializable o1 = new ClaseSerializable();
ClaseSerializable o2 = new ClaseSerializable();

// Escribir el objeto en el fichero
out.writeObject(o1);
out.writeObject(o2);
...
// Leer el objeto del fichero (en el mismo orden !!)
o1 = (ClaseSerializable)in.readObject();
o2 = (ClaseSerializable)in.readObject();



Envío de objetos por la red



También es posible enviar un objeto serializado a través de la red. La diferencia consiste en que ahora se utilizan streams de distinto tipo.


Socket socket = new Socket(maquina, puerto);
OutputStream os = socket.getOutputStream();
InputStream is = socket.getInputStream();
ObjectOutputStream out = new ObjectOutputStream(os);
ObjectInputStream in = new ObjectInputStream(is);

PeticionSerializable ps = new PeticionSerializable();
RespuestaSerializable rs;

// Escribir una petición en el socket
out.writeObject(ps);
// Recibir del socket la respuesta
rs = (RespuestaSerializable)in.readObject();



Serialización en RMI



En RMI, la serialización se utiliza de forma casi transparente al usuario. Concretamente, se utiliza en el paso de parámetros y retorno de valores de las invocaciones a métodos de objetos remotos.
Por ejemplo, cuando hacemos una invocación remota del tipo


retorno obj.metodo(param);



ocurre el siguiente proceso, de forma transparente al usuario:


  1. (Local) El objeto param se serializa y se envía al objeto remoto como una secuencia de bytes



  2. (Remoto) Se obtiene el objeto original a partir de la secuencia de bytes



  3. (Remoto) Se ejecuta el método y se obtiene un valor de retorno



  4. (Remoto) El valor de retorno se serializa y se envía como una secuencia de bytes



  5. (Local) Se obtiene el retorno a partir de la secuencia de bytes





Para que esta invocación se lleve a cabo, es necesario que tanto los parámetros de las invocaciones remotas como los valores devueltos pertenezcan a clases serializables.


Serialización personalizada



En ocasiones puede interesar tomar el control sobre el proceso de serialización de una clase en concreto. Esto se puede hacer sobrecargando los métodos writeObject y readObject de la clase cuya serialización se quiere controlar.



En realidad, no se puede hablar de sobrecarga, puesto que estos métodos no están definidos en java.lang.Object. Este punto es un poco oscuro. Puede consultarse el API al respecto (método writeObject(Object) de ObjectOutputStream y método readObject() de ObjectInputStream) y el JavaTutorial (Essential Java Classes -> Reading and Writing (but no 'rithmetic) -> Object Serialization -> Providing Object Serialization for Your Classes).



Para personalizar la serialización de un objeto, basta añadir un método tal que:


private void writeObject (ObjectOutputStream stream)
throws IOException
{
stream.defaultWriteObject();

...
}



Es necesario respetar exactamente tanto la signatura del método como la primera acción a realizar. A continuación pueden añadirse otras acciones que escriban en el stream dado.



También será necesario añadir un método para hacer el paso inverso:


private void readObject (ObjectInputStream stream)
throws IOException
{
stream.defaultReadObject();

...
}



En [1] hay un ejemplo muy sencillo de uso de estos dos métodos. Con los println es posible comprobar que realmente se ejecutan cuando se produce la serialización y la reconstrucción de un objeto Prueba.


Interfaz Externalizable



Existe una interfaz en java.io llamada Externalizable que permite obtener un mayor control sobre el proceso de serialización y reconstrucción de nuestros objetos.
Esta interfaz define dos métodos, writeExternal y readExternal, que se encargan de serializar y reconstruir un objeto, respectivamente.



La serialización mediante Externalizable requiere de un mayor cuidado. De forma automática, sólo se guarda información relativa a la identidad de la clase del objeto que se está serializando. No se guarda automáticamente ni su estado ni información relativa a sus superclases.
Por ello, en la implementación de writeExternal hay que guardar explícitamente el estado de aquellos atributos que nos interesen, incluídos los heredados.



A la hora de implementar writeExternal y readExternal, se ha de tener muy en cuenta la serialización de las clases superiores en el grafo de herencia y coordinar la implementación de estos métodos con la de los mismos métodos en clases superiores.


Recursos




[1]
Prueba.java


Acerca del autor

Emili Miedes de Elías

Emili trabaja en el Instituto Tecnológico de Informática (Universidad Politécnica de Valencia) desarrollando en Java. En sus ratos libres, colabora con javaHispano y desarrolla software opensource (buscar por emiedes en SourceForge).

domingo
sep162001

Instalacrión de JBoss


Instalación de JBoss.


Fecha de creación: 16.09.2001

Revisión 1.0 (16.09.2001)

Enrique Ibáñez Alemany
enricia AT latinmail DOT com

Copyright (c) 2002, Enrique Ibáñez Alemany. Este documento puede ser distribuido solo bajo los términos y condiciones de la licencia de Documentación de javaHispano v1.0 o posterior (la última versión se encuentra en /licencias/).



Introducción


Este artículo tiene como motivo mostrar la instalación y ejecución del servidor J2EE JBoss. Ante todo hay que aclarar que el JBoss esencialmente es un servidor EJB, por eso su nombre inicial EJBoss a los inicios del proyecto, pero por la beneficiosa aportación de mucha gente se ha convertido en un servidor J2EE.






JBoss es completamente una aplicación Java, por eso es necesario que el JDK 1.3 o superior este instalado y también es conveniente que el subdirectorio '/bin' del JDK este en el PATH para que los ejecutables esten disponibles desde cualquier directorio sin necesidad de incluir la ruta completa. Es conveniente siempre que nosotros queramos iniciar el JBoss con los scripts de arranque que vienen en la distribución. Yo personalmente siempre los utilizo.





En este artículo se explica la instalación de la versión 2.4.0 del JBoss. Esta versión es la última, pero al menos (por conocimiento propio) este artículo seria perfectamente válido desde la versión 2.1 .


Ahora debemos procedecer a la descarga del JBoss. La distribución se presenta en un archivo comprimido '.zip' . En versiones anteriores también se podia encontrar en ficheros comprimidos con la extensión '.tar.gz' y 'tar.bz2'. En estas diferentes presentaciones solo cambia el sistema de compresión pues el contenido es el mismo.


Siempre podemos conseguir la última versión de JBoss desde su página en spurceforge [1], pero podemos ir también al sitio Web del JBoss [2], aqui podemos encontrar las versiones predecesoras en la sección DOWLOAD/Binary.


Nos daremos cuenta de que tenemos diferentes descargas, una de ellas es el JBoss solo ( entonces no es un J2EE ) , y otras dos, cada una de ellas con un servidor JSP/Servlets diferente; Tomcat y Jetty ( asi si que es un J2EE ). En estas descargas además del JBoss se incluye embemido el Tomcat o el Jetty , gestionando completamente el funcionamiento de estos productos(Tomcat/Jetty) el JBoss. Estas dos alternativas son válidas siempre que el servidor EJB (JBoss) y el servidor de JSP/Servlets (Tomcat o Jetty) esten en la misma máquina, pero si necesitamos que cada uno de ellos este en una máquina tendremos la necesidad de instalarlos por separado. También es posible instalar separados cada producto en la misma máquina y hacerlos colaborar. En fin hay varias posibilidades pero esto no es materia de este artículo, ya lo veremos en los próximos.


Volviendo a la descarga, como se ha dicho y según la versión que presentamos en este artículo elegiremos uno de los siguientes archivos:

  • JBoss-2.4.0.zip
  • JBoss-2.4.0_Tomcat-3.2.3.zip
  • Boss-2.4.0_Tomcat-3.2.3.zip
Posibilidades de descarga.


Una vez descargado lo tenemos que descomprimir con nuestra herramienta favorita, ya sea 'gunzip' en sistemas Linux o 'WinZip' en sistemas Windows. Hay que prestar especial atención para conservar la estructura de directorios. El resultado es un directorio con el nombre del archivo sin la extensión del formato de compresión, en nuestro caso sin el '.zip'. Dentro de este directorio encontramos si hemos elegido solo el JBoss, pues la estructura de directorios del mismo y si el que hemos elegido es por ejemplo el que está acompañado con el Tomcat encontraremos un directorio '/jboss' y '/tomcat'.


Si hemos llegado aqui sin ningún problema, la parte de la instalación ya esta finalizada.





Siempre teniendo claro que nuestro JDK esta perfectamente instalado vamos a proceder a ejecutar el JBoss y por supuesto también el Tomcat o Jetty si hemos elegido alguna de estas alternativas. Para esto usaremos los scripts que vienen en la distribución, asi que nuestro PATH tiene que apuntar al directorio '/bin' del JDK. Como se comentó anteriormente existe la posibilidad de iniciar el JBoss sin necesidad de usar los scripts de arranque, esto es simplemente hacer lo que en el script se hace en varias líneas hacerlo solo en una, pero nosotros vamos a usar la forma más comun y sencilla. Para que hacerlo complicado si no es necesario ;-).


Ahora tenemos que situarnos en el subdirectorio '/bin' de la distribución del JBoss. En nuestro caso si hemos optado por instalar solo el JBoss en 'JBoss-2.4.0/bin' si por el contrario hemos elegido una de las distribuciones con el Tomcat o el Jetty será en 'JBoss-2.4.0/jboss/bin'.


Primero vamos a chequear que nuestra instalación del JDK es correcta. Asi que escribimos:

java -version



El resultado tiene que ser un mensaje que nos informe de la versión del Java instalado en nuestro sistema. Como se comentó al inicio del artículo esta debe ser 1.3 o superior.


Llegado aqui solo nos queda iniciar el servidor JBoss. Escribimos... en windows...


...solo el JBoss

run.bat

El JBoss y (Tomcat/Jetty)run_with_tomcat.bat
---o---
run_with_jetty.bat


... y en Linux ...solo el JBoss

run.sh

El JBoss y (Tomcat/Jetty)run_with_tomcat.sn
---o---
run_with_jetty.sh


El JBoss mientras arranca informa por consola de los servicios que está iniciando. A continuación se muestra un pequeño extracto de la salida por consola al final del arranque:

...
[MailService] Mail Service 'Mail' bound
[MailService] Started
[Service Control] Started 28 services
[Default] JBoss 2.4.0 Started in 0m:21s



Esta salida por consola corresponde a la versión 2.4.0 del JBoss con el Tomcat. Cuando se ejecuta el JBoss únicamente en la misma versión se inician 27 servicios asi que no hay que hacer mucho caso al número de servicios de las diferentes versiones.


Si se produce algún error nos daremos cuenta pues se lanza una excepción y se muestra por consola la traza. De todas formas si vemos que el JBoss continua hasta mostrar el mensaje de que se ha arrancado en x segundos, es que se ha iniciado satisfactoriamente. Esto suele pasar cuando nos descargamos una versión con un servidor JSP/Servlet y arrancamos solo el JBoss. En este caso se lanzará una excepción pues en estas distribuciones se incluye en el directorio 'JBoss-2.4.0/jboss/deploy' una aplicación ('.ear') que tiene parte Web y como no dispone de un servidor JSP/Servlet no puede desplegar la parte web. Con mover este archivo a otro directorio.(Mejor que sea fuera de la distribución del JBoss) ya funcionará.





Conclusión


Aunque el artículo es un poco extenso, simplemente la instalación del JBoss se reduce a dos pasos, descargar y descomprimir. Y la ejecución a una sola, llamar al script apropiado. En próximos capítulos veremos como desplegar EJB's y nos adentraremos más en la configuración de este fenomenal servidor J2EE.



Recursos




[1] JBoss en sourceforge,
http://sourceforge.net/projects/jboss/




[2] Web de JBoss,
http://www.jboss.org


Acerca del autor

Enrique Ibáñez Alemany
Enrique Ibáñez Alemany (Enric) es desarrollador Java en Valencia(España).
Dejo de tener tiempo libre cuando apareció ella, la fallera de su vida.

domingo
sep162001

El API comm


API de comunicaciones




El API de comunicaciones es una extensión standard que nos permite realizar comunicaciones con los puertos serie RS-232 y el paralelo IEEE-1284, esto nos permitirá realizar aplicaciones de comunicaciones que utilizan los puertos de comunicaciones (tarjetas inteligentes, fax) independientes de la plataforma.



El API de comunicaciones no se encuentra incluido en el JDK y es una extensión de este, así que antes de empezar a trabajar deberemos instalar este nuevo API en las maquinas que vayamos a realizar el desarrollo y que vayan a ejecutar programas realizados con este API.




Instalación del API de comunicaciones



Lo primero que haremos es obtener el API de comunicaciones, este se puede bajar fácilmente de Internet ya que no ocupa más de 300 Kb.



Una vez que desempaquetemos el fichero procederemos a realizar los siguientes pasos:



Copiamos el fichero Win32com.dll a \jre\bin
En el caso UNIX la librerías se deberían instalar en donde nos indicara la variable de entorno. Por ejemplo en una maquina Sun será donde nos marque la variable LD_LIBRARY_PATH.
Copiamos el archivo comm.jar a \jre\lib\ext.
Copiamos javax.comm.properties a \jre\lib este fichero contendrá los driver que soportara el API, esto es así ya que podremos crearnos nuestros propios drivers de puertos.



La nomenclatura indica el directorio donde se ha instalado el paquete de desarrollo de Java.




Características del API de comunicaciones



En el paquete de comunicaciones javax.comm tenemos una serié de clases que nos permiten tratar varios niveles de programación, estos niveles son los siguientes:



  • Nivel alto: En este nivel tenemos las clases CommPortIdentifier y CommPort que nos permiten el acceso a los puertos de comunicación.
  • Nivel medio: Con las clases SerialPort y ParallelPort que cubren el interfaces físico RS-232 para el puerto serie y IEEE-1284 para el puerto paralelo.
  • Nivel bajo: Este nivel ya toca el sistema operativo y en el se encuentra el desarrollo de drivers.


Los servicios que nos proporciona este paquete son:



  • Poder obtener los puestos disponibles así como sus características.
  • Abrir y mantener una comunicación en los puertos.
  • Resolver colisiones entre aplicaciones. Gracias a este servicio podremos tener varias aplicaciones Java funcionando y
  • utilizando los mismos puertos y no solo sabremos que el puerto esta ocupado sino que podremos saber que aplicación lo esta utilizando.


Disponemos de métodos para el control de los puertos de entrada/salida a bajo nivel, de esta forma no solo nos limitamos a enviar y recibir datos sino que podemos saber en que estado esta el puerto. Así en un puerto serie podremos no solo cambiar los estados sino que podemos programar un evento que nos notifique el cambio de cualquier estado.




Programación a alto nivel



Para esta programación contamos con la clase CommPortIdentifier. Nos encontramos ante la clase principal del paquete ya que lo primero que debemos hacer antes de empezar a utilizar un puerto es descubrir si esta libre para su utilización. El primer programa que nos servirá como ejemplo lo encontramos en el Listado 1, este programa nos enseña la disponibilidad de los puertos. En la Figura A podemos ver el resultado del mismo, el puerto COM2 se encuentra ocupado por el programa "Una aplicación ocupa".




/*********************************************************************
* P1.java
*
* Descripción: Este programa nos permite analizar la disponibilidad de
* todos los puertos soportados en nuestra maquina. Tambien
* nos informara del tipo del puerto así como el propietario
* de este en caso de que se encuentre ocupado.
*
* Autor: Fco. Javier Rodriguez Navarro (c) Junio 2000
**********************************************************************/
import java.io.*;
import java.util.*;
import javax.comm.*;
public class P1
{
static Enumeration listaPort;
static CommPortIdentifier idPort;

public static void main(String[] args)
{
listaPort = CommPortIdentifier.getPortIdentifiers();
ListaPuertos();
}

private static void ListaPuertos()
{

System.out.println("Los puertos disponibles son:");
while (listaPort.hasMoreElements())
{
idPort = (CommPortIdentifier) listaPort.nextElement();
System.out.print("PUERTO: " + idPort.getName() + " ");

if (idPort.getPortType() == CommPortIdentifier.PORT_SERIAL)
{
System.out.println("RS-232 (" + idPort.getPortType() + ")");
} else if (idPort.getPortType() == CommPortIdentifier.PORT_PARALLEL)
{
System.out.println("IEEE 1284 (" + idPort.getPortType() + ")");
} else System.out.println("Tipo de puerto desconocido");

// Describimos si esta disponible.
if (idPort.isCurrentlyOwned())
System.out.println("OCUPADO por: " +
idPort.getCurrentOwner());
else
System.out.println("DISPONIBLE");

System.out.println("---------------------------------------------");
}

}
}








Lo primero que debemos hacer antes de intentar intentar abrir un puerto será ver si ya tiene o no un propietario y para obtener la información de esto debemos obtener el objeto de CommPortIdentifier correspondiente al puerto que se realizara con alguno de los siguientes métodos:




  • getPortIdentifiers() es el método utilizado en nuestro programa y que nos entregará un enumerado con tantos objetos CommPortIdentifier como puertos dispongamos.
  • getPortIdentifier(String) Nos dará el objeto correspondiente al puerto que se le pase como parámetro, este será el método que normalmente usaremos ya que lo normal es que siempre nos conectemos por el mismo puerto. Este método deberá saber tratar la excepción NoSuchPortException que saltara en el caso de que solicitemos un puerto inexistente.


    Una vez que tenemos el objeto del puerto tenemos una serie de métodos que nos permitirán obtener información del puerto y abrirlo para poder iniciar una comunicación. Estos métodos son los siguientes:
    getName() dará el nombre del puerto. En el caso de haber utilizado el método getPortIdentifier(String) será el mismo valor que pasamos como parámetro.
  • getPortType() devuelve un entero que nos informa del tipo de puerto (serie o paralelo), para no tener que acordarnos del valor de cad tipo de puerto disponemos de las constantes PORT_PARALLEL y PORT_SERIAL.
  • isCurrentlyOwned() nos informa si esta libre o no el puerto. En caso de que este ocupado podremos saber quien lo esta utilizando mediante el método getCurrentOwner().
  • open(String, int) abre y por lo tanto reserva un puerto, en el caso de que intentemos abrir un puerto que ya se encuentre en uso saltara la excepción PortInUseException. Los parámetros que le debemos pasar son un String con el nombre de la aplicación que reserva el puerto y un int que indica el tiempo de espera para abrir el puerto.



    Un ejemplo de este método se puede ver en el Listado 2. Este método nos da un objeto CommPort, realmente esto es una clase abstracta de la que heredan las clases SerialPort y ParallelPort. Una vez que se tiene este objeto se deberán encaminar sus salidas a OutputStream y las entradas a InputStream una vez realizado esto la escritura y lectura de los puertos serán tan fácil como utilizar los métodos de estas clases que pertenecen al standard del JDK.
  • addPortOwnershipListener(CommPortOwnershipListener) permite añadir una clase que escuche los cambios de propietarios en los puertos.


Un ejemplo de esto esta en el Listado 2, en la Figura B podemos ver un prototipo de clase que realiza la escucha de cambio de propietarios en el puerto, como se puede ver son tres valores tipos: abrir un puerto, cerrar un puerto e intentar abrir un puerto en uso. Si una vez que tenemos registrado un oyente de eventos lo queremos eliminar deberemos de utilizar removePortOwnershipListener(CommPortOwnershipListerner).








/*********************************************************************
* Escritor.java
*
* Descripción: Este programa escribe una frase por el puerto
* que le pasemos como parametro.
*
* Autor: Fco. Javier Rodriguez Navarro (c) Junio 2000
**********************************************************************/
import java.io.*;
import java.util.*;
import javax.comm.*;

public class Escritor
{
static CommPortIdentifier idPort;
static SerialPort sPort;
static ParallelPort pPort;
static OutputStream salida;
static String datos = new String("HOLA! esto es una prueba");
static evProp ev = new evProp();

public static void main(String[] args)
{

// Lo primero que hacemos es abrir el puerto
try
{
idPort = CommPortIdentifier.getPortIdentifier(args[0]);
idPort.addPortOwnershipListener(ev);
} catch (NoSuchPortException e)
{System.err.println("ERROR al identificar puerto");}

// Abre el puerto necesario.
try
{
if (idPort.getPortType() == CommPortIdentifier.PORT_SERIAL)
{
sPort = (SerialPort) idPort.open("Escritor en serie", 30000);
try
{
salida = sPort.getOutputStream();
} catch (IOException e) {}
}
else
{
pPort = (ParallelPort) idPort.open("Escritor en paralelo", 30000);
try
{
salida = pPort.getOutputStream();
} catch (IOException e) { }
}
} catch (PortInUseException e)
{ System.err.println("ERROR al abrir puerto");}

try
{
salida.write(datos.getBytes());
} catch (IOException e) { System.err.println("Error escritura"); }

}

}

class evProp implements CommPortOwnershipListener
{

public void ownershipChange(int tipo)
{
System.out.print("Valor: " + tipo);
if (tipo == CommPortOwnershipListener.PORT_OWNED)
System.out.println(" Se abre el puerto");
else if (tipo == CommPortOwnershipListener.PORT_UNOWNED)
System.out.println(" Se cierra el puerto");
else if (tipo == CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED)
System.out.println(" Requerido puerto usado");
}
}



Clase CommPort



Esta es una clase abstracta que describe los métodos comunes de comunicación y serán las clases que hereden de ellas (SerialPort y ParallelPort) la que añadan métodos y variables propias del tipo del puerto. Entre los métodos que nos interesa conocer tenemos:



  • close() nos permitirá liberar el puerto que se reservo con open, este notificara el cambio de dueño a las clases que se hubiesen registrado con el método addPortOwnershipListener que se explico anteriormente.
  • getInputStream() nos permitirá enlazar la entrada del puerto al InputStream que nos devuelve para leer del puerto.
  • getOutputStream() nos permitirá enlazar la salida del puerto al OutputStream que nos devuelve para poder escribir en el puerto de la misma forma que si se escribiera en un fichero.
  • getInputBufferSize() nos informa del tamaño que tiene el buffer de entrada del puerto. Este tamaño se puede modificar con el método setInputBufferSize(int). Estos métodos no siempre dan el resultado esperado ya que será la memoria disponible y el sistema operativo quien al final decida si realizar o no correctamente la operación.
    getOutputBufferSize() nos informa del tamaño que tiene el buffer de salida, como en el caso anterior contamos con un método para modificar el tamaño que es setOutputBufferSize(int). Al igual que pasaba con los métodos anteriores su correcto funcionamiento dependen del sistema operativo en si y del desarrollo del driver.


Una vez que hemos visto los principales métodos de la clase abstracta de la que heredan (ParallelPort y SerialPort) pasamos a ver con detenimiento las características de estas.




Clase SerialPort



En esta clase encontramos el interfaces de bajo nivel del puerto paralelo que cumple el standard RS-232. En la Tabla A podemos ver la descripción de las patillas del conector de 25 contactos, ver la Figura C conector tipo A, y su equivalente con el de 9 contactos. En la emisión de un carácter se realizarán las siguientes comprobaciones:









  1. Ponemos el DTR (Indicando que estamos preparados)
  2. Ponemos RTS (Solicito permiso para emitir)
  3. Comprueba que esta DSR (Mira si el destinatario esta listo)
  4. Esperamos a CTS (Se espera a que me autoricen a enviar datos)
  5. Enviamos datos.



En la figura D podemos ver distintas conexiones que nos podemos encontrar en los enlaces punto a punto.









Conexiones DB25 y DB9 del interfaces RS-232




PIN (DB25) PIN (DB9) Descripción
2 2 TD: Canal de transmisión.
3 3 RD: Canal de recepción.
4 7 RTS: Petición para transmitir.
5 8 CTS: Preparado para emitir.
6 6 DSR: Equipo preparado.
7 5 Masa
8 1 DCD: Conexión establecida.
20 4 DTR: Terminal preparado.
22 9 RI: Indicador de llamada.


La clase SerialPort hereda de la clase abstracta CommPort y por lo tanto cuenta con sus métodos pero ademas de estos dispones de otros métodos y variables especificas para el tratamiento de los puertos serie. En el Listado 3 podemos ver el uso de los métodos y eventos que se exponen a continuación




  1. setSerialPortParams(int, int, int, int) nos permite configurar los parámetros del puerto serie, este método debera tratar la excepción UnsupportedCommOperationException que saltara en el caso de que le introduzcamos valores no soportados.


    Los parámetros del método son:

    • La velocidad en el caso de que le pasáramos un valor no valido. Si pasáramos 1210 se produciría la excepción y no se modificarían los datos.
    • El segundo parámetro son los bit de datos. Para indicar el valor utilizaremos las constantes de la clase que se tiene para lo mismo (DATABITS_5, DATABITS_6, DATABITS_7 o DATABITS_8).
    • El bit o bits de stop que utilizaremos y que puede ser 1,2 o uno y medio. Las constantes que definen estas configuraciones son: STOPBITS_1, STOPBITS_2 y STOPBITS_1_5 respectivamente.
    • Paridad que utilizaremos y que puede ser PARITY_NONE en el caso de no utilizar paridad, PARITY_ODD para la paridad impar, PARITY_EVEN paridad par, PARITY_MARK paridad por marca y PARITY_SPACE paridad por espacio.


  2. getBaudrate() nos da la velocidad a la que esta preparada para transmitir y que se puede cambiar con el método setSerialPortParams(int, int, int, int).

  3. getDataBits() nos da la configuración de número de datos y al igual que el método anterior se puede cambiar con el mismo método, los valores posibles son los mismos que utiliza el método de configuración de parámetros.
    getStopBits() nos indica la configuración de bits de parada y al igual que en los métodos anteriores se puede configurar con el mismo método.

  4. getParity() indica la paridad que utiliza.

  5. getFlowControlMode() nos da la configuración del control de flujo que se puede cambiar con el método setFlowControlMode(int) y los valores posibles son: FLOWCONTROL_NONE no existe control de flujo, (FLOWCONTROL_RTSCTS_IN o FLOWCONTROL_RTSCTS_OUT) para el control de flujo por hardware y ( FLOWCONTROL_XONXOFF_IN o FLOWCONTROL_XONXOFF_OUT) para control de flujo por software. El método setFlowControlMode(int al igual que pasaba con setSerialPortParams(int, int, int, int) deberá de saber capturar la excepción UnsupportedCommOperationException.

  6. addEventListener(SerialPortEventListener) nos permite escuchar los cambios de estado del puerto, si quisiéramos quitar este oyente utilizaríamos el método removeEventListener(). Mediante los métodos notifyOnXXX(boolean) nos permitirá habilitar o deshabilitar la notificación de los diferentes cambios que pueden ser:

    • DataAvailable existen datos en la entrada.
    • OutputEmpty el buffer de salida esta vacio.
    • CTS cambio de Clear To Send
    • DSR cambio de Data Set Ready
    • RingIndicator cambio en RI.
    • CarrierDetect cambio en CD.
    • ParityError se ha producido un error de paridad
    • BreakInterrupt se detecta una rotura en la linea.




La clase oyente deberá de tener el método serialEvent(SerialPortEvent) que recibirá un objeto que trata los eventos del puerto serie con tres métodos importante:



  • getEventType() nos informara del evento que se ha producido.
  • getNewValue() que devuelve el nuevo estado.
  • getoldValue() que nos dará el estado anterior al cambio.
  • isDTR() nos informara del estado terminal que se podra cambiar con setDTR(boolean).
  • isRTS() nos dice si ha solicitado permiso para transmitir o no y para cambiar su estado tenemos el método setRTS(boolean),
  • isCTS() nos informa si podemos transmitir, isDSR() dará el estado en el que se encuentra el pin DSR. IsRI() informa de si esta el indicador de timbre, isCD() nos indicara si tenemos portadora.


/*************************************************************
* Serie.java
*
* Descripción: Ejemplo de información de puerto con
* tratamiento de eventos.
*
* Autor: Fco. Javier Rodriguez Navarro (c) Julio 2000
*************************************************************/
import java.io.*;
import java.util.*;
import javax.comm.*;

public class Serie
{
static CommPortIdentifier idPort;
static SerialPort sPort;
static OutputStream salida;
static String datos = new String("Una linea que deseamos escribir ");
static evSerie ev = new evSerie();

public static void main(String[] args)
{
try
{
idPort = CommPortIdentifier.getPortIdentifier("COM2");
} catch (NoSuchPortException e)
{System.err.println("ERROR al identificar puerto");}

try
{
sPort = (SerialPort) idPort.open("Observador1(COM2)", 30000);
informa();
try
{
salida = sPort.getOutputStream();
} catch (IOException e) { }
try
{
sPort.addEventListener(ev);
sPort.notifyOnDataAvailable(true);
sPort.notifyOnOutputEmpty(true);
sPort.notifyOnCTS(true);
sPort.notifyOnDSR(true);
sPort.notifyOnRingIndicator(true);
sPort.notifyOnCarrierDetect(true);
sPort.notifyOnParityError(true);
sPort.notifyOnOverrunError(true);
sPort.notifyOnBreakInterrupt(true);
} catch (TooManyListenersException e) { }
} catch (PortInUseException e)
{ System.err.println("ERROR al abrir puerto");}

try
{

while (true) {salida.write(datos.getBytes());}

} catch (IOException e) { System.err.println("Error escritura"); }
}

// Metodo informa: Nos dara información del estado del puerto
private static void informa()
{
System.out.println("Información del puerto: " + sPort.getName());
System.out.println("Buffer entrada: " + sPort.getInputBufferSize());
System.out.println("Buffer salida: " + sPort.getOutputBufferSize());
System.out.println("Baudios: " + sPort.getBaudRate());
System.out.print("Bits de datos: ");
switch (sPort.getDataBits())
{
case SerialPort.DATABITS_5:
System.out.println("cinco ");
break;
case SerialPort.DATABITS_6:
System.out.println("seis ");
break;
case SerialPort.DATABITS_7:
System.out.println("siete ");
break;
case SerialPort.DATABITS_8:
System.out.println("ocho ");
break;
}

System.out.print("Bits de parada: ");
switch (sPort.getStopBits())
{
case SerialPort.STOPBITS_1:
System.out.println("uno ");
break;
case SerialPort.STOPBITS_2:
System.out.println("dos ");
break;
case SerialPort.STOPBITS_1_5:
System.out.println("uno y medio ");
break;
}

System.out.print("Paridad: ");
switch (sPort.getParity())
{
case SerialPort.PARITY_NONE:
System.out.println("ninguna ");
break;
case SerialPort.PARITY_ODD:
System.out.println("impar ");
break;
case SerialPort.PARITY_EVEN:
System.out.println("par ");
break;
case SerialPort.PARITY_MARK:
System.out.println("por marca ");
break;
case SerialPort.PARITY_SPACE:
System.out.println("por espacio ");
break;
}
System.out.print("Control de flujo: ");
switch (sPort.getFlowControlMode())
{
case SerialPort.FLOWCONTROL_NONE:
System.out.println("ninguno ");
break;
case SerialPort.FLOWCONTROL_RTSCTS_IN:
case SerialPort.FLOWCONTROL_RTSCTS_OUT:
System.out.println("hardware ");
break;
case SerialPort.FLOWCONTROL_XONXOFF_IN:
case SerialPort.FLOWCONTROL_XONXOFF_OUT:
System.out.println("software ");
}
}
}

class evSerie implements SerialPortEventListener
{

public void serialEvent(SerialPortEvent evento)
{
switch (evento.getEventType())
{
case SerialPortEvent.DATA_AVAILABLE:
System.out.println("Datos disponibles");
break;
case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
System.out.println("Buffer vacio");
break;
case SerialPortEvent.CTS:
System.out.print("CTS pasa a ");
if (evento.getNewValue()) System.out.println("cierto");
else System.out.println("falso");
break;
case SerialPortEvent.DSR:
System.out.print("DSR pasa a ");
if (evento.getNewValue()) System.out.println("cierto");
else System.out.println("falso");
break;
case SerialPortEvent.RI:
System.out.print("RI pasa a ");
if (evento.getNewValue()) System.out.println("cierto");
else System.out.println("falso");
break;
case SerialPortEvent.CD:
System.out.print("CD pasa a ");
if (evento.getNewValue()) System.out.println("cierto");
else System.out.println("falso");
break;
}
}
}




Clase ParallelPort



En esta clase tenemos el interfaces de bajo nivel del puerto paralelo que cumple la norma IEEE-1284. El standard IEEE-1284 cuenta con 8 lineas de datos, 5 entrada de estado y 4 salidas de control, en la figura C se pueden ver los tres tipos de conectores que podemos encontrar en este tipo de interfaces. Los contactos del conector tipo A es el más utilizado en los ordenadores y se definen en la Tabla B con sus funciones en el modo SPP que es el modo compatible de trabajo para la impresora.



Conexiones DB25 del interfaces IEEE-1284 en modo SPP




PIN NOMBRE Descripción
1 STROBE Indica que existen datos validos en la lineas de datos D0-7
2 D0 Dato bit 0
3 D1 Dato bit 1
4 D2 Dato bit 2
5 D3 Dato bit 3
6 D4 Dato bit 4
7 D5 Dato bit 5
8 D6 Dato bit 6
9 D7 Dato bit 7
10 ACK* Indica que el ultimo carácter se recibió.
11 BUSY* Indica que la impresora esta ocupada y no puede recoger datos.
12 PE* Sin papel.
13 SLCT* Indica que la impresora esta en linea.
14 AUTO FD Indica a la impresora que realice una alimentación de linea.
15 ERROR* Existe algún error en la impresora.
16 INIT* Pide a la impresora que se inicie.
17 SLCT* IN Indica a la impresora que esta seleccionada.



Nota: Los nombres con * indican señal negada.




Este standard podemos trabajar con 5 modos de funcionamiento:



  • Compatible o SPP.
  • Modo Nibble, este modo reserva el canal de datos y se combina con el modo SPP.
  • Byte Mode, este modo es bidireccional utilizado por IBM y tiene la capacidad de deshabilitar los drivers usando la linea de datos.
  • EPP (Extended Parallel Port) es el modo extendido y se utiliza para periféricos que principalmente no son impresoras.
  • ECP (Enhanced Capabilities Port) al igual que el modo EPP es bidireccional y se utiliza para comunicar diversos tipos de periféricos, este modo es una propuesta de Hewlett Packard y Microsoft.



La clase ParallelPort como dijimos es una clase que hereda de CommPort. Esta clase cuenta con una serie de métodos que nos facilitan el uso del puerto paralelo y los exponemos a continuación:



  • addEventListener(ParallelPortEventListener ev) mediante este método podremos asignar
    un oyente para cuando aparezca un error en el puerto no lo notifique, exactamente nos informara de cuando el buffer de salida este lleno o cuando la impresora indique error. Los métodos que nos permiten habilitar o deshabilitar estos avisos son: notifyOnError(boolean) y notifyOnBuffer(boolean). Si deseamos quitar el oyente podemo utilizar el método removeEventListener().
  • getOutputBufferFree() nos informa de los bytes que tenemos disponible en el buffer de salida.
  • isPaperOut() nos devolverá un valor true en el caso de que nos quedemos sin papel en la impresora, esto es lo mismo que preguntar por el estado de la seña PE (ver tabla B).
  • isPrinterBusy() nos devolverá un valor true en el caso de que la impresora este ocupada y se corresponde con el estado BUSY.
  • isPrinterSelected() nos informa si la impresora esta seleccionada.
  • isPrinterError() chequea si ocurre un error en la impresora y esto se refleja con el estado de ERROR que esta en el pin 15 (ver Tabla B).
  • restart() realiza un reset en la impresora.
  • suspend() suspende la salida.
  • getMode() nos dice el modo configurado del puerto paralelo y los valores posibles son:

    • LPT_MODE_SPP modo compatible unidireccional.
    • LPT_MODE_PS2 modo Byte.
    • LPT_MODE_EPP modo extendido.
    • LPT_MODE_ECP modo mejorado.
    • LPT_MODE_NIBBLE modo nibble.

  • setMode(int) configuramos el modo del puerto paralelo, los valores que puede tomas son los anteriores y a demas LPT_MODE_ANY que será el mejor modo disponible. Este método debera ser capaz de tratar la excepción UnSupportedCommOperationException que saltara en el caso de que introduzcamos un modo no soportado.


Aunque de momento solo se dispone de esta API para unix (de Sun) y Windows, se esta desarrollando una versión para linux.
















Fco. Javier Rodriguez Navarro trabaja como responsable de desarrollos en Tms con el objetivo de crear sistemas abiertos y escalables, de ahí la afición por Java.


Cada vez que tiene un rato libre se lanza a viajar y pasear para conocer nuevas gentes, paisajes y costumbres.



Para cualquier duda o tirón de orejas, e-mail a:
frodrigu_ARROBA_idecnet.com