tsi2 07-web-services

Instituto de

Computación

Facultad de

Ingeniería

Universidad de la

República de Uruguay

Taller de Sistemas de

Información 2

Web Services

11 de Setiembre de 2012

Instituto de Computación – Facultad de Ingeniería – UdelaR – Montevideo, Uruguay 2


Que es un web service?

● Es un servicio o funcionalidad

● Se encuentra disponible a través de Internet o una

Intranet

● Usando una forma estandarizada de mensajería

(generalmente XML)

● No se encuentra atado a ningún sistema operativo ni

ningún lenguaje de programación

● Se puede auto describir (generalmente vía XML)

● Puede ser descubierto a través de un mecanismo de

búsqueda


Tendencias

● Hoy día tenemos dos grandes tendencias en el

desarrollo de web services

● Web services que estandarizan su información

a través de mensajes XML, en formato SOAP.

Estos se denominan servicios SOAP

● Web services que no estandarizan su

información, denominados servicios REST


Web Services SOAP

● Este tipo de servicios, implica el intercambio de

mensajes XML, codificados según el protocolo

SOAP

● Estos mensajes tienen la forma:


Web Services SOAP

● Estos mensajes en formato SOAP son movidos de un

sistema a otro, utilizando HTTP

● El sistema recibe el mensaje, hace lo que tiene que

hacer, y devuelve una respuesta también en formato

SOAP

● Es un sistema simple, que no tiene en cuenta aspectos

importantes del desarrollo de soluciones empresariales,

pero que son tenidas en cuenta a través de extensiones

a los estándares


Especificaciones

● Los servicios web utilizan diferentes

especificaciones para estandarizar su

funcionamiento

● Estas se dividen en dos tipos

● Especificaciones básicas

● Especificaciones avanzadas, de las cuales algunas

se destacan por su utilidad para la construcción de

soluciones de integración


WSDL

Web Services Description Language

(WSDL)

HTTP

SOAP Simple Object

Access Protocol (SOAP)

Universal Description, Discovery and Integration

(UDDI)

Publish Find

FTP, SMTP, etc.

Especificaciones basicas


Mensajes SOAP

● La estructura básica de un mensaje SOAP

consiste de un elemento “Envelope” el cual

contiene

● un elemento opcional “Header”

● un elemento requerido “Body”

– que puede incluir un elemento “Fault”

● El “Envelope” es el elemento raíz de todo

mensaje SOAP e identifica un documento XML

como un mensaje SOAP


Mensaje SOAP

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-

encoding">

<soap:Header>

...

</soap:Header>

<soap:Body>

...

<soap:Fault> ... </soap:Fault>

</soap:Body>

</soap:Envelope>


Mensaje SOAP – Body

<soap:Body>

<t:Translate xmlns:t="http://....../translations">

<t:Word>red</t:Word>

</t:Translate>

</soap:Body>

<soap:Body>

<t:TranslateResponse

xmlns:t="http://....../translations">

<t:Translation>rojo</t:Translation>

</t:TranslateResponse>

</soap:Body>

resultado

solicitud


Transporte de mensajes

● SOAP no impone el uso de un determinado

protocolo para el intercambio de mensajes

● A través del concepto de “binding” SOAP

permite especificar:

● cómo los mensajes SOAP se encapsulan en un

protocolo de transporte

● cómo los mensajes SOAP deben ser tratados con

las primitivas del protocolo


WSDL

● Web Services Description Language

● Lenguaje basado en XML que permite describir

la interfaz y otras características de un Web

Service

● Un documento WSDL puede dividirse en dos

partes:

● descripción abstracta

● descripción concreta


Estandares avanzados


Profiles

● Basic Profile (BP)

● Guías para el desarrollo de WS interoperables utilizando las

especificaciones centrales

● Basic Security Profile (BSP)

● Extiende el BP definiendo guías para el desarrollo de WS

seguros

● Algunos ejemplos:

● Prohíbe el uso de SSL 2.0

● Restringe cantidad de timestamps en header a 1

