Arquitectura multinivel para la construcción de servicios web RESTful

Los servicios web RESTful han surgido como una alternativa prometedora distinta a los servicios basados en SOAP por su simplicidad y naturaleza liviana, además de la capacidad de transmitir datos directamente sobre HTTP. Este artículo brinda una visión general del concepto REST y de los servicios web RESTful y compara a estos últimos con los servicios web basados en SOAP / de estilo RPC. También se analizan los frameworks Java™ para la construcción de servicios web RESTful y una arquitectura multinivel compartida para la construcción tanto de servicios web RESTful como de aplicaciones Web dinámicas.

Bruce Sun, Java Architect, National Center for Atmospheric Research

Photo of Bruce SunBruce Sun is a Sun Microsystems certified Java architect. He has been developing Java-based Web applications since 1998. He is currently working as a Senior Software Engineer at the National Center for Atmospheric Research (NCAR).



03-08-2011

Introducción

Es imperativo que las aplicaciones Web modernas proporcionen interfaces de navegador de alta calidad que usen Asynchronous JavaScript and XML (Ajax) o el kit de herramientas Web de Google (GWT), así como también servicios web RESTful para las aplicaciones cliente externas. Este artículo propone usar un Resource Request Handler (RRH) (controlador de solicitudes de recursos) para Ajax/GWT y para las llamadas de aplicaciones clientes externas, y un Browser Request Handler (BRH) (controlador de solicitudes del navegador) para procesar las solicitudes del navegador y generar datos de salida a mostrar en el navegador. Ambos controladores comparten una misma capa Business Logic (lógica de negocios), que, a su vez, interactúa con la capa Data Access (acceso a datos). La extracción del RRH y el BRH simplifica el diseño y facilita la reutilización de códigos, lo que conlleva a una arquitectura flexible y extensible.


¿Qué es REST?

La Transferencia de Estado Representacional (REpresentation State Transfer - REST) describe un estilo arquitectónico de sistemas en red como, por ejemplo, aplicaciones Web. El término fue utilizado por primera vez en el año 2000 durante una disertación doctoral por Roy Fielding, uno de los principales autores de la especificación HTTP. REST está comprendida por una serie de limitaciones y principios arquitectónicos. Si una aplicación o diseño cumple con esas limitaciones y principios, se considera RESTful.

Uno de los principios REST de mayor importancia para las aplicaciones Web es que la interacción entre el cliente y el servidor no tiene estado entre solicitudes. Cada solicitud del cliente al servidor debe contener toda la información necesaria para comprender la solicitud. El cliente no se dará cuenta si el servidor debe reiniciarse en ningún momento entre las solicitudes. Asimismo, las solicitudes sin estado pueden ser respondidas por cualquier servidor disponible, lo cual resulta apropiado en un entorno como la computación en nube. El cliente puede almacenar los datos en caché para mejorar su rendimiento.

En el extremo del servidor, el estado y la funcionalidad de la aplicación se dividen en recursos. Un recurso es un elemento de interés, una identidad conceptual que se expone a los clientes. Algunos ejemplos de recursos son: objetos de aplicaciones, registros de bases de datos, algoritmos, etc. Cada recurso es de acceso único a través de una URI (Universal Resource Identifier – identificador de recursos universal). Todos los recursos comparten una interfaz uniforme para la transferencia de estados entre cliente y servidor. Se usan métodos estándar HTTP como GET, PUT, POST y DELETE. El motor del estado de la aplicación es Hypermedia y las representaciones de recursos se interconectan mediante hipervínculos.

Otro principio REST importante es el de sistema por capas, el cual implica que un componente no puede ver más allá de la capa inmediata con la cual interactúa. Al restringir el conocimiento del sistema a una sola capa, se impone un límite en la complejidad del sistema en general, promoviendo así la independencia de los sustratos.

Las limitaciones arquitectónicas REST, aplicadas como un todo, generan una aplicación que logra escalar sin problemas a grandes cantidades de clientes. También se reduce la latencia en la interacción entre clientes y servidores. La interfaz uniforme simplifica la arquitectura general del sistema y mejora la visibilidad de las interacciones entre subsistemas. REST simplifica la implementación tanto para el cliente como para el servidor.


