Un saludo y muchas gracias por vuestras visitas, emails y comentarios.

Cuando arrancamos Eclipse se usa la jvm que se encuentra en la variable PATH del sistema, aunque luego tengamos configurado que para los proyectos use  otra jvm. Afortunadamente ésto es facilmente configurable, basta con editar el fichero eclipse.ini, que se encuentra en el raiz del directorio del Eclipse y añadir la siguiente línea con la ruta al javaw que quieras usar:

-vm
c:/java/jre6/bin/javaw.exe

En este fichero también podemos tunear el tamaño inicial y máximo de las memorias heap y permgen. La solución a esos cuelgues repentinos o los inoportunos outofmemory cuando estamos con varios proyectos, servidores, plugins, etc. abiertos en eclipse. Recuerda que por defecto la jvm sólo usa 64MB.

La memoria heap es la asignada de forma dinámica y que puede ser liberada por el recolector de basura. Para configurar los valores inicial y máximo se usan los parametros de la jvm -Xms y -Xmx respectivamente. Por ejemplo, en mi equipo, que tiene 1GB de RAM, tengo las siguiente líneas en el eclipse.ini:

-vmargs
-Xms128m
-Xmx512m

La memoria permgen es memoria que se asigna de forma permanente y, por tanto, no puede ser liberada. En el eclipse.ini del Eclipse 3.3 ya se incluye la siguiente línea para gestionar su tamaño máximo:

–launcher.XXMaxPermSize
256m

Aun así, se pueden utilizar los parametros -XX:PermSize y -XX:MaxPermSize de la jvm para configurar los tamaños inicial y máximo de la memoria permgen. Por ejemplo, estas serian las líneas a añadir para un tamaño inicial de 128MB y máximo de 256MB:

-XX:PermSize=128m
-XX:MaxPermSize=256m

Desconozco si los posts del blog fueron de ayuda o no, así que os dejo unos enlaces al genial curso de Shang Shin donde seguro podreis aprender todo lo necesario para dominar esto de XSDs y WSDLs usando como herramienta el nuevo Netbeans 6 Beta 2.

Web Services and SOA Programming (with Passion!) Hands-on Online Course

Schemas y patrones de diseño.

WSDL básico y avanzado.

No os quedeis en las transparencias y los videos y echarle un ojo a los recursos también.

Podeis aprovechar también para aprender a usar las herramientas soapUI y WS Monitor que seguro os sacarán de más de un apuro en alguna ocasión. Además SoapUI lo podeis usar para hacer pruebas de stress a vuestros webservices como alternativa a JMeter.

Por mi parte, siento el parón en los contenidos pero cambié de trabajo recientemente y, para mi pesar, ya ni me dedico profesionalmente a webservices ni tengo mucho tiempo para echarle en casa.

En Behind Closed Doors: Secrets of Great Management podemos leer siete semanas de la vida de Sam, un manager de nivel medio, y aprender cómo realizar las funciones de gestión típicas del día a día de un responsable de equipo, como delegar tareas, dar feedback, fijar objetivos, manejar reuniones, hacer equipo, controlar el progreso de un proyecto, actuar ante los cambios, etc. sin meterse en ninguna metodología concreta.

El libro mezcla de forma muy acertada una parte práctica (la vida de Sam) con una parte teórica donde se describen las técnicas a usar, haciéndose muy ameno y enganchándote hasta el final. No llega a 160 páginas y usa un inglés fácil de seguir. No es que sea la panacea, lo de los secretos se queda sólo en el título como se podia imaginar, pero si me atrevo a recomendarlo a aquellos que quieran aprender sobre gestión de grupos, sobretodo a cómo manejarse en el día a día. Y es que Sam puede ser un buen ejemplo de buen manager para los que no hemos tenido demasiados.

El webservice al que invocará el cliente es el desarrollado en el artículo anterior, myVirtualShop. Puedes descargarlo aquí listo para desplegar en el repositorio de Axis2.

Preliminares
Si deseas seguir este tutorial paso a paso debes tener instalado:

Por mi parte he aprovechado para probar la nueva versión 1.3 de Axis2. En teoría sólo mejora el rendimiento y corrije algunos bugs. Con la 1.2 funciona igual.

En qué consiste
Crear un cliente webservice utilizando la herramienta WSDL2Java es realmente sencillo, sólo necesitas tener acceso al WSDL que describe el webservice y ejecutar el WSDL2Java para generar las clases Java correspondientes al cliente.

Antes de
Antes de nada vamos a dejar el webservice desplegado y funcionando. Copia el webservice myVirtualShop.aar al repositorio de Axis2, subcarpeta services, y arranca el servidor con el script axis2server localizado en bin. Comprueba que todo está correcto accediendo al endpoint del webservice en http://localhost:8080/axis2/services/myVirtualShop.

Ahora con el webservice funcionando podemos centrarnos exclusivamente en el cliente. Lo primero es crear un nuevo proyecto Java, myVirtualShopClient, y configurar su Build Path para añadir los jars de Axis2, localizados en lib. Para independizar al proyecto cliente de la instalación de Axis2 crea una carpeta lib y copia dentro los jars de Axis2. Seleccionalos todos y añadelos al Build Path. Sé que son muchos y que algunos no hacen falta, pero otros dependen de determinadas decisiones que se tomen durante el desarrollo, como la elección del Databinding a utilizar, de si queremos hacer llamadas asíncronas, enviar attachments, etc. Mi recomendación es tenerlos todos disponibles durante el desarrollo y eliminar los jars innecesarios al crear la distribución.

Lo siguiente es añadir al proyecto el WSDL del webservice y sus schemas asociados. Crea una carpeta resources y copia dentro el WSDL y su schema. Recuerda borrar las extensiones jpg. A continuación un screenshot de como queda el proyecto.

