Primero lo primero – Instalando el JBoss AS 7

Cuando vayamos a www.jboss.org veremos que por primera vez existen dos versiones del servidor para bajarnos.

• Web Profile Only (Java EE6 Certfied)
• Everthing (NOT Java EE6 Certfied)

La primera como su nombre lo indica está orientada al la ejecución de aplicaciones Web y como se puede apreciar es una configuración certificada en cumplir con todos los requerimientos de un servidor Java EE6 con web profile. La otra configuración es lo que se conoce por Full profile pero que todavía no ha sido certificada y no soporta todos lo que necesita un servidor Full Profile, por lo cual es llamada “Full preview profile”.
Yendo a lo concreto, la diferencia entre el Web y el Full es básicamente es la siguiente

• JSR 914 – Soporte de JMS
• JSR 224- Java API 2.2 para WebServices basados en XML (JAX-WS)

Cualquiera de las configuraciones la podemos bajar desde la página de download de JBoss.
Para los ejemplos acá planteados cualquiera de las dos es indistinta. Si no piensan usar JMS y WebServices entonces con la Web van a estar más que bien. Tengan en cuenta que ambas vienen con la variación Lite del contenedor de EJB especificado en la JSR-381. Este contenedor es una versión limitada la cual NO soporta:

• Remote interfaces
• RMI-IIOP Interoperability
• JAX-WS Web Service Endpoints
• EJB Timer Service (@Schedule, @Timeout)
• Asynchronous session bean invocations (@Asynchronous)
• Message-driven beans

Los que quieran ver un poco más sobre que soporta y que no cada una de las versiones pueden consultar la tabla que hay en la guía de JBoss

Ahora a los bifes – Ejecutando el JBoss AS 7.0
Para ejecutar el servidor debemos tener descomprimido el archivo bajado (el zip o el tar.gz) en una carpeta donde mejor nos quede. Por ejemplo en mi caso yo lo instale en Users/ale/opt/Applications/jboss-as-web-7.0.0.Final.
El único requerimiento que tenemos es que debemos tener instalada una versión de la JDK que sea la 6 o superior.

Luego debemos abrir una terminal o consola, dependiendo del sistema en que estamos, y posicionarnos en la carpeta raíz donde instalamos el servidor.
Ahí ponemos nuestro asiento en posición vertical, nos abrochamos los cinturones y ejecutaremos:

• bin\stanadalone.bat si es que estamos en windows
• bin/stanadalone.sh si estamos en cualquier variante de Unix

Paren las rotativas!!! ¿Que es esto de standalone? Por ahora para la comprensión de este artículo solo diremos que standalone es uno de los dos modos de ejecución que trae la versión 7. De las dos opciones esta es la más similar en su funcionamiento a las versiones anteriores de JBoss.

Ahora sí, levantemos el JBoss AS 7!!!. tecleamos bin/stanadalone.sh [ENTER]
Podemos ver como en muy pocos segundos ya está el JBoss AS 7 levantado!!! . Ahora sabemos de primera mano que esta nueva versión levanta con una velocidad mucho mayor que cualquiera de sus versiones anteriores. Eso no es por casualidad y se debe a su nuevo diseño el cual nos provee de un nuevo proceso de carga de componentes. Este proceso tiene dos grandes cambios:

1. Carga concurrente de los servicios, aprovechando los múltiples procreadores que tengamos
2. Solo levanta los servicios críticos para el correcto funcionamiento del servidor. Cualquier otro servicio no crítico queda levantado en forma pasiva hasta que sea utilizado por primera vez.

Según RedHat esta versión ofrece una reducción de 10 veces en el tiempo de arranque con respecto a las versiones anteriores.
Esto podemos confirmar si miramos la última linea impresa por el JBoss, la cual debe decir algo así:

...
...
...
17:30:11,370 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-4) Starting remote JMX connector
17:30:11,405 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
17:30:11,878 INFO  [org.jboss.as.remoting] (MSC service thread 1-3) Listening on /127.0.0.1:9999
17:30:12,049 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-8) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080
17:30:12,742 INFO  [org.jboss.as.connector] (MSC service thread 1-7) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
17:30:13,360 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) Bound data source [java:jboss/datasources/ExampleDS]
17:30:14,120 INFO  [org.jboss.as.deployment] (MSC service thread 1-4) Started FileSystemDeploymentService for directory /Users/ale/opt/Applications/jboss-as-web-7.0.0.Final/standalone/deployments
17:30:14,132 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.Final "Lightning" started in 7885ms - Started 92 of 147 services (55 services are passive or on-demand)

En este caso podemos ver como en JBoss levanto en casi 8 segundos.

Para bajar el JBoss no hay misterios, hacemos como siempre hasta ahora Ctrl+C.

Me parece que vi un lindo gatito – Nueva consola Web
Una vez que tenemos el servidor levantado pasemos a ver otra de las mejoras que trae que es su consola web de administración. Esta consola si la comparamos con la anterior es un avance importante en cuanto a la estética. La consola es una aplicación GWT lo cual la hacen mucho más rica en su funcionamiento. Dentro de esta podemos hacer varias actividades de administración, como ser:

• Configuración de los datasource
• Configuración de los logs
• Configuración de los conectores web y virtual host
• Realizar deployments con al posibilidad de, habilitar, deshabilitar, subir y eliminar aplicaciones
• Configuración de los puertos

Para conectarnos a esta nueva consola tenemos que abrir un browser e ingresar: http://localhost:9990/console

Una funcionalidad que se ha eliminado es la consola JMX. Este cambio se debe a que con JMX no se podía dar soporte a la nueva administración de dominios (hablaremos de ella en otro artículo). Ahora la forma de administrar es usando el modo nativo de administración. Desde este modo podemos configurar y accederá a todas las propiedades de los servidores. JBoss viene con una extensión que hace de puente entre JMX y la API nativa y nos permite conectarnos con un cliente JMX como el jconsole. En mis pruebas lo que si pude detectar es que no estaban todas las funcionalidades presentes en la consola JMX.