● Prohíbe encriptar los elementos body, header y envelope


Plataformas para web services

● Las plataformas de Web Services son un

conjunto de herramientas para un lenguaje de

programación específico

● Permiten:

● invocar web services

● realizar el deploy de Web Services

● Las plataformas tienen en general

componentes en el servidor y en el cliente



● Los componentes en el servidor se alojan

usualmente en algún tipo de contenedor

● servidor Java EE

● contenedor de servlets

● Los componentes en el cliente se empaquetan

en general como herramientas para acceder a

interfaces asociadas a WS



● Las plataformas de Web Services

proveen en general tres subsistemas:

● Invocación

● Serialización

● Deployment


Subsistema de invocación (servidor)

● Recibir SOAPs desde el transporte (HTTP, etc)

● Invocar manejadores para QoS (seguridad, etc)

● Determinar la operación que se quiere invocar

● Determinar la clase/método que se quiere invocar

● Enviar el SOAP al sistema de serialización

● Invocar la clase-método

● Enviar el resultado al sistema de serialización

● Crear y enviar el mensaje SOAP al transporte para el

envío de la respuesta


Subsistema de invocación (cliente)

● Instanciar la clase que implementa la interfaz para

acceder a WS y manejar su invocación

● Enviar parámetros al sistema de serialización

● Adjuntar los mismos en un mensaje SOAP

● Invocar manejadores para QoS

● Enviar el SOAP a través del trasporte (ej. HTTP)

● Recibir los SOAPs respuesta desde el transporte

● Enviar los SOAP al sistema de serialización y completar

la invocación


Subsistema de invocación

Subsistema de Invocación (cliente)

Subsistema de Invocación (servidor)

Param

Param

Param

Request

SOAP

Request

SOAP

Respons

e SOAP

Respons

e SOAP

Param

Param

Param

Return

Objeto

Función

Invocación de Métodos

Invocación de Métodos

Intercambio de Mensajes SOAP

Return


Subsistema de serialización


Subsistema de deployment

● Provee herramientas para configurar un

componente de software para que pueda ser

invocado como un WS vía mensajes SOAP

● Desplegar el componente de SW

● Mapeo operaciones WSDL – componente SW

● Configuración serialización (esquema – params)

● Publicación del WSDL

● Configurar aspectos avanzados (seguridad, etc.)

● Configurar el listener en una dirección de red


Algunas plataformas de WS

● Windows Communication Foundation

● http://msdn.microsoft.com/en-us/library/ms730294.aspx

● Apache AXIS 2

● http://axis.apache.org/axis2/java/core/

● Apache CXF

● http://cxf.apache.org/

● Proyecto Metro

● http://metro.java.net/

● JBoss Web Services

● http://www.jboss.org/jbossws


Implementacion de WS

● Implementación Bottom-up

● Se comienza por el código (por ejemplo, una

clase Java)

● Code-First / Contract-Last

● Implementación Top-down

● Se comienza por el WSDL

● Code-Last / Contract-First


Bottom-Up

● Ventajas

● Forma rápida de exponer funcionalidades vía WS

● No requiere conocimiento de XMLSchema, WSDL

● Desventajas

● El esquema es embebido en el WSDL

● Los cambios en la interfaz son más difíciles de

manejar

● En el WSDL hay dependencias con la

implementación (paquetes y namespaces)


Top-Down

● Ventajas

● Permite el desarrollo independiente y paralelo entre

cliente y servicio

● Cuando se crean nuevos tipos, éstos pueden ser

reutilizados por otros servicios

● No se generan dependencias con la implementación

● Desventajas

● Requiere conocimiento de XMLSchema y WSDL


Web Services en JavaEE 6

● La plataforma JavaEE 6, incluye soporte para

web services, utilizando el protocolo SOAP, a

traves del API JAX-WS

● Java API for XML Web Services

● La implementacion de referencia se denomina

Metro, es desarrollada por Oracle y viene

incluida dentro del servidor de aplicaciones

GlassFish


Web Services en JavaEE6 y JDK6

● En el caso de Jboss, la implementacion de

referencia viene incluida en el componente

JBossWS, dentro del servidor de aplicaciones

JBoss 6

● A partir de la version 6 (update 4), la plataforma

Java estandar (JDK), incluye las APIs para

trabajar con JAX-WS y JAXB, fundamentales

para el consumo de web services


Definiendo un web service



● En el ejemplo anterior se intercambia un objeto

CreditCard entre el consumidor y el proveedor

del servicio

● Los datos intercambiados, deben ser un

documento XML, por lo que se necesita un

método para transformar el objeto Java en un

documento XML y viceversa

● Para esto utilizamos JAXB, anotándolo con

@javax.xml.bind.annotation.XmlRootElement


Invocando un web service

● Un ejemplo de posible cliente...


JAXB

● Si bien el intercambio de información

entre el consumidor y proveedor se hace

en base a XML, el codigo Java no tiene

porque interactuar con esto directamente

● JAXB provee un estándar para trabajar

con representaciones Java de

documentos XML y viceversa


La clase CreditCard


El documento XML


El schema XML


Binding


Marshalling/Unmarshalling


Anotaciones

● JAXB es similar a JPA, salvo que la

persistencia se realiza contra un documento

XML, en vez de una tabla de la base de datos

● El mapping al documento puede ser

customizado utilizando las anotaciones en el

paquete javax.xml.bind.annotation

● El equivalente de @Entity en JAXB, se

denomina @XmlRootElement


Anotaciones


El esquema asociado...


El documento obtenido


Web Services / Funcionamiento

● Si bien el programador Java no debe

preocuparse del manejo de los protocolos de

bajo nivel en web services, es conveniente

conocer que esta sucediendo por detras...


JAX-WS

● Como la mayoría de los componentes Java EE,

los web services utilizan el esquema de

configuración por excepción

● Solo necesitamos una anotación para

transformar un POJO en un web service,

@WebService

● Como en el caso de los EJBs, hay una serie de

requerimientos a la hora de escribir un

servicio...


JAX-WS

● La clase debe estar anotada con

@javax.jws.WebService

● Si el web service es implementado con un EJB,

entonces este solo puede ser stateless

● La clase debe ser publica, y no puede ser final ni

abstract

● La clase debe tener un constructor por defecto

● La clase no debe definir el método finalize

● El servicio debe ser stateless


JAX-WS

● Basta con que un POJO cumpla con los

requisitos anteriores, para que pueda ser

desplegado en un servlet container

● Esto se conoce como servlet endpoint

● Análogamente, un Stateless EJB puede ser

utilizado como clase de implementación del

servicio

● Esto se conoce como EJB endpoint


@WebService

● Esta anotación marca una clase o interfaz como un web

service

● Si se aplica directamente sobre la clase y no la interfaz,

entonces el container generara la interfaz a partir de los

métodos públicos


@WebMethod

● Por defecto, todos los métodos públicos del

web service (o de su interfaz) son incluidos

dentro de lo que se expone al exterior

● Para customizar la forma en como se hace esto

(por ejemplo para cambiar el nombre del

método), usamos la anotación @WebMethod,

aplicada sobre el método a modificar

● Por ejemplo...


@WebMethod


@WebResult

● Opera en conjunto con la anotación anterior

● Permite customizar el nombre del mensaje

devuelto como resultado de la operación


@WebParam

● Permite customizar los parámetros que son enviados al

servicio

● Podemos cambiar el nombre y el tipo de parámetro (IN,

OUT, INOUT)


@OneWay

● Es una anotación que permite indicar que un

método, no retorna valores

● Por ejemplo, los métodos que retornan void

● Esto permite que el container realice

optimizaciones con los métodos de este tipo,

por ejemplo, usando Asynchronous (solo en

EJB)


Ciclo de vida

● El ciclo de vida de los web services es similar al de los

stateless session beans

● No mantienen ningún estado, simplemente existen o no

existen

● Como en el caso de los stateless, podemos usar las

anotaciones @PreDestroy y @PostConstruct

● En el caso de un web service implementado como EJB,

se pueden utilizar interceptors


Ciclo de vida


Web Service Context

● Como en el caso de los EJBs, el web service

tiene un contexto que permite obtener

información útil del ambiente de ejecución del

servicio

● Se inyecta como en el caso de los EJB, usando

@Resource


Web Service Context

● GetMessageContext

● Permite acceder al mensaje SOAP, por ejemplo para

obtener los headers

● GetUserPrincipal

● Identifica a traves del Principal al emisor del

mensaje

● IsUserInRole

● Determina si un usuario autenticado esta presente

en un rol determinado



● Usando herramientas que generen stubs y clases Java

a partir del WSDL, podemos invocar un servicio web

● El JDK provee una herramienta, denominada wsimport

que genera las clases necesarias para poder realizar la

invocación a un determinado web service del que

conocemos su wsdl

● Las interfaces generadas se denominan SEI (Service

Endpoint Interfaces)



● Las interfaces y artefactos generados, deben

ser colocados en el proyecto que realizara el

consumo del servicio web

● Una vez colocados los artefactos (.java)

generados, podemos hacer la invocacion de

esta forma:


Generando los artefactos

● Usamos la herramienta wsimport

● Por ejemplo, en el practico tenemos este

ejemplo:

● wsimport -keep -d ../src

http://localhost:8080/WebService/CalculadoraSer

viceImpl/CalculadoraServiceImpl?wsdl

● keep permite mantener el codigo fuente generado

● -d ../src es la ruta donde se almacena dicho codigo


@WebServiceRef

● Permite inyectar una referencia a un servicio

web, indicando la localizacion del WSDL del

servicio

● Por ejemplo:

