图 2 显示了 Web 服务的一般结构。该结构分成五个逻辑层。离客户端最远的是用于存储 Web 服务要求的信息的“数据层”。数据层之上是“数据访问层”，该层将物理数据的逻辑视图提交给业务层。数据访问层将业务逻辑与对基础数据存储的更改进行隔离并确保数据的完整性。业务层实现 Web 服务的业务逻辑。如图 2 中所示，该层经常分为两部分：业务外观和业务逻辑。业务外观提供简单的接口，该接口直接映射到 Web 服务所公开的操作。业务外观使用由业务逻辑层提供的服务。在一个简单的 Web 服务中，所有业务逻辑可以由与数据访问层直接交互的业务外观来实现。客户端应用程序与 Web 服务“侦听器”进行交互。侦听器负责接收包含服务请求的传入消息，然后分析消息，并将请求调度到业务外观上的适当方法。如果服务返回响应，侦听器还负责将来自业务外观的响应打包成消息并将其发送回客户端。侦听器还处理协定请求及其他关于 Web 服务的文档。仔细一想，您会发现 Web 服务中只有侦听器才知道自己是 Web 服务的一部分！

　　图 2. 一般 Web 服务结构

　　此结构非常类似于 Windows DNA 定义的 n 层应用程序结构。如图 3 所示，Web 服务侦听器相当于 Windows DNA 应用程序的表示层。通用开发方案可能会为通过编程进行访问纳入现有 Web 应用程序的表现功能—即，将 Web 服务添加到现有应用程序。如下图所示，这就像实现访问现有业务外观的 Web 服务侦听器一样简单。

　　图 3. Web 服务结构与 Windows DNA 结构的关系

　　在 Windows DNA 结构中，我们习惯于考虑实现使用数据的数据层和使用 COM 组件的业务层。但是如果数据访问层从 Web 服务而不是数据库获取数据呢？或者，如果业务外观调用 Web 服务来做它的一部分工作呢？应用程序结构一下子看起来与图 1很像。在一些方面，.NET 应用程序结构只是将 Windows DNA 应用程序结构在 Web 上进行了扩展。

　　注意 编程访问的要求和使用模式通常明显不同于要求额外工作的现有 Web 应用程序的要求和使用模式。这些不同之处可能影响应用程序结构的所有层。例如，物理数据架构可能并没有设计用来处理 Web 服务公开的新查询类型或者客户端应用程序的查询量。此外，Web 服务对可靠性要求极高。除非现有的 Web 应用程序高度可用并且能够处理意外的输入值等，否则可能就需要额外工作来满足这些新要求。