Comparing ROA and SOA

As part of my ongoing look at enterprise architecture in 2007, I want to focus on the commonalities and distinguishing features between Resource Orientation and Service Orientation, comparing ROA and SOA. I'm witholding judgement as best I can, to try to be as objective as I can about what these two approaches to web services are. Accordingly, I'm not looking at practicalities. Those clearly matter, but they are separate and distinct from the purely technical differences. Practicalities change over time, but the technical pieces probably don't. I'm considering SOA implemented as SOAP web services, in angry defiance of people who say SOAP is just one implementation mechanism of SOA. While that's reasonable language, it has little value to me in the real world to continually say "SOAP based SOA" instead of just "SOA". There's no other widely adopted implementation of SOA with market and mindshare significance. ROA, on the other hand, is a new term for a particular perspective on REST. The flag bearer for ROA is the book RESTful Web Services by Richardson and Ruby and I follow their interpretation of ROA as faithfully as I can.

The principles of SOA are pretty well known:

1. Open Standards - HTTP, XML, XML Schema, SOAP, WSDL, various WS-*
2. Loose Coupling - Service consumers do not couple to implementation platform, but instead rely on open standards or metadata.
3. Reusability - Services are intended to be highly reused. The goal is a single authoritative service, meeting the needs of all consumers.
4. Contractual - Services adhere to an interface agreement artifact (a service description) that is functionally definitive of the interface.
5. Discoverability - The service contract is an outwardly descriptive and externalizable metadata artifact suitable for forwarding by 3rd parties to potential service consumers
6. Autonomy - Services have control over the implementation of logic and technical machinery they encapsulate.
7. Statelessness - Services generally do not maintain conversational state, Every call is self contained.
8. Rich Behavior - The service contract exposes many kinds of method invocations and associates them logically with the data structures described in the service description.
9. Metadata - Both requests and responses have a clear delination between metadata and payload.

The principles of ROA, as presented by Richardson and Ruby are easily understood:

1. Open Standards - HTTP, often XML, possibly XML Schema or DTD
2. Loose Coupling - Service consumers do not couple to implementation platform, but instead rely on open standards.
3. Universal Addressability - Resources have a URI which serves as a single global name that defines their identity.
4. Uniform Interface - All resources support a small and standard set of behavior methods (GET, POST, PUT, DELETE). Often only GET and POST are used.
5. Behavior Conventions - GET never has side-effects, and anything without side-effects should use GET. PUT and DELETE should be idempotent (repeating them has no additional affect).
6. Statelessness - Services generally do not maintain conversational state, Every call is self contained.
7. Representations - A resources can have tangible representations as bits in various MIME types, but the resource is different than the representations. Representations of a resource may vary with time, and the set of available representations can also grow and shrink over time.
8. Connectedness - A resource can (and should) reference other resources by name (URI) in the representation.
9. Autonomy - Resource providers have control over the implementation of logic and technical machinery they encapsulate, subject only to the uniform interface behavior conventions.
10. Minimal Overloading - parameters to state changing operations should not be used solely to select different behaviors. Heuristically, if an operation parameter could be converted to part of the URI, then it should be.

OK, so ROA and SOA each have open standards, a loose coupling concept, autonomy, and statelessness. Those are probably properties of "Web Services", which generalizes both.

Here are the key differences between SOA and ROA as I see it:

1. Contractual vs Not - SOA offers contractually, discoverable interfaces, while and ROA expects designers to solve problems as they set fit.
2. Rich vs Uniform Behavior - ROA has the uniform interface applied with minimally overloading, while SOA provides rich, discoverable behavior
3. Differentiation vs Equivalence of Data and Metadata - SOA relies on metadata to inform behavior, while ROA uses universal addressability, connectedness and design time conventions for representations and URI's to blur data and metadata together.

Let's examine these in depth.

In SOA, the client and server have a contract that specifies the service operations, endpoints, and input and output data formats. Typically the artifact for expressing the contract (WSDL) is closely tied to the physical implementation of both the service and the client, so that there it is expected to be definitive. In ROA, there is no contract guarantee and the interpretation of resources address mechanisms and response types must be based on knowledge not contained in the system. Often external standards for particular sets of resources arise. These can be open standards like RSS or ATOM, or local standards like a corporate schema or DTD for the output. The local standard might require the resource to self declare it's format, or it might not. There is no standard for how to structure these standards, so resource designers are free to meet needs as they arise, but resource consumers have little assurances over such designs.

The second difference is the types of supported operations. SOA allows a service to offer a rich set of discoverable operations. ROA has specified the operations as a small fixed set with standard meaning. Where an SOA service may be a logical grouping of many operations, each with an independent name within the service, ROA flattens each operation out to it's own URI. The logical grouping might exist within the path of the URI. The minimal overloading principle counsels the implementer to refactor an ROA resources that masks rich behavior within it's parameters, so that the URI fully differentiates separable operations.

The final critical difference is that SOAP messages have an envelope which contains a header and a body. The header concerns information about the handling of the message, while the body is the message itself which must comply to the validation rules for well formed messages defined by the contract. ROA, in contrast simply treats metadata as part of the resource representation, possibly leveraging connectedness and universal addressability to link to other resources that describe the orignal resource. It's up to the conventions and standards surrounding each resource to define the expected behavior associated with it.

This is my attempt to simply define what ROA and SOA are and to observe their common and differentiating characteristics as objectively as possible. In a future article I'll get into dynamic qualities and practicalities, and someday I'll try to combine the technical with the practical and draw conclusions about the suite spots of each.

Technorati Tags: roa soa web-services REST SOAP