在前一节中，我们提到最近的分布式互联网架构变化已如何成为混合
Web
服务。这一主题值得详细说明，因为它已经是（并预期继续是）
SOA
周围的混乱之源。
首先，传统架构内使用
Web
服务是完全合理的。由于许多编程语言都支持对
Web
服务的开发，他们可轻易地将其嵌入老的应用设计。并且，对于那些不支持
Web
服务定制开发的遗留环境，通常也可用适配器的方法来解决。
注意
尽管我们集中于分布式互联网架构，但并没有限制两层客户
-
服务器的应用使用
Web
服务。
Web
服务作为构件包装器
Web
服务在这个语境中的主要角色已引进了一个包含包装器服务的整合层，促成经由
SOA
P
兼容的集成通道的同步通信（
图
4.7
）。实际上，
SOA
P
规范初始发布和第一代
SOA
P
服务器都被特别设计用来复制使用消息的
RPC
风格的通信。
这些集成通道主要在集成结构中，被用以促进与其他应用或外部合作伙伴的通信。也被用于促成与其他（更多的面向服务）解决方案通信，还可利用第三方工具提供的
Web
服务。不管他们在传统架构中的使用或目的，关键是要澄清靠这种方式在分布式互联网架构中纳入
Web
服务不具备真正的
SOA
资格。这只是使用
Web
服务的分布式互联网架构。
并非是反映构件接口和用
Web
服务建立点对点连接，
SOA
提供了对于不同通讯模型的强健支持（基于同步和异步的交换）。另外，在
SOA
内的
Web
服务受制于特定的设计需求，象由面向服务原则提供的那些。这些和其他的特征都支持对和谐的松散耦合的追求。一旦实现，单个服务不再限于点对点通信；它能够适应任何的现在和未来的请求者。
SOA
内部的
Web
服务
然而
SOA
在大小和品质方面会有所不同，
SOA
与其他架构在
Web
服务的使用方面有切实不同的特征。本书主要专注于探索这些特征。目前已经充分阐明：基本上，
SOA
构建于一组
Web
服务，它们被设计用于一个或多个电子商务流程的集体自动化（或者参与自动化的），
SOA
促进将这些服务组织成抽象企业自动化逻辑特定部分的特定层。
同样通过跨企业的标准
SOA
，出现了天然的协同性，超越了专有的应用平台。这考虑到先前不同的环境组成，以支持新的和进化的业务自动化过程。