La consola web no es la única forma de acceder a la interfaz nativa de administración. Tenemos estás cuatro opciones:

• La consola web que como vimos es limitada
• Con un cliente de linea de comando, muy completo por cierto.
• Una API java que se puede acceder directamente con java remoting
• Una API REST-like para enviar comando por http

De estas vale la pena mencionar que la CLI que trae está muy completa, por ejemplo soporta auto completado. Para describir esta consola necesitaríamos una artículo entero. Los interesados pueden leer más sobre esta en JBoss CLI

A la carga – Haciendo nuestro primer deploy
Como ya mencionamos una forma de hacer deploy es por medio del uso de la consola web. Esta forma es muy simple por lo cual no nos vamos a detener en explicar. Lo que si vamos a ver es como hacer un deploy a la vieja usanza copiando el archivo en el directorio de deployment. Para variar esto también ha cambiado, yo estoy convencido de que luego de tantos años de manejar la misma estructura del servidor la gente de JBoss se aburrió y para hacer su trabajo más divertido nos cambio todo!!! Por suerte los cambios son para mejor.

Entonces, ¿Donde debemos copiar nuestra aplicación? Como tenemos levantado el JBoss en modo standalone debemos copiar el artefacto (jar, war o ear) al directorio standalone/deployments. Y listo nuestra aplicación queda levantada y funcionando.

Resumiendo

Los más importante que vimos en el artículo es:
Que versiones están disponibles para bajar
Como levantar el servidor en modo standalone: bin/standalone.sh
Conectarnos a la consola Web: http://localhost:9990/console
Hacer un deployment: Copiar nuestra aplicación a standalone/deployments

Por último espero que hayan visto que esta nueva versión incluye una cantidad de cambios aparte del soporte a Java EE 6.

Para la próxima

En el próximo artículo veremos más sobre los deploy y revelaremos el misterioso “Sandalone”. Antes de despedirme les dejo un deber, ¿luego de hacer el deploy, no ven nada extraño en el directorio deployments?

Saludos y hasta la próxima.

¿Qué, cómo, dónde?
Primero, vamos a definir “qué” queremos hacer. Una vez más, voy a utilizar el clásico ejemplo de obtener PI desde el servidor. Luego veremos el “cómo”.

El “qué” refiere a la interfaz del servicio y el “cómo” a la implementación. Entonces tenemos que crear:

package  ejemplo.client.services

// El “qué”
public interface MathService extends com.aquait.rpc.client.service.Service {
    double getPi();
}

// El “cómo”
package ejemplo.server.services

public class MathServiceImpl extends com.aquait.rpc.server.service.Service implements ejemplo.client.services.MathService {
    public double getPi() {
        return Math.PI;
    }
}

¿Y ahora? Ahora hay que decir el “dónde”. Para esto configuramos el servidor. En el archivo services.config agregamos:

service[math_service].interface = ejemplo.client.services.MathService
service[math_service].implementation =  ejemplo.server.services.MathServiceImpl

Recordar “math_service” que será utilizado más adelante.
El siguiente paso sería crear un jar con las clases e interfaces y copiar ese jar en el subdirectorio application.
Con el comando start levantamos el servidor y deberíamos ver en el log, en el reporte de servicios, al querido MathService.

Mozo! Un PI por favor!
Si todo está bien (y esperemos que así sea) estamos en condiciones de hacerle pedidos al servidor. Para esto, desde el cliente tenemos que conectarnos e invocar al servicio:

// 1 – Nos conectamos al servidor
AppServerClient appServerClient = new AppServerClient("localhost", 6666);

// 2 - Obtenemos un proxy del servicio desado: “math_service”
MathService mathService = (MathService)appServerClient.getService("math_service");

// 3 - Invocamos al método deseado como si lo tuvieramos local
double pi = mathService.getPi();
System.out.println(pi);

Todo esto y mucho más
Esta es la versión simple. Pero en realidad, el servidor soporta seguridad, parámetros de inicialización de los servicios, pool de conexión a la base de datos, mensajería, módulos, etc. Esto se puede ver en el código fuente publicado en el artículo AppServer-03 en un módulo que se llama test.

Good luck!

Este es el último artículo de esta serie. En este voy a presentar como se configura el servidor y además voy a subir el código fuente.

Estructura de directorios:

aquait-appserver/

• application/
  • db_connection_pool.config Configuración del módulo pool de conexiones a la base
  • modules.config Configuración de los módulos
  • services.config Configuración de los servicios
  • messaging.config Configuración del módulo de mensajería
  • security.config Configuración de seguridad
• lib/
  • aquaitrt-bin_2009r1.jar Runtime
  • mail.jar Servicio de mail
• log/
• logging.config Configuración de logging
• server.config Configuración del servidor
• start.sh
• stop.sh
• start.cmd      Scripts para iniciar y detener al servidor
• start.sh
• stop.cmd
• stop.sh

logging.config

handlers = java.util.logging.ConsoleHandler, java.util.logging.FileHandler

java.util.logging.FileHandler.level = ALL

java.util.logging.FileHandler.pattern = ./log/server.%u.txt

java.util.logging.FileHandler.limit = 50000

java.util.logging.FileHandler.count = 1

java.util.logging.FileHandler.formatter = com.aquait.utils.logging.ServerFormatter

java.util.logging.ConsoleHandler.level = INFO

java.util.logging.ConsoleHandler.formatter = com.aquait.utils.logging.ServerFormatter

Archivo que configura el logging. El servidor usa la API estándar de Java SE para logear. El archivo por defecto define dos handlers. El primero que genera archivos y el segundo logea a la consola. Por más detalles, ver http://java.sun.com/javase/6/docs/api/java/util/logging/package-summary.html.

