In my search for how real people are implementing SOA I just about never see SOAP, and WSDL seems unheard of. But when I point this out I inevitably get yelled at and told SOAP and WSDL are used all the time. Which is true, but misses the point. Because what SOAP and WSDL are generally being used for is not SOA but rather RPC, specifically RPC-Encoded. Of course RPC is the text book definition of "Not SOA". So I tip my hat to Web Service's major success – as Not SOA.
The success of RPC-Encoded actually makes a lot of sense. The biggest headache in RPC land is getting completely different systems to agree on data types. How many bytes in a long and in which order are those bytes anyway? XML has made the data type situation significantly better for two reasons:
-
XML datatypes, which define things like shorts, longs, etc. is widely supported by many XML parsers.
-
Every platform in existence, no matter how obscure, seems to have a XML parser.
So the end result is that adopting XML data types to enable RPC communication makes a ton of sense. XML's byte bloat is a bit of a problem (not because of the network bandwidth but because of the processing overhead) but it's well worth paying the byte cost in order to get true RPC interoperability between any two random systems. RPC-Encoded then makes matters easier by specifying how to define various data structures made up of those basic types as well as how to identify function names, arguments, return values and all the other issues around binding. WSDL then provided a description for the whole thing that can be generated and consumed by tooling.
Since the vast majority of corporate systems are co-located and communicate using RPC the success of RPC-Encoded is a very good thing. It helps real people be successful in real projects.
But RPC solves exactly the opposite problem to SOA. RPC is all about getting systems that are co-located to effectively communicate with each other. Because the systems are co-located latency, which I have previously argued is the main difference between RPC and SOA, is a non-factor so implementers can focus on ease of use. The easiest thing possible is to let people talk to remote systems the same way they talk to their own local code, hence the beauty of RPC.
But SOA is all about getting distributed systems to communicate and that means that latency is the overriding consideration. As I explain in my article, RPC is a latency death sentence due to the nearly unavoidable chattiness of RPCs. But in addition to latency, SOA also worries a lot about loose coupling. In RPC scenarios the communicating systems are almost always owned by the same group. But in SOA different groups usually own the communicating systems and so 'robust' and 'flexible' messaging is critical. But, let's face it, there isn't anything much more tightly coupled than a function call and RPC-Encoded exists to move around function calls. The point is that RPC solves exactly the opposite problem to SOA.
So yes, SOAP and WSDL are a success, just not in SOA.
It is, btw, with all due sense of irony that WS-I's latest basic profile has all but banned the use of RPC-Encoded. Oy.
Thanks to Peter Dapkus and Brian Zotter for inadvertently inspiring this article. They are in no way responsible for its content.