NOTA: Ciudad Universitaria, Lunes 5 de Noviembre de 2012

Integrantes: Carnet: Luis Alejandro Gonzales GG09073 José Antonio Sanchez Delgado SD09008 Carlos Bryan Alexander Rodríguez RC06072 Francisco José Orellana Rosales OR07002 Francisco Javier Tobías Rivas TR08004 Geovanny de Jesús Quintanilla Martinez QM07001

WEB SERVICES: REST

Facultad de ingeniería y Arquitectura Escuela de ingeniería de Sistemas Informáticos Ingeniería del Software IGF-115

Ciclo II - 2012

Universidad de El Salvador

INSTRUCTOR: Ing. Bladimir Díaz GRUPO # 7

2

CONTENIDO INTRODUCCIÓN ............................................................................................................................................ 3

OBJETIVOS:................................................................................................................................................... 4

Objetivo General: ..................................................................................................................................... 4

Objetivos Específicos: ............................................................................................................................... 4

DEFINICIÓN DE CONCEPTOS ......................................................................................................................... 5

RAZONES PARA CREAR SERVICIOS WEB......................................................................................................... 6

¿QUÉ ES REST REALMENTE? ......................................................................................................................... 6

¿CUÁL ES LA MOTIVACIÓN DE REST? ............................................................................................................ 7

PRINCIPIOS ................................................................................................................................................... 7

REST utiliza los métodos HTTP de manera explícita ................................................................................... 7

REST no mantiene estado ....................................................................................................................... 10

Servicios con estado vs. Sin estado ......................................................................................................... 11

REST expone URIs con forma de directorios ............................................................................................ 13

REST transfiere XML, JSON, o ambos....................................................................................................... 15

DISEÑO....................................................................................................................................................... 16

LOS SERVICIOS WEB Y REST......................................................................................................................... 23

EL DEBATE ENTRE LOS SERVICIOS WEB BASADOS EN REST Y SOAP .............................................................. 23

CARACTERÍSTICAS DE REST Y SOAP ............................................................................................................. 24

DIFERENCIAS ENTRE REST Y SOAP ............................................................................................................... 25

PROTOCOLOS DE INTERCAMBIO DE INFORMACIÓN: JSON VS XML .............................................................. 26

JSON ...................................................................................................................................................... 27

XML ....................................................................................................................................................... 27

EJEMPLO DE JSON Y XML ........................................................................................................................ 27

VENTAJAS Y DESVENTAJAS DE SU USO .................................................................................................... 28

REST COMO SOLUCIÓN DEFINITIVA A TODOS LOS PROBLEMAS ................................................................... 29

GUÍA PARA CREAR SERVICIOS WEB REST EN NETBEANS. ............................................................................. 31

PRUEBAS A SERVICIOS WEB ........................................................................................................................ 40

CONCLUSIÓN: ............................................................................................................................................. 45

GLOSARIO .................................................................................................................................................. 46

BIBLIOGRAFIA: ............................................................................................................................................ 48

3

INTRODUCCIÓN

En la actualidad, las exigencias y estándares de trabajo en empresas y en el entorno empresarial requieren que sus servicios se encuentren disponibles todos los días a toda hora, de forma que esto crea una necesidad de implementar tecnologías que permitan un nivel de confiabilidad y escalabilidad para que sus servicios se encuentren siempre disponibles en la web, debido a esta situación, los ingenieros y arquitectos de software vieron la necesidad crear e implementar en sus aplicaciones, tecnologías que permitieran que su sistema estuviese alojado en un equipo remoto en una ubicación específica, y otro grupo de equipos o “hosts” pudieran enviar peticiones de dicho servicio a este equipo remoto o “servidor” y este las respondiese exitosamente, de forma que el tamaño de la red o cantidad de hosts haciendo peticiones no sea un problema para estos., permitiendo un alto nivel de escalabilidad.

Habiendo dicho esto, se puede adentrar más en el concepto y aplicación de estas tecnologías, como se les denominaría “Servicios Web”, estos han atravesado distintas etapas de maduración, desde los RPC (Llamadas a procedimientos remotos), SOA (Service - Oriented Architecture) y REST (Representation State Transfer) que serán el pilar de desarrollo de la presente investigación. Cabe mencionar que los servicios web como tales son sistemas de software, mientras que REST son arquitecturas o formas de diseño.

4

OBJETIVOS:

Objetivo General:

Explicar, interpretar y dar una visión amplia sobre las tecnologías de Servicios

Web, su evolución y arquitecturas de diseño que definen el estilo de uso de los

servicios web en la actualidad.

Objetivos Específicos:

Explicar el concepto y utilidad de servicios web.

Detallar la evolución de los servicios web y sus estilos de arquitectura de software

Definir el concepto de REST.

Listar y definir los principios básicos de REST

Ejemplificar la arquitectura de diseño REST

Definir el concepto de SOAP

Definir y explicar las categorías de REST y SOAP

Identificar las diferencias entre REST y SOAP

5

DEFINICIÓN DE CONCEPTOS ¿Qué es un Servicio Web?

El consorcio W3C define los Servicios Web como sistemas software diseñados para soportar una interacción interoperable maquina a maquina sobre una red. Los Servicios Web suelen ser APIs Web que pueden ser accedidas dentro de una red (principalmente Internet) y son ejecutados en el sistema que los aloja. La definición de Servicios Web propuesta alberga muchos tipos diferentes de sistemas, pero el caso común de uso de refiere a clientes y servidores que se comunican mediante mensajes XML que siguen el estándar SOAP. En los últimos años se ha popularizado un estilo de arquitectura Software conocido como REST (Representational State Transfer). Este nuevo estilo ha supuesto una nueva opción de estilo de uso de los Servicios Web. A continuación se listan los tres estilos de usos más comunes:

Remote Procedure Calls (RPC, Llamadas a Procedimientos Remotos): Los Servicios Web basados en RPC presentan una interfaz de llamada a procedimientos y funciones distribuidas, lo cual es familiar a muchos desarrolladores. Típicamente, la unidad básica de este tipo de servicios es la operación WSDL (WSDL es un descriptor del Servicio Web, es decir, el homologo del IDL para COM).

Las primeras herramientas para Servicios Web estaban centradas en esta visión. Algunos lo llaman la primera generación de Servicios Web. Esta es la razón por la que este estilo está muy extendido. Sin embargo, ha sido algunas veces criticado por no ser débilmente acoplado, ya que suele ser implementado por medio del mapeo de servicios directamente a funciones específicas del lenguaje o llamadas a métodos. Muchos especialistas creen que este estilo debe desaparecer.

Arquitectura Orientada a Servicios (Service-oriented Architecture, SOA). Los Servicios Web pueden también ser implementados siguiendo los conceptos de la arquitectura SOA, donde la unidad básica de comunicación es el mensaje, más que la operación. Esto es típicamente referenciado como servicios orientados a mensajes.

Los Servicios Web basados en SOA son soportados por la mayor parte de desarrolladores de software y analistas. Al contrario que los Servicios Web basados en RPC, este estilo es débilmente acoplado, lo cual es preferible ya que se centra en el “contrato” proporcionado por el documento WSDL, más que en los detalles de implementación subyacentes.

REST (REpresentation State Transfer). Los Servicios Web basados en REST intentan emular al protocolo HTTP o protocolos similares mediante la restricción de establecer la interfaz a un conjunto conocido de operaciones estándar (por ejemplo GET, PUT,…). Por tanto, este estilo se centra más en interactuar con recursos con estado, que con mensajes y operaciones.

6

RAZONES PARA CREAR SERVICIOS WEB

La principal razón para usar servicios Web es que se pueden utilizar con HTTP sobre TCP (Transmission Control Protocol) en el puerto80. Dado que las organizaciones protegen sus redes mediante firewalls -que filtran y bloquean gran parte del tráfico de Internet-, cierran casi todos los puertos TCP salvo el 80, que es, precisamente, el que usan los navegadores. Los servicios Web utilizan este puerto, por la simple razón de que no resultan bloqueados. Es importante señalar que los servicios web se pueden utilizar sobre cualquier protocolo, sin embargo, TCP es el más común. Otra razón es que, antes de que existiera SOAP, no había buenas interfaces para acceder a las funcionalidades de otros ordenadores en red. Las que había eran ad hoc y poco conocidas, tales como EDI (Electronic Data Interchange), RPC (Remote Procedure Call), u otras APIs.

Una tercera razón por la que los servicios Web son muy prácticos es que pueden aportar gran independencia entre la aplicación que usa el servicio Web y el propio servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a construir grandes aplicaciones a partir de componentes distribuidos más pequeños es cada día más utilizada. Se espera que para los próximos años mejoren la calidad y cantidad de servicios ofrecidos basados en los nuevos estándares.

¿QUÉ ES REST REALMENTE?

