Representational State Transfer - REST Tutorial

11 Jun 2008 | SearchSOA.com

This SearchSOA.com learning guide will delve into the basics of representational state transfer (REST), its progress in various app dev tooling platforms and its uses inside of a service-oriented architecture (SOA). REST has now moved from a bleeding edge developmental style to one with widespread vendor and open source support. Whether you are a developer, architect, manager or executive, RESTful Web services are likely to become a common occurrence in your applications portfolio.

TABLE OF CONTENTS
   REST Basics
   REST Tooling Support
   REST and SOA
   More Learning Guides

REST Basics

Return to Table of Contents

Born of a UC-Irvine doctoral dissertation by Roy Fielding in the year 2000, REST has grown into a force in the application development community, offering a simplified method of using HTTP protocols to work directly with data.

What is REST?
Fielding describes REST as an architectural style that leverages the modern Web, adding "REST emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems."

Delving into the short definition of REST, a basic use case for it would be an online publisher making available syndicated content. Subscribers would need only to know the URL (Uniform Resource Locator) for the page where the XML file was located, read it with a Web browser, interpret the content data, and reformat and use it appropriately.

Burton Group vice president and research director, Anne Thomas Manes, explains the mechanics of REST thusly: "Although REST defines a number of important architectural constraints (such as clean separation of client interface from server implementation, statelessness, and cacheability), the key distinguishing feature of REST is the requirement for a uniform interface. REST requires the use of a common, generalized, generic interface. It does not permit application-specific interfaces. In the Web world, the REST interface is defined by the HTTP interface, which supports four basic application methods: GET, POST, PUT, and DELETE."

The case for REST
REST emerged as a potential alternative to standards-based Web services development during the early part of the 2000s.

Why is there a backlash against the way Web services are currently built? Stephen O'Grady, an analyst with RedMonk, said: "There are political issues involved in Web services standards, where you have different vendors backing competing standards. In addition to that, there are a large number of standards that have sprung up that are very opaque to a large number of developers. You also have developers saying that there's no need for the complexity and overhead involved."

In short, he said, the current state of Web services means that many developers are locked out of developing applications because they lack the knowledge. It also means that Web services development is unnecessarily complex, slow and laborious -- and hamstrung because of political squabbles and a growing set of hard-to-understand standards and protocols.

Developers have so far been enthusiastic about building lightweight Web services. And they have been voting the way they know best -- by using the technology they favor. O'Grady said Amazon Web services are available using the traditional way of delivering Web services, via SOAP, and in the simplified way, by using HTTP. Developers, he said, favor HTTP over SOAP by an 80% to 20% margin.

One of the early REST applications to gain notoriety was Amazon Light, which provides an alternate interface to Amazon.com. Its creator Alan Taylor praised the intuitive nature of REST.

"The key to REST for me is simplicity," he said. "It's the same reason that I picked up HTML. REST may be a little bit sloppy, but you can see exactly what you're doing in REST, you don't have to rely on any clients and you can see exactly what you're getting."

For his Amazon Light site, Taylor chose several key pieces of data from the Amazon database. REST fetches data from a variety of other places that enhances the experience of using Amazon by adding new features and content. For example, when you view a book, you'll also see author-related links and news, via Google. When you view a movie, there are links to information about the movie at sites such as the Internet Movie Database. And on all pages, there are links to the services of del.icio.us, blogger, Dropcash and Gmail, as well as Amazon.

Ultimately, REST gave Taylor full control over development.

"For me, using Web services was getting lost in a blizzard of white papers, and felt like I didn't know what I was doing. Using REST puts me in control and makes it much easier to build what I want."

Independent consultant Bruce Tate also lauds REST style development, saying "It does most of what you need it to do. It has a security model built in, secure sockets. It has a network structure built in because you can put a link to a net resource in a document. So you can do composition that way. You can have a list of books, and they can have links to books or they can be links to other lists of books. REST changes the way you think about how you structure applications. You're mimicking the Internet instead of trying to decide what a method is. That model is just very, very effective."

REST vs. SOAP
Advocates of REST often contrast it with the SOAP specification.

In order to gain a little more perspective on REST, let's recap a typical process for a SOAP/WSDL design:

1 - Provider creates and implements a Web service interface onto an existing application.

2 - Provider creates a WSDL contract in order to distribute the Web service details to potential consumers.

3 - Consumer obtains WSDL contract for consumption.

