CN116319983A - 一种面向服务通讯的中间件 - Google Patents

一种面向服务通讯的中间件 Download PDF

Info

Publication number
CN116319983A
CN116319983A CN202211569508.4A CN202211569508A CN116319983A CN 116319983 A CN116319983 A CN 116319983A CN 202211569508 A CN202211569508 A CN 202211569508A CN 116319983 A CN116319983 A CN 116319983A
Authority
CN
China
Prior art keywords
communication
service
protocol
interface
layer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211569508.4A
Other languages
English (en)
Inventor
徐凯
袁征
韩媛
罗辉
石颖锋
朱俊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ecarx Hubei Tech Co Ltd
Original Assignee
Ecarx Hubei Tech Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ecarx Hubei Tech Co Ltd filed Critical Ecarx Hubei Tech Co Ltd
Priority to CN202211569508.4A priority Critical patent/CN116319983A/zh
Publication of CN116319983A publication Critical patent/CN116319983A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/30Profiles
    • H04L67/306User profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明实施例提供一种面向服务通讯的中间件,包括:服务部署应用层,用于向服务应用软件的开发及部署提供统一的组件接口以及配置和代码生成工具;服务通讯接口层,用于向服务应用软件提供统一的应用调用通讯接口以及代码生成工具对应的工具生成接口;服务运行代理层,用于向服务应用软件提供统一的运行所需的通讯代理以及通讯回调处理机制;服务通讯管理层,用于通过服务运行代理层提供的通讯代理接口,对服务应用软件的通讯过程进行通讯管理,以及为服务应用软件提供适配的通讯传输所需的通讯协议接口;服务通讯传输层,用于集成服务通讯传输依赖的至少一种通讯传输协议。该中间件能够进行跨平台移植,支持多系统、多协议栈。

Description

