Cómo usar parametros para un webservice en Axis2

Practicamente cualquier aplicación medio seria necesita usar parametros de configuración. Un webservice no iba a ser diferente.

Alternativas hay para todos los gustos o más bien para todas las necesidades, desde crear un fichero properties para ese par de parametros de configuración a uno xml para configuraciones algo más estructuradas. Incluso he llegado a ver usar el fichero properties-service.xml de JBoss. Una mala práctica que no aconsejo, mejor el properties o xml empaquetado dentro de la aplicación y evitamos ataduras innecesarias.

Pero en el caso de desarrollar un webservice con Axis2, el propio Axis2 nos ofrece otra alternativa: el fichero services.xml del propio webservice.

Veamos un ejemplo de cómo almacenar parametros de configuración simples y complejos dentro del fichero services.xml:

<service name="miWebservice">
<description>La descripcion de mi webservice</description>
<parameter name="ServiceClass">path.to.my.ServiceClass</parameter>
 <parameter name="UnParametroSimple">UnValorSimple</parameter>
 <parameter name="UnParametroComplejo">
    <mailconfig>
       <username>Raska</username>
       <password>caracola</password>
       <host>http://mail.mydomain.org</host>
    </mailconfig>
 </parameter>
<operation name="operacion">
</operation>
</service>

Y ahora para obtenerlos hay que hacer uso de la clase MessageContext, obtener el contexto actual y usar el método getParameter teniendo en cuenta que estamos recuperando objetos de tipo OMElement. Un código para el ejemplo anterior seria el siguiente:

MessageContext msgContext = MessageContext.getCurrentMessageContext();
Parameter parametroSimple = msgContext.getParameter("UnParametroSimple");
Parameter parametroComplejo = msgContext.getParameter("UnParametroComplejo");

System.out.println("Parametro Simple " + myParameter.getParameterElement().getText());
System.out.println("ParametroComplejo " + myXMLParameter.getParameterElement());

Cómo obtener la dirección IP de los clientes de tu webservice en Axis2

Suele ser habitual realizar una auditoría sobre las invocaciones de nuestros webservices. Además de la operación, fecha y hora, petición y respuesta, una de las cosas más interesantes a guardar es la dirección IP del cliente. Este dato quizás no es tan trivial de obtener, hay que hacer uso del objeto MessageContext asociado al mensaje recibido. Por lo que aquí os dejo el código:

MessageContext msgCtx = MessageContext.getCurrentMessageContext();
String remoteAddress = (String)msgCtx.getProperty("REMOTE_ADDR");

Otras cosas interesantes que se pueden obtener son los objetos ServletContext y HttpServletRequest:

ServletContext servletContext = (ServletContext)msgCtx.
    getProperty("transport.http.servletContext");

HttpServletRequest httpServletRequest = (HttpServletRequest)msgCtx.
    getProperty("transport.http.servletRequest");

Cómo invocar un webservice desde eclipse

Otra herramienta que he descubierto en mi vuelta a los webservices es el Web Services Explorer de eclipse, una de las muchas aportaciones de IBM al ide que permite invocar servicios web de una forma visual y relativamente sencilla desde nuestro eclipse.

Para usarlo hay que tener instalada la Web Tools Plataform en tu eclipse (lo más cómodo es bajarse el all-in-one) y pulsar en la opción Run -> Launch the Web Services Explorer.

Lo siguiente será seleccionar el webservice a invocar, para ello podemos cargar su WSDL pulsando en el segundo botón de la derecha (WSDL Page) y luego en WSDL Main en Navigator.
A continuación debemos introducir la URL donde esté publicado el WSDL del servicio web y pulsar en Go.

Tras unos instantes, si todo va bien, se habrá generado un cliente para el webservice y podrás ver sus operaciones y sus endpoints. Estos últimos son editables.

A partir de aquí es tan sencillo como seleccionar una operación y rellenar los datos necesarios para invocar al servicio web. Las peticiones y respuestas se pueden ver tanto en el interfaz gráfico (modo Form) como en XML (modo Source).

Como punto negativo decir que a veces el interfaz gráfico no se genera correctamente con mensajes muy complejos y además no es que sea muy intuitivo. Aunque no lo parezca, si haces doble-click sobre los títulos de los paneles se maximizan.

Cómo incluir el stacktrace dentro de un AxisFault en Axis2

La vida da muchas vueltas y heme aquí de nuevo trabajando con Axis2, ueeee! (auto-ola para mi).

Una cosa que siempre me ha parecido muy molesta es que los AxisFault no incluyen la información relativa al stacktrace de la excepción que los generó. Esto puede llegar a ser muy molesto, especialmente durante las pruebas de integración donde no sueles disponer de acceso directo a los ficheros de log. Afortunadamente en Axis2 existe una solución muy sencilla.

Para incluir dentro de un AxisFault el stacktrace de la exception que lo generó, basta con cambiar estos dos parámetros del fichero de configuración de Axis2 (conf/axis2.xml) de false a true:

<parameter name="sendStacktraceDetailsWithFaults">false </parameter>
<parameter name="DrillDownToRootCauseForFaultReason">false </parameter>

y a continuación reiniciar o redesplegar el Axis2.

Tiempo de vida por defecto para una sesion en Tomcat

Una de las cosas que suelen olvidarse durante el desarrollo de una nueva aplicación web es configurar el tiempo de vida o timeout de la sesión http en el fichero web.xml de la aplicación. Y si esto pasa, ¿habrá timeout o no? Y si lo hay ¿cuándo?

Pues ésto es lo último que he aprendido. En Tomcat existe un fichero web.xml para todos los valores por defecto no fijados en los web.xml de cada aplicación. Se encuentra en la carpeta conf. Si echamos un vistazo por él, encontraremos esto:

<session-config>
<session-timeout>30</session-timeout>
</session-config>

Así que la respuesta es... 30 minutos, qué máquinas! Si queremos modificarlo, añadimos la configuración en el web.xml de nuestra aplicación con el valor deseado, -1 para no tener timeout. Pero esto seguro que ya lo sabiais.

NetTool: cliente HTTP y tunneling TCP en Java

Lo mejor de trabajar en equipo y ser colaborativo es que se aprenden muchas cosas, desde algo sencillo como un atajo con el Eclipse a descubrir una herramienta que es una joya como NetTool.

NetTool te permite hacer de cliente HTTP y tunneling TCP de forma muy sencilla. Un cliente HTTP viene muy bien para hacer peticiones directamente contra una aplicacion web, pero sobretodo contra servicios ajax o incluso servicios web y ver el resultado en un momento. Especialmente para hacer pruebas de seguridad XSS.

El tunneling se hace también de forma muy sencilla y te permite examinar el tráfico que ocurre entre dos extremos de una comunicación TCP. Ideal para ver lo que realmente está pasando cuando un equipo hace el servidor y otro el cliente, algo falla y todo el mundo se echa las culpas entre sí, ¿os suena?.

Además la aplicación está hecha en Java, es decir es multiplataforma, y su interfaz está más que cuidada, facilitando su uso enormemente. No es por hacer publicidad, que no me llevo nada, pero también tiene un montón de looks&feels, incluyendo JGoodies! En definitiva, muy recomendable.

Revisiones de código automatizadas con Eclipse

No es fácil establecer una política de revisiones de código que funcione. Por un lado está la resistencia que puede ofrecer el programador que va a ser revisado y por otro la dificultad de encontrar el tiempo necesario que tiene que dedicar el programador que tiene que hace la revisión.

Una buena idea para evitar malos rollos y optimizar el tiempo del equipo es automatizar las partes repetitivas y propensas a descuidar de las revisiones, como los estándares de codificación, longitudes de clases y métodos, código duplicado, malas prácticas, etc. dejando las revisiones por parejas para temas de más alto nivel y diseño.

Entonces un primer paso de una política de revisiones de código debe ser integrar herramientas de este tipo en el ide de los programadores, para que ellos solos puedan mejorar y asegurar la calidad de su código.

A continuación os comento algunas de estas herramientas que he instalado en mi eclipse para evaluar y poder mejorar el proceso de desarrollo de mi equipo.

PMD
Detecta posibles bugs, malas prácticas, código duplicado y código excesivamente complejo en base a un potente juego de reglas configurables.
He tenido problemas al instalarlo copiándolo directamente a la carpeta plugins del eclipse y tuve que hacerlo con el Find and Install del menú Help/Software Updates del eclipse. Es sencillo, sólo hay que añadir http://pmd.sourceforge.net/eclipse como New Remote Site y continuar el asistente.

La primera impresión que te llevas al analizar tu código con PMD es un poco avergonzante, es increible la cantidad de reglas que saltan en cada clase del que hasta ahora era un código del que te sentias orgulloso. Algunas de ellas son bastante discutibles, como evitar construcciones tipo if (x!=y)..;else..; a favor del operador ?, no usar más de una sentencia return en un método o declarar variables y parametros final.

La prioridad por defecto de las reglas no me gusta, mete mucho ruido en el análisis. Por ejemplo, da la misma importancia a que un parametro no sea final que a un método que se salte el número máximo de líneas o de complejidad ciclomática. A su favor, decir que detecta código duplicado además de malos usos de excepciones, loggers, constantes, clases antiguas como Vector, etc. En conclusión, una herramienta útil pero que necesita de una buena y larga configuración para hacerla efectiva.

