The short answer is YES, but first, let’s take a quick look at how Play works because there are some important limitations to this chimera, and understanding the constraints will help you decide when and where to do this kind of integration. In a future post I’ll show how to make this work in a couple of different ways.

Look Ma, No Servlets!

The Play framework has conceptual differences and similarities with other Java webapp frameworks but it differs greatly from all others in one thing: it doesn’t use the Java Servlet API and therefore doesn’t run in a Servlet container. Guillaume Bort (Play’s creator and lead developer) explains his reasons for dumping Servlets here. It basically boils down to Development Speed and Scalability.

On one hand, by dropping the whole Java Servlet apparatus he was able to create an environment that detects code changes, dynamically (re)compiles source files and hot-swaps the new bytecode into the running JVM, to the point where it feels like developing in a dynamic language like Ruby or Python, while maintaining all the goodness of a compiled, type-safe language like Java or Scala. You can literally edit your code, hit reload on your browser and see the change. Compare that to the typical edit-build-deploy-restart cycle with traditional Java-based frameworks. If you don’t think that makes a difference for development you haven’t really tried it yet. To deploy it in production Play pre-compiles all the files and runs the app in an optimized, non-reloadable mode.

On the other hand, the Play framework generates stateless applications that can be easily deployed in load-balanced clusters. You can start as many Play app instances as you need and just do simple load balancing between them; no need for layer 7 juggling, server affinity, session failover, or any of that fun stuff. Web app scalability is a complex subject and I’m not suggesting that Play addresses all its challenges, but it helps you design your web tier so that it doesn’t become the bottleneck. To accomplish this it requires a mental adjustment as some concepts clash with paradigms we take for granted in a Servlet environment (i.e. storing state in the session scope). But having developed and scaled massively large web apps for the past 10 years I believe Play discourages just the right anti-patterns and pushes the correct share-nothing constructs to the dev cycle.

There is a lot more that Play does for you behind the scenes but I won’t cover all its features here. You can watch the intro video on the Play site for a quick teaser. There is no such thing as a perfect development framework but if you create web applications you should take a serious look at Play.

Play-Servlet Chimera

The scenario I described at the beginning echoes one in which I recently found myself. We have a large web application built with some plain old Servlets, some Spring MVC, JSPs, Velocity templates, a service layer, data access code, caching, etc. all glued together with a Spring application context. When we recently needed to add a new feature I really wanted to do it in Play, but I wasn’t sure if I could integrate it in a seamless way or at all.

How can you reconcile these two different and seemingly incompatible runtime environments in a single web application? The answer is, you don’t! It’s not necessary because they can both live under the same webapp without overlapping and here’s why.

Play manages the complete HTTP request-response cycle through its default Mina-based implementation (Netty and Grizzly can be installed as modules). Not only is a container not required, it is not recommended.

However, Lee Breisacher wrote a Servlet wrapper that basically encapsulates a full Play application in a standard Servlet. To try it, you can export the Play application with a single command (play war <playapp_dir> -o <war_dir>). You lose all the dynamic recompilation features of the framework this way, but it is a viable alternative for people with limited deployment options. The resulting file layout conforms to the Servlet WAR standard. All the framework files end up inside the WEB-INF directory and a standard web.xml file is generated with the minimum necessary definitions to manage the full URL space (/*). With this in mind, it was relatively straightforward to take it to the next level: complete integration.

The result is more akin to Frankenstein’s monster than I would have liked, but it works and provides a migration path for new feature development on an old application. It requires splicing the exported Play app with the existing webapp by merging the contents of their respective WEB-INF directories. In a future post I will illustrate how to do this in an automated way.

Obstacles Ahead

Although getting both apps to run together in one Servlet context is relatively easy, getting them to behave like a single, seamless application is much more challenging. The Play app doesn’t naturally have access to any of the data structures of the webapp. You’ll find you need to create a communication channel between the two camps if you want the user to be able to navigate back and forth between different sections of the app without disruption.

For a completely stateless app this is no big deal. You may need to duplicate some HTML templates and maybe find a way to share some caches to avoid having redundant, possibly inconsistent data. For stateful apps it’s a different story. You may find that traditionally simple things like sharing the logged-in user state across requests can take some developer brain power. But these are not insurmountable and once you solve them once you won’t need to solve them again.

One obvious candidate for the traffic cop role is a shared Spring application context. There’s even a Spring module for Play, but I haven’t used it yet so I can’t recommend a solution at this point.

Promising Future

So far, I’m loving the productivity I get with Play. It is still a relatively new player in the space and I’m sure I’ll encounter some bumps along the way, but the community is wonderful and the developers are very responsive. Although I initially hoped it would be easier to plug it into old code I’ve come to embrace its approach and happily accept the limitations.

I used to think that Grails was the holy grail (pun intended) of JVM-based web frameworks. It has a large, active community, tons of modules and Springsource/VMWare behind it. But after using Play I can hardly justify writing all my code in Groovy. With Play’s bytecode gymnastics even Java code in Play looks more compact than Grails’ equivalent. And I haven’t even mentioned Play’s future with the Scala module…it’s just cool. But that’s a subject for another post.

Chris Shorrock wrote a compact, pure Scala client library for Cassandra called Cascal. You can download a precompiled binary from GitHub but I chose to build the latest version myself. If you have Git and Maven already set up on your system you can just do:

$ git clone git://github.com/shorrockin/cascal.git
...
$ cd cascal
$ mvn package

After Maven is done building you’ll have a target directory. Add the main jar file (I got cascal-1.2-SNAPSHOT.jar) to the Build Path in Eclipse and make sure you have other Cassandra dependencies configured (thrift, commons-pool, slf4j, log4j, etc.) I then wrote a simple test object to perform the same functions as before and I think the resulting data access code is very clean and readable:

import com.shorrockin.cascal.utils.Conversions._
import com.shorrockin.cascal.session._

object CassandraCascalTester {
  def main(args : Array[String]) : Unit = {
    // Set up session pool
    val hosts  = Host("localhost", 9160, 250) :: Nil
    val params = new PoolParams(10, ExhaustionPolicy.Fail, 500L, 6, 2)
    val pool   = new SessionPool(hosts, params, Consistency.One)

    pool.borrow { session =>

      // Define column path
      val colPath = "Keyspace1" \ "Standard1" \ "key" \ "column-name"

      // insert
      session.insert(colPath \ "value")

      // read
      val col = session.get(colPath)
      System.out.println("Stored value: " + string(col.get.value))
    }
  }
}

As you can see, we don’t need to explicitly handle a try/catch block and Scala’s implicit type conversions take care of transforming strings to byte arrays and the directory-like column path syntax, all in a type-safe manner enforced by the compiler. For example, colPath will automatically become

Keyspace(value = Keyspace1) \ StandardColumnFamily(value = Standard1) \ StandardKey(value = key) \ Column(name = [B@6910fe28, value = null, time = 1272046381878)

and col will become

Some(Keyspace(value = Keyspace1) \ StandardColumnFamily(value = Standard1) \ StandardKey(value = key) \ Column(name = [B@30ec4a87, value = [B@6910fe28, time = 1272041137177))

Note that we do need to explicitly convert the retrieved value to a String because the basic get has no way of knowing what is stored in there. But Cascal has a solution for that too. Starting with version 1.1 Cascal includes a simple object mapping framework that can do the heavy lifting of populating objects from get and list results. I’ll explore this capability and its constraints in a future post.

The first time I checked the Client Options wiki page there were a couple of projects listed for the Scala language. I wasn’t convinced by any of the alternatives I looked at. Given that Cassandra is such a fast-moving target, I felt that the client library needs to have at least one committed developer (and some community momentum) behind it.

I took a quick look at scromium but I wasn’t convinced with the choice of different token separators. I then looked more deeply into scalandra but just couldn’t make it work with Cassandra 0.6-rc1. I was initially interested in the Akka option since I was already looking at Akka for it’s distributed actors but I was disappointed by its current implementation.

You can use Akka to access Cassandra via the Pluggable Persistence module. According to the documentation you can bypass the Akka STM and use it as a library; they call it the Cassandra Session API. After a lot of tinkering, building Thrift on MacOS X, installing MacPorts to get the missing pieces, etc. I still couldn’t get a simple test to run against Cassandra 0.6-rc1. I later noticed that even Akka developers were considering a shift to Hector, a Java-based library. Given this endorsement I decided to try it myself.

Hector is a thin wrapper over the Cassandra Thrift API. It basically makes it a bit more object-oriented and easy to use from Java.

It turns out that talking to Cassandra from Scala using Hector is very simple, albeit not very Scala-ish. I set up a basic Scala project in Eclipse and added the Hector libraries to the classpath. Then I modified ExampleClient.java and with Cassandra running on the default port it worked like a charm:

import me.prettyprint.cassandra.service.CassandraClientPoolFactory
import me.prettyprint.cassandra.utils.StringUtils._

import org.apache.cassandra.thrift.{Column, ColumnPath}

object CassandraScalaHectorTest {
  def main(args : Array[String]) : Unit = {
    val pool = CassandraClientPoolFactory.INSTANCE.get()
    // var client = pool.borrowClient(Array("cas1:9160", "cas2:9160")
    var client = pool.borrowClient(Array("localhost:9160"))

    try {
      val keyspace = client.getKeyspace("Keyspace1")
      val columnPath = new ColumnPath("Standard1").setColumn(bytes("column-name"))

      // insert
      keyspace.insert("key", columnPath, bytes("value"))

      // read
      val col = keyspace.getColumn("key", columnPath)
      System.out.println("Stored value: " + string(col.getValue()))

      // This line makes sure that even if the client had
      // failures and recovered, a correct
      // releaseClient is called, on the up to date client.
      client = keyspace.getClient()

    } finally {
      // return client to pool. do it in a finally block to
      // make sure it's executed
      pool.releaseClient(client)
    }
  }
}

As you can see this was only slightly modified so it compiles in Scala. It’s a little cleaner and less verbose than the Java version, mostly because of Scala’s type inference, which reduces the need to declare all types.

One of the things I don’t like is the explicit conversions to and from byte arrays. This is exactly the kind of boilerplate that can be done for you by using Scala’s implicit conversions and, overall, it’s just not very idiomatic Scala. Although I’m not a purist and I could live with this solution, I would prefer a cleaner approach. I still haven’t ruled out the possibility of wrapping Hector in Scala and providing a couple of conversions to make it work as expected.

Since I started working on this test the Cassandra Client Options wiki page was updated with a new Scala library called cascal. I haven’t had a chance to try it yet but it looks promising so I will evaluate that next.

Perhaps there’s a silver bullet I haven’t even heard off yet. I’m curious to know how many people are fronting Cassandra with a Scala app.