I was very interested last week to see the release of Google Protocol Buffers. Any contribution to the open source community should be congratulated!

The rapid demise of XML as a data store for large amounts of non-human readable structured data, and for RPC (such as SOAP), comes as no surprise to me. XML, although touted as such, is clearly not human readable. On top of that it is both bandwidth and storage intensive, and requires huge amounts of CPU cycles to process. Even in this day and age of fast CPUs, terabytes of storage and gigabit networks, every byte and cycle still counts, especially for huge companies like Google with vast amounts of data. Bandwidth is not free, and neither are cycles (someone has to pay that power bill!).

Now we’ve reached a new milestone. Web services are quickly dying a well-deserved death. WSDL, despite arguments to the contrary, is nothing new (Michi has written about this in the past, see “To Slice or not to Slice” for details). It is nothing more than an exceptionally convoluted, and unreadable, form of an interface definition language. SOAP, WSDL’s partner in crime, is nothing but hype. Finally, the toilet of history has been flushed, and we can watch the last vestiges of the colossal mistake that is web services swirl down the drain.

The lessons of the past are finally being relearned. Slow, fat and bloated is out. Sleek, small and fast is in. Binary encodings and protocols are undergoing a renaissance. All of this is good news for ZeroC and Ice. We understand speed. We live for simplicity.

So where does Google protocol buffers fit in? Other than agreeing with my general world view that binary encodings for non-human readable data are a good thing, Google protocol buffers are only part of a puzzle for many applications. What is missing is a facility to pass a protocol buffer object over the wire. It didn’t take long for some developers to discuss starting such a project. It also didn’t take long for Blair Zajac to point out here and here that Ice would be a good companion.

I shouldn’t have to go on about why using Ice for an RPC mechanism is a good thing. I could trot out all the standard arguments such as speed, flexibility, security, support for both synchronous and asynchronous operations, firewall traversal, quality documentation, and so on and so forth. But I won’t

Using Ice, it is already pretty easy to pass any data that can be encoded to a sequence of bytes, such as the Google protocol buffers.

Lets take a quick look at what this would look like in python.

// .proto
package tutorial;
message Person {
required int32 id = 1;
required string name = 2;
optional string email = 3;
}
// Slice
module Demo
{
sequence<byte> Person;
interface Hello
{
void sayHello(Person p);
};
};


In the client:


# python
hello = Demo.HelloPrx….
p = Person_pb2.Person()
# Fill in details
hello.sayHello(p.SerializeToString());


In the server:

# python
class HelloI(Demo.Hello):
def sayHello(self, s, current=None):
p = Person_pb2.Person()
p.ParseFromString(s)
print "Hello World from %s" % str(p)


Not very complicated, but can we do better? What would be really cool, is if you could pass a Person object as a method parameter, and it would magically appear in the server as a Person object. In other words, automate all that busy work code. Now that would be great!

That is exactly what I’ve spent the past few days doing, and the result is our latest ZeroC Labs project, which you can read about here. As always, source code is readily available.

We’re releasing this labs project as an experiment, to gauge interest. If the community finds it useful, we’ll integrate this more fully into a future release of Ice. It may even be possible to not only support the Google protocol buffers encoding, but also other encodings such as C# and Java serialized types.

Please look over what this integration has to offer, and give us any feedback you might have!

Have fun with Ice, Matthew