Finalizo la serie destinada a los servicios web en glassfish con la monitorización. Glassfish ofrece múltiples opciones de monitorización que nos permiten conocer el rendimiento de nuestro servidor. En caso de que este rendimiento no sea el esperado, tendremos unos datos muy valiosos para poder cambiar la configuración del servidor y/o nuestra programación buscando mejoras en el mismo.
Por defecto estas opciones vienen desactivadas por lo que el primer paso será activarlas. Para ello dentro de la consola de administración, volvemos al apartado de servicios Web, seleccionamos el Servicio y en la ventana de la derecha nos dirigimos a la pestaña de Monitor-->Configuration.
En esta pantalla cambiamos el nivel de monitorización fijándolo en High y pulsamos guardar. A partir de este momento las llamadas al servicio Web serán monitorizadas. Arrancamos nuestra aplicación cliente, y ejecutamos varias veces las JSP que realiza la llamada al servicio Web.
Como resultado en la pestaña Mesagges vemos un listado con todas las llamadas realizadas por nuestro cliente del servicio Web. Por cada una de las llamadas podemos ver el tiempo de respuesta, el tamaño, la dirección IP del cliente, y si el resultado ha sido correcto o no.
Si seleccionamos uno de estos mensajes, haciendo click sobre la fecha, vamos a la pantalla con toda la información sobre el mensaje. En esta pantalla además de los datos anteriores podemos ver las variables de cabecera que ha enviado el cliente, o los mensajes de error producidos por la respuesta. Además si pulsamos en los botones View Request XML/View Response XML podemos ver los mensajes XML entrantes y salientes, algo que puede resultar muy útil en fases de desarrollo de la aplicación.
Por ultimo, el monitor de servicios Web nos ofrece unas estadísticas generales muy útiles. Datos relacionados con los tiempos de respuesta o el rendimiento medido en peticiones por segundos, nos pueden hacer ver la capacidad y los limites de nuestros servicios Web.
Vamos a dar un paso más en la monitorización accediendo al menú configuración, al apartado Monitoring.En esta pantalla vemos todos los servicios que podemos monitorizar en Glassfish. Para el caso que nos aborda basta con activar la monitorización en la JVM, HTTP Service y Web Container.
Una vez activados los servicios de monitorización, vemos como en el listado de mensajes nos aparece un enlace llamado Call Flow. A través de este enlace podemos visualizar en que servicio dentro de la arquitectura interna de Glassfish se ha consumido el tiempo de respuesta del mensaje.
En el menú Application Server --> Monitor se pueden ver estas y otras opciones de monitorización de las que se puede destacar:
Estareis de acuerdo conmigo en que es un pequeño lujo tener todas estas opciones de serie al trabajar con Glassfish. En fin... Yo sigo de pesca, la próxima parada puede ser cluster o grizzly... lo consultare con la almohada
Web services for Java EE 5 in Glassfish (4)
Ya hemos visto como se hace un servicio Web en JavaEE 5 e incluso hemos buceado un poco dentro de el código "no" generado. Ahora toca ver como realizar un cliente del servicio Web.
Para ello nos vamos a ayudar del netbeans 6. Gracias a el vamos a ver como generar un cliente de un servicio Web es una tarea extremadamente sencilla. No necesitamos conocer JSRs, ni especificaciones, tan solo necesitamos la dirección del servicio Web, del resto se encarga Netbeans y JAX-WS.
El cliente del servicio Web será otra aplicación Web, por lo que el primer paso es crear un nuevo proyecto. Una vez lo tenemos creado, mediante el asistente, creamos un cliente de un servicio Web:
El asistente nos da tres opciones para introducir la dirección del descriptor del servicio Web, el archivo WSDL. Si como en nuestro caso, servidor y cliente son proyectos de Netbeans, podemos seleccionar la primera opción, project. Netbeans nos muestra la lista de proyectos con servicios Web, de la cual debemos seleccionar el servicio Web para el que queremos generar el cliente.
La otra opción, y la que más se suele usar, es la de introducir la dirección del descriptor del servicio Web. Para ello, como ya vimos en días anteriores, copiamos la dirección del servicio Web desde la consola de administración de Glassfish y la introducimos en el campo habilitado a tal efecto en el asistente:
Debemos especificar a que paquete se asignará al código generado por el asistente, en mi caso escribo
org.lasterra.glassfish.clientAl pulsar finalizar Netbeans lanza la tarea wsimport de JAX-WS y añade al proyecto una referencia al servicio Web
Para finalizar el ejemplo solo nos queda localizar el lugar donde deseamos realizar la llamada a la operación del servicio Web. Para el ejemplo seleccionamos la JSP de inicio y arrastramos allí la operación sumar.
Solo falta asignar los valores a los parametros del servicio Web, y al ejecutar la llamada a la página JSP, obtenemos el resultado
Quiero recalcar que en esta ocasión si existe un código generado por el programa wsimport de JAX-WS. Este código Netbeans lo almacena en una carpeta que no se ve desde la vista principal del proyecto. No me gusta mucho esta idea de ocultar el código, pero lo cierto es que no tenemos ninguna necesidad de modificarlo. En cualquier caso su ubicación es la siguiente:
Es interesante ver este código, también con anotaciones JSR-175, que esta compuesto por:
Estaréis de acuerdo conmigo en que es imposible hacerlo más fácil.
Web services for Java EE 5 in Glassfish (3) En la reciente OpenJavaDay de Madrid, y en particular, en la mesa redonda que pude compartir con mis freak-friends, se hablo mucho sobre los lenguajes dinámicos y sobre el JSR-175 (las famosas @) en JavaEE5.
Hemos visto como este nuevo JSR ha aportado mucha sencillez al desarrollo de aplicaciones Java Enterprise. Esta "copia" del antiguo XDoclet ha mejorado mucho por una razón, el código que se genera detrás de una anotación JSR-175 no se ve, y por tanto no se puede modificar.
Esto soluciona el problema que existía antes cuando a través de una anotación, generábamos código que muchas veces, por una u otra razón terminábamos modificando, con los consecuentes problemas que esto podía generar en el futuro al presentarse un cambio.
Vamos a adentrarnos en el código del ejemplo anterior del servicio Web, para ver que realmente, un servicio Web JavaEE5 no genera ni una línea de código, y es Glassfish quien se encarga de ello.
En la primera imagen podemos ver que no existe ningún archivo generado, ni .java, ni .class en todo el proyecto.
Aunque para mí lo más sorprendente es que tampoco existe ningún tipo de información relativa al servicio Web en el descriptor de la aplicación, el archivo web.xml
La primera vez que me di cuenta de esto, me extrañe muchísimo, ya que por ejemplo, esto oculta la dirección del Servicio Web. Pensé entonces que en el descriptor específico de Glassfish iba a encontrar algún dato, pero no fue así
Tuve que ir a la consola de administración para ver la dirección del servicio y como en algún paso interno se había generado mucha información en tres archivos de configuración:
De esta generación de código y configuracón habrá gente a favor y en contra. Bajo mi punto de vista es una avance hacía la sencillez, que es muy positivo. También veo que aunque los IDEs cada vez nos ayudan más, en este caso lo que nos ayuda es la plataforma, que es la que se encarga de generar el código. Un aplauso para el JSR-175.
Web services for Java EE 5 in Glassfish (2)
Con la ya no tan nueva JDK 5.0 se introdujeron muchos cambios, uno de los más sonados fue el uso de las @ como metainformación dentro de nuestro codigo java. Los que llevamos en esto algunos años vimos nacer la idea con el mítico proyecto open source XDoclet y esta idea vuelve a renacer en Java EE 5.
El estandar de servicios Web de Java EE 5, JAX-WS (JSR-224), nacio con varios objetivos, entre los que destacaría:
Fueron tantos los cambios, que lo que iba a ser JAX-RPC2.0 paso a ser JAX-WS y la implementación de referencia se forjo alrededor de la comunidad glassfish.
Como veremos a continuación cada vez es más fácil crear un Servicio Web, sobre todo si estamos ayudados de herramientas de ultima generación. Para trabajar con glassfish el IDE recomendado no podía ser otro que el Netbeans. Para el ejemplo voy a usar la ultima milestone de la versión 6.0. He descargado la versión completa, que además de incluir el servidor glassfish, incluye herramientas de desarrollo SOA y UML.
El primer paso es crear un proyecto web que albergue nuestro servicio Web.
Una vez tenemos el proyecto de aplicación Web empezamos el wizard para crear un nuevo servicio Web.
Se puede ver en la ultima pantalla como se ha añadido un servicio web al proyecto. El editor del netbeans nos muestra la ventana del servicio Web a través de la cual podemos añadir nuevas operaciones a nuestro servicio Web. Pulsamos en el boton Add Operation y rellenamos el formulario
El diseñador de Servicios Web nos muestra la nueva operacion 
.
Pulsando en Source vamos al código generado por el Wizard.
Del código se pueden resaltar varias cosas
Todo esto lo ha hecho por nosotros el netbeans a través del Wizard pero nunca esta de más saberlo. Por tanto solo nos queda implementar la operación (Si, gracias a Dios todavía esto no lo hace el IDE)
Una vez estamos aqui, podemos compilar la clase, si no hay errores arrancamo el proyecto. Esto nos arrancara el servidor glassfish que viene con el netbeans. Si accedemos a la direccion http://localhost:8080/AplicacionWeb/ClaseServicioService?wsdl podremos ver el descriptor de nuestro servicio Web para comprobar que el servicio Web se ha creado correctamente.
Aprovechando las funcionalidades de glassfish, podemos acceder a su administrador Web para visualizar los servicios Web instalados. Para ello accedemos a la dirección http://localhost:4848/ e introducimos el usuario admin y la clave adminadmin (puertos y usuarios son los asignados por defecto en la instalación).
En el próximo post veremos como crear un cliente del servicio Web, y como se puede monitorizar el servicio web desde la consola de administración.
Web services for Java EE 5 in Glassfish
Glassfish es la implementación de referencia de Java EE 5. La verdad es que Sun esta trabajando mucho en el servidor, todo open source, y ha llegado la hora de probar si ese trabajo es tan bueno como nos cuentan en sus blogs y bitacoras.
Son muchas las cosas que quiero ver: grizzly, las funciones del administrador Web y principalmente, jax-ws, la nueva implementación de servicios Web. En este campo he probado casi de todo menos xfire, y no me acaba de convencer nada de lo que he visto, creo que debería ser mucho más fácil hacer un servicio Web y quiero ver si este nuevo estándar aporta la solución que busco.
Por ultimo, recordaros que el capitán que dirige el rumbo de glassfish casualmente es Español, Eduardo Pelegri-Llopart. Tuve la oportunidad de conocerle en los Sun Tech Days de Madrid el pasado año y prometi escribir algo sobre el, así que, con retraso, pero vamos a ello.
Por cierto, si alguién esta pensando que empiezo esta serie de post empujado por el monitor de 52 pulgadas que dicén regalar, esta en lo cierto ;-)
Pasos de la instalación:
Con esto ya tenemos glassfish instalado y todo preparado para empezar a jugar con el.
La primera particularidad de Glassfish frente al Tomcat son los "domains". Un dominio en glassfish es una configuración del servidor. Dentro de esta configuración hay una instancia de administración y N instancias de ejecución, pero todas bajo una misma configuración. De esta forma, con una instalación del servidor puedes tener varias configuraciones/dominios y cada uno de ellos puede tener una configuración distinta : puertos, memoria asignada a la JVM, IIOP, .
Haciendo la analogía con el tomcat, cada dominio del glassfish es una instalación del tomcat con una instancia que tendría tan solo un "manager" (salvando las distancias) y N tomcats con sus respectivas aplicaciones.
Esta configuración puede ser util en entornos con varios administradores que compartan una instalación, aunque sinceramente, no lo acabo de ver, porque en mi pequeño mundo, en un servidor solo hay un administrador ;-)
Al instalar el servidor se crea un dominio por defecto, domain1. Para arrancarlo ejecutamos el comando de administración c:\glassfish\bin\asadmin start-domain domain1. En la consola el servidor nos da información interesante:
asadmin start-domain domain1
Starting Domain domain1, please wait.
Log redirected to C:\glassfish\domains\domain1\logs\server.log.
Redirecting output to C:/glassfish/domains/domain1/logs/server.log
Domain domain1 is ready to receive client requests. Additional services are being
started in background.
Domain [domain1] is running [Sun Java System Application Server
9.1 (build b41d-beta2)] with its configuration and logs at: [C:\glassfish\domains].
Admin Console is available at [http://localhost:4848].
Use the same port [4848] for "asadmin" commands.
User web applications are available at these URLs:
[http://localhost:8080 https://localhost:8181 ].
Following web-contexts are available:
[/web1 / wstx-services ].
Standard JMX Clients (like JConsole) can connect to JMXServiceURL:
[service:jmx:rmi:///jndi/rmi://localhost:8686/jmxrmi] for domain management purposes.
Domain listens on at least following ports for connections:
[8080 8181 4848 3700 3820 3920 8686 ].
Domain does not support application server clusters and other standalone instances.
Comprobamos que el servidor esta arrancado accediendo a http://localhost:8080/. Si vemos el "up and running" podemos instalar una aplicación Web para comprobar que todo es correcto. El manual nos propone la siguente aplicación http://glassfish.dev.java.net/downloads/quickstart/hello.war. La descargamos y la copiamos al directorio glassfish/domains/domain/autodeploy dentro del dominio (este viene a ser el directorio webapps del tomcat).
Una vez copiada la aplicación debe aparecer en ese mismo directorio el archivo hello.war_deployed, si intentamos acceder a al aplicación antes obtendremos un error 404.
Para acceder a la aplicación, http://localhost:8080/hello. Si todo es correcto ya podemos decir que la instalación ha sido correcta.
Installing Glassfish
