说明如何使用XML设备进行版本控制及治理的例子有哪些？

首先，在提供与版本控制及治理相关的能力上，XML装置或任何其他中介（如企业服务总线ESB）之间没有区别。尽管供应商肯定是很乐于道出一些区别的，但其中的基础技术都是一样的。问题不在于“我是否应该用XML装置或基于软件的ESB进行版本控制/治理？”所以我不会就此话题深入。重要的是这里的技术的确可用到任何中介上，不仅仅是XML装置。

运行时治理

让我们从更广的主题开始，运行时治理。运行时治理相关的能力包括安全（身份验证、授权、验证、加密、威胁保护）及流量管理（路由、请求率容限等流量整形技术）。此外，还有指标采集等治理所需的辅助功能。如果你正在收集使用情况相关的指标的话就不能在服务合约中强加请求率协议条款。

在使用XML装置或其他中介时，只有策略被插入请求路径时才能实施。可以把它视为到达实际服务容器的网关。将其放进请求路径通常不是问题，但是你得注意，要确保消费系统无法绕过网关。

如是发生要从外部面对网关的情况，这也不是什么大问题，因为实际的服务容器往往处在与网关不同的网络，防火墙会阻止容器被直接访问。对于内部网关/中介，情况可能不同，所以你可能需要采用双向SSL或其他方法来确保请求总是通过网关流入的。你是选择严格按此执行或是采用其他不那么严格的技术取决于公司的信息安全策略。

至于安全策略，技术就比较直截了当。消费该请求，提取并验证证书，检查授权策略，验证请求消息是否存在XML威胁。他们对这些事情的实现方式很重要，因为有些XML威胁会迅速导致解析器出问题。网关做这些事情的好处是，无论其中牵涉到什么服务和消费者，你都可以推行这些策略。这是非常重要的一点。

转换与协调

我对网关的看法是，无论它是基于软件或装置都好，都应该做一些事情，而且能做得非常好。如果并非所有信息均要进行处理的话，那些事情应该是大部分流程的一部分。这就是为什么我不把转换或协调列入治理相关能力的原因。

转换并非每一个通过网关的消息流都要完成的事情。如果你一定要把它加进去，网关的性能会变得难以预测。如果一大波含有转换的请求涌入会怎么样？会消耗更多的CPU，并让网关陷入将其他消息的流量占用掉的风险。

你希望自己的配置是基于整体消息流量做出而非与特定消息类型相关的流量。安全就是这一类。应该验证每一个请求的证书，对其进行授权检查。如果是向外发布的，则应该对消息进行扫描看是否存在潜在威胁。这适用于所有的流入流量。

对于流量管理来说，同样的事情也是一样的，尽管事情会变得棘手一点。总是要有的基本能力包括路由/负载均衡，尽管你可以选择将负载均衡委派给专门的装置来做到这一点。评估基于内容的路由的性能影响。典型的负载均衡器会在特定位置（如TCP/IP报文头）搜索信息，并基于此信息进行决策，然后按照假设进行优化。如果你现在要在自定义的位置搜索信息决定路由选择呢，该装置的总体性能有可能下降。

版本控制支持

最后，我们来讨论一下版本控制支持。首先，版本控制支持相关的能力有哪些呢？如果消费者明确指定需使用的服务版本，那么网关除了要验证该消费者是否已被许可使用该版本以外就不需要做任何事情了。如果消费者没有明确指定版本，那么你就得为该消费者将请求路由到适当的版本。你会吗？

这就进入了向后兼容的领域。一旦对服务做出变更，你需要考察一下这种变化，然后确定其与之前的请求及响应消息是否向后兼容。如果是，那么你不需要做任何事情。只需路由次请求给新的实现即可。那你可以将流量整形规则慢慢地从旧的向新的迁移，但是不需要进行转换或做任何事情，至少网关不需要。如果接口不是向后兼容，那么就把它当做一项新服务。

从定义来看，如果接口不是向后兼容的话，现有的消费者必须做出变化才能使用。你可以选择保留旧版，让消费者逐渐迁移，但到了一定时候你还是要告诉他们旧版将要关闭。你也可以这么改，即从表面上看并不是后向兼容，但通过转换来实现后向兼容。比方说，如果你改变的是XML服务信息的结构而非添加任何新内容的话，那么通过转换是可以处理的。

我的建议是避免在中介中做这件事，而是在你的服务实现中做。将新的接口暴露为新的服务，但要把请求路由指向新服务实现的旧接口。在实现内侦测该请求是旧的还是新的，然后在此及响应路径进行转换。为什么这么做？性能。避免在网关中进行只在一个服务中出现的定制化活动，这样有可能会影响对其他消息流量的处理。

简言之，请在需要的地方使用网关，用网关来执行一组覆盖全体消息流量的、与特定消费者或服务无关的公共活动。如果你需要执行与特定服务相关的活动，如转换或协调，要么在服务容器自身内做，要么在只处理该服务流量的中介内做。