Servicios web en Java SE, parte 1: descripción general de las herramientas

Java Standard Edition (SE) 6 incluyó soporte para servicios web. Esta publicación comienza una serie de cuatro partes sobre servicios web en Java SE explicando qué son los servicios web y repasando el soporte de Java SE para ellos. Las publicaciones futuras utilizarán este soporte para crear servicios web basados ​​en SOAP y RESTful, y también cubrirán temas de servicios web avanzados.

Java XML y JSON

En esta serie, supongo que comprende XML y JSON. Si no, es posible que desee consultar mi libro Java XML y JSON , que se anuncia al final de esta publicación.

¿Qué son los servicios web?

Wikipedia define el servicio web como "un sistema de software diseñado para soportar la interacción interoperable de máquina a máquina en una red". Se puede obtener una definición más detallada definiendo primero las partes de este término:

  • Web: una enorme red interconectada de recursos, donde un recurso es una fuente de datos con nombre de identificador uniforme de recursos (URI), como un documento basado en PDF, una transmisión de video, una página web o incluso una aplicación. Se puede acceder a estos recursos mediante protocolos estándar de Internet como el Protocolo de transferencia de hipertexto (HTTP) o el Protocolo simple de transferencia de correo (SMTP).
  • Servicio: Una aplicación o componente de software basado en servidor que expone un recurso a los clientes mediante un intercambio de mensajes de acuerdo con un patrón de intercambio de mensajes (MEP). El MEP de solicitud-respuesta es típico.

Dadas estas definiciones, un servicio web es una aplicación / componente de software basado en servidor que expone un recurso basado en web a los clientes a través de un intercambio de mensajes. Estos mensajes pueden formatearse según el lenguaje de marcado extensible (XML) o la notación de objetos JavaScript (JSON). Además, se puede pensar que estos mensajes invocan funciones de servicios web y reciben resultados de invocación. La figura 1 ilustra este intercambio de mensajes.

Figura 1. Un cliente accede a un recurso mediante el intercambio de mensajes con un servicio web.

Empresas y servicios web

Las empresas utilizan los servicios web porque superan los problemas tradicionales del middleware (p. Ej., Costosos de obtener y mantener, incapaces de comunicarse con el software de backend y las aplicaciones cliente a través de Internet e inflexibles) al basarse en estándares libres y abiertos, por su capacidad de mantenimiento, por involucrar la Web y siendo flexible. Además, ayudan a las empresas más grandes a preservar sus inversiones a menudo significativas en software heredado.

Los servicios web pueden clasificarse en simples o complejos. Los servicios web simples no interactúan con otros servicios web (por ejemplo, una aplicación autónoma basada en servidor con una única función que devuelve la hora actual para una zona horaria específica). Por el contrario, los servicios web complejos a menudo interactúan con otros servicios web. Por ejemplo, un servicio web de red social generalizada podría interactuar con los servicios web de Twitter y Facebook para obtener y devolver a su cliente toda la información de Twitter y Facebook de un individuo específico. Los servicios Web complejos son también conocidos como mashups porque puré (combinar) los datos de varios servicios web.

Arquitectura orientada a Servicios

Los servicios web son una implementación de Arquitectura Orientada a Servicios (SOA) , que es un estilo de diseño de software en el que se proporcionan servicios a varios componentes de software a través de un protocolo de comunicación a través de una red. Piense en SOA como un conjunto de principios de diseño o un marco para implementar la lógica empresarial como servicios reutilizables que se pueden combinar de diferentes formas para satisfacer los requisitos empresariales en evolución.

Servicios web basados ​​en SOAP

Un servicio web basado en SOAP es una categoría de servicios web ampliamente utilizada que se basa en SOAP , un lenguaje XML para definir mensajes (invocaciones de funciones abstractas o sus respuestas) que pueden ser entendidos por ambos extremos de una conexión de red. Un intercambio de mensajes SOAP se denomina operación , que corresponde a una llamada de función y su respuesta, y que se muestra en la Figura 2.

Figura 2. Una operación de servicio web implica mensajes de entrada y salida

Las operaciones relacionadas a menudo se agrupan en una interfaz , que es conceptualmente similar a una interfaz Java. Una vinculación proporciona detalles concretos sobre cómo una interfaz está vinculada a un protocolo de mensajería (particularmente SOAP) para comunicar comandos, códigos de error y otros elementos a través del cable. El enlace y una dirección de red (una dirección IP y un puerto) URI se conoce como un punto final , y una colección de puntos finales es un servicio web . La Figura 3 presenta esta arquitectura.

Figura 3. Se puede acceder a las interfaces de operaciones a través de sus puntos finales

