Cornelia's Weblog

my sporadically shared thoughts on, well, whatever is capturing my attention at the moment.

Posts Tagged ‘Spring’

Second Version of the XML REST Framework Released

To coincide with EMC World and the presentation I gave on RESTful SOA, I’m delighted to report that we have released the second version of the XML REST Framework. As I described in a previous post, the April 18 release introduced a framework that allowed a services developer to produce RESTful services over EMC Documentum xDB by “declaring” the resource model, including definition of the uniform interface and media type handling, with Jax-RS annotated POJOs and by using XQuery to implement the operations of the service. This was a good start, yet didn’t really go far enough to even call the resulting services RESTful because the resource representations that flowed into and out of the services where completely devoid of hyperlinks.The new version of the framework now provides the developer a mechanism for insertion of hyperlinks, again leveraging XML standards to do so – this time I’m talking XSLT. Just as with the first version of the framework, the code that goes into your Java POJOs is very thin, essentially calling into the framework that in turn invokes a series of XML-centric steps. The job of the developer then is to inject (using Spring dependency injection) the XML processing artifacts that achieve the required functionality. With the first version of the framework that was an XQuery per operation, and now in version two it is an XQuery plus one or more XSLTs. In version one of the framework you there was only one option available – to execute a single XQuery; in this new version you have the choice of three different “pipelines” – XQuery alone, XQuery followed by an XSLT and XQuery wrapped by XSLTs before and after. Included in the sample application that is part of the framework release are some XSLTs that make it very easy for the developer to simply declare the links they want inserted – no great XSLT expertise required.The EDN postings go into a good bit of detail on how you can leverage the framework. Each posting has two main parts – code and documentation. If you haven’t already downloaded and installed the code from the first release then go directly to the code in the second release; it is a superset of the former. For documentation, please start with the first release – it describes the base framework – and then move on to the docs for the second release; the latter adds to the former rather than replacing it.Finally, yes, there is more to come. We have a very early implementation of the next version of the framework running in the lab (thanks to my very able colleague Xiaotao Liu). Stay tuned, I’ll give you some hints as to what will be included over subsequent posts. I promise it will be fun.

RESTful SOA at EMC World 2010 and …

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.

Building Domain Specific RESTful Services with XML Technologies

Some colleagues and I have been very busy in the last months putting together a framework to do just that. Let me briefly back up a bit…One of the things that I’ve spent some time on in the last couple of years is the Content Management Interoperability Services (CMIS) standards development effort. One of the styles for exposing this set of services is through a RESTful interface. Through incremental improvements happening through the community development process the result is a pretty nice, and quite RESTful, interface. That said, Roy Fielding levied some pretty harsh criticisms toward it when it was first made public – the vast majority of which are now addressed. One issue from Roy’s list remains but is, frankly, something that CMIS didn’t intend to address, and that is the concern that the services exposed over a CMIS compliant repository do NOT expose the domain specific semantics in the resources. Roy is, of course, dead on on this, what CMIS exposes is the repository model, not your domain specific model. Yes, CMIS does provide a service where object types can be obtained by a client, but those details are not a part of the protocol, rather they are tunneled through the protocol. And, while CMIS resource representations do include hyperlinks between related resources, again the related resources are repository resources (i.e. this document is contained in this folder) not domain specific resources.This is an all too common pattern – we build interfaces that expose the repository models – and, of course, this is not at all without use as it does help consumers more rapidly build applications. Unfortunately, it has the unintended consequence of encouraging architectures where all of the domain specific details are all too often included far too far from the server. My boss calls this the “semantic gorp”, and in the best case it lands on an app server somewhere embedded in some services that in turn call the repository-model-centric services, but in the worst case it ends up far further away. This causes all sorts of headaches, which I’ll go into details on in subsequent posts… for now I’ll just call on your intuition to buy that point.(Okay, so that wasn’t entirely brief, but important context nonetheless.)In the deployment of ECM systems you go through a process where you design your domain specific artifacts, content types, lifecycles, etc. You then (ideally) configure the ECM to provide services for those domain specific entities. Wouldn’t it be cool if you got domain specific services as a result of that process? Now, don’t misunderstand, we haven’t built that (yet), but what we just published to the EMC Developer Network is a step in that direction.We have built a framework that allows for the development of domain specific RESTful services over a repository that supports xQuery. In particular, the implementation available for download operates over EMC Documentum xDB. Using the framework, all of the details of connecting to xDB are abstracted away from the developer, and he or she produces the RESTful services by

  1. “declaring” the resource model in Jax-RS annotated Java classes
  2. defining the uniform interface with more Jax-RS annotations (i.e. @GET, @PUT, @POST, @DELETE, etc.)
  3. producing an XQuery to interface each RESTful operation for each resource to the physical manifestation of that resource
  4. and binds it all together in a spring configuration file

In this first release of the framework we are mostly leveraging Jax-RS for REST features, which means that one of the most important features of RESTful interfaces, hyperlinking, is lacking. This will follow in version 2 of the framework in a few weeks.One of the primary drivers for this work was to simplify the development process for these services – if they are easy to build then we should see more domain specific services where otherwise, generic services might have been. This is already proving true in that we are leveraging the framework on several projects internally at EMC. The developers were able to concentrate on their resource models, representations and interactions rather than getting bogged down in the details on how to implement them. Sure, they still need to touch java code and spring configuration files, but it’s not a huge leap to see that tooling could shelter the developer from those details – we’re just focusing on the developer model, not the tooling(, for now?).The framework, including source code, plus a sample application leveraging the framework is available here. Also, for any of you that will be at EMC World in a few weeks, I am giving a talk on this framework – in the highly coveted last slot of the conference in the developer track (Thursday afternoon at 1PM). Hope to see you there.