REST (Representational State Transfer) es un estilo de arquitectura de software para sistemas hipermedias distribuidos tales como la Web. El término fue introducido en la tesis doctoral de Roy Fielding en 2000, quien es uno de los principales autores de la especificación de HTTP. En realidad, REST se refiere estrictamente a una colección de principios para el diseño de arquitecturas en red. Estos principios resumen como los recursos son definidos y diseccionados. El término frecuentemente es utilizado en el sentido de describir a cualquier interfaz que transmite datos específicos de un domino sobre HTTP sin una capa adicional, como hace SOAP. Estos dos significados pueden chocar o incluso solaparse. Es posible diseñar un sistema software de gran tamaño de acuerdo con la arquitectura propuesta por Fielding sin utilizar HTTP o sin interactuar con la Web. Así como también es posible diseñar una simple interfaz XML+HTTP que no sigue los principios REST, y en cambio seguir un modelo RPC. Cabe destacar que REST no es un estándar, ya que es tan solo un estilo de arquitectura. Aunque REST no es un estándar, está basado en estándares:

HTTP URL Representación de los recursos: XML/HTML/GIF/JPEG/… Tipos MIME: text/xml, text/html, …

7

¿CUÁL ES LA MOTIVACIÓN DE REST? La motivación de REST es la de capturar las características de la Web que la han hecho tan exitosa. Si pensamos un poco en este éxito, nos daremos cuenta que la Web ha sido la única aplicación distribuida que ha conseguido ser escalable al tamaño de Internet. El éxito lo debe al uso de formatos de mensaje extensibles y estándares, pero además cabe destacar que posee un esquema de direccionamiento global (estándar y extensible a su vez). En particular, el concepto central de la Web es un espacio de URIs unificado. Las URIs permiten la densa red de enlaces que permiten a la Web que sea tan utilizada. Por tanto, ellos consiguen tejer una mega-aplicación. Las URIs identifican recursos, los cuales son objetos conceptuales. La representación de tales objetos se distribuye por medio de mensajes a través de la Web. Este sistema es extremadamente desacoplado. Estas características son las que han motivado para ser utilizadas como guía para la evolución de la Web.

PRINCIPIOS Los servicios Web no son realmente nada nuevo, y actualmente, si ha utilizado RSS o Atom para leer noticias desde un sitio web, tiene una idea de como funciona un servicio Web. Los servicios Web intercambian datos desde un servidor al cliente, utilizando el formato XML para enviar las peticiones, de modo que tanto el servidor como el cliente puede entenderse. Una mejor forma de entender un servicio Web es compararlo con un formulario HTML (en PHP o ASP) para postear y enviar datos. Ambos, el servicio Web y el formulario, reciben y envían peticiones. La única diferencia es que un servicio Web utiliza XML.

REST plantea cuatro principios con respecto a una implementación concreta de un servicio web REST

● Utiliza los métodos HTTP de manera explícita ● No mantiene estado ● Expone URIs con forma de directorios ● Transfiere XML, JavaScript Object Notation (JSON), o ambos

A continuación vamos a ver en detalle estos cuatro principios, y explicaremos porqué son importantes a la hora de diseñar un servicio web REST.

REST utiliza los métodos HTTP de manera explícita Una de las caraterísticas claves de los servicios web REST es el uso explícito de los métodos HTTP, siguiendo el protocolo definido por RFC 2616. Por ejemplo, HTTP GET se define como un método productor de datos, cuyo uso está pensado para que las aplicaciones cliente obtengan recursos,

8

busquen datos de un servidor web, o ejecuten una consulta esperando que el servidor web la realice y devuelva un conjunto de recursos.

REST hace que los desarrolladores usen los métodos HTTP explícitamente de manera que resulte consistente con la definición del protocolo. Este principio de diseño básico establece una asociación uno-a-uno entre las operaciones de crear, leer, actualizar y borrar y los métodos HTTP. De acuerdo a esta asociación:

● Se usa POST para crear un recurso en el servidor ● Se usa GET para obtener un recurso ● Se usa PUT para cambiar el estado de un recurso o actualizarlo ● Se usa DELETE para eliminar un recurso

Una falla de diseño poco afortunada que tienen muchas APIs web es el uso de métodos HTTP para otros propósitos. Por ejemplo, la petición del URI en un pedido HTTP GET, en general identifica a un recurso específico. O el string de consulta en el URI incluye un conjunto de parámetros que definen el criterio de búsqueda que usará el servidor para encontrar un conjunto de recursos. Al menos, así como el RFC HTTP/1.1 describe al GET.

Pero hay muchos casos de APIs web poco elegantes que usan el método HTTP GET para ejecutar algo transaccional en el servidor; por ejemplo, agregar registros a una base de datos. En estos casos, no se utiliza adecuadamente el URI de la petición HTTP, o al menos no se usa "a la manera REST". Si el API web utiliza GET para invocar un procedimiento remoto, seguramente se verá algo como esto:

GET /agregarusuario?nombre=Zim HTTP/1.1

Este no es un diseño muy atractivo porque el método aquí arriba expone una operación que cambia estado sobre un método HTTP GET. Dicho de otra manera, la petición HTTP GET de aquí arriba tiene efectos secundarios. Si se procesa con éxito, el resultado de la petcición es agregar un usuario nuevo (en el ejemplo, Zim) a la base de datos. El problema es básicamente semántico. Los servidores web están diseñados para responder a las peticiones HTTP GET con la búsqueda de recursos que concuerden con la ruta (o el criterio de búsqueda) en el URI de la petición, y devolver estos resultados o una representación de los mismos en la respuesta, y no añadir un registro a la base de datos. Desde el punto de vista del protocolo, y desde el punto de vista de servidor web compatible con HTTP/1.1, este uso del GET es inconsistente.

Más allá de la semántica, el otro problema con el GET es que al ejecutar eliminaciones, modificaciones o creación de registros en la base de datos, o al cambiar el estado de los recursos de cualquier manera, provova que las herramientas de caché web y los motores de búsqueda (crawlers) puedan realizar cambios no intencionales en el servidor. Una forma simple de evitar este problema es mover los nombres y valores de los parámetros en la petición del URI a tags

9

XML. Los tags resultantes, una representación en XML de la entidad a crear, pueden ser enviados en el cuerpo de un HTTP POST cuyo URI de petición es el padre de la entidad.

Antes:

GET /agregarusuario?nombre=Zim HTTP/1.1

Después:

POST /usuarios HTTP/1.1

Host: miservidor

Content-type: application/xml

<usuario>

<nombre>Zim</nombre>

</usuario>

El método acá arriba es un ejemplo de una petición REST: hay un uso correcto de HTTP POST y la inclusión de los datos en el cuerpo de la petición. Al recibir esta petición, la misma puede ser procesada de manera de agregar el recurso contenido en el cuerpo como un subordinado del recurso identificado en el URI de la petición; en este caso el nuevo recurso debería agregarse como hijo de /usuarios. Esta relación de contención entre la nueva entidad y su padre, como se indica en la petición del POST, es análoga a la forma en la que está subordinado un archivo a su directorio. El cliente indica esta relación entre la entidad y su padre y define el nuevo URI de la entidad en la petición del POST.

Luego, una aplicación cliente p uede obtener una representación del recurso usando la nueva URI, sabiendo que al menos lógicamente el recurso se ubica bajo /usuarios

GET /usuarios/Zim HTTP/1.1

Host: miservidor

Accept: application/xml

Es explícito el uso del GET de esta manera, ya que el GET se usa sólamente para recuperar datos. GET es una operación que no debe tener efectos secundarios, una propiedad también conocida como idempotencia.

Se debe hacer un refactor similar de un método web que realice actualizaciones a través del método HTTP GET. El siguiente método GET intenta cambiar la propipedad "nombre" de un recurso. Si bien se puede usar el string de consulta para esta operación, evidentemente no es el uso apropiado y tiende a ser problemático en operaciones más complejas. Ya que nuestro objetivo

10

es hacer uso explícito de los métodos HTTP, un enfoque REST sería enviar un HTTP PUT para actualizar el recurso, en vez de usar HTTP GET.

Antes:

GET /actualizarusuario?nombre=Zim&nuevoNombre=Dib HTTP/1.1

Después:

PUT /usuarios/Zim HTTP/1.1

Host: miservidor

Content'Type: application/xml

<usuario>

<nombre>Dib</nombre>

</usuario>

Al usar el método PUT para reemplazar al recurso original se logra una interfaz más limpia que es consistente con los principios de REST y con la definición de los métodos HTTP. La petición PUT que se muestra arriba es explícita en el sentido que apunta al recurso a ser actualiza identificándolo en el URI de la petición, y también transfiere una nueva representación del recurso del cliente hacia el servidor en el cuerpo de la petición PUT, en vez de transferir los atributos del recurso como un conjunto suelo de parámetros (nombre = valor) en el mismo URI de la petición.

El PUT arriba mostrado también tiene el efecto de renombrar al recurso Zim a Dib, y al hacerlo cambia el URI a/usuarios/Dib. En un servicio web REST, las peticiones siguientes al recurso que apunten a la URI anterior van a generar un error estándard "404 Not Found".