@WebServiceRef(wsdlLocation="http://localhost:8

080/app/CalculatorService?WSDL")

private CalculatorService service;

● Solo puede ser utilizado en componentes

managed (managed beans, ejbs, etc)

http://local/


REST

● La motivación para desarrollar REST fue la de crear un

modelo arquitectónico de como tiene que funcionar la

web, de forma que sirva de guía para los protocolos de

la web

● REST ha sido usado para describir la arquitectura de la

web, identificar problemas existentes, comparar

soluciones alternativas, y asegurarse que las

extensiones a los protocolos no violan las restricciones

centrales que hace a la web exitosa


REST

● Representational State Transfer

● Es un estilo arquitectónico para la

construcción de software

● REST fue desarrollado junto con el

protocolo HTTP/1.1, el cual se adhiere a

REST


Conceptos

● La arquitectura esta compuesta por clientes y

servidores

● Requests y Responses

● Los Requests y Responses son construidos en

base a la idea de transferir representaciones de

recursos

● Los clientes contienen representaciones

● Los servidores contienen los recursos en si


Conceptos


ROA

● REST es un estilo arquitectónico

● Una arquitectura que se adhiere a este

estilo, es ROA: Resource Oriented

Architecture

● Existen otras que pueden (en parte)

también adherirse a este estilo de trabajo


Ejemplos de ROA

● Las URLs apuntan a recursos

(sustantivos)

● Métodos universales para manejar los

recursos

● GET, POST, PUT, DELETE

● No se maneja estado en el servidor

● Se hace uso de cache


Definimos REST en base a...

● Recursos y URIs

● Representaciones

● Interfaces uniformes

● HATEOAS


... pero NO en base a ...

● Schemas (XSD)

● Lenguajes de descripción

● Generación de código

● Registros


REST/HTTP: Recursos

● Algo, una cosa con identidad

● Una persona, un perfil de Facebook, un usuario en

Twitter, una direccion, una imagen, un video en

Youtube

● Los recursos se nombran con URIs

● Las URIs son estables (no cambian tan seguido)


REST/HTTP: Recursos

● Podemos pensar que la URI es la PK del

recurso


URI

● Generalmente son opacas

● http://www.test.com/24985725

● Lo importante es que los clientes no tengan que

parsearla y entenderla

● Sin embargo, son opacas para las aplicaciones

cliente, pero no para los desarrolladores de clientes

● Una buena forma de organizar los recursos, es

usar un enfoque jerárquico

● http://example.com/movie/TheAvengers/review


Representaciones

● Son los elementos que se envían dentro de un

request, y que se reciben en un response

● Por ejemplo:


Media Types (MIME Types)

● Son el equivalente a la clase de un objeto, o el

schema de un documento XML


Negociacion

● Las representaciones son negociables


Negociacion

● La idea es no sobrecargar las URIs

● Le decimos a los intermediarios y clientes como

vamos a aceptar una representación


Interfaz uniforme


Como se describen las APIs


Un ejemplo:

● Una aplicación quiere transferir U$S1000

de una cuenta bancaria a la otra

● Que Recursos y URIs tendriamos?


Un ejemplo


Una transferencia...


... respuesta


Status


Es esto RESTful?

En realidad, son nombres de recursos


Es esto RESTful?

A través de GET, queremos hacer una operación de modificación

Debemos usar PUT


Es esto RESTful?

Estamos usando GET y POST como sinónimos, cuando no lo son


Es esto RESTful?

Estamos usando IDs internos de aplicación, cuando deberían utilizarse LINKS


Es esto RESTful?

Estamos escondiendo errores del intermediario o del cliente

Debemos usar los códigos de error de HTTP 4xx o 5xx


Web Service + REST

● Son web services desarrollados según la

filosofía de REST

● El énfasis esta en el uso de una comunicación

simple usando HTTP entre cliente y servidor,

intercambiando POX (Plain Old Xml)

● También pueden intercambiarse otros formatos

equivalente sencillos (JSON)

● Un ejemplo sencillo…


Web Service + REST

● Tenemos un servicio REST para obtener el

valor de un stock en el mercado

● Este seria el REQUEST


Web Service + REST

● Y esta seria la respuesta


Comparación

Sitios web, por el año 1992


Comparación

Servicios web WS-*, desde el año 2000


Comparación

Servicios web REST, desde el año 2006


Estandares


Servicio Web SOAP


Servicio web RESTful


Protocolos en SOAP


Protocolos en REST


JAX-RS

● Para escribir un servicio web que utilice REST,

solo se necesita un cliente y un servidor que

soporte HTTP

● Como en el caso de SOAP, a fin de eliminar el

trabajo con protocolos de bajo nivel, aparece el

API JAX-RS

● La implementación de referencia de esta API,

se denomina Jersey (es un proyecto open

source)


JAX-RS


JAX-RS

● En el ejemplo anterior, el recurso

BookResource esta publicado en la URI /book

● El método getBookTitle() queda asociado al

método GET HTTP, produciendo un contenido

de tipo “text/plain”

● Para acceder al recurso, solo debemos usar un

browser con la dirección

http://www.myserver.com/book


JAX-RS

● El servicio REST no implementa ninguna

interfaz ni extiende ninguna clase

● Debemos usar la anotación @Path

● Si queremos usar un EJB, entonces solo

podemos usar @Stateless

● La clase debe ser public, y no abstract ni final

● Debe contener un constructor por defecto

● La clase no debe incluir el método finalize()


Default Providers


Interfaz de acceso al recurso

● JAX-RS define una serie de anotaciones, para

indicar que método HTTP se utilizara para

acceder a un recurso

● Estas anotaciones corresponden a los métodos

HTTP disponibles

● @GET, @POST, @PUT, @DELETE, @HEAD,

@OPTIONS

● Solo los métodos públicos de una clase pueden

exponerse como métodos de recurso


Interfaz CRUD


Interfaz de acceso al recurso

● Cuando un método de recurso es invocado

● Los parámetros para los cuales hay un extractor, son

cargados con dicho valor

● Los valores de parámetros no anotados, llamados

entity parameters, es mapeado del cuerpo del

request, a través de un entity provider

● Los métodos pueden devolver void, un tipo Java o

un Response

● Response es usado cuando es necesario devolver

mas información (metadatos) en la respuesta


Información contextual


Manejo de excepciones


Ciclo de vida


HelloWorld

● Creamos una web application

● Para exponer recursos REST, necesitamos una

implementacion de REST

● Puede ser JAX-RS

● En el caso de JBoss, podemos usar RESTEasy

● Esta es una implementacion que ya viene

incorporada en el servidor 6.0

● Necesitamos que el web.xml sea version 3.0


HelloWorld

<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"> ... ... ... </web-app>


HelloWorld

● Creamos una clase HelloWorldResource

package ejemplos;

import javax.ws.rs.*;

@Path("tutorial")

public class HelloWorldResource {

@GET

@Path("hello")

public String helloworld() {

return "Hello World!";

}

}


HelloWorld

● Luego de creado el recurso, deployeamos

y ejecutamos la aplicación web

● Accedemos al recurso, a través de la URL

● http://localhost:8080/HelloWorld/tutorial/h

ello

● Deberíamos obtener “Hello World!!”

http://localhost:8080/HelloWorld/tutorial/hello





PathParam

● Permite extraer “pedazos” de la URL

package ejemplos;


@Path("tutorial")

public class HelloWorldPoliteResource {

@GET

@Path("sayhello/{name}")

public String helloworld(@PathParam("name")

final String name) {

return "Hi!, how are you " + name;

}

}


PathParam

● Como antes, se deployea y ejecuta la

aplicacion

● Debemos entrar a la URL:

● http://localhost:8080/HelloWorld/tutorial/sayhello/Pablo

● Deberíamos obtener: “Hi!, how are you Pablo”

http://localhost:8080/HelloWorld/tutorial/sayhello/Pablo

http://localhost:8080/HelloWorld/tutorial/sayhello/Pablo


Intercambio de XML

● Podemos intercambiar objetos XML, tanto

para el resultado como para los

parametros

● Para esto debemos usar providers JAXB

(idem SOAP), que se encarguen de

mapear instancias en documentos XML

● Por ejemplo, vamos a intercambiar

objetos Java, “Items”


package ejemplo;

@XmlRootElement

public class Item {

private String codigo;

private int precio;

public Item() {

}

public Item(String codigo, int precio) {

this.codigo = codigo;

this.precio = precio;

}

public String getCodigo() {

return codigo;

}

public void setCodigo(String codigo) {

this.codigo = codigo;

}

public int getPrecio() {

return precio;

}

public void setPrecio(int precio) {

this.precio = precio;

}

}


ItemResource

package ejemplo;


@Path("items")

public class ItemResource {

@GET

@Path("item")

@Produces({ "application/xml" })

public Item getItem() {

Item item = new Item("IPhone5", 1500);

return item;

}

}


ItemResource

● Si ejecutamos la aplicacion, al especificar

application/xml, se utilizara el provider

adecuado para obtener este XML

<item>

<description>IPhone5</description>

<price>1500</price>

</item>


@FormParam

● Esta anotacion sirve para extraer

informacion de un formulario

<html>

<body>

<form method="POST" action="login">

Email Address: <input type="text" name="email"><br>

Password: <input type="text" name="password"><br>

<br>

<input type="submit">

</form>

</body>

</html>


@FormParam

package ejemplos;

import javax.ws.rs.FormParam;

import javax.ws.rs.POST;

import javax.ws.rs.Path;

@Path("/")

public class LoginResource {

@Path("login")

@POST

public String login(

@FormParam("email") String email,

@FormParam("password") String password) {

return "Ingreso con el email: " + email +

" y el password " + password;

}

}


@QueryParam

● Es muy similar al anterior, solo que al

usarlo, se trata de extraer el valor el query

parameter con el nombre indicado

@Path("login/{id}")

public String loginQPM(@QueryParam("id") String idvalue) {

return "Id es " + idvalue;

}

http://localhost:8080/<Nombre de proyecto>/login?id=12345

http://localhost:8080/

tsi2 07-web-services

Education