Freigeben über

Facebook Thrift, Google ProtoBufs, and Interop

  • Artikel

Dare had an en-pointe analysis of the emergence of various new non-standarcd communications protocols, such as Facebook Thrift and Google Protocol buffers, and how they compare to the standards-based comms protocols like RSS, ATOM or even WS-*.  Dare correctly points out that these tools can be useful if you tightly control the endpoints involved in the communication, and, if you're certain the set of communicating endpoints will never expand to include anything you don't tightly control (acquisition? partner?). 

[I updated this blog entry a couple days after it was first published. The text added is enclosed in square brackets.]

After one is accustomed to fire and police protection, and very smooth roads, and storm sewers that keep the roads clear when it rains, it can be easy to forget, and to chafe under the income tax burden that keeps all those government systems functioning.   

In the same way, paying the angle-bracket-tax can get annoying after a while, too.  Starting in 1999 or so, we, as an industry, moved away from binary [remote-procedure call] protocols such as those dragged in by DCE RPC, CORBA IIOP, Microsoft DCOM, or Java RMI.  Instead we have invested heavily in the development of tools and frameworks  that use an XML-based message-passing paradigm to improve interop.  We achieved critical mass on [message-based] communication standards, and everyone was happy.  Except now some of us are not, and we apparently want RPC again.

We want binary serialization because it is so darn efficient.  We want opaque data formats because those angle brackets are just so tiresome.

Well, we embrace those efficiencies at our peril.  We have been here before!   I am not saying that there is no place for Protocol Bugg^H^Hffers.  What I am saying is that we as an industry shifted to XML-based message passing for a good reason, and that reason has not disappeared.  We're used to the smooth roads and working sewers.  Let's not have a revolution and toss all that aside.  Use optimized communications where it makes sense.  [And don't drag in RPC when all we want is binary serialization.]  Dare shows the way.

Last thing - just dreaming a bit here... wouldn't it be cool for developers if there was a single programming framework that could do angle brackets as well as optimized binary transfers?  [And everything was a message? Not a remote procedure call in sight?]  Wouldn't it be cool if you could code it once, and then select the serialization mechanism at configuration time, in metadata.  Wait, wouldn't it be even coooler if .. this is gonna sound crazy, but.... wouldn't it be cool if we could have multiple communication endpoints running at the same time, each dedicated to a different wire protocol, but using the same backing business logic.  One endpoint could speak XML, another could speak binary, and they could run at the same time.    That would be cool, wouldn't it?

Comments