Is The Internet More Fundamental Than REST?
Though I like REST and consider it a very elegant model for SOA, it's a little tiresome to hear day in and day out that it's so much more elegant than the SOAP-based Web Services model. In fact, I'm getting so tired of this shrill posturing that I'm going to stick it to the RESTafarians right now, in their own style.He then outlines some of the core principles that RESTafarians use to backup their arguments:
REST exploits the features of that most scalable application there is - the web, right? REST doesn't fight the features of the web, it works with them, right? HTTP is not just a transport protocol, it's an application protocol, right? URIs are the most natural way to identify resources, HTTP's standard verbs are the most natural way to expose what can be done with resources, and hyperlinks are the most natural way to tie all these together to expose the whole system as a State Machine, right??However, in his view, with the Internet being older and more extensible, it is also more scalable and resilient than REST. Working with the Internet model ("it's about message passing between nodes using a network that is smart enough to provide resilience, but nothing more") pushes you towards:
... the Internet philosophy is "Dumb network, smart endpoints" (remembering of course, that the network isn't really "dumb", just deliberately constrained in its smartness to do nothing more than resilient packet routing). And the protocol used by the Internet for packet routing is, of course, Internet Protocol (IP).Adding a new capability is as simple as:
Just create your own end-to-end protocol and communicate between nodes (endpoints) using IP packets to carry your message payload. You don't need to consult or negotiate with anyone "in the middle". There is no middle.The distinction between low-level communication protocol and higher level "application" stack is made clear when Ganesh discussed the role of TCP in the Internet (UDP is once again consigned to the bin of history):
TCP is interpreted at the endpoints. That's why the networking software on computers is called the TCP stack. Each computer connected to an IP network is an endpoint, identified by nothing more than - that's right - an IP address. Processing of what's inside an IP message takes place at these endpoints. The Internet (that is, the IP network) is completely unaware of concepts such as sockets and port numbers. Those are concepts created and used by a protocol above it. The extensibility and layered architecture of the Internet enables the operation of a more sophisticated networking abstraction without in any way tampering with the fundamental resilient packet-routing capability of the core Internet.Of course this discussion is similar in many ways to what REST, SOA, WS-* and message-oriented architects have been discussing as some of the core principles to achieving loose coupling and scalability: hide as much as you can behind the service endpoints. As an example of how resilient and flexible the Internet is to changing requirements, Ganesh reference IPSec and asks (rhetorically) whether the addition of that protocol required a major overhaul of the Internet:
... they just created another end-to-end protocol called ESP (Encapsulating Security Payload) and endpoints that understood it. Then they "layered" it between TCP and IP.With further references to how the Internet has "has beaten the Telco network even in telephony" Ganesh goes on to illustrate how REST (and the Web) isn't superior to other forms of distributed computing infrastructure.
The Internet is a platform for decentralised innovation. (Heck, the very web that you RESTafarians wave in people's faces is an example of the innovation that the Internet enables. HTTP is an end-to-end protocol, remember?)But where does this leave WS-*? So far there has been a discussion about the Internet versus REST (really the Web), but nothing about Web Services or SOAP. However, after pushing SOAP-RPC into the pit of oblivion, Ganesh makes it clear that his definition of a SOAP message is "SOAP message with WS-Addressing headers", because the use of WS-Addressing gives you a message that can be independently routed, like an IP packet. It is this parallel that he then builds on, providing some nice diagrams to help illustrate the duality.
Now imagine a messaging infrastructure that knows how to route SOAP messages and nothing more. ... How do we innovate and build up higher levels of capability? Why, follow the Internet model, of course. Create protocols for each of them and embed all their messages into the SOAP message itself (specifically into the SOAP headers). There's no need to layer them as in the TCP stack, because reliable delivery, security, transactions, etc., are all orthogonal concerns. They can all co-exist at the same level within the SOAP header block ...Given this approach, we end up with what the entry calls "plumbing required for a loosely-coupled service ecosystem". Obviously this isn't sufficient for building applications based on SOA (as with some others, Ganesh does seem to equate SOA with Web Services), but XML comes to the rescue:
So now define document contracts using an XML schema definition language and a vocabulary of your choice (for Banking, Insurance or Airlines), stick those conforming XML documents into the body of the SOAP messages we've been talking about, and ensure that your message producers and consumers have dependencies only on those document contracts. Ta-da! Loosely coupled components! Service-Oriented Architecture!If only it were that easy in the real world of standards, but you get the general gist. But if it's that easy, the obvious question is: Why aren't we there yet? There are 6 reasons that Ganesh believes are behind the current state of affairs:
- The legacy of SOAP-RPC: "There's a school of thought that says the use of WSDL implies RPC even today, but I'm content with the wrapped document/literal style that takes us away from blatant RPC encoding".
- The lack of standards around bindings for SOAP other than HTTP.
- The need to tunnel through firewalls, which is related to the default SOAP/HTTP binding. "We need to define a port for SOAP itself, and get the firewalls to open up that port. No more flying HTTP Airlines just because we like the Port 80 decor."
- "Vendors of centralised message broker software have been pretending to embrace the SOAP/WS-* vision ("We're on the standards committees!") but in reality they're still peddling middleware, not endpointware."
- The dominance of close-source WS-* stacks in the industry.
- The fact that many of the critical WS-* specifications (transactions, security, reliability etc.) have only recently come to fruition (despite being used and in development for 5 years).
Ignores Metcalfe/Reed's Laws
What is left out from this is the disconnected-ness of IP only services. Both Metcalfe's and Reed's Laws point out that the value of a network of systems/services isn't in the point-to-point connections alone, but in how many possible and realized groups of communicating nodes there are.
REST imposes constraints (uniform interface and linked hypermedia data) exactly to enable connections between any newly added services.
Re: Ignores Metcalfe/Reed's Laws
Re: Ignores Metcalfe/Reed's Laws
In terms of the REST vs MEST, I have a blog post up where I relay a conversation I had with Benjamin Carlyle on the topic. Take a look and tell me what you think:
Re: Ignores Metcalfe/Reed's Laws
I really don't think SOAP is quite as evil as people make it out to be. Use SOAP if you need a transport neutral, message oriented solution. Otherwise leave it alone. If there wasn't firewalls I highly doubt we'd be using SOAP/HTTP at all. But for now, we're forced to tunnel through it.
Then there is another practical aspect in that it is just too damn easy to take a POJO and do RPC with it. While that is insanely evil, I find myself not caring a lot of time (my evil quotient is out of control). For instance, I developed an application where I had control over both endpoints - one was Java and one was a mobile .NET app. It was wayyy easier to develop a SOAP/RPCish app than a RESTful one thanks to the miracle of wsdl2java. I really wouldn't have received too many benefits if I went down a more RESTful route. Caching was a non issue as it was a pretty low bandwidth application. Linkability was a non issue because no one was ever going to link to this stuff - it was for the mobile devices only. Etc.
OK, I'm rambling and I'm not sure these thoughts are that connected. Cheers :-)
Re: Ignores Metcalfe/Reed's Laws
Mr Reed as gone one to work on Croquet. Croquet takes another slant and relies on object replication and synchronised message broadcasting. This is done on a peer-to-peer basis. It still has a uniform connector, URIs and replicated code on demand as "self describing data" but is more scalable than the web because it doesn't rely on central servers:
Correction: SOA and Web Services
"as with some others, Ganesh does seem to equate SOA with Web Services"
Not true. You may recall that towards the end of my post, I said, "In short, I think there are only two valid approaches to building Service-Oriented Architectures today - (1) REST and (2) SOAP-messaging-using-Smart-Endpoints"
And that's just the technology aspect. SOA has business aspects as well, such as Business Modelling and Business Process Re-engineering.
Re: Correction: SOA and Web Services
"In short, I think there are only two valid approaches to building Service-Oriented Architectures today - (1) REST and (2) SOAP-messaging-using-Smart-Endpoints"
SOA is not a technology. It does not come in a shrink-wrapped box. It's as much about the people who deploy applications, develop them, lay down the principles behind how the businesses work etc. Therefore, SOA does not have to be tied to SOAP anymore than REST has to be tied to HTTP. It is just as easy to write SOA "compliant" applications in Web Services as it is to write traditional CORBA/DCOM-style applications in it. There are many good examples of SOA that were developed way before SOAP was even a glimmer in Don Box's eye. People are still developing SOA today without a single piece of SOAP in their bathtubs.
Even *more* extensible!
Of course TCP is more "fundamental" than HTTP. So is IP. Ethernet even more so.
Of course it's more extensible and flexible. So is IP. Ethernet even more so.
Strangely, I don't see WS-* advocates running around saying that we should be holding Ethernet up as a paragon of virtue, since it's obviously so much better than HTTP. Not that someone won't try...
HTTP and REST will certainly constrain their users, and that's the point; any good architecture will, just as using any framework or toolkit will constrain what you can do with it. The point is to offer enough value in the tools that you give people for a broad enough selection of use cases that they'll be able to leverage it and avoid re-inventing the wheel time and again; it's not to take over the world. This is what standards do. This is indeed what WS-* does; it just picked different tradeoffs, and evolved under different conditions.
I would absolutely love to impose mandatory IETF participation for all who espouse WS-*; just about every insight that they have (e.g., message-orientation, end-to-end, self description) is a reflection of what the IETF has been doing for decades, and isn't revolutionary; it's just common sense.
P.S. I weary to see people continue to hold extensibility up as the yardstick of quality. Yes, extensibility is necessary in distributed systems, to assure that you don't paint yourself into a corner, but it's hardly the point of them.
John Krewson, Steve Ropa and Matt Badgley Nov 24, 2014