平台要求

　　在已知 Windows DNA 结构和 Web 服务结构的这些相似之处的情况下，再了解到开发 Web 服务和开发 Web 应用程序并非完全不同，以及可以使用现在的 Windows DNA 技术来开发 Web 服务时，您就不会觉得惊奇了。然而，这两者之间还是有一些显著的差别。特别值得注意的是，为了实现 Web 服务侦听器，可能需要理解 SOAP 消息并生成 SOAP 响应，为服务提供 WSDL 协定和为站点提供 Disco 文件，并且通过 UDDI 为服务做广告。如果 Web 服务正在使用，则可能需要使用 UDDI 或者 Disco 来定位服务和服务协定，解释用于服务的 WSDL 协定，生成适当的 SOAP 消息并解释 SOAP 响应。

　　此外，因为应用程序依赖 Web 服务，所以重要的就是这些服务要完全可靠。Web 服务应该始终可用。不应该出现错误、丢失请求、面临无效请求时出错或者损坏持久数据。应始终在可接受的性能下满足客户要求。在错误出现的极少数情况下，Web 服务应发挥最好的性能来继续处理请求。换句话说，Web 服务需要具备所有的“能力”：可缩放性、可靠性、可用性等。如果 Web 服务不可靠，应用程序开发人员将不愿意使用它。

　　除非 Web 服务的部署和管理比较容易，否则服务提供商的系统管理员将不允许部署 Web 服务。在不使用特殊工具的情况下，应该可以在本地或远程部署 Web 服务。部署进程应该容易掌握并易于重复。无论是和现有版本并存还是替代现有版本，Web 服务的新版本应该易于部署。随着要求的变化，无论是独立还是与其他服务相结合，管理工具都应该能使监视和调整 Web 服务性能变得轻松。必须能够保障 Web 服务的安全以便只有经过授权的使用者才可以使用它。可能最重要的是，即使多个 Web 服务共享实现组件，其中一个 Web 服务的部署不应影响其他 Web 服务的可用性或性能。

　　Web 服务使用者和系统管理员的要求给 Web 服务开发人员造成极大的负担，这和服务所提供的任何功能没有特定的关系。Web 服务开发人员所希望的基础结构和工具支持可以使得实现安全、可靠、可伸缩、易于管理且高度可用的 Web 服务变得更轻松。开发人员还希望基础结构和工具可以对其代码执行及正在使用的基础结构服务进行调试、分析和跟踪。在理想情况下，使用此基础结构和这些工具并不需要学习一门新的编程语言。实际上，对现有技巧、组件、应用程序和数据存储利用得越多越好。

　　当服务收到多个并发请求时，在实现可伸缩及高可用的代码过程中，大多数困难与正确管理资源（例如进程、线程及共享状态）有关。就好像单个客户端在进行访问一样，中间件管理这些资源并让您可以改写服务逻辑。中间件可以极大地提高 Web 服务的可靠性、可伸缩性以及可用性，并且可以极大地简化 Web 服务的开发。

　　在实际情况下，中间件为 Web 服务实现代码提供了一种标准的宿主环境。宿主环境负责下列功能：

　　侦听传入的 HTTP 请求。
　　执行安全验证和授权检查。
　　将授权请求调度给正确的服务。
　　确保服务之间以及服务与宿主环境之间相互独立，即，服务有自己的内存，服务不能阻止其他服务的执行，服务故障不会导致其他服务或宿主环境产生故障。
　　从服务、宿主环境及系统故障中自动恢复。
　　为服务的部署、监视和控制提供管理设备。
　　代表每个服务管理资源比如进程、线程和共享状态。
　　当然，一些 Web 服务将包含标准宿主环境不支持的非标准要求。因此，环境必须具备很大的灵活性以便可以替换不能满足需求的功能。

　　构造和分析消息的 API 也将提高生产效率。至少，API 必须支持 XML 流的读写。通过消除对写入分析和格式化逻辑的需求，针对标准的特定 API（如 SOAP、WSDL、Disco 和 UDDI）将提高生产效率及整体可靠性。这些 API 还可以使您不用费心了解规范的所有细节。

　　如果使用组件技术实现 Web 服务，则在系统提供服务按需激活对象并将消息映射到对象方法调用时，可以取得额外的生产效率收益——本质上是为您实现了 Web 服务侦听器。类似的，如果正在使用 Web 服务，您将想要可以构造代理对象的工具。该工具可以隐藏格式化细节并发送服务请求，然后解释响应。