Build an AJAX / SOAP App in 15 minutes - Part 1.0...

Ever since I met Dan Diephouse at OSCON back in July, I knew there had to be a way to build something cool with XFire. I kept thinking that somehow some new SOAP specification would eventually need to be clustered, and so I kept pestering him to see if there was a good fit. Well nothing interesting materialized, until this past week when I realized that while the SOAP protocol is stateless (actually, to some extent new standards like WS-Addressing and WS-Conversation are changing that), the application which delivers the service is stateful.

Then I started noticing some noise around JSR-181 and building web services from POJOs using annotations. Now things were starting to get interesting! I wondered to myself - how fast could I implement a compelling, yet simple, stateful SOAP application. For a couple of nights I laid awake, dreaming of what kind of application I could build, and more importantly what AJAX framework I could use to showcase it.

With visions of Web 2.0 apps dancing in my head, I started to narrow down the short list to a few - Instant Messenger, Wiki, Blog, Bookmark, or Sticky Notes. But I still hadn't decided on the most difficult part of this endeavor - picking the AJAX framework. Once again, OSCON and a few old connections of mine helped make the choice - but I'll leave the revealing of that decision for Part 2.0 of this post. I will say that the capabilities of the toolkit you use really shape what is and is not possible, and more importantly, what will and will not work well; so it turns out that I decided to make the Sticky Notes app. You'll see why when I get that GUI finished...

In the meantime, I got in touch with Dan and he pointed me right at the exact piece of information I needed to finally kick off the project - basically a how-to guide to build SOAP services using a POJO in about 5 minutes. So last night I sat down to write the server side of the Sticky Notes app. It probably would have taken me only 5 minutes, except I ran into a problem specifying exactly which dependencies I needed in Maven. Fortunately Dan was around and knew just which ones I needed. After updating the XFire WIKI with that knowledge, I pushed the dependencies into my maven project and, you guessed it, I had the service layer done.

Now here's the really cool part - just like my last article about building a parallel web spider, I get to release the code freely available for your enjoyment. At this point, however, I bet you're scratching your head wondering how this could really be useful - right?

Right -- for example if we think about this Sticky Notes app, the notes sure aren't going to be very sticky until I write some kind of persistence layer. It's right about here where most Java developers throw up their hands and figure EJB, iBatis , Hibernate , or one of the many other 100+1 Java persistence solutions that exist today are the only way out of that box.

But if you're like me, you hate writing to and worrying about persisting your objects (I mean what better way is there to waste weeks and months worth of time figuring how best to destroy your perfectly good Object Oriented Design by having to figure out how that design has to be contorted into a completely different domain model just so you can store your objects, right?)

Well, what if you could persist your objects in the Java heap, get automatic scale-out of your application, and High Availability to boot, all without writing a line of extra code? I'm sure you've figured it out by now - throw in dash of Terracotta and all you have to do is add 3 lines of XML to the config file, and it's done. Here they are:

<dso>
  <persistence>
    <mode>permanent-store</mode>
  </persistence>
</dso>

I've just posted version 1.0 of the Notes application. I've only included a tiny Test app for now that lists the current notes, and adds a new note. As I mentioned already, I'm working on the GUI right now and will post it up ASAP.

Meanwhile, give the Notes app a try. Try running two instances of the XFire SOAP service, kill one, kill the Terracotta service, or any of the three. Bring them back and your data is right there where you left it. Damn cool if you ask me.