JAX-WS 2.0 es la especificación siguiente a JAX-RPC 1.1. Veamos algunas cosas de lo que hace:
Mapping Java/WSDL
JAX-WS 2.0 define un mapping estándar para Java/WSDL. Determina como las operaciones WSDL están relacionadas con métodos Java. En otras palabras, cuando un mensaje SOAP invoca una operación WSDL el mapping Java/WSDL determina que método Java invocar y como el mensaje SOAP contiene los parámetros del método. También, el mapping determina como el resultado del método es encapsulado en el response SOAP.
Este mapping estándar nos permite comenzar con una clase Java, pasársela al procesador JAX-WS (puede ser java2wsdl o wsgen) y generar la descripción WSDL del endpoint del Web Service.
Por otro lado, se puede comenzar por un documento WSDL y generar las clases Java y las interfaces. Las clases Java que obtenemos son clases wrapper y es necesario que implementemos la lógica de negocio. Estas clases generadas ya incluyen anotaciones que describen el mapping Java/WSDL.
Algunos principios del mapping WSDL/Java:
- Los port types del WSDL se mapean a Interfaces Java: Un elemento wsdl:portType es mapeado a una interfaz Java denominada service endpoint interface (SEI). No se puede mapear operaciones individuales dentro de un port type a interfaces Java diferentes. Para implementar un port type, se debe desplegar una SEI.
- Los mappings de los parámetros y del valor retornado deben ser compatibles con JAXB: Las clases usadas para los parámetros de la SEI y su valor de retorno deben usar anotaciones JAXB para especificar los componentes del esquema XML al que van a ser mapeados.
WSDL estático
JAX-WS nos permite especificar un documento WSDL estático y omitir la generación automática de WSDL que se basa en los mappings estándar WSDL/Java y XML/Java (JAXB). Esto es útil cuando se necesita publicar un Web Service (WS) que se ajuste a un WSDL específico. También nos permite publicar WSDL basados en esquemas existentes.
Clientes estáticos y dinámicos
Los clientes de Web Services de JAX-WS son instancias de javax.xml.ws.Service. Una instancia de Service se corresponde con el elemento wsdl:service del documento WSDL del WS al que nos queremos conectar. Las instancias de Service pueden ser generadas de manera estática o dinámica. La generación dinámica es realizada en tiempo de ejecución por los métodos Service.create. En lo concerniente a generación estática, es posible generar subclases de Service de un documento WSDL usando herramientas de JAX-WS (como wsimport en GlassFish)
Invocación mediante Interfaces Proxy Java
Las instancias de Service pueden crear un proxy para invocar al WS mediante una SEI. Los métodos Service.getPort se utilizan para crear instancias SEI relacionadas con el wsdl:port a invocar. La SEI generada debe ser consistente con los mappings Java/WSDL (JAX-WS) y XML/Java (JAXB). Es por esto que cuando se utilizan proxys SEI se hacen por lo general con instancias de Service generadas junto al SEI, al compilar el WSDL a invocar mediante herramientas JAX-WS(e.j wsimport).
Invocación con XML
Una instancia de Service puede invocar un WS enviando y recibiendo mensajes XML. Para esto, la clase Service nos provee una instancia de javax.xml.ws.Dispatch al invocar cualquier método createDispatch. Esto nos permite interactuar con el WS directamente via XML sin tener que serializar y deserializar a Java.
XML Service Providers
Es posible desplegar un servicio que simplemente envíe y reciba mensajes XML sin preocuparse en el mapping con clases JAXB, mediante la interfaz javax.xml.ws.Provider. Al crear un servicio mediante Provider, no se hace uso de una SEI; por lo que nos permite crear servicios que trabajen directamente con los request y response en XML.
Framework para Handlers
JAX-WS define handlers de request y de response que pueden ser usados en el lado del cliente o del servidor. Los Handlers nos permite el pre-procesamiento y post-procesamiento de mensajes.
Los handlers tienen acceso de lectura y escriuta al mensaje XML y a su contexto. Los handlers JAX-WS se organizan en listas ordenadas llamadas cadenas de handlers. Las cadenas de handlers se definen a nivel de puerto, por lo que todos los métodos de una SEI usan la misma cadena de handlers.
Basado en el capítulo 2 de SOA Using Java Web Services de Mark D. Hansen
Publicar un comentario