介绍服务代理接口

　　因此，如果改造的中间件不是解决问题的方案，那么什么是呢？答案当然就是架构。但这么说只是问题的一小部分。那我们还按照集成开发者的语言来说，如果你不能依靠任何个别开发商的解决方案来使其完全工作，那么让我们探究一下系统是怎么设计的。如果你想建立一个服务消费者来消费或组成一些功能，但是你还不知道这些功能在哪，甚至不知道如何与其通讯。至少有三种方法可以应对这个特殊的挑战。首先，你可以先和代理谈一下（或者经济人或者中间人），这要用一种你懂的语言和在你已经知道的位置，向这个能够代表消费者的代理发送请求。这是一个“信封里面的信封”概念。基本上，你封装了一份信息，要交给一个你认识的人，但是你不知道他在哪，但这个信封上标的给谁你是知道的。那个人然后打开信封并且将内部的信封交给最终的收件人。这种方法简化了服务消费者必须要知道变化的问题，因为他们只需要知道代理和最终接收者就可以。从技术角度，使用WS寻址简化了这个方法。本质上，服务消费者只需要知道提供者的WS-地址并将其交给服务代理接口解决和提交。

　　我们以前讨论过服务中介的概念。此方法的问题在于服务代理接口仍然需要另找方法来提交信息，并且如果代理接口将所有的规则都保持在黑匣子内部，我们仍然会有和EAI2.0类型ESB solutions相同的问题。这是登记处的入口。服务代理接口不应该存储他们自己的规则，但应该从记录的中央系统中取得所有的路线、位置和基于策略的约束规则。在SOA中，这是登记处的角色。代理接口结果可以缓存登记处look-ups结果用以提高性能，但是元数据自己应该从登记处里面来。

　　因此登记处配置服务代理接口解决了很多服务通讯的问题，但是它仍然留下了服务消费者和服务代理接口之间联系的问题。如果代理接口移动或不可用的话怎么办？服务消费者怎样发现首要位置的服务代理接口？问题的答案就是使用基于登记处的“后期捆绑”。在这个方案中，服务消费者检测登记处来发现代理接口在哪里，这可能建立在服务消费者目前所在位置和与什么样的协议通讯的基础上。有人可能会想我们可以在登记处里面发现其元数据后，直接将服务消费者与服务提供者绑定。问题在于如果服务提供者正在使用一些交替协议或者位置在服务消费者不能达到的地方，我们就会有通讯方面的问题。因此，即使我们在登记处发现了元数据，我们仍然不希望服务消费者和提供者之间的直接通讯。

　　因此这里的最佳解决方案就是使用基于注册表的“后期绑定”来帮助服务消费者来发现代理接口并帮助他们解决服务提供者到WS-Addresses。然后，服务消费者与代理接口通讯，提供WS-Address和通讯所需的元数据。这就使得服务消费者非常简单，促进一套分布式的、多样的服务代理接口，代表服务消费者来实施通讯。这种情况下，公司可以使用和混合一系列技术和方法包括基于硬件的网络中间人、软件代理接口甚至常驻在服务消费者底端的代理商，来执行服务代理接口。

　　最后，在上述情况下，ESB位于何处呢？答案就是没有地方，除非你相信ESB是一种模式而不是一个产品（像IBM曾经提倡的那样）。ESB还需要吗？不是必须的了。那你购买一个的话感觉会好吗？可能吧。当然，这些代理接口怎样呢？ESB开发商当然希望你相信他们的产品，在配置中使用他们的产品，这绝对是事实。他们的产品能使用。问题不在于ESBs不能制作好代理接口。它们当然能，我这里想特别的指出。但是你也可以不使用它或者使用你现存的基础结构，它照样工作。可悲的是大多数的集成架构师并没有将ESBs当做服务代理接口来使用，而是当做EAI2.0 中心辐射或者消息总线中间人，协调Web服务集成，而非SOA。

　　如果你想一想，我们已经在以前实施过复杂的、各种各样的网络。电脑通过DHCP、网关和路由来做网络工作，这样的方式比直接的、点对点IP通讯要先进很多。这基本上就是我们所说的服务通讯。明白了这一点就说明你理解了这不是一个技术问题，而是一个架构问题。

　　要实现SOA，你必须认识到服务这个概念是一种抽象，而非一种接口。一旦你理解了抽象，那这就变得很清楚了。因此你需要对你的SOA初衷做一下反思。你是在用EAI2.0做Web服务集成（WSI）？还是你真的已经将你的架构变成了在异质性和持续变化的环境中面向服务的了？如果你在用EAI 2.0做WSI，你会发现你还要不停的解决相同的问题。而使用SOA，你会发现你能的持续的解决新问题。