Comparación entre los servicios web RESTful y los servicios web de estilo RPC

Hasta hace poco tiempo, los servicios web basados en SOAP construidos con arquitectura de estilo RPC representaban el enfoque más popular para la implementación de una Arquitectura orientada a servicios (SOA). En éste, los clientes de un servicio web de estilo RPC envían un sobre con datos como información de métodos y argumentos al servidor, sobre HTTP. El servidor abre el sobre y ejecuta los métodos nombrados con los argumentos transmitidos. Los resultados del método se reúnen en un sobre y se devuelven al cliente como respuesta. El cliente recibe la respuesta y abre el sobre. Todo objeto tiene sus propios métodos, que le son únicos, y el servicio web de estilo RPC expone solamente una URI, la cual representa el único punto final. Se ignoran la mayor parte de las características HTTP y sólo se soporta el método POST.

El enfoque RESTful de los servicios web surge como una alternativa popular por su naturaleza liviana y a la capacidad de transmitir datos directamente sobre HTTP. Los clientes se implementan usando una gran variedad de lenguajes como programas Java, Perl, Ruby, Python, PHP y Javascript (inclusive Ajax). Generalmente se acede a los servicios web RESTful a través de un cliente automatizado o una aplicación que actúa en representación del usuario. Sin embargo, la simplicidad de estos servicios posibilita la interacción humana directa pudiéndose construir una URL GET con el navegador Web y leer el contenido devuelto.

En un servicio web de estilo REST, cada recurso tiene una dirección. Los recursos en sí son los objetivos de las llamadas de los métodos y todos los recursos comparten una misma lista de métodos. Los métodos son estándar; se soportan los métodos HTTP GET, POST, PUT, DELETE, y, pueden soportarse los métodos HEADER y OPTIONS.

En una arquitectura de estilo RPC, el foco se establece en los métodos, mientras que, en la arquitectura de estilo REST, el foco está dado en los recursos,—información que se recupera como representación y se manipula usando métodos estándar. Las representaciones de los recursos se interconectan mediante hipervínculos que se ubican dentro de la representación.

Leonard Richardson y Sam Ruby introducen el término "arquitectura híbrida REST-RPC" en su libro RESTful Web Services. En lugar de usar sobres para contener al método, los argumentos y los datos; los servicios híbridos REST-RPC transmiten los datos directamente sobre HTTP, asemejándose en este punto al estilo REST. Sin embargo, los servicios híbridos no usan métodos HTTP estándar para realizar operaciones en los recursos, sino que s almacenan la información de métodos en la porción URI de la solicitud HTTP. Muchos servicios web conocidos como la API de Yahoo y la API de del.icio.us usan esta arquitectura híbrida.


Frameworks Java para servicios web RESTful

Han surgido dos frameworks Java que ayudan a construir servicios web RESTful. Restlet (ver la sección Recursos), por Jerome Louvel y Dave Pawson es liviano e implementa conceptos como recursos, representación, conector y tipo de medio para todo tipo de sistemas RESTful, inclusive servicios web. En el framework Restlet, tanto el cliente como el servidor son componentes. Los componentes se comunican entre sí a través de conectores. Las principales clases de este marco son la clase abstracta Uniform y su subclase concreta, Restlet, cuyas subclases son clases especializadas, entre ellas: Application, Filter, Finder, Router, and Route. Estas subclases trabajan juntas en la gestión de la autenticación, el filtrado, la seguridad, la transformación de datos y el enrutamiento de las solicitudes entrantes a sus respectivos recursos. La clase Resource genera la presentación para el cliente.

La JSR-311 (ver la sección de Recursos) es una especificación de Sun Microsystems que define un conjunto de APIs Java para el desarrollo de servicios web RESTful. La implementación de referencia de JSR-311 se denomina Jersey (ver la sección de Recursos).

