1

Sockets en Java - (cliente y servidor)

Los sockets son básicamente formas en las que podemos interconectar 2 (o más) programas mediante el uso
de la internet. En java se utilizan para poder crear conexiones utilizando básicamente una IP/hostname y un
puerto para establecer la conexión. Para aprender podemos utilizarla para conectar 2 programas por medio
de Internet. ¿Cómo funciona?
El modelo más basico de los sockets consta de 2 simples programas, un servidor y un cliente. Basicamente el
programa servidor comienza a “escuchar” en un puerto determinado (nosotros lo especificamos), y
posteriormente el programa que la hace de “cliente” debe conocer la ip o nombre de dominio/hostname del
servidor y el puerto que está escuchando, al saber esto simplemente solicita establecer una conexión con el
servidor. Es aqui cuando el servidor acepta esa conexión y se puede decir que estos programas estan
“conectados”, de este modo pueden intercambiar información. En el siguiente video muestro un programa
servidor con sockets, explico más o menos el codigo, en que consiste y hago una prueba en el cual la
conexión es exitosa.

Otro Autor dice: Usando sockets en Java. Una simple aplicación cliente servidor usando sockets

Los sockets son un mecanismo que nos permite establecer un enlace entre dos programas que se ejecutan
independientes el uno del otro (generalmente un programa cliente y un programa servidor) Java por medio
de la librería [Link] nos provee dos clases: Socket para implementar la conexión desde el lado del cliente
y ServerSocket que nos permitirá manipular la conexión desde el lado del servidor.

Antes de comenzar a ver código (que es lo que todos queremos) explicaré cómo será el funcionamiento de
nuestra aplicación cliente servidor usando sockets en Java, cabe resaltar que tanto el cliente como el
servidor no necesariamente deben estar implementados en Java, solo deben conocer sus direcciones IP y el
puerto por el cual se comunicarán. Para nuestro ejemplo de sockets implementaremos ambos (cliente y
servidor) usando Java y se comunicarán usando el puerto 1234 (es bueno elegir los puertos en el rango de
1024 hasta 65535). La dinámica del ejercicio será como se ve:
 2

El servidor estará a la espera de una conexión, en

cuanto el cliente inicie enviará un mensaje de
petición al servidor, éste le responderá
afirmativamente y una vez recibida la confirmación,
el cliente enviará un par de mensajes y la conexión
finalizará.

Como verás es un ejemplo simple, sin muchas

complicaciones, así que manos a la obra, veamos el
código:

Clase Conexión, usando sockets en java

Crearemos una clase llamada Conexión en el paquete sockets que nos dará los datos que necesitaremos en
el cliente y en el servidor

La clase Conexion simplemente nos brinda los datos que necesitados, mensajes de entrada, flujo de salida
socket para el Cliente y socket para el servidor, estos últimos respectivamente inicializados desde el
constructor. Las clases Cliente y Servidor que veremos en breve van a heredar de la clase Conexion para
tener acceso a los atributos y a los sockets sin problemas. Ahora vemos nuestro servidor:

La clase Servidor

La clase Servidor básicamente estará a la espera de que un cliente se conecte a él usando el socket en el
puerto 1234, recibirá los mensajes, los mostrará y cerrará la conexión, es todo.
 3

Tenemos en este código entonces al servidor que espera la conexión desde el cliente en el método accept(),
una vez ésta sucede, envía un mensaje de confirmación con writeUTF("mensaje"), lee todos los mensajes
enviados por el cliente con readLine() y cierra la conexión con el método close(). Veamos ahora la clase
Cliente.

La clase Cliente

La clase Cliente, establecerá la conexión con el servidor usando un socket en localhost y el puerto 1234, una
vez establece la conexión escribe dos mensajes en el servidor usando un ciclo for y cierra la conexión.
 4

Veamos:

