El “celular” de hoy en día es como una computadora con un montón de periféricos integrados: cámara, teclado, pantalla, teléfono celular, lector de memoria externa, wifi, gps, gsm, etc. Y todo esto en la palma de la mano.

Algunos de estos dispositivos móviles traen sistemas operativos propietarios, otros utilizan alguna versión de Windows, Linux o Symbian OS. Pero hay una características que la gran mayoría tienen en común: Java. Obviamente no es la versión de Java full power que se instala en nuestro desktop, laptop o servidor. Se trata de una versión adaptada a dispositivos móviles en los cuales no se cuenta con Gigas de RAM, o múltiples CPUs con frecuencias de reloj del orden de los Giga Hetrz.

Sorprendentemente, Java Micro Edition (JME, A.K.A. J2ME) tiene las características que la hacen una plataforma bien interesante para desarrollar aplicaciones y particularmente juegos. Y estos últimos son los que vamos a explorar.

Primero un poco de teoría

Dada la cantidad de dispositivos móviles -todos con características diferentes- se inventaron los “perfiles de capacidades”: MIDP por Mobile Information Device Profile. Dependiendo de la versión de MIDP, el dispositivo va a tener más o menos capacidades de: comunicación, presentación, audio, etc.

Además de MIDP, existe otra especificación llamada CLDC por Connected Limited Device Configuration, que define capacidades de bajo nivel del dispositivo, por ejemplo, si tiene la capacidad de manejar número con punto flotante.

MIDP se apoya en CLDC para formar la plataforma Java ME. La idea es desarrollar en la plataforma más compatible que se pueda. Hoy por hoy, la mayoría de los celulares soportan MIDP 2.0 y CLDC 1.1, pero si podemos restringirnos a CLDC 1.0 mejor. El Motorola V360 es un ejemplo de teléfono móvil con MIDP 2.0 y CLDC 1.0.

