He decidido cambiar de blog. A partir de ahora podeis encontrarme en http://jcesarperez.blogspot.com/, aunque continuaré manteniendo este blog para no perder sus contenidos ya que en principio no tengo pensado mudarlos.
Un saludo y muchas gracias por vuestras visitas, emails y comentarios.
Todos hemos oido hablar de las mejoras de rendimiento de Java 6, especialmente para aplicaciones de escritorio, entonces ¿por qué no usar Java 6 para ejecutar Eclipse aunque desarrollemos con Java 5 o incluso Java 1.4? Sí, a algunos nos obligan a seguir viviendo en la prehistoria. Pero… ¿cuantás maquinas virtuales (jvm) tenemos instaladas? ¿Sabemos con cúal arranca Eclipse?
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
Viendo el referers del blog he observado que son muchos los que buscan ayuda para diseñar schemas XSD y ficheros WSDL.
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
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.
Hacía tiempo que llevaba oyendo maravillas de la serie de libros The Pragmatic Programmer y tenía muchas ganas de pillar uno. Por otro lado, mi cambio de trabajo a un rol con más gestión casi me obligaba a que el próximo libro que ocupara mi mesilla de noche fuera sobre management.
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.
En esta ocasión, y como paso lógico después de ver cómo desarrollar un webservice, voy a contar cómo construir un cliente para invocar un webservice utilizando WSDL2Java en Axis2.
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:
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:
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:
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");
}
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");
}
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
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,…
Siguiendo con el motor de webservices Axis2, en esta ocasión toca hablar sobre cómo desarrollar un webservice. Logicamente existen diversas formas de desarrollar un webservice, en el siguiente texto voy a contar cómo desarrollar un webservice siguiendo la metodología conocida por WSDL to Java y qué ventajas reporta. Antes permitidme introduciros brevemente en el mundo de los webservices.
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!
(more…)
Scrum and XP from the Trenches es el último libro que he leido. Llevaba un tiempo oyendo hablar de la metodología Scrum aplicada al desarrollo de software y me apetecia saber más, pero más que un libro teórico lo que estaba buscando era algo práctico y basado en la experiencia. No quería saber qué es Scrum sino cómo sería usarlo en un proyecto real.
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…
En ocasiones es necesario limitar el número de registros obtenidos mediante una consulta SQL. El problema es que no hay un modo estándar de hacer esto con SQL. Por normal general hay que recurrir a alguna extensión propia de cada SGBD.
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 es el nuevo motor de webservices de Apache. Su arquitectura ha sido diseñada desde cero, teniendo en cuenta las lecciones aprendidas con Axis1. Cabe destacar su mejor rendimiento, pero sobretodo su sistema de módulos que permite, de forma sencilla, añadir nuevas funcionalidades y soportar futuras especificaciones sobre webservices.
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:
Descargar
Lo primero es bajarse el Axis2. En la página donde descargar Axis2 se pueden encontrar los siguientes tipos de distribució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:
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?
<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>
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:
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.
He decidido empezar los tutoriales del blog con el nuevo motor de webservices de Apache: Axis2. Llevo un par de años trabajando en SOA y webservices, con Axis1 y Bea Weblogic8 sobretodo, y tengo mucha curiosidad por ver cómo funciona este Axis2.
Los contenidos que tengo pensado ir desarrollando en los próximos tutoriales son:
Y si me animo me gustaría compararlo todo un poco con Netbeans 6 y GlassFish. Pero eso ya será a partir de noviembre.
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Feb | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||
