我想告诉你一个看上去就很简单的项目。乍一看它很简单：将一个Web应用程序移植到ASP.NET上，同时将其Windows CE客户端应用程序移植到压缩框架（Compact
Framework）上。但是事实上，这没有那么容易。应用程序的独特性和我们工作环境的策略一起，让我们不得不在看起来很美的美丽解决方案和相对较丑但是性能更好的解决方案之间做出选择。把数据在Cold Fusion服务器和一些已有的移动设备之间进行移动的时候，我们所需要考虑的Web应用程序使用了标准的HTTP协议、私有的压缩算法，以及20世纪70年代那难以捉摸的剖析算法。这个应用程序似乎很适合迁移到一个已编译了的ASP.NET环境，并能够利用Web服务结构的优势。在测试这个应用程序的时候，我们很早就能够看到将其迁移到.NET的益处。使用Cold Fusion重新编写代码构成.NET组件和ASPX页面，会让应用程序的Web端具有更高的响应能力。这种结构也会让应用程序在未来获得更好的支持。
我们都知道，从允许系统在对象层交换信息这一点来考虑，Web服务是一项伟大的技术。但是，为了支持这个功能，这些系统必须需要一门共同的语言（例如XML）来定义其接口和一个共同的传输载体（例如SOAP）。不幸的是，XML和SOAP本来应该给开发人员带来易用性，但是其冗长性却带走了这点好处。使用Web服务在两个系统之间即使只移动少量的数据都会导致大量冗长的文本文件，而这些文件都需要被串行化、传送、接收和解串。这些处理过程都是相当耗时的，会大量消耗处理器资源，而且非常依靠端点之间管线容量。
在我们对这个Web应用程序进行性能测试的过程中，如果用基于Web服务的机制去取代原有的基于简单串行化机制，那么就会对性能产生相当大的冲击，这一点是很清楚的。在局域网环境下运行的时候，这种差别不是很明显：（现在）每个连接只需要两到三分钟，以前需要一到两分钟。但是，远程客户端――Windows
CE应用程序――需要访问这个应用程序。我们在网络上所需要的两三分钟在数字无线电话进行连接的时候将会需要10到20分钟。最终为保证更高的效率，我们决定使用ASP.NET并重新编写了通信协议，因此保持了简单的串行化机制而没有将其移植到Web服务机制上。