Entonces cuando empecemos a desarrollar, tenemos que elegir que versión de MIDP y CLDC vamos a utilizar. En la página de Oracle (http://java.sun.com/javame/technology/index.jsp), se puede encontrar más información y el SDK (http://java.sun.com/javame/downloads/index.jsp).

Bien, tenemos el SDK instalado, tenemos nuestra IDE de confianza configurada. ¿Y ahora qué? ¡A programar! Bueno, no tan rápido. ¿Cómo se programa un juego? Esto es algo que los que venimos haciendo IT desde ya hace años, no tenemos muy claro. En Internet hay mucha documentación, pero la realmente buena es escasa.

Primero que nada, veremos como es el esqueleto de un juego -en pseudocódigo-:

proceso entrada del usuario
actualizo el estado del juego
dibujo la pantalla
goto 1

Santo patrono de la informática, perdón por el goto.

No hay nada revelador en estas 4 lineas, pero lo que si se pueden empezar a ver algunos problemas. Por ejemplo: este juego va a ejecutar a distinta velocidad según de la potencia del celular. Algo claramente no deseable. Obviamente queremos que nuestro juego funcione a la misma velocidad en cualquier celular, sin importar la potencia del mismo.

Para esto, hacemos un pequeño cambio:

proceso entrada del usuario
actualizo el estado del juego
dibujo la pantalla
esperar X milisegundos
goto 1

Ahora variando X, podemos variar la velocidad del juego. Fácil… ¿no? Queda en manos del usuario elegir X mediante, por ejemplo, el menú el juego. Pero, ¿no se podría determinar X automáticamente? Mejor aún, ¿no se podría determinar X dinámicamente en cada vuelta del ciclo? Claro que sí. Ahora vemos como:

ciclos_por_segundo = 30
milisegundos_por_ciclo = 1000 / ciclos_por_segundo
t_inicial = ahora()
proceso entrada del usuario
actualizo el estado del juego
dibujo la pantalla
t_ciclo = ahora() - t_inicial
si (t_ciclo < milisegundos_por_ciclo) entonces
    esperar (milisegundos_por_ciclo - t_ciclo) milisegundos
goto 3

Nota: La función ahora() devuelve la hora actual en milisegundos, algo como lo que hace System.currentTimeMillis() en Java.

Lo que se hace es, tomar el tiempo que toma un ciclo completo (4, 5 y 6). Si ese tiempo es menor que la cantidad de tiempo que establecimos para cada ciclo en 1 y 2, entonces esperamos esa diferencia de tiempo. Así, todos los ciclos demoran lo mismo y el tiempo de espera se ajusta dinámicamente.

De esta forma logramos un rendimiento igual entre celulares de distinta potencia. Este método se puede mejorar implementando saltos de ciclos (frame skipping) cuando el celular es de muy baja potencia, pero corremos el riesgo de que el juego se vuelva injugable. Así, el juego ejecutará más lento en celulares de poca potencia, ya que todo el tiempo se consumirá en los puntos 4, 5 y 6 y nunca entrará en espera.

Es sorprendente la cantidad de cosas interesantes que se pueden hacer utilizando esta sencilla técnica.

A la práctica

Vamos a implementar, con esta técnica, el “hola mundo” de los juegos: el PONG de a uno.

Pong

Es como si fuera un Arkanoid, pero sin los ladrillos. Es verdad, no es muy divertido.

La implementación en Java del bucle principal sería algo así:

final int CICLOS_POR_SEGUNDO = 30;
final int MILISEGUNDOS_POR_CICLO = 1000 / CICLOS_POR_SEGUNDO;
while (true) {
    long tInicial = System.currentTimeMillis();
    procesarEntradaDelUsuario();
    actualizarEstadoDelJuego();
    dibujarLaPantalla();
    long tCiclo = System.currentTimeMillis() - tInicial;
    if (tCiclo < MILISEGUNDOS_POR_CICLO) {
        Thread.sleep(MILISEGUNDOS_POR_CICLO - tCiclo);
    }
}

Notar que hasta ahora no hay nada hecho particularmente para el PONG. Lo particular estará en las funciones procesarEntradaDelUsuario(), actualizarEstadoDelJuego() y dibujarLaPantalla().

La primera tiene la responsabilidad de tomar la entrada del usuario y modificar algo en el juego, en este caso sería la posición de la paleta. Sí, la paleta es ese rectángulo verde.. hay que tener imaginación

La segunda debe actualizar el estado interno del juego. En este juego, esta función tiene dos objetivos: a) mover la pelota y b) si la pelota se va hacia abajo, entonces el juego termina con el fatídico “Game Over”.

La tercer y última función, debe tomar el estado del juego y dibujarlo en la pantalla.

El código fuente se puede bajar desde acá: pong-scr.tar. En esta implementación, nunca se pierde. Cuando la pelota se va para abajo, aparece nuevamente en el medio de la pantalla. Un buen ejercicio, sería agregarle vidas, que aumente la velocidad de la pelota, darle aceleración a la paleta, mejorar los gráficos, agregarle ladrillitos, sonidos, powerups y ponerle un nombre marketinero (que no sea Arkanoid, claro ) y de ahí, a la fama!

Enjoy!

Una de la cualidades de Grails que personalmente más me gusta es su integración con JEE. Desde Grails podemos utilizar tags JSP, Session Beans y EntityBeans como si fueran parte integral del framework.
En este post nos centraremos en como podemos invocar SessionBeans ya sean remotos o locales desde nuestro código Grails. Esta posibilidad junto con el manejo de los EntityBeans le aportan a Grails adaptabilidad y escalabilidad. A que me refiero con esto, a que siendo prolijos podemos desarrollar una aplicación entera en Grails y luego más adelante pasar los modelos y los servicios a Entities y SessionBeans respectivamente. De esta forma podemos comenzar rápidamente a desarrollar nuestra aplicación haciendo uso de las ventajas de estar en un ambiente dinámico y luego cuando la aplicación está más definida y los cambios no son lo común entonces podemos pasar la capa de negocios a JEE. Este cambio no afecta a ningún otro componente de Grails como ser controladores o vistas.
Para lograr esto último todo lo que debemos hacer es sustituir el código de las operaciones de los servicios por delegación a la misma operación en los SessionBeans creados.

