在看过微软的Web Service Enhancements(WSE) 1.0之后，我想你会看到微软已经理解并意识到了使他们的Web service工具与其它组织的工具具有互操作性以及尊从标准的重要性。我们这里不对WSE的发布做专门的回顾，而是看一下标准的历史以及在使用它们时出现的系统架构问题。
微软的Web Service结构
.NET系统架构师必须认识到的最重要的东西是问题不是微软是否会继续在他们的平台和工具中深入支持Web service。问题应该是：“他们什么时候能那样做？”微软（还有IBM、BEA以及其它的平台提供商）认识到在多点方式中允许系统在服务级对话的价值。在SOAP、XML和UDDI之上的定义这些系统交互方式的标准出现之前，他们一直没有认识到这种价值。
这些附加的标准可以通过向Web service标准中添加元数据（metadata）实现，一种典型的做法是使用将具有特定信息的SOAP头扩展到所需的服务中。这样做的一个最大的潜在问题是用于分解SOAP头以及处理所有被请求的服务的开销。任何人应该都不会看到一个安全的、事务的、可路由的“Hello World”消息在线路上占用1GB的空间，但是即便遵循了标准，处理起来也比较麻烦。
微软将他们的Web Service结构看作一套设计规则，该规则在实现他们的Web service标准的新版本时使用。这些规则意味着微软的工具和技术将允许系统架构师设计具有如下特征的Web service：
模块化、组件化----由很多单独的元素组合成一个一体的服务；这些元素可单独工作，也可协作工作。
通用----不知道也不关心它们在什么地方运行以及谁调用它们。
基于标准----不用知道也不用关心它们是否运行在一个单一供应商的平台还是多个供应商的平台。
分散的----没有管理、控制或者失败的中心点，这样协作者就可以不用要明示的相互信任而协同工作。（用一个系统架构师的话说，“就像跟岳母一起工作。”）
WS-I标准
WS-I标准包括两个规格说明，可划分成三个大类：安全、事务和可靠消息传送。WSE实现的SOAP头支持前两类，允许不同供应商的Web service共享调用间的安全性和事务环境。例如，在WSE的实现中，如果Web service是从微软平台被调用的，那么它可以将调用者的安全性环境传送给运行在IBM WebSphere平台的Web service。如果相同的对话包含属于同一事务的多个动作，那么事务环境也可以传送。
让我们详细看一下一些最重要的规格说明：
WS-Routing，通过中间SOAP注释路由消息使网络有效。可以把WS-Routing看作是SOAP的DNS。
WS-Referral，在SOAP头中包含有关潜在路由的信息，从而允许动态路由策略。
WS-Security（在WSE中实现），定义消息级的安全机制，包括如何交换证书和检查消息的完整性以及机密性。
WS-Attachments，定义一个抽象的模型，用于向SOAP包中添加附加信息。
WS-Coordination，定义多个Web service怎样协同工作以使用一个通用环境元素实现一个单元的工作。
WS-Transaction（在WSE中实现），定义添加端到端事务性活动的协议，主要用于两阶段提交（2PC）和需要补偿事务的时间运行很长的商业服务。
新的系统架构
考虑极端情况，两个事务性系统的安全连接、协同以及可靠路由，允许两个公司使用支持SOAP消息实现的VPN和2PC在他们的系统间建立一个虚拟的玻璃房间，而不考虑他们的计算平台。如果这些公司中的任何一个有另外两个或三个合作伙伴，这此伙伴又有两个或三个伙伴，这样下去，你就建立了一个新的、专用的用于传送消息而不是浏览网页的Internet。
设计这样环境下的应用程序与创建ASP.NET Web站点或者Windows Form应用程序有根本的区别。它不但要求要理解SOAP和XML的基础，而且还要理解实现像WSE之类的Extension的工具和技术。作为一个.NET系统架构师，你应该去下载、安装、测试像WSE之类的新技术，从而可以在设计系统的时候采用它们。
