RestMS where I am at

I received an e-mail a few days ago inquiring about my work on a RestMS implementation. In writing a response I was inspired to consider some of the things which I had discovered in my research so far.

After working through a prototype for the REST API I started delving into the message handling and ran into a bit of brick wall. The RestMS protocol leans on AMQP, as far as I can tell, for a lot of it's concepts in the area of "messaging".

So if your looking to understand RestMS do your self a favor and go and learn how AMQP works, there are few implementations around I am currently using RabbitMQ and it's java based API. Once you have kicked the tires of a few implementations you will go back to the RestMS specification and understand a lot more.

This brings me to a question, are these specifications viewed as autonomous specifications, or indeed are they joined at the hip for some of their core concepts? If RestMS is to be presented as it's own protocol there may be a requirement to carve out the concepts in the AMQP protocol and fork them into this specification.

At this stage it looks like my best option is to enhance an existing messaging server, rather than writing a RestMS server from scratch. My research is however not all for naught, I have quite a good understanding of RestMS, REST and ATOM, and how these protocols/frameworks/standards work.

Insert Witty Couch Reference Here

As a sideline to my research for storm-cloud I ran into a post about a new service from ubuntu one. The post referenced a data store known as CouchDB which is a is a document-oriented database written in Erlang. As I am currently interested in how to store unstructured document data for my RestMS implementation I continued through to a book published by O’Reilly Media on the subject. The book is available to read online for free at CouchDB: The Definitive Guide. I found the first chapter very interesting with a break down of the reason for the project as well as some very insightful quotes from people in the industry relating to distributed data, and access to it.

One thing I find intriguing about this database is it's use of Erlang, a programming language designed at the Ericsson Computer Science Laboratory. Having recently had a peek at scala this language was mentioned quite a bit as "another functional language", however I didn't really look into what it was. Having now had a read over the free first chapter of Erlang and OTP in Action and considering my keen interest in concurrency this looks like a must investigate.

So with this all in mind I set out to install couchdb on my opensolaris box in a zone.

Surveying the land scape

After spending the obligatory time setting up my java project and being led off in many and varied directions chasing shiny new APIs and tools I have come REST back at Java and Maven.

There are certainly a myriad of new frameworks in the JVM, especially with the inclusion of such a diverse array of new languages like JRuby, Groovy and Scala. In the last few weeks I have kicked the tyres of most of them, and certainly the odd one a good test drive. But at this stage I have decided to stick with the old trusty Java and Maven team.

This is not say I am any worse off for the trip having seen some great ideas, new features and tricks I will surely call upon in the future, however in my case all of the building blocks I need for my RestMS server are all written in Java, and for a basic functional 1.0 will be fine bound together using Java.

The reason for sticking with Maven is just the sheer array of plugins, tools and overall power of this build tool. God knows I fight with it, dodging and weaving through it's more complex areas but at the end of the day it does a lot of shit I just cannot be bothered with, or didn't even think was possible. And all with a small tweak here and sometimes bit of head bashing. This paired with the ability to stand on the shoulders of giants, borrowing ideas from the wide array of large projects already using it makes it quite an attractive path.

In addition to development toolsets is the wide variety of open source hosting environments, with http://sourceforge.net, http://code.google.com and http://github.com to name a few. Having also given them all a try again lately I have selected github.com for my storm-cloud project. I can summarise the reason for this by saying I am amazed by how it is entirely focused on the code, how it is browsed, how it is shared. Their interface for code browsing is much more interactive than the other project sites. This paired with the ability to add a nice welcome page to your project is very cool.

So my new project site is http://github.com/wolfeidau/storm-cloud

I am currently, albeit slowly, chipping away at my todo list, adding structure, function and of course tests :)

RestMS a voyage of discovery

For quite some time I have been researching lightweight asynchronous messaging protocols for use as a signalling protocol and the transport of telemetry. Ideally I was looking for something which built upon current protocols, and established client implementations rather than re-inventing the wheel. Quite recently I chanced upon RestMS and after reading through each of the draft specifications, and going through the perl example client code that this could well be a good basis for what I was looking for.

Below are some of the reasons I was attracted to RestMS, albeit quite young at the moment.

1. It uses HTTP which is everywhere, with clients for pretty much everything.
2. It is based on the REST approach to data access and services.
3. The documentation relating to this stack clearly illustrates a lot of thought and experience has gone into these specifications.
4. Some nice high level diagrams with a good explanation of behavior, this provides a great starting point for someone building or evaluating the use of this stack.

So based on this I decided to setup a project to work on my implementation of RestMS, in my language of choice being Java. This can be found at http://code.google.com/p/storm-cloud/.

While looking into the basis for RestMS I have read a lot of resources on the web, I have pulled some of them into the following list.

• REST
• HTTP 1.1 method definitions
• HTTP 1.1 status code definitions
• Building Web Services the REST Way
• How to Create a REST Protocol