Web Services：ATL vs. ASP.NET
本文提供了 ASP.NET 和 ATL Web Services 的快速全面概述。
引言
ASP.NET 和 ATL Server 框架都代表了在 Windows 平台上处理 HTTP 请求的当前最先进技术。这两个框架都建立在近十年前出现的久经考验的 ISAPI 架构之上。ASP.NET 和 ATL Server 将它们的文件扩展名映射到特定的 DLL。ASP.NET DLL 是ASPNET_ISAPI.DLL。ATL Server DLL 由 ATL Server 生成，但大部分是样板代码。在这方面，ATL Server 的一个优势是您可以实际审查（并修改）针对您特定应用程序的原始 ISAPI 请求处理代码。
虽然您可以使用任一框架来编写功能上等效的应用程序，但通常的权衡适用。使用托管语言和 ASP.NET Framework 开发 ASP.NET 应用程序通常非常直接。但是，您将受限于框架（尽管 ASP.NET 通过高度可扩展性缓解了灵活性问题）。另一方面，一旦您的 ATL Server 应用程序通过 IIS，它就主要由一系列 DLL 调用组成——一个非常高性能的方案。ATL Server 应用程序是用 C++ 编写的，因此您拥有极大的控制权，以及相应的责任。
描述
下表对这两个框架进行了简要的比较总结。
|
比较标准 |
ASP.NET Web Service |
ATL Server Web Service |
|
线程池管理 |
内置 |
待编码 |
|
从客户端接收和解析 SOAP 消息，并向客户端发送格式正确的 SOAP 响应 |
内置 |
内置 |
|
消息格式化和编码。有关消息格式及其优缺点的更多详细信息，请参阅 www.ibm.com |
支持文档和 RPC[1] 风格的消息通信。 这提供了灵活性、可扩展性和松散耦合的通信环境。 |
仅支持 RPC 编码风格的消息。RPC 编码很快就会过时[2]。 |
|
缓存和保留全局数据 |
使用全局变量或内置的 |
使用全局变量。 |
|
性能 未进行性能测试或比较。 |
Good |
由于代码是用原生 C++ 编写的，因此预期性能会优于托管代码，即 ASP.NET。 |
|
代码控制 |
CLR 作为中间层，因此我们通常受限于框架。 尽管如此，.NET 运行时具有高度可扩展性，并且可以自定义。此外，我们将使用托管 C++，因此我们也可以在其中编写非托管代码块，即可以编写内存管理例程，而不是依赖垃圾回收器。 积极的一面是，我们可以利用 CLR 的所有功能。 .NET 框架未来版本的任何新增功能也可以无缝利用。 |
对代码拥有完全控制权，因为我们从头开始。 |
|
与其他系统的互操作性 |
灵活 |
RPC 编码的消息对互操作性来说是个麻烦。这是因为不同供应商对 SOAP 编码的实现方式不同。 |
|
未来支持 |
支持良好 |
可能不受支持。 有关详细信息，请参阅此 MSDN 文章中的结论。 |
|
符合 WSI 标准 |
是 |
否 |
结论
这两个框架在构建 Web Services 方面都相当有效，并且在功能上具有可比性。ATL Server 和 ASP.NET 提供对会话状态的访问，并支持 BLOB 式数据缓存以及 SOAP 方法和头。
通常，使用 ASP.NET 构建 Web Service 要容易得多。编写托管代码通常比处理指针和其他 C++ 代码的细微之处更简单。另一方面，如果您发现自己严格限于 C++ 而无法使用托管代码，或者如果您需要对应用程序代码进行非常精细地控制，ATL Server 是构建网站和 Web Services 的一个有吸引力的选择。但值得注意的是，当“Indigo”（下一版 Windows 通信子系统的代号）发布时，微软阐述了将多种技术迁移到 Indigo 的计划。其中包括 ASMX，但不包括 ATL Server。