一种面向服务通讯的中间件
技术领域
本发明涉及通信技术领域,尤其涉及一种面向服务通讯的中间件。
背景技术
随着智能汽车电子电气架构从分布式到跨域融合再到中央计算平台的E/E演变,传统的封闭式的静态分布式面向信号通讯的架构(Signal-Oriented Architecture)由于通讯软件和组件绑定,运行时灵活性低,无法扩展复用到其他软件通讯模块实现多域融合,因而不再满足当前汽车E/E架构的要求。而面向服务通讯的软件架构(Service-OrientedArchitecture,SOA),则因其“接口标准可访问”、“高度解耦”、“高可扩展性”、“高可复用性”将成为未来汽车领域“软件定义汽车(Software Defined Vehicles,SDV)”的技术基础。
SOA在互联网行业发展比较成熟并有完整的生态应用,但在车联网智能驾驶(Advanced Driving Assistance System,ADAS)领域还处于摸索发展阶段。现有软件技术仅支持单操作系统、单协议栈,而对于支持多操作系统、多协议栈目前还没有完整的成熟的解决方案。主要是由于其高度的系统复杂性、严格的功能安全认证使得汽车软件中间件还未能形成行业内统一的标准和统一的通讯协议,智能网联跨域数据共享和通讯交互问题仍然有待解决。
发明内容
本发明实施例提供了一种面向服务通讯的中间件,以能够支持跨平台移植,支持多系统、多协议栈,实现解耦软硬件、异构网络通讯的效果。
第一方面,本实施例提供了一种面向服务通讯的中间件,包括:
服务部署应用层,用于向服务应用软件的开发及部署提供统一的组件接口以及配置和代码生成工具;
服务通讯接口层,用于向服务应用软件提供统一的应用调用通讯接口以及代码生成工具对应的工具生成接口;
服务运行代理层,用于向服务应用软件提供统一的运行所需的通讯代理以及通讯回调处理机制;
服务通讯管理层,用于通过服务运行代理层提供的通讯代理接口,对服务应用软件的通讯过程进行通讯管理,以及为服务应用软件提供适配的通讯传输所需的通讯协议接口;
服务通讯传输层,用于集成服务通讯传输依赖的至少一种通讯传输协议,以使服务应用软件通过在服务通讯管理层确定的通讯协议接口,进行相匹配通讯传输协议的调用。
本发明实施例提供一种面向服务通讯的中间件,包括:服务部署应用层,用于向服务应用软件的开发及部署提供统一的组件接口以及配置和代码生成工具;服务通讯接口层,用于向服务应用软件提供统一的应用调用通讯接口以及代码生成工具对应的工具生成接口;服务运行代理层,用于向服务应用软件提供统一的运行所需的通讯代理以及通讯回调处理机制;服务通讯管理层,用于通过服务运行代理层提供的通讯代理接口,对服务应用软件的通讯过程进行通讯管理,以及为服务应用软件提供适配的通讯传输所需的通讯协议接口;服务通讯传输层,用于集成服务通讯传输依赖的至少一种通讯传输协议,以使服务应用软件通过在服务通讯管理层确定的通讯协议接口,进行相匹配通讯传输协议的调用。上述技术方案提供的面向服务通讯的中间件能够进行跨平台移植,支持多系统、多协议栈,实现解耦软硬件、异构网络通讯的功能。
应当理解,本部分所描述的内容并非旨在标识本发明的实施例的关键或重要特征,也不用于限制本发明的范围。本发明的其它特征将通过以下的说明书而变得容易理解。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例一提供的一种面向服务通讯的中间件的结构示意图;
图2为本发明实施例一提供的另一种面向服务通讯的中间件的结构示意图;
图3为本发明实施例一提供的一种面向服务通讯的中间件中服务通讯消息的封装示例图;
图4为本发明实施例一提供的一种面向服务通讯的中间件通讯“发布/订阅”使用示例图;
图5为本发明实施例一提供的一种面向服务通讯的中间件通讯“请求/响应”使用示例图;
图6为本发明实施例一提供的一种面向服务通讯的中间件“发布/订阅”通讯数据流的传输示例图;
图7为本发明实施例一提供的一种面向服务通讯的中间件“请求/响应”通讯数据流的传输示例图;
图8为本发明实施例一提供的一种面向服务通讯的中间件通讯发送消息的时序示例图;
图9为本发明实施例一提供的一种面向服务通讯的中间件通讯接收消息的时序示例图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明保护的范围。
需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“原始”、“目标”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
考虑到目前行业内面向服务的通讯协议主要有SOME/IP(Scalabe Service-Oriented Middleware Over IP)和DDS(Data Distribution Service)两个主流协议架构,对于原始设备制造商来说,当有服务化的需求时,将直接交付基于SOME/IP或者DDS协议把服务程序编译打包成和协议绑定的库。除此之外可能还有其他超文本传输协议(HyperText Transfer Protocol,HTTP)、消息队列遥测传输(Message Queuing TelemetryTransport,MQTT)等面向服务的通讯协议栈,虽然这些协议都是面向服务的,但是不同的通讯协议的接口、消息数据帧和协议运行时相互之间是不兼容的,对于应用集成来说,如果绑定通讯协议栈,那么一旦服务组件有改动,所有相关的应用都将进行修改,使得应用代码无法复用和扩展。
针对现有软件技术目前仅支持单操作系统、单协议栈,对于支持多操作系统、多协议栈目前还没有完整的成熟的解决方案,因此,需要一种能够解决上述问题的方案。
实施例一
图1为本发明实施例一提供的一种面向服务通讯的中间件的结构示意图,该方法可适用于支持多操作系统、多协议栈的面向服务进行通讯的情况。如图1所示,该面向服务通讯的中间件,包括:服务部署应用层10、服务通讯接口层20、服务运行代理层30、服务通讯管理层40以及服务通讯传输层50。服务部署应用层10,用于向服务应用软件的开发及部署提供统一的组件接口以及配置和代码生成工具;服务通讯接口层20,用于向服务应用软件提供统一的应用调用通讯接口以及代码生成工具对应的工具生成接口;服务运行代理层30,用于向服务应用软件提供统一的运行所需的通讯代理以及通讯回调处理机制;服务通讯管理层40,用于通过服务运行代理层提供的通讯代理接口,对服务应用软件的通讯过程进行通讯管理,以及为服务应用软件提供适配的通讯传输所需的通讯协议接口;服务通讯传输层50,用于集成服务通讯传输依赖的至少一种通讯传输协议,以使服务应用软件通过在服务通讯管理层40确定的通讯协议接口,进行相匹配通讯传输协议的调用。
服务部署应用层10,用于向服务应用软件的开发及部署提供统一的组件接口以及配置和代码生成工具。
其中,服务应用软件具体可以理解为车辆上安装的需要面向服务通讯的应用程序(APP),例如,高阶自动驾驶算法应用程序。服务部署应用层10用于实现本实施例提供的中间件与服务应用软件之间的交互。服务部署应用层10中可以提供给服务应用软件相关组件接口。
在本实施例中,服务部署应用层10可以包含应用基础组件,应用基础组件主要用于提供通讯、调度、配置解析和其它核心基础设施。应用基础组件以通讯节点作为部署载体,服务应用软件中需要通讯的应用实例均部署在通讯节点上。通讯节点可以通过创建通讯服务实例来加载和启动服务应用软件需要通讯的应用实例。示例性的,通讯服务实例可以包括:消息订阅器、消息发布器、消息请求器以及消息响应器。
另外,服务部署应用层10还提供中间件相关的配置,相关配置可以配置文件集的方式进行体现。配置文件集主要提供中间件系统相关的配置以及服务应用软件的消息数据结构体的定义。根据面向服务通讯的特点和需求,可以进行相关信息的配置,以形成配置文件集。示例性的,针对面向服务的通讯来说,需要配置通讯服务实例清单、通讯协议清单、消息定义清单以及其所对应部署的节点配置等。
可以理解的是,服务部署应用层10还包括代码生成工具,代码生成工具用于根据上述所述配置文件集生成服务通讯接口层20的工具生成接口。代码生成工具主要是通过抽象与业务无关的模板接口来高度减轻服务应用软件开发的工作量,同时结合应用基础组件封装的统一接口,从而实现服务应用软件和中间件完全解耦。
需要说明的是,当服务应用软件通过中间件发送消息时,服务应用软件需要发送消息时,会通过服务部署应用层10的应用基础组件封装的通讯接口发送原始数据和消息ID。当服务应用软件通过中间件接收消息时,中间件会将执行处理结果返回给服务应用软件。
服务通讯接口层20,用于向服务应用软件提供统一的应用调用通讯接口以及代码生成工具对应的工具生成接口。
在本实施例中,遵循“发布/订阅”、“请求/响应”通讯模式,相应的,应用调用通讯接口具体可以包括发布、订阅、请求、响应等通讯接口。同时,还可以包括服务发现接口,用于服务的注册和访问。
需要知道的是,服务通讯接口层20中还提供有代码生成工具对应的工具生成接口。工具生成接口用于提供统一的基于配置工具生成的统一标准接口代码,还用于将统一标准接口代码编译打包成动态库服务插件,以供服务通讯管理层40加载并调用。示例性的,工具生成接口中可以包含数据的序列化接口和反序列化接口,序列化接口中封装有数据的序列化方法,反序列化接口中封装有数据的反序列化方法。通过调用数据的序列化接口,可以调用序列化方法对数据进行序列化处理。通过调用数据的反序列化接口,可以调用反序列化方法对数据进行反序列化处理。此外,工具生成接口中还可以包含封装有协议解释表的接口,协议解释表用于描述通讯协议消息数据的配置。示例性的,如SOME/IP协议的事件ID、方法ID、服务ID等配置映射,或者DDS协议的消息ID、域ID、服务质量等配置映射。利用本实施例提供的中间件中的服务通讯接口层20,对于服务应用软件来说将是统一的协议绑定配置和消息配置,从而不需要关心解释表映射的不同的通讯协议。
服务运行代理层30,用于向服务应用软件提供统一的运行所需的通讯代理以及通讯回调处理机制。
在本实施例中,服务运行代理层30向服务应用软件提供统一的运行所需的通讯代理,用于服务应用软件和对端服务应用进行通讯。可以理解的是,通过中间件进行通讯的通讯场景可能有进程内通讯、进程间通讯、片间通讯的场景。其中,进程内通讯是指进行通讯的通讯服务实例部署在同一芯片的同一节点上,进程间通讯是指进行通讯的通讯服务实例分别部署在同一芯片不同节点上,片间通讯是指进行通讯的通讯服务实例分别部署在不同芯片的节点上。针对于不同通讯场景,通讯代理中可以设置不同的代理接口。示例性的,对于进程内通讯,通讯代理中的代理接口为本地代理,对于进程间通讯或者片间通讯,通讯代理中的代理接口为远程代理。
在本实施例中,通讯统一回调处理机制,用于通过统一的应用调用通讯接口注册执行回调函数,并通过提供的线程上下文进行同步或异步触发,实现服务运行时的执行绑定。示例性的,执行绑定可以是订阅绑定、发布绑定、请求绑定、响应绑定或者服务发现绑定等。
服务通讯管理层40,用于通过服务运行代理层提供的通讯代理接口,对服务应用软件的通讯过程进行通讯管理,以及为服务应用软件提供适配的通讯传输所需的通讯协议接口。
在本实施例中,服务通讯管理层40是整个中间件承上启下的的核心层级,对上由服务运行代理层30抽象统一通讯代理接口,对下适配扩展服务通讯传输层50不同的传输协议。服务通讯管理层40主要由协议栈管理模块和协议运行管理模块组成。其中,协议栈管理模块,用于进行通讯协议栈代理接口管理、服务配置实例管理以及通讯传输所采用通讯协议的适配管理;协议运行管理模块,用于协助服务应用软件进行消息通讯时的异步发送和接收消息以及进行回调的异步处理。
需要知道的是,对于消息发送的通讯流程来说,协议运行管理模块接收到用户消息时,在将消息转发到协议栈管理模块之前,需要将用户消息进一步封装成统一协议消息,也就是协议栈管理模块接收到的消息是统一协议消息。相应的,当协议栈管理模块接收到协议传输消息时将协议传输消息封装成统一协议消息,将统一协议消息转发到协议运行管理模块,当协议运行管理模块转发消息到服务运行代理层30时,将解析统一协议消息获得用户消息进一步触发通讯统一回调处理。
服务通讯管理层40对服务应用软件的通讯过程进行通讯管理,通讯协议栈代理接口管理、服务配置实例管理以及通讯传输所采用通讯协议的适配管理。
服务通讯传输层50,用于集成服务通讯传输依赖的至少一种通讯传输协议,以使服务应用软件通过在服务通讯管理层40确定的通讯协议接口,进行相匹配通讯传输协议的调用。
本实施例中,通讯传输协议是指开源的三方通讯传输协议,例如,支持面向服务的SOME/IP和DDS协议。该两种面向服务的通讯协议主要用于片间通讯,片间通讯可以理解为跨机通讯。另外,进程间通信(Inter-Process Communication,IPC)也可以被适配集成。
由于不同的协议有不同的协议头、消息定义方式以及不同的通讯接口,因此,为了保证服务通讯管理层40和服务通讯传输层50解耦,服务通讯管理层40重新封装和适配不同通讯协议消息和接口定义,并提供给服务应用软件统一的消息数据和接口的定义。在服务通讯管理层40确定出想要进行消息通讯的通讯协议接口后,由于服务通讯传输层50集成了服务通讯传输依赖的通讯传输协议,这样可以保证服务应用软件通过该通讯协议接口,调用相匹配的通讯传输协议,以实现消息发送。
本发明实施例提供一种面向服务通讯的中间件,包括:服务部署应用层,用于向服务应用软件的开发及部署提供统一的组件接口以及配置和代码生成工具;服务通讯接口层,用于向服务应用软件提供统一的应用调用通讯接口以及代码生成工具对应的工具生成接口;服务运行代理层,用于向服务应用软件提供统一的运行所需的通讯代理以及通讯回调处理机制;服务通讯管理层,用于通过服务运行代理层提供的通讯代理接口,对服务应用软件的通讯过程进行通讯管理,以及为服务应用软件提供适配的通讯传输所需的通讯协议接口;服务通讯传输层,用于集成服务通讯传输依赖的至少一种通讯传输协议,以使服务应用软件通过在服务通讯管理层确定的通讯协议接口,进行相匹配通讯传输协议的调用。上述技术方案提供的面向服务通讯的中间件能够进行跨平台移植,支持多系统、多协议栈,实现解耦软硬件、异构网络通讯的功能。
作为本发明实施例的可选实施例,在上述实施例的基础上,进一步优化限定服务部署应用层10。图2为本发明实施例一提供的另一种面向服务通讯的中间件的结构示意图,如图2所示,服务部署应用层10包括:应用基础组件,用于向服务应用软件的开发及部署提供通讯、调度、配置解析所需的相关基础组件;配置文件集,用于向服务应用软件提供在服务通讯中涉及的配置文件以及定义服务应用软件在服务通讯中的消息数据结构体;代码生成工具,用于作为服务通讯中通讯所需代码的生成工具,以通过调用服务通讯接口层的工具生成接口,结合配置文件集中配置文件来生成服务应用软件通讯所需代码文件。
应用基础组件,用于向服务应用软件的开发及部署提供通讯、调度、配置解析所需的相关基础组件。
其中,应用基础组件以通讯节点作为部署载体,服务应用软件中需要通讯的应用实例均部署在通讯节点上;通讯节点通过创建通讯服务实例来加载和启动服务应用软件需要通讯的应用实例;通讯服务实例包括:消息订阅器、消息发布器、消息请求器以及消息响应器。
需要知道的是,通讯节点是与业务无关的基础组件,所有需要通讯的面向服务应用实例都需要部署在节点上,由节点配置加载和启动。消息订阅器、消息发布器、消息请求器、消息响应器都是由节点创建出来的通讯服务实例,每个APP应用实例都可以创建一个或多个通讯服务实例,而这些通讯服务实例则是遵循“发布/订阅”、“请求/响应”的通讯模式封装了服务通讯接口层的应用调用接口。
配置文件集,用于向服务应用软件提供在服务通讯中涉及的配置文件以及定义服务应用软件在服务通讯中的消息数据结构体。
具体的,配置文件集主要涉及本实施例提供的中间件的相关配置以及消息数据结构体的定义。其中,服务应用软件在服务通讯中涉及的配置文件包括:通讯服务实例配置清单、通讯协议配置清单、消息定义清单以及进行通信实例部署的通讯节点配置清单。本实施例中对配置文件集包含哪些文件不做具体限制,可以根据面向服务的通讯的需求进行设定。其中,配置文件可以采用arxml格式,此处不做具体限制。
在本实施例中,服务应用软件在服务通讯中的消息包括用户消息(Topic)、统一协议消息(Parcel)和协议传输消息。示例性的,为了更清楚的表述用户消息、统一协议消息以及协议传输消息的定义以及封装情况,图3为本发明实施例一提供的一种面向服务通讯的中间件中服务通讯消息的封装示例图,参照图3,用户消息:由消息ID(TopicId)和消息体(Payload)组成,消息体(Payload)封装了数据类型ID(TypeId)和原始数据(Data);对于所有服务应用软件来说通过通讯接口发送的原始数据都会直接被封装成统一的用户消息,转发到服务运行代理层和协议运行管理模块。
继续参考图3,统一协议消息:由发送方实例ID(Sender)、接收方实例ID(Receiver)、消息类型(Type)、错误码(ErrorCode)以及用户消息(Topic)组成,因为这些字段基本上能够适配所有的通讯传输协议;当协议运行管理模块转发消息到协议栈转发器的时候,将对用户消息进一步封装成统一协议消息传递到对应协议栈转发器,相应的,当协议栈发器接收到协议传输消息时将协议传输消息封装成统一协议消息通过触发回调将协议传输消息转发到协议运行管理模块,当协议运行管理模块转发消息到服务运行代理层的时候,将解析统一协议消息包拿到用户消息进一步触发通讯统一回调处理。
继续参考图3,协议传输消息:不同通讯协议传输消息都会有不同的消息头或消息体定义,示例性的,面向服务的通讯协议主要有SOME/IP和DDS两个主流协议架构,SOME/IP协议消息头由4个字节32bit和可变长消息体组成,而DDS协议则相对复杂同样由32位实时发布订阅(Real-Time Publish Subscribe,RTPS)固定消息报头和可变数量的子消息组成,子消息又由子消息头和子消息体组成,进程间通信IPC协议则与SOME/IP类似。需要说明的是,虽然不同的协议头都很复杂,但是对于面向服务以数据为中心的中间件来说,并不会让用户适配不同的协议头字段,而是在服务通讯管理层就适配并过滤了绝大多数协议头字段。
代码生成工具,用于作为服务通讯中通讯所需代码的生成工具,以通过调用服务通讯接口层20的工具生成接口,结合配置文件集中配置文件来生成服务应用软件通讯所需代码文件。
在本实施例中,代码生成工具主要是根据配置文件集中的配置文件生成服务通讯接口层20的工具生成接口,代码生成工具主要是通过抽象与业务无关的模板接口来高度减轻服务应用软件开发的工作量,同时结合应用基础组件封装的统一接口,从而实现服务应用软件和中间件完全解耦。
为了更清楚的表述节点创建通讯服务实例并配置加载和启动的过程,分别以本实施例提供的中间件通讯“发布/订阅”使用示例,以及中间件通讯“请求/响应”使用示例为例进行描述。
图4为本发明实施例一提供的一种面向服务通讯的中间件通讯“发布/订阅”使用示例图。如图4所示,假设Node1节点部署发布应用服务,记为Node1-Writer,Node2节点部署订阅应用服务,记为Node2-Reader,中间件通讯“发布/订阅”使用示例可以表述为:
Node1节点部署发布应用服务:
S11、主函数入口创建节点;
S12、由节点解析加载配置文件集;
S13、根据配置文件集构造全局唯一的服务实例ID;
S14、通过节点创建节点的发布服务实例并绑定全局唯一的实例ID;
S15、发布服务实例通过注册服务提供服务;
S16、通过服务发现接口发现对端服务实例;
S17、启动一个线程周期发布消息ID为“Test”的数据test。
Node2节点部署订阅应用服务:
S21、主函数入口创建节点;
S22、由节点解析加载配置文件集;
S23、根据配置文件集构造全局唯一的服务实例ID;
S24、通过节点创建节点的订阅服务实例并绑定全局唯一的实例ID;
S25、订阅服务实例通过注册服务提供服务;
S26、通过服务发现接口发现对端服务实例;
S27、异步执行:先构造并注册消息处理回调函数,然后订阅对端消息ID,最后异步回调将会被触发执行。
图5为本发明实施例一提供的一种面向服务通讯的中间件通讯“请求/响应”使用示例图。如图5所示,假设Node1节点部署请求应用服务,记为Node1-Client,Node2节点部署响应应用服务,记为Node2-Service,中间件通讯“请求/响应”使用示例可以表述为:
Node1节点部署请求应用服务:
S31、主函数入口创建节点;
S32、由节点解析加载配置文件集;
S33、根据配置文件集构造全局唯一的服务实例ID;
S34、通过节点创建节点的请求服务实例并绑定全局唯一的实例ID;
S35、请求服务实例通过注册服务提供服务;
S36、通过服务发现接口发现对端服务实例;
S37、异步执行:先构造并注册消息响应处理回调函数,然后请求对端消息ID,并发送请求数据,最后异步回调将会被触发执行。
Node2节点部署响应应用服务:
S41、主函数入口创建节点;
S42、由节点解析加载配置文件集;
S43、根据配置文件集构造全局唯一的服务实例ID;
S44、通过节点创建节点的响应服务实例并绑定全局唯一的实例ID;
S45、响应服务实例通过注册服务提供服务;
S46、通过服务发现接口发现对端服务实例;
S47、异步执行:先构造并注册消息请求处理回调函数,当接收到客户端请求后,处理请求然后向客户端响应同一消息ID的数据。
优选的,所述服务通讯接口层中的应用调用通讯接口,包括:遵循“发布/订阅”、“请求/响应”通讯模式的发布通讯接口、订阅通讯接口、请求通讯接口以及响应通讯接口;还包括遵循面向服务通讯的服务发现接口;相应的,服务应用软件通讯时涉及的统一服务应用消息包括:用户消息、统一协议消息以及协议传输消息;服务应用软件通讯时涉及的通讯形式包括:进程内通讯、进程间通讯以及片间通讯。
其中,服务通讯接口层包含的应用调用接口,包括遵循“发布/订阅”、“请求/响应”通讯模式的发布通讯接口、订阅通讯接口、请求通讯接口、响应通讯接口等通讯接口。同时,遵循面向服务通讯原则设计有一套服务发现接口,服务发现接口用于服务的注册和访问。这些接口调用的方式遵循“骨架/代理(Skeleton/Proxy)”模式,Skeleton接口主要是服务提供方调用的接口,例如服务注册、取消注册、发布、响应等服务端接口;Proxy接口主要是服务消费者调用的接口,例如服务访问、取消访问、订阅、取消订阅、请求等接口。
为了更清楚的描述中间件“发布/订阅”通讯数据流传输,下面针对不同通讯场景来描述。对于“发布/订阅”模式,通过网络通讯节点创建订阅服务实例订阅发布服务实例发布的消息。图6为本发明实施例一提供的一种面向服务通讯的中间件“发布/订阅”通讯数据流的传输示例图,如图6所示:
进程内通讯:在芯片SoC2上的通讯节点3(记为Node3)创建的发布服务实例(记为Writer)和订阅服务实例(记为Reader),由于这两个服务实例都在同一个节点上,因此消息(Topic)将走进程内(Intra)传输,即当Reader订阅了Writer的消息ID(记为TopicId),那么Writer将会通过进程内将消息发送给Reader,而此种场景下,用户消息(Topic)传递将不会走协议层,而是直接将原始数据异步共享给Reader所在的线程。
进程间通讯:在芯片SoC1上由通讯节点1(Node1)创建的发布服务实例(记为Writer)和同一芯片上通讯节点2(记为Node2)所创建的订阅服务实例(记为Reader),由于这两个服务实例都在同一个芯片不同节点上,那么此消息(Topic)将走进程间(IPC)传输。IPC传输主要采用共享内存,主要是片内通讯传输性能好,虽然共享内存传输时非面向服务的协议,但是数据传输仍然走统一的通讯接口,并仍然遵循服务发现模式和数据序列化反序列化流程。
片间通讯:在芯片SoC1上通讯节点2(记为Node2)创建的发布服务实例(记为Writer)和在SoC2上通讯节点3(记为Node3)创建的订阅服务实例(记为Reader)。由于这两个服务实例分布在不同的芯片上,那么此消息将走片间传输,片间通讯协议主要有SOME/IP协议、DDS协议两种,都是面向服务的通讯协议。区别于现有技术中SOME/IP比较常用于汽车开放系统体系(AUTomotive Open System ARchitecture,AUTOSAR)架构平台的中间件,DDS比较常用于机器人操作系统(Robot Operating System,ROS)架构平台的中间件,本发明提供的中间件则有机融合了不同架构平台的通讯协议并提供给服务部署应用层统一的标准。
对于“请求/响应”模式,通过网络通讯节点创建消息请求服务实例发送请求给响应服务实例,由消息响应服务实例处理请求并响应消息给请求服务实例。图7为本发明实施例一提供的一种面向服务通讯的中间件“请求/响应”通讯数据流的传输示例图,如图7所示:“请求/响应”通讯数据流的传输方式与“发布/订阅”通讯数据流的传输方式是一致的,具体如下:
进程通讯:在芯片SoC2上的通讯节点3(记为Node3)创建的响应服务实例(Service)和请求服务实例(Client),由于这两个服务实例都在同一个节点上,因此消息(Topic)将走进程内(Intra)传输。
进程间通讯:在芯片SoC1上由通讯节点1(记为Node1)创建的响应服务实例(记为Service)和同一芯片上通讯节点2(记为Node2)所创建的请求服务实例(记为Client),由于这两个服务实例都在同一个芯片不同节点上,那么此消息(Topic)将走进程间(IPC)传输。
片间通讯:在芯片SoC1上通讯节点2(记为Node2)创建的响应服务实例(记为Writer)和在SoC2上通讯节点3(记为Node3)创建的请求服务实例(Reader),由于这两个服务实例分布在不同的芯片上,那么此消息将走片间传输。但是通讯模式是有所区别的,在Client端请求时也需要发送请求消息(Topic),而在Service端在接收到请求消息后会应答响应消息(Topic)给Client端,这两个Topic虽然消息ID(TopicId)一样,但是携带的数据不一定是一样的,因此对于“请求/响应”模式,其消息ID描述的不是一种数据类型,而是描述的是请求端(Client)请求的数据类型和响应端(Service)响应的数据类型的绑定关系,这实际上与SOME/IP协议的接口描述ID类似,即远程过程调用。
作为本发明实施例的可选实施例,在上述实施例的基础上,进一步优化限定服务通讯接口层20中的工具生成接口,用于提供统一的基于配置工具生成的统一标准接口代码,还用于将统一标准接口代码编译打包成动态库服务插件,以供所述服务通讯管理层加载并调用。
其中,工具生成接口包括数据序列化、数据反序列化以及协议解释表接口。数据序列化和反序列化接口遵循“骨架(Proxy)/代理(Skeleton)”模式,即骨架模式接口封装的是发布、响应的数据序列化方法和代理端请求的数据反序列化方法;Proxy模式接口封装的是请求数据的序列化方法和Skeleton端发布、响应的数据反序列化方法。
协议解释表(ProtocolTable)是描述通信协议消息数据的配置,如SOME/IP协议的事件ID、方法ID、服务ID等配置映射,或者DDS协议的消息ID、域ID、服务质量等配置映射,而对于服务应用软件来说将是统一的协议绑定配置和消息配置,从而不需要关心解释表映射的不同的通讯协议。需要清楚的是,数据的序列化和反序列化接口都是服务提供方配置工具生成的,有些服务实例可能并不提供服务,但仍然需要工具生成空实例。
作为本发明实施例的可选实施例,在上述实施例的基础上,进一步优化限定服务运行代理层30中的通讯统一代理,用于向服务应用软件提供统一的通讯服务代理,以用于服务应用软件和对端服务应用进行通讯;其中,通讯服务代理中的代理接口包括用于进程内通讯的本地代理和用于进程间通讯或者片间通讯的远程代理。
在本实施例中,服务运行代理层中的通讯统一代理:用于向服务应用软件提供统一的通讯服务代理用于和对端服务应用进行通讯。具体的,通讯服务代理主要是通过服务发现机制拿到和对端通讯的代理接口,代理接口有本地代理和远程代理两种。其中,本地代理主要走本地通讯即进程内通讯,远程代理则是走跨进程(进程间)或跨机(片间)通信。本地代理数据传输主要是通过共享指针数据传输,远程代理数据传输则需要经过序列化和反序列化在不同的通讯传输协议上进行数据传输。因此,通讯统一代理在某种程度上也实现了网路通讯路由网关功能。
进一步的,服务运行代理层30中的通讯统一回调处理机制,用于通过统一的应用调用通讯接口注册执行回调函数,并通过提供的线程上下文进行同步或异步触发,实现服务运行时的执行绑定;其中,执行绑定包括:订阅绑定、发布绑定、请求绑定、响应绑定以及服务发现绑定。
在本实施例中,通讯统一回调处理的过程可以表述为:服务运行代理层中的通讯统一回调处理机制主要是通过统一应用调用接口注册执行回调函数并由运行时提供的线程上下文进行同步或异步触发,实现服务运行时的执行绑定。在服务运行时里有订阅绑定、发布绑定、请求绑定、响应绑定以及服务发现绑定等执行绑定。上述均是通过统一的服务运行时线程上下文进行调度并处理。
作为本发明实施例的可选实施例,在上述实施例的基础上,进一步优化服务通讯管理层40,包括:协议栈管理模块,用于进行通讯协议栈代理接口管理、服务配置实例管理以及通讯传输所采用通讯协议的适配管理;协议运行管理模块,用于协助服务应用软件进行消息通讯时的异步发送和接收消息以及进行回调的异步处理。
服务通讯管理层40是整个中间件承上启下的的核心层级,对上由服务运行代理层30抽象统一通讯代理接口,对下适配扩展不同服务通讯传输层50的传输协议。服务通讯管理层40主要由协议栈管理模块和协议运行管理模块组成。
其中,通讯协议栈代理接口管理具体可以理解为管理存储不同通讯服务实例对应的通讯协议栈代理接口。服务配置实例管理具体可以理解为管理存储遵循“骨架/代理”模式的服务配置实例。通讯传输所采用通讯协议的适配管理具体可以理解为通过集成协议栈数据转发代理接口来为服务应用软件的服务通讯适配不同的传输通讯协议。协议运行管理模块使得通讯的数据转发能够安全的被同步或异步处理。
优选的,协议栈管理模块,包括:协议栈管理器,用于管理存储不同通讯服务实例对应的通讯协议栈代理接口;协议栈解释器,用于管理存储遵循“骨架/代理”模式的服务配置实例;协议栈转发器,用于通过继承协议栈数据转发代理接口用来为服务应用软件的服务通讯适配不同的传输通讯协议。
在本实施例中,协议栈管理器管理存储不同服务实例对应的通讯协议栈代理接口。其中,代理接口在初始化的时候创建,并在进行远程服务发现的时候拿到通讯协议栈数据转发代理接口。
在本实施例中,协议栈解释器主要是管理存储“骨架/代理”服务配置实例,在初始化的时候通过加载工具生成接口编译集成的动态库插件获取骨架实例接口和代理实例接口,即获取服务实例对应的协议解释表和数据序列化和反序列接口。协议栈解释器有且只有一个骨架实例和多个代理实例,这是因为在面向服务中,服务实例是全局唯一的,协议栈解释器描述的是本服务提供的协议解释表和数据序列化反序列化方法,解释表和代理的方法在域内可以由其他所有服务实例访问。
在本实施例中,协议栈转发器是继承协议栈数据转发代理接口用来适配不同的传输通讯协议,在初始化的时候创建实例,并在服务发现的时候由协议栈管理器提供给服务运行时管理层,不同的通讯传输协议有不同的协议转发器实例和协议解释器实例。示例性的,SOME/IP协议栈对应有SOME/IP协议栈解释器、SOME/IP协议栈转发器,DDS协议栈对应有DDS协议栈解释器、DDS协议栈转发器,IPC协议栈对应有IPC协议栈解释器、IPC协议栈转发器。可以理解的是,协议栈转发器是真正适配传输通讯协议接口的,因此数据转发代理实例既实现了骨架接口,也实现了代理接口,同时支持面向服务的或非面向服务的通讯传输协议。
需要知道的是,协议栈管理器是通讯节点内共享的对象实例,而协议栈解释器和协议栈转发器是订阅、发布等服务内共享的,即一个节点有且只有一个协议栈管理器,一个服务实例只有一个协议栈解释器和协议栈转发器,一个节点可以有多个服务实例,因此一个协议栈管理器存储了不同服务实例到不同服务协议栈的映射。正是有了协议栈管理功能使得中间件有机融合不同通讯传输协议得以实现。
优选的,协议运行管理模块通过包括的协议运行时处理单元,在服务应用软件进行通讯时进行异步发送和接收消息;其中,通讯模式为订阅、请求模式的接口通过协议运行管理模块中的协议代理通道来发送和接收消息;通讯模式为发布、响应模式的接口通过协议运行管理模块中的协议骨架通道来发送和接收消息;协议运行管理模块还通过解析协议消息包并转发到对端应用所对应服务运行代理层上的通讯统一回调处理机制,来触发响应的执行绑定回调。
在本实施例中,协议栈管理模块是在服务初始化和服务发现的时候实例化好的,而在服务进行通信时则需要由协议运行管理模块包括的协议运行时单元来异步发送和接受消息,对于协议运行时单元来说,仍然遵循“骨架/代理”模式,将通讯模式进行区分,对于订阅、请求模式接口则走协议代理通道(ProtocolProxyChannel);对于发布、响应模式接口则走协议骨架通道(ProtocolSkeletonChannel)。协议运行时处理单元无论走哪个通道,最终都是由协议栈转发器进行数据的收发,因为协议运行时处理单元继承了协议栈数据转发代理回调接口,而协议栈转发器同时也注册了协议栈数据转发代理回调接口,因此数据的收发都是在协议栈转发器内部,而回调的异步处理则交给了协议运行时处理单元。协议运行时处理单元最终会通过解析协议消息包并转发到对应的服务运行代理层30通讯统一回调处理,并触发相应的执行绑定回调。
进一步的,服务通讯传输层50集成的通讯传输协议包括:支持面向服务的SOME/IP协议以及支持面向服务的DDS协议以及用于进程间通信的共享内存传输协议。
在本实施例中,服务通讯传输层50主要是集成扩展不同的开源的三方通讯传输协议。示例性的,服务通讯传输层50主要支持面向服务的SOME/IP协议开源软件和DDS协议开源软件的集成,此外自研IPC共享内存传输协议也可以被适配集成。由于不同的协议有不同的协议头、消息定义方式以及不同的通讯接口,因此为了保证服务通讯管理层40和服务通讯传输层50解耦,服务通讯管理层40重新封装和适配不同的通讯协议消息和接口定义,并提供给应用APP统一的数据消息和接口的定义。本实施例中对服务通讯传输层50集成的通讯传输协议不做具体限制。
上述可选实施例提供了一种支持智能驾驶域多系统、多协议栈的面向服务通讯的中间件,采用统一的标准“骨架/代理(Skeleton/Proxy)模式”通讯接口和代码生成工具,让其实现的组件代码具有高可复用性、高可扩展性;同时可适配非面向服务的通讯协议栈做定制化组件,让不同的传输协议走统一的“骨架/代理接口”传输数据;支持协议的动态绑定和静态绑定,由通讯代理和路由模块进行协议栈的切换,同时支持片间、片内(进程间、进程内)通讯;支持发布/订阅、请求/响应的全双工通讯模式,针对DDS中的实时发布订阅协议进行了适配和扩展;多协议栈管理支持面向服务的SOME/IP、DDS协议栈以及IPC(共享内存)通讯协议;协议运行时组件使得通讯的数据转发能够安全的被同步或异步处理;采用零拷贝、结合高性能的数据序列化反序列化组件,保证数据的传输效率和安全;定义服务实例ID和消息实例ID规则和配置,实现数据安全访问控制和多路数据融合功能,采用分层设计,将与协议相关的通讯组件和协议无关的通讯组件解耦,让其能够有机融合其他三方的中间件通讯架构。
为了更清楚的表述基于本技术方案提供的中间件如何进行通讯,分别以中间件通讯接收消息和发送消息的场景为例进行描述。图8为本发明实施例一提供的一种面向服务通讯的中间件通讯发送消息的时序示例图。如图8所示,面向服务通讯的中间件通讯发送消息的时序可以表述为:
S51、服务应用软件(APP)通过应用基础组件(AppFramework)封装的通讯接口发送原始数据(Data)和消息ID(TopicId)。
S52、发送服务实例将服务应用软件传递的参数封装成用户消息(Topic)以及封装执行回调绑定一并通过应用调用通讯接口发送出去,其中,发送服务实例可以是Writer、Client、Service服务实例即能够发布、请求、响应等需要发送数据的对象。
S53、服务运行代理层将上下文的所有消息通过命令(Command)封装起来,并通过执行器(Executor)以异步的方式将命令传递(Post)到运行时线程任务队列,此时立即返回应用程序数据发送的结果即错误码(ErrorCode),表示服务应用软件的数据能否正常的被服务运行代理层进行调度处理。
S54、执行器(Executor)将在其工作线程上以异步阻塞方式同步运行时(Runtime)的任务队列,并处理命令(Command)里的消息将通过服务运行代理层统一的通讯代理接口将参数透传给协议运行时处理单元。
S55、协议运行时处理单元会根据统一代理接口传递的参数进一步将其封装成统一协议消息(Parcel)通过协议代理或骨架通道将其转发到协议栈转发器。
S56、协议栈转发器将会根据事先绑定的传输协议,最终将Parcel消息所封装的数据通过序列化同时遵循传输协议的协议头将其转换成传输协议消息,并通过服务通讯传输层发送出去,此时立即返回协议运行时处理单元消息发送的错误码结果。
可以理解的是,通过步骤S51-S56就实现了中间件通讯发送消息的过程。
图9为本发明实施例一提供的一种面向服务通讯的中间件通讯接收消息的时序示例图。如图9所示,面向服务通讯的中间件通讯接收消息的时序可以表述为:
S61、服务应用软件(APP)需要事先通过应用基础组件(AppFramework)提供的接口注册处理消息的回调(Callback),并通过接收服务实例订阅或请求接口对回调接口进行执行绑定封装。
S62、服务通讯传输层提供消息接收的回调接口,协议栈转发器将在传输协议的回调线程里进行异步消息接收,并遵循传输协议头将优先对传输协议消息进行解析。
S63、协议栈转发器将协议消息数据反序列化成消息(Topic),并将其封装成统一协议消息(Parcel),然后通过统一代理回调接口将Parcel消息通知到协议运行时处理单元,此时立即返回错误码表示传输协议消息处理完成,将交给协议运行时处理单元进行调度处理,这样也是为了不阻塞消息接收线程,保证消息通讯的稳定性和可靠性。
S64、协议运行时处理单元将Pacel包进一步解析成用户消息(Topic),并通知给服务运行代理层。
S65、服务运行代理层将上下文的所有消息通过命令(Command)封装起来,并通过执行器(Executor)以异步的方式将命令传递(Post)到运行时线程任务队列,并立即返回错误码。此处需要注意的是服务运行代理层上下文有多个执行器。示例性的,参照图8和图9所示的消息收发是在两个不同的线程上下文进行处理的。
S66、接收服务实例将在执行绑定上的线程上下文处理服务应用软件注册的执行回调函数,并将执行处理结果返回给服务应用软件。
可以理解的是,通过步骤S61-S66就实现了中间件通讯接收消息的过程。
值得注意的是,上述面向服务通讯的中间件的实施例中,所包括的各个分层只是按照功能逻辑进行划分的,但并不局限于上述的划分,只要能够实现相应的功能即可;另外,各功能单元的具体名称也只是为了便于相互区分,并不用于限制本发明的保护范围。
注意,上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解,本发明不限于这里所述的特定实施例,对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此,虽然通过以上实施例对本发明进行了较为详细的说明,但是本发明不仅仅限于以上实施例,在不脱离本发明构思的情况下,还可以包括更多其他等效实施例,而本发明的范围由所附的权利要求范围决定。