4 - Consumer implements the WSDL in a specific platform - Java, C#, PHP, Perl - and creates a caller application.

The biggest rub in this process lies on the consumer. Not only will he/she have to deal programatically with extracting the Web service payload -- e.g. the SOAP message -- in order to do something useful with it in the application, but he/she will also need to go the extra mile also programmatically, through WSDL, to do the initial service request in order to get the payload.

Much of this effort revolves around remote procedural calls (RPC), which REST programming seeks to skirt around with a data-centric model.

The architecture of remote procedure calls as embodied in Web services based on XML-RPC or RPC-style SOAP has a completely different style. The client commands the service to carry out a particular operation. In other words, RPC has a verb orientation.

REST emphasizes resources (think nouns) with a uniform interface for addressing them, while RPC emphasizes processes (think verbs) with a uniform interface for invoking them. With a RPC-based architecture, there is no limit to the number of verbs. REST says we can get by with only four, the familiar GET, POST, PUT and DELETE of the HTTP standard, and make the resource addressing handle the variability.

RESTful Web services
The REST style has its benefits and limitations. One of the challenges in using REST is to minimize the amount of current activity information the service is responsible for, maintaining what is known as a stateless condition. There are different ways to achieve that. A good REST application will exhibit key network features such as transparent cacheability, which can lead to improved performance in widely distributed systems, scalability, reduced server load, statelessness on the server making failover easy, etc. Sophisticated REST applications require careful design in order to make them stateless, while still preserving application semantics, security, etc.

It is important that REST does not represent something antithetical to Web services. Rather it represents a way of building Web services without necessarily relying upon Web services standards, literally RESTful Web services. Experts in the field recommend first understanding the nature of the application you are trying to build before deciding on whether REST will be the programming style of choice. REST is most appropriate in HTTP-centric situations where the additional capabilities of SOAP-based interactions don't justify the additional overhead and complexity that SOAP introduces. Because the Web runs on HTTP, many Web-centric interactions lend themselves to REST-based approaches.

It is important to remember that REST may not be the right tool in every situation.

The REST approach contrasts starkly with RPC, where an object called Customer would have a multitude of operations for creating, deleting, and modifying records, with multiple, discrete instances of objects each referring to a different customer. Fundamentally, therefore, REST is more like the document style, which also contrasts with the RPC style by requiring only that service consumers know the operations they wish to call. In the document style approach, we simply call the service we want and pass it an XML document that the service can process any way it wants. So, we might call the CustomerInfo service and pass it an XML document that it is contracted to accept. In turn, the service consumer would receive an XML document that it is expecting, as per the contract, with no reason to call any methods or specify any data types.

As a result, the document style offers a greater degree of loose coupling than the RPC style, since any changes to the methods or operations might have very little impact on service consumers. In addition, the XML body of a document-style Web services interaction contains the actual business message – the valuable stuff. Whereas in the RPC approach, the XML typically just describes the methods and parameters of the method call.

The fundamental difference, therefore, between REST and document-style Web services is how the service consumer knows what to expect out of the service. Web services have contracts, defined in WSDL. Since Web services focus on the service, rather than on the resource, the consumer has clear visibility into the behavior of the various operations of the service, whereas in REST's resource-oriented perspective, we have visibility into the resources, but the behavior is implicit, since there is no contract that governs the behavior of each URI-identified resource.

REST Tooling Support

Return to Table of Contents

Many vendors and open source projects have sought to build out REST tooling. Since REST is a style of building of applications using Web protocols rather than a specific technology, these tooling approaches tend to vary wildly. Some have built platforms around REST while others have built REST hooks into their platforms. This gives users many different options to choose from, allowing them to right-size the technology they use, but it also means many REST-based technologies will not match up with a specific user's needs.

IBM WebSphere sMash
In April of 2008 IBM announced the availability of its WebSphere sMash product.

Some good news for those looking to do more with REST development is that sMash won't be a standalone REST offering inside the Big Blue product ocean.

"We look at REST enablement as a core capability across the IBM portfolio," said Kareem Yusuf, director of product development for WebSphere sMash. WebSphere CTO Jerry Cuomo made the same vow, promising that REST support will be driven across IBM's platforms, particularly on the SOA front.

