Grid vs. Spaces; Oracle Coherence vs. GigaSpaces

Ambos, Oracle Coherence y GigaSpaces, son dos de los productos más utilizados en el mundo de las finanzas, en especial en el ámbito de trading (equities, derivatives, funds, fx, ...). Ambos comparten la idea de poner los datos lo más cerca de la aplicación de manera que sea posible para minimizar la latencia asociada a la obtención de los mismos (i.e. acceder a base de datos, a un servicio remoto, etc.). Sin embargo, el transfondo e historia de ambos productos es diferente y merece la pena echarles un vistazo.

Por una parte Oracle Coherence es un producto que creó la compañía Tangosol adquirida por Oracle este mismo año. La compañía fue fundada en el 2000 por Cameron Purdy, alguien que desde siempre ha sido un asiduo participante en los foros más conocidos del sector, y que en su momento localizó una necesidad en el mundo de J2EE ante los problemas técnicos que presentaban tecnologías como EJB. En su momento fue también el principal impulsor del JSR-107 (JCache), JSR que siempre ha estado demasiado parado (muchos culpan al propio Cameron).

Por otra parte, GigaSpaces ha seguido siempre un camino paralelo y muy similar. Fundada tambiéen en el año 2000 por Nati Shalom se trata de un producto que inicialmente estaba orientado al mundo de Jini, posteriormente JavaSpaces; mundo en el que por cierto se ha convertido en una referencia.

Oracle Coherence es lo que ellos denominan memory "distributed data grid solution", vamos que es una cache distribuida. Estas caches se "pegan" a nuestros componentes y les sirven de cache de modo que no sea necesario acceder a una base de datos o cualquier otro servicio para obtener estos datos. Por detrás existe un complejo protocolo de comunicación para asegurarse que los datos siempre permanecen consistentes, que todo está sincronizado, y que siempre existen copias disponibles para garantizar la disponibilidad. Todo esto sin afectar realmente a la arquitectura de nuestras aplicaciones.

Por su parte, GigaSpaces sigue un camino mucho más rádical y propone que el tradicional modelo basado en capas es erróneo y no apto para sistemas escalables. El problema que plantean es que a la hora de escalar una aplicación empresarial es necesario escalar todas las capas (web, appserver, base de datos, ...), lo que se hace muy complicado. En su lugar proponen el despliegue de aplicaciones en lo que se llaman espacios. VMs dedicadas que contienen todas las capas en una misma VM y que no requieren ningún tipo de acceso externo (salvo quizás para persistir asíncronamente los datos). De este modo se minimiza enormemente la latencia y se consigue una escalabilidad lineal simplemente desplegando nuevas VMs. Para garantizar la disponibilidad se despliegan diferentes espacios y se sincronizan los datos entre los mismos.

Todo esto que comento aquí viene mucho mejor explicado en dos presentaciones que Niti Shalom y Cameron Purdy realizaron en la Spring One 2007. Ambas presentaciones están disponibles en Parleys y dejo los enlaces a continuación. Son realmente recomendable si os gustan estos temas.

Coherence an Introduction
Scalable as Google Simple as Spring (quizás un título no muy apropiado para la charla de GigaSpaces).