Java WebServices JaxWS - JaxRs

8,578
-1

Published on

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
8,578
On Slideshare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
0
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Java WebServices JaxWS - JaxRs

  1. 1. WebServices con JAX-WS, RS Haga clic para agregar texto
  2. 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. 3. Diferencias 31/10/10
  4. 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. 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. 6. Implementando un WebServiceExisten 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. 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. 8. Visión general de un Web service
  9. 9. Resultado del despliegue
  10. 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. 11. Probando nuestro web service Eclipse contiene varias herramientas para probar los web services, en este caso se usara Jboss web service tester.
  12. 12. Anotaciones disponiblesAnotació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. 13. Anotaciones disponiblesAnotació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. 14. Anotaciones disponiblesAnotació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. 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. 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. 17. Que se debe considerar al desarrollarun 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. 18. Que se debe considerar al desarrollarun 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. 19. WebServices con Restful
  20. 20. Introducción 31/10/10
  21. 21. Introducción 31/10/10
  22. 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. 23. Visión general de servicios REST 31/10/10
  24. 24. Anotaciones disponiblesAnotació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. 25. Anotaciones disponiblesAnotació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. 26. Webservice REST y parámetros 31/10/10
  27. 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. 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. 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. 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. 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. 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. 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. 34. Jersey Clientimport com.sun.jersey.api.client.Client;Client client = Client.create();WebResource webResource = client.resource("http://example.com/base"); 31/10/10
  35. 35. Jersey client y GETString 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. 36. Enviando datos encapsuladosClientResponse response = webResource.accept("text/plain").get(ClientRespon se.class);int status = response.getStatus();String textEntity = response.getEntity(String.class); 31/10/10
  37. 37. Jersey Clien y PutClientResponse 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. 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. 39. Web.xml 31/10/10

×