服务消费者与服务提供者通讯的问题

　　在典型的集成环境中，你首要关心的是数据的移动或者业务逻辑的合并以便完成特别的任务。在这种思想指导下，大多数集成开发者考虑的是输入(“gazintas”), 输出 (“gazattas”)、转移和转化。这就是说他们思考的是如何将数据或应用系统功能从一个系统里面提出来、如何进入另外一个系统，还需要思考他们使用的机制，即如何从一个位置到另一个位置得到信息或功能，从一个格式、协议、上下文、流程、策略转到另一个的过程中，他们需要做什么来处理它。因此，架构师就是化学家——这就是说，他们要努力理解系统和它怎样被放在一起的，而集成开发者是化学工程师——只是集中在转化的机制方面。

　　以集成为中心的角度考虑，大多数开发商将服务的概念只看做是另一种形式的gazinta 或者gazatta。这意味着这些集成精英们需要发现一些别的东西来完成转移和转换。开发商来挽救吧！大多数的开发商回应此需求的做法就是简单的去除现存的集成中间件。最终用户对付这种重大转变很容易，不信你瞧，他们现在已经有了转移和转换，可以处理他们基于服务的gazintas/gazattas。但是这就是在做SOA吗？噢！不，不，不。我们已经提醒过你N次了。因此，让我们采取另外一个行动吧。这种方法的错误之处在于服务消费者（你可能会认作gazinta）不应该直接和服务提供者（你可能会错误的认作gazatta）来通讯。

　　为什么？首先，SOA的主要概念是我们在连续异构性的环境下，通过建立一个架构模型、规则和抽象来处理经常出现的、不可预料的变化。这意味着我们不得不在不知道如何使用的情况下设法开发性能。当我们深入研究以前的ZapFlash中松散耦合的七个方面时，我们需要在各方面，包括实施、基础结构、契约、进程、策略、数据模式和语义拥有巨大的可变性。有了这种可变性，公司在业务和IT方面就有了稳定性，甚至当IT和业务在不断变化时。当我们实现那种抽象时，敏捷、可预见性、可靠性、可视性和成本效益都会更加现实。

　　实现此抽象，意味着我们在事情变化的时候我们依然应该保持相关服务而不能中断。很多在IT或者业务环境中的事情都会变化，例如服务的位置和有效性；服务实施和契约的版本控制；业务流程和策略的变化；对报道、可见性、控制的新的或者变化的要求；当然还需要新性能用以解决出现的业务问题或利用新的业务机会。但是如果你认为服务只是一个API，那么当你试图将一个服务客户与服务提供者直接联系起来的时候，那么接下来的一切都会乱哄哄的。提供者移动时怎么办？服务契约变化时怎么办？如果提供者不再可用怎么办？如果你现在需要一个新的通讯机制或者数据模式改变怎么办？

　　对于大多数集成“架构师”来说，对这种复杂性的下意识反应就是在服务客户和服务提供者之间加入一些技术片段，用以改良此问题。初衷是好的，如果你希望拥有变化性，你就不能有直接通信。但是执行起来又全是错的了。如果你依靠这个“黑匣子”和专利科技来管理服务通讯差异这个难题，你只是将所有的复杂的事情和工作都从底端（服务）转移到了一个更复杂、昂贵和靠不住的中间点来了。欢迎来到EAI2.0，其秘密的和未公开的名字大多人称做企业服务总线（ESB）产品——或者至少很多人现在这么称呼它们。