SOCKET VS RMI SOCKET VS RMI Juan Camilo Reyes Resumen Los URL y las conexiones URL (URLConnection) proporcionan un mecanismo de un nivel relativamente alto (nivel 7 del modelo OSI) para acceder a los recursos de Internet. Algunas veces, los programas requieren una comunicación a través de la red, a un nivel un poco más bajo; por ejemplo, cuando se desea escribir una aplicación cliente / servidor. Para este tipo de programas, se utilizan las clases Socket y RMI, provenientes de java, que trabajan en los niveles 3 y 4 del modelo OSI. Palabras claves: Socket, RMI, OSI, conexión, cliente, servidor. Abstract URLs and URL connections (URLConnection) provide a mechanism of a relatively high level (level 7 of the OSI model) to access Internet resources. Sometimes programs require communication over the network, a slightly lower level; For example, when writing a client / server application. For this type of program, use the Java Socket and RMI classes, which work at levels 3 and 4 of the OSI model. Keywords: Socket, RMI, OSI, conection, client, server.
1. Introducción. En las aplicaciones cliente / servidor, el servidor proporciona algún servicio, como por ejemplo: procesamiento de consultas a una base de datos o transmitir los precios actuales de inventario. El cliente utiliza el servicio proporcionado por el servidor, ya sea desplegando los datos de la consulta a la base de datos o haciendo recomendaciones de compra a un inversionista, teniendo en cuenta los precios del inventario. La comunicación entre cliente y servidor debe ser confiable; esto quiere decir que no se pueden perder datos, y que éstos deben llegar al cliente en el mismo orden en el cual fueron enviados por el servidor; por esta razón se utiliza TCP/IP. TCP proporciona un canal de comunicación confiable, punto a punto, que las aplicaciones cliente / servidor utilizan para comunicarse entre ellas a través de Internet. Para comunicarse a través de TCP, se establece una conexión entre el programa
cliente y el programa servidor. Cada programa enlaza un socket en su extremo de la conexión. Para comunicarse, cliente y servidor leen y escriben hacia el socket asociado a la conexión. Cuando se escribe la parte del programa correspondiente al servidor, se abre un conector (socket), normalmente utilizando un número de puerto conocido, y se espera a que se conecte algún cliente. El cliente llama desde algún número de puerto no utilizado (conocido como puerto efímero). En cuanto se conectan el cliente y el servidor, es corriente que éste último proponga que la conversación continúe en un puerto diferente. Este diseño deja libre el número de puerto conocido, para manejar una nueva conexión. Una vez conectados el cliente y el servidor, hay un protocolo de más alto nivel que es dependiente del puerto que se esté utilizando. TCP/IP reserva los primeros 1024 puertos
SOCKET VS RMI para sus protocolos específicos. La siguiente tabla muestra algunos números de puerto conocidos. Estos servicios se ofrecen tanto en puertos TCP como en puertos UDP.
llamado Internet Inter-ORB Protocol o IIOP. La opción propuesta por Microsoft para comunicar objetos remotos es COM (Component Object Model). Hoy este modelo parece haber sido superado por la tecnología .NET. Cuando el cliente y servidor son escritos en Java, la generalidad y complejidad de CORBA no es requerida. En este caso Sun desarrolló RMI, un mecanismo más simple especialmente pensado para comunicación entre aplicaciones Java.
RMI es una tecnología desarrollada por Sun para permitir la colaboración de objetos que están localizados remotamente. Esta tecnología se enmarca en la idea de permitir colaboración entre Objetos Remotos. La idea no es que los objetos se comuniquen a través de la programación del usuario de protocolos estándares de red. La idea es tener un objeto cliente, donde podamos podamos completar un requerimiento de datos. El cliente luego prepara el requerimiento que envía a un objeto ubicado en un servidor. El objeto remoto prepara la información requerida (accediendo a bases de datos, otros objetos, etc). Finalmente el objeto remoto envía la respuesta al cliente. En lo posible esta interacción debería ser lo más semejante posible a requerimientos hechos localmente. En principio se puede anhelar la colaboración de objetos escritos en cualquier lenguaje (no es el caso de RMI). Esta idea no es simple de lograr, corresponde al esfuerzo del grupo OMG (Object Management Group, www.omg.org) los cuales propusieron CORBA (Common Object Request Broker Architecture), el cual define un mecanismo común para descubrir servicios e intercambiar datos. CORBA usa Object Request Broker (ORB) como traductores universales para la comunicación entre objetos. Los objetos remotos hablan a través de estos ORB. El protocolo de comunicación entre objetos y ORB es
2. Marco Teórico. Socket - usted tiene que manejar exactamente qué sockets se utilizan, se especifica TCP o UDP, que maneja todo el formato de los mensajes que viajan entre el cliente y el servidor. Sin embargo, si tiene un programa existente que habla sobre sockets con los que desea interactuar, no importa el idioma en el que esté escrito, siempre y cuando coincidan los formatos de los mensajes. En los sockets dos programas establecen conexión y se envían mensajes. Estos mensajes pueden ser cualquier clase java que implemente la interface Serializable En rmi un programa (cliente) le pide al otro (servidor) una instancia remota (objeto remoto) de una clase y luego llama a sus métodos. Los métodos, aunque son llamados en el código del cliente, se ejecutan en el servidor. Los parámetros que se pasan a los métodos y el resultado devuelto deben ser clases que implementen Serializable o tipos primitivos de datos RMI - oculta gran parte del código específico de la red, no tiene que preocuparse por los puertos específicos utilizados (pero puede hacerlo si lo desea), RMI gestiona el formato de los mensajes entre cliente y servidor. Sin embargo, esta opción es realmente sólo para la comunicación entre los 2
SOCKET VS RMI programas Java. (Usted * podría * interfaz de los programas Java RMI con los programas escritos en otros idiomas, pero probablemente hay maneras más fáciles de hacerlo ...) RMI se construye en la parte superior de los sockets, traduce llamadas de método y devuelve valores y los envía a través de sockets. VENTAJAS E INCONVENIENTES Codificación: El establecimiento de la conexión es similar en número de líneas de código en ambos casos (un par de líneas). Los sockets necesitan más código para identificar qué mensaje llega y tratarlo en consecuencia (sentencias switch-case o tantos if como tipos de mensaje distintos). En rmi se hace con llamadas a métodos, por lo que no es necesario ningún tipo de codificación adicional. En rmi se necesitan una serie de herramientas adicionales, compilar los objetos remotos además de con javac con rmic y finalmente tener lanzado el programa rmiregistry. En los sockets se envía un mensaje y se debe esperar por la respuesta, que puede llegar o no. Las lecturas de mensajes dejan bloqueado el hilo hasta que llegan. En rmi la llamada queda bloqueada hasta recibir la respuesta. En ambos casos suele ser necesario el uso de hilos si las respuestas pueden tardar. Ancho de banda: En los sockets, por la red sólo se envían los mensajes que nosotros enviamos. En rmi, se envía además todo el protocolo interno de rmi, que suele ser de un tamaño considerable. En general, rmi consume más ancho de banda de nuestro enlace físico que los sockets. Comunicación con otros lenguajes: rmi es puramente java, así que sólo puede integrarse entre dos programas java. Con sockets podemos comunicarnos con cualquier otro programa hecho en cualquier otro lenguaje, aunque tendremos que enviar los mensajes campo a campo para hacerlos compatibles con el otro lenguaje.
Mensajes en broadcast. Los sockets permiten enviar mensajes sin destinatario, de forma que cualquiera puede recogerlo. Con rmi la comunicación siempre es punto a punto. Carga dinámica de clases. Rmi permite la carga dinámica de clases, es decir, el servidor puede pasar al cliente clases que este no tenga en su CLASSPATH en tiempo de ejecución y viceversa. Esto hace que ampliar dinámicamente el comportamiento de una aplicación rmi sea más sencillo.
CONCLUSIONES CUÁNDO USAR SOCKETS Y CUÁNDO USAR RMI Si nuestro enlace físico es lento (puerto RS232, modem, etc) es mejor usar sockets. Si tenemos pocos tipos de mensajes y se usan para transmitir muchos datos (por ejemplo, transferencia de ficheros), es mejor sockets. Si el servidor ofrece muchas funcionalidades, es mejor rmi. Si la aplicación servidor va a modificarse con cierta frecuencia y no queremos tener que actualizar todos los clientes uno a uno, la carga dinámica de clases de rmi puede ser una solución. REFERENCIAS BIBLIOGRAFICAS
3
https://docs.oracle.com/javase/7/docs/api/java/net/ Socket.html
https://cloud.google.com/appengine/docs/standard/ java/sockets/
http://www.javaworld.com/article/2077322/corejava/core-java-sockets-programming-in-java-atutorial.html
http://www.public.iastate.edu/~java/docs/guide/rmi /index.html
