Mi granito de java

Página en G+

2012-09-12T08:37:00.000-03:00

He realiado una página en Google Plus sobre "Mi granito de Java". Mi intención es que este Blog sea para educación y la página en G+ para compartir novedades, eventos y humor del mundo IT.

Aquellos que quieran seguirla este es el link: https://plus.google.com/u/0/b/101928657082381280272/101928657082381280272

Api Reflection

2012-09-07T09:23:00.000-03:00

Api Reflection

Java posee un API muy poderosa que no se encuentra en la gran mayoría de los lenguajes. Se trata del API Reflection, que permite comunicarse casi directamente con la máquina virtual de java.
Dicho de otra forma, permite inspeccionar y manipular clases y objetos sin conocer a priori con que objetos estamos trabajando. Este API es utilizada por la gran mayoría de los frameworks como por ejemplo Hibernate o Spring.

La clase Class.

Todos los objetos en java heredan de java.lang.Object y por ello estan dotados del método public final Class getClass(). Este método nos devuelve un objeto java.lang.Class, que va a ser nuestro punto de entrada al API Reflection. En nuestro caso vamos a usar una clase sencilla como ejemplo. La clase Persona, que tiene 4 atributos con sus getters y setters:

Hay diversas formas de obtener el objeto Class. Las más comunes son:

En el primer caso la obtengo de una clase en particular. Si estoy parado en dicha clase también es posible hacer this.getClass(). En el segundo caso obtengo Class a partir de un objeto. Y en el tercer caso obtengo Class a partir del nombre de la clase.

Una vez obtenida la clase es posible acceder a un montón de métodos muy útiles. Los principales son:

Field getField(String name): devuelve un campo público de la clase, a partir de su nombre. Si la clase no contiene ningún campo con ese nombre, se comprueban sus superclases recursivamente, y en caso de no encontrar finalmente el campo, se lanzará la excepcion java.lang.NoSuchFieldException.
Field[] getFields(): devuelve un array con todos los campos públicos de la clase, y de sus superclases.
Method[] getMethods(): devuelve un array con todos los métodos públicos de la clase, y de sus superclases. También existe el método getMethod que se le puede pedir un método en particular.
Class[] getInterfaces(): devuelve un array con todos los interfaces que implementa la clase.
Constructor[] getConstructors(): devuelve un array con todos los constructores públicos.
También es posible crear un objeto de una clase en particular en tiempo de ejecución gracias al método: public T newInstance().

Nos devuelve un Object que luego podemos castear a la clase correspondiente.

Hay varios métodos más que se pueden utilizar. La lista completa esta acá: http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html

Si observamos la lista veremos que varios se repiten pero con la palabra Declared en la firma. Por ejemplo, tenemos getMethods y getDeclaredMethods. La diferencia radica en que el primero obtiene los métodos públicos de la clase y los heredados y el segundo los métodos públicos y privados pero no los heredados.

java.lang.reflect.Field

Field es una clase que representa un atributo de una clase en al API reflection. Tiene muchos metodos interesantes como por ejemplo:

public String getName(): es el nombre del atributo.
public Class getType(): devuelve la clase del atributo.
public int getModifiers(): devuelve los modificadores de un campo representados por un entero que se corresponde con las constantes definidas en la clase java.lang.reflect.Modifier.
public Object get(Object obj): devuelve el valor del atributo.
public void set(Object obj, Object value): setea un valor al atributo.

java.lang.reflect.Method.

Como se habrán imaginado Method tes una clase que representa un método. También tiene varios métodos muy útiles, como por ejemplo:

public String getName(): nombre del método.
public Class[] getParameterTypes(): array con las clases de los parámetros del método.
public Class[] getExceptionTypes(): array con las clases de las excepciones.
public Class getReturnType(): devuelve la clase del valor que devuelve el método.
public Object invoke(Object obj, Object... args): ejecuta el método sobre un objeto, pasándole los parámetros como segundo argumento si es que los necesita. Veremos un ejemplo sobre su uso al final de este post.

Veremos que diferencia hay entre los metodos getMethods() y getDeclaredMethods().

Como se puede observar getDeclaredMethods() puede ser más util en la mayoría de los casos.

Un ejemplo integrador.

Les voy a mostrar un ejemplo que tuve que hacer para el trabajo. Si bien no es exactamente el mismo, es bastante similar. Resulta que nuestra aplicación enviar por web service ciertos datos para que otra aplicación lo pueda mostrar por una página web. Básicamente envía objetos simples con atributos que sean primitivos o Strings con sus getters y setters.

Esta otra aplicación es un semi enlatado que necesita los datos "escapeados". Esto quiere decir, sin acentos ni caracteres raros, sino con el escape de html.

Nos avisaron de esto muy poco tiempo antes de entregar el producto como no podía ser de otra manera. Por suerte existe una clase en el apache commons lang que nos ayudó mucho ya que tiene un método que convierte un String normal en uno escapeado: StringEscapeUtils.escapeHtml(String s).

El problema es que teniamos que recorrer cada uno de nuestros objetos y escapear cuando sean Strings. Y la realidad es que los seteabamos por toda nuestra aplicación y no lo podiamos hacer en la misma clase (que igual era muy molesto) debido a que también guardabamos el valor en nuestra base de datos y allí no tenía que estar escapeado.

Por ello decidimos utilizar reflaction para que le podamos enviar cualquier objeto y por reflection cambie todos sus strings por strings escapeados:

Y su uso sería el siguiente:

Conclusión.

Este API es muy poderosa y permite realizar muchas cosas que en otro lenguaje sería casi imposible. Pero uno debe evitar a toda costa abusar de la misma. Las personas que hace poco la conocen quieren utilizarla en todos lados y realmente puede hacer mucho lío en el código y en su lectura.

Introducción a Hibernate

2011-08-14T01:44:00.000-03:00

En este post voy a hacer una introducción a Hibernate. Tan sólo un Hola Mundo para que se entiendan los conceptos principales. Luego más adelante haré otras entradas para profundizar un poco más sobre este framework.

Hibernate.

“Hibernate es una herramienta de Mapeo objeto-relacional (ORM) para la plataforma Java (y disponible también para .Net con el nombre de NHibernate) que facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicación, mediante archivos declarativos (XML) o anotaciones en los beans de las entidades que permiten establecer estas relaciones. Hibernate es software libre, distribuido bajo los términos de la licencia GNU LGPL. “ - Wikipedia.

Hibernate es un framework que agiliza la relación entre la aplicación y la base de datos. De todos los frameworks ORM que he utilizado, sin dudas es el más completo.
Para aprender Hibernte es necesario tener los conocimientos mínimos de SQL y Java. Conocer JDBC es recomendable. Se puede bajar (en principio con bajar Hibernate Core alcanza) de www.hibernate.org

¿Por que usar un framework ORM?

Cuando uno desarrolla una aplicación se dará cuenta que en la gran mayoría de los casos todo termina siendo un conjunto de ABMs (alta, baja, modificación de datos) para luego poder consultarlos. Para ello se utiliza una base de datos, donde existirán muchas tareas repetidas: por cada objeto que quiero persistir debo crear una clase que me permita insertalo, eliminarlo, modificarlo y consultarlo. Salvo aquellas consultas fuera de lo común, el resto es siempre lo mismo. Aquí es donde entra a jugar un rol importante un ORM: con solo configurarlo ya tiene todas esas tareas repetitivas realizadas y el desarrollador solo tendrá que preocuparse por aquellas consultas fuera de lo normal.

¿Como funciona Hibernate?

Básicamente el desarrollador deberá configurar en un archivo XML o mediante annotations donde corresponde un atributo de una clase, con una columna de una tabla. Es una tarea relativamente sencilla donde existen herramientas que lo hacen por nosotros. En principio voy a realizar los ejemplos con archivos xml y luego, en otro post, los haré mediante annotations.

Configuración.

Vamos a hacer un paso a paso para dejar todo listo. Primero vamos a colocar los jars en el proyecto. Aqui van los de hibernate (que vienen en la carpeta lib de la distribución), más el del driver correspondiente a la base de datos que esten utilizando. Yo voy a utilizar DB2. A continuació voy a colocar los jars necesarios. He colocado los de Hibernate + DB2 + MySQL por si alguno la usa.

Luego vamos a crear una sencilla tabla en la base de datos:
Para MySQL:

CREATE TABLE `autos` (

`IDAUTO` int(10) unsigned NOT NULL auto_increment,

`MARCA` varchar(255) NOT NULL default '',

`MODELO` varchar(255) NOT NULL default '',

PRIMARY KEY (`IDAUTO`)

)

Para DB2:

CREATE TABLE hib.AUTOS (

IDAUTO BIGINT NOT NULL,

MARCA VARCHAR(255),

MODELO VARCHAR(255)

);

CREATE UNIQUE INDEX SQL1108120858221120 ON hib.AUTOS (IDAUTO ASC);

ALTER TABLE hib.AUTOS ADD CONSTRAINT SQL1108128085281980 PRIMARY KEY (IDAUTO);

El siguiente paso es configurar un SessionManager que me permite obtener sesiones y transacciones para trabajar con la base de datos. En este caso haremos uno sencillo, que no sirve para trabajar en producción, pero que nos permite realizar nuestros ejemplos.
Aca les dejo la clase, comentada para que se entienda de donde salen todos los datos.

package configuracion;

import java.util.Properties;

import org.hibernate.HibernateException;
import org.hibernate.MappingException;
import org.hibernate.Session;
import org.hibernate.cfg.Configuration;

public abstract class SessionManager {

    public static Session getSession() throws HibernateException{
        // Instancia un objeto del tipo Configuration
        Configuration config = new Configuration();

        // Registra las clases a mapear en la configuracion
        registerMappers(config);

        // Establece las propiedades de configuracion
        config.setProperties(getHibernateProperties() );

        // Retorna una sesion de trabajo
        return config.buildSessionFactory().openSession();
    }

    private static Properties getHibernateProperties(){
        // Instancia un objeto del tipo Properties.
        Properties props = new Properties();

        // Establece el driver de conexion dependiente del RDBMS.
        //para MySQL seria: props.put("hibernate.connection.driver_class", "com.mysql.jdbc.Driver");
        props.put("hibernate.connection.driver_class", "com.ibm.db2.jcc.DB2Driver");

        // Establece la url de conexion, donde al final va el nombre de la BD
        //para MySQL props.put("hibernate.connection.url", "jdbc:mysql://localhost/testHibernate");
        props.put("hibernate.connection.url", "jdbc:db2://localhost:50000/sample");

        // Establece el usuario.
        props.put("hibernate.connection.username", "db2admin");

        // Establece la clave.
        props.put("hibernate.connection.password", "db2admin");

        // Establece el dialecto a utilizar. Es necesario determinarlo ya que la implementación
        // de SQL puede variar con cada motor de base de datos.
        // Para MySQL sería: props.put("hibernate.dialect", "org.hibernate.dialect.MySQLDialect");
        props.put("hibernate.dialect", "org.hibernate.dialect.DB2Dialect");

        // Retorna las propiedades
        return props;

    }

    // Cada clase mapeada deberá aparecer aca.
    private static void registerMappers(Configuration config) throws MappingException
    {
        config.addResource("negocio/Auto.hbm.xml");
    }
}

Como verán, he configurado el SessionManager de manera programática. Obviamente lo ideal para un proyecto laboral es hacerlo con archivos de configuracion. Aca hay un ejemplo: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configuration.html

Hasta aquí hemos terminado de confgurar Hibernate. Ahora podemos comenzar a utilizarlo. Para ello, haremos la clase Auto y su correspondiente archivo xml

Y, ahora veremos el archivo auto.hbm.xml. La extensión hbm.xml es por conveción. Este archivo representa la forma de relacionar una clase con una tabla. Existirá un hbm.xml por cada clase que desee mapear. Por lo general, se acostumbra dejar el archivo xml en el mismo paquete de la clase mapeada.

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
    <class name="negocio.Auto" table="autos">
        <id name="id" column="idauto">
            <generator class="increment" />
        </id>
        <property name="marca" />
        <property name="modelo" />
    </class>
</hibernate-mapping>

Listo, ya tenemos todo para realizar las primeras pruebas. Pero antes voy a explicar que es cada cosa en el xml:

hibernate-mapping es la raíz del documento y, por ende, todos los tags quedan contenidos dentro de este tag.
El tag class es general: nombra la clase y la tabla.
El tag id representa el atributo que se relaciona con la clave primaria. Su atributo name hace referencia a como se llama el id en la clase (en nuestro caso da la casualidad que se llama id) y el atributo column representa la columna en la base de datos.
El tag property es utilizado para los atributos que no son clave primaria. Sus atributos más importantes son name y column. Si el nombre del atributo coincide con la columna, no es necesario especificar a ambos. Con especificar name es suficiente.
El tag generator esta contenido dentro de id y representa la forma de generar la clase primaria al insertar un nuevo registro. Puede tomar diversos valores pero los más comunes son:

increment: para las claves autoincrementales.
sequence: para los secuenciadores.
assign: para los casos donde la BD no generá la clave primaria, sino que el objeto es quién la determina.

A probar!

Hemos insertado un auto. Tan sencillo como eso, ejecutar el método save.

Vamos a actualizarlo: ahora lo convertiremos en C4:

Y, por último, eliminaremos el registro:

Algunas últimas aclaraciones:

No he hecho consultas mediante Hibernate porque habría que profundizar un poco más y prefiero dejarlo para más adelante.
Para actualizar un registro es necesario colocarle el id a la clase. En este caso era un Long, por lo que tuve que hacer setId(1L).
Hibernate elimina por id de manera automática. Por ello, con solo colocarle el id al objeto auto es suficiente. Para eliminaciones más complejas hay que tirar un poco más de código.

Bien, hasta aquí llego nuestro pequeño ejemplo. Cuando tenga un poco más de tiempo voy a profundizar sobre este framework.

Log4j

2011-07-26T13:51:00.002-03:00

La experiencia indica que el logging forma parte importante del desarrollo de una aplicación. Sobretodo porque nos permite conocer el estado de los objetos en un momento determinado.

Log4j es un framework de Java que se utiliza como herramienta de logging. Muchas veces utilizamos el limitado pero efectivo System.out.printl() para realizar salidas por consola o hacer seguimiento de un error. Si bien a veces con esto alcanza, la realidad es que su alcance es limitado. Hay diversas situaciones en las cuales encuestaríamos algo más completo. Se me ocurre, por ejemplo:

Quiero guardar un archivo con las salidas de la consola.
Quiero ver los mensajes con un formato determinado.
¿Que pasa en los casos donde ocurre un error en producción que no se replica en desarrollo? Llenamos de log nuestro código para poder seguirlo! Y cuando lo encontramos, tenemos que volver a sacar todas las líneas que hemos puesto por las distintas clases! Sin contar la cantidad de veces que debo realizar el deploy en producción. Por otro lado, si lleno el código de log, se llena la consola sin sentido, pero sería bueno guardar esas líneas de log por las dudas...entonces ¿No sería bueno tener diversos niveles de log y que se ejecuten las lineas de log que yo quiero con solo modificar el nivel en un archivo de configuración? Estos y otros problemas los puede arreglar Log4j.

Características de Log4j.

Es simple de usar y entender. Fue hecho en Java; es open source y fue desarrollada en Java por la Apache Software Foundation que permite a los desarrolladores de software elegir la salida y el nivel de granularidad de los mensajes o “logs” (logging) en tiempo de ejecución y no en tiempo de compilación como es comúnmente realizado. Como si fuera poco, es más rápdio que realizar un System.out.print() y le ocupa al sistema menor cantidad de recursos.
La configuración de salida y granularidad de los mensajes es realizada mediante un archivo de configuración externo. Adenás de Java, Log4J ha sido implementado en otros lenguajes como: C, C++, C#, Perl, Python, Ruby y Eiffel.
La página oficial de Log4J es http://logging.apache.org/log4j/ y desde allí debemos bajar los jars necesarios para trabajar en nuestro programa.

Configuración y uso.

Podriamos dividir en dos partes a Log4j. La primer parte consiste en configurarlo. Esto se hace una sola vez y nunca más. En el 99% de los casos no lo tendremos que hacer nosotros, pero es bueno saber como se configura por si alguna vez caemos dentro de ese 1%. La configuración por lo general reside en un archivo de propiedades llamado log4j.properties. Pero debemos tener en cuenta que se puede hacer mediante un achivo xml o programáticamente. Esta última opción no es recomendable ya que se debe tocar código y compilar de nuevo cada vez que se quiere cambiar el nivel del logging.
La segunda parte consiste en saber usarlo. Es la parte más sencilla y con sólo aprender 2 o 3 tips y ya estamos listos.
Primero veremos como se configura y al final de este post veremos como se usa. Si sólo necesitan usarlo pueden ir directamente al final donde se muestran unos ejemplos de uso.

Niveles de prioridad.

Log4j tiene tres components principales para configurar: loggers, appenders y layouts (que los veremos más adelante). Estos tres funcionan juntos para loggear de acuerdo al tipo de mensaje y formato. Cuando escribamos un mensaje para que vaya al log debemos especificar su nivel de prioridad. Por defecto Log4J tiene 6 niveles de prioridad para los mensajes (trace, debug, info, warn, error, fatal). Además existen otros dos niveles extras (all y off).
Niveles de prioridad (De mayor -poco detalle- a menor -mucho detalle-):

FATAL: se utiliza para mensajes críticos del sistema, generalmente después de guardar el mensaje el programa abortará.
ERROR: se utiliza en mensajes de error de la aplicación que se desea guardar, estos eventos afectan al programa pero lo dejan seguir funcionando, como por ejemplo que algún parámetro de configuración no es correcto y se carga el parámetro por defecto.
WARN: se utiliza para mensajes de alerta sobre eventos que se desea mantener constancia, pero que no afectan al correcto funcionamiento del programa.
INFO: se utiliza para mensajes informativos sobre el avance de la aplicación. Estimo que deb ser el más utilizado de todos los niveles.
DEBUG: se utiliza para escribir mensajes de depuración. Este nivel no debe estar activado cuando la aplicación se encuentre en producción.
TRACE: se utiliza para mostrar mensajes con un mayor nivel de detalle que debug.

Extras:

ALL: este es el nivel de máximo detalle, habilita todos los logs (en general equivale a TRACE).
OFF: este es el nivel de mínimo detalle, deshabilita todos los logs.

Por lo general, INFO y DEBUG son los utilizados.

Appenders.

En Log4J los mensajes son enviados a una (o varias) salida de destino, lo que se denomina un appender. Existen varios appenders y también podemos crear propios. Típicamente la salida de los mensajes es redirigida a un fichero de texto .log (FileAppender, RollingFileAppender), a un servidor remoto donde almacenar registros (SocketAppender), a una dirección de correo electrónico (SMTPAppender), e incluso en una base de datos (JDBCAppender). Casi nunca es utilizado en un entorno de producción la salida a la consola (ConsoleAppender) ya que perdería gran parte de la utilidad de Log4J.

No se precupen si no entienden la configuración, de a poco vamos a ver cada punto.

*Fe de erratas: donde dice No mostrará mensajes por debajo del nivel INFO debería decir No mostrará mensajes por debajo del nivel DEBUG

Los appenders se configuran en el archivo externo.Los appenders que vienen con Log4J se encuentran en el paquete org.apache.log4j. Estos son:

ConsoleAppender

Este appender despliega el log en la consola; tiene las siguientes opciones:

Threshold=WARN: Este parámetro establece que el appender no despliega ningún mensaje con prioridad menor a la especificada aquí.
ImmediateFlush=true: El valor por defecto es true, esto quiere decir que los mensajes de log no son almacenados en un buffer, sino que son enviados directamente al destino.
Target=System.err: El valor por defecto es System.out. Establece la salida del sistema a ser utilizada.

FileAppender

Este appender redirecciona los mensajes de logs hacia un archivo.

Threshold=WARN: Este parámetro establece que el appender no despliega ningún mensaje con prioridad menor a la especificada aquí.
ImmediateFlush=true: El valor por defecto es true, esto quiere decir que los mensajes de log no son almacenadosen un buffer, sino que son enviados directamente al destino.
File=mylog.txt: Nombre del archivo donde se almacenará el log. Se puede utilizar el nombre de algún property (${nombre_de_la_propiedad}) para especificar el nombre o la ubicación del archivo.
Append=false: El valor por defecto es true, para que los nuevos mensajes de logs se adicionen al archivo existente.
Si se especifica false, cuando se inicie la aplicación el archivo de log se sobreescribirá.

RollingFileAppender

Este appender redirecciona los mensajes de logs hacia un archivo y permite definir politicas de rotación para que el archivo no crezca indefinidamente.

Threshold=WARN: Este parámetro establece que el appender no despliega ningún mensaje con prioridad menor a la especificada aquí.
ImmediateFlush=true: El valor por defecto es true, esto quiere decir que los mensajes de log no son almacenados en un buffer, sino que son enviados directamente al destino.
File=mylog.txt: Nombre del archivo donde se almacenará el log. Se puede utilizar el nombre de algún property (${nombre_de_la_propiedad}) para especificar el nombre o la ubicación del archivo.
Append=false: El valor por defecto es true, para que los nuevos mensajes de logs se adicionen al archivo existente. Si se especifica false, cuando se inicie la aplicación el archivo de log se sobreescribirá.
MaxFileSize=100KB: Los sufijos pueden ser KB, MB o GB. Rota el archivo de log cuando alcanza el tamaño especificado.
MaxBackupIndex=2: Mantiene un máximo de 2 (por ejemplo) archivos de respaldo. Borra los archivos anteriores.Si se especifica 0 no se mantiene respaldos.

DailyRollingFileAppender

Este appender redirecciona los mensajes de logs hacia un archivo y permite definir politicas de rotación basados en fechas.

Threshold=WARN: Este parámetro establece que el appender no despliega ningún mensaje con prioridad menor a la especificada aquí.
ImmediateFlush=true: El valor por defecto es true, esto quiere decir que los mensajes de log no son almacenados en un buffer, sino que son enviados directamente al destino.
File=mylog.txt: Nombre del archivo donde se almacenará el log. Se puede utilizar el nombre de algún property (${nombre_del_property}) para especificar el nombre o la ubicación del archivo.
Append=false: El valor por defecto es true, para que los nuevos mensajes de logs se adicionen al archivo existente.Si se especifica false, cuando se inicie la aplicación el archivo de log se sobreescribirá.
DatePattern='.'yyyy-ww: Rota el archivo cada semana Se puede especificar que la frecuencia de rotación sea mensual, semanal, diaria, 2 veces al día, cada hora o cada minuto. Este valor no solo especifica la frecuencia de rotación sino el sufijo del archivo de respaldo. Algunos ejemplos de frecuencia de rotación son:

'.'yyyy-MM: Rota el archivo el primero de cada mes
'.'yyyy-ww: Rota el archivo al inicio de cada semana
'.'yyyy-MM-dd: Rota el archivo a la media noche todos los días
'.'yyyy-MM-dd-a: Rota el archivo a la media noche y al media día, todos los días
'.'yyyy-MM-dd-HH: Rota el archivo al inicio de cada hora
'.'yyyy-MM-dd-HH-mm: Rota el archivo al inicio de cada minuto

SocketAppender

Redirecciona los mensajes de logs hacia un servidor remoto de log.

El mensaje de log se almacenará en el servidor remoto sin sufrir alteraciones en los datos (como fecha, tiempo desde que se inicio la aplicación, NDC), exactamente como si hubiese sido guardado localmente.

El SocketAppender no utiliza Layout. Únicamente serializa el objeto LoggingEvent para enviarlo.
Utiliza TCP/IP, consecuentemente si el servidor es accesible el mensaje eventualemente arribará al servidor. Si el servidor remoto está abajo, la petición de log será simplemente rota. Cuando el servidor vuelva a estar disponible la transmisión se reasume transparentemente.Esta reconexión transparente es realizada por un connector thread que periodicamente revisa si existe conexión con el servidor.

Los eventos de logging son automaticamente almacenados en memoria por la implementación nativa de TCP/IP. Esto quiere decir que si la conexión hacia el servidor de logs es lenta y la conexión con los clientes es rápida, los clientes no se ven afectados por la lentitud de la red.

El SocketAppender tiene las siguientes propiedades:

Threshold=WARN: Este parámetro establece que el appender no despliega ningún mensaje con prioridad menor a la especificada aquí.
ImmediateFlush=true: El valor por defecto es true, esto quiere decir que los mensajes de log no son almacenados en un buffer, sino que son enviados directamente al destino.
port=6548: Especifica el puerto por el que se va a comunicar al servidor de logs.
remoteHost=192.168.10.225: Especifica la máquina donde se encuentra el servidor de logs.
reconnectionDelay=300: El valor por defecto es de 30000 milisegundos, que corresponden a 30 segundos. Es un valor entero que corresponde al número de milisegundos que va a esperar para volver a intentar conectarse con el servidor cuando se ha perdido comunicación con este.

SMTPAppender

Envia un mail con los mensajes de logs, típicamente se utiliza para los niveles ERROR y FATAL.

El número de eventos de log enviados en el mail depende del valor de BufferSize. El SMTPAppender mantiene únicamente el último BifferSize en un buffer cíclico.

Threshold=WARN: Este parámetro establece que el appender no despliega ningún mensaje con prioridad menor a la especificada aquí.
ImmediateFlush=true: El valor por defecto es true, esto quiere decir que los mensajes de log no son almacenados en un buffer, sino que son enviados directamente al destino.
To=direccion1@dominio.com: Especifica la dirección de correo a donde se enviará el mail.
From=direccion2@dominio.com: Especifica la dirección de correo desde donde se envia el mail.
SMTPHost=mail.dominio.com: Especifica el servidor de SMTP que se va a utilizar para enviar el mail.
Subject=Mensajes de Logs: Especifica el asunto del mail.
LocationInfo=true: El valor por defecto es false. Envía información acerca de la ubicación donde se generó el evento de log.
BufferSize=20: El valor por defecto es 512. Representa el número máximo de eventos de logs que serán recolectados antes de enviar el mail.

JDBCAppender

Este appender redirecciona los mensajes de log hacia una base de datos.

Threshold=WARN: Este parámetro establece que el appender no despliega ningún mensaje con prioridad menor a la especificada aquí.
ImmediateFlush=true: El valor por defecto es true, esto quiere decir que los mensajes de log no son almacenados en un buffer, sino que son enviados directamente al destino.
Driver=mm.mysql.Driver: Define el driver a ser utilizado, asegurese de tener la clase en el CLASSPATH.
URL=jdbc:mysql://localhost/LOG4JDemo: Es la cadena de conexión que se utilizará.
ser=default: El usuario de la base de datos.
password=default: La clave para poder ingresar a la base de datos.
sql=INSERT INTO TABLA (Message) VALUES ('%d - %c - %p - %m'): La instrucción SQL que se utiliza para grabar el mensaje en la base de datos. Si se desea se puede guardar cada valor en columnas separadas,por ejemplo: INSERT INTO JDBCTEST (Date, Logger, Priority, Message) VALUES ('%d', '%c', '%p', '%m').

Otros appeders:
SyslogAppender: redirecciona los mensajes de logs sistemas operativos Unix.

NTEventLogAppender: redirecciona los mensajes de logs hacia los logs del sistema de NT.

JMSAppender: serializa los eventos y los transmite como un mensaje JMS tipo ObjectMessage.

Layouts

Es el responsable de dar un formato de presentación a los mensajes. Permite presentar el mensaje con el formato necesario para almacenarlo simplemente en un archivo de texto .log (SimpleLayout y PatternLayout), en una tabla HTML (HTMLLayout), o en un archivo XML (XMLLayout).
Además podemos añadir información extra al mensaje, como la fecha en que se generó, la clase que lo generó, el nivel que posee, etc. Inclusive se pueden crear layouts propios. Basta con heredar de la clase org.apache.log4j.Layout.
Los layouts que vienen con el PI son: DateLayout, HTMLLayout, PatternLayout, SimpleLayout, XMLLayout.
SimpleLayout, como lo indica su nombre, es algo simple: nivel de prioridad, un "-" y el mensaje en cuestión. Por ejemplo: INFO - Hola Mundo!
El más utilizado es PatternLayout ya que permite darnos la libertad de utilizar la creatividad para crear el formato de los mensajes. Para ello, debemos aprender algunos patrones:

%m: muestra el mensaje.
%p: muestra el nivel de prioridad.
%r: muestra los milisegundos desde que comenzo la aplicación hasta el evento que se logueó.
%t: muestra el nombre del thread que loguel el evento.
%x: muestra el NDC del thread que loguel el evento.
%n: deja un renglón, con lo cual nos olvidamos de "\n" o "\r\n".
%c: categoría del evento que figura en la configuración.
%%: muestra un signo de porcentaje.
%d: muestra la fecha del vento, que se le puede dar un formato determinado, por ejemplo %d{HH:mm:ss,SSS} o %d{dd MMM yyyy HH:mm:ss,SSS}.
%C: muestra el nombre de la clase que logueo el evento.
%M: muestra el método de la clase que logueo el evento.
%L: muestra el número de línea donde se logueo el evento.

Obviamente utilizar la fecha (el %d) hace el logueo más pesado.

Opcionalmete, se puede especificar los márgenes de cada uno:

Se utiliza el signo menos (-), seguido de un entero para el margen izquierdo.
Se utiliza un entero para el margen derecho.
Se utiliza un punto (.) con un entero para el ancho mínimo.

Ejemplos:
%20p: espacios que tenrá a la derecha el nivel de prioridad.
%-20p: espacios que tenrá a la izquierda el nivel de prioridad.

Configuración del entorno.

El entorno log4j es completamente configurable programaticamente. Sin embargo, es mucho más flexible configurar log4j usando archivos de configuración . Estos archivos pueden estar escritos en XML o en Java properties (formato key=value).

Veamos un ejemplo, con un archivo properties donde se colocan dos appenders: uno para realizar una salida por consola y otro para que guarde un archivo. Por otro lado, cada appender tiene un nivel de prioridad distinto.

log4j.rootCategory= miArchivo, miConsola
# Indica alias para las salidas de log, podemos tener varias

log4j.appender.miArchivo=org.apache.log4j.FileAppender
# Appender miArchivo (lugar donde se envian los mensajes) es un archivo

log4j.appender.miArchivo.Threshold=INFO
# No mostrará mensajes por debajo del nivel INFO

log4j.appender.miArchivo.ImmediateFlush=true
# Se vuelca el mensaje inmediatamente en el appender

log4j.appender.miArchivo.file=C:/Users/Admin/Documents/Java/logFile.log
# Archivo (appender)

log4j.appender.miArchivo.layout=org.apache.log4j.PatternLayout
# Tipo de diseño de los mensajes

log4j.appender.miArchivo.layout.ConversionPattern=%d %-5p %C.%M(%L)===> %m%n
# Diseño

log4j.appender.miArchivo.append=false
# No añade, borra el contenido anterior

log4j.appender.miConsola=org.apache.log4j.ConsoleAppender
# Appender de miConsola

log4j.appender.miConsola.Threshold=DEBUG
# No mostrará mensajes por debajo del nivel INFO

log4j.appender.miConsola.layout=org.apache.log4j.PatternLayout
# miConsola utiliza PatternLayout

log4j.appender.miConsola.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n
# Diseño

Como se puede observar en el ejemplo, usarlo es muy sencillo, basta con decirle a Log4j que nuestra clase quiere guardar log mediante la sentencia Logger.getLogger(Clase.class) y listo. Con eso es suficiente para utilizarlo. Si prestan atención cuando se loguea un mensaje, se coloca el nivel de prioridad.
Veremos como quedó el archivo que grabó el log con un nivel de prioridad distinto al de la consola:

Spring Core

2011-07-14T00:47:00.003-03:00

Continuando con el post anterior de introducción a Spring, que se puede ver en http://migranitodejava.blogspot.com/2011/06/introduccion-spring.html, vamos a profundizar algunos temas.

Creando Beans.

En Spring hay diversas formas de crear un bean. En el ejemplo de la introducción a Spring vimos una opción donde colocábamos la ruta del xml de configuración:
ApplicationContext respuesta =
new FileSystemXmlApplicationContext("C:/Users/max/eclipse workspace/spring.xml");

Esta forma de crear beans esta bien para un ejemplo o aplicaciones muy chicas, pero es poco práctico para el resto de los casos. Spring nos brinda formas alternativas a FileSystemXmlApplicationContext y las más utilizadas son:
ClassPathXmlApplicationContext: busca el xml en el classpath, para mi gusto es la mejor opción.
XmlWebApplicationContext: el xml se encuentra en un contexto de una aplicación web.

Ciclo de vida de un bean.

En Spring la vida de un objeto difiere de la forma tradicional: existen más oportunidades para aprovechar en la creación o destrucción de un bean. Las distintas etapas son:

Instanciación del bean.
Inyección de propiedades.
Nombre del bean: si el bean implementa BeanNameAware, Spring le pasa el id en el método setBeanName(). De esta forma, sabe cual es su id según el xml de Spring.
Contexto: si el bean implementa ApplicationContextAware, Spring llama al método setApplicationContext() y le pasa el contexto como parámetro.
Post proccessor: si hay un BeanPostProccessor, Spring llama al método postProccessBeforeInitialization().
Inicializar bean: si implementa InitializingBean, se llama a afterPropertiesSet().
Post proccessor (de nuevo!): si hay un BeanPostProccessor, Spring también llama al método postProccessAfterInitialization().
El bean esta listo para ser utilizado!
Destrucción del bean: si implmenta DisposableBean se llama a destroy().

Y agregamos lo siguiente al xml:

</bean>

Inyección por constructores.

Es posible instanciar objetos con un constructor distinto al vacío. Para ello existe un tag llamado <constructor-arg> que posee dos atributos importantes: ref y value. Por ejemplo, si tenemos un constructor que recibe un int podriamos hacer lo siguiente:
<constructor-arg value=”100” />
Pero si se recibe un objeto compuesto se deberá usar el atributo ref que hace referencia a otro bean de Spring y se lo llama por su id:
<constructor-arg ref=”persona” />

Veamos un ejemplo:

Y el xml:

<constructor-arg value="100" />

<constructor-arg value="Perez" />

</bean>

Entonces …¿conviene inyectar por constructor o por setter?

Es muy útil la inyección por constructor por varios motivos. Primero, a diferencia de la mayoría de frameworks que nos obligan a que casi todas nuestras clases sean pojos (y por lo tanto usen el constructor vacío), aquí esto no supone un problema y es Spring quien se adapta y nos da la libertad de trabajar como queremos. Por otro lado, obligamos a que, cuando se crea un objeto, se lo haga de la forma adecuada (con todas sus dependencias creadas si o si).
Por otro lado, inyectar por constructor puede hacer engorrosa la herencia y si el bean tiene muchas dependencias se vuelve cada vez más complicado.
Particularmente prefiero inyectar por setter, pero es bueno tener ambas posibilidades.

Inyectar beans exclusivos.

Hay situaciones donde un bean debería ser una dependencia de otro de manera exclusiva. El problema del archivo xml de Spring es que una vez declarado, el bean puede ser dependencia de cualquiera. Por ejemplo:

<constructor-arg value="3" />

<constructor-arg value="Juarez" />

</bean>

</bean>

Hasta aquí nada sobresaliente, simplemente hemos agregado a la clase Persona un objeto Documento y lo hemos vinculado para que funcionen en conjunto.

Pero hay un pequeño problema. ¿Que pasa si agregamos lo siguiente en el xml?

<constructor-arg value="30" />

<constructor-arg value="Gonzalez" />

</bean>

Leo esta usando el documento de Liz!! Eso no es correcto y, por ello, Spring permite crear beans exclusivos de la siguiente manera:

<constructor-arg value="3" />

<constructor-arg value="Juarez" />

</bean>

</property>

</bean>

Observamos que Spring permite definir un bean dentro de una propiedad que no lleva el atributo id y, por lo tanto, no es posible referenciarlo de ninguna manera.
Hay que tener mucho cuidado al crear objetos de este tipo ya que estaremos impidiendo la reutilización del código.

Scope de un bean.