SOAP se utiliza a menudo con el lenguaje de descripción de servicios web (WSDL, que se pronuncia como un genio) , un lenguaje XML para definir las operaciones de un servicio web. Un documento WSDL es un contrato formal entre un servicio web basado en SOAP y sus clientes, que proporciona todos los detalles para interactuar con el servicio web. Este documento le permite agrupar mensajes en operaciones y operaciones en interfaces. También le permite definir un enlace para cada interfaz, así como la dirección del punto final.

Además de admitir documentos WSDL, los servicios web basados ​​en SOAP tienen las siguientes propiedades:

  • La capacidad de abordar requisitos complejos no funcionales como la seguridad y las transacciones: estos requisitos están disponibles a través de varias especificaciones. Para promover la interoperabilidad entre estas especificaciones, se formó la Organización de Interoperabilidad de Servicios Web (WS-I) (un consorcio industrial). WS-I ha establecido un conjunto de perfiles, donde un perfil es un conjunto de especificaciones de servicios web con nombre en niveles de revisión específicos, junto con un conjunto de pautas de implementación e interoperabilidad que recomiendan cómo se pueden utilizar las especificaciones para desarrollar servicios web interoperables. Por ejemplo, el primer perfil, WS-I Basic Profile 1.0 , consta del siguiente conjunto de especificaciones de servicios web no propietarios:
  • SOAP 1.1
  • WSDL 1.1
  • Descubrimiento e integración de descripciones universales (UDDI) 2.0
  • XML 1.0 (segunda edición)
  • Esquema XML, parte 1: estructuras
  • Esquema XML, parte 2: tipos de datos
  • RFC2246: Protocolo de seguridad de la capa de transporte versión 1.0
  • RFC2459: Certificado de infraestructura de clave pública X.509 de Internet y perfil de CRL
  • RFC2616: Protocolo de transferencia de hipertexto 1.1
  • RFC2818: HTTP sobre TLS
  • RFC2965: Mecanismo de administración de estado HTTP
  • El protocolo de capa de sockets seguros versión 3.0

Los ejemplos de perfiles adicionales incluyen WS-I Basic Security Profile y Simple SOAP Binding Profile. Para obtener más información sobre estos y otros perfiles, visite el sitio web de WS-I. Java SE admite el perfil básico WS-I.

  • La capacidad de interactuar con un servicio web de forma asíncrona: los clientes de servicios web deben poder interactuar con un servicio web de forma asíncrona y sin bloqueos. El soporte de invocación asíncrona del lado del cliente de las operaciones de servicios web se proporciona en Java SE.

Los servicios web basados ​​en SOAP se ejecutan en un entorno que incluye un solicitante de servicios (el cliente), un proveedor de servicios y un intermediario de servicios. Este entorno se muestra en la Figura 4.

Figura 4. Un servicio web basado en SOAP involucra a un solicitante de servicios, un proveedor de servicios y un intermediario de servicios (p. Ej., UDDI)

El solicitante del servicio, típicamente una aplicación cliente (por ejemplo, un navegador web), o quizás otro servicio web, primero localiza al proveedor de servicios de alguna manera. Por ejemplo, el solicitante del servicio puede enviar un documento WSDL a un agente de servicios, que responde con otro documento WSDL que identifica la ubicación del proveedor de servicios. El solicitante del servicio se comunica entonces con el proveedor del servicio a través de mensajes SOAP.

Los proveedores de servicios deben publicarse para que otros puedan localizarlos y utilizarlos. En agosto de 2000, se lanzó una iniciativa industrial abierta conocida como Descripción, Descubrimiento e Integración Universal (UDDI) para permitir que las empresas publiquen listados de servicios, se descubran entre sí y definan cómo los servicios o las aplicaciones de software interactúan en Internet. Sin embargo, este registro basado en XML, independiente de la plataforma, no se adoptó ampliamente y actualmente no se utiliza. Muchos desarrolladores encontraron que UDDI era demasiado complicado y carecía de funcionalidad, y optaron por alternativas como publicar la información en un sitio web. Por ejemplo, Google una vez puso a disposición sus servicios web públicos (por ejemplo, Google Maps) en //code.google.com/more/.

Los mensajes SOAP que fluyen entre los solicitantes de servicios y los proveedores de servicios a menudo no se ven, y se pasan como solicitudes y respuestas entre las bibliotecas SOAP de sus pilas de protocolos de servicios web. Sin embargo, es posible acceder a estos mensajes directamente, como descubrirá más adelante en esta serie.

Grandes servicios web

Los servicios web basados ​​en SOAP también se conocen como grandes servicios web porque se basan en muchas especificaciones, como los perfiles WS-I mencionados anteriormente.

Servicios web RESTful

Los servicios web basados ​​en SOAP se pueden entregar a través de protocolos como HTTP, SMTP, FTP y Blocks Extensible Exchange Protocol (BEEP). La entrega de mensajes SOAP a través de HTTP puede verse como un tipo especial de servicio web RESTful.

