El API de Java está formado por una amplísima jerarquía de clases que cubren una gran cantidad de aspectos relacionados con el desarrollo de software en general. Esta organizado en packages ordenados por temas. El J2SE (Java 2 Standard Edition) permite la utilización de todos estos packages en el desarrollo de programas Java y el JRE (Java Runtime Environment) permite la ejecución de programas que usan cualquiera de las clases del API.La documentación que acompaña al J2SE contiene un manual de referencia completo ordenado por packages y clases de todo el contenido del API. Su consulta resulta imprescindible para cualquier desarrollo.
La nomenclatura de los packages es uniforme y ayuda a categorizar las clases. El primer calificador es java o javax (para las clases dedicadas al interfase gráfico). Escapan a esta norma las dedicadas a CORBA y materias afines. El segundo calificador da idea de la materia que cubre el package, como i/o (entrada/salida), math (funciones matemáticas). Hay temas que contienen varios subpackages, con un tercer calificador más específico (por ejemplo javax.sound.midi, que es bastante autoexplicativo).
Los puertos de salida/entrada son elementos materiales del equipo, que permiten que el sistema se comunique con los elementos exteriores. En otras palabras, permiten el intercambio de datos, de aquí el nombre interfaz de entrada/salida (también conocida como interfaz de E/S).
Quizás la más popular de las conexiones que se realiza en un PC, sea la puerta serie, que permite al ordenador comunicarse con todo tipo de dispositivos periféricos: módems, impresoras, escaners, lectores de código de barras, etc. El API de Comunicaciones Java, constituido por el paquete javax.comm, que proporciona JavaSoft, no forma parte del JDK, pero añade soporte a Java para dispositivos serie y paralelo. En este trabajo no se intenta realizar un compendio de comunicaciones serie, sino solamente proporcionar al lector una visión de cómo se utiliza el paquete javax.comm para comunicarse con un dispositivo serie RS-232 y poco más.
El paquete proporciona soporte para dispositivos serie y paralelo al estilo Java, es decir, utilizando una semántica semejante a la que se usa con streams y eventos. Para comunicarse con un dispositivo serie a través de uno de los puertos serie de un ordenador, desde una aplicación Java o un Apple, es necesario un interfaz. El API de Comunicaciones Java, permite transmitir y recibir datos a través de dispositivos conectados al puerto serie; proporcionando además un conjunto de opciones que permiten la configuración de todos los parámetros asociados a los puertos serie y paralelo. Este API es una proposición para establecer un método estándar de acceso a los puertos de comunicaciones, que permita a los autores de software de comunicaciones escribir programas Java independientes de plataforma. Así se pueden escribir programas para emulación de terminales, programas de fax, lectores de tarjetas, etc. Con cada una de las versiones que Sun lanza del JDK, se acompaña de una serie de bibliotecas con clases estándar que valen como referencia para todos los programadores en Java.
Estas clases se pueden incluir en los programas Java, sin temor a fallos de portabilidad। Además, están bien documentadas (mediante páginas Web), y organizadas en paquetes y en un gran árbol de herencia. A este conjunto de paquetes (o bibliotecas) se le conoce como la API de Java (Application Programming Interface)।El API de Java está formado por una amplísima jerarquía de clases que cubren una gran cantidad de aspectos relacionados con el desarrollo de software en general. Esta organizado en packages ordenados por temas. El J2SE (Java 2 Standard Edition) permite la utilización de todos estos packages en el desarrollo de programas Java y el JRE (Java Runtime Environment) permite la ejecución de programas que usan cualquiera de las clases del API।La documentación que acompaña al J2SE contiene un manual de referencia completo ordenado por packages y clases de todo el contenido del API।
El API Java es una Interfaz de Programación de Aplicaciones (API: por sus siglas en ingles) provista por los creadores del lenguaje Java, y que da a los programadores los medios para desarrollar aplicaciones Java। Como el lenguaje Java es un Lenguaje Orientado a Objetos, la API de Java provee de un conjunto de clases utilitarias para efectuar toda clase de tareas necesarias dentro de un programa। La API Java está organizada en paquetes lógicos, donde cada paquete contiene un conjunto de clases relacionadas semánticamente।
Existen numerosas API's de Java para realizar todo tipo de operaciones, algunas de las más conocidas son:
Servlets: Para facilitar la implementación de soluciones Web.
Hibernate: Para facilitar la implementación de persistencia।
En la comunidad de desarrollo Java se suele identificar cada una de las diferentes librerías existentes como API's java. Cuando se construye un sistema informático este suele emplear diversas API`s.
En Java, crear una conexión socket TCP/IP se realiza directamente con el paquete java।net. A continuación mostramos un diagrama de lo que ocurre en el lado del cliente y del servidor (figura):
CLASES ÚTILES EN COMUNICACIONES
Vamos a exponer otras clases que resultan útiles cuando estamos desarrollando programas de comunicaciones, aparte de las que ya se han visto. El problema es que la mayoría de estas clases se prestan a discusión, porque se encuentran bajo el directorio Sun. Esto quiere decir que son implementaciones Solaris y, por tanto, específicas del Unix Solaris. Además su API no está garantizado, pudiendo cambiar. Pero, a pesar de todo, resultan muy interesantes y vamos a comentar un grupo de ellas solamente que se encuentran en el paquete sun.net.
Socket
Es el objeto básico en toda comunicación a través de Internet, bajo el protocolo TCP. Esta clase proporciona métodos para la entrada/salida a través de streams que hacen la lectura y escritura a través de sockets muy sencilla.
ServerSocket
Es un objeto utilizado en las aplicaciones servidor para escuchar las peticiones que realicen los clientes conectados a ese servidor. Este objeto no realiza el servicio, sino que crea un objeto Socket en función del cliente para realizar toda la comunicación a través de él.
DatagramSocket
La clase de sockets datagrama puede ser utilizada para implementar datagramas o fiables (sockets UDP), no ordenados. Aunque la comunicación por estos sockets es muy rápida porque no hay que perder tiempo estableciendo la conexión entre cliente y servidor.
DatagramPacket
Clase que representa un paquete datagrama conteniendo información de paquete, longitud de paquete, direcciones Internet y números de puerto.
MulticastSocket
Clase utilizada para crear una versión multicast de las clase socket datagrama. Múltiples clientes/servidores pueden transmitir a un grupo multicast (un grupo de direcciones IP compartiendo el mismo número de puerto).
Network Server
Una clase creada para implementar métodos y variables utilizadas en la creación de un servidor TCP/IP.
NetworkClient
Una clase creada para implementar métodos y variables utilizadas en la creación de un cliente TCP/IP.
SocketImpl
Es un Interfase que nos permite crearnos nuestro propio modelo de comunicación। Tendremos que implementar sus métodos cuando la usemos. Si vamos a desarrollar una aplicación con requerimientos especiales de comunicaciones, como pueden se la implementación de un cortafuegos (TCP es un protocolo no seguro), o acceder a equipos especiales (como un lector de código de barras o un GPS diferencial), necesitaremos nuestra propia clase Socket.
Puerto Serie.
Los puertos seriales (también llamados RS-232, por el nombre del estándar al que hacen referencia) fueron las primeras interfaces que permitieron que los equipos intercambien información con el "mundo exterior"। El término serial se refiere a los datos enviados mediante un solo hilo: los bits se envían uno detrás del otro (consulte la sección sobre transmisión de datos para conocer los modos de transmisión).
Originalmente, los puertos seriales sólo podían enviar datos, no recibir, por lo que se desarrollaron puertos bidireccionales (que son los que se encuentran en los equipos actuales). Por lo tanto, los puertos seriales bidireccionales necesitan dos hilos para que la comunicación pueda efectuarse. La comunicación serial se lleva a cabo asincrónicamente, es decir que no es necesaria una señal (o reloj) de sincronización: los datos pueden enviarse en intervalos aleatorios. A su vez, el periférico debe poder distinguir los caracteres (un carácter tiene 8 bits de longitud) entre la sucesión de bits que se está enviando. Ésta es la razón por la cual en este tipo de transmisión, cada carácter se encuentra precedido por un BIT de ARRANQUE y seguido por un BIT de PARADA. Estos bits de control, necesarios para la transmisión serial, desperdician un 20% del ancho de banda (cada 10 bits enviados, 8 se utilizan para cifrar el carácter y 2 para la recepción). Los puertos seriales, por lo general, están integrados a la placa madre, motivo por el cual los conectores que se hallan detrás de la carcasa y se encuentran conectados a la placa madre mediante un cable, pueden utilizarse para conectar un elemento exterior. Generalmente, los conectores seriales tienen 9 ó 25 clavijas y tienen la siguiente forma (conectores DB9 y DB25 respectivamente):
Puerto paralelo.
La transmisión de datos paralela consiste en enviar datos en forma simultánea por varios canales (hilos)। Los puertos paralelos en los PC pueden utilizarse para enviar 8 bits (un octeto) simultáneamente por 8 hilos.
Los primeros puertos paralelos bidireccionales permitían una velocidad de 2,4 Mb/s. Sin embargo, los puertos paralelos mejorados han logrado alcanzar velocidades mayores:El ECP (puerto de capacidad mejorada), desarrollado por Hewlett Packard y Microsoft। Posee las mismas características del EPP con el agregado de un dispositivo Plug and Play que permite que el equipo reconozca los periféricos conectados.
Los puertos paralelos, al igual que los seriales, se encuentran integrados a la placa madre. Los conectores DB25 permiten la conexión con un elemento exterior (por ejemplo, una impresora).
Principios Básicos
Con demasiada frecuencia, los programadores se involucran en un proyecto y codifican interactivamente con un API a través del editor sin haber reflexionado suficientemente sobre el problema que intentan resolver. Para evitar confusiones y potenciales problemas, el programador debería recoger la información, cuando se trate de comunicación con dispositivos serie externos, que se indica seguidamente antes de iniciar ese proyecto. Recuerde también el lector, que todos los dispositivos requieren en algún momento que se deba consultar su manual, que para eso el fabricante lo ha escrito; no es suficiente con la intuición.
Muchos dispositivos tienen un protocolo que debe seguirse, para poder establecer comunicación entendible con él। El dispositivo decodificará los datos que sigan ese protocolo, así que hay que poner atención en el envío y recepción de datos. Con una inicialización correcta no se asegura que la comunicación también lo sea, por ello hay que tomarse el tiempo necesario en hacer las pruebas que sea menester, incluso haciendo una aplicación de lo más simple, que escriba y lea datos a través del puerto serie usando el API de Comunicaciones Java.
Consultar los ejemplos que proporcione el fabricante; incluso aunque se encuentren en otro lenguaje de programación, siempre resultan útiles।Buscar o codificar el ejemplo más simple posible para verificar la comunicación con el dispositivo
En el caso de dispositivos serie, esto puede resultar altamente frustrante cuando se envía algo al dispositivo conectado al puerto serie y no sucede nada. Este es el resultado que se obtiene cuando las condiciones de la línea son incorrectas. La regla numero Uno de la programación con dispositivos (a no ser que se esté escribiendo un driver) es asegurarse de que se puede establecer comunicación con el dispositivo.
Si el protocolo es muy complicado, hay que considerar el uso de algún tipo de software que analice la línea RS-232, el cual permite comprobar los datos que se intercambian los dos dispositivos sin interferir en la transmisión।
El uso del API de Comunicaciones Java con éxito en una aplicación requiere proporcionar algún tipo de interfaz para el control del dispositivo utilizando el API como mecanismo de transmisión. En otras palabras, con excepción de los dispositivos más simples, se necesita una capa por encima para formatear los datos de forma que sean entendibles por el dispositivo. Desde luego, el protocolo más simple es ninguno, es decir, la no existencia de protocolo, en donde los datos se envían y reciben sin ningún tipo de interpretación.
API de Comunicaciones Serie
Este API proporciona a los programadores la siguiente funcionalidad:
Una especificación completa para control y acceso a los puertos serie y paralelo। Esto facilita mucho los desarrollos, ya que disminuye en gran medida la carga de trabajo a realizar para el acceso a estos puertos.
Control total de todos los parámetros de los puertos serie: velocidad en baudios, bits de stop, paridad, bits por trama; así como control manual o automático de las líneas de control de flujo। Normalmente, en RS-232, hay dos líneas de señal y el resto son líneas de control; dependiendo del tipo de comunicación, síncrona o asíncrona, el número de líneas de control seleccionadas puede variar. El API proporciona acceso a las líneas de control fundamentales.
En este momento, es necesario hacer una pequeña descripción para ayudar al lector a entender algo acerca de la paridad y los bits de arranque y parada। La paridad fue incorporada a RS-232 porque las líneas de comunicaciones podían ser ruidosas, es decir, si se mandaba el código ASCII 0, que en hexadecimal es 0x30 (o 00110000 en binario), a lo largo de su viaje podía encontrarse con acciones de campos magnéticos, por ejemplo, que hacían que alguno de sus bits cambiasen de valor. Para evitarlo, en vez de mandar 8 bits como sería normal, se incluye un BIT más a la cadena de bits enviada indicando si la suma total de bits enviados es par o impar, y... Esa es la paridad.
Los bits de arranque (start) y parada (stop) fueron añadidos al protocolo de comunicaciones serie para permitir a los receptores sincronizarse con respecto a los caracteres que están siendo enviados। La paridad, al usar un solo BIT, no permite la corrección del error, solamente la detección. Las soluciones a este problema vienen de la mano de protocolos que forman una capa por encima del API de comunicaciones serie, normalmente utilizando protocolos de mensajes con checksums que permiten la detección de errores en grupos muy grandes de bits. Por ejemplo, cuando el lector se conecta son su proveedor de Internet sobre PPP, los paquetes que se intercambian son de 128 bytes por paquete con checksum, que si coincide en los dos lados, hay una seguridad del 99,999% de que lo enviado es lo recibido.
Hay casos donde este esquema no funciona; por ejemplo, cuando se envían comandos críticos a dispositivos que están muy, muy lejos (más allá del sistema solar). En estos casos se utilizan los protocolos forward correcting, porque no hay posibilidad de retransmisión de los paquetes y, además, el espacio está repleto de ruido electromagnético.
Siguiendo con las funcionalidades del API de Comunicaciones Java। Este API utiliza para entrada y salida los streams, un concepto que debería ser ya familiar al lector. Es importante reutilizar los conceptos de Java cuando se implementan nuevas funcionalidades o se corre el peligro de que los APIs resulten posteriormente muy complicados en su manejo.
Los streams pueden extenderse para proporcionar control sobre el flujo y los umbrales। Por ejemplo, puede ser necesario lanzar un aviso cuando haya 15 caracteres en el buffer, o cuando solamente queden 15 espacios vacíos para almacenar caracteres. El control del flujo es importante cuando dos dispositivos conectados a través de un interfaz no pueden mantenerse uno al otro; sin el control del flujo, pueden darse condiciones alteradas, tanto por exceso como por defecto. En condiciones en que haya problemas por exceso de información, se recibirán datos mientras todavía se están procesando otros, con lo cual habrá pérdidas de información; y en el caso contrario, la información estará presente pero no disponible. Normalmente estas condiciones solamente se dan a nivel hardware, a nivel de la USART (Universal Synchronous Asynchronous Receiver Transmitter), que es el dispositivo físico que convierte los bytes a una señal ondulada coincidiendo con la velocidad en baudios.
El API de Comunicaciones Java utiliza el modelo de eventos que JavaSoft ha introducido desde el lanzamiento del JDK 1।1 para proporcionar información de las líneas de señal que van cambiando y del estado del buffer. Los cambios de estado se refieren solamente a las señales que están bien definidas en el estándar RS-232; por ejemplo, la señal de detección de portadora (Carrier Detect) es utilizada por los módems para indicar que se ha establecido la conexión con otro módem, o para indicar que ha detectado un tono de llamada. Luego el hacer una conexión o detectar una llamada será un evento. La detección de eventos y la notificación de cambios están totalmente implementadas en el API.
Y ahora, es conveniente también, la revisión de algunas de las cosas que el API de Comunicaciones Java no hace, para que el lector tenga idea de lo que puede o no conseguir con su uso। Este API no proporciona ninguna de la siguiente funcionalidad.
Procesado de las señales, control de llamadas o control del módem। El procesado de señales se refiere a procesado adicional de caracteres de entrada o salida; por ejemplo, una opción muy común de post-procesado es la conversión de los caracteres de retorno de carro a retorno de carro más salto de línea, cuyo origen se remonta a los antiguos teletipos, ya que ahora con las pantallas gráficas y las impresoras láser, esto tiene menos importancia.
El control de llamadas y del módem se puede realizar con aplicaciones adicionales que también se pueden desarrollar con el API de Comunicaciones Java। El control de llamadas, normalmente, es lo que proporciona un interfaz para los comandos AT de los módem. Este interfaz suele venir documentado en los manuales del módem. Un ejemplo facilitará la comprensión de este concepto al lector. Se parte de que se tiene un módem conectado al puerto COM1 y que se quiere marcar un número de teléfono. La aplicación Java del control de llamadas preguntará el número de teléfono que se quiere marcar e interrogará al módem; estos comandos son manejados por el API, que no realiza ninguna interpretación de ellos. Es decir, para marcar el numero 608123456, el controlador de llamadas enviará un AT y se quedará esperando OK, cuando lo reciba enviará ATDT608123456. Uno de los cometidos principales de estas aplicaciones de control es el tratar los errores y timeouts que se puedan producir durante la comunicación.
Un interfaz gráfico para el control de los puertos serie। Normalmente, el lector habrá observado que los puertos serie disponen de una ventana de diálogo que permite su configuración, pudiendo especificar la velocidad, paridad, etc.
El diagrama que muestra la figura siguiente describe los objetos involucrados en la lectura o escritura de datos en un puerto serie desde Java.
Conclusión:
Al realizar el presente trabajo nos dimos cuenta que el API java comm es un API muy potente, contando incluso con traducción a nomenclaturapostscript para impresoras antiguas. Sin embargo requiere muchas líneas de código para enviar una simple instrucción hacia el puerto serial y/o paralelo.
En nuestro proyecto de manipular un dispositivo a través del API de comunicación con java no pudo llevarse acabo debido a que hacían falta incluirlos en nuestro programa también nos hizo falta un poco de adentrarnos o conocer mas afondo el uso del programa JAVA, por eso optamos por realizar el programa pero en parte simulación software de nuestro proyecto।
Ahora bien, se puede plantear el problema de que el lector tiene a su disposición un ordenador con puertos serie, y un dispositivo que quiere conectar a través de uno de los puertos, pero no dispone de la implementación del driver correspondiente, y el fabricante todavía no la tiene disponible, solamente proporciona, en el manual del dispositivo, una somera información de cómo se podría acceder al dispositivo a través de llamadas realizadas en C। Y el problema que se plantea es cómo, a través del uso de javax।comm se puede utilizar este dispositivo especial। La respuesta pasa por implementar un interfaz que se comunique con ese dispositivo a través de métodos nativos.
Habría que comprobar el comportamiento del API de Comunicaciones Java ante grandes avalanchas de datos o aplicaciones en tiempo real, en donde sí se puede valorar la bondad de API। No obstante esa duda, la aproximación tan disciplinada que proporciona este API de Comunicaciones hará mucho más sencilla la integración de cualquier dispositivo serie como lectores de códigos de barras, impresoras, lectores de tarjetas, y cientos de otros dispositivos.
