Se hace camino al andar…

He estado leyendo el libro “Service-Oriented Architecture (SOA): Concepts, Technology, and Design” de Thomas Erl y he llegado al convencimiento (entre otras muchas cosas) de que para hacer “verdadero SOA” son necesarios:

• una infraestructura que haga posible la localización y la colaboración (síncrona o asíncrona) entre servicios
• buscar un modelo a partir del cuál poder diseñar los servicios como componentes estándar (independientemente de la infraestructura en la que se desplieguen)

Respecto al segundo punto, leyendo, leyendo y navegando, navegando, he llegado a una serie de artículos de IBM sobre integración usando SOA. Tras leer varios de ellos (reconozco que no todos), he visto que SCA sería una posible solución. Para los que quieran una introducción rápida a SCA, creo que es mejor acudir a la fuente directamente. En la web de OpenSOA se define el modelo en UML, por si eso ayuda en algo a su comprensión. Lo mejor de todo es que ya hay incluso especificación para API Java y ejemplos de cómo usar JAX-WS para implementar un componente “SCA-enabled”.

SCA es una propuesta OASIS (por lo que se garantiza que Microsoft también participa y que, por tanto, está garantizado el éxito en la interoperabilidad). A mí, sin embargo, me queda la duda (y me gustaría mucho que alguien me lo explicara) sobre qué diferencia hay entre SCA y JBI y entre SCA y WSIT. Lo que pasa es que la gente de Glassfish parece un poco escéptica al respecto de adoptar SCA (al menos tal cual está ahora definida). Ya le pregunté “in person” a Eduard Pelegrí y me contestó que él veía más factible una convergencia a medio/largo plazo de JBI (Sun) y SCA (IBM).

De todos modos, vamos a ver, que yo sepa… SOA no sólo se puede implementar con .NET o con J2EE…

El artículo de Kohsuke es de enero de 2007 y aconseja pasarnos ya a JAXB 2.1 y JAX-WS 2.1… aunque tengamos que poner cosas en {jdk6}/lib/endorsed.

Seguramente todo esto nos evitaría quebraderos de cabeza al usar el wsimport y todo eso… porque NO podemos usar la AntTask que viene con Glassfish v2 (hay que poner en el classpath del taskdef los siguientes jars: {glassfish v2}/lib/webservices-tools.jar y webservices-rt.jar) a menos que pongamos en nuestro {jdk6}/lib/endorsed las librerías de JAX-WS 2.1 (lo siento, no he terminado este ejercicio porque estaba fuera de mis objetivos de esta semana).

Entre otras cosas, el uso de JAX-WS 2.1 nos permitiría tener los famosos WS “stateful”. Así que quizás sería buena idea pasarnos a JAX-WS 2.1 después de todo…

He encontrado un enlace bastante sencillo de seguir como introducción a JAX-WS con JDK 6. No hace falta Glassfish, un Tomcat vale para estas pruebas (pero arrancado con JDK 6, claro).

La segunda parte de este artículo es aún mejor porque explica cómo hacer un simulador de un webservice “de verdad” para poder desarrollar un cliente.

Aconsejo no usar NetBeans para poder “tomar el pulso” a todo lo que está ocurriendo. (Bueno, en realidad quiero decir que uséis vuestro IDE preferido, retirando NetBeans de la categoría de IDE y pasándolo a la de generador de código). Ahora en serio, en realidad yo he usado el build.xml que viene y simplemente he tenido que cambiar en el build.properties dónde está mi JDK (y eso simplemente porque he preferido meterlo en Eclipse para ver mejor el código).

¡Ah, por cierto! No es necesario que os descarguéis el código tal y como dicen en el artículo: viene en <vuestro jdk6>/sample/webservices/EbayClient (y también EbayServer).

Por cierto, al ejecutar el dichoso “wsimport” no lo hace como una tarea ant sino que ejecuta el binario que viene con el JDK (un poco triste, pero es el estilo Sun…). De todos modos, lo peor es cuando ves lo que se genera en el paquete “ebay.apis”: ¡¡¡714 clases por 115 @webmétodos!!! Esto me recuerda un artículo sobre JAX-WS, aunque no queda bien parado…

De todos modos, si alguien se queda “con hambre”, ahí va un enlace a artículos sobre este tema.

He encontrado una comparativa entre JAX-WS 2.1 + JAXB (Glassfish) vs Axis2 1.1.1 + XMLBeans y resulta bastante evidente que el rendimiento de JAX-WS es bastante mejor que el de Axis2, sin embargo, me queda la duda de qué ocurriría si esta comparativa la hiciera alguien de Apache Axis2…

¿Alguno conocéis otras comparativas? Nosotros, en DEGESYS, sólo estamos usando Glassfish y no hemos tenido la oportunidad de comparar. Por cierto, si tuviera… digamos 4 horas… para hacer esta comparativa… ¿alguien tiene una receta para instalar Axis2 y probarlo en ese margen de tiempo?

De todos modos, me quedo con el último comentario en el artículo antes mencionado. Dice que sería mejor comparar JAX-WS RI (la implementación de referencia incluida en Glassfish) con Axis2 cuando éste incorpore el módulo con la implementación de JAX-WS. (Creo que ya lo incorpora, pero no he tenido tiempo de comprobarlo: en la web de Axis2 dicen “JAX-WS intregration”…)