server.config

# Server config

# Server listening port

#

port = 6666

# Worker pool size

#

workers.poolsize = 10

# Shutdown password

#

shutdown.password = _shut_down_now_server_

Este archivo define tres parámetros del servidor. Primero el puerto TCP/IP en el cual el servidor escucha conexiones. Los clientes se deberán conectar a este puerto. El segundo parámetro define la cantidad de workers (hilos) que atienden los pedidos de los clientes. Y el tercero es la contraseña para bajar el servidor. Se baja mediante el script stop que se comunica al puerto definido y manda un mensaje especial. El servidor solamente se puede bajar desde el mismo host en donde está ejecutando.

db_connection_pool.config

# DBConnectionPoolModule configuration

#

# Examples:

# url = jdbc:oracle:thin:@<host>:<port>:<database>

# driverclass = oracle.jdbc.driver.OracleDriver

#

enable = false

url = <url>

username = <user>

password = <pass>

driverclass = <driver_class>

autocommit = false

poolsize = 5

maxpoolsize = 10

Este archivo controla los parámetros del pool de conexiones a la base de datos.

modules.config

# Modules to load

# Format:

# module.name = <module_name>

# module[<module_name>].class = <module_class>

#

En este archivo se delcaran los módulos que van a desplegarse en el servidor. Cada módulo puede tener una cantidad varible de parámetros.

messaging.config

# MessagingModule configuration

#

enable = false

poolsize = 10

# Security realms

# Format (<n> starts at 0):

# security_realm[<n>] = <security_realm_class>

#

Este archivo configura la seguridad del servidor. Se pueden definir varios realms que se ejecutan en orden para cada pedido de los clientes.

services.config

# Services

# Format:

# service[<service_name>].interface = <service_interface>

# service[<service_name>].implementation = <service_implementation>

# service[<service_name>].parameter[<param_name>] = <param_value>

#

Este archivo configura los servicios que se publican en el servidor. Para cada servicio hay que configurar la interfaz y la implementación de esta. Además, opcionalmente, se pueden agregar parámetros de inicialización.

Con esto finalizamos esta serie. Siempre estoy a las orden ante cualquier consulta que tengan al respecto de este servidor.

Bajar código fuente: aquaitrt_2009-10-14.tar.gz

Siguiendo la exploración de los principales componentes de servidor, en este artículo vamos a ver el el componente de conexiones a la base de datos y el de mensajería. Los dos componentes se diseñaron e implementaron separadamente del servidor de aplicaciones, por lo que no están acoplados de ninguna forma. Para “agregarlos” al servidor, se implementaron módulos del servidor que los adaptan.

Pool de conexiones a la base de datos

El pool implementado es muy sencillo. Tiene una colección de conexiones con un tamaño inicial (configurable) y en caso de que el cliente (en este caso el servidor de aplicaciones) necesite más, crea hasta un máximo (también configurable).

Diseño del pool de conexiónes a la BD

Los métodos startup() y shutdown() del módulo manejan el ciclo de vida del pool. El primero carga de un archivo de configuración -que veremos más adelante- los datos para crear el pool y el segundo mata a las conexiones activas.

Mensajería

El servicio de mensajería también es sencillo, pero potente. Poseé un pool de hilos que procesan los mensajes en form asíncrona. La clase Messaging tiene un conjunto de MessageHandlers que son los responsables de procesar los mensajes. Cuando llega un mensaje, este se le pasa a todos los handlers y cada uno es responsable de si lo procesa o no.

Diseño del servicio de mensajería

En el próximo artículo voy presentar la configuración del servidor y también voy a subir el código fuente. Hasta el próximo!

Hoy en día casi todo proyecto de desarrollo tiene alguna interfaz web como parte del producto. Esto no es ningún desafío si tenemos un equipo el cual ya ha trabajado con este tipo de proyectos. ¿Pero que pasa si el equipo no tiene experiencia en el desarrollo de aplicaciones web?

Por ejemplo, viene del mundo enterprise, con años de experiencia en sistema de mediano y gran porte con clientes realizados con frameworks GUIs como ser Swing.

Al principio seguramente subestimemos el mundo web pensando que todo es es un juego de niños que cualquiera puede hacer y que contratando a un diseñador web nuestros problemas van a estar solucionados. Pero obviamente uno está equivocado y ni bien comienza a estudiar lo básico se encuentra con una cantidad de conceptos no menores como ser manejo de sesión, AJAX, CSS, XSS, SQL-Inyection que uno debe entender antes de poder realizar cualquier sistema.

Una vez que terminamos de estudiar estos conceptos y que nos volvemos a sentir seguros para comenzar es recién ahí que nuestro problema comienza. En ese momento es cuando la gran pregunta surge ¿Qué framework web (FW) es el que debo utilizar para mis proyectos?

Hace un par de años atrás esto no hubiera sido un problema, la respuesta probablemente hubiera sido si estamos trabajando en Java, utiliza struts. Pero hoy eso cambió debido a que solo para Java en la página http://java-source.net/open-source/web-frameworks podemos encontrar más de 40 frameworks, dentro de los cuales el que yo utilizo no está. Y ni hablar si entramos considerar FW de diferentes lenguaje de programación como ser Ruby, Python, php y .net . ¿Entonces como podemos hacer para responder semejante pregunta hoy en día?