Por defecto, todos los beans de Spring son Singletons. Si no se conoce dicho patrón se puede leer en http://migranitodejava.blogspot.com/2011/05/singleton.html
Spring sólo crea una única instancia de cada objeto en su contenedor y luego la reutiliza. Todos sabemos que en ciertos casos esto no es conveniente, por lo que nos da la opción de cambiarlo. Para ello, en la etiqueta bean hay un atributo llamado scope que puede tomar los siguientes valores:

Singleton: es el valor default e implica una única instancia.
prototype: se instancia todas las veces que sea necesario.
request: válido en Spring MVC, donde es instanciado por cada petición HTTP.
session: válido en Spring MVC, donde es instanciado por cada usuario.
global-session: válido en Spring MVC, donde es instanciado en una session global HTTP.

Ojo si usan una versión anterior a Spring 2 que esto se trata de manera diferente.

Como se habrán dado cuenta, este singleton de Spring tiene una particularidad: no es realmente un Singleton. Es decir, Spring nos asegura que nos devolverá una única instancia pero nada impide que haga un new Object().
Muchas veces nosotros necesitamos controlar el Singleton para evitar problemas. Para ello Spring nos brinda una solución:

Y en el xml definimos cual es el método encargado de crear el bean:

De esta forma, es posible adaptar a Spring para que instancie los objetos como nosotros le digamos. Este ya si es un Singleton propiamente dicho.

Autoconexión.

Vimos que es posible conectar las propiedades mediante un constructor o los métodos setters. Hasta aquí se hizo de manera explícita en el archivo xml. Pero se puede hacer que Spring resuelva esto por nosotros mediante el atributo autowire de cada bean. Hay 4 tipos de autoconexión:

byName: es la más común, ya que conecta por ID (ver el ejemplo). Si no se encuentra un bean correspondiente la propiedad queda sin conectar.
byType: busca un único bean en el contenedor cuyo tipo sea correspondiente con la propiedad a conectar. Si no se encuentra no conecta, pero si encuentra más de una lanza una UnsatisfiedDependenciException.
constructor: busca uno o más beans del contenedor que correspondan con los parámetros del constructor del bean a conectar. Si no puede resolverlo lanza una UnsatisfiedDependenciException.
autodetect: intenta primero conectar por constructor y luego byType.

Y en el xml:

<constructor-arg value="100" />

<constructor-arg value="Perez" />

</bean>

</bean>

Autoconexión por defecto.

Por defecto, los beans no se conectan. Pero esto se puede cambiar en la etiqueta beans:

...

</beans>
De esta forma, le estamos diciendo a Spring que conecte por byName por defecto, lo que se puede sobreescribir en cualquier etiqueta bean.

Colecciones.

Voy a asumir que ya todos conocen el concepto de List, Set, Map y las colecciones más importantes de Java, como por ejemplo Properties. Así que iré directamente a un ejemplo integrador donde se mostrará como configurar Spring para cada tipo de colección. De todas maneras, es muy intuitivo entenderlo.

List, set y arrays funcionan de manera similar. Cuando son array o list simplemente debo confgurar el xml de la siguiente manera (si son sets, solo hay que cambiar <list> por <set>):

<ref="telefono1">

<ref="telefono2">

<ref="telefono3">

</list>

</property>

</bean>

Y un Map sería:

<map>

</map>

Tanto en la clave como en el valor es posible referenciar a otros beans en lugar de poner Strings. Para ello, en vez de key debemos colocar key-ref donde haremos referencia hacia el id de otro bean. Lo mismo ocurre en el valor: en vez de value debemos colocar value-ref.

En cuanto a los properties (clase java.util.Properties) se hace de la siguiente manera:

<props>

<prop key="clave1" >valor1</prop>

<prop key="clave2">valor2</prop>

</props>

Herencia entre beans.

Es posible utilizar herencia dentro de los beans declarados en el xml de Spring, lo cual nos puede permitir que nuestro archivo se reduzca en cuanto a la cantidad de líneas que tenemos que escribir. Para ello, el tag bean posee 2 atributos que, hasta ahora, no hemos utilizado. Estos son:

parent: indica quien es el padre (como un extends).
abstract: indica si es un bean abstracto que me sirve solo como modelo pero que nunca se va a instanciar. Toma valores true o false.

Por ejemplo, supongamos que en una empresa los empleados tienen, en su gran mayoría, el mismo domicilio y telefono laboral. Solo cambiar su interno.

Luego, cada vez que quiera crear un empleado solo debo hacer lo siguiente:

Si un empleado no tiene, por ejemplo, ese domicilio laboral, entonces se lo puede sobreescribir:

</bean>

Y el xml era así:

</bean>

</bean>

Ahora vamos a hacer un pequeño cambio en el xml y lo vamos a dejar así:

Y realizamos la implementación SaludoAlternativo:

Como se imaginarán hemos cambiado el "Hola mundo" por algo más actual. =)

2) Sustitución por getter: permite que los métodos sean sustituidos en tiempo de ejecución con nuevas implementaciones. En realidad es un caso especial de la sustitución anterior. Se suele utilizar en casos de métodos abstractos, aunque no es obligatorio.

Vamos a porner un ejemplo sencillo. Imaginemos que una clase llamada Reloj posee el siguiente método:

public abstract Tiempo getTiempo();

En el xml se podría escribir:

<lookup-method name="getTiempo" bean="tiempoImpl"/>

</bean>

De esta forma se sustituye lo que devuelve el método por la implementación de tiempoImpl. En la practica la sustitución por método no se suele utilizar demasiado ya que no son demasiados los casos donde se puede aplicar (¿para que voy a hacer un método que despues lo voy a cambiar no?), pero es bueno saber que existe.

Estas son las características principales del Core de Spring. Cuando tenga tiempo y ganas escribiré un post sobre Spring AOP.

Introducción a Spring

2011-06-28T18:36:00.001-03:00

Primero voy a dar una introducción a Spring para quienes no conozcan el framework, donde veremos de que se trata, como configurarlo y un sencillo "Hola Mundo". Luego escribiré un post sobre Spring Core que permitirá conocer el framework de manera más amplia.

Spring es un marco de trabajo cuya finalidad es facilitar el desarrollo de aplicaciones con Java. Fue creado por Rod Johnson y es de código abierto.
Sus características son:

Simplicidad y acoplamiento débil: da la sensación que quién desarrollo Spring se imagino a Java de otra manera, más robusto y configurable, con más facilidadades y posibilidades para los desarrolladores. Esto se ve reflejado en este framework: busca ser simple y se basa en la inyección de dependencias para obtener un acoplamiento débil. Luego veremos estos dos conceptos.
Es un contenedor: no es solo un framewrok más. Es un contenedor que gestiona el ciclo de vida de los objetos y como se relacionan entre ellos. Proporciona una gran infraestructura que permite que el desarrollador se dedique a la lógica de la aplicación.
Ligero: es muy rápido en tiempo de procesamiento y no es intrusivo a la hora de desarrollar. Esto último es uno de sus puntos más fuertes.
Orientado a aspectos: soporta la programación orientada a aspectos, lo que permite facilitar una capa de servicios que son ideales para este tipo de programación como auditoría, o gestión de transacciones.

Módulos de Spring

Spring posee diversos módulos que se pueden agregar a las aplicaciones Java. Cada desarrollador agrega los módulos que necesite. Spring Core es el núcleo de Spring, es el único módulo que tenemos que agregar para que Spring funcione. ya que contiene la DI (inyección de dependencias) y la configuración y uso de objetos Java. Muchas aplicaciones sólo necesitan de Spring Core sin necesidad de agregar módulos adicionales.

Otros módulos conocidos son: AOP para trabajar con aspectos, DAO para trabajar con base de datos, MVC para la capa web, Portlet MVC para trabajar con portlets, JMS para mensajería y Security para el manejo de seguridad (el framewrok de seguridad era antes conocido como Acegi).
Como se puede observar Spring nos da muchas opciones para poder agregar a nuestro proyecto. Estos no son los únicos módulos que nos ofrece Spring, sólo son los más importantes.

Inyección de dependencias (DI).

Originalmente la inyección de dependencias se llamaba inversión de control, pero en el 2004 Martin Fowler llegó a la conclusión que realmente no se invertía el control, sino las dependencias.
La DI permite a un objeto que conozca sus dependencias mediante una interfaz y no por su implementación. De esta forma, la implementación puede variar sin que el objeto dependiente se de cuenta. La gran ventaja de la DI es el acoplamiento débil entre objetos.
Muy linda la teoría pero si uno se inicia en Spring por primera vez suena a conceptos muy abstractos. Nada mejor que un ejemplo sencillo para aclarar los puntos. Veremos un pequeño ejemplo antes de introducirnos en Spring Core, pero antes veremos como configurar Spring en una aplicación eclipse:

1) Bajar Spring desde http://www.springsource.org/download y agregar las fuentes al proyecto.
2) Si la distribución de Spring no adjunta las librerías de apache commons también hay que bajarlas: http://commons.apache.org/
Adjunto un pic con las librerias necesarias para empezar (ignoren el archivo spring.xml por ahora):

3) Dentro de las librerías habrán visto que hay un archivo llamado spring.xml (le pueden poner el nombre que quieran, es lo mismo).
Por ahora les recomiendo que hagan un archivo xml que tenga el siguiente contenido y lo agreguen al classpath. Luego les explicaré que significa cada cosa de dicho archivo.

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

</bean>

</bean>

</beans>

4) Por último, vamos a hacer una clase que nos permita levantar el archivo:

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;

public class ContextFactory {

    private static ApplicationContext respuesta;