A continuación veremos como se configura Grails para utilizar SessionBeans tanto para EJB3.0 como EJB2.1

Inyectando los SessionBeans
Grails permite inyectar tanto en los servicios como en los controladores cualquier SB al igual que lo hace con sus servicios. Al Grails utilizar Spring en el manejo de sus componentes es posible utilizar todas las ventajas de este dentro de Grails. La forma más sencilla de configurar los objetos a ser inyectados dentro de los controladores o servicios, y en especial los SB, es utilizando el archivo resources.groovy. Este archivo es equivalente a el archivo applicationContext.xml de Spring solo que en vez de ser un archivo XML es una clase groovy que utiliza el SpringBuilder como DSL para la configuración. Por defecto el archivo resources que se encuentra en grails-app/conf/spring y tiene el siguiente contenido:

// Place your Spring DSL code here
beans = {

}

Dentro del closure es donde se deben agregar las definiciones de los beans.

Configuración de servidor JNDI
Para poder acceder a cualquier componente que se encuentra en un servidor de aplicaciones debemos hacerlo utilizando JNDI. Para esto Spring provee una clase utilitaria la cual facilita las operaciones sobre un servidor de nombres JNDI como ser lookup y a su vez actúa como un proveedor de contexto JNDI. Para esto hay que agregar la siguiente definición en el resources.groovy

	ejbJndi(org.springframework.jndi.JndiTemplate){
		environment = [
			"java.naming.factory.initial" : "org.jnp.interfaces.NamingContextFactory",
			"java.naming.provider.url" : "jnp://http://localhost:1099

Donde:

• ejbJndi

Es el nombre del bean el cual es de tipo org.springframework.jndi.JndiTemplate. Este nombre puede ser cualquiera. Es a este nombre que se hará referencia para determinar el servidor de nombres que provee el acceso a un objeto.

• environment

Es la propiedad de JndiTempalte la cual se configura con un Mapa que tiene las propiedades JNDI

En un archivo podrían existir tantas definiciones de JndiTemplate como proveedores JNDI se necesiten acceder.

Configuración de servidor JNDI por ENVIRONMENT
Es muy probable y necesario, que el servidor JNDI requiera diferente configuración de IP y puerto según sea el ambiente desarrollo, producción o testing. Para lograr esto se debe anexar a la configuración anterior lo siguiente:

• Colocar el valor de la IP y puerto del JBoss en cada environment del Config.groovy.
• Importar la clase ConfigurationHolder en el archivo resources.groovy
• Sustituir la ip y puerto de la variable "java.naming.provider.url" por las cargadas en la configuración.

Ejemplo
Config.groovy

  ...
  environments {
    development {
        ...
        jboss.ip = "10.200.8.173"
        jboss.port = "1099"
        ...
    }
    production {
        ...
        jboss.ip = "172.16.2.105"
        jboss.port = "1099"
        ...
    }

Resources.groovy

     import org.codehaus.groovy.grails.commons.*
     ...
	ejbJndi(org.springframework.jndi.JndiTemplate){
		environment = [
			"java.naming.factory.initial" : "org.jnp.interfaces.NamingContextFactory",
			"java.naming.provider.url" : "jnp://"+ConfigurationHolder.config.jboss.ip+":"+ConfigurationHolder.config.jboss.port]
	}

Configuración de componentes EJB 3.0
Para poder inyectar componentes EJB 3.0 tenemos que agregar la siguiente configuración:

	xXXServices(org.springframework.jndi.JndiObjectFactoryBean){
		jndiName = "XXXServices/remote"
		jndiTemplate = ref("ejbJndi")
	}

Donde:

• xXXServices

Es el nombre que se le dará a la referencia remota al SB y que será utilizado para inyectar esta en los controladores y servicios. Cualquier controlador o servicio que tenga una propiedad con nombre xXXServices se le inyectara la referencia al SB remoto definido por ese nombre en el archivo resources.groovy. La primer x es en minúscula para indicar que por convención el nombre debe comenzar en minúscula.

• jndiName

Nombre por el cual se va a buscar la referencia al SB en el servidor JNDI

• jndiTemplate

Nombre del bean que se va a utilizar como provider para acceder al objeto JNDI. Es el definido en el punto anterior.

Para utilizar el SB en un servicio sería:

public class EjemploServices {
	def xXXServices

	void unMetodo(param1, param2) {
		xXXServices.invocoMetodoEnEJB(param1, param 2)
	}
}

Configuración de componentes EJB 2.1
Para poder inyectar componentes EJB 2.1 tenemos que agregar la siguiente configuración que es similar a la vista para EJB 3.0.

 xXXServices(org.springframework.ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean) {
		jndiName = "EJBXXXServices"
		businessInterface = "biz.aquait.yyy.ejb.EJBXXXServices"
		jndiTemplate = ref("ejbJndi")
		refreshHomeOnConnectFailure = true
                lookupHomeOnStartup=false

	}

Donde:

• xXXServices

Es el nombre que se le dará a la referencia remota al SB y que será utilizado para inyectar esta en los controladores y servicios. Cualquier controlador o servicio que tenga una propiedad con nombre xXXServices a esta se le inyectara la referencia al SB remoto definido por ese nombre en el archivo resources.groovy. La primer x es en minúscula para indicar que por convención el nombre debe comenzar en minúscula.

• jndiName

Nombre por el cual se va a buscar la referencia al SB en el servidor JNDI

• refreshHomeOnConnectFailure

Refresca la home cuando detecta un fallo en la conexión, por ejemplo cuando se reinicia el servidor

• lookupHomeOnStartup

Hace que la aplicación no haga el lookup a levantar sino al utilizar servicios del SB.

• jndiTemplate

Nombre del bean que se va a utilizar como provider para acceder al objeto JNDI. Es el definido en el primer punto.

• businessInterface

La interfaz remota del SB, es decir la que extiende EJBObject.

La forma de utilizar el SB dentro de un servicio u otro componente es la misma forma que las referencias a SB implementados  con EJB 3.0.

Conclusión

Siguiendo los pasos presentados arriba podemos decir que configurar Grails para utilizar  SB no es engorroso y que el uso de estos dentro del framework es transparente ya que se usan de la misma forma que un servicio de Grails.

En la medida que adquiría experiencia me daba cuenta que faltaba algo. Tenía la sensación que lograba las metas con un esfuerzo personal muy importante, pero mi equipo lo hacía de forma irregular.

Luego de decenas de proyectos comencé a buscar la verdadera razón del éxito. Comprendí que éste radica en la naturaleza de las personas que trabajan en él, sumado al conocimiento técnico adecuado. Por esta razón, siempre considere a mi equipo de trabajo como el “gran actor” de un proyecto y siempre intente generar el contexto más adecuado para obtener el mayor rendimiento de ellos, incluyendo la motivación personal.

También aprendí que si quieres hacer un proyecto exitoso debes estar dispuesto a darle paso a quienes te acompañan en el trabajo cotidiano. Sin importar el nivel jerárquico, todos quieren ser reconocidos, todos quieren proponer, todos quieren aportar al objetivo. He aquí lo difícil, intentar satisfacer estas necesidades. Siempre intente hacerlo, convencido que era fundamental para lograr el objetivo.

Hace un par de años atrás, descubrí que muchas de esas premisas, en las cuales yo me basaba intuitivamente, estaban plasmadas en algo llamado SCRUM. Comencé a leer con ahínco, y poco a poco me daba cuenta que había encontrando lo que desde hace tiempo buscaba. Un marco de trabajo que pone por escrito el sentido común, basándose en el valor que aportan las personas, el vínculo, la creatividad, la crítica constructiva, la auto-enseñanza y la auto-organización.

¿Acaso alguien cree que es un buen project manager por hacer cronogramas, calcular presupuestos, hacer cumplir órdenes? Si estás o has estado desempeñando este rol, seguramente pienses que nada de lo anterior fue fundamental en el éxito de un proyecto. En mi opinión, un buen project manager es quién logra llevar a cabo un proyecto sintiendo que realmente tuvo el control del proyecto, fue el gestor, pero sabe perfectamente que sin el equipo de trabajo, solamente con su aporte individual no lograba el objetivo.

Del análisis anterior surge el tipo de líder que propone SCRUM, el líder que articula, orquesta, comanda, pero prácticamente no aparece en escena. Logrando el compromiso profesional de su equipo de trabajo plasmado en productos tangibles, que agreguen valor al cliente. Todo esto, conjugado con ciclos de desarrollo cortos, permiten corregir en base al empirismo y siempre con riesgo de bajo costo.

Muchas veces, al hablar de metodologías ágiles, tales como SCRUM, los project manager pensamos en anarquía y poca intensidad, cuando en realidad es exactamente lo contrario. Para practicar correctamente SCRUM se exige disciplina e intensidad, sostenidas en el tiempo.

Podría haber escrito un artículo que explicara aburridamente SCRUM, pero iría contra la esencia de éste método, por tal razón, los invito a aprender SCRUM. Luego habrá tiempo para decidir si lo practican o no, pero no lo quiten de sus escenarios por desconocimiento. Piensen, por algo está siendo utilizado por las grandes empresas del mundo de tecnología; Google, Yahoo, Microsoft, HP, Novell, SAP, Nokia, Xerox, etc.

Intro

Siguiendo en la linea de la introspección, hoy vamos a ver una simple reflexión que nos va a permitir invocar sobre una instancia de una clase a métodos por su nombre.

What for?

La reflexión es una característica interesante, que se hace fundamental a la hora de diseñar componentes genéricos. Nos permite crear instancias de determinada clase con el nombre de la clase o también invocar métodos sobre una instancia de una clase teniendo el nombre del método. Esto, por ejemplo, nos simplifica enormemente la implementación del patrón command.

How? What?!

En GWT (al menos hasta la 1.7) no hay reflexión. Lo que vamos a hacer en esta implementación de reflexión, es proveer un mecanismo para invocar métodos por nombre. Suponiendo que tenemos una clase llamada MiClase que tiene un método llamado miMetodo buscamos poder hacer algo así:

MiClase instancia = new MiClase();

String nombreMetodo = “miMetodo”;

Object[] parametros = new Object[]{...};

invocar(instancia, nombreMetodo, parametros);

Enter generators!

Lo que vamos a hacer es que GWT genere la clase MiClaseReflection. ¿Cómo? Usando generators. Esta es una característica bien interesante de GWT. El foco de este artículo no está en explicar generators, hay mucha literatura en Internet. Acá va un link: http://code.google.com/intl/es/webtoolkit/doc/1.6/DevGuideCodingBasics.html#DevGuideDeferredBinding. Igual no hay que ser un experto para entender lo que vamos a hacer.

Básicamente vamos a escribir una clase que genere el código de MiClaseReflection, que tiene un único método -invocar- que es una cadena if..elseif..else que pregunta por cada método de MiClase y si alguna coincide, se lo invoca. Sería algo como esto:

if (nombreMetodo.equals(“miMetodo1”)) {

    target.miMetodo1(params);  // void

} else if (nombreMetodo.equals(“miMetodo2”)) {

    return target.miMetodo2(params); // no void

} else {

    throw new Exception(“método no encontrador: ” + nombreMetodo);

}

Obviamente falta chequeos de parámetros.

Para no tener que realizar ningún paso previo a la compilación generando la clase con alguna utilidad externa vamos a usar la API que tiene GWT que permite extender el compilador (com.google.gwt.core.ext). NOTA: Los que hayan utilizado APT de Java van ver unas cuantas similitudes (http://java.sun.com/javase/6/docs/technotes/guides/apt/index.html).

Cuando el compilador de GWT encuentra con la instrucción GWT.create(class) –que devuelve una implementación de la interfaz class– invoca al generador asociado a la interfaz class (esta asociación se declara en el gwt.xml del módulo). En este generador se “escribe” el código que implementa la interfaz class. Para escribir este código tenemos la asistencia de la API com.google.gwt.core.ext.typeinfo que recuerda mucho a la API Mirror Reflection de Java.

Generate

La instrucción GWT.create() toma una interfaz y devuelve una implementación de la misma. Entonces vamos definir una interfaz de marca y la vamos a llamar Reflectable. Toda clase que queramos tener soporte de reflexión va a tener que implementar esta interfaz:

public interface Reflectable {

}

Entonces la clase MiClase:

public class MiClase implements Reflectable {

    void miMetodo1();

    int miMetodo2();

}

Además, tenemos que tener la interfaz de idioma de la reflexión:

public interface Reflection<I extends Reflectable> {

    Object invoke(I target, String methodName, Object... params)

    throws InvocationException;

}

Para obtener una reflexión y usarla suponiendo que miMetodo no tiene parámetros:

MiClase objeto = new MiClase();

Reflection<MiClase> reflection = GWT.create(MiClase.class);

reflection.invoke(objeto, “miMetodo”);

Para asociar el generador con la interfaz Reflectable, agregamos el siguiente fragmento al :

    <generate-with class="com.aquait.utils.gwt.rebind.ReflectionGenerator">

        <when-type-assignable class="com.aquait.utils.gwt.reflection.Reflectable"/>

    </generate-with>

Así, cuando el compilador de GWT encuentra GWT.create(MiClase.class), llama al generador pues la clase MiClase implementa Reflectable. Luego, tenemos una implementación de la interfaz Reflectable para la clase MiClase.

Para usarlo en un proyecto, hay que agregar esto en el <modulo>.gwt.xml:

<inherits name="com.aquait.utils.gwt.Reflection"/>

El JAR se puede descargar de acá: introspection-reflection4gwt.jar

Nota: Este JAR tiene una versión actualizada de la introspección que elimina los métodos getIntrospectable() y setIntrospectable() de la interfaz Introspection. Por lo tanto, los métodos getProperty() y setProperty() toman como primer parámetro al Introspectable.

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

]]> http://blog.aquait.info/2009/10/180/feed/ 0 http://blog.aquait.info/2009/10/java-appserver-02-dbpool-messaging/ http://blog.aquait.info/2009/10/java-appserver-02-dbpool-messaging/#comments Wed, 28 Oct 2009 18:17:16 +0000 Enrique http://blog.aquait.info/?p=175

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.

]]> http://blog.aquait.info/2009/09/112/feed/ 0 http://blog.aquait.info/2009/09/java-rpc-07-extras-y-rendimiento/ http://blog.aquait.info/2009/09/java-rpc-07-extras-y-rendimiento/#comments Mon, 07 Sep 2009 01:07:39 +0000 Enrique http://blog.aquait.info/?p=104

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!

]]> http://blog.aquait.info/2009/09/java-rpc-07-extras-y-rendimiento/feed/ 0 http://blog.aquait.info/2009/09/introspeccion-en-gwt/ http://blog.aquait.info/2009/09/introspeccion-en-gwt/#comments Wed, 02 Sep 2009 18:23:27 +0000 Enrique http://blog.aquait.info/?p=89

