实际上，尽管我们再三地为业务、技术、以及混合的爱好者定义条款，但是定义仍然有欠缺之处，定义强调服务抽象概念的基本形态，也强调抽象概念和面向服务所选择的基础框架间需要建立联系。因此，不担心别人会挑剔 “具体的抽象概念”这一表述的矛盾，让我们钻研ZapThink到底用一个服务表示了什么。

　　技术实现，界面和抽象概念

　　正如在我们的ZapFlash(ZapFlash: ZapThink公司的时事新闻半月刊)服务集中的微妙中讨论的，即使在IT上下文中术语“服务”也都被多次使用。但是虽然ZapFlash将我们在SOA上下文中谈及的服务与其他IT服务进行了区分，此ZapFlash只完全集中于SOA上下文中的定义细节。甚至在相关的狭义上下文中，人们仍常对服务的抽象概念的级别感到困惑。基本上，SOA上下文中我们的抽象概念可分为三个级别：

　　1. 服务技术实现 —— 在抽象概念的这一级别上，我们谈论软件。一个服务技术实现是由运行代码组成。这就是服务组件基础框架存在的地方，它处理服务组件，服务组件是可以销毁或提供服务的技术实现(在下文的第二级含义中)

　　2. 服务接口 —— Web服务存在于这一级别，由Web服务描述语言(WSDL)文件提供接口的合同文本，但是不会提及根本的技术实现。然而Web服务不是唯一的服务接口类别，因为服务合同文本并不总是WSDL文件。有时服务界面是松散耦合的，但是很多时候并非如此。

　　3. 抽象服务 —— 一个交易容量或数据的表示法，交易能力或数据是指团体能与其他这样的服务一起实现交易过程的。一个抽象服务是典型的交易服务，但是抽象IT服务的角色并不是必需的，当然如果有的话更好。这样的交易服务是ZapThink所关注的服务种类，这也是成为SOA基础的核心抽象。抽象服务始终需要松散耦合，尽管特殊的耦合需求可有所不同。因而构造松散耦合的抽象服务变成了实现SOA的核心挑战。

　　到目前为止，一直都还不错 —— 但是此时真正的问题是我们怎么才能使一个抽象服务实际运转，我们支配的工具是服务技术实现、界面和随之而来的所有基础框架。谈论“业务性能表示法”是一回事，而把1和0串成能真正运行的东西又是另一回事。

　　服务合同文本，SOA技术实现，和松散耦合

　　理解抽象服务第一个重点是理解在服务和服务合同间存在典型的多对多关系，正如ZapThink在我们的ZapFlash 理解服务、合同和决策间的关系中解释的。显而易见，一个服务技术实现可能支持多种合同，任一合同都能符合一个特殊的服务接口，比方说为了一个特殊类型的消费者而定义的特殊服务接口。同样地，也许会有几个支持单个合同，以及相应的单个服务接口的技术实现，例如出于测量故障容错能力的目的。

　　然而用抽象服务，关系变成了我们可能称为“多对多对多”的：一个特殊的抽象服务可能有几个合同文本，这些合同文本描述了和不同消费者的关系，同时也描述多个服务接口，而这些服务接口每个都可能有一个或多个服务技术实现。这个方法可能听起来很复杂，但是这是把抽象服务松散的耦合的关键。为了说明这一点，让我们举个例子。

　　假定我们有一个客户信息服务，一个大型企业中的不同业务管道能销毁或创建此客户信息服务，来提供或更新业务管道所需的客户的任意信息。从交易角度，这是一个单纯的业务服务，由决策程序启动该业务后，可被任意业务管道使用。然而从IT角度，将客户信息实现为为一系列有不同服务合同文本的服务接口更有意义，这样可以支持各种各样的业务管道中可能的客户信息的略有不同的需要。此外，除了可能将这些服务和产品中的其他服务一起应用的决策系统之外，每个服务接口可能代表几个服务实现，这样SOA底层的管理框架能根据需要进行调节，以满足抽象服务和服务接口的合同中规定的服务标准。

　　在这个例子中，服务抽象的复杂性是必需支持抽象服务的松散耦合。例如，业务消耗装置的管道可能需要顾客信息的不同形式，或者可能要求服务返回部分是不同的数据。为了松散的连接这样的消费者，一个媒介(或媒介集)可能执行一次转换，以接收从服务接口的任何部分产生的输出，并将其转换成特殊消耗装置所需要的格式 转换按照适当的合同进行，此合同管理特殊消耗装置和抽象服务之间的连接。于是，以当时有效的运行时间决策系统为基础，管理基础架构(也可能是集成基础架构)可能提供基于上下文的路由，此路由是为了从特殊的服务接口到底层的技术实现之间的请求。

　　此外，一个服务接口可能支持几个合同文本，例如，当一个服务接口有多个绑定。在网络服务的情况中每个WSDL文件指定一个绑定，因此为了支持不止一个绑定，服务接口必须要有多个服务合同文本。每个绑定与它自身的服务技术实现通信，或者更为普遍的情况是多个技术实现可能支持每个绑定，或者一个技术实现可能支持多个绑定。

　　无论如何，松散的耦合不仅仅意味满足不同用户的不同需要，它还意味着变更的创建。因为我们有适当的操作、管理的基础架构，这使得抽象服务、抽象接口、抽象技术实现中可以建立多对多对多关系，在松散耦合方式中我们能够对那些需求修改等变更做出反应，换句话说，不需要破坏任何事物。

　　例如，如果一个消费者修改了必需的数据格式，我们能提出一个新的合同文本，这也许需要服务接口和抽象服务之间媒介的一个新转换，但是不会直接影响服务接口或任何一个服务技术实现。另一个例子是需要升级或增加一个新的数据源来支持服务。这样的变更可能需要一个或多个服务接口的一个新的技术实现。但是如果那些接口的合同文本没有变化，那么抽象服务就不受影响，消费者也就不受影响。第三个例子是决策升级，这将改变服务接口和他们的技术实现间的基于上下文的路由行为。实际上，我们将这个基于上下文的路由应用视作管理变更而不是集成作业，因为这需要支持运行时间决策变更。

　　ZapThink的收获

　　用这种面向服务方法去技术实现抽象服务时，有一个引人注目的副作用：计算你有多少服务变得困难。当然，在这个例子中，从交易的角度来看你有一个顾客信息服务，但是实际上它可能有很多个服务合同文本，每个合同文本都有几个接口——并且随着时间流逝，那些接口的数量会发生变化。你怎么计算服务可能影响你的SOA成熟模型，甚至影响诸如你的软件许可成本等，因此这个问题远比它看上去的重要得多。

　　归根结底，最重要的事是记住顾客信息抽象服务只是一个简单的例子。在一般情况下，必须依据手头问题的特殊性，从多种SOA框架模式中挑选一个架构，正如我们近期的ZapFlash SOA基础框架模式和媒介方法所解释的。概括地说是松散耦合提出的架构挑战，这种挑战是计划和技术实现SOA基础框架的核心。构造服务抽象概念提出了一个交易的单一化表示法，但是需要深层次的额外的努力以使抽象概念成为一个具体的客观存在。这是SOA的工作：实现和维护松散耦合的交易服务是任何SOA技术实现成功的关键。