A continuación voy a definir lo que IMHO son los factores que yo he utilizado para responder está pregunta y que pueden ser de ayuda a otros que se enfrenten a una situación similar. Partiremos de la base que tenemos un equipo de desarrollo con experiencia en un lenguaje determinado el cual debemos reconvertir al desarrollo de aplicaciones web. Algunos de los puntos que se plantearán no tienen sentido por ejemplo para un desarrollador independiente o si se está armando un equipo desde cero. Cuando se trabaja con un equipo ya formado hay factores a considerar que no dependen directamente de la tecnología y que pueden determinar que el mejor FW del mundo, no sea la mejor elección, lo cual hace que la solución del vecino no siempre sea la solución adecuada para uno. Por lo tanto debemos tener sumo cuidado con nuestros pares cuando con su mejor intención nos recomiendan “él FW” ya que probablemente ellos no conozcan el contexto donde usted lo debe utilizar. Por último hay que ser realistas y saber que probablemente al finalizar el proceso de selección haya más de un FW que pueda ser utilizado y que la definición terminará siendo un tema de preferencia con un grado de incertidumbre. La respuesta final solo la sabrá luego de estar avanzado en el primer proyecto, pudiendo equivocarse y debiendo reconsiderar su decisión. Por tal motivo es importante elegir como primer experiencia un proyecto no crítico.

Los puntos que voy a nombrar a continuación no están en un orden especial.

Puntos a tener en cuenta a la hora de elegir un FW
Conocimientos del equipo

Es de suma importancia evaluar en que se siente cómodo el equipo trabajando. Es decir si tengo todos programadores Java muy probablemente lo mejor sea buscar una FW dentro de Java de esta forma el equipo podrá aprender rápidamente el FW ya que no tiene que perder tiempo estudiando los detalles de otro lenguaje. Por otro lado FW buenos hay en casi todos los lenguajes así que no debería ser un problema fijar este punto. La excepción a esta regla sería si estamos trabajando con un lenguaje desactualizado como ser Clipper o Cobol. Pero en este caso estaremos ante una problema mayor que es una reconversión tecnológica de los sistemas.

¿Necesitamos algo que solucione solo la presentación o tenemos que trabajar en todas las capas?

Es importante determinar que grado de libertad tenemos a la hora de elegir. Es decir, estamos ante un caso en el cual tenemos un sistema ya armado al cual solo debemos darle la presentación web o estamos ante un caso en el cual podemos elegir desde la forma de presentar los datos hasta la forma de persistirlos. Dependiendo de esto nos convendrá utilizar algo que soluciones todo nuestro requerimientos o simplemente centrarnos en lo que necesitamos que es solucionar la presentación web. En base a lo anterior podemos dividir los FW dividir en dos grupos y así descartar el que no sea de nuestro interés. Los grupos serían:

Frameworks full stack

Son los que presentan una solución completa que va desde la capa de presentación hasta la capa de persistencia de la información. Los más nuevos están basados en el patrón MVC. Algunos ejemplos de estos son:

• Rails en ruby y que podríamos decir que es la estrella del momento
• Grails en Groovy
• CakePhp en php
• Spring Roo y SEAM en Java
• Django en Python

Detallar cada uno no es nuestra intención, simplemente me limitaré a comentar que la mayoría está basado en los principios de CoC (convention over configuration), DRY (don’t repeate yourself) y que su composición básica consta de un procesador de templates para el diseño de las vista (que generarán las páginas dinámicas), un despachador de HttpRequests que siguiendo determinadas convención decide a que servicio despachar el pedido. Para el manejo de los datos cuentan con un framework ORM que ofrece creación de consultas dinámicas y una cantidad de facilidades que simplifican el trabajo.

Solo de presentación:

Estos son aquellos que están orientados solo a la capa de presentación.

Ejemplos de este tipo son:

• GWT- Google Web Tookit:el cual genera una aplicación 100% JavaScript pero que es programada en Java
• JSF: Java Server Faces, es el framework de componentes oficial de Java
• ASP.NET: que es LA opción dentro de Microsoft

Soporte (comunidad, fabricante, libros, certificación, perspectiva a futuro)

Un punto importante, sobre todo en los proyectos OS, es ver la comunidad que hay al rededor del framework a utilizar. Es importante investigar si hay una empresa invirtiendo recursos en el desarrollo del producto o está movido pura y exclusivamente por la comunidad. En el último casó es cuando “el tamaño si importa” y dependiendo del tamaño de la comunidad en que se sustenta depende el soporte que podemos tener. Para esto la mejor forma es en la página del framework buscar que tantos reporte de bugs hay, que tan rápido se solucionan, cuantos desarrolladores hay corrigiendo tickets. Siguiendo en esta misma linea hay que ver cada cuanto sale una nueva versión y si hay versiones destinadas a generar una versiones estables del framework o si solo salen versiones cuando hay nuevas funcionalidades. Visto que vamos a tener que aprender a utilizar el framework hay que estudiar la calidad de la documentación de este, ver que tantos libros publicados (por ejemplo en Amazon) hay sobre el tema y si se ofrece algún tipo de certificación y/o capacitación.

Existencia de proyectos exitosos

Como nuestra intención es utilizar el FW para un producto que en algún momento deberá salir en producción seguramente no queramos ser los conejillos de indias. Si el FW es mínimamente serio entonces debe tener en su sitio web referencia a sistemas que están implementado con este. No es una mala idea de ser posible dar una mirada a estos y ver que tan bien funcionan. Sería excelente poder encontrar un blog de uno de estos proyectos en el cual se comente la experiencia durante el desarrollo del sistema.

Integración con la plataforma existente

Si el proyecto va a formar parte de un ecosistema más complejo entonces hay que tomar en cuenta las posibilidades de integración que tiene el FW y si estas son aceptables dentro de la arquitectura de nuestro producto. Por ejemplo si tenemos que interactuar con un sistema JEE es importante determinar que facilidades para invocar servicios EJB me da el FW. Claro está que siempre es posible desarrollar una capa que se encargue de la interacción, pero si el FW lo soporta nativamente no solo nos ahorramos trabajo sino que estamos reutilizando algo que está probado y utilizado por otros.

Curva de aprendizaje