Intro

Una de las características que más se extrañan a la hora de utilizar GWT es la capacidad de Java de realizar introspección sobre beans. La causa de esta limitación es que GWT no tiene emulación la API reflexión (java.lang.reflect). En este artículo vamos a ver como podemos implementar una suerte de introspección en GWT. También vamos a explorar algunas aplicaciones de introspección, ya que en principio no es trivial su utilidad.

What for?

Lo primero que vamos a ver es para qué queremos esto.

Supongamos que queremos desarrollar un framework de componentes visuales que tenga data binding (capacidad de “enganchar” la propiedad de un objeto a un componente visual). Seguramente a todo aquel que le tocó la “maravillosa” tarea de implementar un CURD (ABM en criollo) se topó con la tediosa tarea de setear y leer de los componentes visuales al objeto y viceversa. Si te tocó hacer esto, algo malo hiciste . Bueno, esta es una tarea tan aburrida como propensa a errores, sobre todo de Control-C + Control-V. Si pudieramos decir algo como: “este componente UI mira la propiedades tal de cual objeto”, entonces podemos aliviar bastante esta tarea ya que por ejemplo nos ahorramos todo el código de manejo de eventos.

Entonces si podemos hacer esto, podemos construir un conjunto de componentes a los cuales simplemente le seteamos el bean y la propiedad que “mira” así cuando al componente se le cambia el valor, automáticamente se refleja en el bean y viceversa.

