Sunday, May 25, 2008

Cisco Etch - a replacement for SOAP, or just another CORBA? And why is there still no binary protocol version of SOAP?

I see that Cisco are planning to release and open source a new RPC protocol called Etch later this year. Goals of Etch:
  • RPC protocol without the compatibility and complexity issues of SOAP
  • Mappings across many langauges (C# and Java to begin with, Python and Ruby later)
  • IDL based
  • IDE support
Performance is supposed to be significantly better than SOAP:

In a testbed environment where SOAP was managing around 900 calls a second, Etch generated more than 50,000 messages in a one-way mode, and 15,000 transactions with a full round-trip, company officials stated.

Although not mentioned in the article I'm willing to bet Etch is a binary protocol (implied by performance and Cisco's network heritage). So if it is cross-language, IDL based and binary, what is the difference between Etch and CORBA?

The performance of SOAP is something that constantly disappoints me whenever I develop a large-scale web service. After many years debating the topic the SOAP standards people still haven't come up with a binary version. Because text based XML is a 'standard' there is little you can do to boost SOAP performance other than throw more hardware at it, usually by running many instances of the web service.

I haven't had the cash to try xml hardware acceleration :)

Microsoft have a proprietary .NET-to-.NET binary version of SOAP, and Hessian is a notable open source binary SOAP (benchmarks here).

When I get the time I'm curious to see if the VTD-XML parser can help boost application performance. The doco for this project implies that the author first tried to patent his XML parsing techniques and sell them to the likes of Sun, but for some reason nobody bought it. Now the author has released C, Java and C# implementations under the GPL license, but he won't release the source code :)

1 comment:

Anonymous said...

Hessian hasn't got much to do with SOAP - it's more aligned with XML-RPC (what SOAP should have been). You don't need a description language, just follow the API that's used for the service. It's *very* easy to serialise complex objects, even maps (SOAP can't even do that)!