Este punto hoy en día es engañoso debido a que los FW modernos tienen una curva de aprendizaje muy rápida inicialmente pero que para llegar a niveles de expertos hay que dedicarle mucho tiempo como a cualquier otro framework. Si ha esto le sumamos que la mayoría de los FW son OS con una documentación de mala calidad, que probablemente no exista soporte local y que para capacitarnos tengamos que viajar muchos kilómetros (por lo menos si están el el Sur como yo). Lo cual hace que la capacidad de aprendizaje del equipo sea un factor importante. En algunos casos para poder llegar a solucionar un problema será necesario estudiar el código fuente del FW. Si llegáramos a tener la suerte de que el presupuesto nos permitiera poder capacitar parte del equipo y/o de contratar soporte entonces no hay que dudarlo. Los dolores de cabeza y el tiempo que se puede ganar seguramente lo vale.

Probar, probar y probar

Inevitablemente para poder determinar el FW tendremos que destinar recursos y realizar algunas pruebas antes de poder llegar a una conclusión aceptable y fundamentada. No es necesario probar todos para estar tranquilo de que estamos utilizando el mejor. Cuando evaluemos recordar que estamos buscando el adecuado para el contexto donde hay que usarlo y no el mejor en general. Con un buen análisis previo probablemente no debamos probar más de dos o tres FW. Para que la prueba sea lo más comparativa posible debemos elegir un proyecto tipo y e implementarlo con con los FW que vayamos a evaluar..

¿Como comparamos los FW?

Para la comparación de los FW he utilizado una herramienta que a mi me ha ayudado a la hora de evaluar y puede ser de ayuda para ustedes también. La herramienta es una simple tabla en la que refleja la mayoría de los puntos vistos. En esta tabla calificaremos los FW dándoles un puntaje donde para cada punto tendríamos un máximo asignable y la suma de los máximos te todos los puntos suma 100. Al definir máximos diferentes por puntos estamos priorizando los puntos a evaluar de acuerdo a nuestro contexto. Por ejemplo si estamos en un caso en el cual tenemos una cantidad de sistemas existentes con los cuales debemos interactuar seguramente la capacidad de integración del FW sea uno de los puntos más importantes a evaluar mientras que si no tenemos que interactuar con otros sistemas, tenemos tiempos tiranos y un equipo ya formado con poca experiencia web entonces la curva de aprendizaje es un punto determinante en nuestra elección.

Para dejar en claro este punto vamos a ver un ejemplo:

La lectura que se pude hacer de la tabla anterior es que debemos realizar pruebas con el FW2 y el FW4 para definir cual de estos dos es el que vamos a utilizar. Gracias al estudio que realizamos redijimos por lo menos a la mitad la cantidad de FW a estudiar y tenemos una tabla que justifica nuestra elección.

Obviamente cuanta más filas le agreguemos a la tabla tendremos más información para justificar la elección.

Por las dudas aclaro que los máximos asignados son de ejemplos y ustedes deberían definir los suyos de acuerdo a sus necesidades.

En resumen…

En resumen a la hora de seleccionar un FW debemos seguir tres pasos:

1. Primero debemos evaluar los conocimientos del equipo y determinar que tipo de FW se quiere si uno que sea full-stack o solo presentación.

2. Una vez tengamos esto y sabiendo el lenguaje de preferencia podemos buscar el subconjunto de FW a evaluar. Para facilitar la evaluación confeccionamos una planilla como la vista en el punto anterior.

3. Por ultimo con los FW mejor ranqueados realizamos las pruebas las cuales se realizan con un mismo proyecto implementado en cada uno de los FW.

Luego de todo esto podremos saber cual es el FW a utilizar. Parece mucho trabajo, no? Si seguro que lo es, pero es la única forma de poder tomar una decisión minimizando el riesgo de equivocarnos… y cuando la decisiones tecnológicas de una empresa depende de nosotros es bueno tener herramientas para justificar nuestras decisiones y sobro todo para asegurarnos el éxito de nuestro trabajo.

Ahora que tenemos un servicio RPC podemos usarlo como base para implementar un servidor de aplicaciones, pero solamente un servicio RPC no alcanza. Por esto, vamos a implementar estos módulos/servicios:

• Seguridad: autorización, autenticación y auditoria

• Pool de conexiones a la base de datos

• Servicio de mensajería asíncrona

Y, además de tener una API para agregar servicios, el servidor va a proveer una API para agregar módulos del usuario. Ahora el diagrama de componentes del servidor:

Diagrama de componentes

Los componentes de la capa superior utilizan funcionalidades de los componentes de la capa inferior. Ahora vamos a explorar cada uno de los componentes.

Security realms manager

Esto es obligatorio en cualquier AppServer. En el Security Realms Manager se instalan los security realms. ¿Qué es un security realm? Conceptualmente es un componentes que controla el acceso al los servicios. Desde el punto de vista técnico, es la implementación de la interfaz:

public interface SecurityRealm {
    /**
     * The login method.
     * @param credentials The credentials to validate
     * @throws LoginException If an exeption ocurrs during login
     */
    void login(Credentials credentials) throws LoginException;

    /**
     * The logout method.
     * @param credentials The credentials
     */
    void logout(Credentials credentials);

    /**
     * This method returns true if and only if the service's method can be
     * executed with the given credentials.
     *
     * @param credentials the credentials of the executing user
     * @param serviceName the service name
     * @param methodName the method name to execute
     * @param params the paramenters to pass to the method
     * @throws NotExecutedException signals that the execution is not allowed for the given credentials, serviceName, methodName and params
     */
    void executionAllowed(Credentials credentials, String serviceName, String methodName, Object... params) throws NotExecutedException;
}

Son solamente tres métodos: login, logout y isExecutionAllowed. Los dos primeros refieren al concepto de autenticación y el tercero refiere al concepto de autorización, pero también se puede asociar a auditoría ya que siempre se ejecuta antes de realizar la invocación al servicio.

