如果你退几步设想一下，在一个异构的环境中运行Web服务(就像Web服务的最常见应用情况那样)，因为其核心是一种集成技术，所以处理器更容易出现问题。因为它们是专门针对JAX-RPC设计的，所以如果你的Web服务终端是用C、Visual BASIC或Perl实现的，那么这些处理器就不能正常工作。

　　管理消息

　　一个更通用的方法是在服务使用者和服务提供者之间放置一个媒介。截取线级(wire-level)通信量进行带外处理并不是一个新的概念。这种概念已在Web领域通过硬件和软件用于实现负载平衡、加速、路由和缓冲。

　　一旦你意识到你不仅可以检查和处理SOAP消息的内容，而且通过WSDL还可以深入理解该消息的格式、操作及其终点，那么这一方法的消息管理能力非常令人感兴趣。

　　例如，以我最近的专栏中所述的员工工资服务为基础举一个简单的应用实例。该服务获取一个员工号并返回相应的工资信息。设想在经过数月的操作之后，公司内的几个主要部门都开始使用这个服务，而且许多人都要求它还要包含佣金信息。开发人员决定要求这一服务的使用者们修改入站消息(该消息以前只是一个员工号)，以包含一个另外的参数，来指明是要返回工资还是返回佣金或是两者都返回。表2给出了这两种格式之间的区别。

　　在理想的情况下，Web服务的提供者和使用者会同时修改其环境来支持新的参数，并将系统升级。在Web服务领域，提供者与使用者通常具有不同的工作重点和优先次序，他们的升级日程安排互不相关、基础设施难以改变，这些升级的保障条件也互不相同。

　　解决这些问题的方案是什么呢? 从管理层面说有许多选项可用来理解线上消息。一个选项是在线上查找具有老标记的消息，并将他们发送至一个老的实现，这是一种简单的版本说明解决方案。另一种方法是将没有参数的老格式的消息进行转换来包含一个默认值。这种实现的抽象称作服务虚拟化。

　　这一方法的结果是服务提供者可以按照一个与服务使用者无关的时间安排进行升级。而更大的好处是，因为管理过程是在线上发生的，与实施无关，所以即使你的后端环境包含一些异构的Web服务实现，也有可能进行升级。相应地，服务使用者可以选择根据其自己的时间安排进行升级或利用新的特性。

　　这一基础设施有很多实际用途。如果你的服务使用者需要传送SOAP消息，但你已经不能升级你的基于二进制的后端基础设施了，那么应当怎么做呢? 你可以使用这一方法在后端的入站SOAP协议与二进制协议之间进行中介传送。或者，你可以根据发送该消息的服务使用者的类型或者安排机器升级周期的必要性等这样一些因素，将该消息发送至不同的机器。

　　正是有了这种想法，才出现了很多关于Web服务管理的非常夸张的流程和新兴的实现原型。这些是在可靠性、安全性、事务处理、网格计算，甚至是商务流程管理等方面对其他新兴Web服务标准的自然补充。但是需要记住的重要事情是:这并非不可思议;这只是对Web服务带给人们的固有特性的利用和创新。

　　标准，标准，还是标准

　　能够将Web服务作为资源进行管理方面现在已经有了具体的研究成果。大多数厂商追求的标准是适用于分布式管理的Web服务(Web Services for Distributed Management，WSDM)，即一种针对Web服务的OASIS技术成果，就像用于J2EE应用程序的Java Management Extensions (JMX)那样:提供一种与厂商和实施无关的方法来将异构的各种Web服务当作可管理的资源来管理。

　　该标准实际上将会转变为一组Web服务和每个Web服务的实施预期将提供的一些操作–配置、监控和其他管理任务的操作。如果按照标准进行实施，则任何Web服务都将能够由一个遵循WSDM标准的管理基础设施进行管理。