Claims (12)

1.一种面向服务通讯的中间件,其特征在于,包括:
服务部署应用层,用于向服务应用软件的开发及部署提供统一的组件接口以及配置和代码生成工具;
服务通讯接口层,用于向服务应用软件提供统一的应用调用通讯接口以及代码生成工具对应的工具生成接口;
服务运行代理层,用于向服务应用软件提供统一的运行所需的通讯代理以及通讯回调处理机制;
服务通讯管理层,用于通过服务运行代理层提供的通讯代理接口,对服务应用软件的通讯过程进行通讯管理,以及为服务应用软件提供适配的通讯传输所需的通讯协议接口;
服务通讯传输层,用于集成服务通讯传输依赖的至少一种通讯传输协议,以使服务应用软件通过在服务通讯管理层确定的通讯协议接口,进行相匹配通讯传输协议的调用。
2.根据权利要求1所述的中间件,其特征在于,所述服务部署应用层,包括:
应用基础组件,用于向服务应用软件的开发及部署提供通讯、调度、配置解析所需的相关基础组件;
配置文件集,用于向服务应用软件提供在服务通讯中涉及的配置文件以及定义服务应用软件在服务通讯中的消息数据结构体;
代码生成工具,用于作为服务通讯中通讯所需代码的生成工具,以通过调用服务通讯接口层的工具生成接口,结合所述配置文件集中配置文件来生成服务应用软件通讯所需代码文件。
3.根据权利要求2所述的中间件,其特征在于,所述应用基础组件以通讯节点作为部署载体,服务应用软件中需要通讯的应用实例均部署在通讯节点上;
通讯节点通过创建通讯服务实例来加载和启动服务应用软件需要通讯的应用实例;
所述通讯服务实例包括:消息订阅器、消息发布器、消息请求器以及消息响应器。
4.根据权利要求2所述的中间件,其特征在于,服务应用软件在服务通讯中涉及的配置文件包括:通讯服务实例配置清单、通讯协议配置清单、消息定义清单以及进行通信实例部署的通讯节点配置清单。
5.根据权利要求1所述的中间件,其特征在于,所述服务通讯接口层中的应用调用通讯接口,包括:遵循“发布/订阅”、“请求/响应”通讯模式的发布通讯接口、订阅通讯接口、请求通讯接口以及响应通讯接口;还包括遵循面向服务通讯的服务发现接口;
相应的,服务应用软件通讯时涉及的统一服务应用消息包括:用户消息、统一协议消息以及协议传输消息;
服务应用软件通讯时涉及的通讯形式包括:进程内通讯、进程间通讯以及片间通讯。
6.根据权利要求1所述的中间件,其特征在于,所述服务通讯接口层中的工具生成接口,用于提供统一的基于配置工具生成的统一标准接口代码,还用于将统一标准接口代码编译打包成动态库服务插件,以供所述服务通讯管理层加载并调用。
7.根据权利要求1所述的中间件,其特征在于,所述服务运行代理层中的通讯统一代理,用于向服务应用软件提供统一的通讯服务代理,以用于服务应用软件和对端服务应用进行通讯;
其中,所述通讯服务代理中的代理接口包括用于进程内通讯的本地代理和用于进程间通讯或者片间通讯的远程代理。
8.根据权利要求1所述的中间件,其特征在于,所述服务运行代理层中的通讯统一回调处理机制,用于通过统一的应用调用通讯接口注册执行回调函数,并通过提供的线程上下文进行同步或异步触发,实现服务运行时的执行绑定;
其中,所述执行绑定包括:订阅绑定、发布绑定、请求绑定、响应绑定以及服务发现绑定。
9.根据权利要求1所述的中间件,其特征在于,所述服务通讯管理层,包括:
协议栈管理模块,用于进行通讯协议栈代理接口管理、服务配置实例管理以及通讯传输所采用通讯协议的适配管理;
协议运行管理模块,用于协助服务应用软件进行消息通讯时的异步发送和接收消息以及进行回调的异步处理。
10.根据权利要求9所述的中间件,其特征在于,所述协议栈管理模块,包括:
协议栈管理器,用于管理存储不同通讯服务实例对应的通讯协议栈代理接口;
协议栈解释器,用于管理存储遵循“骨架/代理”模式的服务配置实例;
协议栈转发器,用于通过继承协议栈数据转发代理接口用来为服务应用软件的服务通讯适配不同的传输通讯协议。
11.根据权利要求9所述的中间件,其特征在于,所述协议运行管理模块通过包括的协议运行时处理单元,在服务应用软件进行通讯时进行异步发送和接收消息;
其中,通讯模式为订阅、请求模式的接口通过所述协议运行管理模块中的协议代理通道来发送和接收消息;
通讯模式为发布、响应模式的接口通过所述协议运行管理模块中的协议骨架通道来发送和接收消息;
所述协议运行管理模块还通过解析协议消息包并转发到对端应用所对应服务运行代理层上的通讯统一回调处理机制,来触发响应的执行绑定回调。
12.根据权利要求1所述的中间件,其特征在于,所述通讯传输层集成的通讯传输协议包括:支持面向服务的SOME/IP协议以及支持面向服务的DDS协议以及用于进程间通信的共享内存传输协议。
CN202211569508.4A 2022-12-08 2022-12-08 一种面向服务通讯的中间件 Pending CN116319983A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211569508.4A CN116319983A (zh) 2022-12-08 2022-12-08 一种面向服务通讯的中间件

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211569508.4A CN116319983A (zh) 2022-12-08 2022-12-08 一种面向服务通讯的中间件