Como un principio de diseño general, ayuda seguir las reglas de REST que aconsejan usar sustantivos en vez de verbos en las URIs. En los servicios web REST, los verbos están claramente definidos por el mismo protocolo: POST, GET, PUT y DELETE. Idealmente, para mantener una interfaz general y para que los clientes puedan ser explícitos en las operaciones que invocan, los servicios web no deberían definir más verbos o procedimientos remotos, como ser /agregarusuario y/actualizarusuario. Este principio de diseño también aplica para el cuerpo de la petición HTTP, el cual debe usarse para transferir el estado de un recurso, y no para llevar el nombre de un método remoto a ser invocado.

REST no mantiene estado

Los servicios web REST necesitan escalar para poder satisfacer una demanda en constante crecimiento. Se usan clusters de servidores con balanceadores de carga y alta disponibilidad, proxies, y gateways de manera de conformar una topología serviciable, que permita transferir

11

peticiones de un equipo a otro para disminuir el tiempo total de respuesta de una invocación al servicio web. El uso de servidores intermedios para mejorar la escalabilidad hace necesario que los clientes de servicios web REST envien peticiones completas e independientes; es decir, se deben enviar peticiones que inlcuyan todos los datos necesarios para cumplir el pedido, de manera que los componentes en los servidores intermedios puedan redireccionar y gestionar la carga sin mantener el estado localmente entre las peticiones.

Una petición completa e independiente hace que el servidor no tenga que recuperar ninguna información de contexto o estado al procesar la petición. Una aplicación o cliente de servicio web REST debe incluir dentro del encabezado y del cuerpo HTTP de la petición todos los parámetros, contexto y datos que necesita el servidor para generar la respuesta. De esta manera, el no mantener estado mejora el rendimiento de los servicios web y simplifica el diseño e implementación de los componentes del servidor, ya que la ausencia de estado en el servidor elimina la necesidad de sincronizar los datos de la sesión con una aplicación externa.

Servicios con estado vs. Sin estado La siguiente ilustración nos muestra un servicio con estado, del cual una aplicación realiza peticiones para la página siguiente en un conjunto de resultados múlti-página, asumiendo que el servicio mantiene información sobre la última página que pidió el cliente. En un diseño con estado, el servicio incrementa y almacena en algún lugar una variablepaginaAnterior para poder responder a las peticiones siguientes.

Los servicios con estado tienden a volverse complicados. En la plataforma Java Enterprise Edition (Java EE), un entorno de servicios con estado necesita bastante análisis y diseño desde el inicio para poder almacenar los datos eficientemente y poder sincronizar la sesión del cliente dentro de un cluster de servidores. En este tipo de ambientes, ocurre un problema que le resulta familiar a los desarrolladores de servlets/JSP y EJB, quienes a menudo tienen que revolver buscando la causa de una java.io.NotSerializableException cuando ocurre la replicación de una sesión. Puede ocurrir tanto sea en el contenedor de Servlets al intentar replicar la HttpSession o por el contenedor de

12

EJB al replicar un EJB con estado; en todos los casos, es un problema que puede costar mucho esfuerzo resolver, buscando el objeto que no implementa Serializabledentro de un grafo complejo de objetos que constituyen el estado del servidor. Además, la sincronización de sesiones es costosa en procesamiento, lo que impacta negativamente en el rendimiento general del servidor.

Por otro lado, los servicios sin estado son mucho más simples de diseñar, escribir y distribuir a través de múltiples servidores. Un servicio sin estado no sólo funciona mejor, sino que además mueve la responsabilidad de mantener el estado al cliente de la aplicación. En un servicio web REST, el servidor es responsable de generar las respuestas y proveer una interfaz que le permita al cliente mantener el estado de la aplicación por su cuenta. Por ejemplo, en el mismo ejemplo de una petición de datos en múltiples páginas, el cliente debería incluir el número de página a recuperar en vez de pedir "la siguiente", tal como se muestra en la siguiente figura:

Un servicio web sin estado genera una respuesta que se enlaza a la siguiente página del conjunto y le permite al cliente hacer todo lo que necesita para almacenar la página actual. Este aspecto del diseño de un servicio web REST puede descomponerse en dos conjuntos de responsabilidades, como una separación de alto nivel que clarifica cómo puede mantenerse un servicio sin estado.

Responsabilidad del servidor

Genera respuestas que incluyen enlaces a otros recursos para permitirle a la aplicación navegar entre los recursos relacionados. Este tipo de respuestas tiene enlaces embebidos. De la misma manera, si la petición es hacia un padre o un recurso contenedor, entonces una respuestsa REST típica debería también incluir enlaces hacia los hijos del padre o los recursos subordinados, de manera que se mantengan conectados.

Genera respuestas que indican si son susceptibles de caché o no, para mejorar el

rendimiento al reducir la cantidad de peticiones para recursos duplicados, y para lograr

13

eliminar algunas peticiones completamente. El servidor utiliza los atributos Cache-Control y Last-Modified de la cabecera en la respuesta HTTP para indicarlo.

Responsabilidades del cliente de la aplicación

Utiliza el atributo Cache-Control del encabezado de la respuesta para determinar si debe cachear el recurso (es decir, hacer una copia local del mismo) o no. El cliente también lee el atributo Last-Modified y envia la fecha en el atributo If-Modified-Since del encabezado para preguntarle al servidor si el recurso cambió desde entonces. Esto se conoce comoGET Condicional, y ambos encabezados van de la mano con la respuesta del servidor 304 (No Modificado) y se omite al recurso que se había solicitado si no hubo cambios desde esa fecha. Una respuesta HTTP 304 significa que el cliente puede seguir usando la copia local de manera segura, evitando así realizar las peticiones GET hasta tanto el recurso no cambie.

Envia peticiones completas que pueden ser serviciadas en forma independiente a otras peticiones. Esto implica que el cliente hace uso completo de los encabezados HTTP tal como está especificado por la interfaz del servicio web, y envia las representaciones del recurso en el cuerpo de la petición. El cliente envia peticiones que hacen muy pocas presunciones sobre las peticiones anteriores, la existencia de una sesión en el servidor, la capacidad del servidor para agregarle contexto a una petición, o sobre el estado de la aplicación que se mantiene entre las peticiones.

Esta colaboración entre el cliente y el servicio es esencial para crear un servicio web REST sin estado. Mejora el rendimiento, ya que ahorro ancho de banda y minimiza el estado de la aplicación en el servidor.

REST expone URIs con forma de directorios

Desde el punto de vista del cliente de la aplicación que accede a un recurso, la URI determina qué tan intuitivo va a ser el web service REST, y si el servicio va a ser utilizado tal como fue pensado al momento de diseñarlo. La tercera característica de los servicios web REST es justamente sobre las URIs.

Las URI de los servicios web REST deben ser intuitivas, hasta el punto de que sea facil adivinarlas. Pensemos en las URI como una interfaz auto-documentada que necesita de muy poca o ninguna explicación o referencia para que un desarrollador pueda comprender a lo que apunta, y a los recursos derivados relacionados.

Una forma de lograr este nivel de usabilidad es definir URIs con una estructura al estilo de los directorios. Este tipo de URIs es jerárquica, con una única ruta raiz, y va abriendo ramas a través de las subrutas para exponer las áreas principales del servicio. De acuerdo a esta definición, una

14

URI no es sólamente una cadena de caracteres delimitada por barras, sino más bien un árbol con subordinados y padres organizados como nodos. Por ejemplo, en un servicio de hilos de discusiones que tiene temas varios, se podría definir una estructura de URIs como esta:

http://www.miservicio.org/discusion/temas/{tema}

La raiz, /discusion, tiene un nodo /temas como hijo. Bajo este nodo hay un conjunto de nombres de temas (como ser tecnologia, actualidad, y más), cada uno de los cuales apunta a un hilo de discusión. Dentro de esta estructura, resulta facil recuperar hilos de discusión al tipear algo después de /temas/.

En algunos casos, la ruta a un recurso encacja muy bien dentro de la idea de "esctructura de directorios". Por ejemplo, tomemos algunos recursos organizados por fecha, que son muy prácticos de organizar usando una sintáxis jerárquica.

El siguiente ejemplo es intuitivo porque está basado en reglas:

http://www.miservicio.org/discusion/2008/12/23/{tema}

El primer fragmento de la ruta es un año de cuatro dígitos, el segundo fragmento es el mes de dos dígitos, y el tercer fragmento es el día de dos dígitos. Puede resultar un poco tonto explicarlo de esta manera, pero es justamente el nivel de simpleza que buscamos. Tanto humanos como máquinas pueden generar estas estructuras de URI porque están basadas en reglas. Como vemos, es facil llenar las partes de esta URI, ya que existe un patrón para crearlas:

http://www.miservicio.org/discusion/{año}/{mes}/{dia}/{tema

Podemos también enumerar algunas guías generales más al momento de crear URIs para un servicio web REST:

Ocultar la tecnología usada en el servidor que aparecería como extensión de archivos (.jsp, .php, .asp), de manera de poder portar la solución a otra tecnología sin cambiar las URI.