    public static ApplicationContext getInstance(){
        if (respuesta != null) {
            return respuesta;
        }
        respuesta = new FileSystemXmlApplicationContext
        ("C:/Users/max/eclipse workspace/spring.xml"); // aca pongan la ruta donde pusieron el xml
        return respuesta;
    }

Listo, con esto tenemos todo para comenzar con nuestro ejemplo.
Crearemos una clase Alumno que tiene un atributo de la clase (intefaz) Saludo.

Aquí una posible implementación de la clase Saludo:

Veamos como se ejecuta esto:

¿Que ha pasado aquí?

A simple vista deduciremos lo siguiente: la clase Alumno posee un atributo que es una interfaz y no se entera como es la implementación de la misma.
Vamos a explicar el funcionamiento: todo se debe gracias al archivo de configuración xml. El tag <beans> es el elemento raíz del xml y todo lo que se encuentre dentro de este elemento es configuración de Spring.
El elemento <bean> indica a Spring que se configurará un objeto para ser utilizado en el contenedor de Spring. Id es un atributo obligatorio que debería identificar unívocamente al bean en cuestión.
En nuestro ejemplo vemos la siguiente configuración:

</bean>

El atributo class indica la clase a la cual pertenece el bean y cada bean puede tener subelementos <property> que representan los atributos (en este caso me refiero a atributos de objetos y no de xml) del bean. El name debe coincidir con el nombre de atributo que tenga en la clase y, en este ejemplo, value sería el valor que toma. Veremos luego que hay varias opciones más.
Continuando con el xml vemos:

</bean>

La novedad aca aplica a atributo ref del elemento property: esta indicando que este atributo es un objeto y, por lo tanto, es conveniente configurar dicho objeto de manera separa y se hace referencia al mismo mediante su id.

¿Y no es lo mismo hacerlo así?

Si y no a la vez: tradicionalmente cada objeto es responsable de obtener sus propias dependencias y esto lleva a un código muy acoplado. Cada objeto debe conocer como se construyen otros y si bien los patrones creacionales pueden ayudar con este tema, entonces hay que conocer que patrón se aplicó a cada objeto.
Cuando se aplica la DI se otorgan las dependencias a cada objeto, se obtiene un acoplamiento débil: si un obejto solo conoce sus dependencias mediante su interfaz, entonces puede variar su implementación sin que el objeto dependiente sepa la diferencia. Por otro lado, el código es más limpio y ordenado.

Hasta aquí con esta breve introducción a Spring. Cuando escriba sobre Spring Core se verán estos temas con más profuncidad.

Cassandra

2011-06-23T00:46:00.000-03:00

Junto a Guillermo Kessler hemos hecho una investigación sobre una base de datos NO SQL llamada Cassandra. Primero veremos sus características principales y luego les mostraremos el código fuente utilizado.

Cassandra es una Base de Datos NO SQL. Posee una estructura par-valor para almacenar datos de manera escalable, consistente y distribuída. Fue creada para manejar grandes volúmenes de datos distribuidos en numerosos servidores estándar, ofreciendo alta disponibilidad.
La historia de Cassandra nace directamente de la experiencia que supuso Dynamo para Amazon. Facebook contrató a uno de sus autores y le encargó diseñar un nuevo sistema para sus datos. Este ingeniero desarrolló Cassandra y, en 2008, Facebook liberó su código.

Características

Punto de falla: maneja grandes volúmenes de datos distribuidos en numerosos servidores estándar, ofreciendo alta disponibilidad sin ningún punto único de falla.
Basada en clave-valor: tiene un almacén de valores de claves manejado con consistencia eventual (modelo de consistencia usado en programación paralela). Las claves mapean hacia múltiples valores que se agrupan en familias de columnas. Esas familias se definen cuando se crea una base Cassandra, pero luego se les puede agregar columnas a las diferentes familias. Las columnas se pueden agregar a claves específicas y así diferentes claves tendrán diferentes cantidades de columnas dentro de una misma familia. Los valores de una familia de columnas para cada clave se almacenan juntos, haciendo de Cassandra un híbrido entre una DBMS orientada a columnas y un almacén de datos orientado a filas.
Soporte comercial: debido a que es un producto relativamente nuevo, recién acaba de aparecer una primer empresa ofreciendo soporte comercial para Cassandra. Se trata de Riptano (http://www.riptano.com/), que además está creando herramientas para usar sobre el core de Cassandra. El plan de Riptano consiste en usar a Cassandra como plataforma central e ir agregándole porciones propietarias que hagan a su versión comercial. Uno de sus primeros servicios podría ser el de migración para que usuarios de otras bases de datos puedan pasar su información a Cassandra.
Releases: Apache se encarga de sacar un nuevo release cada tres o 4 meses. Hoy esta en su versión 0.6 y ya esta trabajando en su versión 0.7.

Clientes

Un cliente es una API que nos permite conectar y realizar operaciones contra Cassandra. Esta última usa como cliente por defecto Thrift que es un cliente de bajo nivel. Al ser un cliente de bajo nivel resulta más complejo y lento operar contra esta base de datos.
Existen clientes de alto nivel para diferentes lenguajes como Java, PHP, Perl, etc. Un cliente de alto nivel nos va a permitir operar mas fácil y rápido contra la base de datos, facilitandonos las cosas. En la documentación oficial de Cassandra se recomienda el uso de estos clientes de alto nivel por encima de Thrift.

Los clientes de alto nivel recomendados para Java en la última versión estable de Cassandra (0.6.7) son:

Hector: http://github.com/rantav/hector
Pelops: http://code.google.com/p/pelops/
HelenaORM: http://github.com/marcust/HelenaORM (ORM layer built on Hector)
OCM: http://github.com/charliem/OCM (higher level client built on Hector)
Datanucleus-Cassandra plug-in: http://github.com/PedroGomes/datanucleus-cassandra (Persistence of objects through the JDO/JPA APIs under the Datanucleus platform).
Jassandra: http://code.google.com/p/jassandra/
Kundera: http://code.google.com/p/kundera/

Lamentablemente la mayoría de estos clientes tiene documentación escasa y poco mantenimiento.
Dentro de los nombrados en la lista, el más robusto es Hector. Si bien es sencillo de usar comparado con Thift, su documentación no es del todo completa y se debe tener cuidado que en cada versión de Cassandra se usan librerias diferentes de Hector, por lo cual se debe tener la versión correspondiente de Hector con la de Cassandra.

Ventajas

Dispone de consistencia eventual, al igual que el sistema Dynamo de Amazon.
Proporciona un modelo de datos basados en ColumnFamily, más rico que el tradicional modelo de clave/valor, al igual que el modelo BigTable de Google.
Es altamente escalable y distribuida. Normalmente se ejecutan en clusters de servidores formados por ordenadores baratos, por lo que la expansión del sistema es realmente sencilla.
Es rápida ya que elimina el cuello de botella que supone el tener que traducir las consultas a lenguaje SQL.

Pruebas

Hemos realizado dos tipos de pruebas: en modo local y en modo distribuído. En ambos casos se ha observado una gran velocidad en la lectura/escritura de datos. Un ejemplo claro, es que con una configuración local ha podido traer a memoria 50.000 objetos repetidos de un total de 800.000 en sólo 3.08 segundos. La configuración y el código de esta prueba se encuentra al final de este post.
No hemos observado problema con la integración de varios nodos para trabajar conjuntamente en red: hemos probado 3 máquinas trabajando juntas sin mayores problemas.

Es obvio que la velocidad es el fuerte de Cassandra, es por eso que es utilizada por empresas que tienen que manejar un gran volumen de datos.

Conclusión

Observando a las compañías que manejan un enorme volúmen de datos, tales como Google, Amazon o Facebook, nos damos cuenta que sus sistemas de datos no están basados en bases de datos tradicionales (relacionales). Google utiliza BigTable, Amazon usa Dynamo, y Facebook y Digg gestionan sus datos con Cassandra. Actualmente, Twitter1 también esta migrando sus datos a esta tecnología.
¿Por qué las compañías más relevantes del mundo de la tecnología abandonan las bases de datos relacionales? Principalmente, porque son muy costosas y lentas cuando manejan tal cantidad de datos. Por ejemplo, Cassandra es capaz de escribir en disco 50GB de datos en tan sólo 0.12 milisegundos, 2500 veces más rápido que MySQL.
Entonces, ¿todas las compañias seguirán estos pasos en un futuro? No, estas bases de datos deben utilizarse en casos especiales, cuando la información debe ser accedida por millones de personas y la velocidad es un tema primordial.
Para una compañía que no posee estas características hay varios puntos a tener en cuenta: no soporta trasacciones ya que tiene un almacén de valores de claves manejado con consistencia eventual, lo que quiere decir que los datos “eventualmente” se van a ver, pero no siempre reflejan la realidad. Por otro lado, no se tiene todas las ventajas conocidas de las base de datos relacionales como DB2 u Oracle, que van desde el soporte técnico hasta la facilidad para obtener información mediante reportes. Por último, la documentación es escasa y pobre.
Dicho de otra manera, si no tenes una red social o algo que se le parezca ni se te ocurra complicarte sin sentido!!!!

Detalle de las pruebas:

Adjuntamos la configuración/código utilizado:
storage-conf.xml

<Keyspace Name="CDT">

       


       <ColumnFamily Name="Proyectos" CompareWith="BytesType"/>


       <ColumnFamily Name="Desarrolladores" CompareWith="BytesType"/>

         

       <ColumnFamily CompareWith="TimeUUIDType" ColumnType="Super"

   CompareSubcolumnsWith="BytesType" Name="Trabajan"/>



       <ReplicaPlacementStrategy>org.apache.cassandra.locator.RackUnawareStrategy</ReplicaPlacementStrategy>

     

     <ReplicationFactor>1</ReplicationFactor>

     <EndPointSnitch>org.apache.cassandra.locator.EndPointSnitch</EndPointSnitch>

    </Keyspace>

</Keyspaces>

package main;

import java.util.ArrayList;
import java.util.Date;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.io.UnsupportedEncodingException;
import org.apache.thrift.transport.TTransport;
import org.apache.thrift.transport.TSocket;
import org.apache.thrift.protocol.TProtocol;
import org.apache.thrift.protocol.TBinaryProtocol;
import org.apache.thrift.TException;
import org.apache.cassandra.thrift.Cassandra;
import org.apache.cassandra.thrift.Column;
import org.apache.cassandra.thrift.ColumnOrSuperColumn;
import org.apache.cassandra.thrift.ColumnParent;
import org.apache.cassandra.thrift.ColumnPath;
import org.apache.cassandra.thrift.ConsistencyLevel;
import org.apache.cassandra.thrift.InvalidRequestException;
import org.apache.cassandra.thrift.Mutation;
import org.apache.cassandra.thrift.NotFoundException;
import org.apache.cassandra.thrift.SlicePredicate;
import org.apache.cassandra.thrift.SliceRange;
import org.apache.cassandra.thrift.SuperColumn;
import org.apache.cassandra.thrift.TimedOutException;
import org.apache.cassandra.thrift.UnavailableException;
import org.safehaus.uuid.UUID;
import org.safehaus.uuid.UUIDGenerator;

public class TestCassandra {

    public static final String UTF8 = "UTF8";

    public static final String KEYSPACE = "CDT";
    public static final String PROYECTOS_FAMILY = "Proyectos";
    public static final String DESA_FAMILY = "Desarrolladores";
    public static final String TRABAJAN_FAMILY = "Trabajan";

    public static void test(long cantidad, boolean abrirTr) throws Exception {
        long inicio, intermedio, fin = 0;

        TTransport tr = new TSocket("localhost", 9160);
        TProtocol proto = new TBinaryProtocol(tr);
        Cassandra.Client client = new Cassandra.Client(proto);
        if (abrirTr) {
            System.out.println("Comienzo la insercion");
            inicio = new Date().getTime();
            for (int i = 0; i < cantidad; i++) {
                tr.open();
                inserting(client, i);
                tr.close();
            }
            System.out.println("Fin inserción");
            intermedio = new Date().getTime();
            System.out.println("Comienzo la lectura");

            for (int i = 0; i < cantidad; i++) {
                tr.open();
                reading(client, i);
                tr.close();
            }
            fin = new Date().getTime();

        } else {

            tr.open();
            inicio = new Date().getTime();
            System.out.println("Comienzo la inserción");
            for (int i = 0; i < cantidad; i++) {

                inserting(client, i);

            }
            tr.close();

            System.out.println("Fin inserción");
            intermedio = new Date().getTime();
            System.out.println("Comienzo la lectura");
            tr.open();
            for (int i = 0; i < cantidad; i++) {

                reading(client, i);

            }
            System.out.println("Fin lectura");

            tr.close();
            fin = new Date().getTime();
        }
        double insercion = (double) (intermedio - inicio) / 1000;
        double lectura = (double) (fin - intermedio) / 1000;
        double total = insercion + lectura;
        System.out.println("Entrada de datos: " + insercion);
        System.out.println("Lectura de datos: " + lectura);
        System.out.println("Total proceso: " + total);

    }

    private static void inserting(Cassandra.Client client, long i)
            throws UnsupportedEncodingException, InvalidRequestException,
            UnavailableException, TimedOutException, TException {

        String keyID = "java" + i;
        // INSERTAMOS DATOS.
        long timestamp = System.currentTimeMillis();

        // Un proyecto
        ColumnPath colPathName = new ColumnPath(PROYECTOS_FAMILY);
        colPathName.setColumn("NOMBRE".getBytes(UTF8));
        client.insert(KEYSPACE, keyID, colPathName, "Proyecto".getBytes(UTF8),
                timestamp, ConsistencyLevel.ONE);
        ColumnPath colPath = new ColumnPath(PROYECTOS_FAMILY);
        colPath.setColumn("email".getBytes(UTF8));

        client.insert(KEYSPACE, keyID, colPath, "blablabla".getBytes(UTF8),
                timestamp, ConsistencyLevel.ONE);


        String llaveID = "Me gusta esto" + i;
        ColumnPath colName = new ColumnPath(DESA_FAMILY);
        colName.setColumn("unaColumna".getBytes(UTF8));
        client.insert(KEYSPACE, llaveID, colName, keyID.getBytes(UTF8),
                timestamp, ConsistencyLevel.ONE);

        List<Column> entriesColumns = new ArrayList<Column>();

        entriesColumns.add(new Column("observaciones".getBytes("UTF8"),
                "Hijos nuestros".getBytes("UTF-8"), timestamp));

        entriesColumns.add(new Column("pm".getBytes("UTF8"),
                "te vas a la B".getBytes("UTF-8"), timestamp));

        UUID uuid = UUIDGenerator.getInstance().generateTimeBasedUUID();

        SuperColumn superColumn = new SuperColumn(uuid.toByteArray(),
                entriesColumns);

        ColumnOrSuperColumn cosc = new ColumnOrSuperColumn();
        cosc.setSuper_column(superColumn);

        List<Mutation> mutList = new ArrayList<Mutation>();
        Mutation mut = new Mutation();
        mut.setColumn_or_supercolumn(cosc);
        mutList.add(mut);

        Map<String, List<Mutation>> mapCF = new HashMap<String, List<Mutation>>(
                1);
        mapCF.put(TRABAJAN_FAMILY, mutList);

        Map<String, Map<String, List<Mutation>>> muts = new HashMap<String, Map<String, List<Mutation>>>();
        muts.put(llaveID, mapCF);

        client.batch_mutate(KEYSPACE, muts, ConsistencyLevel.ONE);

    }

    private static void reading(Cassandra.Client client, long i)
            throws InvalidRequestException, NotFoundException,
            UnavailableException, TimedOutException, TException,
            UnsupportedEncodingException {
        String keyID = "java" + i;
        String llaveID = "Me gusta esto" + i;

        ColumnPath colPathName = new ColumnPath(PROYECTOS_FAMILY);
        colPathName.setColumn("NOMBRE".getBytes(UTF8));
        // Leemos una columna (clave, valor y timestamp)
        Column col = client.get(KEYSPACE, keyID, colPathName,
                ConsistencyLevel.ONE).getColumn();

        // System.out.println("--------- Leemos una columna ------");
        // System.out.println(new String(col.name, UTF8) + ":"
        // + new String(col.value, UTF8) + ":" + new Date(col.timestamp));

        // Leemos las filas completas...
        SlicePredicate predicate = new SlicePredicate();
        SliceRange sliceRange = new SliceRange();
        sliceRange.setStart(new byte[0]);
        sliceRange.setFinish(new byte[0]);
        sliceRange.setCount(50000);
        predicate.setSlice_range(sliceRange);

        // System.out.println("--------- Leemos todas las filas ------");
        ColumnParent parent = new ColumnParent(PROYECTOS_FAMILY);
        List<ColumnOrSuperColumn> results = client.get_slice(KEYSPACE, keyID,
                parent, predicate, ConsistencyLevel.ONE);
        // for (ColumnOrSuperColumn result : results) {
        // Column column = result.column;
        // System.out.print(new String(column.name, UTF8) + ":"
        // + new String(column.value, UTF8) + ":"
        // + new Date(column.timestamp)+" | ");
        // }
        // System.out.println("----------------------------");
        // Leemos las entradas
        //
        parent = new ColumnParent(TRABAJAN_FAMILY);

        results = client.get_slice(KEYSPACE, llaveID, parent, predicate,
                ConsistencyLevel.ONE);

        for (ColumnOrSuperColumn result : results) {
            SuperColumn superColumn = result.super_column;
            UUID uuid = new UUID(superColumn.name);
            // System.out.println(uuid.toString() + " [ ");
            for (Column column : superColumn.columns) {
                // System.out.print(new String(column.name, UTF8) + ":"
                // + new String(column.value, UTF8) + ":"
                // + new Date(column.timestamp)+" | ");
            }
            // System.out.println(" ] ");
        }
    }

    public static void lecturaParticular(int i) throws InvalidRequestException,
            NotFoundException, UnavailableException, TimedOutException,
            TException, UnsupportedEncodingException {
        long a = 0;
        TTransport tr = new TSocket("localhost", 9160);
        TProtocol proto = new TBinaryProtocol(tr);
        Cassandra.Client client = new Cassandra.Client(proto);
        tr.open();
        long inicio = f();
        String keyID = "java" + i;
        String llaveID = "Me gusta Cassandra" + i;

        ColumnPath colPathName = new ColumnPath(PROYECTOS_FAMILY);
        colPathName.setColumn("NOMBRE".getBytes(UTF8));
        // Leemos una columna (clave, valor y timestamp)
        Column col = client.get(KEYSPACE, keyID, colPathName,
                ConsistencyLevel.ALL).getColumn();

        // System.out.println("--------- Leemos una columna ------");
        // System.out.println(new String(col.name, UTF8) + ":"
        // + new String(col.value, UTF8) + ":" + new Date(col.timestamp));

        // Leemos las filas completas...
        SlicePredicate predicate = new SlicePredicate();
        SliceRange sliceRange = new SliceRange();
        sliceRange.setStart(new byte[0]);
        sliceRange.setFinish(new byte[0]);
        sliceRange.setCount(50000);
        predicate.setSlice_range(sliceRange);

        // System.out.println("--------- Leemos todas las filas ------");
        ColumnParent parent = new ColumnParent(PROYECTOS_FAMILY);
        List<ColumnOrSuperColumn> results = client.get_slice(KEYSPACE, keyID,
                parent, predicate, ConsistencyLevel.ALL);
        System.out.println("Total columnas: " + results.size());
        for (ColumnOrSuperColumn result : results) {
            Column column = result.column;
            // System.out.print(new String(column.name, UTF8) + ":"
            // + new String(column.value, UTF8) + ":"
            // + new Date(column.timestamp)+" | ");
        }
        // System.out.println("----------------------------");

        System.out.println("--------- ------");
        parent = new ColumnParent(TRABAJAN_FAMILY);

        results = client.get_slice(KEYSPACE, llaveID, parent, predicate,
                ConsistencyLevel.ALL);
        a = results.size();
        for (ColumnOrSuperColumn result : results) {
            SuperColumn superColumn = result.super_column;
            UUID uuid = new UUID(superColumn.name);
            // System.out.println(uuid.toString() + " [ ");
            for (Column column : superColumn.columns) {
                // System.out.print(new String(column.name, UTF8) + ":"
                // + new String(column.value, UTF8) + ":"
                // + new Date(column.timestamp)+" | ");
            }
            // System.out.println(" ] ");
        }

        tr.close();
        long fin = f();
        double total = (double) (fin - inicio) / 1000;
        System.out.println("Total encontrados: " + a);
        System.out.println("Total proceso: " + total);
    }

    private static long f() {

        return new Date().getTime();
    }
}

Ejemplo de codigo de Hector:

// nombre del cluster, ip de conexion puede ser cualquiera del nodo
        Cluster cluster = HFactory.getOrCreateCluster("Test Cluster", "192.168.254.66:9160");
        // nombre del keyspace
        Keyspace keyspace = HFactory.createKeyspace("CDT", cluster);

        Mutator mutator = HFactory.createMutator(keyspace);
        // inserta datos
        mutator.insert("jsmith", "Proyectos", HFactory.createStringColumn("first", "John"));
        mutator.insert("pedroloco", "Proyectos", HFactory.createStringColumn("first", "Pedro"));
        mutator.insert("juanmiguel", "Proyectos", HFactory.createStringColumn("first", "Juan"));

        // recupera un dato
        ColumnQuery<String, String> columnQuery = HFactory.createStringColumnQuery(keyspace);
        columnQuery.setColumnFamily("Proyectos").setKey("jsmith").setName("first");
        QueryResult<HColumn<String, String>> result = columnQuery.execute();

        System.out.println(result.get().getValue());

        //recupera varios datos
        MultigetSliceQuery<String, String> multigetSliceQuery = HFactory.createMultigetSliceQuery(keyspace, StringSerializer.get(), StringSerializer.get());
        multigetSliceQuery.setColumnFamily("Proyectos");
        multigetSliceQuery.setKeys("java1", "java100", "java999");
        multigetSliceQuery.setRange("", "", false, 3);
        QueryResult<Rows<String, String>> result2 = multigetSliceQuery.execute();

        System.out.println(result2.get().getCount());

        for (Row<String, String> r : result2.get()) {
            System.out.println(r.getColumnSlice().getColumnByName(r.getColumnSlice().getColumns().get(0).getName()).getValue());
Es mucho mas sencillo usar Hector como cliente que Thrift.

Programación orientada a objetos con Java

2011-06-17T15:29:00.001-03:00

La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe variedad de lenguajes de programación que soportan la orientación a objetos. - Wikkipedia.

¿Que es un objeto?

Un objeto es una representación detallada, concreta y particular de un "algo". Tal representación determina su identidad, su estado y su comportamiento particular en un momento dado.
Quizas decir que es una representación de un “algo” suene un tanto vaga, pero es exactamente eso: un objeto en el software puede representar a un objeto tangible como un “motor” o bien, puede representar a un objeto no tangible, como el objeto “estrategia”.
Un objeto es una pieza de software única que posee ciertas características (atributos) y un comportamiento previamente determinado (métodos que se definen en una clase).
A diferencia de otros lenguajes, un objeto siempre pertenece a una clase. No puede existir sintaxis “tirada” en cualquier lugar.

¿Que es una clase?

Un clase es una plantilla que se utiliza para definir las características y habilidades de los objetos, lo que significa, que una clase es la definición de un objeto. Es un modelo abstracto, sin “vida”, ya que son sus instancias (objetos) las que tendrán valores en el futuro.
Desde un punto de vista más técnico, es el lugar donde se define los métodos y atributos que tendrán los objetos. Una clase es un contenedor de uno o más datos (variables o propiedades miembro) junto a las operaciones de manipulación de dichos datos (funciones/métodos).
Para aquellos que vienen de la programación estructurada es un conjunto de datos definidos por el programador, parecidos a las “estructuras de datos” de la programación estructurada, pero con la importante novedad de incluir también las herramientas necesarias para su manipulación.

Cuando se crea una clase, por convención, suelen colocarse en la parte superior los atributos de la misma. Y en la parte inferior, sus métodos. Si esto no se cumple, funcionan igual, aunque esto podría afectar el entendimiento de la misma y, por ende, el mantenimiento del sistema.
Los nombres de las clases empiezan con mayúscula y si tuviesen palabras en el medio, también comenzarían con mayúscula: AutoDeCarrera.

Atributos

Los atributos son las características del objeto. Toman valores durante la vida del mismo. Estos valores determinan el estado del objeto.
Cuando definimos un atributo se establece su nombre y su tipo. Los atributos suelen ser sustantivos. Marcan las propiedades del objeto.
Una persona puede tener varios atributos. Además de las variables (y clases) definidas por Java, es posible agregar atributos propios, por ejemplo documento que hace referencia a la clase Documento.
Los atributos se escriben con minúscula y si tuviesen palabras en el medio, éstas van con mayúscula: colorDeOjos.

Métodos

Representan el comportamiento del objeto. Es decir, lo que el objeto puede hacer.
Los métodos se escriben con minúscula y si tuviesen palabras en el medio, éstas van con mayúscula: dameCantidad().

Deben especificar lo que devuelven….y en caso que no devuelvan nada se utiliza la palabra reservada “void”.

Creando objetos.

Un objeto es una instancia de una clase.
Es la implementación con valores del modelo abstracto (clase).
La sintaxis para crear un objeto es new Objeto(), donde la parte izquierda del igual representa la referencia del objeto.

Por ejemplo, para crear un objeto de la clase Persona habría que colocarla siguiente sintaxis:

Persona p = new Persona();

El paradigma de objetos posee tres características fundamentales:

Encapsulamiento
Herencia
Polimorfismo

1) Encapsulamiento.

Consiste en ocultar los detalles de la implementación de un objeto, a la vez que se provee una interfaz pública por medio de sus métodos permitidos.
Es la propiedad de los objetos de permitir el acceso a sus estados. Esto se logra a través de su interfaz pública o a través de relaciones preestablecidas con otros objetos. Lo que importa es el comportamiento del objeto y no como esta implementado ese comportamiento.
Tiene una regla de oro: atributos en privado y métodos públicos.

El modificador “private” hace que un atributo (o método) pueda ser accedido sólo dentro de la propia clase.
El modificador “public” hace que un atributo (o método) pueda ser accedido desde todos lados.

Aquí vemos como todos los atributos son privatizados y todos tienen métodos Get que sirve para pedir el valor del atributo en cuestión y un método Set que sirve para asignarle un valor determinado. Se debe prestar especial atención a aquellos atributos que son objetos, ya que reciben un objeto instanciado.

Los errores de codificación se subrayan en rojo y son debido a que los atributos fueron privatizados, por ende, no pueden ser accedidos por fuera de la clase.

Esta sería la forma correcta.

Ventajas del encapsulamiento.:

La complejidad de la implementación queda escondida al resto de los objetos. Esto se ve reflejado en la vida real, yo quiero que mi auto funcione pero no quiero saber como esta hecho el motor.
La implementación de un objeto puede variar sin que ello afecte a los objetos que interactúan con él. Esto se debe a que los objetos llaman a un método y no saben como es la implementación. De esta manera, si la implementación (que es algo interno de la clase) varía, el resto de los objetos no se ven afectados.
Se protege al objeto de usos indebidos o inapropiados. Si los atributos son accedidos a través de métodos, es posible realizar ciertas validaciones, por ejemplo, el método setSueldo(-120) no debería asignar 120 al sueldo de la persona, ya que es un número negativo. El método setIVA(0.25) debería ser privado, asi ese atributo es de sólo lectura.
Se centraliza la manipulación del dato. Supongamos que el método getDNI() debe ser modificado para que, además del DNI, nos anteponga el número de sucursal donde trabaja la persona. Sin los Get y Set hubiera sido bastante engorroso y hubiesemos tenido que recorrer todo el programa. Con los Get y Set es tan simple como modificar 1 sólo método.

2) Herencia.

Es la capacidad de un objeto para utilizar las estructuras y métodos existentes en sus antepasados. Los “hijos” pueden compartir (y extender) su comportamiento sin tener que reimplementarlo. Si bien se heredan los métodos de los antepasados, es posible redefinirlos si fuera necesario.
La idea es no repetir comportamientos que otros ya lo tienen implementados. La idea es que en la clase padre exista un comportamiento estándar y la clase hija pueda especializarse en otros aspectos.

Hay dos tipos de herencia:

Simple
Múltiple ( es cuando una clase tiene más de 1 padre, lo cual no esta permitido en Java)

En Java, para heredar de una clase se utiliza la palabra clave “extends”. En nuestro ejemplo la definición de la clase Cliente es: public class Cliente extends Persona

Ventajas de la herencia.

Aumenta la reutilización del código. Tal como se pudo apreciar en la presentación anterior.
Favorece el Polimorfismo de los objetos. Esto se verá a continuación.
Las clases pueden ser organizadas jerárquicamente. Un “hijo” es un “tipo de…” de una clase padre.

3) Polimorfismo.

