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

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!

Hoy veremos la capa Sesión. Como el nombre lo indica, la idea de esta capa es la de representar la sesión, tanto para el cliente como para el servidor. En el cliente va a haber una única sesión, mientras en el servidor van a existir una por cada cliente conectado. La principal responsabilidad de esta capa es mantener el estado del cliente del lado del servidor.

Esta capa es bastante sencilla está compuesta por tres clases y una interfaz. Al igual que en la capa conexión, hay clases que se comparten entre el cliente y el servidor y hay clases que solo se usan del lado del servidor, en realidad hay una sola que se usa exclusivamente del lado del servidor: la clase SessionManager.

El diseño sigue la misma filosofía que el de la capa Conexión: tiene su propio paquete, se basa en el patron Observer para notificar la llegada de mensajes y tiene la primitiva send(p) para enviar mensajes.

Diseño de la capa Sesión

La clase Session es el centro del diseño; cada instancia va a escuchar por ConectionPacket a través de la Connection asociada y va a notificar al SessionPacketListener. Este es el funcionamiento tanto del lado del cliente como del lado del servidor para el envío y recepción de paquetes.

Además, el servidor acepta conexiones mediante el SessionManager, ya que es un ConnectionListener. Cuando se acepta la conexión este crea la Session para esta nueva conexión.

En el próximo artículo vamos a ver la capa Pedido, que tiene bastante jugo.

Feliz nostalgia

Para comenzar, recordemos que la responsabilidad de esta capa es comunicar al cliente y al servidor mediante la red. La capa conexión que se va a implementar va a ser sobre TCP/IP, pero el diseño permite que se pueda implementar sobre otros protocolos.

Acá va el diagrama de clases (en UML):

Diseño de la capa Conexión

Como se puede ver, el diseño es bastante sencillo. El principal servicio de esta capa, lo provee la clase Conection con el método send(ConnectionPacket p). La clase ConnectionPacket, no es otra cosa que la unidad de trabajo de esta capa. En general, todas las capas van a tener su packet.

Cuando un paquete llega a la clase Connection, esta notifica de la llegada del mismo mediante el evento connectionPacketArrived de la interfaz ConnectionPacketListener. Se da una suerte de patron Observer. Notar que la clase Connection es un Thread, así puede atender y autónomamente los paquetes que llegan.

Acá presentamos el diagrama de secuencia para el envío y llegada de un paquete desde el cliente:

Envío y llegada de un mensaje

En el servidor ocurre algo similar, cuando llega un paquete a la clase Connection, se notifica al ConnectionPacketListener para que procese el mensaje. Si corresponde una respuesta, se enviará de la misma forma que en el cliente. La idea es que la clase Connection sea la misma tanto para el lado del cliente como para el lado del servidor.

Recepción de un mensaje en el servidor

El último caso que queda ver es qué sucede cuando una petición de conexión de un nuevo cliente. Acá es donde entran en juego la clase ServerConnection y la interfaz ConnectionListener.

La clase ServerConnection es responsable de escuchar por conexiones y cuando llega una, notifica mediante el evento newConnection(Connection c) de la interfaz ConnectionListener. Entonces, cuando llega una nueva conexión al servidor, el implementador de newConnection va a crear una nueva Connection para atender al nuevo cliente.

A grandes rasgos, esta es la capa Conexión. A la hora de implementar aparecen algunos detalles de sincronización de threads y manejo de sockets, pero nada del otro mundo.

Es importante comprender el mecanismo del eventos ya que se utiliza en todas las capas del RPC.

En el próximo artículo estaremos analizando la capa Sesión.

Este es el primero de una serie de artículos en los cuales presentaré el diseño y desarrollo de un mecanismo RPC en Java. Este RPC va a ser multi-hilo del lado del servidor para que pueda atender varios pedidos a la vez; y también va a ser multi-hilo del lado del cliente para que pueda realizar varios pedidos a la vez al servidor.

Primero lo primero: arquitectura

Algo importante en cualquier sistema medianamente complejo, es la arquitectura. Esta característica determinará lo flexible, extensible y mantenible del sistema.

Siguiendo el principio de divide+conquista elaboraremos una arquitectura en capas (o stack de capas) tanto del lado del cliente como del lado del servidor. La idea es que cada capa se comunica “lógicamente” con su homóloga y “físicamente” con la capa inferior.

Arquitectura de capas

Responsabilidades de cada una de las capas:

• La capa Conexión se encarga de mantener la conectividad entre el cliente y el servidor. Del lado del cliente se mantiene un socket con el servidor. Del lado del servidor, se mantienen todas las conexiones (sockets) con los clientes.

• La capa Sesión se encarga de mantener los datos de la sesión. La razón de esta capa es que si hay un problema de comunicación, no se pierda la sesión y el cliente se pueda reconectar.

• La capa Pedido se encarga del lado del cliente de gestionar los pedidos realizados por los servicios en forma concurrente. Del lado del servidor los pedidos se despachan, también concurrentemente, a los servicios servidor.

• La capa servicio es la que usa el cliente para comunicarse con el servicio servidor. Cada servicio consta de dos partes: la interfaz que utiliza el cliente y la implementación que está en el servidor.

Así, un pedido generado en la capa Servicio del cliente pasa virtualmente a la capa Servicio del servidor y si corresponde una respuesta, recorrerá el camino inverso. De esta forma se logra la invocación remota.

Además, la idea es que no haya diferencia (a nivel sintáctico) entre una llama remota y una llamada local, así en el código del cliente:

double pi = mathService.getPi();

Como se ve, no se distingue si se trata de una llamada local o una llamada remota. Este es el efecto que se busca.

En sucesivos artículos exploraré cada una de las capas, comenzando por la capa Conexión.

Hasta el próximo!