"We're systematically going through our product line and REST-enabling everything from MQ to CICS, DB2, WebSphere Application Server and on and on. This liberates these products and the content they represent to the Web," Cuomo said. "With all that content dangling out on the Web, programmers can now agilely write new applications by interacting with those programs."

Using sMash coders can mashup content and then deploy it as a Web application, he explained. Mashups developed with the Project Zero technology also lend themselves to being hosted in a Software as a Service (SaaS) mode, Cuomo said.

"So Zero as a service is the next thing on the horizon," he added.

sMash was based on an open source effort launched by Big Blue called Project Zero. Early in 2007 Cuomo described the impetus for the project:

"So one of the things I've been reflecting on is what happens if we embrace the Web more as the platform? We built application servers and relinquished the role of the Web servers to a lighter transport role. What if we made the Web server truly the application server? It's a popular term now, REST. REST has always been around. So what happens if we really built around REST with URLs and GET, POST, PUT, DELETE as the four operations on those URLs. How far can you go?

"You think about lightweight environments. One of the things I think about having done in WebSphere is can we build a radically simple environment on the Web for building Web-oriented applications? I think the answer is yes. You can do WOA (Web-oriented architecture), the agile cousin of SOA. It's doing SOA on the Web, Web SOA if you will. So one of the things I'm driving very hard at with my incubation team is experimenting with a REST server."

Project Zero incorporates other pieces of open source functionality to form the sMash platform.

Project Zero makes extensive use of the Apache Software Foundation Ant make tool and the related Ivy dependency manager to coordinate assembly of all the parts of an application. Ant and Ivy files are in XML format. JavaScript Object Notation (JSON) script files are used extensively for application configuration and initialization of data structures where other toolkits might use XML or properties files.

Microsoft -- Astoria and WCF
Microsoft also tackled REST development with a code-named project: Astoria.

Astoria provides a roadmap on how REST type Web services will be designed and deployed in the Microsoft world, providing a series of tightly integrated hooks to those points typically associated with RESTful services -- a browser and serverside data layer -- while staying in a symbiotic relationship with other Microsoft developments in this space, namely Silverlight as a browser environment, Visual Studio as a development platform, and the .NET framework on the serverside. The first distinction you should be aware of is that even though Astoria revolves around REST type Web services, it is actually two initiatives, one related to the programming model itself, which focuses on bringing structure to these type of designs, and another to publicly hosting such services on Microsoft infrastructure. Though it also should be mentioned the latter does not imply you can't host your own Astoria projects.

That REST functionality also found its way into Windows Communication Foundation (WCF), Microsoft's Web services stack, via .NET 3.5. According to Dino Chiesa, director of .NET platform product management in the Connected Systems Division at Microsoft:

"WCF adds support for REST-style services with a new attribute for a service operation. This allows a simple HTTP request to be dispatched to a WCF operation, keying on the URI in the request. REST-style service interfaces can be included in the applications that expose WS-* style interfaces. WCF in .NET 3.5 includes new support for JSON encoding. This allows a Web page to very easily connect with WCF services using Ajax. And, .NET 3.5 brings syndication support, including RSS and ATOM. This means you can very easily write WCF apps that serve up syndication feeds. You could do this before, but now with .NET 3.5 it's simpler."

Ruby on Rails and REST
The Ruby on Rails (RoR) framework was an immediate hit in the developer community, but it got even hotter with Rails 2.0 when it added extensive REST support.

Rails 2.0, the latest version of the framework for the Ruby language, is made for doing REST applications, says Mike Clark, author of "Advanced Rails Recipes: 84 New Ways to Build Stunning Rails Apps".

"As of Rails 2, REST is very much a core idea and implementation in Rails," Clark explained. "David Heinemeier Hansson, the creator of Rails, began getting the REST bug many months ago. He was looking at the Atom Publishing Protocol and getting deep into REST. So when you're working with Rails 2 today and you're using the facilities inside of Rails, things like Scaffolding to put up a Web application really quickly, all the code generation in Rails is building a RESTful application."

The Rails creator is positioning it as "REST out of the box," Clark said, but notes developers are not locked into it. "You can certainly write a non-RESTful application. That's easy to do as well, but Rails and REST go together because David believes that's the way to build Web applications."

In particular Rails leverages REST in the Controller portion of the Model-View-Controller design pattern.

A "Controller" typically interprets inputs from a user or server request to decide which model objects will be used for data, the actions to be taken and which view will generate the response. Controller classes can take advantage of a large library of helper classes for dealing with HTML elements. Recent versions of RoR have increase support for REST style requests by creating controller base classes, which can interpret request URLs in REST terms.