Momento WSDL2Java
En este punto ya podemos utilizar WSDL2Java para generar de forma automática el código Java para el cliente webservice a partir del fichero WSDL. El código generado incluye un stub cliente para invocar al webservice y las clases Java necesarias para el Databinding de los mensajes XML. Como motor de Databinding vamos a usar adb.

Para ejecutar WSDL2Java se puede optar por hacerlo mediante una consola, ANT, Maven o un plugin de Eclipse o IDEA. Nosotros vamos a ver cómo usar el plugin de Eclipse Code Generator Wizard. Es más fácil y descriptivo:

1. Pulsa File->New->Other->Axis2 Wizards->Axis2 Code Generator.
2. Elije la opción de generar código Java desde un fichero WSDL. Pulsa Next.
3. Selecciona el fichero myVirtualShop.wsdl localizado en resources. Pulsa Next.
4. En la pantalla de opciones, selecciona custom como Codegen option e indica org.example.myvirtualshop.wsclient como Custom package name. Fijate que dejamos adb como Databinding y que se va a generar código cliente, tanto para llamadas síncronas como asíncronas. Pulsa Next.
5. Finalmente selecciona el proyecto myVirtualShopClient como destino del código a generar. Para ello elije la primera opción y elije el proyecto al pulsar el botón Browse. Pulsa Finish.

En las siguientes imágenes se ilustran los pasos anteriores.

Si refrescas el proyecto podrás ver las clases creadas en el nuevo package org.example.myvirtualshop.wsclient:

• MyVirtualShopStub: Esta es la clase stub cliente con la que se pueden invocar las operaciones del webservice. Contiene un método por cada operación del webservice y clases internas que representan los elementos de los mensajes XML (databinding). Además, y como hemos seleccionado el modo asíncrono durante el wsdl2java, existe un método, que empieza por start, para realizar cada operación del webservice de forma asíncrona.
• MyVirtualShopCallbackHandler: Esta es una clase abstracta que representa el manejador de respuestas asíncronas. Su funcionamiento lo veremos más adelante.

Despues de
Con el cliente ya creado sólo falta incorporar el código Java necesario a nuestra aplicación para crear el mensaje de petición deseado, usar el stub para invocar la operación correspondiente y procesar la respuesta.

Lo primero es crear una instancia del stub e indicar la URL del endpoint del webservice al que queremos invocar. Ejemplo:

String sEndPoint = "http://localhost:8080/axis2/services/myVirtualShop";
MyVirtualShopStub stub = new MyVirtualShopStub(sEndPoint);

Construir un mensaje es muy fácil. Existe una clase interna (JavaBean) por cada elemento complejo del mensaje XML que se utiliza para realizar el databinding o mapeo entre objetos Java y XML (y viceversa). Por tanto no es más que ir creando objetos y usar metodos set. Para ver las clases internas puedes ayudarte de la vista Outline del propio Eclipse. Sorpresa! Los incomprensibles sufijos _typeX siguen sin desaparecer en la versión 1.3 de Axis2.

El siguiente código es un ejemplo de cómo se construiría una petición para la operación Order:

//Elemento raiz del mensaje
OrderRequest orderRequest = new OrderRequest();
//Elemento Cliente
Cliente_type0 cliente = new Cliente_type0();
cliente.setNombre("John Waterfall");
cliente.setDireccion("NA");
orderRequest.setCliente(cliente);
//Elemento items
Items_type0 items = new Items_type0();
Item_type0[] aItem = new Item_type0[1];
//Elemento item
aItem[0] = new Item_type0();
aItem[0].setRef("R0001");
aItem[0].setCantidad(100);
items.setItem(aItem);  
orderRequest.setItems(items);

Para invocar al webservice el stub cuenta con un método por cada operación. Los métodos son getCatalog, search, order y getStateOrder. Estos métodos tienen como parámetro la clase que representa el mensaje petición de la operación y devuelven la correspondiente respuesta. Siguiendo con el ejemplo, lo siguiente sería el código para invocar la operación Order y procesar la respuesta:

OrderResponse orderResponse = stub.order(orderRequest);
System.out.println("** OrderResponse.getIdPedido() = " + orderResponse.getIdPedido());
System.out.println("** OrderResponse.getFechaPrevistaEntrega() = " + orderResponse.getFechaPrevistaEntrega());
System.out.println("** OrderResponse.getgetTotal() = " + orderResponse.getTotal());

Si deseas ver un ejemplo un poco más completo dónde se invocan las cuatro operaciones del webservice, puedes descargarte la siguiente clase TestClient, copiarla al package org.example.myvirtualshop.wsclient y ejecutar su método main. Asegurate antes de que el webservice se encuentra desplegado y ten cuidado con los nombres de las clases internas del databinding, los números de los sufijos podrían variar.

Modo asíncrono
Una de las novedades de Axis2 es que permite realizar llamadas asíncronas sobre las operaciones de un webservice.

¿Qué diferencia hay entre una llamada síncrona y asíncrona? Cuando se invoca a un método de forma síncrona o bloqueante, el flujo de control del programa no sigue con la siguiente instrucción hasta que no termina la ejecución del método invocado (el 99.9% de las llamadas en Java). Mientras que cuando se invoca a un método de forma asíncrona o no bloqueante, el flujo de control del programa continua automáticamente con la siguiente instrucción y en otro thread se ejecuta el método invocado (concurrencia).

Estas llamadas asíncronas forman el patrón de intercambio de mensajes (MEP) conocido por In-Only y es muy útil para invocar operaciones de las que no necesitamos una respuesta o no podemos disponer de la respuesta en ese mismo instante.

Para invocar las operaciones del webservice de forma asíncrona el stub contiene un método por cada operación que se llama igual pero empezando por el prefijo start.  Los métodos son startGetCatalog, startSearch, startOrder y startGetStateOrder. Estos métodos tienen dos parametros, el mensaje de petición y el manejador de la respuesta asíncrona (CallbackHandler) que será el encargado de recibir la respuesta de la operación invocada.

Para crear un CallbackHandler hay que usar, más bien heredar, la clase abstracta CallbackHandler generada por el wsdl2java. Esta clase tiene dos métodos por cada operación del webservice, uno para procesar la respuesta y otro para procesar un posible error en la comunicación. Por tanto habrá que sobreescribir el par de métodos correspondientes a la operación que se vaya a invocar de forma asíncrona con el código para procesar la respuesta de la operación o tratar un posible error.

Veámoslo en detalle y siguiendo nuestro ejemplo para el webservice MyVirtualShop. Los pasos para poder invocar la operación Order de forma asíncrona serían los siguientes:

1. Crea una clase que herede de la clase abstracta MyVirtualShopCallbackHandler, llámala OrderCallbackHandler. Aquí tienes su código.
2. Sobreescribe el método receiveResultorder con el siguiente código de ejemplo para procesar la respuesta:
   

   public void receiveResultorder(OrderResponse result) {
    System.out.println("** Procesando respuesta asíncrona de operación Order…");
    System.out.println("** OrderResponse.getIdPedido() = " + result.getIdPedido());
    System.out.println("** OrderResponse.getFechaPrevistaEntrega() = " + result.getFechaPrevistaEntrega());
    System.out.println("** OrderResponse.getgetTotal() = " + result.getTotal());
    System.out.println("** Procesando respuesta asíncrona de operación Order… OK");
   }

3. Sobreescribe el método receiveErrororder con el siguiente código de ejemplo para procesar un posible error:
   

   public void receiveErrororder(Exception e) {
    System.out.println("** Error en invocación asíncrona a operación Order…");
    e.printStackTrace();
    System.out.println("** Error en invocación asíncrona a operación Order… OK");
   }

4. Crea una nueva clase, TestAsynClient, con un método main para probar la llamada asíncrona a la operación Order. Aquí tienes su código. El código para crear el stub y la petición es exactamente el mismo que en el ejemplo de más arriba. Sólo cambia el código para hacer la llamada, que sería el siguiente:
   

   System.out.println("\n*** Invocando operacion Order de forma ASÍNCRONA…");  
   OneCallbackHandler callback = new OneCallbackHandler();
   stub.startorder(orderRequest, callback);
   System.out.println("*** El flujo de control del programa continua con la siguiente instruccion a la llamada asíncrona\n");
   Thread.sleep(10000); //Espera 10s para que no termine el thread main y por tanto el programa sin recibir antes la respuesta

5. Para probarlo ejecuta la clase recién creada. Si quieres probar el caso de receiveError sólo tienes que parar el Axis2 y volver a ejecutar la clase.

Conclusiones
Hasta aquí esto es todo. Como habeis visto usar un webservice con Axis2 es rápido y sencillo, pero con otras tecnologías el proceso es muy similar. Que el webservice haya sido creado también con Axis2 es irrelevante. Para crear un cliente sólo necesitamos el wsdl del servicio, es el único punto en común que tienen el cliente y el servicio. Pero, para evitar sorpresas en cuanto a la interoperabilidad se debe desarrollar el wsdl de forma independiente a una tecnología en concreto, sobretodo si es un wsdl complejo. Y a pesar de todo, la interoperabilidad 100% no se puede garantizar. Las sorpresas siempre están ahí, llámense bugs, attachments, estándares,…

Technorati Post Claim: Technorati Profile

Presentaciones
Un webservice o servicio web es una aplicación modular, auto-contenida, auto-descriptiva, sin estado y accesible a través de Internet. Su objetivo es la interoperabilidad entre aplicaciones, con un mínimo acoplamiento e independientemente de la tecnología con la que hayan sido desarrolladas.

Para lograr la interoperabilidad, aparte de basarse en estándares, un webservice se comunica mediante mensajes XML utilizando el protocolo SOAP. El interfaz de un webservice se describe en un documento XML utilizando el estándar WSDL. En este fichero, que recibe el mismo nombre WSDL, se definen los detalles de cómo usar un webservice, como las operaciones, el formato de los mensajes, el tipo y el protocolo de transporte del webservice.

El WSDL es, por tanto, básico a la hora de crear un cliente para un webservice y debería ser cuidadosamente diseñado. Un buen diseño evitará problemas de interoperabilidad aunque se empleen tecnologías diferentes a la del webservice para crear los clientes. Por ello, debería ser de máxima importancia durante el desarrollo de un webservice.

Empezando la casa por el tejado
Sin embargo, y descartando la opción de parsear los XML a pelo, es habitual encontrarse con un enfoque radicalmente contrario. Partiendo de la implementación de la lógica del webservice (una clase Java) se genera de forma automática el WSDL correspondiente. El nombre de este método es Java to WSDL. Pero al seguirlo estamos condicionando la interoperabilidad del webservice a la bondad de la herramienta empleada para generar el WSDL. A cambio se facilita el desarrollo (ahora incluso con anotaciones) del webservice.

Este enfoque funciona bien para servicios web realmente sencillos, con métodos de pocos parametros de tipo básico. Pero puede (casi seguro) dar problemas de interoperabilidad en webservices con mensajes complejos si se usan tecnologías distintas (aunque sean del mismo lenguaje) para el webservice y los clientes. No se puede obviar que diferentes herramientas generan diferentes WSDLs a partir de la misma clase Java…

Otra desventaja de usar este enfoque es que estamos haciendo al interfaz del webservice depender de la implementación. Adiós abstracción entonces. Si mañana cambia la implementación es más que posible que deba cambiar el interfaz (WSDL) y, por tanto, también todos los clientes que se hubieran creado. Además habremos perdido el control sobre el diseño del interface del webservice, en realidad la cara de todo servicio web, lo que todo el mundo que va a ver y donde merece la pena emplear tiempo para que sea lo más amigable y comprensible.

El camino
La alternativa que en este tutorial se propone es actuar justo al revés y de forma más natural. Primero se define el interfaz del webservice, es decir, el WSDL, donde se describen las operaciones, el formato de los mensajes, el tipo y protocolo de comunicación. Entonces se generan de forma automática las clases Java que implementan tanto el esqueleto del webservice como sus mensajes. Este método se llama WSDL to Java.

No sólo es más natural el orden de hacer las cosas, primero el interfaz, luego la implementación. También es mucho más natural y ágil describir los mensajes XML del webservice usando schemas XML en vez de clases Java. Otras ventajas son evitar los posibles efectos colaterales en la interoperabilidad sufridos por la generación automática del WSDL, y no perder el control sobre su diseño.

En realidad, y como veremos, crear un WSDL no es tan complicado, mientras no vayamos la primera vez en plan comando con un editor de textos básico. Tranquilidad, porque además no hace falta empollarse la especificación del W3C, sólo un buen IDE y tener claros un par de conceptos. No me enrollo más. Allá vamos!

Preliminares
Para seguir este tutorial antes deberias instalar:

• JDK 1.4 o superior, con la variable de entorno JAVA_HOME configurada.
• Eclipse 3.3 + wtp 2.0 o superior. Puedes descargar desde aquí el pack all-in-one.
• Axis2 1.2 Standard Binary Distribution. No olvides configurar la variable de entorno AXIS2_HOME. Si necesitas ayuda para instalar Axis2 puedes consultar el artículo anterior Instalando Axis2.

Estructura de un webservice en Axis2
Axis2 utiliza un modelo propio de empaquetamiento para webservices. Este nuevo modelo permite a Axis2 el despliegue en caliente y auto-actualización de los webservices de su repositorio. La estructura de este modelo es similar al conocido jar, pero con las siguientes diferencias:

1. La extensión para un webservice es aar en vez de jar.
2. Debe existir un fichero descriptor del webservice llamado services.xml. Este fichero se puede generar automáticamente, así que no es problema.
3. A nivel raíz existirá una carpeta llamada META-INF que contendrá el citado services.xml y, opcionalmente, el fichero WSDL para devolver en lugar de uno autogenerado por Axis2.

Descripción del webservice myVirtualShop
Es el momento de presentar al webservice que nos acompañará durante toda esta serie de tutoriales sobre Axis2.

Imaginemos que tenemos que crear una capa de webservices para ampliar el sistema de ventas por Internet de un negocio que quiere ir más allá de la típica aplicación web de tienda virtual. Esta opción permitirá a los clientes del negocio automatizar su proceso de compras y optimizar su sistema de control de inventario inteligente. Las aplicaciones de los clientes y del negocio van a poder comunicarse de un modo estándar y, lo más importante, independientemente de la tecnología propia de cada una.

Las operaciones del webservice que vamos a implementar son: obtener el catalogo de productos, búsqueda de productos, hacer un pedido y consultar el estado de un pedido. Las llamaremos getCatalog, search, order y getOrderState, respectivamente.

En el supuesto modelo de datos de la aplicación, los productos que componen el catálogo formarán parte de una categoria (sólo una) y tendrán una referencia (única), un nombre, una descripción, una disponibilidad y un precio.

Preparación del entorno de desarrollo
Como entorno de desarrollo voy a utilizar eclipse con sus webtools, y así probar su editor de wsdl y schemas, más el plugin para eclipse, Code Generator Wizard de Axis2. Los plugins de Axis2 se pueden descargar aquí y para instalarlos basta con descomprimirlos en la carpeta plugins del eclipse y luego arrancar eclipse.

Para evitar tener todos los jar del Axis2 inundando la vista de nuestro proyecto vamos a crear una libreria de usuario. Abre la pantalla Window/Preferences, selecciona Java/Build Path/User Libraries. Crea una nueva variable de usuario, llamala AXIS2 y añade dentro todos los jar de la carpeta lib de la distribución del Axis2.

Creación del proyecto myVirtualShop
Para crear un proyecto de un webservice en Axis2 basta con crear un proyecto Java. Le asignamos un nombre, myVirtualShop por ejemplo, y le añadimos la libreria de usuario que hemos creado para los jar de Axis2. A mi siempre me gusta separar las carpetas de los fuentes y los binarios.

Ahora creamos las carpetas META-INF y resources. Si fueramos a necesitar alguna otra libreria como hibernate, spring, etc. creariamos también una carpeta lib, copiariamos los jars dentro y los añadiriamos al build path del proyecto.

Schemas
El primer paso del desarrollo del webservice es definir el formato de los mensajes XML de cada operación. Para ello vamos a crear un schema XSD donde se definan los elementos de entrada y salida de las operaciones del webservice. Se podría crear más de un schema, quizás lo recomendable es uno por mensaje, pero por simplificar lo dejaremos en un solo schema.

Crear un schema no es complicado, sobretodo si se cuenta con un buen editor visual. Es similar a crear arboles, se empieza por definir un elemento del que pueden colgar secuencias de otros elementos y así sucesivamente. Los elementos tienen un nombre y pueden tener atributos. Tanto los atributos como los elementos que serían las hojas del árbol tienen un tipo. Al elemento que sería la raíz del árbol se le denomina global. Una buena práctica es hacer globales los elementos que se vayan a reutilizar, como el elemento Producto al que se hace referencia en las respuestas de las operaciones getCatalog y search.

El editor XML de las WTP de Eclipse no está mal. Su punto fuerte es la refactorización. Puedes cambiar el nombre, orden y tipo de elementos y atributos sin problemas. Lo que no me ha gustado es que sólo es capaz de mostrar 2 profundidades a la vez en pantalla. Para avanzar en la jerarquía tienes que seleccionar el elemento más profundo (derecha). En general prefiero el XMLSpy, pero no es gratis.

El schema se llamará myVirtualShop.xsd, con http://www.example.org/myVirtualShop/messages como namespace e irá en la carpeta META-INF. Dentro del schema se define un elemento global por cada mensaje. Los mensajes son getCatalogRequest, getCatalogResponse, searchRequest, searchResponse, orderRequest, orderResponse, getOrderStateRequest y getOrderStateResponse. Su formato puede examinarse en las siguientes figuras.

Unos ejemplos de los XML resultantes: 1, 2, 3, 4, 5, 6, 7 y 8.

Los elementos Producto y Catalogo se han hecho globales para poder reutilizarse en distintos mensajes. Producto para reutilizarse en getCatalogRequest y searchResponse, y Catalogo por si en un futuro se desea crear una nueva operación que lo use.

Éste es el schema final, copialo a META-INF y refresca el proyecto. Ojo! borra la extensión jpg y dejalo en xsd (lo mismo para los siguientes ficheros, cosas de la administración del blog…).

El temido WSDL
Ahora vamos a crear el interfaz del webservice, el WSDL. Selecciona File/New/Other/Web Services/WSDL. Colócalo en META-INF y dale un nombre, myVirtualShop.wsdl. Pulsa Next. El target namespace será http://www.example.org/myVirtualShop/wsdl. Lo demás dejalo como está: SOAP como protocolo y la opción document literal. Es decir, va a ser un webservice basado en intercambio de documentos mediante SOAP.

Ya tenemos delante un esqueleto del WSDL. Echale un ojo a la vista Source y verás los distintos elementos que forman un WSDL:

• Service: el servicio en sí. El nombre del servicio y del puerto se usan para formar la url con la que acceder al servicio, también llamada endpoint. Su formato es el siguiente: http://host:puerto/axis2/services/nombre_portType.
  El atributo location puedes dejarlo como está. El propio Axis se encargará de modificarlo según sea necesario.
• PortType: es el interfaz donde se definen las operaciones del webservice.
• Binding: especifica el protocolo concreto, el tipo de webservice y los formatos de las operaciones de un PortType concreto.
• Message: define los mensajes de cada operación del webservice.
• Types: es un elemento contenedor para definir los tipos de datos o elementos que serán usados en los mensajes. Las definiciones se hacen con schemas XSD.

Aunque un buen editor visual te abstrae de muchos de estos detalles es más que recomendable familiarizarse con el código y la sintaxis.

Lo primero que vamos a hacer es importar dentro del WSDL el schema donde hemos definido previamente los elementos que forman los mensajes. En este punto el editor no funciona muy bien y lo mejor es hacerlo a mano. Desde la vista Source del editor cambia el fichero para que sea igual que este:

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns:tns="http://www.example.org/myVirtualShop/wsdl"
 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
 xmlns:msg="http://www.example.org/myVirtualShop/messages"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="myVirtualShop"
 targetNamespace="http://www.example.org/myVirtualShop/wsdl">
    <wsdl:types>
        <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
      <xsd:import
    namespace="http://www.example.org/myVirtualShop/messages"
    schemaLocation="myVirtualShop.xsd">
   </xsd:import>     
        </xsd:schema>
    </wsdl:types>
[…]

Una vez definidos los tipos podemos usar el editor visual para ir creando las distintas operaciones y mensajes correspondientes. Ve a la vista Design del editor. De izquierda a derecha están representados los elementos service, binding y port type. Verás que ya existe una primera operación genérica. Vamos a cambiarle el nombre por getCatalog y asignar como mensajes de entrada y salida los elementos existentes dentro del proyecto getCatalogRequest y getCatalogResponse respectivamente.

Para cambiar el nombre de la operación, haz doble click sobre el primer NewOperation. Para asignar el elemento getCatalogRequest haz click derecho sobre el elemento de entrada NewOperation a la derecha de input. Selecciona Set Element/Existing. En Search Scope marca Enclosing Project para ver la lista de elementos disponibles. Selecciona el elemento getCatalogRequest de nuestro schema. Ahora haz lo mismo para la respuesta NewOperationResponse, el elemento que tienes que asignar es, lógicamente, getCatalogResponse.

Fácil, no? Pues ahora crea el resto de operaciones: search, order y getOrderState, y asignales sus correspondientes mensajes de entrada y salida.

Ojo! Lo cierto es que el editor aún falla bastante. Por ejemplo, al crear una nueva operación creará un schema interno en types para los tipos de los mensajes. Lo podrás ver en la vista Outline. Debes elegir siempre como elementos de los mensajes los del schema myVirtualShop.xsd. Y al terminar el WSDL borra este schema interno que se crea solo y cualquier rastro suyo.

Finalmente debemos actualizar el contenido del binding con las nuevas operaciones. Para ello haz click derecho sobre el binding y selecciona Generate Binding Content.

En cualquier momento puedes validar el WSDL haciendo click derecho sobre él en la vista Package Explorer y seleccionando Validate.

Éste es el WSDL final y como quedaria en el editor visual.

WSDL2Java
Lo más traumático ya ha pasado. Ahora con el WSDL ya definido vamos a crear las clases del webservice a partir de él. Para ello haremos uso del plugin Code Generator Wizard de Axis2 que previamente hemos instalado y ejecutaremos el método WSDL2Java.

Selecciona File/New/Other/Axis2 Wizards/Axis2 Code Generator, elije el wizard para generar código Java a partir de un fichero WSDL e indica la localización del WSDL. A continuación aparecerá la pantalla de opciones. En ella puedes elegir entre generar código para servidor, cliente o ambos, puedes indicar el motor de Databinding a usar y asignar mapeos entre namespaces XML y packages Java. Nosotros vamos a generar código Java para servidor usando adb como motor de Databinding y el fichero descriptor del webservice, services.xml. Para ello haz lo siguiente:

1. Selecciona la opción custom para Codegen option.
2. Indica org.example.myvirtualshop.ws como Custom package name.
3. Selecciona Generate server side code y Generate a default services.xml.
4. Indica el nombre de package org.example.myvirtualshop.ws para el namespace http://www.example.org/myVirtualShop/ws.
5. Indica el nombre de package org.example.myvirtualshop.ws.messages para el namespace http://www.example.org/myVirtualShop/ws/messages.

La pantalla quedaría así:

Para finalizar sólo queda seleccionar el destino del código generado. En la siguiente pantalla indica el proyecto MyVirtualShop. Para ello selecciona la primera opción, Browse and select a project […], e indica el proyecto MyVirtualShop en el diálogo Browse. Pulsa Finish y listo!

Si refrescas el proyecto podras ver todo lo generado:

1. En src, el package org.example.myvirtualshop.ws que contiene las clases MyVirtualShopMessageReceiverInOut y MyVirtualShopSkeleton. Ésta última es la clase skeleton que hay que completar para dotar de funcionalidad al webservice, si le echas un vistazo verás que tiene un método por cada operación. La primera se encarga de recibir y enviar los mensajes de forma transparente.
2. En src, el package org.example.myvirtualshop.ws.messages con las clases que implementan los elementos XML de los mensajes del webservice según el motor Databinding empleado.
3. En resources, el fichero descriptor services.xml y los ficheros temporales myVirtualShop.wsdl y xsd0.xsd utilizados durante la generación de código.
4. En el raíz del proyecto, el script ANT build.xml que usaremos para empaquetar el webservice en un fichero aar.

Decepciones
A más de uno le habrá sorprendido encontrarse con esos sufijos _typeX en los nombres de las clases generadas para los mensajes. Sinceramente a mi también y me parece imperdonable para una versión 1.2. Más aún si tenemos en cuenta que este comportamiento no ocurría en Axis1.

La herramienta todavía contiene más bugs o defectos que ya estaban solucionados en Axis1. Por ejemplo, no hay manera de que sobreescriba el código generado, tienes que borrar primero, inexplicable también el formato e indentación de la clase skeleton. Además si usas XMLBeans como motor de Databinding ya te aviso que no funciona para todos los WSDLs, al menos yo he tenido problemas con varios.

Implementación
Para poder probar el webservice sin obtener un molesto AxisFault vamos a añadir una clase mock que implemente las operaciones del webservice y en la que delegue la clase skeleton. Ojo! Esto no es más que un prototipo rápido que sería sustituido en un desarrollo real.

La clase mock es ésta. Más tonta no puede ser. Crea el nuevo package org.example.myvirtualshop.ws.mock y cópiala dentro.

Ahora modifica la clase skeleton para que delegue en el mock. El código quedaría así:

import org.example.myvirtualshop.ws.mock.MyVirtualShopMock;
/**
 *  MyVirtualShopSkeleton java skeleton for the axisService
 */
public class MyVirtualShopSkeleton{
  public org.example.myvirtualshop.ws.messages.GetCatalogResponse getCatalog(org.example.myvirtualshop.ws.messages.GetCatalogRequest getCatalogRequest){
    MyVirtualShopMock mock = new MyVirtualShopMock();
    return mock.getCatalog(getCatalogRequest);
  }
  public org.example.myvirtualshop.ws.messages.SearchResponse search(org.example.myvirtualshop.ws.messages.SearchRequest searchRequest){
    MyVirtualShopMock mock = new MyVirtualShopMock();
    return mock.search(searchRequest);
  }
  public org.example.myvirtualshop.ws.messages.OrderResponse order(org.example.myvirtualshop.ws.messages.OrderRequest orderRequest){
    MyVirtualShopMock mock = new MyVirtualShopMock();
    return mock.order(orderRequest);
  }
  public org.example.myvirtualshop.ws.messages.GetOrderStateResponse getOrderState(org.example.myvirtualshop.ws.messages.GetOrderStateRequest getOrderStateRequest){
    MyVirtualShopMock mock = new MyVirtualShopMock();
    return mock.getOrderState(getOrderStateRequest);
  }
}

Empaquetar y desplegar
El desarrollo ya está terminado, sólo falta empaquetar y desplegar. Para empaquetar vamos a usar ANT porque el plugin Service Archiver de Axis2 deja mucho que desear (y va otra decepción).

Antes debemos preparar el proyecto. Para ello borra los ficheros temporales ficheros temporales myVirtualShop.wsdl y xsd0.xsd en resources y copia desde META-INF a resources los ficheros myVirtualShop.wsdl y myVirtualShop.xsd. El proyecto quedaría así:

Para usar ANT debes abrir la vista ANT del Eclipse y arrastrar dentro el fichero build.xml. Haz doble click en el task jar.server y refresca el proyecto cuando termine. El webservice habrá quedado empaquetado en un fichero Services.aar en la carpeta recien creada build/lib. Cámbiale el nombre myVirtualShop.aar.
(Actualización 06/08/2007: Si obtienes un error de javac al ejecutar ANT asegurate que en la variable path del sistema se apunta a la carpeta bin del JDK)

Toca desplegar, tan sólo tienes que copiar el webservice al repositorio de Axis2, en services, y arrancar el servidor con el script axis2server situado en bin. Para comprobarlo abre en un navegador la url http://localhost:8080/axis2/services/ y verás el webservice myVirtualShop desplegado junto al Version de Axis2.

