It’s been a really good week for me. I didn’t attend EMC World last year because, well, I didn’t really have much to talk about. But in the last year the work that we have been doing in the CTO Office around an integration architecture that has emerged as Service-oriented and RESTful has reached a point where there is not only plenty to talk about but, wow, there is a stream of additional work that follows on from this. I’ll be busy for a while. Aside from having the opportunity to attend some great sessions and connect with a whole slew of really talented people, I also had the opportunity to present a session in the Developer Track of the conference.The title of the presentation was RESTful SOA, Developing RESTful Web Services for Distributed Applications (Like Cloud). (Hmm, as I type that title now I realize, of course, that “Cloud” is not an application, but I think you know that I mean “like those running in the cloud.”) I was scheduled in the last slot on the last day of the conference – OUCH! All week I spoke with people who said “I’d love to see your presentation but I’ll already be on my way home.” So I expected around 10 people, half of which would be colleagues, and low and behold, I think there were more than 50 in the room!! That really speaks to the interest that people have in this still emerging architectural style.After spending just a moment to introduce what we do in the Architecture Group of the CTO Office (work on an integration architecture) and why we are embracing a RESTful approach, the presentation broke out into two almost equal halves.In the first chunk I talked about REST in general. I still feel that most folks understand only a part of the four fundamental cornerstones of a RESTful architecture. Those cornerstones are:

• A resource centricity and addressability
• Abiding by a (the?) uniform interface
• The use of media types for resource representation
• And hyperlinking

For each of these cornerstones I covered what it is and why it’s important. In the discussion on the uniform interface we drilled down the the characteristics of safe, idempotent and cacheable (Joe Gregorio talks about “zippable” as well – I don’t have any experience with that one yet so have little to say at this point). Rather than writing a whole chapter detailing these things let me give you a brief analogy – the web as we know it today. It works as well as it does, it scales as well as it does because it is RESTful. You can access web resources (web pages) via their URLs, new web sites can be added with no performance degradation in part because of the layered web and cacheable operation results, the network can be unreliable yet applications still work because of safe and idempotent operations, a range of different devices and application types all work against the web, and you can navigate to related resources, without going through some central point of control, by simply invoking embedded hyperlinks. Way cool.Following this discussion on RESTful architectures in general, which took us through the first half of the hour, I moved on into pragmatics and talked about an approach for implementing RESTful services. Using the steps outlined in Richardson and Ruby we quickly covered how to implement services that achieve resource orientation and addressability, implement a uniform interface and support various media types. We use Java and Jax-RS annotated POJOs to declare our services and for implementation I showed how you can use XML technologies such as an XML database like EMC Documentum xDB and an XQuery engine (a part of xDB) to avoid a lot of grungy Java code. The steps for the services developer are very prescriptive; assuming the resource model and physical model are designed she will:

1. Declare the resource model and uniform interface; a Java class per resource, a method per uniform interface operation supported.
2. Craft an xQuery to mediate from the resource model to the physical model and to implement the service operations.
3. And glue it all together using spring.

The first version of the XML REST Framework we have created can be found on the EMC Developer Network and the article that delivers the release goes into much more detail on how all this works.BUT, we’re not done. The resource representations we produce and consume using the first version of the framework do not include hyperlinks. Can you imagine a Web where you have to go back to some index each time you want to access another web page or complete your Amazon purchase? Or one where you have to know the exact URL for EVERY page you want to access? Well, without links in resource representations that is exactly what we are forcing the client programs to do. So the final part of the presentation covered the extensions we made to the first version of the framework to enable the services developer to easily insert hyperlinks to related resources within their resource representations, using XSLT. For details on how this all works please see the second version of the XML REST Framework, also found on the EMC Developer Network.Unfortunately, with so much material to cover I had little time left for questions during the session but fielded quite a few after we had broken up. If you were in the session, or even if you weren’t, and have any questions, fire away! Thanks to everyone who attended EMC World this year – and especially those of you who stuck around until the end.