jax-ws, metro y cxf

No hace mucho que empecé a trabajar con web services. Buscando, buscando, vi como opciones axis y jax-ws. Al final, por sencillez, me decidí por jax-ws … pero hoy he descubierto un pequeño detalle que no sabía.

jax-ws no es más que una especificación y hay varias posibles implementaciones. Las más conocidas son metro y cxf. Yo he estado usando metro, confundiéndolo con jax-ws. Ahora que he descubierto que hay dos, he investigado un poco en internet a ver ventajas de una y otra. No he hecho pruebas ni una búsqueda exhaustiva, simplemente comento aquí algunas cosas que he visto.

Por un lado, metro obliga a poner las anotaciones sobre clases, mientras que cxf admite que se pongan en interfaces. No es algo demasiado importante, pero siempre es más elegante tener definido el web service sobre una interfaz.

Metro sólo soporta SOAP, mientras que cxf soporta también otros protocolos. De hecho, una misma interfaz puede llevar simultáneamente anotaciones de SOAP y de REST, de forma que la clase que lo implementa no necesita saber qué tipo de web service habrá detrás.Por su parte, Metro no soporta REST. La implementación de esta gente para REST está en un proyecto separado, Jersey.

Tanto Metro como CXF tienen plugin de maven para generar el WSDL a partir de la clase java o para generar las clases java a partir del WSDL.

Una cosa que he leído pero no he acabado de entender es que parece ser que hay diferencias a la hora de tratar/generar código en los parámetros de un WebMethod si estos parámetros tienen cierta complejidad, como ser colecciones. Intentaré echarle un ojo con más calma a ver.

Los Web Services y yo

web services Sí, se que ando de vacaciones, pero por suerte para mí, soy de los que todavía les gusta su trabajo y, aunque no estoy trabajando, sí ando "revolviendo" en cosillas que me resultarán útiles más adelante. En concreto, en varios proyectos en los que es posible que participe se usan o se van a usar Web Services. A aprender me toca, sobre todo teniendo en cuenta que es posible que en uno de ellos sea yo el que tome la decisión de qué herramientas/tecnologías usar. Y en ello ando estos días, entre playa y terrazita, leyendo y jugueteando con los Web Services.

Aunque en el proyecto se nos aconseja el uso de .NET, yo soy más partidario de Java, básicamente por tres motivos:

  • Es el lenguaje que conocemos todos los desarrolladores del grupo. De usar .NET, tendríamos un tiempo de aprendizaje mayor: los Web Services y el lenguaje.
  • En Java casi todo es gratis, con el consiguiente ahorro de licencias, tanto de desarrollo como de los servidores.
  • .NET nos limitaría a servidores Windows, mientras que Java nos permitiría desplegar en cualquier servidor, Windows, linux, solaris, …. Sé que está el proyecto MONO, pero no veo la necesidad de meter más complejidad al asunto.

En cualquier caso, no dudo que con .NET se puedan hacer perfectamente Web Services igual que en java, posiblemente más fácilmente integrados con otras cosas de Microsoft, pero no veo ninguna ventaja clara en lo que es estrictamente el lenguaje de uno sobre otro.

El siguiente tema es si SOAP o REST. En principio, por lo que he ido leyendo, me inclino por REST. Aparentemente es más simple y parece ser que es la nueva tendencia. Posiblemente me decida por REST, pero le veo/tengo un par de pegas/dudas.

  • Al ser más nuevo, me da la impresión de que está menos soportado por los servidores/herramientas actuales. Muchas de las herramientas traen como coletilla "soporte para REST". Siempre es un riesgo meterse en algo reciente.
  • De la misma forma, me da la impresión de que toca codificar más. En SOAP creas tu WSDL y aunque no he buscado con detalle, me da la impresión de que hay miles de herramientas que te generan el código tanto de la parte cliente como de la parte servidor para el uso del Web Service definido por ese WSDL. En REST posiblemente haya equivalentes, pero al ser más nuevo, seguro que hay menos o están menos desarrollados. Insisto, no he mirado en serio, es sólo la impresión que me ha dado en una búsqueda superficial.

Otra gran duda es el tipo de librerías a usar para el Web Service. He visto herramientas como Restlet, (es con la que estoy jugando), pero da la impresión de ser algo muy simple para aprendizaje, no tengo muy claro si puede servir para un servidor en producción con fuertes requisitos de seguridad. También hay cosas como JAX-WS o como Jersey, pero el verlos debajo de GlassFish y sobre todo el primero, debajo de Java EE, me da la impresión de que sería matar moscas a cañonazos. Nuestro proyecto sólo tendría unos pocos Web Services y con datos no muy complejos, aunque sí bastante trasiego.

Finalmente, está el tema de elegir servidor, hay cosas como Spring Web Services, Apache Axis 2 o cosas más tradicionales como Jetty, Tomcat o servidores más "bestias" como Glassfish o JBoss. Por un lado, las ganas de aprender me tiran a Spring, pero el irme a algo conocido me tira por Tomcat. Como he comentado, Glassfish o JBoss me parecen excesivos para lo que pretendemos.

En fin, sigo investigando y haciendo pruebas, pero cualquier sugerencia de gente con experiencia por estos lares, es bienvenida.