An interesting analogy came up in a conversation with one of my favorite (link-)bloggers, Holger Arendt (whom I finally met in person this week):
The SOAP/WSDL/WS-* SOA view of the world is like a statically typed programming language, i.e. C++ or Java — everything is pre-defined, contracts govern everything, nobody can interact without following formal rules … and ideally, everything violating the rules (and policies) will get caught before even going into production.
RESTful HTTP is like a dynamic programming language (i.e. Smalltalk, Ruby, Python, etc.) — you’ll only find out at runtime whether things actually work together, and might well run into errors that would have been caught by a rigorous (and strict) rule-checking process up front; but on the other hand, you have a much more dynamic system, where you can add and remove and change stuff on the fly, and even have some means to react to errors dynamically.
While REST and the Web accepts that things are not necessarily as clean and correct as you expect them to be, the contract-driven SOA view relies on a big and consistent plan. And maybe similarly to the view of dynamic vs. static languages, we’ll just have to accept that there is never going to be any sort of agreement.
Agreed, and with a bit more courage and trust in your convictions, you might even say more, perhaps even in front of (potential) clients ;-)
Just one point: contracts between components/services can and need to be precise, whether in a WS/SOA or REST world, but they need not be unnecessarily restrictive.
For example, I can declare a very strict and precise service contract that says that all information must be encoded using XML 1.0 and sent/received using HTTP 1.1 and that nothing else (at all) is allowed. That might be useful, but it doesn’t really restrict the type and nature of the information being exchanged, because XML 1.0 gives me sufficient flexibility in that regard.
The fundamental (and hard) part of any design (or architecture) problem is identifying which aspects of the system need to be defined exactly (so that useful progress can be made) and which aspects require flexibility for change (so you won’t be hindered in the future).
This is, IMHO where REST scores most strongly against WS/SOA. With WS/SOA, we do not (yet) have a series of patterns or constraints [as the REST guys would call them] that can usefully guide the system design process.
-Mike.
P.S. As an experienced data modeller, you will also know that whatever design choices you make (in terms of exactness and flexibility) will be correct for certain uses/changes of the system, but completely wrong for others. There is never, sadly just one “correct” answer to any design problem and what is correct today might turn out to be wrong tomorrow. Bill Kent’s “marriage” problem is one (trivial) example…