Mantener todo en minúsculas. Sustituir los espacios con guiones o guiones bajos (uno u otro). Evitar el uso de strings de consulta. En vez de usar un 404 Not Found si la petición es una URI parcial, devolver una página o un

recurso predeterminado como respuesta.

Las URI deberían ser estáticas de manera que cuando cambie el recurso o cambie la implementación del servicio, el enlace se mantenga igual. Esto permite que el cliente pueda generar "favoritos" o bookmarks. También es importante que la relación entre los recursos que está explícita en las URI se mantenga independiente de las relaciones que existen en el medio de almacenamiento del recurso.

15

REST transfiere XML, JSON, o ambos

La representación de un recurso en general refleja el estado actual del mismo y sus atributos al momento en que el cliente de la aplicación realiza la petición. La representación del recurso son simples "fotos" en el tiempo. Esto podría ser una representación de un registro de la base de datos que consiste en la asociación entre columnas y tags XML, donde los valores de los elementos en el XML contienen los valores de las filas. O, si el sistema tiene un modelo de datos, la representación de un recurso es una fotografía de los atributos de una de las cosas en el modelo de datos del sistema. Estas son las cosas que serviciamos con servicios web REST.

La última restricción al momento de diseñar un servicio web REST tiene que ver con el formato de los datos que la aplicación y el servicio intercambian en las peticiones/respuestas. Acá es donde realmente vale la pena mantener las cosas simples, legibles por humanos, y conectadas.

Los objetos del modelo de datos generalmente se relacionan de alguna manera, y las relaciones entre los objetos del modelo de datos (los recursos) deben reflejarse en la forma en la que se representan al momento de transferir los datos al cliente. En el servicio de hilos de discusión anterior, un ejemplo de una representación de un recurso conectado podría ser un tema de discusión raiz con todos sus atributos, y links embebidos a las respuetas al tema.

<discusion fecha="{fecha}" tema="{tema}">

<comentario>{comentario}</comentario>

<respuestas>

<respuestade=" gaz@mail.com" href="/discusion/temas/{tema}/gaz"/>

<respuestade=" gir@mail.com" href="/discusion/temas/{tema}/gir"/>

</respuestas>

</discusion>

Por último, es bueno construir los servicios de manera que usen el atributo HTTP Accept del encabezado, en donde el valor de este campo es un tipo MIME. De esta manera, los clientes pueden pedir por un contenido en particular que mejor pueden analizar. Algunos de los tipos MIME más usados para los servicios web REST son:

MIME-Type Content-Type JSON applica on/json XML applica on/xml

16

XHTML applica on/xhtml+xml

Esto permite que el servicio sea utilizado por distintos clientes escritos en diferentes lenguajes, corriendo en diversas plataformas y dispositivos. El uso de los tipos MIME y del encabezado HTTP Accepto es un mecanismo conocido comonegociación de contenido, el cual le permite a los clientes elegir qué formato de datos puedan leer, y minimiza el acoplamiento de datos entre el servicio y las aplicaciones que lo consumen.

DISEÑO

La World Wide Web no es sólo un espacio de información, también es un espacio de interacción. Utilizando la Web como plataforma, los usuarios, de forma remota, pueden solicitar un servicio que algún proveedor ofrezca en la red. Pero para que esta interacción funcione, deben existir unos mecanismos de comunicación estándares entre diferentes aplicaciones. Estos mecanismos deben poder interactuar entre sí para presentar la información de forma dinámica al usuario. Se precisa, pues, una arquitectura de referencia estándar que haga posible la interoperabilidad y extensibilidad entre las distintas aplicaciones y que permita su combinación para realizar operaciones complejas.

17

Fuente: W3C Oficina Española. "Los Servicios Web en funcionamiento". Guía Breve de Servicios Web. http://www.w3c.es/Divulgacion/Guiasbreves/ServiciosWeb

