I want to tell you about a project that was simple at first glance. Initially, it looked like things would be fairly straightforward: Port a Web application over to ASP.Net and its Windows CE client application over to the Compact Framework. But as things turned out, it wasn't that easy. The particulars of the applications and the politics of the environment we were working under conspired to make us choose between a graceful solution that ran like a dog, and a relatively ugly but much better-performing solution.
The trouble with Web servicesThe Web application in question used standard HTTP protocols, a proprietary compression algorithm, and a 1970s fugitive parsing algorithm for moving data between a Cold Fusion server and a set of mobile devices in the field. This app seemed to be an ideal candidate to move to a compiled ASP.Net environment and take advantage of Web services architecture. While testing this application, it became obvious early on where we would get the benefits of migrating it to .Net. Rewriting the Cold Fusion code as .Net components and ASPX pages would make the Web side of the application much more responsive. This structure would also make the application considerably more supportable going forward. We all know that Web services are a wonderful technology for allowing systems to exchange information at the object level. However, to support this functionality, those systems must have a common language that defines their interfaces (e.g., XML) and a common transmission carrier (e.g., SOAP). Unfortunately, what XML and SOAP give developers in ease of use, they take away in their verbosity. Moving even small amounts of data between two systems using Web services can result in large, wordy text files that must be serialised, transmitted, received, and deserialised. These processes are time-consuming, processor-intensive, and highly dependent upon the size of the pipe between the endpoints. During our performance testing of the Web application, it became clear that replacing the existing simple serialisation mechanism with one based on Web services would generate a substantial performance hit. When running in a local network environment, the difference was not very noticeable; it was taking only two or three minutes per connection vs. one to two minutes before. However, remote clients -- Windows CE applications -- were required to access the application. Our two or three minutes over the wire became 10 to 20 minutes over a digital wireless phone connection. In the end, we decided to use ASP.Net and rewrite the communications protocol to be more efficient, while keeping the simple serialisation mechanism instead of moving it to Web services. C++ vs. anything else
The aforementioned client application was originally written in Visual Basic and then ported to C++ using the Embedded Visual C++ toolkit. It was difficult to support even for the original developers, and virtually impossible for a new developer to decipher -- even assuming that he or she took the weeks necessary to study the nuances of developing VC++ applications for the Windows CE OS. This looked like an application that screamed to be ported to the Compact Framework, where it could take advantage of the standard functionality of the common language runtime (CLR) and be more easily supported and enhanced. One of the most difficult hurdles for any system architect to overcome in a large organisation is the insistence by the C++ gurus that no worthwhile program has ever been written in any other language. (An old joke illustrates my point: What's the difference between a C++ programmer and God? God knows he's not a C++ programmer.) Like the Assembler and COBOL developers before them, the C++ folks' insistence that their language is the only choice for real applications makes it difficult for architects to sell them on the benefits of a CLR and a core set of .Net Framework classes. C++ gurus will just insist that they already have a much better set of tools and classes than any vendor could offer. In defence of the C++ programmer, historically, there hasn't been much of a choice for Windows CE developers. Applications written in Embedded Visual Basic as a rule run too slowly to be usable and require a runtime to be installed on every device. Visual C++ applications, on the other hand, perform very well but are difficult to maintain and require a very specific set of expensive programming skills. The .Net Compact Framework represents a reasonable middle ground, and all new CE .Net devices will ship with the .Net Compact Framework installed, including the C# and VB.Net JIT compilers required to execute .Net applications. Our testing found that when rewritten for the .Net Compact Framework, our application performed acceptably in most situations, with one exception. When a large number of items had to be managed on the device, we needed to create C++ helper objects to maintain acceptable performance. We were lucky here: For some other applications we've tested, the performance of the application required the speed of C++. But we are thankful that over the next year, new Windows CE devices will be released that approach the 1GHz processing barrier (instead of the current 400-MHz processor maximum), and many of these performance issues will simply disappear. Choosing speed over grace
.Net architects face difficult decisions like these every day. In most cases, the decision basically boils down to one issue: Speed or grace? Writing applications that meet the performance requirements may mean creating applications that are more difficult to support and that use less strategic technology. In the end, the best thing an architect can do is design the applications to use the current technology where necessary, but use interfaces and methodologies that make it easier to port the application to a future platform when it becomes more viable from a performance point of view.
For a weekly round-up of the enterprise IT news, sign up for the
Enterpise newsletter. Find out what's where in the new Tech Update with our
Guided Tour. Tell us what you think in the
Enterprise Mailroom.
Enterpise newsletter. Find out what's where in the new Tech Update with our
Guided Tour. Tell us what you think in the
Enterprise Mailroom.
Related stories
Post your comment
In order to post a comment you need to be registered and logged in.
You can also log in with Facebook. Log in or create your ZDNet UK account below
By signing up for this service, you indicate that you agree to our Terms and Conditions and have read and understood our Privacy Policy. Questions about membership? Find the answers in the Community FAQ
