I've been doing a lot of reading lately on SOA and REST. I've even spent a little time looking at ROA. There is a common theme that permutes all of these approaches to architecture. It's something I can best sum up as omniscient inference. The idea that software will be able to infer the usefulness of the service or resource through some omniscient capability. What do I mean? Well, let me tackle each architectural pattern individually.
SOA proponents argue that you can't have a true SOA without UDDI. The promise of UDDI is that software that needs a service can make SOAP calls and discover what services are available. Once discovering these services, your software is now able to infer the mechanisms by which the service can be invoked. It's quite impressive really. Your application will be able to infer from the WSDL the entities that are required to interact with the service, understand the boundary conditions of the service, and therefore be able to immediately leverage the service to extend its functionality.
Okay, this isn't completely accurate. The intent of UDDI is to standardize the mechanism for organizations to discover what services are available. The problem is that it really tries to serve two masters. Software obviously can't leverage a service a priori. Developers need to design their applications based on the semantics of the service. The problem is that WSDL is a mediocre way to specify the full semantics of an interface for developers. It's difficult to read and even more difficult to document. Proponents would argue that developers don't use WSDL, they use code generators to translate into native languages familiar to the developer. But a Java method doesn't define semantics. Ultimately, the developer needs associated documentation, which challenges the need for UDDI as a service library.
For deployment and routing discovery, UDDI is useful. It's also incredibly complex as most of the information in UDDI is not required simply to manage the rendezvous between a client and service. In fact, most coordination of services does not require the WSDL but rather system qualities about the service provider. The result is that UDDI has too few semantics defined for developers and too much semantics defined for client/service binding.
REST tries to go in a different direction than SOA. The goal is simplicity and it does achieve a simpler interaction style than SOAP for simple tasks. This is a good thing. The problem with SOAP (and CORBA before it) is that even simple things require a significant amount of overhead. You have to design WSDL, after reading several hundred pages of specifications. You have to translate the WSDL with compilers, and install services frameworks. The performance of your application is hampered by the SOAP marshaling and the framework layers that exist to protect you from SOAP's complexities. This is reasonable for complex problems but when I want to retrieve is a list of news items, a simple object in itself, then this is unnecessarily complex. The REST camp is justified in crying foul.
But REST also proposes magic. Micro-formats will save developers from complex entities. They will standardize the way information is exchanged and allow applications to just work across the Internet. In fact, micro-formats are simple enough that applications may be able to extract information from formats they have never seen before, or so the claim. And now we're back to this style of programming that allows our applications to possess omniscient inference.
Micro-formats face two major challenges. First, standardizing across organizations will prove to be challenging. Especially where the contents represents business entities that are offered by competing companies. What incentive exists for company A to cooperate with company B on a standard definition of their common entity? Businesses thrive in a competitive market through differentiation. It's conceivable that some least common denominator format can be agreed upon, but each will still want to extend it to attract customers to their business. Even relatively common data will face the temptation for extensions that give one company an edge in the market.
More problematic though is micro-formats are appropriate for simple entities. As entities become more complex though, the format will no longer be micro. For example, ATOM and MIME are both formats for representing a message. ATOM is perfectly sufficient for a broad range of messages but it is not complete. That's okay because the goal is to make simple messages simple and it does that admirably. But as the message semantics expand, you have to resort to MIME to adequately model them. Messages are not the only entities that will either outgrow or potentially never fit within a micro-format.
ROA is an intriguing proposition. Applications are freed from worrying about services at all. A resource, which is effectively an entity, exposes the state transitions it is willing to accept. Applications don't even care what the resource is, they simply decide whether they are interested in the state transitions available. The level of omniscient inference with this approach is difficult to even explain. So, if the resource is a tennis court and the state transition is reserve (is that a state change or operation?) an application can decide, without caring about the resource per se, that it wants to reserve it. Of course if this is a seat at a concert you may be committing to a financial transaction. At the very least, the state may change back without the applications knowledge (except it's omniscient so that isn't possible).
The reader may take away from this article that I'm anti-SOA, anti-REST, and anti-ROA. That would be unfortunate as it doesn't characterize my position at all. SOA is necessary for proper decoupling of large architectures. REST has tackled the problem of making simple services, simple. ROA is truly intriguing, although I'd like to see more attention given to the concept. No, my objection is to bold claims that can't realistically be achieved. It isn't necessary and detracts from the real value that these approaches bring to the world of architecture. There are meritorious aspects of each approach so let's focus on how to best leverage those in appropriate ways.