When designing a distributed system, at some point we need to decide which communication protocol and data types to use for communication between different system components. Large portion and philosophy in our design is directly dependent on this decision, as it affects how we handle reliability, flexibility, security, scalability and performance of the whole system.
This is also the point where huge mistakes are easily made. Community doesn’t help much either, because in this particular domain (Application-to-Application protocols and data types), people are usually divided on two different approaches:
- RPC, SOAP and WS-* style (let’s call it SOA group)
- REST (Representational State Transfer) architecture
Each group has its strong and weak sides (I’m not going to cover those here, as they are widely covered already). In environments where compromises are not an option (for example: latency/performance) SOA group is the first choice, but this really makes the difference only in extremely large scale environments like Google, Yahoo and others like them. Pretty much everywhere else, REST should be a clear winner. However, I don’t feel really comfortable with that too, and that’s why I’m writing this.
REST architecture was designed for distributed hypermedia systems and it was designed in parallel with HTTP/1.1 protocol by Roy Fielding. That’s why it’s often referred to as RESTful HTTP. But that’s where we can get it all wrong.
Great deal of HTTP protocol success comes from extreme flexibility of HTML and XML languages. Because of their robustness, and HTTP downfalls, in Application-to-Application (not Application-to-User/Browser) communication we’re forced back to convenience over correctness, creating huge bloats where we actually shouldn’t. Programmers tend to write distributed RESTful systems on top of TCP/HTTP without even realizing the lack of correctness.
Not so long ago, Google stepped out with new protocol design, called SPDY (speedy). The idea was to incorporate SPDY at layer6 (session layer) below HTTP, to achieve number of things TCP/HTTP alone do not offer, which in turn results with much faster loading of Web pages and better overall user experience. Some of the key points in spdy design are:
- Session multiplexing. Clients can send and receive parallel requests/responses over single tcp connection
- Bi-Directional communication. Both ends can act like “client” and “server”
- Server can push non-requested data frames, but related to client’s request
Whether or not spdy gets IETF approval some day (topic for some other discussion), it got me thinking how correct and powerful would it be to have such a protocol in developers’ arsenal for App-to-App communication. Currently, spdy design process is on second draft and more and more I see new features/changes being made to properly support today’s Web standards.
How about an lightweight spdy clone designed solely for App-to-App communication and not for Web? How about “lightweight” HTTP on top of such clone? Where are the boundaries then, between protocol utilization and message self-descriptiveness bloat?