Pero ¿cómo hacer esto sin introspeccion?

How? What?!

Como vimos, en GWT (al menos hasta la 1.7) no hay reflexión, por lo que no nos queda más remedio que buscar otra forma de implementar introspección. Primero vamos a ver qué es la introspección en Java. Según el JavaDoc de la clase java.beans.Introspector:

“The Introspector class provides a standard way for tools to learn about the properties, events, and methods supported by a target Java Bean.”

En español:

“La clase Introspector provee una forma estándar para que herramientas descubran propiedades, eventos y métodos soportados por un Java Bean”.

La parte que más nos interesa es la parte de las propiedades. O sea, queremos poder implementar un mecanismo con el cual se le pueda preguntar a un Java Bean cuales son sus propiedades y cuales son los valores de estas.

La forma que vamos a implementar es creando una clase que sea la introspección para cada clase que queramos tener introspección.

Entonces para la clase:

public class Persona {
    private String nombre;
    private String direccion;
    private Date nacimiento;
    private boolean sexo;

    public Persona() {
    }

    public String getNombre() {
        return nombre;
    }
    public void setNombre(String nombre) {
        this.nombre = nombre;
    }

    // ...más getters y setters...
}

Tenemos que implementar la clase de “introspección”:

public PersonaIntrospection {
    private Persona persona;

    public PersonaIntrospeccion() {
    }

    public Persona getPersona() {
        return persona;
    }

    public Persona setPersona(Persona p) {
        persona = p;
    }

    public List<String> getProperties() {
        List<String> l = new ArrayList<String>();
        l.add(“nombre”);
        l.add(“direccion”);
        l.add(“nacimiento”);
        l.add(“sexo”);
    }

    public Object getProperty(String property) {
        if (“nombre”.equals(property))
            return persona.getNombre();
        else if (“direccion”.equals(property))
            return persona.getDireccion();
        else if (“nacimiento”.equals(property))
            return persona.getNacimiento();
        else if (“sexo”.equals(property))
            return persona.getSexo();
        else
            throw new IllegalArgumentException(property);
    }

    public void setProperty(String property, Object value) {
        if (“nombre”.equals(property))
            persona.setNombre((String)value);
        else if (“direccion”.equals(property))
            persona.setDireccion((String)value);
        else if (“nacimiento”.equals(property))
            persona.setNacimiento((Date)value);
        else if (“sexo”.equals(property))
            persona.setSexo((Boolean)value);
        else
            throw new IllegalArgumentException(property);
    }
}

