【上汽零束SOA】云管端一体化SOA软件平台系列介绍之五：服务实现篇

近来SOA技术在汽车圈可谓是风生水起， 各路大咖关于SOA的文章也层出不穷，有写电子电气架构的，有写服务设计的，有写具体实现协议的，而我接下来从SOA软件实现的角度，结合一个具体的软件开发实例，让更多的朋友们理解什么是SOA，SOA背后的实质是什么，SOA框架承担哪些职责，SOA服务开发者要做哪些事情，SOA开发过程中可能潜在哪些问题等等。

SOA是一种方法论， 除了公认的一些特点外（譬如接口契约， 松耦合等），业界尚未有统一的定义。既然没有统一的定义，也就没有统一的实现方式。不过得益于一些标准化协会、开源组织及商业公司的共同努力，业界一时间出现了很多SOA框架，譬如W3C组织定义的Web Service，OMG组织定义的Corba，微软的WCF，阿里的duboo等，在很多领域（尤其是互联网领域），SOA架构成为大量应用场景首选的解决方案。

而在汽车领域，目前非常热门的框架要数Genivi组织定义的CommonAPI和AUTOSAR组织定义的Adaptive AUTOSAR（简称AP）（AP平台内容较多， SOA框架核心部分是ara::com）。AP的ara::com和CommonAPI有很多的相似性，对于开发者而言，CommonAPI实现起来会容易许多，而且CommonAPI是开源的，而AP则多是由商业公司（譬如Vector, Electrobit等公司）闭源提供。本文将基于开源的CommonAPI介绍，同时对比AP实现，让大家看到更多实现细节的同时，也可以看到CommonAPI和AP的差异。

当然，上汽零束的云管端一体化SOA软件平台也提供基于SOA的服务开发工具链和方法论，相关信息零小束也会在日后逐步公开，敬请期待。

一、设定应用场景

首先我们还是基于一个应用场景来定义服务。譬如以导航为例， 可以把计算一条路径的模块定义成一个服务。原因很简单，算路过程里面的实现还是蛮复杂的，里面会用到若干算法，通过把算路定义成服务，可以很好的把算路过程分离出来，很多基于算路的应用，譬如HMI等可以独立于算路模块，单独进行设计，这样可以达到模块解耦的目的。如下图所示：

二、服务接口定义

首先我们得认识一下什么是服务接口， 服务接口不同于传统应用的函数接口。因为SOA有一个基本特点，就是“接口契约”。“接口契约”简单点说就是一种接口描述语言IDL，不同的SOA框架接口描述