Vemos entonces que el cliente obtiene el flujo de salida de datos hacia el Servidor con el
método getOutputStream y lo usa para enviarle un par de mensajes con el método writeUTF("mensaje..."),
finalmente cierra la conexión con close(). Notar que si se desea enviar más de dos mensajes bastará con
cambiar el límite superior del ciclo for i < 100 por ejemplo.

Pues muy bien ya tenemos todo, aunque los segmentos de código con un poco extensos (no demasiado) son
bastante simples y están bien comentados, a continuación pondré los códigos para los respectivos main que
harán uso del servidor y del cliente.
 5

Un Servicio web RESTful en Java con Apache Tomcat 8 y Jersey 2 Jax-RS. Retornando XML, JSON y HTML

Los servicios RESTful son una práctica forma de desarrollar servicios web que funcionan sobre el
protocolo HTTP, facilitando la comunicación e invocación de estos. Los servicios RESTful reciben peticiones
por medio de direcciones URL (o URIs) y retornan una respuesta particular en algún formato adecuado (XML,
JSON, HTML, texto plano, etc.).

En esta sección desarrollaremos un servicio web RESTful en Java usando la librería Jersey la cual es una
implementación de JAX-RS. Nuestro servicio será muy simple, recibirá una petición a una dirección específica
y retornará un mensaje en texto en algún formato (según la petición), será como un Hola Mundo en RESTful,
pero con más detalles y adiciones.

Nuestro servicio lo desplegaremos en un servidor Apache Tomcat en su versión 8 que podremos descargar
del enlace (apache-tomcat), usaremos la librería Jersey en su versión 2.14 la cual implementa JAX-RS2.0 que
podemos descargar en (Librería Jersey). Del .zip de Jersey, tomaremos todos los .jar que están en cada una
de las carpetas (api, ext y lib).

La estructura de carpetas para nuestro proyecto será la siguiente (explicación paso a paso más abajo):
 6

Estructura de carpetas para el servicio web RESTful con Java y Apache Tomcat

Una vez descargado apache tomcat lo podremos descomprimir en una carpeta llamada "servidor" en
nuestro disco C:/ para acceder a él fácilmente, dentro de la carpeta servidor encontraremos otra carpeta
llamada webapps, al interior de ésta crearemos una nueva carpeta llamada RESTful (fijarse en las
mayúsculas y minúsculas) y dentro de ésta crearemos otra llamada WEB-INF (debe estar en mayúsculas),
esta carpeta WEB-INF tendrá dentro de sí un archivo llamado [Link], una carpeta llamada lib y otra
llamada classes. Dentro de la carpeta lib pondremos todos los archivos .jar de .zip de jersey. Dentro de la
carpeta classes pondremos la estructura del paquete de nuestro servicio web que será [Link], quiere
decir que la carpeta ws contendrá el archivo .java del servicio web que llamaremos [Link].

Ahora veamos el contenido de los archivos [Link] y [Link]

El archivo [Link]

El archivo [Link] será el código de funcionamiento del servicio web, será el que indique qué hacer
al recibir peticiones por algún tipo de mensaje HTTP (put, get, delete, post, etc.).

Tenemos entonces en el código anterior un servicio web que funciona en la ruta getMessage/type donde
type puede ser cualquier cosa, pero solo se aceptará texto, HTML, XML y JSON si es diferente a estos, se
retorna un mensaje en texto plano diciendo "Tipo no soportado". Hay que notar que únicamente tenemos
un método el cual puede ser llamado usando el método get de HTTP, es decir que lo podremos invocar
incluso desde el navegador web. Este método al ser el único posee múltiples tipos MIME de respuestas (para
XML, HTML, JSON y texto plano) que se especificaron en un pequeño arreglo en el marcador @Produces.
Cabe resaltar que el valor del parámetro enviado por URL se obtiene con la anotación @PathParam("type"),
nótese que debe coincidir con lo que se puso en @Path.