Polimorfismo implica varias formas de responder el mismo mensaje. En programación orientada a objetos se denomina polimorfismo a la capacidad que tienen objetos de diferentes clases de responder al mismo mensaje.
Esto significa que puede haber muchos mensajes con el mismo nombre, en diferentes clases. Cada clase responde al mensaje con su código propio (o método).
Existen diferentes formas de apreciar el polimorfismo:
a) Sobre-carga de métodos
b) Sobre-escritura de métodos
c) Vinculación dinámica

a) Sobrecarga de métodos.

La sobrecarga de métodos consiste en declarar métodos con el mismo nombre que serán diferenciados por los parámetros que reciben o que retornan.
Los parametros se diferencian por el tipo y la cantidad.
Por ejemplo, un mismo nombre de método puede recibir un String o un int o nada. Ahora veremos un ejemplo donde quedará más claro.

En el ejemplo se puede observar que en caso de crear un una Persona, es posible asignarle un apellido, así como también es posible no pasarle parámetros y que tome un apellido por default.
La ventaja de esto es que no es necesario declarar una método con distinto nombre para métodos similares en los que únicamente cambia el tipo de parámetros que han de utilizar.

b) Sobreescritura de métodos

Una subclase sobreescribe un método de su superclase cuando define un método con las mismas características (nombre, número y tipo de argumentos) que el método de la superclase.
Las subclases emplean la sobreescritura de métodos la mayoría de las veces para agregar o modificar la funcionalidad del método heredado de la clase padre.

En el ejemplo vemos que el nombre por default “Perez” no le sirve a la clase Cliente, la cual prefiere “Garcia”.

Vemos en el ejemplo que Persona y Cliente tienen la opción de setear un apellido (1er caso) o tomar el que viene por default (2do y 3er caso). Esto se puede apreciar en la salida por consola.

c) Vinculación dinámica.

Una referencia a un objeto de una clase, puede pasar a referenciar a otro objeto de otra clase.
Esto es posible siempre y cuando esten en la misma línea de herencia.
En nuestro ejemplo, una persona Puede referencia a un Cliente, ya que ambos se encuentran en la misma línea de herencia.

Si bien la clase instancia es Cliente, se puede observar que el numero de cliente no aparece. Si lo necesito debo “castear”. Luego veremos este concepto.

Respuesta correcta: Garcia.

Casteo.

Para que un objeto que fue referenciado por otro pueda recuperar sus métodos particulares es necesario “castear”.
El casteo sirve para cambiar de tipo. Es como que el objeto se “saca el disfraz”.

Hasta aquí la teoría de objetos, pero pronto crearé una nueva entrada con cosas básicas de Java como tipos de atributos/métodos, clases abstractas, paquetes, interfaces, etc. que van a complementar este post.

Para crear este post me he basado en unos manuales que he escrito junto a otros profesores cuando trabajaba en IBM. Ellos son:

David Brunstein.
Gabriel García.
Sabrina Campa.

¿Cual es el mejor Java Cache?

2011-06-16T21:31:00.003-03:00

Para hacerla corta...Infinispan. Para hacerla larga y ver que pruebas hicimos para sacar esa conclusión, leer lo que sigue a continuación.

Hemos realizado diverso tipos de pruebas con los caches más conocidos para que se tenga una mejor visión a la hora de seleccionar una alternativa.

Algunas de las siguientes pruebas se realizaron con el framework CacheBenchFwk en su version 1.0.0 y otras se hicieron con una aplicación desarrollada especialmente para estas pruebas, para poder tener una vista mas detallada sobre las ventajas de esta herramienta.

Las pruebas con el CacheBenchFwk las hemos realizado con las siguientes herramientas:

Infinispan 4.0.0
Jboss Cache 3.2.2GA
EHCache 1.7.2

Y las pruebas desarrolladas por nosotros las hicimos con las siguientes librerías en su versión FINAL:

Infinispan 4.1.0
Jboss Cache 3.2.5GA
EHCache 2.2.0

Las pruebas fueron realizadas con las siguiente configuracion:

Linux Ubuntu 10.04
Total memoria RAM: 4 Gigas.
Procesador: 4 procesadores Intel Atom 330 1.6 Ghz.
JDK version "1.6.0_20" 64-Bit con los parametros -Xms1g -Xmx1g
CacheBenchFwk 1.0.0
Pruebas en modo standalone con 25 concurrencias usando Strings generados aleatoriamente tanto para valores como para las claves generando 1 kb de carga por cada entrada.
Las pruebas no locales fueron hechas en una red local con 3 nodos de iguales características a las descriptas anteriormente.
Configuraciones de las distintas tecnologias estan por default.

Pruebas locales.

En los siguientes graficos de performance se ven dos barras verticales para Infinispan como para JbossCache. Cada una se corresponde con un tipo de Isolation level Read Commited y Repeatable Read.

1) Pruebas de Stress

Carga de datos

Lectura de datos

2) Pruebas de escritura y lectura simples

Los tiempos son tan bajos que Infinispan no aparece en la grafica.

Como se puede apreciar en los graficos anteriores Infinispan es superior a Jboss Cache y EHCache, obteniendo los tiempos mas bajos tanto en escritura como lectura de datos.

En el caso de la pruebas de stress, estan fueron hechas con los distintos caches como si funcionaran unicamente en un servidor dedicado exclusivamente para cache. Si bien la tecnologia con la que se hicieron las pruebas no son las de un servidor, son aproximados los resultados. Las pruebas de stress demuestran que en el caso de que se quiera montar un servidor para uso exclusivo de cache Infinispan es una excelente opción, ya que en la pruebas se uso concurrencia simulando las distintas peticiones que se pueden realizar. Estas pruebas se realizaron como unico nodo, pero Infinispan se puede usar en modo cluster lo cual permitiria una mayor disponibilidad de datos y ser escalable, pudiendo elegir el modo en que se repliquen los datos(en cada nodo una copia o una parte de esta).

Por otro lado las pruebas simples fueron hechas con una aplicación simple desarrollada por Guillermo y por mí para demostrar la performance de cada cache en un modo de uso local contra una aplicación. Las pruebas, como se ve en los graficos, volvieron a dar a Infinispan como el más rapido. Estos resultados por ejemplo nos sirven a la hora de decidir con que cache de segundo nivel poner a funcionar Hibernate.

Pruebas no locales.

Dado que Infinispan fue un amplio ganador con respecto al resto, decidimos ampliar sus pruebas y realizar un testeo con varios nodos en red para ver si decrecía su rendimiento de alguna manera. Estas pruebas tuvieron las siguientes características:

Las pruebas se realizaron el con el cliente Hot Rod y en modo embebido, debido a que son las dos mejores maneras de usar Infinispan en un entorno con Java.
Para funcionar en modo cluster Infinispan usa Jgroups con las configuraciones TCP como para UDP.

Vamos a hacer una breve explicación de los dos modos:
1) Modo embebido.

La configuración en este modo es secilla, puede ser declarativa o programatica. Con esto podemos levantar varios nodos, pero en cada uno de estos debemos poner nuestra aplicación con Infinispan embebido. Si bien la configuracion es sencilla esto tiene desventajas:

Alto consumo de recursos.
Tiempo en inicializar Infinispan depende de la cantidad de datos que maneje el cache en ese momento.
Bloqueo de acceso al resto de las instancias al agregar nuevos nodos, debido que estos son lentos en levantar.
Para agregar un nuevo nodo debo deployar la aplicación en este.

2) Hot Rod Client
Esta manera de utilizar Infinispan resulta mas sencilla, rapido y performante que la embebida. Lo que se hizo fue levantar los nodos de la siguiente manera:

./startServer.sh -r hotrod -l 192.168.254.66 -c config.xml -p 11311 -o 192.168.254.66 -x 11311

Una vez con todos los nodos levantados, estos ya se estaban mandando mensajes entre sí. Luego levantamos la aplicación configurando la ip de un solo nodo y enseguida reconocio el resto y creo un pool de conexiones para cada uno. El codigo usado fue el siguiente:

Las pruebas con este cliente fueron mas que satisfactorias, ya que el cliente detectaba cuando se agregaba un nodo o se bajaba uno del cluster. Esto no afectaba a su performance. Si bien este cliente hay algunas operaciones que no soporta como las queries sobre el cache su manejo del cluster compensa.

¿Que aprendimos de las pruebas realizadas?

Al realizar las pruebas en modo embebido y con el cliente Hot Rod, se recomienda ampliamente el uso del cliente Hot Rod en un entorno Java, ya que este maneja de manera mas eficiente el cluster:

Detecta automáticamente cambios en la topología del cluster.
Al agregar nuevos nodos resulta es más rapido con el cliente Hot Rod que de manera embebida.
Usa lo que se llama smart routing para mayor velocidad de respuesta.
Se puede controlar el pool de conexiones con el cluster.
Al levantar el cliente este empieza a detectar los posibles nodos del cluster en la red local.
Muy configurable.

Conclusión.

Infinispan es un producto opensource de JBoss y se ha nutrido de la experiencia de Jboss Cache (una librería). Es una solución que nos permite crear enormes estructuras de datos distribuidas y altamente concurrentes almacenadas en la memoria RAM de múltiples nodos de un cluster.

Hemos podido observar que Infinispan es altamenta escalable, configurable y sencilla de utilizar. Asimismo, su rendimiento suele ser superior en casi todos los aspectos con respecto a sus competidores.

Infinispan no presentó problemas para realizar pruebas en máquinas distribuídas y su velicidad se ha mantenido constante en las diversas pruebas. Es un producto áltamente recomendable.

Este post es una adaptación de un informe que hice junto a Guillermo Kessler

Infinispan

2011-06-16T00:18:00.003-03:00

Infinispan es una plataforma open source de manejo de Cache. Es similar a otras herramientas conocidas en el mercado como EHCache, JBoss Cache o Coherence.
Cabe aclarar que siendo una herramienta de Jboss, no es una improvisación, sino que el proyecto creció nutriendose de la experienca de JBoss Cache. De todas maneras, son herramientas diferentes, sin relación alguna. La gran diferencia entre ambas es que Jboss Cache es una librería y infinispan es una plataforma mucho mas completa, con herramientas GUI y posibilidad de distribuirla en miles de servidores/nodos.
Se puede bajar de: http://www.jboss.org/infinispan.

Sus características son:

Memoria masiva y alta disponibilidad: si bien es posible utilizar infinispan de manera local, su fuerte es el trabajo distribuìdo. No sólo se limita a que cada servidor es una copia de otro (como Jboss Cache), también es posible realizar realizar una distribución de la información en los diferentes servidores.
Escalabilidad: dado que es una plataforma distribuida es muy simple lograr que sea escalable. Se puede acoplar tantas instancias como se deseen y no existe impedimento hasta donde se quiera crecer con la capacidad del Cache.
Datos distribuidos: su algoritmo de hashing permite que sus datos distribuidos se recuperen de manera veloz y sin generar tráfico en la red.
Persistencia: posee varias formas para guardar los datos en el disco duro, que van desde JDBC hasta archivos planos.
Lenguajes varios: no sólo es posible trabajar con Java, también es posible utilizar varios lenguajes más como PHP, Python, Ruby, C, etc.
Administración: es simple de administrar y posee herramientas GUI para realizar estadísticas.

Configuración del Cache.

Es posible realizar una configuración declarativa, basada en XML o bien a nivel programación. Por otro lado, se puede configurar como default o Global, siendo esta última un cache compartido entre varias instancias.
Si se tiene una configuración previa con otra herramienta de cache, existen scripts que automatizan la migración hacia infinispan desde:

EHCache 1.x
JBoss Cache 3.x
Coherence 3.x

Tiene muchas facilidades para lockear objetos, sincronizar el cache, limpiarlo o hasta indexarlo de diversas formas. Es altamente configurable.

Ejemplo.

Cache Loaders

Un Cache Loader es la conexión que se mantiene contra una herramienta de persistencia de datos. Dicho loader es el encargado de guardar los datos para su posterior persistencia y obtener los datos cuando estos no se encuentren en el cache.
Infinispan posee muchas formas de configuración de cache loaders, de hecho, se puede configurar más de uno al mismo tiempo para que trabajen en cadena. Asimismo, se puede configurar algunos items como Cache Passivation, Eviction, Pool de Conexiones, etc.
Se ofrecen diversos tipos de cache loaders como File System, JDBC (soporta JTA), Hibernate, Cloud cache loader, Remote cache loader y Cassandra cache loader.

Módulos de servidor para Infinispan.

Apartir de la version 4.1 se agrego la posibilidad de usar Infinispan en el modo cliente-servidor, lo cual permite levantar unicamente servidores de Infinispan de manera muy rapida. Esto es por la creacion de distintos modulos de servidor y distintos clientes para estos, permitiendo usar un esquema de acceso como el siguiente (el gráfico lo saque de la página oficial):

Tipos de servidor

Los tipos de servidores se diferencian en el protocolo de comunicación y como manejan las conexiones entrantes.

REST:

Distribuído como un archivo WAR, que puede ser deployado en cualquier servlet container permitiendo el acceso a Infinispan vía RESTful interface.
Para poder conectarse se puede usar cualquier cliente HTTP.
Este módulo es recomendado para entornos donde el puerto HTTP es el único método de acceso permitido entre clientes y servidores.
Los clientes de quieran equilibrar la carga o tolerancia a fallas (failover) entre los diferentes REST servers pueden usar culquier HTTP load balancer standard como mod_cluster.

Memcached:

Es una implementacion de Memcached text protocol respaldado por Infinispan.
Para conectarse se puede usar cualquiera de los Memcached client.
A diferencia de los Memcached servers, los Memcached servers basados en Infinispan se los puede poner en cluster y por lo tanto distribuir o replicar informacion usando algoritmos hash. Entonces este modulo es interesante para usuarios que quieran proveer failover de la informacion en Memcaches servers.
Algunos clientes soportan load balance y failover pasandoles una lista estatica de direcciones de servidores (perl's Cache::Memcached por ejemplo) pero para agregarle o sacarle algun servidor se tiene que hacer manualmente.

Hot Rod

Hot Rod server es una implementacion de Hot Rod Protocol respaldado por Infinispan que permite a los clientes hacer dynamic load balancing, failover y smart routing.
Las opciones de Java Hot Rod client son un poco limitadas debido a su implementacion.
Es ideal para clientes que se ejecutan en java, ya que el cliente provee dynamic load balancing y failover. Esto significa que los Hot Rod clients puede detectar dinámicamente cambios en la topología de los Hot Rod servers mientras esten como cluster, entonces cuando nuevos nodos que se unen o se quitan, los clientes actualizan la vista de la topología de los Hot Rod servers. Y cuando los Hot Rod servers son configurados en modo distribución, los clientes pueden detectar donde reside una key en particular y pueden enrutar los pedidos de forma inteligente.
Load balancing y failover es dinámicamente proporcionado por el cliente usando la información que le provee el server.

WebSocket

Infinispan WebSocket Server permite usar Infinispan sobre un Websocket
Este modulo esta específicamente desarrollado para clientes Javascript.
Este modulo es particularmente adecuado para desarrolladores que quieran acceder alas instancias de Infinispan desde código Javascript.
Los websockets trabajan en el mismo puerto HTTP, se puede usar cualqueir HTTP load balancer.

Modos de clusterización.

Infinispan puede ser configurado como local o cluster. Si es en modo cluster, el cache puede ser configurado para replicar los cambios en todos los nodos, para invalidar cambios en los nodos y finalmente ser usado en modo distribuído (los cambios de estado son replicados en un pequeño grupo de nodos suficientes como para ser tolerante a fallos pero no en muchos nodos para prevenir la escalabilidad). Estas configuraciones suelen ser muy sencillas.

Los distintos modos de clusterización son:

1) Modo Local

Permite tener los datos en memoria como JBoss Cache y EHCache. Algunas de las caracteristicas que ofrece:
Mantener los datos en memoria para después persistirlos, ejemplo: cache level-2 para Hibernate.
Eliminar objetos para evitar quedarse sin memoria.
Vencimiento de objetos en cache.
Fue pensado para lograr un alto rendimiento en entornos multi-CPU/multi-core.