Un servicio web RESTful es una categoría de servicio web ampliamente utilizada que se basa en la transferencia de estado representacional (REST) , un estilo de arquitectura de software para sistemas hipermedia distribuidos (sistemas en los que las imágenes, el texto y otros recursos se encuentran alrededor de las redes y son accesibles a través de hipervínculos) . El sistema hipermedia de interés en un contexto de servicios web es la World Wide Web.

REST historia

Roy Fielding (autor principal de las versiones 1.0 y 1.1 de la especificación HTTP, y cofundador de la Apache Software Foundation) introdujo y definió REST en su tesis doctoral en 2000. Fielding imaginó REST como el estilo arquitectónico de la Web, aunque escribió mucho después de que la Web fuera una empresa en marcha. REST es ampliamente considerado como la solución a lo que se considera la creciente complejidad de los servicios web basados ​​en SOAP.

La parte central de REST es el recurso identificable por URI. REST identifica los recursos por sus tipos de Extensiones de correo de Internet multipropósito (MIME) (como texto / xml). Además, los recursos tienen estados que son capturados por sus representaciones. Cuando un cliente solicita un recurso de un servicio web RESTful, el servicio envía una representación del recurso con tipo MIME al cliente.

Los clientes utilizan los verbos POST, GET, PUT y DELETE de HTTP para recuperar representaciones de recursos y manipular recursos. REST asigna estos verbos a las operaciones de creación, lectura, actualización y eliminación (CRUD) de la base de datos, de la siguiente manera:

  • POST: crea un nuevo recurso basado en los datos de la solicitud.
  • OBTENER: lea el recurso existente sin producir efectos secundarios (no modifique el recurso).
  • PUT: actualiza el recurso existente con los datos de la solicitud.
  • ELIMINAR: Elimina el recurso existente.

Cada verbo va seguido de un URI que identifica el recurso. (Este enfoque inmensamente simple es fundamentalmente incompatible con el enfoque de SOAP de enviar mensajes codificados a un solo recurso). El URI puede referirse a una colección, como //javajeff.ca/library, oa un elemento de la colección, como //javajeff.ca/library/9781484219157: estos URI son solo ilustraciones.

Para las solicitudes POST y PUT, los datos de recursos basados ​​en XML se pasan como el cuerpo de la solicitud. Por ejemplo, podría interpretar POST //javajeff.ca/library HTTP/ 1.1(donde HTTP/ 1.1describe la versión HTTP del solicitante) como una solicitud para insertar POSTdatos XML en el //javajeff.ca/libraryrecurso de recopilación.

Para las solicitudes GET y DELETE, los datos generalmente se pasan como cadenas de consulta, donde una cadena de consulta es la parte de un URI que comienza con un ?carácter. Por ejemplo, donde GET //javajeff.ca/librarypodría devolver una lista de identificadores para todos los libros en un libraryrecurso, GET //javajeff.ca/library?isbn=9781484219157probablemente devolvería una representación del recurso del libro cuya cadena de consulta identifica el Número de libro estándar internacional (ISBN) 9781484219157.

Más información sobre las asignaciones HTTP-CRUD

Para obtener una descripción completa de las asignaciones entre los verbos HTTP y sus contrapartes CRUD, consulte la tabla "Métodos HTTP del servicio web RESTful" en la entrada Representational State Transfer de Wikipedia.

REST también se basa en los códigos de respuesta estándar de HTTP, como 404 (recurso solicitado no encontrado) y 200 (operación de recurso exitosa), junto con tipos MIME (cuando se recuperan representaciones de recursos).

RESTful frente a grandes servicios web

Si se pregunta si debe desarrollar un servicio web utilizando SOAP o REST, consulte Servicios web RESTful frente a servicios web "grandes": tomar la decisión arquitectónica correcta.

Soporte de servicios web en Java SE

Antes de Java SE 6, los servicios web basados ​​en Java se desarrollaban exclusivamente con el SDK de Java Enterprise Edition (EE). Aunque se prefiere Java EE para desarrollar servicios web desde una perspectiva de producción, porque los servidores basados ​​en Java EE proporcionan un grado muy alto de escalabilidad, una infraestructura de seguridad, facilidades de monitoreo, etc., el despliegue repetido de un servicio web en un Java EE contenedor a menudo ha llevado mucho tiempo, lo que ha ralentizado el desarrollo. Java SE 6 simplificó y aceleró el desarrollo de servicios web al agregar API, anotaciones, herramientas y un servidor HTTP ligero (para implementar servicios web en un servidor web simple y probarlos en este entorno) en su núcleo.

API

Java SE proporciona varias API que admiten servicios web. Junto con varias API de JAXP (SAX, DOM, StAX, etc.) que analizo en Java XML y JSON , Java SE proporciona las API de JAX-WS, JAXB y SAAJ: