Uso básico de AmberPoint express con Axis

1
13663

Uso básico de AmberPoint express con Axis


En este tutorial se muestra cómo utilizar AmberPoint Express
para monitorizar
un servicio web que hayamos hecho nosotros, y se cuentan algunas cosas inesperadas
que he encontrado.

Por Javier Cámara (jcamara@softwareag.es)
Arquitecto de software en el BCS Competence Center de Software AG España.

Introducción

AmberPoint es un producto para gestionar SOAs en base a
agentes distribuidos que se instalan en los clientes y servidores de la SOA, monitorizando
y asegurando su tráfico, así como otras funciones de gestión y gobierno como la redefinición
de los puntos de acceso.
En este tutorial instalaremos AmberPoint Express,
la versión gratuita de AmberPoint, y
veremos qué nos permite hacer. Lo haremos con la aplicación de demo que trae, y también
con el servicio web que creamos en un tutorial previo,
invocándola a través del cliente correspondiente que creamos en otro tutorial.
Como veremos, esto desvelará algún problema en AmberPoint Express.

El resto del tutorial contiene lo siguiente:

Instalación de AmberPoint Express para Tomcat/Axis

AmberPoint, al contrario que otras soluciones centralizadas como los ESBs, utiliza una arquitectura distribuida
e instala agentes allí donde están los servicios y sus clientes. Por ello necesita versiones diferentes
para cada plataforma donde los agentes se vayan a instalar, y por eso hay también diversas versiones
de AmberPoint Express. Nosotros, como de costumbre, usaremos la versión para Java, en particular
la de Tomcat/Axis (hay otra para WebSphere). Te puedes descargar esta versión desde
el sitio de AmberPoint
tras registrarte gratuitamente. Viene con un Tomcat y Axis, y si no tenemos
una máquina virtual Java instalada él mismo nos instala una.

La instalación es muy sencilla, sólo hay que ejecutar AmberPointExpressJava.exe y
seguir las instrucciones:

  • Nosotros hemos elegido la opción de instalación «Tomcat», que instala tanto el Tomcat con Axis
    como la aplicación de demo:

  • En nuestro caso ya tenemos máquinas virtuales instaladas, así que elegimos una de ellas:

  • Luego elegimos el directorio de instalación (aquí lo hemos puesto bajo
    C:\Archivos de programa, pero puedes dejar el que viene por omisión si quieres):

  • Después elegimos el grupo de programas donde se instalará:

  • Luego escogemos el puerto donde escuchará el Tomcat del AmberPoint, que no debe
    estar siendo usado por ningún otro servidor:

  • Después de esto nos puede salir un aviso del firewall de Windows XP. Debemos decirle
    que permita al instalador continuar pulsando «Desbloquear»:

  • Después de eso, la instalación ya va sola. Al final nos pregunta si queremos arrancar
    Tomcat, y le diremos que sí, pero que no estamos interesados en ver el README:

Si todo va bien, después de un rato veremos la pantalla principal de la consola de AmberPoint
Express, de lo cual hablaremos en la siguiente sección.

Uso de AmberPoint Express con la aplicación de demo que trae

Tras arrancar el Tomcat que viene con AmberPoint Express, si todo va bien veremos la pantalla principal
de la consola:

Ahí, en la parte superior izquierda, vemos los servicios que AmberPoint Express ha descubierto
automáticamente
que están instalados en el Tomcat. O sea, son los servicios de la propia
aplicación de demo de AmberPoint Express, pues son los únicos que hay instalados en ese Tomcat. Es
capaz de descubrir automáticamente todos esos servicios porque esta versión está especialmente
programada para hacerlo en un entorno Tomcat y Axis, pero no servirá para otro tipo de servicios
o servidores de aplicaciones. Pinchando en cualquiera de esos servicios veremos más información
sobre el mismo:

Para que AmberPoint Express pueda monitorizar un servicio, éste tiene que estar gestionado
(managed). Por omisión ningún servicio lo está, así que vamos a hacer que AmberPoint gestione
todos los servicios de demo que trae. Para eso pinchamos en cada uno para ver sus detalles y luego
le damos al botón de . Cuando hacemos eso, AmberPoint Express va
a alterar la aplicación web que alberga al servicio de la siguiente forma:

  • Incluye librerías adicionales en su WEB-INF\lib
  • Define un nuevo filtro de servlets en el web.xml que «espía» todo el tráfico
    que pasa por el URL del servicio

El uso de un filtro de servlets (en vez de un handler de Axis) es interesante y apropiado,
pues así puede funcionar con otros motores de servicios web Java.

Una vez AmberPoint ha completado la habilitación de la gestionabilidad para el servicio,
los detalles del mismo nos muestran unas estadísticas sobre el tráfico de ese servicio,
con una bonita interfaz Flash:

Y como podemos ver en la lista de la izquierda, ahora, además del nombre del servicio, por omisión
nos aparecen las operaciones que ofrece. Después de que hayamos puesto todos los servicios
bajo la gestión de AmberPoint Express, veremos esto:

Ahora vamos a abrir, en una nueva ventana del navegador, la aplicación de demo que trae
AmberPoint Express en http://localhost:8480/apexpressdemo/ui/client.xhtml
y a ejecutarla para provocar tráfico con esos servicios:

Si ahí seleccionamos las cajitas de todos los servicios y luego le damos al botón de
, la aplicación de demo comenzará a enviar mensajes.
Pulsando en el botón la misma aplicación de demo
nos informa de la cantidad de mensajes enviados, pero la gracia está en volver
a la consola de AmberPoint Express y ver que los gráficos de
tráfico se actualizan automáticamente:

También, pinchando en la pestaña de podemos ver la lista
de mensajes intercambiados:

Así como el detalle de cada uno de esos mensajes:

Así pues, como vemos, AmberPoint Express monitoriza y registrar el tráfico recibido por los
servicios, y ofrece algunas utilidades para consultarlo. Otras soluciones de AmberPoint
más completas (y de pago, claro) ofrecen más cosas, como seguimiento de políticas de servicios,
gestión de las direcciones de los servicios (ej. cambio), seguridad, etc.

Lo que hemos hecho hasta ahora ha sido simplemente ejecutar la propia demo que trae AmberPoint
Express. Pero claro, nosotros queremos usarlo en nuestra propia aplicación,
así que vamos a ello.

Uso de AmberPoint Express con nuestro servicio y aplicación de sucursales

En tutoriales previos hicimos un servicio web que buscaba las sucursales de un banco,
y una aplicación AJAX que accedía a él. Ahora vamos
a ver qué tal monitoriza AmberPoint express este servicio.

