Page 1
Page 2
Who remembers creating bit-encoded packet structures along with checksums to serve as your wire protocol for connecting distributed systems? It doesn’t seem that long ago that I was doing just that in order to get telemetry from a distant vending machine into a Windows 3.1 PC at a speed of 1200 baud over a wireless 450 MHz business radio link. Just ten years ago we suffered from a complete lack of wireless bandwidth and reliability. We had to build efficiency and reliability into our wire protocols and associated systems because no one else was going to provide it for us.
Baby Steps Down the Hall
By 1995-96, wireless bandwidth got a little faster but not any more reliable with proprietary systems like Mobitex and IP-based systems like CDPD. Depending on your coverage map, your data could cruise along as fast as 9600 or even 19.2 kb/s. Did this newfound bandwidth mean we could change our wire protocol to something like a bloated, comma-delimited ASCII string? No way! For starters, wireless carriers charged by the byte, which made things pretty expensive. More importantly, our tiny, bit-encoded packets were more likely to reach their destination intact than larger packets. Why is this? It’s because wireless networks are inherently unreliable. The chance that your RF signal will drop out before your big packet makes it to the other side is unacceptably high. Not only will you get charged for the packet that almost made it, but your costs will go up as your system performs retries to ensure reliability.
Enter XML
The advent of XML ushered in a new era of interoperable, easy to understand, but highly bloated packet structures. XML became the new wire protocol for distributed system communications on LANs and high-speed WANs. We had the Holy Grail of data and metadata all rolled into a single structure. As long as XML packets were traveling across networks running at 10 or 100 Mb/s, no one noticed the inefficiencies introduced by the more interoperable way of structuring data. We witnessed two big changes over earlier wire protocol designs. First, we were now sending big fat ASCII and UNICODE strings instead of high and low order bits. Secondly, we were incurring the overhead of sending metadata along with the data needed for the operation. Where we used to send a packet API document to our business partners so they could decode and map our data to their data structures, today we send self-explanatory metadata. Where we’ve gained ease of use, we’ve lost out in size, speed, and efficiency.
Add HTTP to the Mix
XML over HTTP is the replacement for bit-encoded packets sent via sockets or over null-modem cables. While being less performant, it is firewall-friendly and has become the transport of choice in our web-enabled world. As long as I was dealing with high-speed data circuits, I had pretty good luck with posting XML over HTTP to business partners. It even works reasonably well over ISDN or 1xRTT wireless links as long as you’re sending small XML fragments.
SOAP – Bigger and Badder
As everybody on the planet knows by now, SOAP forms the core packet structure at the center of the Web Services trio that also includes WSDL and UDDI. With Web Services we’ve reached the summit of ease of use and interoperability. SOAP is the new XML wire protocol that runs over everyone’s favorite transport, HTTP. In order to send messages and invoke remote methods, SOAP adds substantial text overhead above and beyond the data and metadata that one might normally post over HTTP. Again, in a world of ever-increasing bandwidth, developers have been turning a blind eye to this issue in exchange for greater productivity. With the exception of those of you who build applications that talk to EPROM’s over a serial connection, bit-encoded packets are all but a distant memory. I must admit, I love how easy it is to build and consume Web Services using Visual Studio 2003. I even converted my energy trading company’s “XML over HTTP” API for trading commodities into Web Services. It took no time at all to build and ran at least 50% slower than our previous API based on an older Windows DNA architecture. Easier, but bigger and slower. In this context, I find it comical that proponents of Service Oriented Architectures (SOA) want us to build ever larger, “coarse-grained” web methods that get more accomplished in one shot. While this thinking helps us to more closely model a web method call after a complete business process, it doesn’t consider issues like network reliability and bandwidth. Whether it’s been COM, DCOM, CORBA, or RMI, big method calls with lots of parameters have always been advocated over smaller, more numerous, chatty method calls. Just keep in mind that the bigger the packet, the more likely it will be chopped in half by an RF dropout.
Back to Wireless
About a month ago I purchased the new i-mate Smartphone2 device. I love the phone and I was excited about creating .NET Compact Framework applications for it. Since it’s a GSM phone, I had to switch from my CDMA provider to one that worked with GSM technology. I was able to get a plan that provided unlimited GPRS Internet data connectivity. For those of you who don’t know, GPRS is a wireless packet data technology that gives you average speeds of around 20-30 kb/s. This is basically one notch above the CDPD wireless data technology I was using in the mid-nineties. I’m absolutely horrified by how slow navigating the Internet has become with this device. I began to wonder what I should expect from my Compact Framework apps that communicate with servers via Web Services. Well, it goes without saying that the performance is dismal. Don’t get wrong, consuming Web Services in the Compact Framework is easy and it even performs reasonably well on my iPAQ with WiFi. Unfortunately, that’s not good enough. With GPRS as the most widely used wide area wireless protocol, it may be time to turn away from the ease of Web Services in exchange for a lighter weight wire protocol. Trust me, we still have a few years to go before everyone’s running WiMax on their device, and Microsoft isn’t adding support for HTTP 1.1 compression until version 2.0 of the Compact Framework. Now I’m not advocating a wholesale return to the past by telling you to use bit-encoded packets over sockets, but there are a few things you can do to boost performance and give your users a better experience.
Next Page