Con el fin de estandarizar los diferentes aspectos relacionados con los servicios web o Web Services (WS), el W3C recoge todo lo referente a estos en: Web Services Activity(http://www.w3.org/2002/ws/).

Así pues, Web Services (WS) ofrece una un significado estándar para interoperar entre diferentes aplicaciones de software corriendo en diferentes plataformas y/o marcos de trabajo. El W3C pretende diseñar la arquitectura, definirla y crear el núcleo de tecnologías que hagan posible los Servicios Web. Esta arquitectura se basa en los siguientes componentes:

● Diseñar un marco de mensajería: ○ Simple SOAP: Simple Object Access Protocol es un protocolo simple para

intercambiar información estructurada en un ambiente descentralizado y distribuido. "Messaging Framework" define, usando tecnologías XML, un marco extensible de mensajería que contiene una construcción del mensaje que se pueda intercambiar con una variedad de protocolos subyacentes. http://www.w3.org/TR/soap12-part1/

○ Web Services Addressing (WS-Addressing): Direccionamiento de Servicios Web. La dirección de los servicios Web proporciona mecanismos neutrales para transportar los servicios web y los mensajes. Define un sistema de características abstractas y una representación de XML para referirse a servicios de la Web y para facilitar la dirección final de los mensajes. Esta especificación permite a los sistemas de mensajería soportar la transmisión del mensaje a través de redes que incluyen el procesado de nodos tales como gestión final, cortafuegos y pasarelas mediante una forma de transporte neutro. http://www.w3.org/TR/ws-addr-core/

○ SOAP Message Transmission Optimization (MTOM) Descripción de la Optimización de la Transmisión del Mensaje. Describe una característica abstracta y una puesta en práctica concreta para optimizar el formato de la transmisión y/o de la vía de los mensajes SOAP. http://www.w3.org/TR/soap12-mtom/

● Descripción de los Servicios: ○ Web Services Description Language (WSDL): Lenguaje de Descripción de los

Servicios Web. Se trata de un lenguaje para describir Servicios Web. La especificación define el lenguaje básico que puede usarse para describir servicios Web basados en un modelo abstracto de lo que ofrece el servicio. También define los criterios de conformidad de los documentos en relación a este lenguaje. http://www.w3.org/TR/wsdl20/

○ Web Services Choreography Description Language (WS-CDL): Lenguaje de Descripción de la Coreografía de los Servicios Web. Es un lenguaje basado en XML que describe colaboraciones peer to peer de los participantes definiendo, desde

18

un punto de vista global, un comportamiento observable común y complementario; donde ordenado el mensaje, intercambia el resultado de acuerdo a un objetivo de negocios común.http://www.w3.org/TR/ws-cdl-10/

Los servicios web que se basan en XML permiten que las aplicaciones compartan información y que además invoquen funciones de otras aplicaciones independientemente de cómo se hayan creado dichas aplicaciones e independientemente del sistemas operativo o plataforma en que se ejecuten y de los dispositivos utilizados en el acceso. Los servicios Web XML, aunque sean independientes entre sí, pueden vincularse para realizar una tarea. Por ejemplo, Google, utiliza un Servicio Web -Google Web APIs- basado en los estándares SOAP y WSDL que permite programar en Java, Perl ó Visual Studio.NET y que sirve para la recuperación de información permitiendo utilizar este buscador en distintas plataformas y Servicios Web.http://www.google.com/apis/ Por su parte, Amazon Web Services ofrece una serie de de aplicaciones de referencia que permiten a los desarrolladores acceso directo a la plataforma de tecnología de Amazon y construir aplicaciones propias. Una lista promenorizada de muchos de los servicios web existentes en la actualidad los ofrece XMethod: http://www.xmethods.com

Además, existen numerosos proyectos como Web Services and Semantic (WS2) Project (http://www.w3.org/2004/WS2/) cuyo objetivo es promover los Servicios Web y trabajar en la integración de la semántica en la Web, o el proyecto Infrawebs Europe http://www.infrawebs.org/ cuyo objetivo es desarrollar un marco para que los desarrolladores de software y proveedores de servicios puedan generar y establecer plataformas de desarrollo para aplicaciones de Servicios Web que sean abiertas, extensibles y reconfigurables.

Como se ha afirmado anteriormente, los servicios web se componen de varias capas entre las que destacan: servicios de transporte (constituidos por los protocolos del nivel más bajo, que codifican la información independientemente de su formato, y que pueden ser comunes a otros servicios), de mensajería, de descripción y de descubrimiento.

En la capa inferior se encuentran los servicios de transporte que son los encargados de establecer la conexión y el puerto utilizado. Lo más común es emplear el protocolo de hipertexto HTTP, pero también se pueden usar otros protocolos como SMTP (Simple Mail Transfer Protocol o Protocolo de Transmisión de Correo Simple que es el protocolo que nos permite recibir correos electrónicos), o el protocolo FTP (File Transfer Protocol). En la capa siguiente se encuentran los servicios de mensajería que especifican cómo se tiene que codificar el mensaje que contiene los datos que se intercambian entre el ordenador cliente y el ordenador servidor. Como se ha afirmado, el protocolo más utilizado en esta capa es SOAP que permite utilizar cualquiera de los protocolos de transporte antes mencionados y que utiliza el lenguaje XML para especificar los mensajes.

Por su parte, la función del lenguaje WSDL (Web Service Description Language) es decirle a una aplicación qué formato usar para comunicarse, especificando por medio de un lenguaje estándar, tanto la dirección del servicio como la interfaz que se va a utilizar. WSDL es un lenguaje basado en

19

XML para describir servicios en la Web. Ofrece a los proveedores de servicios, una formato básico de descripción de las peticiones de servicios web sobre diferentes protocolos o codificaciones.

Existe un grupo de trabajo dentro del W3C, el Web Services Description Working Group http://www.w3.org/2002/ws/desc/ que analiza y desarrolla el lenguaje WSDL. WSDL se usa para describirqué puede hacer un servicio web, dónde reside, y cómo invocarlo. WSDL define los servicios como colecciones de puntos finales de la red o puertos. En WSDL la definición abstracta de puntos finales y mensajes se separa de su concreto despliegue en la red o formato de datos ligados. Esto permite reutilizar las definiciones abstractas de los mensajes, que son descripciones abstractas de los datos que están siendo intercambiados, y los tipos de puerto, que son colecciones abstractas de operaciones. El protocolo concreto y las especificaciones del formato de datos para un tipo particular de puerto constituye un enlace reutilizabe. Un puerto se define por asociación a una dirección de red con un enlace reutilizable; una colección de puertos define un servicio. Y, así, un documento WSDL usa los siguientes elementos en la definición de servicios en red:

Tipos (Types): un contenedor para definiciones del tipo de datos que usan algunos tipos de sistemas (tal como XSD).

Mensaje (Message): una definición abstracta tipo del dato que está siendo comunicado. Operación (Operation): una descripción abstracta de una acción soportada por el

servicio. Tipo de puerto (Port Type): un conjunto abstracto de operaciones soportadas por uno o

más puntos finales. Conexión (Binding): un protocolo concreto y una especificación de formato de datos

para un tipo de puerto particular. Puerto (Port): un punto final individual definido como una combinación de una conexión

y una dirección de la red. Servicio (Service): una colección de puntos finales relacionados.

Por último, en la capa superior se encuentra UDDI (Universal Description, Discovery and Integration), un protocolo que permite no sólo describir servicios web, sino también describir productos, compañías, transacciones, etc. UDDI es uno de los principales edificios construidos para llevar a cabo los servicios Web. UDDI provee un mecanismo para que los clientes encuentren de forma dinámica otros servicios web creando una plataforma interoperable estándar que permite a las compañías usar de forma rápida, fácil y dinámica los servicios Web. Usando la interfaz de UDDI, pueden conectarse dinámicamente la empresas con los servicios proporcionados por socios externos. Para ello es necesario registrarse en UDDI y los registros pueden tener diversos propósitos y usarse en distintos contextos. Existen 2 tipos de clientes: compañías que desean publicar un servicio (y su interfaz de uso) y clientes que desean obtener cierta clase de servicios por medio de una conexión. UDDI se monta sobre SOAP y asume que las consultas y las respuestas son objetos de UDDI enviados como mensajes de SOAP. El W3C también está teniendo en consideración los desarrollos del protocolo UDDI. Se trata de un esfuerzo conjunto de la industria

20

y en el que intervienen proveedores de las principales plataformas y software, así como operadores en el mercado y líderes de los negocios dentro del consorcio de los estándares OASIS. El proyecto UDDI no es específico de una industria, sino que cualquier compañía de cualquier parte del mundo puede beneficiarse de esta iniciativa. http://www.uddi.org/

Así pues, la plataforma básica de los Servicios Web es el lenguaje XML construido sobre el protocolo de hipertexto HTTP y para el intercambio de esta información estructurada en un entorno descentralizado y distribuido, se utiliza el protocolo SOAP (Simple Object Access Protocol), pero en los Servicios Web también intervienen otros mecanismos, lenguajes y tecnologías entre las que se encuentran el lenguaje WSDL, el protocolo UDDI y otros lenguajes como WSFL, WSML, WSMO, WSMX, etc.

El lenguaje WSFL o Web Services Flow Language es un lenguaje XML para describir la composición de los servicios web como parte de una definición del proceso de negocio. Fue diseñado por IBM como parte de un marco tecnológico de servicios web y para completar las especificaciones existentes. WSDL considera 2 tipos de servicios web: el primer tipo especifica un proceso de negocio ejecutable conocido como Modelo de flujo (flowModel) y el segundo tipo es un negocio en colaboración conocido como Modelo global (globalModel).

21

Para describir los servicios web, el W3C recomienda utilizar el Web Service Modeling Language (WSML) o Lenguaje de Modelado de Servicios Web que provee una sintaxis formal y una semántica para el modelado de ontologías de servicios web (Web Service Modeling Ontology -WSMO-). WSML está basado en diferentes lógicas formales, llamadas Lógica de descripción (Description Logics), Lógica de Primer Orden (First-Order Logic) y Lógica de Programación (Logic Programming), que se usan para el modelado de Servicios de la Web Semántica. WSML consta de un número de variantes basadas en estas diferentes lógicas formales llamadas WSML-Core, WSML-DL, WSML-Flight, WSML-Rule y WSML-Full. WSML-Core es el núcleo el lenguaje y las otras variantes WSML ofrecen incrementos de expresividad en la dirección de la Descripción Lógica y la Lógica de Programación. Por último, ambos paradigmas se unifican en WSML-Full, la variante más expresiva de WSML.

WSML se especifica en términos de una sintaxis normativa legible por seres humanos. Pero además de esta sintaxis legible por seres humanos, WSML tiene una sintaxis XML y RDF para el intercambio sobre la Web y para la interoperabilidad con aplicaciones basadas en RDF. También es posible el mapeo entre ontologías WSML y ontologías OWL para interoperar con ontologías OWL por medio de un subconjunto semántico común de OWL y WSML. Más información al respecto, se puede obtener en: http://www.wsmo.org/wsml/wsml-syntax, http://www.wsmo.org/wsmly http://www.w3.org/Submission/WSML/.

22

Por su parte, Web Service Modeling Ontology (WSMO) u Ontología de Modelado para Servicios Web se basa en el Marco de Modelado de Servicios Web (WSMF) que separa los elementos que se necesitan para describir servicios en ontologías, servicios Web, objetivos y mediadores. WSML es el lenguaje usado para describir todos estos elementos. El modelo de servicios describe el comportamiento del servicio en términos de procesos y de constructos de control. La base conecta procesos, entradas y salidas en el modelo de proceso a un determinado protocolo de transporte descrito en un documento de WSDL (http://www.wsmo.org y http://www.w3.org/Submission/WSMO/)

WSMO supone uno de los mayores esfuerzos con el propósito de especificar la información semántica de los Servicios Web para hacer posible la automatización de servicios, su composición y ejecución. WSMO recomienda el uso de vocabularios ampliamente aceptados tales como metadatos Dublin Core y FOAF. En WSMO, un objetivo especifica qué quiere el usuario y las descripción del servicio Web definen la capacidad que proporciona el servicio. Con WSMO también pueden expresarse las propiedades no funcionales del servicio.(http://www.wsmo.org/TR/d2/v1.2/)

También se ha desarrollado WSMX (Web Service Modelling eXecution environment) que es el entorno de ejecución de modelado de servicios web y la implementación de referencia de WSMO. Se trata de la ejecución de un entorno para integración de las aplicaciones de los compañías donde los servicios web están integrados por varias aplicaciones. El objetivo es incrementar la automatización de los procesos en los negocios de una manera flexible mientras se ofrecen soluciones de integración escalable. El lenguaje interno de WSMX es WSML.(http://www.wsmx.org/)

Por último, también existe el lenguaje SWSL (Semantic Web Services Language) un lenguaje para describir la ontología de los servicios de la Web Semántica (SWSO). SWSL tiene 2 partes: SWSL-FOL, un lenguaje de lógica de primer orden, y SWSLRules, un lenguaje basado en reglas. SWSL-FOL se usa principalmente para la especificación formal de la ontología y para proeer interoperabilidad con otros modelos de procesos basados en la lógica de primer orden y otras ontologías de servicios. Por el contrario, SESL-Rules está diseñado para ser un lenguaje actual para la especificación de servicios. (http://www.w3.org/Submission/SWSF-SWSL/)

23

LOS SERVICIOS WEB Y REST Esta comparación es un tanto errónea, aunque es bastante típica entre los Diseñadores de Software y Desarrolladores. REST es un estilo, mientras que los servicios Web son sistemas software. Por tanto, no es posible la comparación de ambos conceptos. Por otra parte, popularmente se generaliza el concepto de servicio Web con el de servicio Web basado en SOAP. Entonces cabe aclarar que es posible diseñar servicios Web basados en REST, es decir tomando REST como estilo de diseño.

Por tanto, el análisis debe ser formulado de la siguiente manera.

EL DEBATE ENTRE LOS SERVICIOS WEB BASADOS EN REST Y SOAP Muchos diseñadores de Servicios Web están llegando a la conclusión que SOAP es demasiado complicado. Por tanto, están comenzando a utilizar Servicios Web basados en REST para mostrar cantidades de datos masivos. Este es el caso de grandes empresas como eBay, Yahoo! o Google.

El problema principal surge del propósito inicial de SOAP. Esta tecnología fue originalmente pensada para ser una versión, sobre Internet, de DCOM o CORBA. Así lo demuestra su predecesor, el protocolo XML-RPC. Estas tecnologías lograron un éxito limitado antes de ser adaptadas. Esto es debido a que este tipo de tecnologías, las basadas en modelos RPC (Remote Procedure Call) son más adecuadas para entornos aislados, es decir, entornos donde se conoce perfectamente el entorno. La evolución en este tipo de sistemas es sencilla, se modifica cada usuario para que cumpla con los nuevos requisitos.

Pero cuando el número de usuarios es muy grande es necesario emplear una estrategia diferente. Se necesita organizar frameworks que permitan evolucionar, tanto por el lado del cliente como del servidor. Se necesita proponer un mecanismo explícito para la interoperabilidad de los sistemas que no poseen la misma API. Protocolos basados en RPC no son adecuados para este tipo de sistemas, ya que cambiar su interfaz resulta complicado.

Por esta razón, se intenta tomar como modelo a la Web. A primera vista se puede pensar que SOAP lo hace, ya que utiliza HTTP como medio de transporte. Pero Fielding argumenta que la Web funciona mejor cuando se utiliza en el estilo que lo hace REST. Utilizar HTTP como medio de transporte para protocolos de aplicación a través de firewalls es una idea equivocada. Esto reduce la efectividad de tener un firewall. Lo cual aumenta las posibilidades de nuevos agujeros de seguridad.

Sin embargo, los partidarios de SOAP argumentan que gracias a la tecnología existente que permite a los diseñadores encapsular la complejidad del sistema, dando lugar a interfaces generadas automáticamente que permiten facilitar el diseño del sistema.

Según argumenta Spolsky lo interesante de SOAP es que permite utilizar lenguajes de alto nivel para llamar y para implementar el servicio. Añade que “Alegar que SOAP es malo porque el formato de conexión es horrible y pesado es como alegar que nadie debería utilizar Pentium

24

porque su juego de instrucciones es mucho más complicado que el juego de instrucciones del 8086. Eso es cierto, pero por esa razón existen los compiladores.”

CARACTERÍSTICAS DE REST Y SOAP Según hemos visto a lo largo del documento, el principal beneficio de SOAP recae en ser fuertemente acoplado, lo que permite poder ser testado y depurado antes de poner en marcha la aplicación. En cambio, las ventajas de la aproximación basada en REST recaen en la potencial escalabilidad de este tipo de sistemas, así como el acceso con escaso consumo de recursos a sus operaciones debido al limitado número de operaciones y el esquema de direccionamiento unificado.

A modo de resumen, veamos las características de ambas aproximaciones en la siguiente tabla:

REST SOAP

Características Las operaciones se definen en los mensajes.

Una dirección única para cada instancia del proceso.

Cada objeto soporta las operaciones estándares definidas.

Componentes débilmente acoplados.

Las operaciones son definidas como puertos WSDL.

Dirección única para todas las operaciones.

Múltiple instancias del proceso comparten la misma operación.

Componentes fuertemente acoplados.

Ventajas declaradas

Bajo consumo de recursos. Las instancias del proceso son

creadas explícitamente. El cliente no necesita

información de enrutamiento a partir de la URI inicial.

Los clientes pueden tener una interfaz “listener” (escuchadora) genérica para las notificaciones.

Generalmente fácil de construir y adoptar.

Fácil (generalmente) de utilizar. La depuración es posible. Las operaciones complejas

pueden ser escondidas detrás de una fachada.

Envolver APIs existentes es sencillo

Incrementa la privacidad. Herramientas de desarrollo.

Posibles desventajas

Gran número de objetos. Manejar el espacio de nombres

(URIs) puede ser engorroso. La descripción

sintáctica/semántica muy informal (orientada al usuario).

Pocas herramientas de desarrollo.

Los clientes necesitan saber las operaciones y su semántica antes del uso.

Los clientes necesitan puertos dedicados para diferentes tipos de notificaciones.

Las instancias del proceso son creadas implícitamente.

25

DIFERENCIAS ENTRE REST Y SOAP La principal diferencia entre REST y SOAP se resume en los siguientes puntos de vista del propósito de la Web:

REST SOAP

“La Web es el universo de la información accesible globalmente” (Tim Berners Lee)

“La Web es el transporte universal de mensajes”

A continuación vamos a intentar esbozar las diferencias entre REST y SOAP desde varios puntos de vista:

REST SOAP Tecnología Interacción dirigida por el usuario

por medio de formularios. Flujo de eventos orquestados.

Pocas operaciones con muchos recursos

Muchas operaciones con pocos recursos.

Mecanismo consistente de nombrado de recursos (URI).

Falta de un mecanismo de nombrado.

Se centra en la escalabilidad y rendimiento a gran escala para sistemas distribuidos hipermedia.

Se centra en el diseño de aplicaciones distribuidas.

Protocolo

Principalmente JSON. XML auto descrip vo.

Tipado fuerte, XML Schema.

HTTP. Independiente del transporte. HTTP es un protocolo de aplicación. HTTP es un protocolo de transporte. Síncrono. Síncrono y Asíncrono.

Descripción del servicio

Con a en documentos orientados al usuario que define las direcciones de pe ción y las respuestas.

WSDL.

Interactuar con el servicio supone horas de testeado y depuración de URIs.

Se pueden construir automá camente stubs (clientes) por medio del WSDL.

No es necesario el pado fuerte, si ambos lados están de acuerdo con el contenido.

Tipado fuerte.

WADL propuesto en noviembre de WSDL 2.0.

26

2006. Ges ón del estado

El servidor no ene estado (stateless).

El servidor puede mantener el estado de la conversación.

Los recursos con enen datos y enlaces representando transiciones a estados válidos.

Los mensajes solo con enen datos.

Los clientes man enen el estado siguiendo los enlaces.

Los clientes man enen el estado suponiendo el estado del servicio.

Técnicas para añadir sesiones: Cookies

Técnicas para añadir sesiones: Cabecera de sesión (no estándar)

Seguridad HTTPS. WS-Security. Implementado desde hace muchos años.

Las implementaciones están comenzando a aparecer ahora.

Comunicación punto a punto segura. Comunicación origen a des no segura.

Metodología de diseño

Iden ficar recursos a ser expuestos como servicios.

Listar las operaciones del servicio en el documento WSDL.

Definir URLs para direccionarlos. Definir un modelo de datos para el contenido de los mensajes.

Dis nguir los recursos de solo lectura (GET) de los modificables (POST, PUT, DELETE).

Elegir un protocolo de transporte apropiado y definir las correspondientes polí cas QoS, de seguridad y transaccional

Implementar e implantar el servidor Web.

Implementar e implantar el contenedor del servicio Web.

PROTOCOLOS DE INTERCAMBIO DE INFORMACIÓN: JSON VS XML Tanto REST como SOAP poseen sus características específicas como metodologías de desarrollo de Servicios Web, por lo tanto estos poseen ciertas formas de estructurar la información para el intercambio de la misma: JSON y XML respectivamente.

XML y JSON son lenguajes para el intercambio de datos, uno es un lenguaje con historia, seguro, de fácil lectura tanto por software como por las personas, posee estructura jerárquica. El otro,

27

reduce el tamaño de la respuesta del servidor, es más natural, es más abreviado, requiere menos codificación, menos procesamiento y representa mejor la estructura de datos.

Ambos tienen el mismo objetivo, crear un formato que sea fácil de leer y entender para el almacenamiento de información. Primero tenemos la definición de ambos formatos.

JSON Acrónimo de JavaScript Object Notation, es un formato ligero para el intercambio de datos. JSON es un subconjunto de la notación literal de objetos de JavaScript que no requiere el uso de XML.

La simplicidad de JSON ha dado lugar a la generalización de su uso, especialmente como alternativa a XML en AJAX. Una de las supuestas ventajas de JSON sobre XML como formato de intercambio de datos en este contexto es que es mucho más sencillo escribir un analizador sintáctico (parser) de JSON. En JavaScript, un texto JSON se puede analizar fácilmente usando el procedimiento eval(), lo cual ha sido fundamental para que JSON haya sido aceptado por parte de la comunidad de desarrolladores AJAX, debido a la ubicuidad de JavaScript en casi cualquier navegador web.

XML Siglas en inglés de eXtensible Markup Language ('lenguaje de marcasextensible'), es un lenguaje de marcas desarrollado por el World Wide Web Consortium (W3C). Deriva del lenguaje SGML y permite definir la gramática de lenguajes específicos (de la misma manera que HTML es a su vez un lenguaje definido por SGML) para estructurar documentos grandes. A diferencia de otros lenguajes XML da soporte a bases de datos, siendo útil cuando varias aplicaciones se deben comunicar entre sí o integrar información.

XML no ha nacido sólo para su aplicación en Internet, sino que se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas. Se puede usar en bases de datos, editores de texto, hojas de cálculo y casi cualquier cosa imaginable.

EJEMPLO DE JSON Y XML

XML

28

JSON

VENTAJAS Y DESVENTAJAS DE SU USO

Un archivo JSON es un conjunto de datos agrupados. Nada más. Puede tener una estructura jerárquica, pero lo único que tienes son objetos, vectores, variables y valores.

Un archivo XML es mucho más. Es un conjunto de datos estructurado. Como tal, admite consultas (xpath), tiene una estructura fácilmente comprobable (DTD, XML Schema), puede visualizarse (CSS), procesarse (XSL), etc.

Espacio

A menudo se alega que JSON es mucho más pequeño que XML, por lo que es mucho mejor para compartir datos en red.

Se estima que un archivo JSON es, aproximadamente, las tres cuartas partes de un archivo XML (comparando archivos "equivalentes” para obtener un resultado más confiable)

Sin embargo, si lo que se desea es ahorrar espacio, es mejor utilizar algún formato binario o un JSON/XML comprimido. Dado que son archivos de texto, es posible que ambos se compriman en gran magnitud, dando lugar a tamaños muy similares.

Además, un XML admite referencias dentro del propio XML, así como entidades, por lo que se pueden generar macros, que es algo que JSON no soporta. Además, XML soporta referencias a archivos externos -que pueden encontrarse ya en la máquina destino y no tener que enviarse por la red-, por lo que en teoría sería mucho más rápido de enviar.

Hay que agregar que un archivo JSON siempre debería ir codificado en UTF-16 little endian, ya que estaba pensado para javascript/java, pero un XML puede ir codificado en cualquier sistema. De esta manera, según qué contenido, puede ocupar mucho menos un XML que un JSON.

29

Velocidad

En muchos sitios se alega que JSON, al ser más pequeño que XML, es más rápido de procesar.

Eso no es del todo cierto: JSON, al tener muchas menos características que XML, debería ser más rápido de procesar. Sin embargo, no es posible utilizar Firefox como téster, ya que la velocidad de proceso dependerá de la librería que utilicemos para procesarlo.

El problema de este tipo de comparación es que es muy peligrosa y poco fiable ya que se comparan dos elementos de distinta naturaleza. ¿Cuál es el precio de comprobar que el JSON tiene la estructura que esperamos? ¿Cuál es el precio de tener que programar, cada vez, el comprobador? Con XML lo tenemos muy sencillo, ya que basta con indicar el XML Schema y ya se encargará la librería que estamos utilizando.

Variedad

Como todo, XML se creó con una finalidad y JSON se creó con una finalidad completamente distinta. XML es una manera de estructurar datos, mientras que JSON es una manera de intercambiar datos entre un lenguaje que debería ser sencillo (javascript) y otro lenguaje (java).

De todas maneras, de la misma manera que a XML se le han encontrado otros usos posteriores, como SOAP, seguramente JSON tenga muchos otros usos, como es el caso de REST.

REST COMO SOLUCIÓN DEFINITIVA A TODOS LOS PROBLEMAS Evidentemente no se puede concebir a la metodología REST, como una ganadora completa frente a SOAP. Sin embargo, existen una serie de puntos que resaltan los partidarios de SOAP, que son de gran utilidad en REST:

• Asincronía: Esto normalmente tiene diferentes significados, pero el concepto más común es que dos programas en comunicación (cliente y servidor, en nuestro caso) deberían no necesitar estar en comunicación constante mientras uno de ellos está realizando una operación costosa. Debería existir algún tipo de mecanismo mediante el cual un participante pueda avisar al otro cuando el resultado esté listo. SOAP no soporta directamente esto, sin embargo puede utilizarse de una manera asíncrona por medio del uso de un transporte asíncrono, aunque esto no está todavía estandarizado. Por otra parte, existen una variedad de propuestas para hacer asíncrono a HTTP, ya que existen una variedad de aspectos a asincronizar. Una de tales especificaciones es conocida como “HTTPEvents”, la cual está propuesta para su estandarización.

• Routing (Enrutamiento): Los mensajes HTTP son enrutados del cliente a los proxys y a los servidores. Esto es una especie de enrutamiento controlado por la red, pero a veces es adecuado poder controlar por el cliente el enrutamiento de los mensajes mediante la definición de una ruta entre los nodos. Los partidarios de REST creen que esto puede ser uno de los pocos puntos en

30

común con SOAP, ya que el modo que SOAP utiliza el “Routing” es compatible con la Web. Por tanto, los investigadores de REST trabajan en un modelo similar al de SOAP.

• Fiabilidad: Este concepto al igual que el de asincronía puede tener varias interpretaciones. El más común es el envío de una única vez del mensaje. Esto es relativamente fácil de lograr en HTTP, pero no es una característica integrada. La solución consiste en enviar repetidamente e internamente el mensaje hasta obtener una confirmación. Pero el problema recae en el uso del comando POST, recordemos que no es free-side-effect. Por tanto, es necesario incluir en la cabecera algún tipo de identificador del mensaje. En el caso de que el destinatario obtenga un mensaje previamente analizado, el mensaje se desecha.

• Seguridad: Los defensores de SOAP argumentan que REST no dispone de mecanismos tan completos de seguridad como es el caso de la especificación WS-Security. Aunque en realidad, esto debería ser estudiado más profundamente.

Una manera muy sencilla de controlar la seguridad consiste en utilizar listas de control de acceso (ACLs). Esta medida de seguridad se puede tomar tanto a nivel global como a nivel local (URIs). Este sistema resulta mucho más difícil de implementar en soluciones basadas en RPC, ya que el sistema de direccionamiento es propietario y expresado en parámetros arbitrarios. Por otra parte, es posible utilizar las características de seguridad implícitas de HTTP: HTTPS y el sistema de autorización y autenticación de HTTP.

• Modelo extensible: SOAP tiene un modelo extensible que permite al creador del mensaje SOAP ser muy explícito sobre si comprender una porción del mensaje es opcional u obligatorio. Esto también permite al encabezamiento ser objetivo de algunos intermediarios. Existe una extensión de HTTP con muchas de las mismas ideas (posiblemente la versión SOAP esté basada en esta versión), pero no es tan conocida ni está tan clara sintácticamente.

• Descripción del servicio: SOAP tiene WSDL, pero muchos alegan que HTTP no tiene nada similar hasta la fecha. Esto no es del todo cierto, WADL (Web Application Description Language) proporciona una simple alternativa a WSDL para el uso con aplicaciones Web basadas en XML/HTTP. Hasta el momento tales aplicaciones han sido descritas principalmente por medio de combinaciones de descripciones textuales y esquemas XML. WADL pretende proporcionar una descripción de estas aplicaciones procesable automáticamente.

31

• Familiaridad: REST requiere repensar el problema en términos de manipulación de recursos direccionables en vez de llamadas a métodos. Evidentemente, la parte del servidor puede implementarse como se quiera, pero la interfaz con los clientes debe hacerse en términos de REST.

Los clientes podrían preferir una interfaz basada en componente a una interfaz REST. Así como los programadores que están más familiarizados con el uso de APIs. Además, las APIs se integran mucho mejor en los lenguajes de programación existentes. Para los programadores por el lado del cliente, REST puede resultar algo novedoso, en cambio para el otro lado, no se notara mucha diferencia con lo que se había desarrollado en los últimos años, sitios Webs.

GUÍA PARA CREAR SERVICIOS WEB REST EN NETBEANS. Como primer paso, creamos un nuevo proyecto web y elegimos su ubicación.

En la configuración del servidor elegimos GlassFish Server y la versión 6 de Java EE, por ultimo podemos seleccionar los frameworks que podemos usar en la aplicación, para nuestro caso no es necesario ya que solo se consumirán los servicios web.

Por ultimo al presionar el botón “Finish” se creara nuestro proyecto y se mostrara el entorno de trabajo.

32

Ahora crearemos la conexión a nuestra base de datos, como ejemplo se utilizará el gestor MySql y una base llamada “Alumnos”.

Dentro del panel del proyecto iremos a la pestaña “Services” y al hacer click derecho sobre Databases seleccionamos “New Connection”

Nos mostrara una ventana de dialogo como la siguiente, aquí en la opción Driver debemos seleccionar MySQL (Connector/ J driver), luego presionamos Next.

33

En el siguiente dialogo especificamos los valores para la conexión a la base de datos como se muestra, teniendo cuidado de escribir el nombre de nuestra base en el campo database, y como user name se tiene por defecto el “root”, presionamos el botón Test Conecction para verificar que los datos son los correctos y luego el botón Next.

Por ultimo en el siguiente cuadro presionamos sobre el botón Finish.

34

Ya tenemos nuestra conexión lista y la podemos observar dentro de la pestaña “Services”.

Ahora regresamos a las pestaña Projects y crearemos dos paquetes, el primero com.alumnos.entidad contendrá las clases entidad generadas de nuestra base de datos, el segundo com.alumnos.servicio tendrá las clases que contienen los servicios web.

Ahora hacemos click derecho sobre el paquete com.alumnos.entidad y buscamos la opción New -> Entity Classes from Database

Lo cual nos mostrara el siguiente cuadro de dialogo para establecer la base de datos, aquí en la opción Data Source seleccionamos New Data Source

35

En el siguiente cuadro colocamos Alumnos en la opción JNDI Name, y en Database Connection deberá aparecernos la que fue creada con anterioridad, la seleccionamos y presionamos OK.

Una vez realizado podemos observar que aparecerán las tablas de nuestra base, presionamos el botón Add All para crear las clases de todas las tables, y luego en el botón next.

En el siguiente dialogo verificamos que el paquete que contendrá nuestras clases sea com.alumnos.entidad, y estén seleccionadas las demás opciones tal como muestra la imagen, presionamos el botón next.

36

Por ultimo especificamos las opciones de mapeo, en la opción Collection Type seleccionamos java.util.List y las demás opciones tal como muestra la imagen.

Por ultimo presionamos Finish y nuestras clases serán generadas.

37

Ahora crearemos los servicios web, para ello seleccionamos click derecho dentro de nuestro paquete com.alumnos.servicio, y buscamos la opción new -> RESTful Web Service from Entity Classes.

Nos mostrara el siguiente cuadro de dialogo donde se muestras las clases entidad disponibles, presionamos el botón Add All y luego Next.

En la siguiente pantalla verificamos que nuestros servicios sean creados en el paquete especificado com.alumnos.servicio.

38

Presionamos sobre el botón Finish y nos mostrara el siguiente cuadro con las opciones para registrar nuestros servicios dentro de la aplicación, en este caso dejamos los valores por defecto tal como muestra la figura y presionamos OK.

Ahora nuestras clases han sido creadas, cabe destacar que dentro de la vista de nuestro proyecto se genera una carpeta especial (RESTful Web Services) en la que podemos acceder y testear nuestros servicios.

39

Luego de esto podemos probar sin errores nuestro proyecto, como primer paso hacemos click sobre él y seleccionamos la opción “Deploy”.

40

PRUEBAS A SERVICIOS WEB REST

DEV HTTP Client Fácil de construir peticiones HTTP personalizadas. Dev cliente HTTP está diseñado para hacer descubrimiento de recursos HTTP, manipulación y la pruebas más fácilmente. A continuación se muestra la interfaz de la aplicación luego de ser instalada en nuestro navegador

Luego de ello se ocupara el metogo GET y procedemos a realizar las pruebas con nuestra aplicacion a traves de la URL http://5.114.4.196:8080/TEST/resources/com.test.entity.poi.que es la que tenemos configurada como ejemplo. Damos SEND y se produce una petición HTTP de nuestro RESTful Web Service y vemos que en la pestaña Response Headers aparece tanto un código de estatus, el tipo de contenido la fecha y el servidor de nuestra aplicación

41

En la pestaña Response Body podemos observar nuestra petición en formato JSON

42

43

RESTClient Un depurador para servicios web RESTful. 2.0.3. Sirve para construir peticiones HTTP y testear directamente solicitudes a un servidor. Al Igual que el anterior haremos una peticion GET con la URL http://5.114.4.196:8080/TEST/resources/com.test.entity.poi

Luego de ello obtenemos respuesta a nuestra petición de nuestro RESTful Web Service en un formato JSON

44

45

CONCLUSIÓN:

Los servicios web, propiamente dichos dependen en alta medida de la arquitectura de diseño en la

cual dichos servicios hayan sido basados. Entre estos estilos de diseño encontramos dos que en la

actualidad se debaten cual es el mejor, de forma que se exponen sus características y diferencias

para que el desarrollador defina por el mismo cuál de las dos le es más conveniente. Estamos

refiriéndonos a REST y SOAP.

Por el lado de REST (Representational State Transfer), podemos concluir que es un estilo de

arquitectura de software para sistemas hipermedias distribuidos tales como la Web. En realidad,

REST se refiere estrictamente a una colección de principios para el diseño de arquitecturas en red.

Estos principios resumen como los recursos son definidos y diseccionados para un uso

conveniente de los mimos, esto lo ha llevado al punto de éxito que es usado por gigantes de la

web como Amazon, eBay y Google.

En cuanto a SOAP, esta tecnología fue originalmente pensada para ser una versión, sobre Internet,

de DCOM o CORBA. Así lo demuestra su predecesor, el protocolo XML-RPC. Estas tecnologías

mostraron buenos resultados en entornos aislados y controlados, pero en entornos de rápido

crecimiento era necesario organizar frameworks para poder evolucionar con el entorno, tanto en

cliente como servidor.

SOAP utiliza lenguajes de alto nivel para ejecutar la llamada e implementación de los servicios

web, lo que conduce a proponer un mecanismo explícito para la interoperabilidad de los sistemas

que no poseen la misma API. Como último, podemos decir que SOAP utiliza como medio de

transporte el protocolo HTTP.

46

GLOSARIO

Distributed Component Object Model (DCOM), en español Modelo de Objetos de Componentes Distribuidos, es una tecnología propietaria de Microsoft para desarrollar componentes software distribuidos sobre varios ordenadores y que se comunican entre sí.

Common Object Request Broker Architecture (CORBA) es un standard definido por el Object Management Group (OMG) que permite que diversos componentes de software escritos en múltiples lenguajes de programación y que corren en diferentes computadoras puedan trabajar juntos.

Interfaz de programación de aplicaciones (IPA) o API (del inglés Application Programming Interface) es el conjunto de funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción. Son usadas generalmente en las bibliotecas (también denominadas vulgarmente "librerías").

WSDL (en ocasiones leído como como wisdel) son las siglas de Web Services Description Language, un formato XML que se utiliza para describir servicios Web . La versión 1.0 fue la primera recomendación por parte del W3C y la versión 1.1 no alcanzó nunca tal estatus. La versión 2.0 se convirtió en la recomendación actual por parte de dicha entidad.

WSDL describe la interfaz pública a los servicios Web. Está basado en XML y describe la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan después al protocolo concreto de red y al formato del mensaje.

Uniform Resource Identifier o URI (en español «identificador uniforme de recurso») es una cadena de caracteres corta que identifica inequívocamente un recurso (servicio, página, documento, dirección de correo electrónico, enciclopedia, etc.). Normalmente estos recursos son accesibles en una red o sistema. Los URI pueden ser localizadores uniformes de recursos (URL), Uniform Resource Name (URN), o ambos

Web Application Description Language (WADL) descripción de formato en para aplicaciones web basadas en HTTP (Específicamente para aplicaciones basadas en REST).

WS-Security (Seguridad en Servicios Web) es un protocolo de comunicaciones que suministra un medio para aplicar seguridad a los Servicios Web. En abril de 2004 el

47

estándar WS-Security 1.0 fue publicado por Oasis-Open. En 2006 fue publicada la versión 1.1.

Originalmente desarrollado por IBM, Microsoft, y VeriSign, el protocolo es ahora llamado oficialmente WSS y está desarrollado por un comité en Oasis-Open.

El protocolo contiene especificaciones sobre cómo debe garantizarse la integridad y seguridad en mensajería de Servicios Web.

Hyper Text Transfer Protocol Secure (en español: Protocolo seguro de transferencia de hipertexto), más conocido por sus siglas HTTPS, es un protocolo de aplicaciónbasado en el protocolo HTTP, destinado a la transferencia segura de datos de Hiper Texto, es decir, es la versión segura de HTTP.

Es utilizado principalmente por entidades bancarias, tiendas en línea, y cualquier tipo de servicio que requiera el envío de datos personales o contraseñas.

QoS o Calidad de Servicio (Quality of Service, en inglés) son las tecnologías que garantizan la transmisión de cierta cantidad de información en un tiempo dado (throughput). Calidad de servicio es la capacidad de dar un buen servicio. Es especialmente importante para ciertas aplicaciones tales como la transmisión de vídeo o voz.

AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones.

World Wide Web Consortium, abreviado W3C, es un consorcio internacional que produce recomendaciones para la World Wide Web.

SGML son las siglas de Standard Generalized Markup Language o "Estándar deLenguaje de Marcado Generalizado". Consiste en un sistema para la organización y etiquetado de documentos.

Lista de control de acceso o ACL (del inglés, access control list) es un concepto de seguridad informática usado para fomentar la separación de privilegios. Es una forma de determinar los permisos de acceso apropiados a un determinado objeto, dependiendo de ciertos aspectos del proceso que hace el pedido.

48

BIBLIOGRAFIA:

Leonard Richardson and Sam Ruby, "REST ful Web Services", O'Reilly Publishers,

2007.

Stefan Tilkov, “REST vs SOAP. Oh no, Not Again”.

Joe Gregorio, “How to create a REST Protocol”. XML.com website.

http://www.xml.com/pub/a/2004/12/01/restful-web.html

William Brogden, “REST versus SOAP – the REST story”.