Publications (1)

Publication Number Publication Date
CN116319983A true CN116319983A (zh) 2023-06-23

Family

ID=86776832

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211569508.4A Pending CN116319983A (zh) 2022-12-08 2022-12-08 一种面向服务通讯的中间件

Country Status (1)

Country Link
CN (1) CN116319983A (zh)

Similar Documents

Publication Publication Date Title
Grace et al. A reflective framework for discovery and interaction in heterogeneous mobile environments
US20020138659A1 (en) Method and system for application development and a data processing architecture utilizing destinationless messaging
Bouloukakis et al. Automated synthesis of mediators for middleware-layer protocol interoperability in the IoT
Ferscha et al. A light-weight component model for peer-to-peer applications
Aijaz et al. Enabling high performance mobile web services provisioning
CN113726869A (zh) 通信方法、网关以及电子设备
Panisson et al. Designing the architecture of p2p-based network management systems
Anke et al. A service-oriented middleware for integration and management of heterogeneous smart items environments
CN105812241A (zh) 基于Spring Integration的企业应用集成方法和系统
Kang et al. Android RMI: a user-level remote method invocation mechanism between Android devices
CN116319983A (zh) 一种面向服务通讯的中间件
CN109669793B (zh) 中间件进程内对象调用方法
MXPA05003667A (es) Metodo y aparato para sistema de integracion de servicio.
Matteucci Publish/subscribe middleware for robotics: requirements and state of the art
Wies et al. A practical approach towards a distributed and flexible realization of policies using intelligent agents
Anke et al. Seamless integration of distributed OSGi bundles into enterprise processes using BPEL
Xin et al. An architecture design of a JBI-based enterprise service bus
Frei et al. Eventizing applications in an adaptive middleware platform
Allam et al. A message-passing model for service oriented computing
El Khaddar Middleware Solutions for the Internet of Things: A Survey
Garcés-Erice et al. A flexible and scalable message broker for sensor network integration
Melby Using J2EE technologies for implementation of ActorFrame based UML 2.0 models
Dobrescu et al. Using UPnP services with an intelligent sensor network node
Lipperts et al. CORBA Wrappers for A-posteriori Management
Dobrescu et al. Embedding wireless sensors in UPnP services networks

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination