Este documento describe las diferencias entre JAX-WS y JAX-RS, los estándares para crear web services y web services REST en Java. Explica que JAX-WS se usa para crear web services SOAP tradicionales mientras que JAX-RS se usa para crear servicios RESTful. También proporciona detalles sobre las implementaciones más populares de cada estándar como Apache CXF, Glassfish Metro y Jersey.

1. WebServices con JAX-WS, RS
 Haga clic para agregar texto

2. Que es JAX-WS JAX-RS
 Son los estándares java para el manejo de web
services y web services REST
 Existen varias implementaciones del estándar como
JAX-WS:
 Apache CFX
 Glassfish Metro
 Apache Axis2
 También varias de JAX-RS:
 Apache CFX
 Jersey
 RESTEasy
 Restlet

3. Diferencias
31/10/10

4. Estándares WS
 Los web services se guían por estándares liberados por
OASIS(Organization for the Advancement of Structured
Information Standards)
 Define servicios como:
 WS-Addressing
 WS-Coordination
 WS-MetadataExchange
 WS-Policy
 WS-ReliableMessaging
 Web Services Security
 WS-SercureConversation
 WS-SecurityPolicy
 WS-Transaction
 WS-Trust
 WS-Federation

5. Consideraciones
 Las implementaciones difieren entre los estadares
WS soportados.
 No todos los IDEs se integran fácilmente con cada
implementación.
 No todas las implementaciones son interoperables
con otros clientes o servidores.
 La compatibilidad con JDK 1.4 no esta asegurada en
algunas versiones.

6. Implementando un WebService
Existen dos aproximaciones para crear un web
service.
 Desde el WSDL: este aproximación se basa en el
archivo WSDL para generar las clases JAVA
necesarias para su implementación, estas clases
son un esqueleto con las anotaciones necesarias
para implementar el web service.
 Desde la Clase JAVA: esta aproximación creamos
la clase debidamente anotada junto con la
funcionalidad implementada y desde la cual se
genera el WSDL para que el web service sea
consumido.

7. Creando un web service
 Crear un web service con JAX-WS consta de
realizar las anotaciones necesarias sobre la clase y
sus métodos para publicarlas.
 Se debe agregar disponibilidad del archivo wsdl de
descripción del archivo.
 Con estos dos elementos es posible desplegar el
web service en cualquier contenedor servidor JEE o
Servlet container.

8. Visión general de un Web service

9. Resultado del despliegue

10. Como funciona
 La implementación de JAX-WS incorpora las
herramientas necesarias para convertir la clase
anotada en su respectivo wsdl y clases asociadas al
request y la response.
– WSDL to Java, WSDL to JavaScript, Java to
JavaScript
– Java to WSDL,XSD to WSDL, WSDL to XML, IDL
to WSDL
– SDL to SOAP, WSDL to CORBA, WSDL to
service
– WSDL to IDL
– WSDL Validation

11. Probando nuestro web service
 Eclipse contiene varias herramientas para probar los
web services, en este caso se usara Jboss web
service tester.

12. Anotaciones disponibles
Anotación Descripción
@WebService Marca la clase como la implementación de un web
service
@WebMethod Marca un método de la clase como operación del
endpoint
@OneWay Marca el método como una operación de una sola
vía
@WebParam Se usa para marcar los parámetros del método
como accesibles
@WebResult Mapea el resultado de una operación a un wsdl o
xml
@HandlerChain Anotación para especificar un manejador externo.
Por ejemplo un filtro para autenticar el webservice
@SOAPBinding Establece la configuración del encoding del web
service.
@RequestWrapper Establece la clase la cual contendrá el request
durante una petición

13. Anotaciones disponibles
Anotación Descripción
@ResponseWrapper Encapsula la respuesta de un webmethod en una
clase especificada
@ServiceMode Establece si la implementacion JAX-WS procesara
todo el mensaje o solo los PayLoads(la parte que
esta al rededor del mensaje), por ejemplo validar
todo el mensaje, o solo la parte SOAP
@WebEndpoint Se usa para sobre escribir los metodo getPort
@WebFault Establece excepciones para las operaciones
@WebServiceClient Establece la configuracion de un cliente para uin
servicio web
@WebServiceProvider Establece como clase que implementa un archivo
wsdl
@XmlRootElement Mapea una clase a el root element de un archivo
xml
@XmlAccessorType Establece si son las atributos o metodos se
serualizan por defecrto

14. Anotaciones disponibles
Anotación Descripción
@XmlType Mapea una clase a los atributos de un
archivo xml
@XmlElement Mapea un atributo a un valor en un
archivo xml
@Resource Es una anotación común utilizada
para inyectar el webcontext
@PostConstruct Es una anotación común que indica un
método que debe ejecutarse
inmediatamente despues de la
inizialicacion
@PreDestruct Es una anotación común que indica un
método que debe ejecutarse
inmediatamente antes de la destruccion

15. Requerimientos para crear un WS
 La clase o la interface que implementa deben estar
tener sus respectivas anotaciones
 Los métodos publicados no deben ser static o final
 Lo métodos expuestos como webservices deben
ser anotados con @webmethod
 Los parámetros deben ser compatibles con las
librerías JAXB (Java Architecture for XML Binding).
Definir un xml con los datos para construir los
objetos en tiempo de ejecución a partir de este xml
 La clase implementación, marcada como
@webservice no deben ser final o abstract
31/10/10

16. Requerimientos para crear un WS
 La implementación debe tener un constructor por
defecto sin parámetros
 La clase no debe tener implementación del método
finalize
 Se tienen disponibles los métodos @PreDestroy y
@PostConstruct para los eventos de su ciclo de
vida
31/10/10

17. Que se debe considerar al desarrollar
un web service
 Los web services son un buen método de
integración, pero son mas dificiles de mantener en
un entorno donde proliferan.
 Según el servidor de aplicaciones que utilicemos se
recomienda utilizar la implementación Jax-WS que
mejor se integren por ejemplo JBossAS con
JBossWS o GlassFish con Metro
 En algunos casos los web services pueden llegar a
ser pesados ya que deben serializar y deserializar
los datos en XML, validar estas serializaciones y
encapsular los datos, no se debe delegar sobre
ellos lógica de negocio de uso continuo.

18. Que se debe considerar al desarrollar
un web service
 Se debe controlar la proliferación de webservices
llevando una buena política de gobierno sobre su
implementación uso y responsabilidades. Se deben
catalogar su uso, ubicaciones y funcionalidad para
evitar funcionalidad repetida o funcionalidad oculta.
31/10/10

19. WebServices con Restful

20. Introducción
31/10/10

21. Introducción
31/10/10

22. Que es un web service restful
(Representational State Transfer)
 Especificación jsr-311 donde se define una Api
para desarrollar web services Restful sobre http
 Permite realizar intercambio de información a
través de los métodos http (get,put,post,etc..)
 Los métodos http se muestran como una manera
excelente de interactuar con entidades y sus
operaciones CRUD
31/10/10

23. Visión general de servicios REST
31/10/10

24. Anotaciones disponibles
Anotación Descripción
@Path url donde respondera el webservice
@Get Método que responderá a peticiones Get
@Post Método que responderá a peticiones Post
@Put Método que responderá a peticiones Put
@Delete Método que responderá a peticiones Delete
@Head Método que responderá a peticiones Head
@PathParam Representa un parametro extraido de el request de
la url

25. Anotaciones disponibles
Anotación Descripción
@QueryParam Representa un parametro extraido de el query
reuest
@Consumes Representa los tipos mimes que recibe el web
service
@Produces Representa los tipos mimes que envía el web
service
@Provider Representa configuraciones que representan
configuraciones como el proveedor
MessageBodyReader o MessageBodyWriter

26. Webservice REST y parámetros
31/10/10

27. Parámetros por PathParam
 Los parámetros por PathParam son representados
en la url como:
 http://localhost/ helloservice /{name}
 Los parámetros recibidos se pueden restringir de
acuerdo a una expresión regula dada.
 @Path(" helloservice /{name: [a-zA-Z][a-zA-Z_0-9]}")
 En caso de no cumplir con la expresión regular el
servidor responderá con error 404
31/10/10

28. QueryParam
 Los parámetros pasados como QueryParam son
parámetros representados por la url en formato del
método GET
http://localhost/ helloservice &param1=valor1?param2=valor2
 http://localhost/myservice?usuario=juan&edad=18
@GET
@Produces("text/plain")
public String sayHello(@DefaultValue(“juan")
@QueryParam("name") String name) {
return "Hello World! “+name;
}
31/10/10

29. Parámetros
 Los parámetros tienen restricciones de tipo como
 Solo tipos primitivos excepto char
 Wrapper de tipos primitivos
 Cualquier calse con un constructor que solo reciba un
String
 Cualquier clase que tenga un metodo statico
valueOf(String)
 List, Set, SortedSet donde los tipos contenidos
cumplan con las validaciones anteriores
 En caso de no cumplir con las restricciones el
servidor respondera BadRequest
31/10/10

30. Respuestas de Webservice REST
 Los métodos web service REST pueden generar
varios tipos de respuesta, cualquier tipo MIME
 Esta implementaciones se seleccionan de acuerdo
a los parámetros que acepte el cliente, así si el
servidor envía respuestas XML o PLAIN el cliente
puede seleccionar cualquiera de las dos en sus
llamadas al método.
31/10/10

31. URL
 La url de un webservice REST se generan a partir
de sus parámetros @Path o la concatenación de
ellos
31/10/10

32. REST soporta tipos Wrapper
 Las respuestas de los web services REST se
representan en texto plano o algún formato de texto
plano así que no se puede manejar de una manera
tan transparente como los webservice SOAP
 Gracias a la JAXB (Java Architecture for XML
Binding). podemos utilizar tipos complejos como
clases java para el paso de datos entre los clientes
y los WebServices, pero esto no es automático
como en los WebServices SOAP
31/10/10

33. Clientes REST
 Los clientes REST no son autogenerados, por lo
tanto podemos hacer uso de la librería jersey Client
 Si no se desea utilizar este enfoque, se debera
codificar a mano por medio de los objetos Java
httpRequest y httpResponse
31/10/10

34. Jersey Client
import com.sun.jersey.api.client.Client;
Client client = Client.create();
WebResource webResource =
client.resource("http://example.com/base");
31/10/10

35. Jersey client y GET
String s = webResource.get(String.class);
MultivaluedMap queryParams = new
MultivaluedMapImpl(); queryParams.add("param1",
"val1"); queryParams.add("param2", "val2");
String s =
webResource.queryParams(queryParams).get(Strin
g.class);
31/10/10

36. Enviando datos encapsulados
ClientResponse response =
webResource.accept("text/plain").get(ClientRespon
se.class);
int status = response.getStatus();
String textEntity = response.getEntity(String.class);
31/10/10

37. Jersey Clien y Put
ClientResponse response =
webResource.type("text/plain").put(ClientResponse.
class, "foo:bar");
MultivaluedMap queryParams = new
MultivaluedMapImpl(); queryParams.add("param1",
"val1"); queryParams.add("param2", "val2");
ClientResponse response =
webResource.queryParams(queryParams).put(Clie
ntResponse.class, "foo:bar");
31/10/10

38. WebServices y su entorno
 Los diferentes infraestructuras para las
aplicaciones java hacen que la implementacion de
los webservices ya sean SOAP o REST cambien
en su desarrollo
 En servidores full JEE la configuracion es minima
sobre el entorno, asi que es implementar y desplegar,
pero su uso de memoria es mayor
 En servidores mas pequeños (servlet o jsp containers)
su uso de memoria es menor, pero es necesario
configuraciones especificas para el correcto
funcionamiento del proveedor de webservices.
31/10/10

39. Web.xml
31/10/10