Aquí tienes un sucursales.war que puedes desplegar dentro del
Tomcat de AmberPoint Express y que contiene tanto el servicio web como la página de la aplicación
AJAX. Para desplegarlo, simplemente cópialo en el directorio webapps de AmberPoint
Express (ej. C:\AmberPoint\Express\server\webapps
o C:\Archivos de programa\AmberPoint\Express\server\webapps) y reinicia el Tomcat
(lo puedes parar y arrancar con los iconos de programa que creó la instalación de AmberPoint
Express). Luego volvemos a la consola de AmberPoint Express
(http://localhost:8480/apexpress/)y pinchamos en el
enlace de Discover. Aparentemente todo irá bien:

Pero en realidad, algo malo ocurre: no nos ha descubierto nuestro servicio. Aunque nos diga que
No problems discovering Web services, y tampoco veamos nada malo si pinchamos en el
enlace de View application log, si vamos a la caja de comandos del Tomcat
(«Tomcat hosting AmberPoint Express (Port 8480)»), vemos que ahí sale un problema:

AmberPoint In-server Agent "apManufacturerSystem" started:
    build 3344 of express (Express_Kit_Refresh/56108) on 2006-01-18
AmberPoint In-server Agent "apRetailerSystem" started:
    build 3344 of express (Express_Kit_Refresh/56108) on 2006-01-18
AmberPoint In-server Agent "apWarehouseSystem" started:
    build 3344 of express (Express_Kit_Refresh/56108) on 2006-01-18
PARSE error at line 2 column 234
org.xml.sax.SAXParseException: Element type "web-app" must be declared.

Para empezar, dice poco del AmberPoint Express el que nos diga que no hay problemas cuando
no es así. El problema parece ser que el el web.xml que en su momento nos creó el Eclipse no le gusta
al AmberPoint Express. Es un web.xml versión 2.4 que usa XML Schema en vez de DTDs:

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID"
    version="2.4"
    xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
    <display-name>

Puede que el problema sea porque mi PC está detrás de un proxy (y al no configurarlo el Tomcat no
puede descargarse el XSD), o más probablemente
que AmberPoint Express no soporta esa versión de web.xml. En fin, para quitarnos de historias pondremos una declaración
igual a la que tienen las aplicaciones de demo de AmberPoint Express, que usan la versión 2.3.
Así pues, paramos el Tomcat
del AmberPoint Express y editamos el web.xml de nuestra aplicación sucursales, que está
desplegada ya dentro de webapps (ej. en
C:\AmberPoint\Express\server\webapps\sucursales\WEB-INF):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
        PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
        "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
    <display-name>

Pero esto no es suficiente: hay más cosas en el web.xml que nos creó
Eclipse que no coinciden con la v2.3 y que siguen causando errores en el AmberPoint.
Así que seguimos editando el web.xml y donde pone:

    <servlet>
        <display-name>
        Apache-Axis Servlet</display-name>
        <servlet-name>AxisServlet</servlet-name>
        <servlet-class>
        org.apache.axis.transport.http.AxisServlet</servlet-class>
    </servlet>
    <servlet>
        <display-name>
        Axis Admin Servlet</display-name>
        <servlet-name>AdminServlet</servlet-name>
        <servlet-class>
        org.apache.axis.transport.http.AdminServlet</servlet-class>
        <load-on-startup>100</load-on-startup>
    </servlet>

Intercambiamos el orden de servlet-name y display-name:

    <servlet>
        <servlet-name>AxisServlet</servlet-name>
        <display-name>
        Apache-Axis Servlet</display-name>
        <servlet-class>
        org.apache.axis.transport.http.AxisServlet</servlet-class>
    </servlet>
    <servlet>
        <servlet-name>AdminServlet</servlet-name>
        <display-name>
        Axis Admin Servlet</display-name>
        <servlet-class>
        org.apache.axis.transport.http.AdminServlet</servlet-class>
        <load-on-startup>100</load-on-startup>
    </servlet>

Si queremos, podemos borrar también ya el sucursales.war que desplegamos antes,
pues una vez la aplicación está desplegada (y, sobre todo, modificada) no sirve para nada.
Arrancamos de nuevo Tomcat, y ahora ya no sale ningún error en la caja
de comandos del Tomcat. Vamos a la consola del AmberPoint Express y vemos que ahora sí nos
ha encontrado a nuestro servicio Sucursales:

Pinchamos en él y lo ponemos bajo la gestión de AmberPoint Express pulsando el
botón , tras lo cual ya tenemos acceso a la monitorización de
nuestro servicio:

Vale, pues ahora vamos a invocar a nuestro servicio con la aplicación AJAX que hicimos.
Para eso nos conectamos a http://localhost:8480/sucursales/sucursales.html.
Para esta primera prueba utilizaremos Internet Explorer:

Y le damos al botón de Buscar sucursales, pero ¡héte aquí que nos encontramos con
un error!:

¿Cómo que The root element is required in a well-formed document? ¿Es que no le hemos
mandado un XML correcto? Vamos a ver, ejecutemos lo mismo con Firefox en vez de con Internet Explorer:

¡Con Firefox funciona! Y de hecho, con Internet Explorer también… siempre que el servicio
no esté gestionado con AmberPoint
. Efectivamente, si sacamos al servicio Sucursales de la gestión
de AmberPoint Express (botón en la consola de AmberPoint Express),
podemos comprobar cómo con Internet Explorer funciona perfectamente. Pero en cuanto
ponemos al servicio bajo la gestión de AmberPoint Express, deja de funcionar, ya esté ejecutándose
el Internet Explorer en la misma máquina o en otra remota.

Parece claro que el filtro de servlets de AmberPoint Express, que debería ser invisible para
el servicio, está impidiendo que el mensaje le llegue correctamente. Ni la consola ni el log
de AmberPoint Express dejan ningún rastro de la operación fallida.
En fin, yo ya he
informado
de este problema en los foros de AmberPoint Express, pero en el momento de escribir estas
líneas no he recibido ninguna respuesta útil al respecto.

Una conclusión interesante que sacamos de este problema es que AmberPoint Express no registra
ninguna información de estos mensajes fallidos
, aún cuando Axis sí ha devuelto una SOAP Fault.
Si cambiamos sucursales.html para que genere un mensaje incorrecto y lo mandamos desde Firefox,
la lista de mensajes de AmberPoint Express sí muestra la SOAP Fault devuelta por Axis:

Pero no así con el otro tipo de Fault. Quizás ambas cosas (el que Axis no reciba el mensaje bien
y el que no se registre) se deben a lo mismo, ej. a un fallo interno del filtro de servlets
de AmberPoint Express que impide que ambas funciones terminen correctamente. T-t-t : es una
mala cosa, eso de comerse errores.

Aparte de con Internet Explorer, resulta que también falla con un cliente muy sencillo: un programita Java
que usa la clase URLConnection para enviar el SOAP. Con Firefox, XML Spy,
el Web Services Explorer de Eclipse o Axis (que por debajo no utiliza URLConnection)
funciona bien.
Y si ponemos entre el cliente y el servidor el TCPMon de Axis para ver el tráfico, lo cierto es que
este que no interfiere entre el tráfico: los clientes que fallan siguen fallando,
y los clientes que funcionan siguen funcionando.

Resulta un poco decepcionante, aunque hay que recordar que AmberPoint Express es sólo una versión
gratuita específica
, y no el producto comercial.

En fin, si seguimos usando Firefox o cualquiera de esos otros clientes para enviar mensajes a nuestro
servicio, veremos que AmberPoint Express nos permite lo que ya hemos visto: monitorizar los mensajes
que se le envían, su tiempo de respuesta, etcétera.

Uso de AmberPoint Express en otro Tomcat y Axis

Hasta ahora hemos probado AmberPoint Express sólo con el propio Tomcat que él mismo trae,
pero esto no es muy útil para situaciones reales, donde tenemos nuestro propio servidor de aplicaciones.
Aunque la documentación habla sólo de
Tomcat 4, nosotros vamos a ver qué pasa cuando lo instalamos en Tomcat 5. Para eso,
vamos a:

  1. Aún en el Tomcat de AmberPoint Express, desde la consola del mismo dejar de gestionar
    nuestro servicio Sucursales, para que quite las entradas que tiene en el web.xml

  2. Copiar, desde el directorio webapps del Tomcat de AmberPoint al de nuestro
    Tomcat, las aplicaciones apexpress y sucursales

Y después arrancamos nuestro Tomcat. Primero vamos a comprobar, por si acaso, que nuestra aplicación
y servicio funcionan bien, conectándonos ej. a http://localhost:8080/sucursales/sucursales.html
y dándole al botón de Buscar sucursales. Si todo va bien, lo siguiente nos vamos a
conectar a la consola de AmberPoint Express, por ejemplo
en http://localhost:8080/apexpress/.
Lo primero, nos encontramos un error:

Y también salen unos cuantos errores en la caja de comandos del Tomcat, pero no hay que preocuparse:
esto ocurre (creo) por haber cambiado de directorio a AmberPoint Express,
que graba cosas en otros directorios. Si pinchamos en Re-discover the Web Services podremos
acceder a la consola:

Salen unos cuantos errores más en la caja de comandos, pero nos descubre bien los servicios,
encontrando el nuestro y cualquier otro que tengamos con Axis en ese Tomcat. En cualquier
caso, si pinchamos en nuestro servicio y le pedimos que lo gestione con el botón
, todo funciona bien:

Si ahora intentamos acceder a nuestro servicio con el cliente AJAX usando Internet Explorer,
veremos que sigue sin funcionar, aunque con un mensaje de error diferente:

Este tiene algo más sentido que el anterior: Axis se queja de que el XML que ha recibido está
cortado, supuestamente por AmberPoint Express. Por lo demás, todo funciona igual: el Firefox,
XML Spy, etcétera sí funcionan y podemos monitorizar la actividad del servicio:

En suma, que a pesar de ser Tomcat 5 en vez de Tomcat 4, y de algunos errores que salen en
la caja de comandos del Tomcat, aparentemente AmberPoint Express sí funciona.

Resumen y conclusiones

Hemos visto qué hace AmberPoint Express y para qué sirve: monitorizar servicios web (Axis), en teoría
sin alterar para nada ni la implementación ni la configuración de los mismos o de sus clientes.
Y que, además de funcionar en el Tomcat 4 que trae preinstalado, parece que también funciona
en Tomcat 5.
Aunque también nos hemos encontrado con algunos problemas:

Problema Solución
AmberPoint Express no entiende el web.xml 2.4 que generó Eclipse Editar el web.xml para que use y cumpla el DTD de web.xml 2.4
Si el cliente es Internet Explorer o Java usando URLConnection, AmberPoint Express impide el acceso al servicio Usar otro cliente (Firefox, XML Spy, Axis)

A mí me parece una herramienta muy interesante porque esto de usar agentes distribuidos para
monitorización, seguridad y otras cosas me parece mucho más interesante y con mucho más futuro
que utilizar ESBs; pero lo cierto es que estos problemillas de AmberPoint Express me han dejado
un poco decepcionado. Si algún día pruebo la versión comercial, ya os contaré.


1 COMENTARIO

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad