Ahora es más fácil hacer Web Services (se supone)

(Imagen: Edvard Munch - Niña enferma)

Una de las ideas detrás de JWS (Java Web Services) es facilitarle la vida a los desarrolladores en la ya tediosa tarea de crear y desplegar Web Services. Supuestamente, ahora ya es así, por lo que revisaremos a grosso modo las características de JWS que nos harán trabajar menos xD:

Anotaciones en código fuente

Ahora es posible anotar nuestro código fuente para hacer más simple el despliegue de Web Services. Estas anotaciones están definidas en JAX-WS, WS-Metadata y JAXB

Mapping Java/WSDL estándar

JAX-WS define un mapping estándar (sorry, pero no sé como traducir mapping xD) de WSDL a Java y viceversa. Cuando un service implementation bean (SIB : clase que puede ser desplegada como endpoint de WS) es desplegado, el WSDL resultante está basado en este mapping por defecto. Este mapping por defecto le facilita la vida al programador Java que quiere desplegar un Web Service y no conoce mucho de WSDL o XML.

Aunque no todo es perfecto, y este mapping tiene sus limitaciones. Por ejemplo, no se puede mapear mapear dos operaciones en el mismo puerto WSDL que pertenezcan a diferentes SIB's. En cristiano, si tenemos el puerto wsdl:port con las operaciones foo y bar, tanto foo como bar deben pertenecer a las misma clase/interface Java. Además, sólamente es posible mapear un WSDL a un SIB, por lo que es imposible desplegar una clase no anotada como Web Service.

Contexto de Serialización estándar

Ahora ya no es necesario especificar mappings y serializadores al momento del despliegue de un Web Service. Parafraseando, con el contexto de serializacióne estándar no hay que definir el XML al que las clases Java van a ser mapeadas. Y esto es posible debido a que JAXB se encarga de la serialización. JAXB tiene reglas estándar para serializar/deserializar componentes de un esquema XML a/desde objetos Java.

Modelos de desarrollo

El primero es "comienzo por Java". En este modelo, se empieza el desarrollo del Web Service(WS) construyendo una clase Java. Luego, para desplegar esta clase como WS la anotamos con @WebService y listo xD!. Los runtimes de JAX-WS y JAXB se encargan de mapear esta clase a un documento WSDL usando los mappings estándar de WSDL/Java y XML/Java. Si queremos modificar nuestro WSDL lo podemos hacer mediante anotaciones.

El otro modelo es "comienzo por el WSDL". En este caso tomamos un WSDL ya existente y usamos un compilador WSDL (que nos brinda la implementación JAX-WS) para generar las clases Java que implementan ese WSDL. Con este modelo obtenemos una grupo de SEI's (Service Endpoint Interface) que se corresponden con el WSDL. Entonces, nuestro trabajo es implementar las SEI's con lógica de negocio.

Y el último modelo es "comienzo por WSDL y por Java". La idea aquí es referenciar un WSDL pre-existente en la anotación @webService, que usaremos en la clase Java que pretende implementarla. Entonces, utilizamos anotaciones para hacer mapping entre la clase y el WSDL referenciado.

Basado en el capítulo 2 de SOA Using Java Web Services de Mark D. Hansen