Por supuesto todo este proceso de empaquetamiento y despliegue se podría automatizar un poco más con un nuevo task de ANT. También se podría haber ejecutado Axis2 sobre un Tomcat. He preferido dejarlo así por sencillez.

Bien, pues esto es todo entonces. Si no puedes esperar al siguiente artículo para crear un cliente y probar el webservice, puedes usar alguna herramienta tipo XMLSpy, JMeter o SoapUI que permiten invocar las operaciones de un webservice a partir de su WSDL. Para acceder al WSDL de un servicio Axis basta con añadir el sufijo ?wsdl al endpoint del servicio, sería: http://localhost:8080/axis2/services/myVirtualShop?wsdl.

Conclusiones
Me ha quedado un post realmente largo y a priori podría parecer que desarrollar un webservice con WSDL2Java es dificil y complicado, sobretodo si lo comparamos con los últimos Helloworld de Java2WSDL + anotaciones con Netbeans. Pero no sería una comparación justa, aquí se ha desarrollado un webservice con un interfaz relativamente complejo y no un simple Helloworld que devuelve un String.

Si bien en la actualidad WSDL2Java no es la metodología con mayor apoyo por parte de la industria, en mi opinión es la metodología más adecuada para construir un webservice de complejidad media/alta respetando al máximo la interoperabilidad, el principal objetivo de los webservices, y cuidando el desarrollo del interfaz del servicio.

Si el interfaz de un webservice son los mensajes XML qué mejor forma de definir el formato de un documento XML que con schemas XSD. Construir luego el WSDL puede costar al principio (como todo lo nuevo) pero en realidad es un proceso mecánico. A cambio obtendremos de un modo automático todas las clases Java necesarias para realizar el intercambio de mensajes. ¿Merece la pena aprender a construir un WSDL? Para mi sí, sin duda.

El libro resulta muy ameno, se lee en unos dias, no llega a 200 páginas, y está escrito con un inglés sencillo. Como encima tiene una versión gratuita en InfoQ (gracias Henrik Kniberg), no se le puede pedir mucho más. Totalmente recomendable.

Es muy curioso y envidiable ver que fuera de España, tener dias para trabajar desde casa, para autoformación o contar con grandes pizarras y salas donde reunirse no es ciencia-ficción. Y de seguir una metodología ágil ni hablamos…

Así, por ejemplo, en Oracle se emplea la pseudo columna rownum.

select * from MI_TABLA where rownum<=10;

En SQL Server, se usa la cláusula especial top.

select top 10 * from MI_TABLA;

En MySQL, existe la cláusula limit.

select * from MI_TABLA limit 10;

Pero, ¿y si necesitas una solución independiente de la base de datos?

Entonces no te queda otra que recurrir a JDBC y usar el método setMaxRows del interface java.sql.Statement. Veámoslo!

//Creamos una sentencia SQL
Statement select = conexion.createStatement();
//Limita el número de registros a devolver por la SELECT
select.setMaxRows(10);
//Ejecutamos el select
ResultSet resultadoSelect = select.executeQuery("select * from MI_TABLA" );

Si quieres usar un PreparedStatement no hay problema. Es el mismo método. Recuerda que PreparedStatement es un interface hijo de Statement. Veámoslo también.

//Creamos un preparedStatement
PreparedStatement pSelect = conexión.prepareStatement("select * from MI_TABLA where MI_CAMPO=?");
//Indicamos el parametro del select (pej un String)
pSelect.setString(1, "MI_VALOR");
//Limita el número de registros a devolver por la SELECT
pSelect.setMaxRows(10);
//Ejecutamos el select
ResultSet resultadoSelect = pSelect.executeQuery();

Es posible que esta solución sea menos eficiente que la solución nativa del SGBD. Pero eso ya depende del driver JDBC…

Axis2 puede utilizar SOAP 1.1, SOAP 1.2 y REST. Además soporta las especificaciones WS-Security, WS-ReliableMessaging, WS-Addressing, WS-Coordination y WS-Atomic Transaction.

Con esto, queda presentado Axis2. Para más información puedes consultar su página web.

Preliminares
Si quieres seguir este tutorial antes debes instalar:

• JDK 1.4 o superior, con la variable de entorno JAVA_HOME fijada.
• ANT 1.6.5 o superior. Para ejecutar los samples y generar una distribucion war a partir de la standard. No olvides añadir la carpeta bin al path y fijar la variable ANT_HOME.
• Tomcat 5.X o superior. En realidad servirá cualquier contenedor de servlets.

Descargar
Lo primero es bajarse el Axis2. En la página donde descargar Axis2 se pueden encontrar los siguientes tipos de distribución:

• Standard Binary Distribution. Es la versión completa de Axis2. Puede ejecutarse, a diferencia de Axis1, como un servidor independiente o generar una aplicación web para desplegar en un contenedor de servlets. Contiene además las herramientas wsdl2java, java2wsdl y los samples.
• Source Distribution. Contiene el código fuente y puede generarse una versión ejecutable con Maven.
• WAR (Web Archive) Distribution. Esta es una versión lista para ser desplegada como una aplicación web en un contenedor de servlets.
• Documents Distribution. Es un zip con toda la documentación.

Descargamos la primera opción, Standard Binary Distribution, y se descomprime en una ruta a nuestra elección.
A continuación se debe crear la variable de entorno AXIS2_HOME para que apunte a la ruta donde se ha descomprimido Axis2, pej: /opt/axis2

NOTA: En el momento de realizar este tutorial la última versión de Axis2 es la 1.2, durante el resto del tutorial se supondrá que se está trabajando con esta versión.

Estructura
Echemos un vistazo al Axis2 que acabamos de instalar y encontraremos la siguiente estructura de carpetas:

