根据SOA架构层级模型(图1)，业务逻辑经过面向服务架构(SOA)的软件分析和设计过程后，被分解为单个服务并绑定相应的可执行软件单元。以服务软件架构为输入，汽车服务软件的实现和部署工作主要在服务组件层(Service Components)完成(图1红色箭头)。

图 1 SOA 层级架构模型

01 满足 SOA 架构的服务组件架构

(Service-Component-Architecture)

针对服务组件，SOA定义了服务组件的架构模型(SCA)(图2)，在SCA的框架下，服务组件内部被分为业务逻辑(Service)与基础设施逻辑(Interface和Message)两部分，并互相解耦：

服务软件单元(Service)：业务/功能逻辑，不关心操作系统和编程语言，可由熟悉业务逻辑的相关方开发

接口(Interface)：决定对外提供哪些服务以及自身服务依赖哪些服务，不关心操作系统和编程语言，可由SOA架构设计方完成开发和部署

消息(Message)：接口数据的通讯链路/环境绑定，不关心操作系统和编程语言，可由SOA架构设计方完成开发和部署

整个服务组件层的工作是对服务组件进行规范型描述，描述内容主要包含两个部分:

服务组件架构模型SCA的配置描述

服务组件内部业务逻辑和基础设施逻辑的集成

图2 SOA服务组件架构模型(SCA)

02 服务组件架构SCA的配置描述

通过SCA架构模型，每个服务软件单元(Service)以标准的接口形式(Interface)向消费方提供服务内容，以统一的通讯协议传递序列化消息(Message)。对于SOA架构设计和应用人员，需要通过工具配置SCA架构模型中的参数，使其与服务管理组件一同实现SOA软件的部署和运作。

图3 SCA架构模型中的配置信息

SCA架构模型中的主要元素分为“服务接口”和“服务实现”两大类。其中，“服务接口描述”包含服务软件单元(Services)，组件接口(Interface)和消息通讯(Message)；“服务实现”则包括通讯协议绑定(Binding)和服务端口信息等(Endpoint)(图3)。

WebService的SCA架构模型配置描述

以IT行业SOA封装使用较为广泛的WebService为例，其对SCA架构模型的描述遵从如下标准协议:

表1 SCA架构模型中的配置信息

在IBM公司发布的SOA系统解决方案- 企业服务总线(Enterprise-Service-Bus)中提供了WebSphere Integration Developer开发环境，该环境支持配置生成符合WSDL规范的服务组件描述文档。

汽车软件的SCA架构模型配置描述

在汽车软件领域，当前，联合电子采用AUTOSAR Adaptive组织提供的模型描述规范。AUTOSAR Adaptive组织对SCA架构模型的描述遵循如下标准:

表2 SCA架构模型中的配置信息

03 汽车SOA软件的实现方案

如上文所述，汽车软件领域，联合电子遵循AUTOSAR Adaptive标准来完成SOA中间件的部署和应用，AUTOSAR Adaptive组件采用经典的代理(Proxy)-框架(Skeleton)模式来完成SCA架构模型的描述(如图4)。

图4 Proxy(stub)/Skeleton架构模式

这种模式将原本直接交互的调用者(Client)与被调用者(Server)分离，由代理负责传递信息来完成调用，client和server不需要处理通信层详细信息。同时，AUTOSAR Adaptive厂商基于C++语言具体实现代理-框架模式，确保应用服务开发人员可以灵活配置自定义的服务接口，并结合对应工具生成SCA架构模型代码(.cpp/.cc)和配置文件(.json)。具体的，这些代码：

封装了SOME-IP协议栈和底层通讯细节(Middleware Transport Layer)

提供了相应的服务虚接口(virtual function)

通过1)，服务组件开发人员不必再关心服务Message对应的协议如何实现；通过2)，服务组件开发人员基于C++的语言特性，可继承(inherit)虚接口并覆写(override)虚接口的具体实现(函数体)。该机制保证了“基础设施逻辑”和“业务(功能)逻辑”的解耦，服务内部业务逻辑的改动不影响服务组件向外的接口提供。

04 SOA服务组件实现和部署的具体步骤

SOA服务组件“实现和部署”的整个过程以面向服务(SOA)的软件架构为输入，内容上除完成第二章提到的“基础设施逻辑”配置工作外，还需将业务(功能)逻辑与基础设施逻辑集成，最终编译成可执行的服务组件单元(Service Component)(图5)。

图5 服务组件单元(Service Component)

如第一章中对服务组件的SCA描述，整体服务组件(Service Component)由服务单元(Service)提供的“业务逻辑”和适配目标系统环境相关的“基础设施逻辑”两部分组成。在开发过程中，这两部分是解耦的，可同时进行的，且软件形态是灵活的。

服务单元(Service)的逻辑可以是源码或被封装为SDK形式，且不关心具体的编程语言；基础设施逻辑 (Interface和Message) 则以C++的形态编码，与服务管理中间件一起确保服务的动态响应性和服务自身的可扩展性，其软件形态同样可以是源码或SDK形式提供。

在流程上方法论上，”实现和部署”工作主要分为服务组件接口设计，服务组件集成实现和安装部署三个步骤：

组件接口设计阶段: 联合电子编写arxml完成对服务组件SCA中“基础设施逻辑”的配置开发，并经由AUTOSAR Adaptive中间件供应商提供的代码框架和生成器(Generator)，最终得到相关的配置文件(.json)和源代码(.cc/.cpp)；对“服务单元逻辑”，联合电子可同步基于建模工具进行开发；

组件集成实现阶段: 联合电子编写APP框架，完成“服务单元逻辑”与“基础设施逻辑”的软件集成工作；

组件安装部署阶段: 联合电子编写编译和安装脚本，完成源码的编译链接和可执行文件(App)的安装，同时，对APP安装部署权限和系统环境做适配调整。

“分析和设计面向服务的架构”、“实现和部署面向服务的软件”是有效开发SOA汽车软件的关键环节，“实现和部署面向服务软件”的过程是SOA软件可以“落地”不可或缺的环节。联合电子可以提供SOA软件开发工程服务: 该软件工程服务以运动域控制器XCU作为硬件载体，采用AUTOSAR Adaptive组件作为SOA服务管理的中间件，最终可在XCU这样符合SOA架构的开放性软件平台上提供SOA服务组件产品。