I had the opportunity to attend Sun Developer Day last week, held in Brisbane Australia. The speakers were fairly good. My manager and I attended together. It was funny viewing as a RESTafarian how on one hand the speakers were talking about Web 2.0, the power of community, and how it was developers driving demand for internet services that would help Sun sell hardware and reap their profits. On the other hand they seemed to equate the success of the web with their SOA vision of the future.
The presentation that brought this in the sharpest focus was that of Ashwin Rao, "SOA, JBI, BPEL : Strategy, Design and Best Practices". Ashwin walked us through the SOA Architectural Big rules. I made notes, crossing out the errors and replacing them with the relevant REST principles. I have left my notepad at work this weekend so can't bring you the exact list that Ashwin presented. In fact, it is interesting to look over the web and see how different the big rules are between presentations by the same company over the course of only a few years. I'll pick up from a similar list:
| Summary: | Services should be objects with lots of methods and represent effectively a whole application. |
| Discussion: | Look at resources, instead. They are at the granularity they need to be based on the content types they support and the application state they demarcate. The granularity of a services doesn't matter, and can evolve. Resources, on the other hand, are the unit of communication and remain stable. |
| Mostly | |
| Summary: | Everything goes through an intermeditary that performs the actual interaction for you. |
| Discussion: | I can see some value in this, however the complexity is significantly increased. Centering an architecture around this concept seems frought with problems of restricted evolution. Instead, this capability should be a service in its own right that can be replaced. |
| Summary: | Conversation state is maintained by coordinator |
| Discussion: | Stateless services scale better. Conversations should always be short (one request, one response) in order to combat internet-scale latency. |
| Summary: | You can tell your coordinator to deliver your message at most once, at least once, etc. |
| Discussion: | This kind of reliable messaging is often not necessary. When it is necessary it is probably better to put in into the HTTP layer rather than the SOAP layer. Most HTTP requests are idempotent, so the problem is not as big as it might initially seem. There are also reasonable techniques already in place for the web to avoid duplicate submissions. At least once semantics are straightforward for a bit of code in the client to do, rather than needing to push things through a coordinator. Just keep trying until you get a result. This also allows the client more freedom as to when it might want to give up. If the client wants to exit early it could still pass this on to another service. Again, putting the message bus in the middle of the architecture seems like a mistake. It should be at the edge for both performance and evolability reasons. |
| Orchestrated | |
| Summary: | You can use BPEL to invoke methods, handle exceptions, etc. |
| Discussion: | Everything is orchestrated. Whether you use BPEL or some other programming language would seem to matter little. |
| Summary: | Service descriptions are available alongside services. |
| Discussion: | In SOA you write client code every time someone develops a new WSDL file that you want use in interactions. In REST you write client code every time someone develops a new content type that you want to use in interactions. Either way, the final contract is held in code: Not in the specification. In REST we have a uniform interface. All of the methods mean essentially the same thing when applied to any resource. Resources themselves are discovered through hyperlinks. Content types are where the real specifications are needed. So far there is little evidence that specifications of this kind structured so stringently that machines can read them are of any special advantage over human-oriented text. |
SOA seems to be fundamentially about a message bus. This is supposed to ease the burden of communications by moving functionality from the client into the bus. While this is not necessarily a bad thing, it does nothing to solve the two big issues: Scalability and Communication. The message bus does nothing for scalability, and real communication is just as distant in this model as in any earlier RPC-based model.
REST presents an almost completely distinct view of communication to the SOA big rules. You could use one or both or neither. They barely cross paths. REST is about solving the scalability and communications problems. Scalability is dealt with by statelessness and caching. That is one thing, but communications is where REST really makes inroads when compared to RPC.
It separates the concerns of communcation into nouns, verbs, and content. It provides a uniform namespace for all resources. It requires a limited set of verbs be used in the architecture that everyone can agree on. Finally, it requires a limited set of content types in the architecture that everyone who has a reason to understand does understand. It reduces the set of protocols on the wire, rather than providing tools and encouragement to increase the set.
Tim Bray is wrong when he talks about HTTP Verbs being a red herring. REST's separation then constraining of verbs and content types is what makes it a foray into the post-RPC world.
SOA has no equvalent concept. Instead, it concentrates on the transfer of arbitrary messages belonging to arbitrary protocols. It promotes the idea that object-orientation and RPC with their arbitrary methods on arbitrary objects with arbitrary parmeter lists are a suitable means of addressing the communications issue. It seems to accept that there will be a linear growth in the set of WSDL files in line with the size of the network, cancelling the value of participation down to at best a linear curve.
Object-Orientation is known to work within a single version of a design controlled by a single agency, but across versions and across agencies it quickly breaks down. REST addresses the fundamental question of how programmers agree and evolve their agreements over time. It breaks down the areas of disagreement, solving each one in as generic a way as possible. Each problem is solved independently of the other two. It is based around a roughly constant number of specifications compared to the size of the network, maximising the value of participation. By restricting the freedom of programmers in defining new protocols we move towards a world where communication itself is uniform and consistent.
We know this works. Despite all of the competing interests involved in building the web of HTML, it has become stronger and less contraversial over time. It has evolved to deal with the changing demands of its user base and will continue to evolve. RESTafarians predict the introduction of higher-level semantics to this world following the same principles with similarly successful results. SOA still has no internet-scale case study to work from, and I predict will continue to fail beyond the boundaries of a single agency.
Benjamin