从能力开放平台角度谈SOA实施思路(10.10)

对于能力开放平台或者叫Open API平台，一个典型的特征就是以轻量的Rest API接口进行发布，同时全部以提供服务接口为主，而很少主动去消费外部系统的服务。其核心的原因仍然是当我们把内部的一个或多个业务系统的能力进行开放的时候，我们很清楚究竟需要暴露哪些接口和服务，包括每一个接口服务的数据项，而并不需要和消费方的系统进行逐个沟通和确认。

内部业务系统将所有的信息通过能力开放平台暴露出来，即所有的API接口服务全部注册和接入到ESB或轻量的SOA服务总线，提供统一的服务目录库。如果没有暴露的那就是本身就没有该数据或者数据涉及安全性要求而不能被暴露。

能力开放平台暴露所有的接口服务能力，形成完整的服务资产，那么剩下的事情就相对简单，外围的业务系统只需要去选择和订购服务，对于订购的服务在审批或确认通过后，只需要能力开放平台配合进行联调即可。也就是说能力开放平台在后期的服务实施过程中唯一的工作就是提供服务消费指南，同时配合外围业务系统消费方进行服务的联调。

接入能力开放平台的服务不用去考虑适配外部的业务系统，而是外部的业务系统需要来适配能力开放平台提供搞得标准API接口服务。因此大量的适配，映射或转换工作都转移到消费方来实现。

在当前互联网可以看到对于电商的Open API平台，传统电信运营商的PaaS能力开放平台，包括物联网的云服务平台，大数据服务平台等基本都是按能力开放平台的思路进行构建。如果能力开放平台本身需要去消费外部业务系统的服务，那么自然也就算不上自身能力的开放了。

注意能力开放不仅仅是自身已有的数据进行开放和暴露，或者内聚在自身系统里面的业务规则暴露为标准的业务服务，同时当我们需要外部业务系统提供数据给我们的时候，也可以提供标准的能力开放接口，只是这类接口是导入类服务接口而已。

能力开放平台更多的是以自我为中心去考虑服务接口的设计，因此对于查询类服务接口往往存在两种情况。其一是数据不落地的情况下实时调用，自然能够很好的满足数据的实时性要求；但是如果是数据落地模式下的定时数据增量同步调用，那么往往就很难满足实时性要求。正是这个原因在设计定时查询类服务接口的时候，需要考虑是否增加数据变化的实时消息事件通知机制，以满足实时性的要求。