Many, like consultant and author Bruce Tate, insist the Rails REST functionality is enterprise grade technology.

"One of the contributions of Rails is its ability to be a very efficient REST platform," he explained. "As you enter the earliest pieces of script to generate pieces of your application on the fly, REST automatically gets generated from the Rails resource generators. What makes the platform nice from that perspective is you can have one application that can handle HTML and XML requests. And that's out of the box before you start building additional pieces and customizing your application."

Java and REST
Not to be left out of a hot new application development paradigm, the folks at the Java Community Process have embraced REST. It's pet project on the HTTP-based architectural style is named Jersey, or JSR-311. It has gained ratification as part of the GlassFish Java EE 5 application server.

In Jersey the servlet which supports JAX-RS resources is the ServletAdaptor class in the com.sun.ws.rest.impl.container.servlet package. The deployment descriptor for a RESTful Web service maps this servlet to a name such as "resources" and specifies that it must be initialized when the server (such as Tomcat or GlassFish) is started. On initialization the ServletAdaptor searches for Java classes containing the JAX-RS annotations and inspects them for the HTTP method and Mime type supported. The Jersey project already supports XML and JSON output types in addition to HTML and plain text.

Any number of resource classes supporting various HTTP methods and resource types can be supported in one application. The JAX-WS API gives rules for locating the best match to a request.

When a recognizable URI is forwarded to the ServletAdaptor it uses Java reflection to create an instance of the resource class and uses the annotations embedded in the class to prepare input to the proper method. The output of the selected method becomes the body of the response if any.

It is important to note that each request causes a new instance of a resource class to be created, after the request has been completed, this instance is discarded. Although this extra object creation may sound wasteful, it vastly simplifies the whole process. It is up to the programmer to provide static methods or other classes to hold long-lived data.

The NetBeans IDE can also be deployed for the creation of a RESTful Web service, as demonstrated in a tutorial by SearchSOA.com columnist William Brogden. On the subject he writes:

"Updates to NetBeans and adding new functions is handled by the plug-in manager which connects to the central repository. I added the plug-in named 'RESTful Web Services' and also updated several other modules. This plug-in is considered a beta version, corresponding to the Jersey version 0.5.1, so it is still in early stages of development.

"I created a new RESTful Web Service project in NetBeans by following the Jersey example cited in the Web resources below. This mainly involved filling in the name that will appear in URIs, Java package name and class name. The purpose of this service is to examine an input word and return a list of words that sound similar based on the Metaphone phonetic coding algorithm. I specified that the URI path to this resource will be 'lookup.'"

MuleSource and open source REST
In late 2007 MuleSource, noted for its open source Mule ESB, hired Dan Diephouse, creator of the XFire Web services stack (now Apache CFX), to head up its REST tooling efforts. Diephouse believes REST holds out huge promise to developers, but that better tooling will be needed to bring it to the mainstream.

"The tools issue is one of the things I think is holding back REST at this moment," he said. "There's a lot of work going into the area of how to turn a business application into a RESTful service. One example of this is the annotations in Java, which the JSR-311 standard people are working on. In Apache CFX, we did our own annotations to turn your Web service into a RESTful service. There's also work in Apache Abdera to build an Atom publishing protocol annotation. So we're seeing a lot of work in the area to help simplify development. Right now, people are basically building their own frameworks internally taking advantage of the Java servlet API. While that can work, it's a little more maintenance and takes a little more upfront work. It scares people away I think. Like it or not, it's really easy to take your business code and turn it into a Web service with SOAP and WSDL. It's not really possible to do that right now with REST. So I think we'll see a lot of development in that area in the coming year."

In particular, MuleSource is looking to leverage things like the AtomPub protocol for its SOA registry.

"There have been a lot of people who said we can use Atom for more than just blogs," Diephouse said. "So there have definitely been people whose shoulders we stand on. Because I've been involved in the Abdera project, which was an Atom Publishing Protocol implementation, I got to know some of these folks and learn a little bit about what they are doing and how to apply it. I know there's one other company that uses the Atom Publishing Protocol for registry, but it's a unique feature and a selling point for a lot of people."

In addition to the registry MuleSource offers a RESTpack for the Mule 2.0 ESB. It provides tools, tutorials and documentation to help architects and developers get started with REST.

