面向服务架构(SOA)的汽车软件实现和部署.docVIP

面向服务架构(SOA)的汽车软件实现和部署  根据SOA架构层级模型(图1)，业务逻辑经过面向服务架构(SOA)的软件分析和设计过程后，被分解为单个服务并绑定相应的可执行软件单元。以服务软件架构为输入，汽车服务软件的实现和部署工作主要在服务组件层(Service Components)完成(图1红色箭头)。 图 1 SOA 层级架构模型 满足 SOA 架构的服务组件架构 (Service-Component-Architecture) 针对服务组件，SOA定义了服务组件的架构模型(SCA)(图2)，在SCA的框架下，服务组件内部被分为业务逻辑(Service)与基础设施逻辑(Interface和Message)两部分，并互相解耦： 服务软件单元(Service)：业务/功能逻辑，不关心操作系统和编程语言，可由熟悉业务逻辑的相关方开发 接口(Interface)：决定对外提供哪些服务以及自身服务依赖哪些服务，不关心操作系统和编程语言，可由SOA架构设计方完成开发和部署 消息(Message)：接口数据的通讯链路/环境绑定，不关心操作系统和编程语言，可由SOA架构设计方完成开发和部署 整个服务组件层的工作是对服务组件进行规范型描述，描述内容主要包含两个部分: 服务组件架构模型SCA的配置描述 服务组件内部业务逻辑和基础设施逻辑的集成 图2 ?SOA服务组件架构模型(SCA) 服务组件架构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规范的服务组件描述文档。 在汽车软件领域，当前，联合电子采用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)虚接口的具体实现(函数体)。该机制保证了“基础设施逻辑”和“业务(功能)逻辑”的解耦，服务内部业务逻辑的改动不影响服务组件向外的接口提供。 SOA服务组件实现和部署的具体步骤 SOA服务组件“实现和部署”的整个过程以面向服务(SOA)的软件架构为输入，内容上除完成第二章提到的“基础设施逻辑”配置工作外，还需将业务(功能)逻辑与基础设施逻辑集成，最终编译成可执行的服务组件单元(Service Component)(图5)。 图5 ?服务组件单元(Service Component) 如第一章