El security realms manager utiliza el interceptor que aparece en Java RPC-07: en el método onPreExecution() se llama al método executionAllowed() del security realm y continúa la ejecución si este no da la excepción NotExecutedException. Por seguridad, tampoco ejecuta si ocurre cualquier otra excepción (o error) en el executionAllowed() y así evita que un bug quiebre el sistema de seguridad.

Entonces poniendo código arbitrario en método executionAllowed() se puede autorizar o no la ejecución de un método de un servicio con determinados parámetros.

El security realms manager maneja una colección de security realms. Se ejecutan todos y solamente se da por autorizada la llamada si todos autorizaron. El servidor tiene implementado un security realm abstracto que se basa en nombre de usuario y contraseña y otro security realm para hacer auditoría (logging).

public abstract class AbstractUserPasswordSecurityRealm extends SecurityRealmAdapter {

    public AbstractUserPasswordSecurityRealm() {
    }

    public void login(Credentials c) throws LoginException {
        UserPasswordCredentials cred = (UserPasswordCredentials)c;
        if (cred != null) {
            String user = cred.getUser();
            String pass = cred.getPassword();
            validate(user, pass);
        } else {
            throw new LoginException("null credentials");
        }
    }

    public void executionAllowed(Credentials credentials, String serviceName, String methodName, Object... params) throws NotExecutedException {
        if (credentials == null) {
            throw new NotExecutedException("not logged in");
        }
    }

    public abstract void validate(String user, String pass) throws LoginException;
}

Module manager

Como vimos, el servidor es extensible. ¿Pero cómo? Mediante módulos. Un módulo no es más que un bean que tiene un nombre y dos métodos para el manejo del ciclo de vida: startup() y shutdown(). Luego, el servidor tiene un método para obtener el módulo por su nombre. Como es tan simple la interfaz, es fácil adaptar cualquier servicio para incorporarlo al servidor. Por ejemplo, el servicio de mensajería asíncrona se implementó por separado y se creó un módulo para adaptarlo a este servidor de aplicaciones. Idem con el pool de conexiones a la base de datos. La interfaz:

public interface Module {
    void setName(String name);
    String getName();

    void startup() throws Exception;
    void shutdown();
}

Para obtener un módulo desde un servicio, se lo pedimos al ServerContext:

ServerContext.getModule(moduleName);

La clase ServerContext nuclea un conjunto de métodos estáticos que dan acceso a diferentes partes del servidor de aplicaciones. Los que más se desatacan son getModule() y getServerConfig(). El primero ya lo vimos. El segundo devuelve un Mapa con propiedades que se cargan de un archivo de configuración. Ya veremos la configuración en una sección dedicada a esta.

Services Loader

Este es el componente encargado de leer de un archivo de configuración y crear los servicios en el RPC. Está implementado como módulo así se puede reemplazar fácilmente por otro y se acopla al servidor. Básicamente lee de un archivo de configuración la descripción de los servicios con sus parámetros y los agrega al servidor.

En el siguiente artículo voy a describir el pool de conexiones a la base de datos y el servicio de mensajería. También voy a describir los archivos de configuración.

Hasta el próximo.

En este es último artículo de la serie RPC voy explorar algunas extras que tiene el servidor que nos van a servir para implementar un servidor de aplicaciones, pero sin perder generalidad. También vamos ha realizar un test de rendimiento, viendo el througput (pedidos por segundo) que tiene el servidor.

Extras

Los servicios en el lado del servidor toman parámetros de inicialización. Esto nos va a permitir pasar datos al servicio para configurarlos. Estos parámetros se acceden mediante el método getParameters() de la clase Service, que devuelve un Mapa con la configuración.

Validación de servicios

Antes de agregar un servicio al servidor, se realizan los siguientes chequeos:

• Que la implementación del servicio tiene que tener un constructor sin parámetros

• Que la implementación del servicio debe implementar la interfaz del servicio

• Qué no haya sobrecarga de métodos en el servicio

• Que el tipo de retorno como los parámetros de los métodos sean serializables

Estos chequeos ayudan a evitar errores comunes.

Autorización de ejecución

Antes de efectivamente ejecutar un método de un servicio, se invoca a un interceptor: onPreExecution. Si se ejecuta correctamente, entonces se pasa a invocar al servicio, si no se sale por excepción NotExecutedException. Esto nos va a servir para implementar, por ejemplo, mecanismos de seguridad y auditoría (logging).

Rendimiento

Con el test de rendimiento vamos comprobar ver si el diseño que hicimos es escalable como queríamos. El test se realizó en un notebook que tiene un CPU Intel modelo T9500 (C2D 2.6GHz, 6MB de cache core Penryn) con 2GB de RAM sobre Ubuntu 9.04 32 bits y con Java6. Los resultados fueron:

Caso	Procesos cliente	Hilos por cliente	Pedidos por hilo	Total pedidos	Tiempo (segs)	Pedidos/ segundo
1	5	30	2500	375000	207	1811,59
2	10	30	2500	750000	229	3275,11

Si bien no es un test de stress muy riguroso, nos da una buena aproximación de la performance y escalabilidad del servicio: aumentando al doble la cantidad de pedidos, solamente sube el tiempo en 10,6%. También, hay un valor que se puede ajustar en la creación del servidor que es el tamaño del pool de workers de la capa Pedido que despachan pedidos a la capa Servicio. Por defecto es de tamaño 10, pero si se está ante una configuración multi CPU se puede subir este valor para obtener mejor rendimiento. En el caso del test de rendimiento se utilizó un pool de 10 workers.

Un servidor de aplicaciones basado en un versión más vieja de este mecanismo de RPC está implantado hace ya varios años en uno de los bancos más importantes de Uruguay.

En el próximo artículo vamos a comenzar con la introducción al servidor de aplicaciones y cuales son los componentes principales.

Stay tuned!

En el artículo anterior vimos como estaba estructurada la capa Servicio y cuales eran las ideas principales. Pero para que sea realmente útil, nos quedaba responder las siguientes dos preguntas:

