Page 1
Page 2
Smaller is Faster
If you’re in control of the creation of both the client and the server side of your application and you don’t care about interoperability, you can build any kind of wire protocol you want. Just to be safe, you should probably stick to HTTP as your transport so you don’t run into any firewall or proxy issues. It might be a little more work on your part, but you might try sending GET and POST requests containing the smallest amount of bit-encoded or string data possible to an ASPX page. You would have to write code on the page in order to catch, decode, process, and then send an appropriate response to your Pocket PC or Smartphone client. If your response is the result of a database query, you might choose to return a comma-delimited result. Again, this assumes that you control both sides of the system and that metadata is unnecessary since you know what to expect in advance.
If you want to build something that’s easier to maintain that can interoperate with others, try building a system that posts XML fragments back and forth between an ASPX page and your wireless clients. While not as lightweight as the previous example, it’s certainly lighter than SOAP calls. An example XML fragment may look like this:
Request -> <Login UserName=”Rob” Password=”Pass” />
Response -> <LoginResult Token=”123ABC” />
Just make sure you create good documentation that describes what each XML fragment means in case to want to make this service available to others.
If someone has already built a Web Service that you want to consume, you still have a chance to lighten things up a bit. As you may or may not know, a .NET Web Service supports not only SOAP, but also GET and POST. This means that you can avoid the overhead of SOAP in your requests to Web Services. A lightweight Name/Value query string will suffice instead of a SOAP Header, Envelope, and Body. That being said, the server will send you a SOAP response, but at least you’ve cut down the data payload by as much as 50%. By default, the .NET Framework 1.1 doesn’t allow GET and POST requests so you must make the following addition to your Web.config file:
<configuration>
<system.web>
<webServices>
<protocols>
<add name=”HttpGet” />
<add name=”HttpPost” />
</protocols>
</webServices>
</system.web>
</configuration>
One Last Thing
Even though I’ve spent a lot of time beating up on Web Services, there’s another performance culprit lurking out there whose popularity rivals that of Web Services themselves. I’m talking about, of course, the DataSet object. Show me a Web Service and I’ll show you a web method that returns a DataSet. And why not? ADO.NET makes it so easy to work with this XML representation of a database. DataTables, DataBinding, Autoincrementing columns; what’s not to love? I personally don’t love the overhead associated with using DataSets. With the limited bandwidth afforded by today’s Smartphones and Pocket PCs, DataSets can suck the life out of your application. How do you beat the performance of returning a DataSet and binding it to a DataGrid? Try returning a comma-delimited string and populate a ListView instead. The performance difference is like night and day.
In Conclusion
It’s easy for an armchair technologist to point out the deficiencies in today’s easy-to-use technologies for connecting systems together and passing data around. I like Web Services and DataSets just as much as anyone. But when looked at from an unreliable, low-bandwidth, wireless point of view, they aren’t necessarily the technologies that you should be using to get the job done. When we as Mobile/Wireless developers tell our clients that we add value over and above a desktop developer, are we telling the truth? We’re not if we build Compact Framework applications that same way a desktop developer builds WinForm apps. Just because powerful desktop and server technologies are present in the Compact Framework, that doesn’t mean you should use them. Mobile developers and architects are different because they know how to build compelling applications that run well in underpowered, low-memory, unreliable, low-bandwidth environments. Hopefully, this article has shed some light on choices that are available to you for creating more efficient wire protocols for wireless environments.
Previous Page