CheckStyle
Otro analizador de código Java que cuenta con dos plugins para Eclipse, el de David Schneider y el de Marco van Meegen. Yo prefiero el primero con diferencia. Se instala via eclipse añadiendo la url http://eclipse-cs.sourceforge.net/update/ como New Remote Site en Help -> Software updates -> Find and install.

CheckStyle tiene un juego muy completo de reglas, que a diferencia de PMD tiene en cuenta también los estándares de codificación de Sun, con reglas hasta para los espacios y tabuladores. Ésto provoca que hacer un análisis con CheckStyle emita un buen número de violaciones, algunas importantes y otras no tanto.

Afortunadamente es muy flexible de configurar. Es realmente sencillo crear una nueva configuración e ir añadiendo las reglas que quieras, con la prioridad y parametros de tu gusto. Merece la pena.
Como punto negativo decir que el icono de violación en el editor podía estar más cuidado y cambiar de color según la severidad de la violación. Además no tiene una perspectiva propia en Eclipse, hay que añadir las vistas a mano.

FindBugs
Se puede instalar desde Eclipse usando http://findbugs.cs.umd.edu/eclipse como New Remote Site.

No es tan completo como los anteriores, sólo sirve para encontrar posibles bugs y malas prácticas. Aún así es muy bueno en lo que hace, tiene su propia perspectiva en Eclipse con una interfaz muy cuidada que lo hace muy fácil de usar.

Entonces como herramienta única no es suficiente, pero si se puede usar junto a otra que realice la parte de reglas sintácticas y métricas.

Elementos negativos

En todos los equipos siempre hay un miembro más negativo que el resto, llamémosle H. Esto es así, igual que hay uno más alto, uno más lento o uno más feo. Y es responsabilidad del jefe de equipo que todo el mundo se sienta integrado y agusto para poder rendir al máximo. Un buen ambiente eleva la productividad, pero se hace difícil lograrlo cuando tienes a H con su pataleta quejica, su punto de vista egoista, su poca predisposición o simplemente no señalando en la dirección que te gustaría.

No se debe caer en la táctica fácil de señalar, aislar y hablar mal de nuestro negativo como si de un cancer se tratara, pensando que con un poco de suerte se busca otro trabajo o se le acaba el contrato y adiós. Esta es la táctica del jefe mediocre y cobarde, capaz de llevarse un proyecto por delante y amargar por el camino a una persona que seguramente no haya hecho nada malo.

Porque H, nuestro elemento negativo, en realidad suele ser de un pérfil como mínimo avispado, con talento y bastante idealista. ¿Entonces qué ha pasado? Bueno, la vida es dura y seguramente no contaba con toparse con lo que se ha topado en su vida laboral. Su pequeño idealista ahora está enrabietado, confuso y decepcionado con el mundo, y ademas quiere manifestarlo, ganándose así la etiqueta de H el negativo.

¿Qué hacer entonces?
Es difícil y desde luego no existe una solución rápida, así que no debe buscarse. Desde luego lo que un jefe de equipo no debe hacer nunca es hacer de menos, llamar negativo, hacer bromas pesadas y sobretodo comparar su situación con la de otro. Esto sólo empeoraría las cosas y con razón.

Sí que se debe intentar dar ejemplo siendo optimista, colaborativo y pasándolo bien trabajando en equipo. Preocupate por su situación, busca asignarle tareas que para él sean atractivas, sé justo y premia su buen trabajo. No esperes resultados a corto plazo. Date al menos seis meses para que tus esfuerzos den algún fruto y nunca olvides que la responsabilidad del grupo es tuya, el fracaso será sólo tuyo.

Un nuevo comienzo

Este año 2008 me ha traido un nuevo y deseado cambio en lo profesional, abandono mi labor en una software factory para volver a la consultoria. Nueva compañia, nuevas responsabilidades, nuevos proyectos, nuevo cliente, nuevos compañeros y... ¿por qué no? nuevo blog.

Un nuevo blog pero con un viejo objetivo: compartir experiencias. Compartir experiencias sobre desarrollar en Java, libros, gestión de equipos, prácticas ágiles, testing y lo que caiga.

Atrás dejo mi anterior blog con la espinita clavada de no haber profundizado como me hubiera gustado en Axis2. Esta vez espero hacerlo mejor y escribir más.

About me

Contacto
julio.cesar.perez.arques ARROBA gmail PUNTO com

Bio
Julio César Pérez Arques es un ingeniero informático con más de 5 años de experiencia en Java que trabaja actualmente como Analista para la consultora multinacional Steria en diversos proyectos J2EE. Anteriormente formó parte de otras empresas como Everis, Hewlett-Packard y Software AG, trabajando para clientes como Telefónica España y la CARM, especializándose en proyectos de Administración Electrónica con SOA y Webservices.