• ¿Cómo vamos a hacer para crear una instancia que sea un proxy de la clase MathServiceImpl, que implemente la interfaz MathService en forma automática y en tiempo de ejecución?

• ¿Cómo vamos a hacer un RequestListener genérico que “decodifique” el RequestPacket e invoque al método correcto de MathServiceImpl?

Primero la primera. Para poder ejecutar un método, necesitamos saber: qué método de qué servicio y con qué parámetros lo vamos a ejecutar y mandar esa información al servidor; para esto vamos a crear la clase ServicePacket, que contiene esta información (el nombre del servicio, el nombre del método y un array de Object con los parámetros que toma el método).

Ahora necesitamos el proxy. Afortunadamente Java nos provee un mecanismo para crear proxies en tiempo de ejecución. Para ver la documentación sobre proxies dinámicos ver http://java.sun.com/javase/6/docs/technotes/guides/reflection/proxy.html. Ahh! El poder de la reflexión

Entonces, lo que vamos a hacer es un InvocationHandler que arme el ServicePacket y con ayuda de la capa Pedido lo mande al servidor:

public class ServiceInvocationHandler implements InvocationHandler {
    // implements InvocationHandler
    public Object invoke(Object proxy, Method m, Object[] args) throws Throwable {
        RequestPacket req = new RequestPacket(new ServicePacket(serviceName, m.getName(), args), getUniqueKey());
        ResponsePacket result = requestManager.send(req);
        return result.getData();
    }
}

Vamos a tener una instancia de ServiceInvocationHandler por cada servicio y a cada servicio lo vamos a identificar con un String: serviceName.

Para crear un proxy utilizaremos la clase ServiceProxyFactory que tiene el método createProxy() implementado según la guía sobre proxies dinámicos que va a crear por nosotros el ServiceInvocationHandler configurado. Y así obtenemos los proxies:

MathService mathService = serviceProxyFactory.createProxy(“MathService”);

Luego la invocación:

double pi = mathService.getPI();

No hay que crear ninguna clase extra ni nada por el estilo. Lo único que hay que hacer es pedirle a la serviceProxyFactory un proxy del servicio con el nombre del servicio deseado. Este nombre es el identificador con el que se registró el servicio en el servidor, por lo que es buena práctica ponerlo como constante en la interfaz del servicio.

Obviamente hay más detalles de implementación, como que pasa con las excepciones en el servidor, pero no vale la pena adentrarnos en este punto ya que se puede ver claramente en la implementación de ServiceInvocationHandler.

Ahora la segunda pregunta: ¿Cómo vamos a hacer un RequestListener genérico que “decodifique” el RequestPacket en invoque al método correcto de MathService?

Simple, utilizando otra vez el poder de la reflexión. Vamos a explotar la capacidad de invocar métodos teniendo solamente el nombre y el nombre de la clase. Ahora es cuando vamos a “decodificar” RequestPacket, o mejor dicho, su payload: el ServicePacket. Con este payload, sabemos qué tenemos que ejecutar y con qué parámetros.

Entonces, vamos a tener un componente RequestPacketListener para escuchar los pedidos de los clientes y con los datos en el ServicePacket podemos ejecutar el método requerido.

Ahora un poco de UML:

Diseño de la capa Servicio

La clase ServiceManager implementa RequestPacketListener, por lo que acepta paquetes de la capa Pedido. Además contiene la colección de servicios registrados. Cuando llega un ServicePacket, con el nombre obtiene la instancia del servicio, con el nombre del método, obtiene el objeto método a ejecutar y con los parámetros (array de Object) lo ejecuta. La respuesta le envía al la capa Pedido en forma de ResponsePacket.

Las clases RPCClient y RPCServer nos dan las funcionalidades para interactuar con el RPC de forma sencilla, encapsulando código “pegamento”.

Entonces, un servicio se define:

La declaración:

public interface MathService extends client.service.Service {
    String SERVICE_NAME = “math_service”;
    double getPI();
}

La implementación:

public class MathServiceImpl extends server.service.Service implements MathService {
    @Override
    public double getPI() {
        return 3.1416;
    }
}

Se registra en el main del servidor:

RPCServer rpcServer = new RPCServer(12345); // port en donde escucha el servidor
rpcServer.getServiceManager().addService(
            MathService.SERVICE_NAME, // nombre
            MathtService.class,       // interfaz
            MathServiceImpl.class);   // implementación

Y se utiliza en el cliente:

RPCClient rpcClient = new RPCClient(“localhost”, 12345); // host y port en donde está el servidor
MathServie mathService = (MathService)rpcClient.getService(MathService.SERVICE_NAME);
double pi = mathService.getPI();

Así queda el RPC implementado. En el siguiente artículo estaré posteando el código fuente y señalando algunas características extras que no fueron descritas para no agregar complejidad pues no están estrictamente relacionadas con el RPC.

Next!

Lo primero que tenemos que hacer es ver como, desde el cliente, nos “enganchamos” al código del servidor. Esto lo vamos a hacer mediante un proxy. Un proxy no es otra cosa que un representante del servicio en el cliente. Entonces, las invocaciones que se hagan sobre el proxy van a terminar en servidor:

Esquema de una llamada RPC

La idea es que este proxy utilice la capa Pedido: construyendo el RequestPacket, mandándolo con send() y devolviendo el ResponsePacket con la respuesta. Y en el servidor hay que tener un RequestPacketListener que “decodifique” el paquete y lo mande a ejecutar al método correcto de la implementación correcta.

Entonces vamos a partir el servicio en dos: interfaz e implementación. La interfaz del servicio la usa el cliente:

public interface MathService {
    double getPI();
}

Y su implementación está en el servidor:

public class MathServiceImpl implements MathService {
    @Override
    public double getPI() {
        return 3.1416;
    }
}