La JSR-311 proporciona una serie de anotaciones con clases asociadas e interfaces que pueden usarse para exponer objetos Java como recursos Web. La especificación supone que el protocolo de redes subyacente es HTTP. En esta se brindan mapeos claros entre la URI y sus correspondientes clases de recursos, así como también mapeos de métodos HTTP con los métodos de los objetos Java, mediante el uso de anotaciones. La API soporta una amplia gama de tipos de contenidos de entidad HTTP como HTML, XML, JSON, GIF y JPG, entre otros. También se proporciona la capacidad de complementación que permite la inclusión de otros tipos de contenidos en aplicaciones de manera estándar.


Arquitectura multinivel para la construcción de servicios web RESTful

Los servicios web RESTful y las aplicaciones Web dinámicas se asemejan en muchos aspectos. Suelen proporcionar datos y funciones iguales o muy similares, aunque lo hacen para distintos tipos de clientes. Por ejemplo, un sitio Web de un catálogo de comercio electrónico en línea proporciona una interfaz de navegador para que los usuarios puedan buscar y ver productos para luego pedirlos. Sería útil que este sitio también brindase servicios web para que las empresas, los minoristas y hasta los particulares pudieran realizar pedidos de manera automática. Los servicios web pueden beneficiarse con la separación de responsabilidades inherente a la arquitectura multinivel de la misma manera que lo hacen las aplicaciones Web más dinámicas. Los datos y la lógica de negocios pueden compartirse entre clientes tanto automatizados como GUI. Las únicas diferencias estarán dadas en la naturaleza del cliente y la capa Presentation (presentación) del nivel medio. Además, la separación entre la lógica de negocios y el acceso a los datos posibilita la independencia de las bases de datos y proporciona la capacidad de complementación que permite el uso de diversos tipos de almacenamiento de datos

La Figura 1 muestra los denominados clientes automatizados: Java; scripts de distintos lenguajes como Python, Perl, Ruby, PHP; y herramientas de la línea de comandos como Curl. También pertenecen a este grupo los Ajax, Flash, JavaFX, GWT, blogs y wikis que se ejecutan dentro del navegador y actúan como consumidores del servicio web RESTful, debido a que lo hacen de manera automatizada y en representación del usuario. Los clientes de servicios web envían solicitudes HTTP al Resource Request Handler en el nivel Web. Las solicitudes sin estado de los clientes contienen la información de métodos en el encabezamiento, a saber: POST, GET, PUT y DELETE y se mapearán hacia las operaciones correspondientes de los recursos que se encuentran en el Resource Request Handler. Cada solicitud contiene toda la información necesaria, incluso las credenciales que permiten al Resource Request Handler procesar la solicitud.

Figura 1. Diagrama de un entorno de aplicación Web de varios niveles
Diagrama de un entorno de aplicación Web de varios niveles

Cuando recibe una solicitud de un cliente de servicio web, el Resource Request Handler solicita el servicio a la capa Business Logic (lógica de negocios). El Resource Request Handler identifica todas las entidades conceptuales que el sistema expone como recursos y asigna una única URI a cada una de ellas. Sin embargo, las identidades conceptuales no existen en esta capa, sino que se encuentran en la capa Business Logic. El Resource Request Handler puede implementarse usando Jersey u otro framework como Restlet. El Resource Request Handler deberá ser liviano y delegar el trabajo pesado principalmente al nivel de negocios.

Ajax y los servicios web RESTful se ajustan naturalmente el uno al otro. Ambos aprovechan las tecnologías Web de fácil disponibilidad y los estándares como HTML, JavaScript, objetos de navegador, XML/JSON y HTTP. Por consiguiente, no hay absolutamente ninguna necesidad de comprar, instalar o configurar ningún otro componente de importancia para lograr una interacción efectiva entre los front-end de Ajax y los servicios web RESTful. Los servicios web RESTful proporcionan a Ajax una API muy sencilla para gestionar las interacciones con los recursos en el servidor.

El cliente del navegador Web de la Figura 1 actúa como un front-end GUI al brindar funciones de visualización usando HTML generado por el Browser Request Handler en la capa Presentation. El Browser Requester Handler puede implementarse usando modelos MVC (algunos ejemplos Java son: JSF, Struts o Spring). Éste acepta la solicitud del navegador, solicita el servicio a la capa Business Logic, genera la presentación y le responde al navegador. La presentación debe mostrarse al usuario mediante el navegador y no contendrá únicamente el contenido, sino también los atributos de visualización como HTML y CSS.

Las reglas de negocios se centralizan en la capa Business Logic, la cual cumple la función de intermediario en el intercambio de datos entre la capa Presentation y la capa Data Access. Los datos se proporcionan a la capa Presentation como objetos de dominio u objetos de valor. Desacoplar el Browser Request Handler y el Resource Request Handler de la capa Business Logic ayuda a facilitar la reutilización de códigos y conlleva a una arquitectura flexible y extensible. Además, a medida que van surgiendo nuevos frameworks REST y MVC, se simplifica cada vez más la implementación sin que sea necesario reescribir la capa Business Logic.

La capa Data Access brinda el nivel de almacenamiento de datos a la interfaz y puede implementarse usando el patrón de diseño DAO o bien soluciones de mapeo relacional de objetos como Hibernate, OJB o iBATIS. Otra alternativa es implementar los componentes de la capa Business y la capa Data Access como componentes EJB con soporte de un contenedor EJB que facilite el ciclo de vida de los componentes y gestione la persistencia, las transacciones y las asignaciones de recursos. Sin embargo, esta opción requiere de un servidor de aplicaciones conforme a Java EE como, por ejemplo, JBoss y no funcionaría con Tomcat. La gran ventaja de esta capa está dada en la separación del código de acceso a datos de la lógica de negocios la cual permite el uso de tecnologías de almacenamiento de datos dispares. La capa Data Access también puede actuar como un punto de integración para la vinculación con otros sistemas, incluso en casos de clientes de otros servicios web.

El nivel de almacenamiento de datos abarca sistemas de bases de datos, servidores LDAP, sistemas de archivos y sistemas de información empresarial como sistemas legado, sistemas de procesamiento de transacciones y sistemas de planificación de recursos empresariales. Al usar esta arquitectura, usted comenzará a darse cuenta de la potencia del servicio web RESTful, que cuenta con la flexibilidad para ser una API unificada de todo tipo de almacenamiento de datos empresariales y así exponer datos separados en aplicaciones Web centradas en el usuario y scripts de informe por lotes automatizados.


Conclusión

REST describe un estilo arquitectónico de sistemas en red como, por ejemplo, aplicaciones Web. Las limitaciones REST, aplicadas como un todo, generan una arquitectura simple, escalable, eficiente, segura, confiable y extensible. Los servicios web RESTful han surgido como una alternativa prometedora distinta a los servicios basados en SOAP por su simplicidad y naturaleza liviana, además de la capacidad de transmitir datos directamente sobre HTTP. La arquitectura multinivel tanto para servicios web como para aplicaciones Web dinámicas conlleva a la reutilización, simpleza, extensibilidad y a una clara separación de las responsabilidades de los componentes. Ajax y los servicios web RESTful se ajustan naturalmente el uno al otro. Usando Ajax y los servicios web RESTful juntos, los desarrolladores logran crear interfaces de alta calidad.

Este artículo antecede a un tutorial que explica cómo construir servicios web RESTful y aplicaciones Web dinámicas con la arquitectura multinivel aquí descripta. El tutorial brinda un ejemplo de la forma en que los servicios web REST, Ajax, y Spring Web Flow trabajan juntos para producir una interfaz Web de alta calidad, similar a una interfaz de escritorio. El tutorial usa Jersey, Spring, MySQL y Tomcat, y está configurado e implementado en Eclipse.

Este artículo fue posible gracias al apoyo de la Fundación Nacional de la Ciencia en parte de la investigación, conforme al acuerdo de cooperación firmado con la University Corporation for Atmospheric Research. El Centro Nacional de Investigación Atmosférica es patrocinado por la Fundación Nacional de la Ciencia. Asimismo, quisiera agradecer a Markus Stobbs del NCAR, quien colaboró con sugerencias y la edición del artículo.

Recursos

Aprender

Obtener los productos y tecnologías

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=SOA y servicios web
ArticleID=425306
ArticleTitle=Arquitectura multinivel para la construcción de servicios web RESTful
publish-date=08032011