Más allá de las optimizaciones que se le pueden hacer al código (como cachear la lista de propiedades), la idea es que se entienda de por qué esta clase nos da introspección sobre un objeto persona. Como ya se deben estar imaginando, la gracia es no tener que escribir la clase PersonaIntrospection. La gracia es trabajar menos en cosas aburridas y más en cosas “divertidas“

Enter generators!

Lo que vamos a hacer es que GWT genere la clase PersonaIntrospection. ¿Cómo? Usando generators. Esta es una característica bien interesante de GWT. El foco de este artículo no está en explicar generators, hay mucha literatura en Internet. Acá va un link http://code.google.com/intl/es/webtoolkit/doc/1.6/DevGuideCodingBasics.html#DevGuideDeferredBinding. Igual no hay que ser un experto para entender lo que vamos a hacer.

Básicamente vamos a escribir una clase que genere el código de XxxIntrospection para la clase Xxx según vimos en el ejemplo de Persona. Y (para no tener que realizar ningún paso previo a la compilación generando la clase con alguna utilidad externa) vamos a usar la API que tiene GWT que permite extender el compilador (com.google.gwt.core.ext). NOTA: Los que hayan utilizado APT de Java van ver unas cuantas similitudes (http://java.sun.com/javase/6/docs/technotes/guides/apt/index.html).

Cuando el compilador de GWT encuentra con la instrucción GWT.create(class) –que devuelve una implementación de la interfaz class– invoca al generador asociado a la interfaz class (esta asociación se declara en el gwt.xml del módulo). En este generador se “escribe” el código que implementa la interfaz class. Para escribir este código tenemos la asistencia de la API com.google.gwt.core.ext.typeinfo que recuerda mucho a la API Mirror Reflection de Java.

Generate

Ahora vamos a ver el generador en si. Pero primero vamos a ver como se utiliza. GWT.create() toma una interfaz y devuelve una implementación de la misma. Entonces vamos definir una interfaz de marca y la vamos a llamar Introspectable. Toda clase que queramos tener soporte de introspección va a tener que implementar esta intefaz:

public interface Introspectable {
}

Entonces la clase Persona:

public class Persona implements Introspectable {
    // ... atributos y métodos ...
}

Además, tenemos que tener la interfaz de idioma de la introspección:

public interface Introspection<I extends Introspectable> {
    I getIntrospectable();
    void setIntrospectable(I i);
    <T> T getProperty(String propName);
    void setProperty(String propName, Object value);
    Collection<String> getPropertyNames();
}

Y para obtener una introspección y usarla:

Persona persona = new Persona();
Introspection<Persona> instrospection = GWT.create(Persona.class);
instrospection.setIntrospectable(persona);

for (String prop : instrospection.getPropertyNames()) {
    System.out.println(prop + " = " + instrospection.getProperty(prop));
}

String nombre = instrospection.getProperty("nombre");
String direccion = instrospection.getProperty("direccion");
Date nacimiento = instrospection.getProperty("nacimiento");
Boolean sexo = instrospection.getProperty("sexo");

Para asociar el generador con la interfaz Introspectable, agregamos el siguiente fragmento al :

<generate-with class="com.aquait.utils.gwt.rebind.IntrospectionGenerator">
    <when-type-assignable class="com.aquait.utils.gwt.introspection.Introspectable"/>
</generate-with>

Así, cuando el compilador de GWT encuentra GWT.create(Persona.class), llama al generador pues la clase Persona implementa Introspectable. Luego, tenemos una implementación de la interfaz Introspection para la clase Persona.

Para usarlo en un proyecto, hay que agregar esto en el <modulo>.gwt.xml:

<inherits name="com.aquait.utils.gwt.Introspection"/>

El módulo GWT se puede descargar de acá: introspection4gwt

EDIT: se actualizó el archivo debido a un pequeño bug.

EDIT: se volvió a actualizar debido a un bug que hacía que no se tomaran en cuenta las propiedades de las super clases.