In one phrase: lack of interoperability.
Now the reasoning behind the phrase….
ProtocolBuffers is a language independent data format and a set of tools or libraries which Google released into the public domain a few years ago. The unique selling points are language independence and high efficiency / performance. ProtocolBuffers RPC is a remote procedure call client and server side “interface” specification which utilizes the protocol buffer messages and defines “Services”. The RPC api has some very interesting features which are arguably interesting for service providers – like call cancellation, and asynchronous callback on completion.
Now the ProtocolBuffers serialization is very performant – much more so than say SOAP WebServices. Unfortunately Google did not release their own implementation of a RPC library into the public domain. This would not be a problem if they had defined a standard which would standardize interoperability of the RPC services between different implementations – between clients and servers made available by different parties with differing technologies and programming languages. The lack of a “wire format specification” in particular
- means providers need to provide own libraries in all supported languages if they want to achieve a reasonably wide adoption. The current list of Official RPC Implementations shows that most libraries only support 1 language. A few RPC implementations support 2 languages, and the only library ICE which says it supports multiple ( all ) is not actually an Protobuf RPC implementation, but a library which was an existing multilanguage proprietary RPC library which was just extended to support Protobuf message payloads.
- means software vendors cannot choose one library since they’re not compatible with other libraries. For example JBoss application server would not use Tomcat if it were not a standard web application container.
Google could do things differently – example Thrift from Facebook. Thrift provides a reference implementation with each language binding. Having said that, I do appreciate why Google was not prepared to release their RPC implementation(s). You need more than just wireformat to define interoperability. For example
- a service naming concept – or “directory service” ( DNS ). Cloud service providers find themselves partitioning services – not all service providers are going to load balance behind one hostname.
- application layer identity management, authentication and authorization mechanisms
- transport layer security and protection mechanisms.
- logging mechanisms
- accounting mechanisms
- monitoring and administrative remote control of all the above.
I guess if Google were to release an implementation which did all the above, they would be giving up some of their very precious strategic operational advantages.