SOA 架构概述
一、Web 服务 SOA 相关技术规范概述
Web 服务作为 SOA 架构技术发展的典型和成熟代表其促进了 SOA 架构技术的发展和推广,其标准体系的开发方式和开发内容对于车载 SOA 软件架构技术规范开发具有深入的指导意义。
1、技术标准组织
SOA 架构的 WEB 服务相关的标准化组织主要有三家,分别为万维网联盟(WorldWideWeb ConsortiumW3C)、结构信息标准化促进组织(Organisation for the Advancement of Structureo Information Standards,OASIS)和 Web 服务互操作组织(Web Service Interoperability Organisation, WS-1)
(1)W3C
W3C 是一个专注于开发基于 Web 的行业技术标准的国际联盟。它的使命是通过开发协议和指导方针,确保万维网作为一种多功能媒体的长期增长使万维网充分发挥其潜力。1994 年 TimBerners-Lee 创建了 W3C 因为跨网络分割的风险变得越来越明显(特别是在多个版本的 HTML 同时工作时)。从那时起 W3C 就开始优先开发核心的 Web 技术(HTMLXML 等)以及相关的样式化语言(CSSXSLT 等)。如今 Web 服务严重依赖于 W3C 开发的技术 W3C 委员会制作 Web 服务技术主要由以下几部分:
· XML 架构 1.0;
· WSDL1120;
· SOAP1.11.2;
· WS-Addressing1.0;
· wS-Policy1.5;
(2)OASIS Wawindows
OASIS 成立于 1993 年,是一家非营利性的国际协会,旨在开发、整合和推广包括 Web 服务、安全、商业事务、供应链、电子政务、互操作性等所需的标准。OASIS 对 Web 服务的贡献包括对 UDDI(Universal Description Discovery and Integration)规范的标准化,以及对 WS-BPEL 规范的标准化。此外 OASIS 也推出了诸如面向服务的架构参考模型和面向服务架构的相关规范等。OASIS 和 W3C 不同,它的主要兴趣在于制定附加规范以及支持不同的行业,与应用领域的关系更为密切。
(3)WS-I
WS-I 成立于 2002 年,其目的不是建立新的标准,而是旨在推动 Web 服务的互操作性。具体目包括三个方面:
1)为客户的网络服务应用提供实施指导和培训;
2)促进跨平台、跨应用软件和跨程序语言的网络服务的一致和兼容,并保证可靠兼容;
3)致力于使网络服务协同成为本行业共同遵守的准则,以帮助客户在网络服务技术的选择上轻松决策,提高网络服务的应用范围和水平,并确保网络服务技术的持续发展。
2、技术标准的形成
(1)标如何被开发出来?
为了充分利用 Web 服务技术最大潜力发掘其技术价值理解并将技术规范开发为已批准的行业标准的过程是很重要的。
这一切都始于新技术的原创想法,当社区对这个想法有足够的兴趣时,W3C 就会举行一个开放的研讨会,相关方聚在一起讨论技术解决的范围和技术提出的解决方案。
就 Web 服务而言,供应商组织通常倡议他们独立或合作开发的技术,虽然这些技术常常用来解决那些对供应商来说很重要的问题,但人们希望让它们成为非专有的 Web 服务框架的一部分。如果 W3C 参与者之间有足够的协议,那么这些所提出的技术将成为创建行业标准的基础。
(2)标准开发流程是怎样的?
W3C 技术规范声明周期的第一步是成立一个负责定义目标标准的工作组。该组将由 W3C 成员组成他们通常由供应商代表和从业者组成。W3C 还提供了支持的技术人员,帮助确保该技术将完全补充其他已经开发的行业标准。
然后,该组通过以下阶段开发一个规范:
1)工作草案-这是一个定期发布的规范的快照,以让社区了解工作组所采取的方向,并收集早期的意见。
2)最后一次呼叫工作草案--当工作组认为该规范满足其所有原始要求时,它将发布此文件并正式请求社区的意见。这一步骤通常至少持续三周。
3)候选推荐--纳入前一阶段的反馈后,工作组要求实施规范,以确保规范实际上是可实现和互操作的。
4)建议--证明规范已以互操作方式成功实施,已提交 W3C 咨询委员会批准,这一步骤至少会持续四周。
5)建议--规范为 W3C 建议,通常称为“行业标准”。
整个过程的持续时间因所开发规范的范围和复杂程度而不同。从一个工作组成立的那一刻起,它可能需要 18 个月到几年的时间来提交 W3C 建议。在这些阶段,公众可以通过提交工作组有义务回应的反馈,对正在制定的技术规范发表评论。工作组成员之间的所有通信和工作组的所有交付成果都发布为公开访问。
W3C 的一个特殊性是,它的过程是基于共识的,这意味着整个工作组在做出决定之前需要就解决方案达成一致。投票只有在有严重分歧的情况下才会进行投票,而通过投票作出的任何决定通常会在剩下的过程中进行仔细审查。
二、 AUTOSAR-AP 平台 SOA 相关技术规范概述
AUTOSAR-AP 平台采用 SOA 方法论主要涉及一种自适应软件产品的开发,是一套包括软件分析.设计、开发、部署在内的复杂工作流程。主要包括两个方面:工作流定义与成果物定义。具体描述如下:
(1)流程定义
AP 平台的方法论作为 CP 平台的扩展,其引入了新的概念,AP 平台软件的实例是在进程的上下文中执行。AP 平台引入了“机器”(Machine)的概念“机器”是虚拟化的 ECU 一个可以部署软件的实体。
它可以是真实存在的处理器也可以是一个虚拟机,AP 软件则运行在某一特定的“机器”上。
(2)开发服务接口(Service Interface)
AP 平台是一个面向服务的软件架构(SOA)基于 AP 平台的软件开发首先需要进行服务接口的设计。服务接口可以由事件(Events)、方法(Methods)和字段(Fields)组成是生成软件组件头文件的基础。
(3)开发通信结构(Communication Structure)
OEM 在设计阶段需要指定预期“机器”(Machine)的通信结构以及相应的配置参数,包括机器的所有网络端点和服务发现地址端口等。这一步将产生一个可交付的“机器设计”(MachineDesign),一个特定的“机器”模型将引用一个特定的“机器设计”模型。
(4)开发自适应应用软件(Adaptive Application Software)
自适应应用软件开发从软件组件(SWcomponent)的设计开始软件组件是通过其端口(Port)定义的,每个端口实现一个服务接口。基于服务接口描述,生成包含实现软件组件的头文件。开发人员在此基础上实现软件组件的核心功能。
(5)开发自适应平台软件(AdaptivePlatformSoftware)
与应用级软件类似,平台级软件可以由基于标准化服务接口的软件组件组成,也可以直接实现而不需要软件组件模型。
(6)定义和配置机器
包括了功能组状态和每个状态超时的定义,进程到特定机器的映射,以及平台服务(例如 NM、 DolP)和基础模块(例如日志)配置等。此过程会产生一个独立于服务实例或应用程序的机器清单
(Machine Manifest)
(7)集成软件
软件的实现和编译完成后,需要集成到一个可执行文件(Executable)中。通过进程来定义特定机器上可执行文件的实例化,每一个进程会产生一个执行清单(ExecutionManifest),其中包括了进程及其启动配置。
(8) 定义和配置服务实例(ServiceInstance)
首先对服务接口进行部署,然后定义服务接口的实例,并决定是否提供或使用该服务实例。其次要建立服务实例到机器的映射,以及服务实例到端口的映射。此过程会产生进程所需的所有服务实例清单(Service Instance Manifest)。
(9)生成软件包(SoftwarePackage)
将可执行文件及所需清单整合为软件包上传到机器上,而无需重新刷写。OEM 可以将软件包存储在后端服务器中进行统一管理。
(10)成果物定义
由于 AUTOSAR 的工作流包含了整个汽车软件开发流程,涉及多个开发角色,因此需要各个开发角色之间有信息交互为了保证信息不出现二义性需要对各个环节的工作成果物规则进行定义。同时为了信息的保存、传输交互的需求,需要定义这些成果物的载体,ARXML 就是定义了不同流程成果物的载体使用不同的标签来表示不同的信息及流程,这些标签的定义就是 AUTOSAR 的数据元模型。
· M0:使用 M1 级规则生成的可运行软件实体,例如车门控制的可自行软件组件
· M1:使用 M2 级规则定义软件组件,例如车门控制的软件组件,软件组件的表现形式可以是 ARXMLC/C++语言或各类文档。一般情况下会使用工具链以 ARXML 的形式定义软件组件的框架,然后导入下游工具链生成目标语言。或直接生成目标语言框架,然后手写代码的形式完成整体的软件组件;
· M2:使用 M3 级规则定义使用 AUTOSAR 开发的元素语法及规则,例如软件组件 port 口机器,
清单等。该级别的元素与具体的功能无关,类似于各类开发语言的语法;
· M3:用于定义 M2 的元模型
本文节选自中国汽车基础软件生态委员会(AUTOSEMO)本月发中国汽车基础软件发展白皮书 2.0》,如需获得完整报告,请下载。资料下载链接:https://pan.baidu.com/s/1rOTeFu4oJVRNjIzTcIOaVQ 提取码:d72b
原文链接:https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7547
评论