Java Message Service and Apache ActiveMQ JMS Server also features REST functionality these days, as does a relatively new offering called Restlet.

As an example of a clean slate approach to RESTful Web services, we find the Restlet project. Restlet is a trademark of Noelios Consulting, the originators of the API. This open-source project is licensed under the Open Source Initiative Common Development and Distribution License. The first public release was in November 2005 and is currently at version 1.0.7, with a major revision to 1.1 in the works.

The Restlet developers feel that only a complete replacement of the servlet API can fully exploit REST concepts. For example, the servlet API assumption of one thread per request prevents use of Java's "NIO" non-blocking I/O classes and limits scalability. Use of the NIO classes permits more flexible connectors between computing components.

REST/Web services harmony
REST is also gaining traction in unlikely places, like in Web services standards.

In recognition of the number of developers turning away from SOAP to the REST style, the W3C working group incorporated what they term "HTTP support" in the recently released WSDL 2.0 specification. This version, many years in the making, is a major revision of version 1.0 with reorganization supposed to reduce complexity. In theory, a WSDL 2.0 document can describe a service as both a SOAP and a REST application.

 

The Axis2 Web services stack joins Struts and ColdFusion in attempting to add REST support to those development tools, though Axis2 by no means offers full support.

Digging into the documentation, we find that Axis2 support for a RESTful GET is accomplished by reformatting a REST style URL into a SOAP request that is forwarded to the normal SOAP request processing with the response in an XML format that does not include the normal SOAP envelope. While this is sufficient for Ajax style support of XML consuming rich Internet applications (RIAs), it does not handle other resource types an application might need and there is no provision for use of the PUT and DELETE methods.

Yet perhaps greater synergy between REST and Web services will be found if Web Application Description Language (WADL), the REST answer to WSDL, gains widespread acceptance. Some have criticized WADL, particularly using it to automatically generate Java stubs, as being too heavyweight for a supposed lightweight approach to development. SearchSOA.com columnist Daniel Rubio addressed the plusses and minuses of that approach, writing:

"While the mechanics of using such an approach -- that of automated code generation -- have caused criticism among early WADL analysts, stating that its not only unnecessary, but that it will start REST down the same path as SOAP and other distributed technologies like CORBA, which depend on intermediate languages/descriptors, from a practical point of view one cannot deny that using such a contract to obtain stub classes is an even quicker way to get started with REST-based Web services clients."

REST and SOA

Return to Table of Contents

Sometimes REST is mistakenly portrayed as an architectural approach contrary to service-oriented architecture (SOA). Yet many experts in the field now agree that REST can be a powerful tool inside of SOA rather than a method of building Web app stovepipes. This section will deal with the synergy between REST and SOA.

How can SOA utilize REST?
Analysts now envision a steady adoption pattern for REST development, which will happen alongside enterprise-wide SOA efforts.

"REST is not new because REST is in fact the Web," said Burton Group's Anne Thomas Manes. "The Web has been around for 15 years, but very few people have used it for service-oriented systems. Mostly REST is being used for visual applications, browser-based applications."

That is about to change. Looking to the future, Manes listed time frames Burton predicts for REST adoption now and in the next three, five and 10 years.

"Today, it is only innovators that are really working with REST," she said. "In three years, we should see the early adopters start to play with REST. It will probably be five years before it is adopted by the early majority. We anticipate that the late majority will probably not pick up REST for at least another 10 years."

What will drive REST adoption eventually is that it brings structure in the form of "constraints" to the sometimes chaotic world of Web services, which includes those pesky rogue services, according to Burton. This will provide a level of maturity for SOA development.

Microsoft architect Savas Paratsidis described how REST could enable multi-directional messaging inside an SOA, something he calls Message Exchange State Transfer (MEST), an acronym which has yet to much in the way of traction even if the concept is compelling.

"Message queuing systems allowed you to reason in terms of one-way messages," he writes. "Service-bus architectures are doing exactly the same. Event-based programming models are built around the same concept. Our intention behind MEST is to use terminology familiar to the REST camp to describe the service-oriented architectures and provide an architectural framework for those building Web services applications."

In explaining the basics of MEST, Parastatidis lists four key points:

• MEST is not an application protocol in the same way that REST is not one either;
• It is based on the transfer of a message and the processing of the contents of that message in application-specific ways;
• The behavior of what happens with the contents of a message is defined through protocols (description of complex message-exchange patterns);
• MEST attempts to describe service-oriented architectures in terms of services and messages and a set of architectural principles.

Mark Hansen has provided a detailed tutorial of how to use REST for SOA-style integration in his book "SOA Using Java Web Services".

The REST invasion ranked as SearchSOA.com's top SOA story of 2007.

Of course, if everyone starts using REST to create Web services it raises the question of how do you govern it? No one's quite figured that out yet because we're still only in the hype wave when it comes to REST.

Lustratus Research's Steve Craggs counts himself as a skeptic when it comes to REST.

"I think it's all a con," he said. "From a business point of view I don't understand what the benefits are."

While REST may be simple, direct and elegant to a programmer, Craggs said he has yet to see where REST will cut development costs or speed time to market.

"It's just another cool, new technology and businesses don't particularly need that," he said. "That can cause more problems than it solves."

Web-oriented SOA
Yet service orientation also creates its share of "new technology" headaches. According to iTKO Inc. chief scientist John Michelsen, "So the problem is the WS-* guys have so much rigor that the implementations are non-interoperable. What we've got to do there is simplify. Throw half of these things out. Make sure there are good interoperability standards and not worry so much about all the little details."

While Michelsen says building on existing technology and expertise is his favorite approach to SOA, he is also seeing some intriguing work being done on the cutting edge of Web 2.0 and REST. He has doubts about how the Web 2.0/REST approach will scale, but he sees it as a good place for departmental IT to begin an SOA journey.

"There is a lot of ground-up SOA being done in Web 2.0 and REST," he said. "I think it's got legs at a departmental level. I think there are some challenges that the REST guys are going to have when they try to go enterprise-wide. It's good to have a rapid application development environment, especially if you're building front ends with the ability to collaborate lots of services from disparate providers. Web 2.0/REST approach is certainly handy for that."

Some view REST as the central organizing principle in what is being called Web-oriented architecture, or WOA. Yet, as Michelsen describes, WOA might be a little loosey goosey for some enterprises:

"The problem is that while it's very reasonable to say that too much structure and too much policy is going to make change difficult because it's too much of a burden. That's fair. The WOA guys claim that against the WS-* guys, but one of the tenets of WOA is you just don't have these kinds of standards at all. You basically do XML over HTTP and anything goes. But if you have too much change, you'll be breaking too often. You can go too far with WS-* standards and have change inhibitors, and you can go way too loose and have change inhibitors as well. WOA is a great way to go, especially if you're doing ground-up SOA, but many things I've gotten for free were worth what I paid. So don't get the impression that WOA is SOA for free. It isn't. You've got to have a certain level of governance, otherwise there's no real way to manage change."

Zapthink senior analyst Ron Schmelzer provided some valuable guidance when it comes to SOA, WOA and REST:

Service-oriented architecture is an enterprise architecture approach that is fundamentally agnostic to the method for implementing a service. Use of RESTful styles for service implementation as well as following specific REST-oriented styles of service design would be helpful for those that seek a Web-oriented approach to SOA. Given that, why bother calling this new concept WOA at all? How about just Web-oriented SOA?

The RESTful SOA registry
In early 2008 WSO2 Inc. and MuleSource Inc. both debuted REST-based SOA registry products, eschewing the traditional UDDI approach.

WSO2 vice president Paul Fremantle explained the process that brought his company to the decision to build a REST-based registry.

"For our project we looked at UDDI and we looked at ebXML and we felt they were both kind of heavyweight and overly complex solutions," he said. "So we went back to first principles and when we looked at it we realized that fundamentally the Web resources are the most important when you look at a registry/repository. It's really about managing resources. That took us to the REST model. So we're building a completely REST-based registry/repository."

For developers, the WSO2 Registry provides a structured registry and repository. For business users it offers a Web-based interface into a Web 2.0 community that enables users to store, catalog, index and manage enterprise metadata in what WSO2 calls "a simple, scalable and easy-to-use wiki-style model."

In this first release, the more hardcore registry/repository features the developers will use are still a work in progress, said Fremantle, but he said there are some core functionalities within the first release that developers can use and more tools will be added in the next release.

"Although governance is an area that we still need to do a lot of work on, there are some core concepts that we built into the registry that are very useful," he said. One such feature is tracking dependencies between WSDLs and schemas, he said. "If you have a WSDL that refers to a schema, then we track those dependencies both ways. If someone modifies the schema, we can notify the WSDL that there's a change and the WSDL might be affected."

