The second talk of day 1 I attended, was a mix of NoSQL and Cloud Computing. And more to the point, how to integrate these technologies into Spring Enterprise Applications. The NoSQL part focussed on two popular NoSQL databases, Redis and MongoDB and was done by Chris Richardson, while the cloud part focussed on vmware’s Cloud Foundry. This part was presented by Josh Long.
With a little background to the rise of cloud services and why we need them (Big Data, New Clients, Social Networking to name but a few of the reasons), Cloud Foundry is introduced. Cloud Foundry is a so called Platform As A Service (PAAS). A PAAS provider has the benefits of eg. ease of deployment, application management and can be easily scaled up or down.
Cloud Foundry gives you:
- a tomcat server;
- a choice of programming languages like Java, Scala and Groovy;
- a choice of application services like RabbitMQ, MongoDB, Redis and MySQL;
- a choice of frameworks, like Grails and Ruby on Rails
- a command line interface (vmc);
- an application lifecycle API (lets you eg. start or stop your deployed applications);
- integration with the SpringSource Tool Suite (an IDE based on Eclipse for Spring developers).
Cloud Foundry is also avalilable as a free, so called Micro Cloud, that makes it easy for developers to do some experimenting.
Josh showed a demo of how to deploy applications to Cloudfoundry via the command line interface. For example, with the vmc push command you can deploy web applications to Cloud Foundry’s Tomcat Server and the vmc update command is used for updating those apps (only the changed parts in the source code are transfered to the cloud). With the vmc create-service command you can create application services on Cloud Foundry, like a mysql database. In another demo Josh showed that all this can also be accomplished graphically by using the SpringSource Tool Suite.
Cloud Foundry in Spring
The setup for integrating with Cloud Foundry services is done in the usual Spring style. You declare all the services as Spring beans in a Spring configuration file. For Cloud Foundry services configuration the cloud namespace is available. You need to add a Maven dependency to your pom file – cloudfoundry-runtime – to gain access to this namespace.
- <cloud:data-source>: A regular RDBMS dataservice available in CloudFoundry (MySQL database), can be injected into regular Spring beans;
- <cloud:redis-connection-factory>: Redis application service;
- <cloud:mongo>: MongDB application service.
You can also make use of a very cool feature called auto-reconfiguration. This lets you define a DataSource bean against a local MySQL database or a MongoDbFactory bean against a local MongoDB installation. Once you deploy an application which uses these beans to Cloud Foundry, auto-reconfiguration kicks in and reconfigures those beans to make use of a corresponding Cloud Foundry service.
Furthermore, as of Spring 3.1, you can make use of so-called profiles. You can make a profile with specific service configurations for example for local, testing and cloud deployment. So, when you’re developing you use the local profile and when you’re ready for deployment into the cloud you can switch to the cloud profile.
NoSQL databases are an alternative for traditional relational databases.RDBMS databases like MySQL, Oracle, etc. have been around for quite a while. Chris mentions a couple of problems related to RDBMS databases:
- ORM mismatch, it’s not always easy to map a relational schema to an object oriented model;
- Difficult to handle semistructured data;
- Difficult to scale;
- Poor performance for some use cases.
These are some of the problems that led to the rise of NoSQL databases in the past. NoSQL databases offer high performance, high scalability, a richer datamodel and are schema less. This comes at a price. Chris mentions a few of the drawbacks of NoSQL:
- Limited support for transactions;
- Relaxed consistency;
- Unconstrained data.
As you can see, it depends on the use case, which database to choose. For most use cases RDBMS database are a good choice, but for some specific use cases, NoSQL databases are a way better alternative, eg. when performance is much more important than highly consistent data.
After this introductory talk of NoSQL, two of the more popular NoSQL databases are discussed, Redis and MongoDB. They are both available in Cloud Foundry and can be easily integrated into Spring applications via Spring Templates.
Redis is a so called advanced Key-Value Store. It’s very fast, persistence is optional and it has support for transactions by the use of optimistic locking. It also supports Master-slave replication. Some of it’s use cases are as a storage for session state or for high performance queries.
MongoDB is a so called document-oriented database. It uses JSON-style documents for storage and retrieval. It’s fast, has a rich query layer and is highly available an scalable. MongoDB uses query by example.
NoSQL in Spring
Spring offers a lot of goodies for integration with a NoSQL database:
- Template classes
- Auto-generation of repositories
- Java <-> NoSQL mapping
- Cross-Store persistence
- Roo Support (Spring Roo is a framework for generating Spring apps)
For both MongoDB and Redis a Spring Template is available. Spring Templates are java classes that perform the role of an abstraction layer on top of a resource. Templates take away a lot of boilerplate code, transform checked into runtime exceptions and transform underlying errors into common exceptions (eg. when you use the JdbcTemplate, your exception will be same for a unique key violation regardless of whether you use a mysql database, or an Oracle database).
For Redis, the RedisTemplate, is available. Spring also offers Redis-backed collections, like the DefaultRedisSet Set. And there is also caching support via the @Cacheable annotation.
For MongoDB, there is a MongoTemplate available. For configuration purposes the mongo namespace is available. Furthermore annotations are available to do Java <-> NoSQL mapping for MongoDB: @Document, @Id, @Indexed, etc. MongoDB can also leverage the power of the QueryDSL project. This project provides type-safe composeable queries.
AMQP is a protocol for message-oriented middleware. Messaging can be used to decouple systems. AMQP is based on open standards, has clustering support, supports transactions, flow control and error handling, to name but a few of it’s features.
RabbitMQ is an implementation of AMQP and is available as an application service in Cloud Foundry. Configuration of RabbitMQ in Cloud Foundry can be done via the following Spring Bean:
Spring also has two template classes available for use:
This talk clearly proved that Cloud Foundry integrates smoothly with Spring applications. So when you’re already building your enterprise applications with Spring, you should definitely consider Cloud Foundry as your PAAS of choice. Cloud Foundry lacks a JEE Server, so for real JEE applications it’s less suitable. For most web applications though, a TomCat server will be sufficient. The choices of programming languages and frameworks in Cloud Foundry should suit a lot of web developers. It’s also great that they added support for an RDBMS database as well as some popular NoSQL databases. And last but not least, the Micro Cloud feature should be a great way to do some experimenting and gain a good insight on what the product has to offer. I for one can’t wait to play a little with it.
The NoSQL integration in Spring is also neatly done. I like the way Spring abstracts all external resources by way of Templates. It’s uniformly done, reliefs the developer of a lot of boilerplate coding and provides a unified way of dealing with exceptions. A lot of NoSQL databases are supported this way. Also the Java <-> NoSQL mapping available for MongoDB should appeal to a lot of programmers familiar with JPA providers like Hibernate.