Especificaciones para J2EE
miércoles, septiembre 19, 2001 at 2:00AM 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.
j2ee
miércoles, septiembre 19, 2001 at 2:00AM
martes, septiembre 18, 2001 at 2:00AM
domingo, septiembre 16, 2001 at 2:00AM
Fecha de creación: 10.9.2001
Revisión 1.1 (27.10.2001)
Emili Miedes de Elías
emiedes@iti.upv.es
|
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.).
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.
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
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();
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();
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);
(Local) El objeto param se serializa y se envía al objeto remoto como una secuencia de bytes
(Remoto) Se obtiene el objeto original a partir de la secuencia de bytes
(Remoto) Se ejecuta el método y se obtiene un valor de retorno
(Remoto) El valor de retorno se serializa y se envía como una secuencia de bytes
(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.
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();
...
}
También será necesario añadir un método para hacer el paso inverso:
private void readObject (ObjectInputStream stream)
throws IOException
{
stream.defaultReadObject();
...
}
println es posible comprobar que realmente se ejecutan cuando se produce la serialización y la reconstrucción de un objeto Prueba.
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.
[1]
Prueba.java
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, septiembre 16, 2001 at 2:00AM
Fecha de creación: 16.09.2001
Revisión 1.0 (16.09.2001)
Enrique Ibáñez Alemany
enricia AT latinmail DOT com
|
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:
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.batEl JBoss y (Tomcat/Jetty)
run_with_tomcat.bat
---o---
run_with_jetty.bat... y en Linux ...solo el JBoss
run.shEl JBoss y (Tomcat/Jetty)
run_with_tomcat.sn
---o---
run_with_jetty.shEl 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á.
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.
[1] JBoss en sourceforge,
http://sourceforge.net/projects/jboss/
[2] Web de JBoss,
http://www.jboss.org
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, septiembre 16, 2001 at 2:00AM
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.
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
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
Copiamos javax.comm.properties a
La nomenclatura
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:
Los servicios que nos proporciona este paquete son:
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.
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:
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");
}
}
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:
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.
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:

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

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
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:
/*************************************************************
* 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;
}
}
}
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.
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:
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:
Aunque de momento solo se dispone de esta API para unix (de Sun) y Windows, se esta desarrollando una versión para linux.
|