According to Mulesource architect Dan Diephouse, the Mule Galaxy registry aims to get at Web services that don't rely on Web services standards.

"One of our advantages is we're not so focused on Web services," he said. "We try to work with anything. Two, we're open source so we're very accessible. We already have people coming in and writing plug-ins for various platforms that might not come bundled with a registry/repository. Another advantage is we integrate with the open source infrastructure that's already out there like Maven, Spring, Mule, Apache. And again it's very easy to write your own plug-in."

Data services and REST governance
The business logic abstraction necessary for SOA has created the need for data abstraction as well. While that makes data more portable, Burton Group analyst Peter Lacey has argued REST does a much more elegant job of handling data.

In terms of business data, the named resource could be something obvious such as an employee or a stock item or a document, he said.

"But it can also be fairly unobvious things like the third item purchased today, or all sales for 2007, or just the second quarter, or just yesterday, or just yesterday at 3, and so on," Lacey explained. "There is an infinite supply of URIs, which you can use to name an infinite number of resources. In short, a resource is simply data and that's interesting when you're talking about data services."

He said Roy Fielding's description of REST noted that unlike a distributed object system "the nature and state of an architecture's data elements is a key aspect of REST."

"In other words, in REST data is a first class citizen," Lacey said. "Unlike systems like SOAP or DCOM or CORBA where the process is the focus, in REST the data is the focus."

When it comes to governance, Michelsen offered up some tips on how to govern anything, even a RESTful Web service.

"There are two basic layers of governance: the producer side publishing cycle and the consumer side consuming cycle," he said. "The difference between producing a service that is made available in an SOA and just creating a re-useable software component is the process you go through in making that service available to the rest of the network to consume it. You can build a component that's hidden and you never publish it and it's still a service, but it doesn't get out. So the publishing cycle is required for SOA. There are three key attributes for a publishing cycle of a service. There's the service itself and the endpoint to that service. There are the proof points required by the policy.

"The third piece is the testability of that service. Essentially, it gets to the fact that if you produce the customer lookup service and I call your service and you are part of my workflow, I need the ability to validate that what you gave me as a response really is the accurate response."

RESTful SOA in action
REST and SOA have been brought together to form one online veterinary business.

VetSource Inc. developed an SOA-based e-commerce application providing home delivery of veterinary prescriptions. With the new service veterinary hospitals can set up their own website where pet owners can order medications directly once they have a prescription from their veterinarian, explains Craig Sutter, the technical director at VetSource. His company hosts all the e-commerce applications, but allows the vet hospital to customize it to list office hours and services such as boarding.

The RESTful e-commerce applications written in Java employ the open source enterprise service bus (ESB) technology from MuleSource Inc. to provide services and information from a MySQL database to different groups of end-users, Sutter explained. The SOA implementation also uses the Apache Web Server.

REST is also popping up in demonstrations of the Apache Tuscany project, which employs the Service Component Architecture (SCA) specification.

Version 1.2 of Tuscany (which also leverages the Service Data Objects specification) has added distributed SCA domain management, an Eclipse plug-in, Atom binding through Apache Abdera project, improved JMS binding and an OSGi runtime. IBM's Jean-Sebastien Delfino used Tuscany for a demo of a fruit store which starts with an online catalog and shopping cart. For those functions he used carrot tags to name the components and declare their implementations, properties and bindings. The transport protocols could be switched just by changing a tag, Delfino chose Atompub and JSON-RPC. He noted that he was running the service a Java SE environment, saying "It doesn't have to run in a big app server. … Basically you have an Ajax app designed as a set of SCA components." He added the whole process takes about 15 minutes.

Users can implement Web-oriented SOA by following a set of conventions for defining services and coordinating their interaction:

• Follow all the precepts of SOA defined by ZapThink as well as others in the space – make sure your services are properly abstracted, loosely coupled, composable, and contracted.
• Every Web-oriented service should have an unambiguous and unique URI to locate the service on the network.
• Use the URI as a means to locate as well as taxonomically define the service in relation to other services.
• Use well-established Web methods (POST, GET, etc.) for interacting with services.
• Lessen the dependence on proprietary middleware to coordinate service interaction and shift to common Web infrastructure to handle SOA infrastructure needs.