• bin: contiene scripts para ejecutar Axis2 como un servidor standalone y ejecutar las herramientas wsdl2java y java2wsdl.
• conf: incluye el fichero de configuración axis2.xml.
• lib: las librerias que usa Axis2.
• repository: contiene los servicios (webservices) y módulos disponibles.
• samples: códigos de ejemplo.
• webapp: contiene la aplicación web de administración de Axis2. Se incluye sólo para la generación de una distribución war de Axis2.

Modo standalone
Axis2 puede ejecutarse de 2 modos, como aplicación web desplegada en un contenedor de servlets o como servidor standalone gracias a un mini servidor web que trae integrado.

El modo standalone es una novedad respecto a Axis1 y muy útil para el desarrollador en entornos limitados. Usa el script axis2server de la carpeta bin para arrancar el servidor de Axis2. Abre la página http://localhost:8080/axis2/services para comprobar que Axis2 se ha iniciado correctamente. Podras ver el único webservice desplegado, llamado Version, y obtener su WSDL (ver figura 1).

Por defecto, el servidor standalone de Axis2 usa el puerto tcp 8080. Si quieres, puedes cambiarlo en el fichero de configuración axis2.xml de la carpeta conf.

<transportReceiver name="http" class="org.apache.axis2.transport.http.SimpleHTTPServer">
    <parameter name="port">6060</parameter>
     […]
</transportReceiver>

Si usas JDK6 y tienes problemas, debes copiar el stax-api.jar de la carpeta lib de Axis2 a la carpeta lib/endorsed del JRE o common/endorsed del Tomcat si vas a usar Axis2 en Tomcat.

Despliegue en caliente de webservices
Una de las novedades más importantes de Axis2 es la posibilidad de desplegar en caliente webservices. Para ello basta con copiar el webservice al repositorio, carpeta services. Adios al AdminClient de Axis1!

El modelo de despliegue de Axis2, similar al nuevo modelo J2EE, define un formato para empaquetar los webservices. Un fichero .aar (en realidad es un jar) que contendrá los ficheros class, jar y recursos del webservice más un fichero de configuración dentro de la carpeta META-INF llamado services.xml.

¿Vemos un ejemplo?

1. Abre una consola y colocate en la carpeta samples/pojo de Axis2.
2. Ejecuta: ant. Si no funciona correctamente revisa que el path contiene la carpeta bin de ant y revisa también las variables de entorno JAVA_HOME, AXIS2_HOME y ANT_HOME.
3. Se habrá creado una carpeta build y dentro el fichero AddressBookService.aar. En realidad es un jar, así que puedes abrirlo con un simple descompresor. Dentro están las clases del webservice y el fichero de configuración services.xml que define el nombre, ámbito, receptores de mensajes y el nombre de la clase principal del servicio. Es muy sencillo, lo veremos en detalle cuando veamos cómo desarrollar webservices.

<service name="AddressBookService" scope="application">
    <description>
       POJO: AddressBook Service
    </description>
    <messageReceivers>
       <messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-only"   class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver"/>
       <messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out"   class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
    </messageReceivers>
    <parameter name="ServiceClass" locked="false">sample.addressbook.service.AddressBookService</parameter>
</service>

4. Copia el fichero AddressBookService.aar a la carpeta repository/services de Axis2 y ya está!
5. Abre de nuevo http://localhost:8080/axis2/services en un navegador y verás como el servicio AddressBookService se ha desplegado sin tener que reiniciar el servidor (ver figura 2).

Este nuevo modelo de despliegue permite también la actualización en caliente de un webservice (aunque por defecto está desactivada). Las características de despliegue y actualización en caliente pueden configurarse en el fichero axis2.xml.

<axisconfig name="AxisJava2.0">
    <parameter name="hotdeployment">true</parameter>
    <parameter name="hotupdate">false</parameter>
    […]
</axisconfig>

Modo aplicación web
Aunque el modo standalone es muy útil, lo normal es distribuir Axis2 como una aplicación web para usar toda la potencia y funcionalidad de nuestro contenedor de servlets favorito.

Veamos cómo generar un Axis2 war:

1. Abre una consola y colocate en la carpeta webapp de Axis2.
2. Ejecuta: ant.
3. Se habrá generado el fichero axis2.war dentro de una nueva carpeta dist en Axis2. Esta distribución contiene el fichero de configuración axis2.xml (carpeta conf) y los webservices (services) y módulos (modules) del repositorio de Axis2 en el momento de ser generada.

Por supuesto, siempre está la opción de bajarte la distribución WAR directamente.

La distribución web de Axis2 contiene una aplicación de administración. Vamos a verla. Copia el axis2.war generado a la carpeta webapps del Tomcat. Arranca el Tomcat y abre http://<host>:<port>/axis2 en un navegador (ver figura 3).

Puedes listar los servicios disponibles, validar el estado y administrar Axis2. El usuario es admin/axis2 (puede modificarse en axis2.xml). Con él puedes gestionar los servicios y módulos existentes, además de subir nuevos servicios que serán desplegados automáticamente gracias al despliegue en caliente de Axis2.

Hay que tener en cuenta que las modificaciones que hagamos se perderan con el reinicio del Tomcat o del Axis2. Para que los cambios en la configuración perduren deben hacerse directamente en el fichero axis2.xml. Por eso, si se va a estar "tocando" la configuración o los servicios lo mejor será descomprimir el axis2.war en webapps/axis2 y borrar el axis2.war de webapps.

Hasta aquí, esto es todo. Sé que me dejo muchas cosas, como módulos, desarrollo de servicios, clientes, handlers, seguridad, etc. Lo veremos poco a poco, el siguiente tema será cómo desarrollar un webservice desde WSDL.