Formación WS

Introducción a Servicios Web

TEMARIO

1. Introducción
a. Conceptos básicos de servicios web: Descripción de los estándares y arquitectura de
los servicios web
b. Protocolos basados en XML
i. Nociones básicas de XML-RPC
c. SOAP
i. Nociones básicas de Marshalling
ii. Procesamiento de errores y control de excepciones
iii. Streaming (transferencia de grandes volúmenes)
iv. Uso de interceptores
2. WSDL (Web Service Description Language). Puntos de entrada.
3. Solución basada en Apache CXF basado en anotaciones

P · 2.


TEMARIO

4. Invocación a servicios web: Herramientas y APIs para la creación y despliegues de
servicios web con java
5. Versionado de servicios web
6. Seguridad
a. Cifrado (HTTPS)
b. Identificación (WSS)
c. Identificación (User/Pass)
7. Servicios web RESTful

P · 3.


P · 4.


1.a. INTRODUCCIÓN - Conceptos básicos

“Los servicios web son a las máquinas lo que las páginas web son a los humanos”.

 El diálogo entre las dos partes se establece a
través de peticiones y respuestas
 El protocolo de transporte es HTTP
 Puede intercambiarse cualquier tipo de dato
 Textos
 Imágenes
 Ficheros
 Datos firmados
 Una transacción comienza con la petición y
termina con la respuesta

P · 5.


1.a. INTRODUCCIÓN - Conceptos básicos - Arquitectura

Un servicio web expone su estructura a través de un fichero WSDL
 Servicios disponibles
 Puertos disponibles
 Tipo de datos esperados
A través de esta información pueden generarse clientes capaces de enviar peticiones al servicio web y procesar
las respuestas del mismo.

P · 6.


1.a. INTRODUCCIÓN - Conceptos básicos - Arquitectura

Existen tres operaciones básicas que son realizadas en cualquier comunicación de servicios web:
 Serialización
 Convierte los datos representados en memoria (Java, .NET…) en lenguaje XML
 Construcción del Mensaje SOAP
 Construye una petición o una respuesta SOAP que incluye los datos serializados
 Deserialización
 Convierte los datos en lenguaje XML a datos en memoria (Java, .NET…)

P · 7.


1.a. INTRODUCCIÓN - Conceptos básicos - Estándares

Básicos
 SOAP
 WSDL (y XSD)
 XML
Mensajería
 MTOM
Interoperabilidad
 WS-i
Seguridad
 WS-Security (WSS)
Java
 JSR 101: JAX-RPC
 JSR 224: JAX-WS 2.0
 JSR 110: WSDL4J
 JSR 222: JAXB 2.0
http://www.ibm.com/developerworks/webservices/standards/

P · 8.


1.a. INTRODUCCIÓN - Conceptos básicos – Estándares

ESTÁNDARES INDUSTRIA

http://wsit.java.net/
Web Services Interoperability Technologies

http://msdn.microsoft.com/en-us/netframework/aa663324
Windows Communication Foundation

P · 9.



Básicos

 SOAP - Simple Object Access Protocol
 Define la estructura de los intercambios de información en XML entre los servicios web
 Cada mensaje SOAP incluye cero o más cabeceras y un cuerpo que incluye el “Payload”
 Los mensajes SOAP pueden contener errores en forma de SOAP FAULT
 http://www.w3.org/TR/soap12 - Versión 1.2
 http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ - Versión 1.1
 WSDL - Web Services Description Language
 Define la estructura de los servicios web publicados
 http://www.w3.org/TR/wsdl - Versión 1.1
 http://www.w3.org/TR/wsdl20 - Versión 2.0 (no utilizada actualmente)
 XSD - XML Schema
 Define los datos de los servicios web publicados como parte del WSDL
 http://www.w3.org/XML/Schema - Versión 1.1
 XML
 http://www.w3.org/XML/

P · 10.



Mensajería
 MTOM - SOAP Message Transmission Optimization Mechanism
 Define la estructura para la transmisión de ficheros a través de servicios web
 Engloba las dos especificaciones anteriores (SwA y DIME)
 http://www.w3.org/TR/soap12-mtom/
Interoperabilidad
 WS-i
 Web Services Interoperability (esta organización ha sido adquirida recientemente por OASIS)
 Es un conjunto de perfiles que definen reglas sobre el SOAP para garantizar la compatibilidad de los servicios web
entre diferentes tecnologías (.NET, Java, PHP…)
 WS-i Basic Profile
 Define las reglas para crear servicios web interoperables
 http://ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html
 WS-i Attachments Profile (adherido al WS-I Basic Profile a partir de la versión 1.1)
 Define las reglas para crear servicios web interoperables (con transmisión de ficheros)
 http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html

P · 11.



Seguridad
 WSS
 WS-Security
 Define extensiones SOAP que permiten la autenticación, integridad y confidencialidad de los datos
intercambiados por los servicios web a través de
 Múltiples formatos de tokens de seguridad
 Múltiples dominios de confianza
 Múltiples formatos de firma (XML)
 Múltiples técnicas de cifrado
 Seguridad de punto a punto sin confiar en la seguridad del transporte
 http://www.oasis-open.org/specs/index.php#wssv1.0

P · 12.



Java
 JSR 101: JAX-RPC
 Permite implementar el envío RPC de mensajes de acuerdo a la especificación SOAP 1.1
 http://java.net/projects/jax-rpc/
 JSR 224: JAX-WS 2.0
 Es una evolución de JAX-RPC, compatible con su predecesora, que soporta nuevas funcionalidades
(SOAP 1.2, WS-i Perfil Básico 1.1, MTOM,…)
 http://jax-ws.java.net/
 JSR 110: WSDL4J
 Permite la creación, representación y manipulación de documentos WSDL
 http://sourceforge.net/projects/wsdl4j/
 JSR 222: JAXB 2.0
 Java Architecture for XML Data Binding
 Permite mapear los objetos Java en estructuras XML de manera automática
 Se lo denomina “herramienta de marshalling”
 http://jaxb.java.net/

P · 13.


P · 14.


1.b. INTRODUCCIÓN - Protocolos basados en XML

XML-RPC
 Es un protocolo de intercambio de información con formato XML que utiliza HTTP como protocolo de
transporte (http://www.xmlrpc.com/)
 SOAP es la evolución del protocolo XML-RPC
 Permite hacer llamadas a procedimientos remotos usando XML como lenguaje común y HTTP como
protocolo de transporte.
 También permite usar otros protocolos de transporte (JMS, correo electrónico…)

P · 15.


1.b. INTRODUCCIÓN - Protocolos basados en XML

 SOAP es un protocolo mas completo que XML-RPC
 Inicialmente fue diseñado para evitar los problemas relativos a la apertura de puertos derivados de
tecnologías como RMI (SOAP puede funcionar por el puerto 80)

Característica XML-RPC SOAP
Escalares básicos V V
Estructuras V V
Arrays V V
Estructuras nombradas y arrays X V
Manejo de fallos V V
Encoding X V
Tipos de datos definidos por el usuario X V
Requiere entendimiento del cliente X V
Instrucciones de proceso específicas X V

P · 16.


P · 17.


1.c. INTRODUCCIÓN - SOAP

SOAP - Estructura
SOAP es un protocolo basado en XML que consta de tres partes
 ENVELOPE
 Envuelve a los HEADERs y al BODY
 Define la estructura que describe el contenido del mensaje y sus instrucciones de proceso
 HEADER
 Aparece cero o más veces en el mensaje
 Es utilizado para definir información de control
 BODY
 Aparece exactamente una vez en el mensaje
 Define los parámetros y sus valores

P · 18.



SOAP – Estilos de comunicación
 Document
 El parámetro de entrada de un servicio es cualquier documento XML
 La respuesta puede ser cualquier cosa o incluso ninguna cosa
 Este estilo de comunicación es requerido para garantizar interoperabilidad WS-i
 RPC
 Fue el primer estilo de comunicación definido, por lo que es muy utilizado en la actualidad
 SOAP gestiona las llamadas RPC a través de XML
SOAP – Encodings
 Encoded
 Permite marshalling/unmarshalling de valores para los tipos definidos en el modelo SOAP 1.1
 Literal
 Permite mensajes XML simples que no incluyen información de encoding
 Define los tipos empleados a través de un XML Schema (XSD)

P · 19.



SOAP – Modelos de mensaje
 Document/literal
 Debe utilizarse para la creación de cualquier servicio web nuevo
 Provee interoperabilidad WS-i
 RPC/literal
 No es muy usado en la práctica, ya que no permite (por ejemplo) el mapeo de Arrays
 RPC/encoded
 No provee interoperabilidad WS-i
 Las primeras implementaciones de servicios web en Java (por ejemplo http://axis.apache.org/axis/)
solo soportaban este modelo, por lo que todavía existen muchos servicios web generados de esta
manera
 Document/encoded
 No se usa en la práctica

P · 20.



RPC/encoded

Document/literal

P · 21.


1.c.i INTRODUCCIÓN - Marshalling

Se denomina Object/XML Mapping al proceso que convierte un documento XML a un objeto y viceversa. A este
proceso también se le denomina XML Marshalling o Serialización XML.
Actualmente se utilizan varios motores de marshalling de manera generalizada:
 JAXB (http://jaxb.java.net/) – Estándar de Java desarrollado por Oracle
 JIBX (http://jibx.sourceforge.net/) – Proyecto de código libre
 XMLBeans (http://xmlbeans.apache.org/) – Proyecto iniciado por Weblogic y cedido posteriormente a
Apache
 Castor (http://www.castor.org/) – Uno de los primeros proyectos de software libre para realizar
marshalling
 (!) Axis 1 (http://axis.apache.org/axis/) – Axis ya realizaba el proceso de marshalling a través de la
construcción de clases Java de conversión estáticas a partir del documento WSDL
La mayoría de ellos utilizan encoding UTF-8 por defecto para realizar sus transformaciones, ya que el “WS-I
Basic Profile 1.1” define que los documentos XML de un servicio web deben utilizar encoding UTF-8 o UTF-16.
Se puede configurar el proceso de marshalling de dos maneras:
 Generando las clases Java de conversión (estáticas o dinámicas) a partir de un documento XSD
 Utilizando anotaciones en los beans de Java para indicarle los campos que deben ser convertidos al
motor de marshalling

P · 22.


1.c.i INTRODUCCIÓN - Marshalling

<xs:element name="person">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string" />
<xs:any processContents="skip" maxOccurs="unbounded" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>

Esquema XSD

import org.w3c.dom.Element;

@XmlRootElement
class Person {
public String getName();
public void setName(String);

@XmlAnyElement
public List<Element> getAny();
}

Definición por anotaciones

P · 23.


1.c.ii INTRODUCCIÓN – Procesamiento de errores y control de excepciones

Cuando se produce un error de proceso o una excepción en el tratamiento de una petición a un servicio web,
aparece un bloque en el SOAP BODY denominado SOAP FAULT.
El elemento SOAP FAULT debe aparecer como una entrada del SOAP BODY y solo debe aparecer una vez.
Elementos de un SOAP FAULT
 Code o FaultCode
 Es un elemento obligatorio que contiene el tipo de error
 Puede contener los siguientes valores
 VersionMismatch - Cuando el nodo ENVELOPE no es el elemento raíz del mensaje SOAP o su
estructura no se ajusta a la especificación declarada
 MustUnderstand – Se produce cuando no se cumplen las restricciones o inclusiones relativas a
espacios de nombres declaradas en el HEADER
 DataEncodingUnknown – Es el código menos usual y solo aplica al modelo encoded. Se
produce cuando el valor de uno de los nodos del mensaje lleva un encoding diferente al
soportado
 Sender – Se ha producido un error de proceso de la petición en el servidor.
 Receiver – Se ha producido un error de proceso de la respuesta en el cliente bien debido a
valores no esperados o bien debido a estructura del mensaje no esperada

P · 24.



Elementos de un SOAP FAULT (cont.)
 Reason o FaultString
 Es un elemento obligatorio
 Incluye información textual sobre el error
 Node
 Es un elemento opcional
 Indica la URI del nodo del mensaje SOAP que ha provocado el error
 Role o FaultActor
 Indica la URI del nodo que se estaba procesando cuando se produjo el error
 Detail
 Incluye información adicional sobre el error específica para la aplicación

P · 25.



<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:m="http://www.example.org/timeouts"
xmlns:xml="http://www.w3.org/XML/1998/namespace">
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>m:MessageTimeout</env:Value>
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text xml:lang="en">Sender Timeout</env:Text>
</env:Reason>
<env:Detail><m:MaxTime>P5M</m:MaxTime></env:Detail>
</env:Fault>
</env:Body>
</env:Envelope>

P · 26.


1.c.iii INTRODUCCIÓN – Streaming

Message Transmission Optimizacion Mechanism (MTOM)
 http://www.w3.org/TR/soap12-mtom/
 Permite la transmisión de cadenas de datos binarias

MTOM encapsula los dos estándares anteriores
 SOAP Message with Attachments (SwA) - Java
 http://www.w3.org/TR/SOAP-attachments
 Direct Internet Message Encapsulation (DIME) - Microsoft
 http://bgp.potaroo.net/ietf/all-ids/draft-nielsen-dime-02.txt

MTOM es interoperable
 Cumple el profile de interoperabilidad 1.1 de WS-i

P · 27.


1.c.iii INTRODUCCIÓN – Streaming

El mecanismo se basa en la utilización de datos base64Binary definido en la especificación XSD 2
 http://www.w3.org/TR/2004/PER-xmlschema-2-20040318/#base64Binary
<soap:Body>
<tns:ByteEcho>
<tns:data>JVBERi0xLjYNJeLjz9MNCjE+DQpzdGFyNCjEx0YNCg==</tns:data>
</tns:ByteEcho>
</soap:Body>

Una vez detectada la cadena, el mecanismo MTOM se encarga de separar los datos en un contenedor MIME
utilizando el estándar XOP (http://www.w3.org/TR/xop10/)
<soap:Envelope>
<soap:Body>
<tns:ByteEcho>
<tns:data><xop:Include href="cid:1.633335845875937500@example.org"/></tns:data>
</tns:ByteEcho>
</soap:Body>
</soap:Envelope>
--MIMEBoundary000000
content-id: <1.633335845875937500@example.org>
content-type: application/octet-stream
content-transfer-encoding: binary

P · 28.


1.c.iv INTRODUCCIÓN – Uso de interceptores

Interceptores
 El uso de interceptores o manejadores en servicios web es análogo al uso de filtros en páginas web.
 Permiten aplicar reglas comunes a todos los servicios web de petición y respuesta gestionados por la
aplicación
 Requieren configuración XML para su lanzamiento y la implementación de un interface para modelar su
comportamiento

Interface de JAX-RPC
 http://download.oracle.com/javaee/1.4/api/javax/xml/rpc/handler/Handler.html

package javax.xml.rpc.handler;
public interface Handler{
public boolean handleRequest(javax.xml.rpc.handler.MessageContext context);
public boolean handleResponse(javax.xml.rpc.handler.MessageContext context);
public boolean handleFault(javax.xml.rpc.handler.MessageContext context);
public void destroy();
public void init(javax.xml.rpc.handler.HandlerInfo config);
public javax.xml.namespace.QName[] getHeaders();
}

P · 29.


1.c.iv INTRODUCCIÓN – Uso de interceptores

Interface de JAX-WS
 http://jax-ws.java.net/nonav/jaxws-api/2.2/javax/xml/ws/handler/Handler.html

package javax.xml.ws.handler;
public interface Handler<C extends javax.xml.ws.handler.MessageContext> {
public boolean handleMessage(C context);
public boolean handleFault(C context);
public void close(C context);
}

¿Para qué puede emplearse un interceptor?
 Escribir la traza de peticiones y respuestas SOAP
 Ejecutar validaciones comunes de datos
 Ejecutar acciones de identificación comunes
 Unificar el tratamiento de errores

P · 30.


P · 31.


2. WSDL - Puntos de entrada

Web Service Description Language (WSDL)
Estándar que permite describir el “contrato” de un servicio web
 Información que contienen las peticiones y respuestas a un servicio web
 Cómo se trasmite el servicio a través de protocolo particular (por ejemplo SOAP sobre HTTP)
 La ubicación o punto de entrada del servicio web

P · 32.



WSDL Definition (<wsdl:definitions>)
 Documento XML que compone una descripción WSDL
 Incluye los espacios de nombres utilizados por los diferentes elementos del documento
 Se recomiendo utilizar un espacio de nombres significativo para los elementos definidos por la
propia aplicación
 targetNamespace=http://censo.servicios.zaragoza.es

Tipos (<wsdl:types>)
 Define los tipos de datos que van a ser utilizados por los métodos del servicio web
 Se describen a través de Esquemas XML (XSD - http://www.w3.org/XML/Schema)

Mensajes (<wsdl:message>)
 Cada mensaje está identificado por un nombre
 Contiene una o más partes que hacen referencia a alguno de los tipos definidos

P · 33.



Tipo de Puertos (<wsdl:portType>)
 Un puerto incluye una serie de operaciones
 Cada operación puede contener tres tipos de mensaje
 Input
 Output
 Fault

Mapeos (<wsdl:binding>)
 Son una instanciación de un puerto
 Definen el protocolo y el puerto de entrada de cada una de las operaciones
 Cada operación tiene un estilo (document/rpc) y un encoding (literal/encoded)

Servicios (<wsdl:service>)
 Define la ubicación de los puertos mapeados
 Contiene una o más partes que hacen referencia a alguno de los tipos definidos

P · 34.



P · 35.



P · 36.


P · 37.


3. SOLUCIÓN - CXF con anotaciones

Enfoques de diseño

Enfoque Ventajas Desventajas
Java first • Requiere menos conocimiento de • Propensa a problemas de
WSDL, XML, WS-i… interoperabilidad
• Mejor soportada por las • Más sensible a los cambios
herramientas de desarrollo • Menos control sobre el WSDL
• Más natural para desarrolladores
Java
WSDL first • Facilita la interoperabilidad • Requiere más conocimiento de
• Menos sensible a los cambios WSDL, XML, WS-i…
(versionado) • No están soportadas por un
• Permite mayor control sobre el entorno de desarrollo propio
WSDL • Tiempos de desarrollo más
elevados

P · 38.



¿Por qué se ha elegido CXF?
 Es la propuesta de Apache como sustituto a la familia Axis
 Es uno de los frameworks de servicios web más utilizados
 Da soporte a todos los estándares
 Permite múltiples protocolos de transporte

Tendencias
 AXIS 2 – Herencia de AXIS 1 http://axis.apache.org/axis2/java/core/
 Spring WS – Modelar a partir del contrato http://static.springsource.org/spring-ws/sites/2.0/
 CXF – Modelar a partir de los datos http://cxf.apache.org/
 Metro - Implementación de referencia http://metro.java.net/

* Más información en http://wiki.apache.org/ws/StackComparison

P · 39.



Características de Apache CXF (http://cxf.apache.org/)
 Estándares soportados
 SOAP 1.1, 1.2
 WSDL 1.1
 WS-I BasicProfile 1.1
 WS-Security 1.0, 1.1
 Especificaciones implementadas
 JAXB 2.x
 JAX-WS 2.x
 Requisitos
 Java 5 o superior (aunque puede funcionar en Java 1.4 con http://retrotranslator.sourceforge.net/)
 Herramientas
 Integración nativa con Spring 2 o superior
 Soporte a múltiples marshallers (JAXB, XmlBeans, Aegis, SDO)
 Publicación automática de WSDL
 Generación de servicios a partir de XSD o WSDL

P · 40.



Anotaciones
 Están disponibles a partir de Java 5
 Permiten asociar comportamientos a atributos y métodos de las clases java
 http://download.oracle.com/javase/1.5.0/docs/guide/language/annotations.html
Anotaciones utilizadas por CXF
 Descripción del servicio
 Utiliza anotaciones estándar de JAX-WS
 @WebService, @WebMethod, @WebParam, @WebResult…
 http://jax-ws.java.net/jax-ws-ea3/docs/annotations.html
 Descripción del mapeo de datos
 Utiliza anotaciones estándar de JAXB
 @XmlElement, @XmlAttribute, @XmlType, @XmlValue…
 http://download.oracle.com/javaee/5/api/javax/xml/bind/annotation/package-summary.html
Integración con Spring
 Utiliza las características de inyección de beans a través de descriptores XML
 http://static.springsource.org/spring/docs/2.0.x/reference/beans.html

P · 41.



Paso 1. Definir el servicio web
// Utilizando anotaciones de JAX-WS
@WebService
public interface CensoService {
Persona getPersona(@WebParam(name=“nif”) String nif);
}
Paso 2. Implementar el servicio web
// Anotación de JAX-WS
@WebService( endpointInterface = “CensoService” )
public class CensoServiceImpl implements CensoService {
Persona getPersona(String nif) {
…
}
…
}

P · 42.



Paso 3. Definir los beans de intercambio de datos
// Utilizando anotaciones de JAXB
@XmlRootElement
public class Persona {
private String nif;
private String nombre;

public String getNif() { … }
public void setNif(String nif) { … }
public String getNombre() { … }
public void setNombre(String nombre) { … }
…
}

P · 43.



Paso 4. Definir las opciones de publicación del servicio web (cxf.xml)
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jaxws="http://cxf.apache.org/jaxws"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">

<!–- Utilizando el espacio de nombres de JAX-WS -->
<jaxws:endpoint id=“censo”
implementor=“CensoServiceImpl”
address="/CensoWS">
</jaxws:endpoint>

</beans>

P · 44.



Paso 5. Dar de alta el punto de entrada en el descriptor web
<web-app>
<!–- Añadir la configuración de CXF a través de Spring -->
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:cxf.xml</param-value>
</context-param>
<!–- Listener de SPRING -->
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<!–- Servlet de CXF -->
<servlet>
<servlet-name>CXFServlet</servlet-name>
<servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>
</servlet>
<servlet-mapping>
<url-pattern>/services/*</url-pattern>
</servlet-mapping>
</web-app>

P · 45.



¡El servicio web ya está disponible!

P · 46.



Interceptores
 http://cxf.apache.org/docs/interceptors.html
 Utiliza los interceptores por defecto de JAX-WS en sus cuatro cadenas de procesamiento
 inInterceptors - Permite realizar operaciones sobre los SOAP de entrada
 outInterceptors – Permite realizar operaciones sobre los SOAP de salida
 inFaultInterceptors – Permite realizar operaciones sobre SOAP FAULT de entrada
 outFaultInterceptors – Permite realizar operaciones sobre SOAP FAULT de salida

// Utilizando inyección de Spring
<jaxws:endpoint id=“censo”
implementor=“CensoServiceImpl”
address="/CensoWS"> // Utilizando anotaciones de JAX-WS
<jaxws:inInterceptors> @WebService
<bean class=“MyInterceptor”/> @InInterceptors (interceptors={“MyInterceptor"})
</jaxws:inInterceptors> public interface CensoService {
</jaxws:endpoint> }

P · 47.



Interceptores – Fases

P · 48.



Interceptores

public class MyInterceptor extends AbstractPhaseInterceptor<Message> {

public MyInterceptor() {
super(Phase.RECEIVE);
}

public void handleMessage(Message message) {
String encoding = (String) message.get(Message.ENCODING);
if (encoding.toLowerCase().indexOf("utf-8") == -1) {
throw new Fault("Encoding " + encoding + " no soportado. Use UTF-8");
}
}

public void handleFault(Message messageParam) {
}
}

P · 49.


P · 50.


4. INVOCACIÓN a SERVICIOS WEB

La invocación a un servicio web puede construirse de diferentes maneras:
 Utilizando un software específico
 Recomendable para la realización de pruebas
 El más utilizado es denominado SOAP UI (http://www.soapui.org/)
 Creando un cliente Java a partir del fichero WSDL
 Casi todos los frameworks de servicio web disponen de una herramienta para crear clientes Java
 En el caso de CXF la herramienta es denominada wsdl2java (http://cxf.apache.org/docs/wsdl-to-
java.html)
 Estas herramientas pueden integrarse con scripts de Ant
 Creación de clientes con Apache CXF
 En caso de que se haya creado el servicio web con CXF y se desee proveer un cliente de
referencia, puede empaquetarse el interface del servicio web junto con los beans de parámetros
 El cliente puede realizar la invocación al servicio a través de las clase base de JAX-WS
JaxWsProxyFactoryBean

(*) Herramientas adicionales http://cxf.apache.org/docs/tools.html

P · 51.



SOAP UI

P · 52.



Generación a partir del WSDL

Ficheros generados

 Peticion.java
 Bean JAXB que representa los datos de
la petición
 Respuesta.java
 Bean JAXB que representa los datos de
la respuesta
 Servicio.xsd
 Esquema XML que define los
elementos de petición y respuesta
 Servicio.wsdl
 Documento WSDL del servicio

P · 53.



Cliente CXF
import org.apache.cxf.interceptor.LoggingInInterceptor;
import org.apache.cxf.interceptor.LoggingOutInterceptor;
import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;

public final class Client {
private static String URL = "http://localhost:8080/sampleCXF/services/CensoWS";
public static void main(String args[]) throws Exception {

JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();

factory.getInInterceptors().add(new LoggingInInterceptor());
factory.getOutInterceptors().add(new LoggingOutInterceptor());
factory.setServiceClass(CensoService.class);
factory.setAddress(URL);
CensoService client = (CensoService) factory.create();

Persona response = client.getPersona("88888888Y");
System.out.println(response.getNif() + " - " + response.getNombre());

}
}

P · 54.


P · 55.


5. VERSIONADO DE SERVICIOS WEB

 Es un problema que no está resuelto en las arquitecturas de servicios web, aunque el borrador de la
especificación de WSDL 2.0 (http://www.w3.org/TR/wsdl20/) ya incluye directrices de diseño
 Debe ser resuelto aplicando patrones de diseño y manuales de buenas maneras

Condiciones de compatibilidad genéricas
 Compatibilidad hacia atrás (versionado menor)
 Añadir nuevas operaciones (WSDL)
 Añadir nuevos valores (XSD)
 Incompatibilidad hacia atrás (versionado mayor)
 Eliminar operaciones (WSDL)
 Renombrar operaciones (WSDL)
 Cambio de los parámetros (el orden o el tipo) de una operación
 Cambio en la estructura de un tipo de datos complejo

P · 56.



Versionado menor

Servicio Censo 1.0

@WebService
Persona getPersona(@WebParam(name="nif") String nif);
}

private String nif;
…
}

P · 57.



Versionado menor

Servicio Censo 1.1

@WebService
Persona getPersona(@WebParam(name="nif") String nif);
Empresa getEmpresa(@WebParam(name="cif") String cif);
}

private String nif;
private String direccion;
…
}

P · 58.



Versionado mayor

Servicio Censo 2.0

@WebService
public interface CensoServiceV2 {
Persona getPersona(@WebParam(name="persona") Persona persona);
Empresa getEmpresa(@WebParam(name="empresa") Empresa empresa);
}

Es necesario añadir un nuevo punto de entrada
 http://localhost:8888/cxfMTOM/services/CensoWS Servicio en versión 1.X
 http://localhost:8888/cxfMTOM/services/CensoV2WS Servicio en versión 2.X

P · 59.


P · 60.


6. SEGURIDAD – Cifrado (HTTPS)

Capa de transporte
Los servicios web pueden ser invocados a través de diferentes capas de transporte
 HTTP
 JMS
 Local
 Email
Configuración de medios de transporte en CXF - http://cxf.apache.org/docs/transports.html

Seguridad en la capa transporte (HTTPS)
 No es necesaria ninguna configuración adicional para los servicios web
 El cifrado de datos se aplica a través de la capa de transporte HTTP
 Requiere un certificado privado en el servidor y un certificado público en el cliente

P · 61.


6. SEGURIDAD – Identificación y no repudio (WSS)

WS-Security
 Especificación que define la seguridad de los servicios web a nivel de mensaje
 http://docs.oasis-open.org/wss/v1.1/
 Soporta los mecanismos básicos de seguridad
 Autenticación: SAML, Username Token, XML Signature (JSR-105)
 Autorización: J2EE security, SAML Assertions
 Confidencialidad: XML Encryption (JSR-106)
 Integridad: XML Signature (JSR-105)
 No repudio: XML Signature (JSR-105)

P · 62.



Frameworks
 Axis2
 Basado en Apache Rampart
 http://axis.apache.org/axis2/java/rampart/
 Spring WS
 Independiente del motor de WSS
 http://static.springsource.org/spring-ws/sites/2.0/reference/html/security.html
 CXF
 Basado en WSS4j
 http://ws.apache.org/wss4j/
 Metro (Glassfish)
 Basado en XWSS
 http://xwss.java.net/

http://www.ibm.com/developerworks/webservices/library/j-jws14/index.html?ca=drs-

P · 63.



Frameworks – Interoperabilidad

Existen ciertas partes del estándar WSS que no están cubiertas por las primeras versiones de WSS4J
 WSS4j no soporta InclusiveNamespaces en la canonicalización de los métodos de XMLDSig (opcional en
el estándar WSS)
 WSS4j no soporta Timestamp firmado (opcional en el estándar WSS)

Configuración de XWSS para garantizar la compatibilidad con WSS4j

<xwss:Sign includeTimestamp="false">
<xwss:CanonicalizationMethod disableInclusivePrefix="true" />
<xwss:SignatureTarget type="qname" value="SOAP-BODY">
<xwss:Transform algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" disableInclusivePrefix="true"/>
</xwss:SignatureTarget>
</xwss:Sign>

P · 64.



WSS en CXF

 Debe definirse a través de los interceptores de WSS4j
<jaxws:inInterceptors>
<bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor"/>
<bean class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor"/>
</jaxws:inInterceptors>

 Para utilizar la firma WSS debe implementarse la clase abstracta provista por CXF
(AbstractWSS4JInterceptor)
 Mensajes de entrada (InInterceptor)
 Verificar el mensaje SOAP
 Mensajes de salida (OutInterceptor)
 Firmar el mensaje SOAP

P · 65.


P · 66.

Servicios Web REST

Representational State Transfer (REST)

WS- listEntries()
addEntry() collection Único endpoint que procesa
todas las operaciones a través
getEntry()
service de un interface específico

deleteEntry()
updateEntry()

RESTful listEntries()
addEntry()
collection
Conjunto de "recursos" con
operaciones asociadas a la
colección y al recurso
getEntry()
deleteEntry()
updateEntry() entry

P · 67.

Servicios Web REST

Estándares

JAX-RS (JSR-311) es la JCP que provee la API Java para servicios web RESTful sobre protocolo HTTP
 http://jsr311.java.net/

XML, eXtensible Markup Language, es un metalenguaje extensible de etiquetas desarrollado por el (W3C)
 http://www.w3.org/XML/
<user>
<username>john</username>
<password>password</password>
<link>/users/john</link>
</user>

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.
 http://www.json.org/
{"user":{"username":"john", "password":"password", "link":"/users/john"}

P · 68.

Servicios Web REST

Un ejemplo con CXF

Paso 1. Definir el servicio web
// Utilizando anotaciones de JAX-RS
@Path("/")
@Produces("application/xml")
@GET
@Path("/personas")
Personas getPersonas();
}
Paso 2. Implementar el servicio web
public class CensoServiceImpl implements CensoService {
public Personas getPersonas() {
…
}
…
}

P · 69.

Servicios Web REST

Un ejemplo con CXF

Paso 3. Definir los recursos
// Utilizando anotaciones de JAXB
@XmlRootElement(name="persona")
private Integer id;
}
@XmlRootElement(name="personas")
public class Personas {
private Collection<Persona> personas;
@XmlElement(name="persona")
@XmlElementWrapper(name="personas")
public Collection<Persona> getPersonas() {
return personas;
}
}

P · 70.

Servicios Web REST

Un ejemplo con CXF

Paso 4. Definir las opciones de publicación del servicio web (cxf.xml)
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jaxrs="http://cxf.apache.org/jaxrs"
xsi:schemaLocation=“http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/jaxrs.xsd">

<!–- Utilizando el espacio de nombres de JAX-RS -->
<jaxrs:server id="service" address="/">
<jaxrs:serviceBeans>
<bean id="serviceImpl" class=“CensoServiceImpl”/>
</jaxrs:serviceBeans>
<jaxrs:extensionMappings>
<entry key="xml" value="application/xml" />
</jaxrs:extensionMappings>
</jaxrs:server>
</beans>

P · 71.

Servicios Web REST

Un ejemplo con CXF

Paso 5. Dar de alta el punto de entrada en el descriptor web
<web-app>
<!–- Añadir la configuración de CXF a través de Spring -->
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:cxf.xml</param-value>
</context-param>
<!–- Listener de SPRING -->
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<!–- Servlet de CXF -->
<servlet>
<servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>
</servlet>
<servlet-mapping>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>

P · 72.

Servicios Web REST

Un ejemplo con CXF

El servicio web ya está disponible

P · 73.

Servicios Web REST

Uso de servicios web RESTful

Suelen usarse junto con AJAX

Escenarios adecuados
 Cuando los recursos van a estar disponibles para un grupo de usuarios desconocidos potencialmente
grande.
 Cuando el propósito de la aplicación es mandar información.
 Cuando está previsto que la aplicación crezca continuamente.
 Cuando el uso de recursos hardware (CPU, memoria, ancho de banda…) no es determinante.
 Cuando la gestión del estado de la aplicación es simple.

Escenarios desaconsejados
 Situaciones donde la seguridad de los datos es determinante
 Cuando el propósito principal de la aplicación es recibir y procesar grandes cantidades de información.
 Cuando el uso de los recursos hardware es determinante.
 Cuando la gestión del estado de la aplicación no es trivial

P · 74.


P · 75.


REFERENCIAS

 “The Java Web Services Tutorial”
 http://download.oracle.com/docs/cd/E17802_01/webservices/webservices/docs/2.0/tutorial/doc/
 “JAX-WS 2.2 Specification”
 http://jcp.org/aboutJava/communityprocess/mrel/jsr224/index3.html
 “Developing Apache CXF Interceptors”
 http://fusesource.com/docs/esb/4.2/cxf_interceptors/cxf_interceptors.pdf
 “Configuring Web Service Endpoints”
 http://fusesource.com/docs/esb/4.2/deploy_service/deploy_service.pdf
 “CXF for the enterprise and web”
 http://netzooid.com/presentations/cxf-apachecon-us-07.ppt
 “Understanding and modelling WSDL 1.1”
 http://www.ibm.com/developerworks/webservices/library/j-jws20/index.html
 “Web Services Handbook for WebSphere Application Server Version 6.1”
 www.redbooks.ibm.com/redbooks/pdfs/sg247257.pdf
 “Java Enterprise Edition 5 Web Services Developer Certified Professional Exam”
 http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=41&p_exam_id=1Z0_862

P · 76.

Formación WS

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Formación WS

Más de Angel Borroy López

Formación WS