2) Modo replicación

Es un simple modo de clusterización donde cada instancia de cache descubre otras instacias de cache (en distintas JVM) dentro de la red local y formar un cluster. Las entradas que se agregan al cache en cualquiera de las instancias son replicadas a todas las instancias del cluster y pueden ser obtenidas localmente desde cualquier instancia. Este modo permite una manera rápida de compartir estados a través del cluster, pero este modo solo es performante en cluster pequeños (por debajo de los 10 servers), debido a la cantidad de replicaciones que debe hacer.
Este modo puede ser sincrónico o asincrónico. El sincrónico bloquea la llamada (ejemplo: put()) hasta que se replica en todos los nodos. En cambio el asincrónico es mas rapido debido a que no hace falta que se replique inmediatamente en todos los nodos, por los tanto no produce bloqueos de ningun tipo. El asincrónico va a replicar en determinados intervalos de tiempo, cuando se llene la cola de elementos o una combinacion de estos.

3) Modo invalidación

Este modo no comparte información. Lo que hace es borrar información que puede ser vieja desde caches remotos. Usar este modo solo tiene sentido si se tiene respaldo de la información como una base de datos.
Es usado para tener un acceso rapido a datos sin tener que acceder a la base cada vez que se soliciten estos. Se suele usar con cache loaders, puede ser sincrónico o asincrónico.

4) Modo distribuído

Este es un modo poderoso que permite a Infinispan escalar linealmente a medida que se agregan mas servers al cluster. La distribucion hace el uso de un algoritmo hash consistente que determina donde deben ser almacenadas las entradas dentro del cluster.
El numero de copias que mantiene en el cluster es un equilibrio entre la performance y la durabilidad de la información.

5) Hot Rod Client

Hot Rod es un protocolo binario para la comunicación con el cluster. Este es sencillo de usar, pero posee ventajas y desventajas comparado con el resto de los clientes para los otros modulos.

Ventajas:

Sencillo uso a traves de su API.
Configuración simple.
Es inteligente.
Para que funcione solo se debe conocer la ip y puerto de nodo.
Maneja el pool de conexiones.
Posee estrategias para el balance entre nodos.
Detecta la topologia de la red y si esta fue modificada (cuando se agregan o quietan nodos).
Detecta automaticamente todos los nodos del cluster solo configurandole con una ip de estos. Conoce la distribución de las keys en los nodos lo cual baja la carga de trabajo de estos.

Desventajas:

Solo soporta comunicación TCP.
No soporta queries en el cache.
No soporta las estadísticas.

Este post lo he adaptado de un informe que he realizado junto con Guillermo Kessler.

EhCache

2011-06-15T11:54:00.000-03:00

EhCache es un cache open source, basado en standards, escalable, robusto, performante y basado en java. Es mantenido por Terracota, quien como un plus provee un servidor adicional para mejorar la performance del cache. Se puede bajar de http://ehcache.org.

Sus características principales son:

Rápido y simple de usar.
Pequeño (menos de 700 kb) y con pocas dependencias.
Escalable: permite, por un lado, escribir a disco y, por otro, trabajar con muchos caches en paralelo.
Flexible: permite trabajar con Objects o Serializables y configurarlo mediante xml o programaticamente.
Extensible: se pueden adicionar plug-ins, loaders, listeners, JMX y exceptions handlers. Trabaja con varias APIs como JTA o frameworks como Hibernate.
Distribuído: posee muchas opciones de replicación de los datos.
Cache Server: permite agregarle servidores standalone (o un war, en su defecto).

Como funciona.

Es muy sencillo de utilizar. El API nos provee diversas formas de crear un cache y la más sencilla es simplemente pasando un parámetro String con el nombre del cache a un método (addCache) de la clase CacheManager.

Veremos los métodos de colocación/obtención de datos del cache. Como se observa hay que crear un nuevo objeto Element por cada entrada. Esto mucho no me gusta, pero la realidad es que lo hace de manera muy rápida.

Datos útiles.

Para enviar datos a disco el cache ofrece el método flush(). Para saber el estado general del cache nos ofrece varios métodos que nos dan diversa información. Los más usados son:

¿Que más nos ofrece EhCache?

Se puede configurar de diversas maneras para su mejor performance. Un link interesante para ello se ofrece en la página oficial: http://ehcache.org/documentation/offheap_store.html
También posee un API que nos permite buscar datos en el cache, lo cual puede resultarnos muy útil: http://ehcache.org/documentation/search.html verán que el API es muy parecido al Criteria de Hibernate.

JBoss Cache

2011-06-14T11:15:00.000-03:00

Es un cache transaccional, clusterizado y basado en una estructura de árbol. Obviamente también puede funcionar en modo “standalone“ y sin clusterizarlo.

Lo podemos bajar de su page oficial: http://www.jboss.org/jbosscache en la sección Downloads. Si leemos la documentación oficial veremos que hay una versión que especial para trabajar con clases POJOs y el cache viene prreparado para trabajar sus relaciones. No vamos a tener en cuenta esta particular versión.

Sus ventajas más importantes son:

API simple para trabajar el cache.
Es eficiente y “thread-safe”.
Posibilidad de replicar a algunos o todos los clusters.
Persistencia a disco o remota.
Garbage collector inteligente.

Como funciona.

Esta organizado como un árbol, con un único elemento raiz. Cada nodo del árbol que tiene un Map donde guarda objetos que hayan implementado la interface java.io.Serializable.
La forma más sencilla de comenzar a utilizarlo es mediante su interface Cache que se puede obtener mediante un CacheFactory que se basa en un xml u objeto java. Una vez que se tenga acceso al Cache, se puede navegar su estructura para guarda u obtener datos.

Aqui un ejemplo de como he creado un cache:

El ejemplo sigue así: he colocado 2000 objetos del tipo String y luego los he obtenido. Si vemos la salida por consola observamos que se perdió más tiempo en colocarlo que en obtenerlos.

Para colocar y obtener datos he utilizado 2 métodos:

Los nombres de los nodos es arbritario y es recomendable verlo como un grupo lógico de datos. La clase Fully Qualified Name (Fqn) encapsula un patch a una ruta determinada del árbol.
La interface Cache también publica los métodos put/get/remove que reciben un Fqn como parámetro. Esto evita tener que trabajar con nodos:

Tipos de Cache
Se pueden setear diversos tipos de Cache:

LOCAL: local, sin cluster.
REPL_SYNC: replica de manera sincronizada con los otros cluster. Implica que los cambios son replicados y el cluster que disparó el cambio de datos se bloquea hasta tener el OK del resto.
REPL_ASYNC: replica de manera asincrónica. Es decir, que el cluster que dispara el cambio no se bloquea, sique trabajando.
INVALIDATION_SYNC: cuando un dato es actualizado en uno de los clusters, no lo replica, solo envía un mensaje al resto diciendo que sus datos son inválidos. Trabaja de manera sincronizada.
INVALIDATION_ASYNC: ídem anterior, pero trabaja de manera asincrónica.

En mi ejemplo, no he utilizado clusters por lo tanto lo seteo de manera local:

Cache Listerners

Hay varios tipos de eventos que podemos “escuchar” si fuese necesario. Como son muchos, no voy a nombrar todos aquí. Les recomiendo que vean el siguiente link para ver todas las posibilidades que hay: http://docs.jboss.org/jbosscache/3.2.1.GA/userguide_en/html_single/index.html#api.listener

Los eventos más comunes para escuchar son:
@CacheStarted
@CacheStopped
@NodeCreated
@NodeModified
@NodeRemoved
@CacheBlocked
@CacheUnblocked

Por suerte los nombres son muy descriptivos y no necesitan mayor explicación. Se utiliza de la siguiente manera:

¿Que más nos ofrece JBoss?
Si quieren seguir investigando hay muchos temas adicionales para ver como CacheLoaders, manejo de transacciones, politicas de Eviction, configuración por xml y estadísticas entre los temas mas importantes.

Java Cache

2011-06-14T11:10:00.001-03:00

“En informática, una cache o caché (esta última única forma reconocida por la RAE Real Academia Española.) es un conjunto de datos duplicados de otros originales, con la propiedad de que los datos originales son costosos de acceder, normalmente en tiempo, respecto a la copia en el caché.” - Wikkipedia

En el mundo Java existen una gran variedad de productos diseñados para almacenar en caché los objetos que suelen ser accedidos frecuentemente de manera que aumente de forma notable el rendimiento de aplicaciones e-bussines. Eliminando accesos innecesarios a la base de datos, se reduce el tráfico de red e incrementa la escalabilidad de las aplicaciones.

Entre los productos más reconocidos podemos nombrar a JBoss Cache, EhCache y el nuevo producto de JBoss: Infinistpan. En los próximos post voy a dar una introducción de cada uno de ellos y luego los compararé para ver cual es el mejor de todos.

Visitor

2011-06-13T08:47:00.000-03:00

Busca separar un algoritmo de la estructura de un objeto. La operación se implementa de forma que no se modifique el código de las clases sobre las que opera.
Si un objeto es el responsable de mantener un cierto tipo de información, entonces es lógico asignarle también la responsabilidad de realizar todas las operaciones necesarias sobre esa información. La operación se define en cada una de las clases que representan los posibles tipos sobre los que se aplica dicha operación, y por medio del polimorfismo y la vinculación dinámica se elige en tiempo de ejecución qué versión de la operación se debe ejecutar. De esta forma se evita un análisis de casos sobre el tipo del parámetro.

Este patrón debe utilizarse cuando.

Una estructura de objetos contiene muchas clases de objetos con distintas interfaces y se desea llevar a cabo operaciones sobre estos objetos que son distintas en cada clase concreta.
Se quieren llevar a cabo muchas operaciones dispares sobre objetos de una estructura de objetos sin tener que incluir dichas operaciones en las clases.
Las clases que definen la estructura de objetos no cambian, pero las operaciones que se llevan a cabo sobre ellas.

Dado que este patrón separa un algoritmo de la estructura de un objeto, es ampliamente utilizado en intérpretes, compiladores y procesadores de lenguajes, en general.
Se debe utilizar este patrón si se quiere realizar un cierto número de operaciones, que no están relacionadas entre sí, sobre instancias de un conjunto de clases, y no se quiere “contaminar” a dichas clases.

Diagrama UML

Visitor: declara una operación de visita para cada uno de los elementos concretos de la estructura de objetos. Esto es, el método visit().
VisitorConcreto : implementa cada una de las operaciones declaradas por Visitor.
Element: define la operación que le permite aceptar la visita de un Visitor.
ConcreteElement: implementa el método accept() que se limita a invocar su correspondiente método del Visitor.
ObjectStructure: gestiona la estructura de objetos y puede ofrecer una interfaz de alto nivel para permitir a los Visitor visitar a sus elementos.

El Element ejecuta el método de visitar y se pasa a sí mismo como parámetro.

Ejemplo

En Argentina todos los productos pagan IVA. Algunos productos poseen una tasa reducida. Utilizaremos el Visitor para solucionar este problema.

Consecuencias

Facilita la inclusión de nuevas operaciones.
Agrupa las operaciones relacionadas entre sí.
La inclusión de nuevos ElementsConcretos es una operación costosa.
Posibilita visitar distintas jerarquías de objetos u objetos no relacionados por un padre común.

Template Method

2011-06-13T08:30:00.000-03:00

Define una estructura algorítmica cuya lógica quedará a cargo de las subclases. Para ello, escribe una clase abstracta que contiene parte de la lógica necesaria para realizar su finalidad. En ella se define una estructura de herencia que sirve de plantilla ("Template" significa plantilla) de los métodos en las subclases.

Dicho de otra forma, define un esqueleto de un algoritmo, delegando algunos pasos a las subclases. Permite redefinir parte de dicho algoritmo sin cambiar su estructura.

Se debe utilizar este patrón cuando.

Se quiera factorizar el comportamiento común de varias subclases.
Se necesite implementar las partes fijas de un algoritmo una sola vez y dejar que las subclases implementen las partes variables.
Se busque controlar las ampliaciones de las subclases, convirtiendo en métodos plantillas aquéllos métodos que pueden ser redefinidos.

Este patrón se vuelve de especial utilidad cuando es necesario realizar un algoritmo que sea común para muchas clases, pero con pequeñas variaciones entre una y otras. En este caso, se deja en las subclases cambiar una parte del algoritmo.

Diagrama UML

AbstractTemplate o AbstractClass: implementa un método plantilla que define el esqueleto de un algoritmo y define métodos abstractos que deben implementar las subclases concretas
TemplateConcreto o ConcreteClass: implementa los métodos abstractos para realizar los pasos del algoritmo que son específicos de la subclase.

Ejemplo

Como ejemplo, imaginemos una empresa que posee socios, clientes, empleados, etc. Cuando se les solicite que se identifiquen, cada uno lo realizará de distinta manera: quizas un empleado tiene un legajo, pero un cliente tiene un numero de cliente, etc.

Consecuencias

Favorece la reutilización del código.
Lleva a una estructura de control invertido: la superclase base invoca los métodos
de las subclases.

Strategy

2011-06-12T16:11:00.000-03:00

Encapsula algoritmos en clases, permitiendo que éstos sean re-utilizados e intercambiables. En base a un parámetro, que puede ser cualquier objeto, permite a una aplicación decidir en tiempo de ejecución el algoritmo que debe ejecutar.
La esencia de este patrón es encapsular algoritmos relacionados que son subclases de una superclase común, lo que permite la selección de un algoritmo que varia según el objeto y también le permite la variación en el tiempo. Esto se define en tiempo de ejecución. Este patrón busca desacoplar bifurcaciones inmensas con algoritmos dificultosos según el camino elegido.

Este patrón debe utilizarse cuando:

Un programa tiene que proporcionar múltiples variantes de un algoritmo o comportamiento.
Es posible encapsular las variantes de comportamiento en clases separadas que proporcionan un modo consistente de acceder a los comportamientos.
Permite cambiar o agregar algoritmos, independientemente de la clase que lo utiliza.

Diagrama UML

Strategy: declara una interfaz común a todos los algoritmos soportados.
StrategyConcreto: implementa un algoritmo utilizando la interfaz Strategy. Es la representación de un algoritmo.
Context: mantiene una referencia a Strategy y según las características del contexto, optará por una estrategia determinada..
Context / Cliente: solicita un servicio a Strategy y este debe devolver el resultado de un StrategyConcreto.

Ejemplo

Imaginemos una biblioteca de un instituto educativo que presta libros a los alumnos y profesores. Imaginemos que los alumnos pueden asociarse a la biblioteca pagando una mensualidad. Con lo cual un libro puede ser prestado a Alumnos, Socios y Profesores.
Por decisión de la administración, a los socios se les prestará el libro más nuevo, luego aquel que se encuentre en buen estado y, por último, aquel que estuviese en estado regular.
En cambio, si un Alumno pide un libro, ocurre todo lo contrario. Por último, a los profesores intentarán otorgargarles libros buenos, luego los recién comprados y, por último, los regulares. Este caso es ideal para el patrón Strategy, ya que dependiendo de un parámetro (el tipo de persona a la que se le presta el libro) puede realizar una búsqueda con distintos algoritmos.

Seguramente las distintas estrategias concretas sean Singleton.

Consecuencias

Permite que los comportamientos de los Clientes sean determinados dinámicamente sobre un objeto base.
Simplifica los Clientes: les reduce responsabilidad para seleccionar comportamientos o implementaciones de comportamientos alternativos. Esto simplifica el código de los objetos Cliente eliminando las expresiones if y switch.
En algunos casos, esto puede incrementar también la velocidad de los objetos Cliente porque ellos no necesitan perder tiempo seleccionado un comportamiento.

Observer

2011-06-11T12:29:00.000-03:00

Este patrón de diseño permite reaccionar a ciertas clases llamadas observadores sobre un evento determinado.
Es usado en programación para monitorear el estado de un objeto en un programa. Está relacionado con el principio de invocación implícita. La motivación principal de este patrón es su utilización como un sistema de detección de eventos en tiempo de ejecución. Es una característica muy interesante en términos del desarrollo de aplicaciones en tiempo real.

Debe ser utilizado cuando:

Un objeto necesita notificar a otros objetos cuando cambia su estado. La idea es encapsular estos aspectos en objetos diferentes permite variarlos y reutilizarlos independientemente.
Cuando existe una relación de dependencia de uno a muchos que puede requerir que un objeto notifique a múltiples objetos que dependen de él cuando cambia su estado.

Este patrón tiene un uso muy concreto: varios objetos necesitan ser notificados de un evento y cada uno de ellos deciden como reaccionar cuando esta evento se produzca.
Un caso típico es la Bolsa de Comercio, donde se trabaja con las acciones de las empresas. Imaginemos que muchas empresas estan monitoreando las acciones una empresa X. Posiblemente si estas acciones bajan, algunas personas esten interesadas en vender acciones, otras en comprar, otras quizas no hagan nada y la empresa X quizas tome alguna decisión por su cuenta. Todos reaccionan distinto ante el mismo evento. Esta es la idea de este patrón y son estos casos donde debe ser utilizado.

Diagrama UML

Subject: conoce a sus observadores y ofrece la posibilidad de añadir y eliminar observadores. Posee un método llamado attach() y otro detach() que sirven para agregar o remover observadores en tiempo de ejecución.
Observer: define la interfaz que sirve para notificar a los observadores los cambios realizados en el Subject.
SubjectConcreto: almacena el estado que es objeto de interés de los observadores y envía un mensaje a sus observadores cuando su estado cambia.
ObserverConcreto: mantiene una referencia a un SubjectConcreto. Almacena el estado del Subject que le resulta de interés. Implementa la interfaz de actualización de Observer para mantener la consistencia entre los dos estados.

Ejemplo

Vamos a suponer un ejemplo de una Biblioteca, donde cada vez que un lector devuelve un libro se ejecuta el método devuelveLibro(Libro libro) de la clase Biblioteca.
Si el lector devolvió el libro dañado entonces la aplicación avisa a ciertas clases que están interesadas en conocer este evento:

Cada clase que quiera observar el cambio del estado en el libro deberá implementar la siguiente interface y darle lógica al método update:

Veamos el subject:

La biblioteca es quién dispara el evento. Seguramente el estado de un libro no estará en formato String, pero no viene al caso.

Veamos como funciona:

Consecuencias

Permite modificar las clases subjects y las observers independientemente.
Permite añadir nuevos observadores en tiempo de ejecución, sin que esto afecte a ningún otro observador.
Permite que dos capas de diferentes niveles de abstracción se puedan comunicar entre sí sin romper esa división.
Permite comunicación broadcast, es decir, un objeto subject envía su notificación a todos los observers sin enviárselo a ningún observer en concreto (el mensaje no tiene un destinatario concreto). Todos los observers reciben el mensaje y deciden si hacerle caso ó ignorarlo.
La comunicación entre los objetos subject y sus observadores es limitada: el evento siempre significa que se ha producido algún cambio en el estado del objeto y el mensaje no indica el destinatario.

Temas a tener en cuenta.

Si los observadores pueden observar a varios objetos subject a la vez, es necesario ampliar el servicio update() para permitir conocer a un objeto observer dado cuál de los objetos subject que observa le ha enviado el mensaje de notificación.
Una forma de implementarlo es añadiendo un parámetro al servicio update() que sea el objeto subject que envía la notificación (el remitente). Y añadir una lista de objetos subject observados por el objeto observer en la clase Observer.
Si los objetos observers observan varios eventos de interés que pueden suceder con los objetos subjects, es necesario ampliar el servicio add() y el update() además de la implementación del mapeo subject-observers en la clase abstracta Subject. Una forma de implementarlo consiste en introducir un nuevo parámetro al servicio add() que indique el evento de interés del observer a añadir e introducirlo también como un nuevo parámetro en el servicio update() para que el subject que reciba el mensaje de notificación sepa qué evento ha ocurrido de los que observa.

Cabe destacar que Java tiene una propuesta para el patrón observer:
Posee una Interfaz java.util.Observer: una clase puede implementar la interfaz Observer cuando dicha clase quiera ser informada de los cambios que se produzcan en los objetos observados. Tiene un servicio que es el siguiente: void update (Observable o, Object arg)
Este servicio es llamado cuando el objeto observado es modificado.
Además Java nos ofrece los siguientes servicios:
void addObserver (Observer o)
protected void clearChanged()
int countObservers()
void deleteObserver (Observer o)
void deleteObservers()
boolean hasChanged()
void notifyObservers()
void notifyObservers (Object arg)
protected void setChanged()

Posee una clase llamada java.util.Observable: esta clase representa un objeto Subject.
Veamos el mismo ejemplo con el estandard de Java:

State

2011-06-10T15:01:00.001-03:00

Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno. Busca que un objeto pueda reaccionar según su estado interno. Si bien muchas veces esto se puede solucionar con un boolean o utilizando constantes, esto suele terminar con una gran cantidad de if-else, código ilegible y dificultad en el mantenimiento. La intención del State es desacoplar el estado de la clase en cuestión.

En determinadas ocasiones se requiere que un objeto tenga diferentes comportamientos según el estado en que se encuentra. Esto resulta complicado de manejar, sobretodo cuando se debe tener en cuenta el cambio de comportamientos y estados de dicho objeto, todos dentro del mismo bloque de código. El patrón State propone una solución a esta complicación, creando un objeto por cada estado posible.

Este patrón debe ser utilizado cuando:

El comportamiento de un objeto depende de un estado, y debe cambiar en tiempo de ejecución según el comportamiento del estado.
Cuando las operaciones tienen largas sentencias con múltiples ramas que depende del estado del objeto.

Este patrón se utiliza cuando un determinado objeto tiene diferentes estados y también distintas responsabilidades según el estado en que se encuentre en determinado instante. También puede utilizarse para simplificar casos en los que se tiene un complicado y extenso código de decisión que depende del estado del objeto.

Diagrama UML

Context: mantiene una instancia con el estado actual
State: define interfaz para el comportamiento asociado a un determinado estado del Contexto.
StateConcreto: cada subclase implementa el comportamiento asociado con un estado del contexto.

El Context delega el estado específico al objeto StateConcreto actual. Un objeto Context puede pasarse a sí mismo como parámetro hacia un objeto State. De esta manera la clase State puede acceder al contexto si fuese necesario. Context es la interfaz principal para el cliente. El cliente puede configurar un contexto con los objetos State. Una vez hecho esto estos clientes no tendrán que tratar con los objetos State directamente. Tanto el objeto Context como los objetos de StateConcreto pueden decidir el cambio de estado.

Ejemplo

Imaginemos que vamos a un banco y cuando llegamos nos colocamos en la fila de mostrador: si la misma esta abierta, seguiremos en la fila. En cambio, si esta cerrada nos colocaremos en otra fila o tomaremos alguna decisión acorde. Por otro lado, si vemos un cartel que dice "enseguida vuelvo" quizás tenemos que contemplar el tiempo disponible que tenemos. Es decir, para nosotros, el comportamiento de un banco cambia radicalmente según el estado en el que se encuentre. Para estas ocasiones, es ideal el uso de un patrón de estados.

El banco publica un método llamado atende() pero en realidad la atención la realiza la ventanilla.

La ventanilla cambia su comportamiento según el estado en que se encuentre. Por ejemplo, si esta cerrada, no hay atención directamente. Por eso mismo, delega el método de atención a su estado y es este mismo estado quién toma la decisión de atender o no.

Consecuencias

Se localizan fácilmente las responsabilidades de los estados concretos, dado que se encuentran en las clases que corresponden a cada estado. Esto brinda una mayor claridad en el desarrollo y el mantenimiento posterior. Esta facilidad la brinda el hecho que los diferentes estados están representados por un único atributo (state) y no envueltos en diferentes variables y grandes condicionales.
Hace los cambios de estado explícitos puesto que en otros tipos de implementación los estados se cambian modificando valores en variables, mientras que aquí al estar representado cada estado.
Facilita la ampliación de estados mediante una simple herencia, sin afectar al Context.
Permite a un objeto cambiar de estado en tiempo de ejecución.
Los estados pueden reutilizarse: varios Context pueden utilizar los mismos estados.
Se incrementa el número de subclases.

Temas a tener en cuenta

El patrón no indica exactamente dónde definir las transiciones de un estado a otro. Existen dos formas de solucionar esto: definiendo estas transiciones dentro de la clase contexto, la otra es definiendo estas transiciones en las subclaes de State. Es más conveniente utilizar la primer solución cuando el criterio a aplicar es fijo, es decir, no se modificará. En cambio la segunda resulta conveniente cuando este criterio es dinámico, el inconveniente aquí se presenta en la dependencia de código entre las subclases.
Por otro lado, los estados concretos suelen ser Singleton.

Memento

2011-06-10T12:01:00.000-03:00

Este patrón de diseño permite capturar y exportar el estado interno de un objeto para que luego se pueda restaurar, sin romper la encapsulación.
Su finalidad es almacenar el estado de un objeto (o del sistema completo) en un momento dado, de manera que se pueda restaurar posteriormente si fuese necesario. Para ello se mantiene almacenado el estado del objeto para un instante de tiempo en una clase independiente de aquella a la que pertenece el objeto (pero sin romper la encapsulación), de forma que ese recuerdo permita que el objeto sea modificado y pueda volver a su estado anterior.

Hoy en día, muchos aplicativos permiten el "deshacer" y "rehacer" de manera muy sencilla. Para ciertos aplicativos es casi una obligación tener estas funciones y sería impensado el hecho que no las posean. Sin embargo, cuando queremos llevar esto a código puede resultar complejo de implementar. Este patrón intenta mostrar una solución a este problema.

Se usa cuando:

Se necesite restaurar el sistema desde estados pasados.
Se quiera facilitar el hacer y deshacer de determinadas operaciones, para lo que habrá que guardar los estados anteriores de los objetos sobre los que se opere (o bien recordar los cambios de forma incremental).

Este patrón debe ser utilizado cuando se necesite salvar el estado de un objeto y tener disponible los distintos estados históricos que se necesiten. Por ello mismo, este patrón es muy intuitivo para darse cuando debe ser utilizado.
Hoy en día una gran variedad de aplicaciones poseen las opciones de "deshacer" y "rehacer". Por ejemplo, las herramientas de Microsoft Office como Word, Power Point, etc. Es imposible pensar que ciertas herramientas no tengan esta opción, como el Photoshop. También IDEs de programación como Eclipse utilizan una opción de historial local. Una solución para este problema es el patrón Memento.

Diagrama UML

Caretaker: es responsable por mantener a salvo a Memento. No opera o examina su contenido.
Memento: almacena el estado interno de un objeto Originator. El Memento puede
almacenar todo o parte del estado.
Originator: crea un objeto Memento conteniendo una fotografía de su estado
interno.

Ejemplo

Vamos a realizar un ejemplo de este patrón donde se busque salvar el nombre de una persona que puede variar a lo largo del tiempo.

Consecuencias

No es necesario exponer el estado interno como atributos de acceso público, preservando así la encapsulación.
Si el originador tendría que de almacenar y mantener a salvo una o muchas copias de su estado interno, sus responsabilidades crecerían y sería inmanejable.
El uso frecuente de Mementos para almacenar estados internos de gran tamaño, podría resultar costoso y perjudicar la performance del sistema.
Caretaker no puede hacer predicciones de tiempo ni de espacio.

Temas a tener en cuenta.

Si bien la implementación de un Memento no suele variar demasiado, cuando la secuencia de creación y restauración de mementos es conocida, se puede adoptar una estrategia de cambio incremental: en cada nuevo memento sólo se almacena la parte del estado que ha cambiado en lugar del estado completo.
Esta estrategia se aplica cuando memento se utiliza para mantener una lista de deshacer/rehacer.
Otra opción utilizada es no depender de índices en la colecciones y utilizar ciertos métodos no indexados como el .previus() que poseen algunas colecciones.

Mediator

2011-06-10T07:48:00.000-03:00

Un Mediator es un patrón de diseño que define un objeto que hace de procesador central, coordinando las relaciones entre sus asociados o participantes. Permite la interacción de varios objetos, sin generar acoples fuertes en esas relaciones. Todos los objetos se comunican con un mediador y es éste quién realiza la comunicación con el resto.

Cuando muchos objetos interactúan con otros objetos, se puede formar una estructura muy compleja, con muchas conexiones entre distintos objetos. En un caso extremo cada objeto puede conocer a todos los demás objetos. Para evitar esto, el patrón Mediator, encapsula el comportamiento de todo un conjunto de objetos en un solo objeto.

Usar el patrón Mediator cuando:

Un conjunto grande de objetos se comunica de una forma bien definida, pero compleja.
Reutilizar un objeto se hace difícil por que se relaciona con muchos objetos.
Las clases son difíciles de reutilizar porque su función básica esta entrelazada con relaciones de dependencia.

Un ejemplo real que se puede comparar con este patrón es un framework que se llama Struts. Struts posee un clase que hace de Mediadora que se llama ActionServlet. Esta clase lee un archivo de configuración (el struts-config.xml) para ayudarse con la mediación, pero lo importante es que se encarga de comunicar el flujo de información de todos los componentes web de una aplicación. Si no utilizamos Struts, entonces cada página debe saber hacia donde debe dirigir el flujo y el mantenimiento de dicha aplicación puede resultar complicado, especialmente si la aplicación es muy grande.
En cambio, si todas las páginas se comunican con un mediador, entonces la aplicación es mucho más robusta: con cambiar un atributo del mediador todo sigue funcionando igual.
Como conclusión podemos afirmar que este patrón debe ser utilizado en casos donde convenga utilizar un procesador central, en vez de que cada objeto tenga que conocer la implementación de otro. Imaginemos un aeropuerto: que pasaría si no tuviese una torre de control y todos los aviones que deban aterrizar/despegar se tienen que poner todos de acuerdo para hacerlo. Además cada avión debe conocer detalles de otros aviones (velocidad de despegue, nafta que le queda a cada uno que quiera aterrizar, etc).
Para evitar esto se utiliza un torre de control que sincroniza el funcionamiento de un aeropuerto. Esta torre de control se puede ver como un mediador entre aviones.

Diagrama UML

Mediator: define una interface para comunicarse con los objetos colegas.
MediatorConcreto: implementa la interface y define como los colegas se comunican entre ellos. Además los conoce y mantiene, con lo cual hace de procesador central de todos ellos.
Colleague: define el comportamiento que debe implementar cada colega para poder comunicarse el mediador de una manera estandarizada para todos.
ColleagueConcreto: cada colega conoce su mediador, y lo usa para comunicarse con otros colegas.
Los colegas envían y reciben requerimientos de un objeto mediador. El mediador gestiona cada mensaje y se lo comunica a otro colega si fuese necesario.

Ejemplo

Nuestro ejemplo será un chat: donde habrá usuarios que se comunicaran entre sí en un salón de chat. Para ellos se define una interface llamada IUsuarioChat que todos los objetos que quieran participar de un chat deberán implementar. La clase Ususario representa un usuario que quiera chatear.

Veamos como funciona:

Consecuencias

Desacopla a los colegas: el patrón Mediator promueve bajar el acoplamiento entre colegas. Se puede variar y reusar colegas y mediadores independiéntemente.
Simplifica la comunicación entre objetos: los objetos que se comunican de la forma "muchos a muchos" puede ser remplazada por una forma "uno a muchos" que es menos compleja y más elegante. Además esta forma de comunicación es más fácil de entender. Es decir, un objeto no necesita conocer a todos los objetos, tan sólo a un mediador.
Clarifica como los objetos se relacionan en un sistema.
Centraliza el control: el mediador es el que se encarga de comunicar a los colegas, este puede ser muy complejo, difícil de entender y modificar. Para que quién conoce el framework Struts, es muy similar al concepto del archivo struts-config.xml: centraliza el funcionamiento de la aplicación, aunque si llega a ser una aplicación muy compleja el archivo se vuelve un tanto complicado de entender y seguir.

Temas a tener en cuenta.

Sabemos que el patrón Mediator introduce un objeto para mediar la comunicación entre "colegas". Algunas veces el objeto Mediador implementa operaciones simplemente para enviarlas o otros objetos; otras veces pasa una referencia a él mismo y por consiguiente utiliza la verdadera delegación.
Entre los colegas puede existir dos tipos de dependencias:

Un tipo de dependencia requiere un objeto para conseguir la aprobación de otros objetos antes de hacer tipos específicos de cambios de estado.
El otro tipo de dependencia requiere un objeto para notificar a otros objetos después de que este ha hecho un tipo específico de cambios de estado.

Ambos tipos de dependencias son manejadas de un modo similar. Las instancias de Colega1, Colega2, .... están asociadas con un objeto mediator. Cuando ellos quieren conseguir la aprobación anterior para un cambio de estado, llaman a un método del objeto Mediator. El método del objeto Mediator realiza cuidadoso el resto.
Pero hay que tener en cuenta lo siguiente con respecto al mediador: Poner toda la dependencia de la lógica para un conjunto de objetos relacionados en un lugar puede hacer incomprensible la dependencia lógica fácilmente. Si la clase Mediator llega a ser demasiado grande, entonces dividirlo en piezas más pequeñas puede hacerlo más comprensible.

Iterator

2011-06-09T22:48:00.000-03:00

Provee un mecanismo estándar para acceder secuencialmente a los elementos de una colección; define una interface que declara métodos para acceder secuencialmente a los objetos de una colección. Una clase accede a una colección a través de dicha interface.

La motivación de este patrón reside en la gran diversidad de colecciones y algoritmos que existe hoy en día para recorrer una colección. Lo que se busca es acceder a los contenidos de los objetos incluidos sin exponer su estructura.
Podemos decir que este patrón nace para poder soportar diversas formas de recorrer objetos y para ofrecer una interfaz uniforme para recorrer distintos tipos de estructuras de agregación.

Se utiliza cuando:

Una clase necesita acceder al contenido de una colección sin llegar a ser dependiente de la clase que es utilizada para implementar la colección, es decir sin tener que exponer su representación interna.
Una clase necesita un modo uniforme de acceder al contenido de varias colecciones.
Cuando se necesita soportar múltiples recorridos de una colección.

Este patrón debe ser utilizado cuando se requiera una forma estándar de recorrer una colección, es decir, cuando no es necesario que un cliente sepa la estructura interna de una clase. Un cliente no siempre necesita saber si debe recorrer un List o un Set o un Queue y, menos que menos, que clase concreta esta recorriendo.
El ejemplo más importante de este patrón esta en el Java Framework Collection: las colecciones en el paquete java.util siguen el patrón Iterator. La causa de porque Java utiliza este patrón es muy simple. En la versión 1.6 Java posee alrededor de 50 colecciones. Y cada una de ellas es un caso de estudio: cada una funciona de manera distinta a la otra, con algoritmos muy distintos, por ejemplo: hay trees, binary trees, arrays, ring buffers, hashes, hash maps, array lists, sets, etc. Si nosotros como clientes de Java tendríamos que aprender como se debe recorrer una colección en Java, sería realmente muy molesto. Pero si todas las colecciones se recorren de la misma forma estándar, y además, cada colección sabe cual es la mejor manera de recorrerla, entonces sería un gran avance que, de hecho, lo es.

Diagrama UML

Agregado/Aggregate: define una interfaz para crear un objeto iterator.
Iterator: define la interfaz para acceder y recorrer los elementos de un agregado.
IteradorConcreto: implementa la interfaz del iterador y guarda la posición actual del recorrido en cada momento.
AgregadoConcreto: implementa la interfaz de creación de iteradores devolviendo una instancia del iterador concreto apropiado.

Cliente: solicita recorrer una colección y lo hace siguiendo los métodos otorgados por la interfaz Iterator.

Ejemplo

Vamos a realizar un ejemplo muy sencillo: una división o sucursal que contiene empleados. Para ello internamente implemento un Array pero el cliente no tiene porque saberlo.

Y ahora crearemos un Iterator para recorrer los empleados de la división. El método iterator devuelve un objeto DivisionIterator. Veamos como funciona:

Si ha recorrido alguna colección mediante un objeto Iterator estará familiarizado con el siguiente código:

Consecuencias

Es posible acceder a una colección de objetos sin conocer el código de los objetos.
Utilizando varios objetos Iterator, es simple tener y manejar varios recorridos al mismo tiempo.
Es posible para una clase Colecction proporcionar diferentes tipos de objetos Iterator que recorran la colección en diferentes modos. Por ejemplo, una clase Colecction que mantiene una asociación entre la clave de los objetos y el valor de los objetos podría tener diferentes métodos para crear Iterators que recorran sólo la clave de los objetos y crear Iterators que recorran sólo el valor de los objetos.
Las clases Iterator simplifican el código de las colecciones, ya que el código de los recorridos se encuentra en los Iterators y no en las colecciones.

Interpreter

2011-06-09T14:40:00.000-03:00

Este patrón busca representar un lenguaje mediante reglas gramáticas. Para ello define estas reglas gramáticas y como interpretarlas. Utiliza una clase para representar una regla gramática.
Si un tipo particular de problema se presenta frecuentemente, puede ser provechoso expresar los diferentes casos del problema como sentencias de un lenguaje simple. Se puede, entonces, construir un intérprete que resuelva el problema interpretando dichas sentencias.

Cuando Utilizarlo.

Este patrón se debe utilizar cuando hay un lenguaje que interpretar y se puede interpretar sus palabras como árboles sintácticos abstractos. Para ello, la gramática debe ser simple.
Difícilmente el desarrollador utilice este patrón en algún momento de su vida, lo que no quita que no sea un patrón utilizado. La situación ideal que se debe considerar para aplicar este patrón es que exista un lenguaje sencillo que pueda interpretarse con palabras. El ejemplo más claro es JAVA: este lenguaje permite escribir en archivos .java entendibles por humanos y luego este archivo es compilado e interpretado para que pueda ejecutar sentencias entendibles por una máquina.

Diagrama UML

AbstractExpression: declara una interfaz para la ejecución de una operación.
TerminalExpression: implementa una operación asociada con los símbolos terminales de la gramática
NonterminalExpression: implementa una operación de interpretación asociada con los símbolos no terminales de la gramática.
Context: contiene información global para el interprete.
Client: construye un árbol sintáctico abstracto que representa una sentencia particular en el lenguaje que la gramática define. El cliente construye una expresión

Ejemplo

Luego de leer el ejemplo, se entenderá porque este patrón sólo funciona con lenguajes con reglas sencillas... de hecho este ejemplo no lo pensé yo, lo vi en una página hace muchos años y no recuerdo cual era para colocar la fuente...
Veamos un ejemplo donde se utiliza el interpreter para interpretar los números romanos mediante ciertas reglas matemáticas y convertirlo en un número de escala decimal.

Primero creamos el contexto: esto es una clase donde tiene un input (un String ya que los numeros romanos son letras) y un output (un int ya que la respuesta será un número).

Lo que sigue a continuación es puro algoritmo: si pensamos como funcionan los numeros romanos vamos a encontrar un patrón (pongo como ejemplo con escala de 10 pero es lo mismo para el resto de las escalas): de 1 a 3 es el mismo signo I (ocupa 1 espacio por vez), el 4 es una combinacion del 5 con el 1.... IV (ocupan dos lugares), el 5 es V (ocupa 1 lugar) y el próximo signo que hace combinación es el 9 (IX) que utiliza un signo de una escala mayor.

Una vez que entendemos el algoritmo y logramos la interpretación correcta, agregar una nueva expresión es muy sencillo. Aca corte en 1000 porque ya se entiende la idea.

Veremos esto en práctica:

Consecuencias
Se puede destacar las siguientes ventajas:

Facilidad para cambiar la gramática, mediante herencia, dado que las diferentes reglas se representan con objetos.
Facilidad para implementar la gramática, dado que las implementaciones de las clases nodo del árbol sintáctico son similares, pudiendo usarse para ello generadores automáticos de código.
Facilidad para introducir nuevas formas de “interpretar” las expresiones en la gramática.

Y las siguientes desventajas:

Limitación en el tipo de gramática: si no es simple, es casi imposible implementarlo.
No es conveniente utilizarlo si la eficiencia es un punto clave.

Patrones de Diseño de GOF

2011-06-09T12:21:00.001-03:00

Los patrones de diseño son una pieza fundamental en el desarrollo del software. En mi opinión un desarrollador senior debería conocerlos. No todos, pero si los más importantes. Al ser algo estándar, permiten hablar un lenguaje común entre un equipo de desarrollo; por ende, si un junior también los conoce puede ser muy beneficioso, ya que estaría hablando en el mismo lenguaje de una persona con más experiencia. Empecemos por explicar el concepto de un patrón:

“Un patrón describe un problema el cual ocurre una y otra vez en nuestro ambiente, y además describen el núcleo de la solución a tal problema, en tal una manera que puedes usar esta solución millones de veces, sin hacer lo mismo dos veces.” [Alexander et al.].
Aunque Alexander se refería a patrones en ciudades y edificios, lo que dice también es válido para patrones de diseño orientados a objetos.

Los patrones de diseño tratan los problemas del diseño de software que se repiten y que se presentan en situaciones particulares, con el fin de proponer soluciones a ellas. Son soluciones exitosas a problemas comunes.

Estas soluciones han ido evolucionando a través del tiempo. Existen muchas formas de implementar patrones de diseño. Los detalles de las implementaciones se llaman estrategias.
En resumen, son soluciones simples y elegantes a problemas específicos del diseño de software orientado a objetos.

Un poco de Historia

En 1994 se publicó el libro "Design Patterns: Elements of Reusable Object Oriented Software" escrito por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. Ellos recopilaron y documentaron 23 patrones de diseño aplicados usualmente por expertos diseñadores de software orientado a objetos. Ellos no fueron los únicos que inventaron los patrones, pero la idea de patrones de diseño comenzó a tomar fuerza luego de la publicación de dicho libro.

Que es gof.

Los ahora famosos Gang of Four (GoF, que en español es la pandilla de los cuatro) formada por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. Son los autores del famoso libro "Design Patterns: Elements of Reusable Object Oriented Software".

Aquí una breve reseña de los autores:

Erich Gamma, informático suizo, es actualmente el director del centro tecnológico OTI en Zúrich y lidera el desarrollo de la plataforma Eclipse. Fue el creador de JUnit, junto a Kent Beck.

Richard Helm trabaja actualmente con The Boston Consulting Group, donde se desempeña como consultor de estrategias de IT aplicadas al mundo de los negocios.
Su carrera abarca la investigación de distintas tecnologías, desarrollo de productos, integración de sistemas y consultoría de IT. Antes de incorporarse a BCG, Richard trabajó en IBM: comenzó su carrera como científico investigador en "IBM Thomas J. Watson Research Center" en Nueva York. Es una autoridad internacional en arquitectura y diseño de software.

Ralph E. Johnson es profesor asociado en la Universidad de Illinois, en donde tiene a su cargo el Departamento de Ciencias de la Computación. Co-autor del famoso libro de Gof y pionero de la comunidad de Smalltalk, lidera el UIUC patterns/Software Architecture Group.

John Vlissides (1961-2005) era ingeniero eléctrico y se desempeñaba como consultor de la Universidad de Standford. Autor de muchos libros, desde 1991 trabajó como investigador en el "IBM T.J. Watson Research Center".

Cuando utilizar los patrones de diseño.

Como analistas y programadores vamos desarrollando a diario nuestras habilidades para resolver problemas usuales que se presentan en el desarrollo del software. Por cada problema que se nos presenta pensamos distintas formas de resolverlo, incluyendo soluciones exitosas que ya hemos usado anteriormente en problemas similares.

Antes de comenzar nuestro diseño, deberíamos realizar un estudio meticuloso del problema en el que nos encontramos y explorarlo en busca de patrones que hayan sido utilizados previamente con éxito. Estos patrones nos ayudarán a que nuestro proyecto evolucione mucho más rápidamente.

Cuando no utilizarlos.

Si hay una sensación que describa lo que puede sentir un desarrollador o diseñador después de conocer los patrones de diseño esa podría ser la euforia. Esta euforia viene producida por haber encontrado un mecanismo que convierte lo que era una labor artesana y tediosa, en un proceso sólido y basado en estándares, mundialmente conocido y con probado éxito.

Después de recién iniciarse en los patrones, probablemente el paso siguiente que tomará será emprender el rediseño de algunos proyectos aún vigentes y que intente aplicar todas las maravillosas técnicas que ha aprendido para que así estos proyectos se aprovechen de todos los beneficios inherentes al uso de patrones de diseño.

Esto termina en intentar que se aplique estos patrones en toda situación donde sea posible, aún en aquellas donde no deba aplicarse.

Donde utilizarlos.

No es obligatorio utilizar los patrones siempre, sólo en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. Abusar o forzar el uso de los patrones es un error muy común.

Antes de abordar un proyecto con patrones se debe analizar minuciosamente qué patrones nos pueden ser útiles, cuáles son las relaciones entre los diferentes componentes de nuestro sistema, cómo podemos relacionar los patrones entre sí de modo que formen una estructura sólida, cuáles son los patrones que refleja nuestro dominio, etc. Esta tarea obviamente es mucho más compleja que el mero hecho de ponerse a codificar patrones "porque sí".

Beneficios.

Proporcionan elementos reusables en el diseño de sistemas software, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.
Efectividad comprobada en la resolución de problemas similares en ocasiones anteriores.
Formalizan un vocabulario común entre diseñadores.
Estandarizan el diseño, lo que beneficia notablemente a los desarrolladores.
Facilitan el aprendizaje de las nuevas generaciones de diseñadores y desarrolladores utilizando conocimiento ya existente.

Tipos de patrones.

Verán en casi todas las bibliogafrías que hay una clasificación de tipos de patrones. Los patrones tienen dos tipos de clasificaciones:

1) Clasificación según su propósito

Creacionales: definen la mejor manera en que un objeto es instanciado. El objetivo de estos patrones es de abstraer el proceso de instanciación y ocultar los detalles de cómo los objetos son creados o inicializados.
De Comportamiento: permiten definir la comunicación entre los objetos del sistema y el flujo de la información entre los mismos.
Estructurales: permiten crear grupos de objetos para ayudarnos a realizar tareas complejas.

2) Clasificación según alcance

De clase: se basados en la herencia de clases.
De objeto: se basan en la utilización dinámica de objetos.

		Propósito
		De Creación	Estructural	De Comportamiento
Alcance	Clase	Factory Method	Adapter	Interpreter
				Template Method
	Objeto	Abstract Factory	Adapter	Chain of Responsability
		Builder	Bridge	Command
		Prototype	Composite	Iterator
		Singleton	Decorator	Mediator
			Facade	Memento
			Flyweight	Observer
			Proxy	State
				Strategy
				Visitor

Por último...

Cuando quise aprender a utilizar los patrones de diseño me encontré con una pobre documentación en la web: vagos ejemplos; lenguajes que no conocía, indioma inglés y casos mal explicados. Esto me llevo a escribir un manual de patrones de diseño que hoy en día se usa en un instituto educativo para dictar un curso sobre dichos patrones. Por esta razón, hoy he adaptado y modificado este libro para publicar dichos ejemplos en el blog.
Tengo que dejar algo bien en claro antes de abordar con los patrones en sí. Daré ejemplos de cada uno de ellos, pero esto no quiere decir que es la única forma de hacerlo. Los patrones pueden adaptarse a nuestras necesidades: no lo tomen como algo rígido. Por ejemplo, si se necesita adaptar un poco un patrón para que me pueda ayudar en una solución, que así sea.

Command

2011-06-07T19:55:00.002-03:00

Encapsula un mensaje como un objeto. Especifica una forma simple de separar la ejecución de un comando, del entorno que generó dicho comando. Permite solicitar una operación a un objeto sin conocer el contenido ni el receptor real de la misma. Si bien estas definiciones parecen un tanto ambigüas, sería oportuno volver a leerlas luego de entender el ejemplo.

Este patrón suele establecer en escenarios donde se necesite encapsular una petición dentro de un objeto, permitiendo parametrizar a los clientes con distintas peticiones, encolarlas, guardarlas en un registro de sucesos o implementar un mecanismo de deshacer/repetir.

Se debe usar cuando:

Se necesiten colas o registros de mensajes.
Se deba tener la posibilidad de deshacer las operaciones realizadas.
Se necesite uniformidad al invocar las acciones.
Se quiera facilitar la parametrización de las acciones a realizar.
Se quiera independizar el momento de petición del de ejecución.
El parámetro de una orden puede ser otra orden a ejecutar.
Se busque desarrollar sistemas utilizando órdenes de alto nivel que se construyen con operaciones sencillas (primitivas).
Se necesite sencillez al extender el sistema con nuevas acciones.

Lo que permite el patrón Command es desacoplar al objeto que invoca a una operación de aquél que tiene el conocimiento necesario para realizarla. Esto nos otorga muchísima flexibilidad: podemos hacer, por ejemplo, que una aplicación ejecute tanto un elemento de menú como un botón para hacer una determinada acción. Además, podemos cambiar dinámicamente los objetos Command.

Diagrama UML

Command: declara una interfaz para ejecutar una operación.
CommandConcreto: define un enlace entre un objeto “Receiver” y una acción. Implementa el método execute invocando la(s) correspondiente(s) operación(es) del “Receiver”.
Cliente: crea un objeto “CommandConcreto” y establece su receptor.
Invoker: le pide a la orden que ejecute la petición.
Receiver: sabe como llevar a cabo las operaciones asociadas a una petición. Cualquier clase puede hacer actuar como receptor.

El cliente crea un objeto “CommandConcreto” y especifica su receptor. Un objeto “Invoker” almacena el objeto “CommandConcreto”. El invocador envía una petición llamando al método execute sobre la orden.
El objeto “CommandConcreto”, invoca operaciones de su receptor para llevar a cabo la petición.

Ejemplo

Escenario: una empresa maneja varios servidores y cada uno de ellos deben correr diversos procesos, como apagarse, prenderse, etc. Cada uno de estos procesos, a su vez, implican pequeños pasos como, por ejemplo, realizar una conexión a dicho servidor, guardar los datos en un log, etc.
Dado que cada servidor tiene su propia lógica para cada operación, se decidió crear una interfaz llamada IServer que deben implementar los servidores:

Obviamente en un caso real los métodos tendrían el algoritmo necesario para realizar tales operaciones. Hemos simplificado estos algoritmos y en su lugar realizamos una salida por consola en cada método.
Hasta aquí nada nuevo, sólo clases que implementan una interfaz y le dan inteligencia al método. Comenzaremos con el Command:

Ahora realizaremos un invocador, es decir, una clase que simplemente llame al método execute:

Veamos como funciona el ejemplo:

Consecuencias

Command desacoplado: el objeto que invoca la operación de aquél que sabe como realizarla.
Las órdenes son objetos manipulados y extendidos de forma natural.
Se pueden ensamblar órdenes en una orden compuesta.
Facilidad de adición de nuevos objetos Command.

Chain of Responsibility

2011-06-05T11:33:00.001-03:00

Permite establecer una cadena de objetos receptores a través de los cuales se pasa una petición formulada por un objeto emisor. La idea es que cualquiera de los receptores pueden responder a la petición en función de un criterio establecido. Encadena los objetos receptores y pasa la petición a través de la cadena hasta que es procesada por algún objeto.
Busca evitar un montón de if – else largos y complejos en nuestro código, pero sobre todas las cosas busca evitar que el cliente necesite conocer toda nuestra estructura jeráquica y que rol cumple cada integrante de nuestra estructura.
En múltiples ocasiones, un cliente necesita que se realice una función, pero o no conoce al servidor concreto de esa función o es conveniente que no lo conozca para evitar un gran acoplamiento entre ambos.

Se utiliza cuando:

Las peticiones emitidas por un objeto deben ser atendidas por distintos objetos receptores.
No se sabe a priori cual es el objeto que me puede resolver el problema.
Cuando un pedido debe ser manejado por varios objetos.
El conjunto de objetos que pueden tratar una petición debería ser especificado dinámicamente.

La motivación detrás de este patrón es crear un sistema que pueda servir a diversas solicitudes de manera jerárquica. En otras palabras, si un objeto que es parte de un sistema no sabe cómo responder a una solicitud, la pasa a lo largo del árbol de objetos. Como el nombre lo implica, cada objeto de dicho árbol puede tomar la responsabilidad y atender la solicitud.
Un ejemplo típico podría ser el lanzar un trabajo de impresión. El cliente no sabe siquiera qué impresoras están instaladas en el sistema, símplemente lanza el trabajo a la cadena de objetos que representan a las impresoras. Cada uno de ellos lo deja pasar, hasta que alguno, finalmente lo ejecuta.
Hay un desacoplamiento evidente entre el objeto que lanza el trabajo (el cliente) y el que lo realiza (impresora).

Diagrama UML

Handler: define una interfaz para tratar las peticiones. Implementa el enlace al sucesor.
HandlerConcreto: trata las peticiones de las que es responsable. Si puede manejar la petición, lo hace, en caso contrario la reenvía a su sucesor.
Cliente: inicializa la petición. Conoce a un gestor que es el que lanza la petición a la cadena hasta que
alguien la recoge.

Ejemplo

Escenario: estamos realizando el software para un banco y uno de los puntos más importantes es saber quién puede aprobar un crédito. Por lo tanto el banco define las siguientes reglas de negocio:

Si el monto no supera los $ 10.000 entonces el ejecutivo de cuenta pueda aprobar el préstamo.
Si el monto esta entre los $10.000 y $50.000 entonces la persona indicada para realizar la aprobación es el líder inmediato de dicho ejecutivo.
Si el monto se encuentra entre $ 50.000 y $100.000 entonces es el Gerente quién debe realizar dicha aprobación.
Por montos superiores a los $100.000 entonces la aprobación la realizará el Director.

Para este caso se ha decidido realizar un patrón Chain of Responsibility. Se decide crear una interface llamada IAprobador que debe implementar toda clase que pertenezca a nuestra cadena de responsabilidades.

En nuestro caso será el banco quién organice la cadena, pero seguramente en la práctica utilizaremos un factory. Para el cliente el banco será suu punto de entrada.

Y, desde el punto de vista del cliente, verán que es muy sencillo:

Consecuencias

Reduce el acoplamiento.
Añade flexibilidad para asignar responsabilidades a objetos.
No se garantiza la recepción.