Muy bien ahora lo que haremos será compilar nuestro [Link]. Debido a que no estamos usando
ningún entorno de desarrollo usaremos el comando javac desde la consola
 7

Al ejecutar esto desde la consola tendremos junto al archivo [Link] un archivo llamado
[Link].

Nota: Si obtienes algún problema con la compilación, verifica haber copiado bien el código de arriba y
haberlo colocado en las carpetas que corresponden según el paquete.

El archivo [Link]

Este archivo aunque pequeño es totalmente indispensable para el correcto funcionamiento y despliegue de
nuestro servicio web. No profundizaré mucho respecto al archivo [Link] como tal, solo mencionaré que el
valor de <param-value> en <init-param> debe coincidir con la ruta del paquete donde se encuentra el
archivo .java y que <url-pattern> especifica la ruta donde se "ubicará"" inicialmente el servicio web para ser
invocado según el valor de la etiqueta @Path. Para este caso al poner /* indicamos que no es necesario
añadir nada a la ruta y que después del slash (/) puede ir cualquier cosa; esto quiere decir que una ruta para
invocar nuestro servicio web puede ser [Link] si pusiéramos
que el valor de <url-pattern> fuera /servicios/* entonces para invocar el servicio ya deberíamos usar la
URL [Link]

Una vez ya tenemos nuestro archivo [Link] compilado y hemos creado nuestro archivo [Link] y
todos los archivos, librerías, carpetas y demás se encuentran en la ruta correcta, solo nos queda arrancar el
servidor Tomcat e invocar nuestro servicio web (usando el navegador por ejemplo).

Para correr el servidor, también lo podemos hacer desde consola o iniciando directamente el archivo
[Link] en windows o [Link] en Linux que se encuentran en la carpeta bin de Tomcat, veámoslo
desde consola:
 8

Si todo ha ido bien, podemos ingresar a la URL [Link] y

obtendremos un mensaje que dice "Éste es mi primer servicio RESTful con Java", si miramos el código fuente
de esa página podremos ver que el servicio escribió <?xml version='1.0' encoding='UTF-8'?
><root><value>Éste es mi primer servicio RESTful con Java</value></root>

Si ingresamos a la dirección [Link] obtendremos como

respuesta lo siguiente: {"root":{"value":"Éste es mi primer servicio RESTful con Java"}} Notemos que la E
tildada se ve mal puesto que el archivo JSON no posee formato a diferencia del XML y el HTML.

Si ingresamos por ejemplo a [Link] obtendremos como

respuesta: "Tipo no soportado" puesto que PHP no hace parte de nuestros tipos MIME considerados.

Resumen de servicios web

Se puede conectar un cliente de servicio web a un servicio web de Informatica para acceder, transformar o
entregar datos. Es posible conectar una aplicación externa o una transformación de consumidor de servicio
web a un servicio web como cliente de servicio web.

Un servicio web puede procesar solicitudes de información, de actualización de datos o de ejecución de

tareas. Por ejemplo, un cliente de servicio web envía una solicitud para ejecutar una operación de servicio
web. El cliente de servicio web pasa un ID de cliente en la solicitud. El servicio web recupera la información
de cliente y pedido y devuelve la información al cliente en una respuesta.

Los servicios web de Informatica se comunican con los clientes de servicio web a través de los protocolos de
mensajería Protocolo simple de acceso a objetos (Simple Object Access Protocol, SOAP) o Transferencia de
estado representacional (Representational State Transfer, REST).

Servicio web SOAP

Servicio web que utiliza el protocolo SOAP. La solicitud del cliente del servicio web y la respuesta del servicio
web son mensajes SOAP. El lenguaje de descripción de servicios web (web service description language,
WSDL) es un lenguaje de definición de interfaz basado en XML que describe la funcionalidad de un servicio
web. Los archivos WSDL contienen una descripción sobre el método de invocación del servicio web, los
parámetros que espera dicho servicio y las estructuras de datos que devuelve. Es posible crear un servicio
web SOAP de Informatica a partir de un archivo WSDL.

Transformación de consumidor de servicio web SOAP

Se conecta a un servicio web como un cliente del servicio web para acceder a datos o transformarlos
durante un proceso de asignación. Es posible crear una transformación de consumidor de servicio web SOAP
a partir de WSDL

Servicio web REST

 9

Servicio web que recibe una solicitud HTTP para ejecutar las operaciones de servicios web. Un servicio web
REST de Informatica puede recibir una solicitud HTTP para ejecutar una operación GET. Un servicio web REST
de Informatica puede devolver una respuesta en un archivo JSON XML.

Transformación de consumidor REST

Se conecta a un servicio web REST como un cliente del servicio web para acceder a datos o transformarlos
durante un proceso de asignación. La transformación de consumidor de servicio web REST se conecta a un
servicio web mediante una URL que se define en la transformación, en una conexión HTTP o en una
conexión HTTPS. Los mensajes de solicitud y respuesta contienen datos en formato XML o JSON.

Diferencias entre los servicios web REST y SOAP

Formato de mensaje de solicitud

Los mensajes SOAP presentan una estructura XML. Los servicios web SOAP analizan el código XML para
determinar la operación que debe realizar el servicio web. La solicitud REST consiste en una cadena URI
simple con una consulta.

Formato de mensaje de respuesta

El servicio web SOAP devuelve una respuesta en formato XML según los parámetros definidos por el WSDL.

El servicio web REST de Informatica devuelve mensajes de respuesta Notación de objeto JavaScript
(JavaScript Object Notation, JSON) o XML. El formato de mensaje de respuesta no viene definido por un
WSDL ni por un esquema. El formato de salida se define al definir el servicio web REST de Informatica.

Formato de asignación de servicio web

Los servicios web SOAP de Informatica contienen asignaciones de operaciones. Las asignaciones de
operaciones SOAP contienen una transformación de entrada que analiza el código XML proveniente de un
mensaje de solicitud. Añada transformaciones a la asignación de servicio web para procesar los datos según
la solicitud de cliente.

Los servicios web REST de Informatica contienen asignaciones de recursos. La asignación de recursos no lee
la consulta de la solicitud. La asignación de recursos REST contiene una transformación de lectura en lugar
de una de entrada. La transformación de lectura lee un objeto de datos del repositorio de modelos para
recuperar los datos que se devolverán al cliente. De forma predeterminada, no es necesario añadir una
transformación de filtro ni de búsqueda para recuperar los datos a partir de la consulta del cliente. El
servicio web REST filtra los datos de salida una vez que la asignación devuelve los datos.

Proceso del servicio web

Los servicios web reciben solicitudes de los clientes de servicios web.

El siguiente proceso describe la forma en que el servicio de integración de datos procesa las solicitudes de
servicio web procedentes de clientes de servicio web:

1. El servicio de integración de datos recibe una solicitud procedente de un cliente de servicio web.
2. El módulo de servicios web o bien el módulo de servicios web REST del servicio de integración de datos
procesa la solicitud mediante la ejecución de una asignación.
3. El módulo de servicios web o bien el módulo de servicios web REST envía una respuesta al cliente de
servicio web.
 10

Proceso de transformación de consumidor de servicio web

Es posible conectar una aplicación externa o una transformación de consumidor de servicio web a un
servicio web como cliente de servicio web.
En el siguiente proceso se describe la forma en que una transformación de consumidor de servicio web
envía una solicitud y recibe una respuesta de un servicio web:

1. La transformación de consumidor de servicio web genera una solicitud y se conecta con el servicio web
mediante un objeto de conexión.
2. La transformación de consumidor de servicio web recibe la respuesta del servicio web.
3. La transformación de consumidor de servicio web extrae los datos de la respuesta y los devuelve en
puertos de salida de transformación.

Componentes de servicio web SOAP

Los componentes de un servicio web SOAP definen el objetivo del servicio web y la vía de comunicación del
cliente de servicio web con el servicio web.

Un servicio web posee los siguientes componentes:

Operaciones

Por otra parte, un servicio web puede contener una o varias operaciones. Cada operación corresponde a una
acción en el servicio web.

Web Services Description Language (WSDL)

Un WSDL es un documento XML que describe los protocolos, formatos y firmas de las operaciones de un
servicio web.

Simple Object Access Protocol (SOAP)

SOAP es el protocolo de comunicación para los servicios web.

////OTRO AUTOR

La diferencia entre SOAP y REST API. Quizás ya esté familiarizado con SOAP y REST, y busque expandir sus
conocimientos u obtener una nueva perspectiva. O tal vez escuchó sobre ellos y está tratando de
comprenderlos mejor. Después de todo, SOAP y REST están bien establecidos con definiciones y
especificaciones que se remontan a décadas.

Permítame describir la diferencia SOAP y REST, comparar y, de lo contrario, arrojar luz sobre estos dos
enfoques importantes para el servicio web y el diseño de API web. También destacaré algunos de los
desafíos de prueba asociados con estos enfoques y cómo resolverlos. Primero, definamos qué son y cómo se
relacionan con la World Wide Web.
 11

Diferencia entre servicios web SOAP y REST

El Consorcio World Wide Web (W3C) recomienda estándares y protocolos para la colección global de
recursos interconectados que conocemos como World Wide Web. Se accede a un recurso "web" en una
dirección "web" y se entrega a través de un protocolo "web".

Como alguien que lee esta publicación de blog, es posible que sepa que está leyendo un documento HTML
en el URI que se muestra en la barra de direcciones de su navegador que se solicitó y entregó mediante el
protocolo HTTP (S). El W3C definió cómo estas mismas tecnologías que le permiten leer esta publicación de
blog pueden facilitar la comunicación entre sistemas de software. En particular, el W3C definió los "servicios
web", lo que llevó a la creación de muchos otros estándares y tecnologías a lo largo de los años. Echemos un
vistazo de alto nivel a lo que son.

Ahora, profundicemos en algunos detalles sobre la diferencia entre el jabón y el descanso, entendiendo
cómo estos enfoques se comparan entre sí.

Operaciones

Un servicio SOAP define un conjunto de operaciones. Las operaciones pueden ser arbitrarias en el sentido de
que no existen restricciones en el alcance o propósito de las operaciones que se definen. Las operaciones
tienen una firma, típicamente representativa del nombre completo del elemento dentro del elemento
Cuerpo del sobre. Por ejemplo, el nombre del elemento podría ser "calcular algo" o "hacer algo divertido".

Una API REST tiene una colección de operaciones para cada recurso. Las operaciones que están disponibles
se limitan a CRUD (crear, recuperar, actualizar y eliminar). Las operaciones se asignan a métodos HTTP como

GET, POST, PUT, PATCH y DELETE.

 12

Representación de datos
La mensajería SOAP implica el intercambio de documentos XML denominados sobres SOAP. Un sobre SOAP
contiene un elemento "Cuerpo" y un elemento "Encabezado" opcional. El XML dentro del elemento "Body"
puede ser arbitrario, pero normalmente representa una o más entidades u objetos. El tipo de contenido es
“texto / xml” o “aplicación / jabón + xml” dependiendo de si se está siguiendo la versión 1.1 de SOAP o la
versión 1.2 de SOAP. Los elementos XML en SOAP también se pueden usar para envolver otros tipos de
datos, textuales o binarios. Los métodos definidos por el W3C llamados “XOP” y “MTOM” describen cómo
empaquetar de manera eficiente datos binarios en mensajes XML y SOAP como un MIME “Multiparte /
Related”, evitando la necesidad de codificar en base64 los datos binarios directamente dentro de las
etiquetas XML.

La mensajería de la API REST implica el intercambio de representaciones de un recurso. Una

"representación" puede ser cualquier formato de datos. Podría ser un formato de intercambio / intercambio
de datos estructurados como XML o JSON, o algo completamente diferente como PDF o JPEG. No hay
restricción de tipo de contenido. Una API REST podría admitir múltiples formatos de datos o diferentes
formatos de datos para diferentes recursos.
 13

Extensibilidad
SOAP y REST son extensibles pero de formas muy diferentes. Vamos a sumergirnos en la comparación.
 14

Interoperabilidad
SOAP se diseñó teniendo en cuenta la interoperabilidad, siguiendo estándares abiertos, sin estar ligado a
ninguna implementación, plataforma o lenguaje de programación específicos. Sin embargo, algunas cosas de
la especificación se dejaron abiertas a interpretación. Algunas partes pueden ser confusas o tener errores o
errores tipográficos o malos ejemplos. Los problemas surgen de cosas simples como si:

Se supone que un valor particular debe estar entre comillas o no.

Ciertas construcciones XML están bien o deben evitarse.

Se deben permitir o restringir tipos específicos de cosas en el cuerpo de SOAP.

Otro organismo de normalización, el Organización de interoperabilidad de servicios web (WS-I), surgió para
proporcionar pautas para la interoperabilidad de servicios web. El WS-I proporciona varios perfiles de
interoperabilidad. Cada perfil tiene una lista de requisitos y una lista de afirmaciones, que definen cómo
verificar los requisitos. En resumen, los perfiles WS-I dicen cosas como "deberías hacer esto" y "no deberías
hacer aquello". Dato curioso: Parasoft contribuyó al documento de afirmaciones de prueba (TAD) de WS-I
Basic Profile 1.1.

Las API REST son interoperables en el sentido de que son fáciles de invocar. Hay muchas herramientas y API
que pueden realizar solicitudes HTTP. Las herramientas populares incluyen cURL y Cartero. Incluso se puede
utilizar un formulario simple en una página web para realizar solicitudes HTTP. También hay varios
estándares abiertos que se utilizan normalmente para las API REST además de HTTP, incluidos los formatos
de mensajes abiertos como JSON. Las API REST también pueden implementar varios estándares abiertos de
seguridad y autorización (más sobre esto más adelante).
 15

Seguridad

La seguridad es una consideración importante tanto para SOAP como para REST. La seguridad de la capa de
transporte es necesaria para cifrar los mensajes a medida que se envían por cable para evitar escuchas. La
seguridad de la capa de mensajes es necesaria para la seguridad de extremo a extremo, por lo que el
mensaje está protegido de cualquier intermediario que pueda tener acceso a él antes de llegar a su destino
previsto. Se necesitan mecanismos de autenticación o autorización para establecer la identidad entre cliente
y servidor.

Definiciones de servicios

Hay varios tipos de formatos de documentación de consumibles de máquina para servicios SOAP y REST. Los
documentos de definición de servicios permiten el procesamiento automatizado, como la generación de
código automatizado para clientes o resguardos de servicio. Los documentos de definición de servicios
también se pueden traducir a un formato de documentación amigable para el ser humano como una página
web.
 16

Cada formato de definición de servicio tiene su propia colección de herramientas para la generación de
códigos y documentos. Esto significa que debe utilizar un conjunto diferente de herramientas según la
implementación del servicio. Sin embargo, existen convertidores para que pueda convertir un documento
OpenAPI en una RAML (o viceversa).

¿Cómo se supone que debo probar todo esto? 😵

REST y SOAP ofrecen sus propias compensaciones y desafíos, especialmente con respecto a las pruebas. Para
probar una API, debe poder crear clientes, enviar datos de entrada y luego poder ver y validar la salida que
se devolvió.