El hecho de que MathServiceImpl implemente MathService, es por prolijidad, pero no es obligatorio.

Ahora necesitamos una implementación del lado del cliente que utilice la capa Pedido:

public class MathServiceProxy implements MathService {
    @Override
    public double getPI() {
        RequestPacket req = new RequestPacket(id, “obtener_valor_de_pi”);
        ResponsePacket resp = requestManager.send(req);
        return ((Double)resp.getData()).doubleValue();
    }
}

Y en el servidor:

public class RemoteExecution implements RequestPacketListener {
    public ResponsePacket requestPacketArrived(RequestPacket requestPacket) {
        if (requestPacket.getPayload().equals(“obtener_valor_de_pi”)) {
            return new ResponsePacket(requestPacket.getKey(), mathServiceImpl.getPI());
        }
        return null;
    }
}

Para realizar la invocación desde el cliente:

MathService mathService = new MathServiceProxy();
double pi = mathService.getPI();

Así invocamos desde el cliente, utilizando la interfaz, al servidor y obtenemos la respuesta. La capa Servicio nos va a dar todo esto (y más) automágicamente. Esto nos va a permitir que solamente tengamos que escribir la interfaz (MathService) y la implementación del servicio (MathServiceImpl).

Las preguntas que quedan son:

• En el cliente: ¿Cómo vamos a hacer para crear una instancia que sea un proxy de la clase MathServiceImpl, que implemente la interfaz MathService en forma automática y en tiempo de ejecución?

• En el servidor: ¿Cómo vamos a hacer un RequestListener genérico que “decodifique” el RequestPacket en invoque al método correcto de MathService?

Estas dos preguntas las vamos a responder en el próximo artículo

Hoy examinaremos una de las capas más complejas del sistema, la capa Request. Comparando esta capa con las anteriores (Conexión y Sesión) que son básicamente pasa-mano, esta capa agrega buena parte de la complejidad del sistema. ¿Por qué? Porque es la encargada del manejo de pedidos y respuestas concurrentes entre los clientes y el servidor.

En las decisiones tomadas en el diseño de esta capa primó la escalabilidad: capacidad del servidor de procesar gran cantidad de pedidos y conservando tiempos de respuestas bajos. (Aclaro que no se busca desarrollar el RPC con más rendimiento del mundo, me conformo con uno que sea útil para cargas medias. Habrá un artículo dedicado al rendimiento del sistema).

Al diseñador!

Primero vamos a analizar el lado del servidor. Lo que buscamos es la capacidad de recibir y procesar pedidos concurrentemente, y claro, enviar las respuestas correspondientes. Siguiendo con la filosofía de las capas inferiores, vamos a tener la interfaz RequestPacketListener para escuchar pedidos, RequestPacket y se van a responder con la clase ResponsePacket.

Diseño de la capa Pedido, lado servidor

La clase principal es RequestManager. Al implementar SessionPacketListener tiene la capacidad de recibir los mensajes de la capa Session y procesarlos. “Procesarlos” significa notificar al RequestPacketListener asociado. Ahora, para que esto sea concurrente, nos vamos a valer de la clase ThreadPoolExectutor para despachar los pedidos. Este Executor tiene un pool de threads -workers- que serán los que en definitiva invocan a requestPacketArrived() del RequestPacketListener para notificar la llegada del pedido. Antes de iniciar el procesamiento, a estos workers se les setea el contexto, que es el Map<String, Object> de Session; esto se hace mediante la clase WorkerContext.

Ahora el cliente. En principio esta capa del lado del cliente podría ser simplemente otro pasamano, pero como queremos que un mismo cliente pueda realizar varios pedidos concurrentemente, tenemos que dale un poco más de pienso. Además, vamos a implementar un send() sincrónico. Así, podemos escribir:

ResponsePacket response = requestManager.send(request);

Entonces ya esto se está pareciendo cada vez más a un RPC.

Pero, cómo hacer para que una operación que es naturalmente asíncrona (el send de sockets), sea sincrónica? Simple, utilizando semáforos (¡busy-waiting está prohibido!). Por cada pedido se va a crear un semáforo (Future) sobre el cual vamos a esperar la respuesta luego de enviar el pedido al servidor. Cuando la respuestas llega se notifica y el atributo data está cargado. Como queremos que un mismo cliente pueda realizar varios pedidos concurrentemente, vamos a tener una colección de estos semáforos.

El atributo key en las clases RequestPacket y ResponsePacket es para encontrar al destinatario de la respuesta.

Diseño de la capa Pedido, lado cliente

Bueno, ahora si, esto ya es un RPC: mediante el RequestManager, podemos realizar pedidos al servidor y esperar la respuesta. Mientras el cliente espera, el servidor procesa la respuesta con el RequestPacketListener.

Entonces, para implementar un método remoto, tenemos que crear un RequestPacketListener que haga lo que necesitamos y desde el cliente, mandar el RequestPacket con el método send de la clase RequestManager:

RequestPacket req = new RequestPacket(key, “obtener_valor_de_pi”);
ResponsePacket resp = requestManager.send(req);
double pi = (Double)resp.getData();

Y en el servidor:

public class RemoteExecution implements RequestPacketListener {
    public ResponsePacket requestPacketArrived(RequestPacket requestPacket) {
        if (requestPacket.getPayload().equals(“obtener_valor_de_pi”)) {
            return new ResponsePacket(requestPacket.getKey(), 3.1416);
        }
        return null;
    }
}

Si bien este mecanismo es válido, está lejos de lo que queríamos; que era tener la misma sintaxis que la invocación a métodos locales:

double pi = mathService.getPI();

Y su implementación:

public MathService {
    public double getPI() {
        return 3.1416;
    }
}

Si podemos lograr esto último, estamos en la situación que queríamos desde el principio. En el próximo artículo vamos a ver la capa Servicio que, entre otras cosas, nos va a resolver este problema.

Hasta el próximo!