CN115134406B - 管理服务间通信的方法、服务间通信管理系统 - Google Patents

管理服务间通信的方法、服务间通信管理系统 Download PDF

Info

Publication number
CN115134406B
CN115134406B CN202210310505.2A CN202210310505A CN115134406B CN 115134406 B CN115134406 B CN 115134406B CN 202210310505 A CN202210310505 A CN 202210310505A CN 115134406 B CN115134406 B CN 115134406B
Authority
CN
China
Prior art keywords
service
inter
ipc
stub
server
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.)
Active
Application number
CN202210310505.2A
Other languages
English (en)
Other versions
CN115134406A (zh
Inventor
V·阿鲁维拉
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.)
Aptiv Technologies Ltd
Original Assignee
Aptiv Technologies 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 Aptiv Technologies Ltd filed Critical Aptiv Technologies Ltd
Publication of CN115134406A publication Critical patent/CN115134406A/zh
Application granted granted Critical
Publication of CN115134406B publication Critical patent/CN115134406B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4557—Directories for hybrid networks, e.g. including telephone numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/541—Client-server
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/547—Messaging middleware

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

本公开涉及管理服务间通信的方法、服务间通信管理系统。方法，包括：由服务间通信管理系统从与服务器侧服务相关联的配置文件获得指定第一服务间通信机制的信息，第一服务间通信机制要用于从服务器侧服务向客户端侧服务发送一个或更多个消息；在服务间通信管理系统处实体化与由配置文件指定的第一服务间通信机制相关联的存根，存根能够在操作上与服务器侧服务交互；在存根处，使用与存根相关联的第一服务间通信机制从服务器侧服务接收要向客户端侧服务转发的代理的消息，代理与第一服务间通信机制相关联；并根据与服务器侧服务相关联的配置文件指定的第一服务间通信机制，从存根向客户端侧服务的代理转发消息。

Description

管理服务间通信的方法、服务间通信管理系统
技术领域
本公开涉及管理服务之间的服务间通信，特别是在分布式环境中的服务间通信。
背景技术
分布式软件架构(或面向服务的架构)已经变得越来越重要。软件组件可以被设计成由分布式团队和供应商开发的服务。这种服务可以集成到原始设备制造商(OEM)系统中。分布式服务可以被设计成经由进程间通信(IPC)机制彼此交互。这样的IPC机制以各种格式可用。然而，适合于特定平台或给定场景的IPC格式在另一场景中可能表现不好。
这样的服务的业务逻辑的实现方式通常与用于与系统中的其它服务交互的IPC机制的实现方式紧密耦合。这一事实极大地阻碍了服务的可移植性，使得难以将它们移植到被配置成支持其它IPC机制的另一平台。需要相当大的努力来用另选IPC机制重新实现服务，以使得有可能在另一平台上部署该服务。
图1示出了根据现有技术的系统100的架构。提供了多个服务105。各个服务被配置成与IPC栈层110交互，IPC栈层110转而被提供在适当的平台115上。平台115可以被实现为片上系统(SoC)或分布式平台。
为了使用IPC机制将从一个服务105向另一个服务105发送消息，需要向各个服务提供IPC应用编程接口(API)层120。第一服务1051可能需要根据第一服务1051的业务逻辑1061和/或第二服务1052的业务逻辑与第二服务1052交换消息。IPC API层120向服务105提供允许经由IPC栈层110在第一服务1051与第二服务1052之间的消息传输所必需的代码。图1中所示的IPC栈层110提供根据特定IPC格式的IPC机制。消息在从第一服务1051经由IPC栈层110发送之前由串行化/去串行化(SER/DES)层1251串行化。消息在第二服务1052处被接收之后由串行化/去串行化单元1252去串行化。然后，去串行化的消息具有可由第二服务1052读取的格式。串行化和去串行化是使用特定于用于该消息传输的IPC格式的格式来执行的。
这种现有技术方案遇到了多个缺点。各个服务的业务逻辑与用于在业务之间交换消息的特定IPC机制紧密耦合。由于业务逻辑与IPC机制紧密联系，所以接口定义是IPC专用的，并且针对不同的IPC，需要以不同的接口描述语言(IDL)格式来重新实现。因此，将特定服务从使用一个IPC机制切换到另一个IPC机制是非常困难的。实际上，从一个IPC机制到不同的IPC机制的切换会需要调整服务的业务逻辑。此外，如上所述，要在服务之间交换的数据结构的串行化和去串行化专用于特定IPC机制。因此，特定服务不能同时支持多种IPC机制。
发明内容
本公开的第一个方面提供了一种管理服务器侧服务与客户端侧服务之间的服务间通信的方法，所述方法包括以下步骤：
由服务间通信管理系统从与所述服务器侧服务相关联的配置文件获得指定第一服务间通信机制的信息，所述第一服务间通信机制要用于从所述服务器侧服务向所述客户端侧服务发送一个或更多个消息；在所述服务间通信管理系统处实体化与由所述配置文件指定的所述第一服务间通信机制相关联的存根，其中，所述存根能够在操作上与所述服务器侧服务交互；在所述存根处，使用与所述存根相关联的第一服务间通信机制从所述服务器侧服务接收要向所述客户端侧服务转发的代理的消息，其中，所述代理与所述第一服务间通信机制相关联；以及根据与所述服务器侧服务相关联的配置文件指定的所述第一服务间通信机制，从所述存根向所述客户端侧服务的所述代理转发所述消息。
所述配置文件可以指定进程间通信IPC机制，并且所述存根可以与所指定的IPC机制相关联，所述方法可以还包括：获得与同所述存根相关联的所述IPC机制相关的应用编程接口API信息；以及根据与所述存根相关联的IPC机制的所述API信息，实体化与所述存根相关联的IPC机制的IPC通道的第一端点。
从所述存根向所述代理转发所述消息的步骤可以包括：从所述存根向与所述存根相关联的IPC机制的所述IPC通道的所述第一端点转发所述消息；以及从与所述存根相关联的所述IPC通道的所述第一端点向与所述代理相关联的IPC通道的第二端点发送所述消息。
所述配置文件可以指定非IPC机制，并且，从所述存根向所述代理转发所述消息的步骤可以包括使用一个或更多个直接函数调用从所述存根直接向所述代理转发所述消息。
所述方法可以还包括检测将所述服务间通信机制从所述第一服务间通信机制更新为第二服务间通信机制的、对所述服务器侧服务的配置文件的改变，并且响应于该检测，终止与所述第一服务间通信机制相关联的所述存根，并且实体化与所述第二服务间通信机制相关联的存根。
本公开的第二个方面提供了一种管理客户端侧服务与服务器侧服务之间的服务间通信的方法，所述方法包括以下步骤：由服务间通信管理系统从与所述客户端侧服务相关联的配置文件获得指定第一服务间通信机制的信息，所述第一服务间通信机制用于在所述客户端侧服务处从所述服务器侧服务接收一个或更多个消息；在所述服务间通信管理系统处实体化与由所述配置文件指定的所述第一服务间通信机制相关联的代理，其中，所述代理能够在操作上与所述客户端侧服务交互；在所述代理处从与所述第一服务间通信机制相关联的存根接收消息；以及从所述代理向所述客户端侧服务转发所述消息。
所述配置文件可以指定进程间通信IPC机制，并且，所述代理可以与所指定的IPC机制相关联，所述方法可以还包括：获得与同所述代理相关联的所述IPC机制相关的应用编程接口API信息；以及根据与所述代理相关联的IPC机制的所述API信息，实体化与所述代理相关联的IPC机制的IPC通道的第二端点。
在所述代理处从所述服务器侧服务接收消息的步骤可以包括由所述服务间通信管理系统使用与所述客户端侧服务相关联的侦听器来激活所述代理。
所述配置文件可以指定非IPC机制，并且，在所述代理处接收所述消息的步骤可以包括：在所述代理处从与所述服务器侧服务相关联的所述存根接收一个或更多个直接函数调用。
所述方法可以还包括检测将所述服务间通信机制从所述第一服务间通信机制更新为第二服务间通信机制的、对所述配置文件的改变，并且响应于该检测，终止与所述第一服务间通信机制相关联的所述代理，并且实体化与所述第二服务间通信机制相关联的代理。
本公开的第三个方面提供了一种计算机可读介质，所述计算机可读介质包括计算机可读指令，所述计算机可读指令在由一个或更多个处理器执行时使得所述一个或更多个处理器执行根据第一、第二方面所述的方法。
本公开的第四个方面提供了一种用于管理服务器侧服务与客户端侧服务之间的服务间通信的服务间通信管理系统，所述服务间通信管理系统包括存储器和控制器，所述控制器被配置成：从与所述服务器侧服务相关联的配置文件获得指定第一服务间通信机制的信息，所述第一服务间通信机制用于从所述服务器侧服务向所述客户端侧服务发送一个或更多个消息；在所述服务间通信管理系统处实体化与由所述配置文件指定的所述服务间通信机制相关联的存根，其中，所述存根能够在操作上与所述服务器侧服务交互；从与所述客户端侧服务相关联的配置文件获得指定所述第一服务间通信机制的信息，所述第一服务间通信机制用于在所述客户端侧服务处从所述服务器侧服务接收一个或更多个消息；在所述服务间通信管理系统处实体化与由所述配置文件指定的所述第一服务间通信机制相关联的代理，其中所述代理可在操作上与所述客户端侧服务交互；在所述存根处，使用与所述存根相关联的所述第一服务间通信机制从所述服务器侧服务接收要向所述客户端侧服务发送的消息；根据所述第一服务间通信机制从所述存根向所述代理转发所述消息；在所述代理处根据所述第一服务间通信机制从所述存根接收所述消息；以及从所述代理向所述客户端侧服务转发所述消息。
所述第一服务间通信机制可以是进程间通信IPC机制，并且，所述存根和所述代理可以均与所述IPC机制相关联，所述控制器可以还被配置成：获得与所述IPC机制相关的应用编程接口API信息；根据与所述存根相关联的所述IPC机制的所述API信息，实体化与所述存根相关联的所述IPC机制的IPC通道的第一端点；以及根据与所述代理相关联的IPC机制的API信息，实体化与所述代理相关联的所述IPC机制的所述IPC通道的第二端点。
所述第一服务间通信机制可以是非IPC机制，并且其中，从所述存根向所述代理转发所述消息包括使用一个或更多个直接函数调用从所述存根直接向所述代理转发所述消息。
所述控制器可以还被配置成：检测将所述服务器侧服务的所述服务间通信机制从第一服务间通信机制更新为第二服务间通信机制的、对所述服务器侧服务的配置文件的改变，并响应于该检测，终止与所述第一服务间通信机制相关联的所述存根，并实体化与所述第二服务间通信机制相关联的存根；和/或检测将所述客户端侧服务的所述服务间通信机制从第一服务间通信机制更新为第二服务间通信机制的、对所述客户端侧服务的配置文件的改变，并响应于该检测，终止与所述第一服务间通信机制相关联的所述代理，并实体化与所述第二服务间通信机制相关联的代理
附图说明
为了可以完全理解本文描述的公开内容，将参照附图描述各种示例，其中：
图1是例示根据现有技术的系统的示意性框图；
图2是例示根据本公开实施方式的示意性系统的示意性框图；
图3A是根据本公开实施方式的服务器侧系统的示意性框图；
图3B是根据本公开实施方式的客户端侧系统的示意性框图；
图4是例示根据本公开实施方式的为对存根和端点进行实体化而执行的操作的流程图；
图5是例示根据本公开实施方式的为对代理和端点进行实体化而执行的操作的流程图；
图6A是例示根据本公开实施方式的为发送消息而执行的操作的流程图；
图6B是例示根据本公开实施方式的为接收消息而执行的操作的流程图；
图7是例示根据本公开实施方式的流水线配置下的系统的示意性框图；
图8是根据本公开实施方式的服务间通信管理模块、服务器和客户端的示意性框图；
图9是例示根据本公开实施方式的由服务间通信管理系统执行的服务器侧操作的流程图；
图10是例示根据本公开实施方式的由服务间通信管理系统执行的客户端侧操作的流程图；以及
图11是根据本公开实施方式的计算设备的示意性框图。
具体实施方式
本公开的实施方式以克服上述问题的方式允许分布式环境中的服务彼此通信。
本文描述的实施方式允许有效地管理服务之间的通信。特别地，通过在与各个服务相关联的配置文件中指定特定的服务间通信机制，可以为该服务选择服务间通信机制(在服务器侧和客户端侧)。使用服务间通信管理系统，在使用相同服务间通信机制的服务器和客户端之间建立通信路径。服务间通信管理系统负责实体化与在服务器的配置文件中指定的服务间通信机制相关联的存根。服务间通信管理系统负责实体化与在客户端的配置文件中指定的服务间通信机制相关联的代理。服务间通信管理系统可以支持与相应服务器相关联的多个存根以及与相应客户端相关联的多个代理。在它们各自的配置文件中指定相同的服务间通信机制的服务器和客户端可以经由存根和代理之间的通信路径交换消息。
在一些实施方式中，服务间通信机制是进程间通信(IPC)机制。除了建立分别与服务器侧服务与客户端侧服务相关联的存根和代理之外，服务间通信管理模块还实体化IPC通道端点以允许经由配置文件中指定的IPC机制进行服务间通信。因此，指定相同IPC机制的服务器和客户端可以交互，例如通过经由所指定IPC机制定义的通信路径交换消息。
在一些实施方式中，使用非IPC通信机制来在服务器和客户端之间建立通信路径。在这样的实施方式中，服务间通信管理模块维护数据库，该数据库包括对指定了非IPC通信机制的服务器进行标识的信息。该数据库还对在客户端的配置文件中指定了服务器的标识符的客户端进行标识。服务间通信管理模块在服务器和客户端之间建立逻辑连接。因此，可以使用一个或更多个直接函数调用来建立服务器与客户端之间的通信。
各个服务器和各个客户端的配置文件可以是可编辑的，使得用户可以将特定服务器或客户端的服务间通信机制从第一服务间通信机制改变为第二服务间通信机制。更新服务间通信机制可以是从第一IPC机制到第二IPC机制。更新服务间通信机制可以是从IPC机制到非IPC机制。更新服务间通信机制可以是从非IPC机制到IPC机制。
此外，各个服务器和客户端的配置文件可以指定超过一个服务间通信机制。对于指定超过一个服务间通信机制的服务器，可以针对各个服务间通信机制对存根进行实体化。同样，对于指定超过一个服务间通信机制的客户端，可以针对各个服务间通信机制对代理进行实体化。这允许客户端和/或服务器同时经由不同的通信路径来通信。
根据本文描述的实施方式，简化了服务器侧服务与客户端侧服务的开发。任何特定通信机制的应用编程接口(API)被抽象到服务间通信管理模块。因此，服务器侧和客户端端服务的开发者不需要包括特定通信机制的API。相反，可以提供允许与服务间通信管理模块交互的通用API。这使得能够在不要求对服务器或客户端的逻辑进行任何重新编程的情况下，更新特定服务器或客户端的服务间通信机制。
在采用进程间通信(IPC)的实施方式中，将允许经由IPC机制传输消息所需的API从服务本身抽象到IPC管理层。各个服务具有相关联的配置文件，在配置文件中指定了针对该服务的IPC机制或格式。
服务器侧的服务，即负责向客户端提供服务的服务，可在操作上在IPC管理层处实体化与配置文件中指定的特定IPC机制相关联的存根，作为针对该服务的输出IPC机制。IPC管理层被配置成访问应用编程接口API库，该应用编程接口API库用于在发送消息的服务的配置文件中指定的IPC机制。API库包括API信息，该API信息包括专用于该IPC机制的协议和定义。从API库获得的用于所指定的IPC机制的API信息然后可以用于实体化与服务器侧服务相关联的网络接口处的IPC通道端点。
在客户端侧提供相应的设置以允许消耗由服务器提供的服务。客户端侧服务可在操作上在IPC管理层处实体化与配置文件中指定的特定IPC机制相关联的代理，作为针对该服务的输入IPC机制。IPC管理层被配置成访问用于在客户端侧服务的配置文件中指定的IPC机制的应用编程接口API库。API库包括API信息，该API信息包括专用于该IPC机制的协议和定义。从API库获得的用于所指定的IPC机制的API信息然后可用于实体化与客户端侧服务相关联的网络接口处的IPC通道端点。
在存根和服务器侧IPC通道端点已经在服务器侧被实体化之后，并且在代理和客户端侧IPC通道端点已经在客户端侧服务被实体化之后，可以从服务器向客户端发送消息。消息是根据在相应服务的配置文件中指定的IPC机制发送的。此外，可以从客户端向服务器发送消息。例如，客户端可以向服务器发送请求消息。这样的请求消息可以从代理向存根转发。从服务器向客户端转发的消息可以采取对从客户端向服务器发送的请求消息的响应消息的形式。
有利地，服务本身的业务逻辑不依赖于任何特定IPC机制和与任何特定IPC机制相关联的API信息。因此，仅需要向各个服务提供通用API信息以与IPC管理层交互。不需要提供专用于服务层处的特定IPC格式的API信息。
此外，IPC管理层可在操作上使用与平台所支持的各种IPC格式无关的串行化/去串行化格式来串行化/去串行化消息。另选地，要发送的消息可以由服务本身进行串行化。
图2是例示示例性系统200的示意性框图。系统200包括服务205。服务205包括服务2051，在该示例中，服务2051向一个或更多个服务2052、2053发送一个或更多个消息。由于服务2051正在向服务2052、2053发送消息，所以服务2051也可以被称为服务器。由于服务2052、2053接收由服务2051发送的消息，所以服务2052、2053在此可以被称为客户端。然而，应注意，服务205中的每一者可被配置成发送两者及接收消息两者。这样，各个服务205可以被配置成既用作服务器又用作客户端。依赖于相应服务的业务逻辑，第一服务2051可以充当向充当客户端的第二服务2052提供服务的服务器，而同时第一服务2051可以充当从充当服务器的第二服务2052接收服务的客户端。
系统200包括IPC栈层210。IPC栈层210被提供在平台215上。平台215可以是片上系统(SoC)。另选地，平台215可以是云平台。IPC栈210被配置成充当负责根据特定IPC机制从服务器向客户端传送消息的层。IPC栈210可以包括允许经由IPC机制传输消息所需的硬件和软件。IPC栈210可以被实现为用于经由IPC通道发送和接收一个或更多个消息的一个或更多个IPC通道端点。
各个服务205具有定义一个或更多个输入IPC机制和一个或更多个输出IPC机制的相关联的配置文件。配置文件可由用户编辑，从而可改变服务所使用的输入IPC机制和输出IPC机制。
系统200包括IPC管理层220。IPC管理层220从与所指定的IPC机制相关联的库获得用于实现所指定的IPC机制所需的实现方式信息。实现方式信息可以包括定义了针对特定IPC机制而言遵循的规则API信息。针对特定IPC机制的API信息用于实体化IPC通道端点，从而允许经由针对该特定IPC机制的IPC通道发送和接收消息。
经由IPC机制发送的消息可以在传输之前被串行化。同样地，在客户端侧服务处接收的消息可以被去串行化。在图2所示的实施方式中，IPC管理层220在传输消息之前对消息进行串行化，并对接收到的消息进行去串行化。IPC管理层220可以访问消息串行化/去串行化层225以执行消息串行化/去串行化。在本公开的实施方式中，消息串行化/去串行化是使用独立于用于传输消息的IPC机制的格式来执行的。本文描述的实施方式使用谷歌协议缓冲器来执行串行化/去串行化，然而，本领域中已知的其它串行化/去串行化格式也可以用作另选方式。
另选地，可以在将消息提供给IPC管理层220之前由服务器侧服务执行消息串行化。同样地，客户端侧服务可以在客户端已经从IPC管理层220接收到消息之后去串行化该消息。在消息串行化/去串行化由服务本身执行的实施方式中，所使用的格式也可以独立于用于传输消息的IPC机制。例如，谷歌协议缓冲器可用于由服务对消息进行串行化/去串行化。
IPC栈210包括被配置成分别支持IPC机制IPC1、IPC2、IPC3的IPC栈211、212、213。IPC栈211、212、213包括网络接口和IPC通道端点，以使得能够通过传输层进行消息传输。示例IPC机制可以包括WebSockets、ZeroMQ、MQTT、DBus、SOME/IP或本领域已知的任何其他IPC机制。这样，IPC机制可以被认为是被配置成允许经由传输层在两个服务之间传输消息的任何协议。IPC机制可以允许经由同一设备上的共享存储器来通信或经由网络在设备之间传输消息。
在图2所示的示例中，服务器侧服务2051被配置成向客户端侧服务2052、2053发送消息。这样，服务2051充当服务器，而服务2052、2053各自充当与服务2051通信的客户端。在该示例中，服务2051被配置成经由IPC1栈211向服务2052传送消息，IPC1栈211是使用IPC机制IPC1的IPC栈。服务2051被配置成经由IPC2栈212向服务2053传送消息，IPC2栈212是使用IPC机制IPC2的IPC栈。
因此，在该示例中，服务2051被配置成同时经由两个IPC机制发送消息。应当理解，服务205中的每一者可以被配置成经由超过一个IPC机制接收消息。
在该示例中，服务2051的配置文件2161指定输出IPC机制IPC1和IPC2。可以在IPC管理层220处实体化对应于IPC机制IPC1和IPC2的单独的存根。可以使用来自相应API库的API信息来实体化网络接口处的用于IPC机制IPC1和IPC2的IPC通道端点。在其相关联的配置文件2162中，服务2052指定输入IPC机制IPC1。在IPC管理层220处实体化对应于该IPC机制IPC1的代理。可以使用来自针对IPC机制IPC1的API库的API信息来实体化网络接口处的用于IPC机制IPC1的IPC通道端点。
在其相关联的配置文件2163中，服务2053指定输入IPC机制IPC2。在IPC管理层220处实体化对应于IPC机制IPC2的代理。可以使用来自针对IPC机制IPC2的API库的API信息来实体化在网络接口处的用于IPC机制IPC2的IPC通道端点。
与各个服务相关联的配置文件可以被配置成指定一个或更多个输出IPC格式和一个或更多个输入IPC格式。一个或更多个输出IPC格式指定由充当服务器的服务经由相应通道输出消息所使用的IPC机制。一个或更多个输入IPC格式指定以下IPC机制：通过该IPC机制来配置服务(充当客户端)以接收消息。可以通过用户输入来更新输入IPC格式和输出IPC格式。在检测到用户输入时，可以终止现有的存根、代理和通道端点。替换存根、代理和IPC通道端点可以响应于检测到IPC格式的更新而被实体化。
该方案的优点在于，IPC管理层220实现管理经由特定IPC机制消息感测和接收的功能。在现有技术中，该功能将必须由服务本身通过使用针对要使用的IPC机制的特定API来执行。IPC管理层220可以被理解为形成了各种IPC机制的API的抽象层。
如上所述，平台215可以是云平台。因此，图2中所示的各个元件可以驻留在能够访问分布式环境中的网络的单独的主机设备中。图2中所示的一些或所有元件可以驻留在同一主机设备上。在一些实施方式中，图2中所示的所有元件可驻留在同一主机设备上。在这样的实施方式中，平台215可以实现为片上系统(SoC)。
图3A和图3B是分别例示根据本公开实施方式的服务器侧系统和客户端侧系统的功能单元的示意性框图。服务器侧系统和客户端系统可以形成分布式计算系统。另选地，可以在单个计算设备上提供服务器侧系统和客户端侧系统。
图3A例示了服务器侧系统3001的组件。图4是例示在服务器侧系统3001处采取的步骤的流程图，该步骤用于建立从第一服务3051到网络接口3451的通信路径，以允许使用特定IPC机制进行通信。图6A是例示在服务器侧系统3001处采取的从服务器侧系统3001向客户端侧系统3002发送消息的步骤的流程图。
图3B例示了客户端系统3002的组件。图5是例示在客户端系统3002处采取的步骤的流程图，该步骤用于根据第二服务3052的输入IPC机制建立从第二服务3052到网络接口3452的通信路径。图6B是例示在客户端侧系统3002处采取的从服务器侧系统3001接收消息的步骤的流程图。
参照图3A，服务器侧系统3001包括充当服务器(即向客户端提供服务的实体)的第一服务3051。第一服务3051包括业务逻辑3061以提供第一服务3051的功能。第一服务3051还可以包括IPC管理API 3201。IPC管理API 3201可以包括定义第一服务3051与IPC管理层之间的交互的信息。IPC管理API 3201独立于当从第一服务3051向第二服务3052发送消息时要使用的IPC机制。这与现有方案相反，在现有方案中，API被提供给特定服务，该API专用于该服务所使用的IPC机制。
第一服务3051具有与其相关联的配置文件3161。配置文件3161可以相对于第一服务本地存储或者可以远程存储。配置文件3161包括指定一个或更多个输出IPC机制的信息。另外，配置文件3161可以包括指定一个或更多个输入IPC机制的信息。这样，第一服务3051可以被配置成在本公开的实施方式中既充当服务器又充当客户端，因为第一服务既可以经由输出IPC机制输出要发送的消息，又可以经由输入IPC机制接收已发送的消息。
服务器侧系统3001包括与第一服务3051通信的IPC管理模块3101。IPC管理模块3101包括IPC存根311和IPC侦听器3121。IPC管理模块是服务间通信管理模块的示例。
例如，第一服务3051的业务逻辑3061可以确定要发送一个或更多个消息。参照图4，在步骤4.1，第一服务3051被配置成从配置文件3161获得指定输出IPC机制的信息。在步骤4.2，第一服务3051指示IPC管理模块3101实体化IPC存根311以及可选地实体化IPC侦听器3121。第一服务3051可以通过生成指定要与IPC存根311相关联的输出IPC机制的命令来指示IPC管理模块3101对IPC存根311进行实体化。
在步骤4.3，在IPC管理模块3101处由IPC管理模块3101的控制器3141对IPC存根311进行实体化。IPC侦听器3121也可以在这个阶段被实体化。因此，IPC存根311和IPC侦听器3121各自与在第一服务3051的配置文件3161中指定的输出IPC机制相关联。IPC侦听器3121可以被配置成监测第二服务3052的连接状态并且通知第一服务3051关于第二服务3052已经连接或断开连接。IPC侦听器3121还可以被配置成检测从第二服务3052接收的请求消息。
然后，在步骤4.4，控制器3141可以获得存储在与经实体化的IPC存根311和IPC侦听器3121的IPC机制相关联的IPC API库315中的API信息。可以提供用于各个IPC机制的IPCAPI数据库。IPC API数据库315可以本地存储在IPC管理模块3101中。
控制器3141使用存储在IPC存根311的IPC机制的IPC API库315中的信息来实体化作为网络接口3451的一部分的IPC通道端点3401。控制器3141可以在步骤4.5指示网络接口3451实体化IPC通道端点3401。然后在步骤4.6中，对IPC通道端点3401进行实体化。
在本公开的实施方式中，IPC通道端点3401被配置成与底层传输层的接口。在一些实施方式中，IPC通道端点3401使用传输控制协议(TCP)与传输层交互。在其它实施方式中，IPC通道端点3401使用用户数据报协议(UDP)与传输层交互。
IPC通道端点3401可以是通过与传输层的基础设施交换数据而创建的，该数据指定以下各项中的一项或更多项的组合：服务器侧服务(即本例中的第一服务3051)的协议类型、IP地址和端口号。IPC通道端点3401的结构和属性可以由用于该IPC机制的应用编程接口(API)来定义。在已经建立了IPC通道端点3401之后，IPC通道端点3401用作用于通过传输层发送和接收数据的端点。
IPC通道端点3401可以是WebSockets、ZeroMQ、MQTT、DBus、SOME/IP或任何其它IPC机制之一的端点。
如上所述，IPC机制可以被认为是被配置成允许经由传输层在两个服务之间传输消息的任何协议。IPC机制可以允许经由同一设备上的共享存储器通信或经由网络在设备之间传输消息。
IPC存根311被配置成在第一服务3051(充当服务器)与同在第一服务3051的配置文件3161中指定的特定IPC机制相对应的IPC通道之间提供接口。
当要从服务器侧系统3001向客户端系统3002发送消息时，第一服务3051从配置文件3161识别要用于发送消息的输出IPC机制。第一服务3051可以向与要使用的输出IPC机制相关联的IPC存根311发送命令。提供给IPC存根311的命令可以为setServerAvailable()，使得IPC存根311知道第一服务3051准备好转发消息。
参照图6A，第一服务3051在步骤6.1生成要向第二服务3052发送的消息。在步骤6.2，第一服务3051向IPC存根311转发消息。第一服务3051可以使用命令sendMessage()和publishMessage()向IPC存根311提供消息。
sendMessage()可以用于指定消息应被发送到的目标客户端。例如，IPC侦听器3121可以检测来自第二服务3052的请求消息。响应地，控制器3141可以在网络接口3451处实体化专用于第二服务3052的句柄。sendMessage()命令可以用于将消息寻址到与该句柄相关联的特定第二服务3051。
如果要向系统中的所有客户端发送消息，则可以使用publishMessage()。换言之，具有与IPC存根311的输出IPC机制相同的输入IPC机制的所有客户端侧服务被配置成接收由第一服务3051使用publishMessage()命令转发的消息。
在步骤6.3，IPC存根311接收消息。
在一些实施方式中，在步骤6.4，IPC存根311被配置成使用串行化/去串行化单元3301来对消息进行串行化。串行化/去串行化单元3301可以包括可用于根据特定串行化格式来对消息串行化的API信息。在其它实施方式中，该消息由第一服务3051串行化。在由第一服务3051执行串行化的实施方式中，可在第一服务3051处提供串行化/去串行化API。在本公开的实施方式中使用的格式串行化/去串行化独立于任何特定IPC机制。在一些实施方式中，使用谷歌协议缓冲器来执行串行化/去串行化。这样，可以在第一服务3051处提供谷歌协议缓冲器API。
在本发明的实施方式中，串行化格式独立于任何特定的编程语言或IPC机制，使得可以对来自可能使用不同编程语言编写的各种服务的消息进行串行化。例如，可以使用谷歌协议缓冲器来对消息进行串行化，然而，本领域技术人员将意识到其它合适的串行化格式。
在步骤6.5，IPC存根311向与IPC存根311相关联的IPC机制的通道的第一端点3401转发经串行化的消息。
在步骤6.6，然后从IPC机制的通道的第一端点3401向与第二服务3052相关联的IPC机制的通道的第二端点3402发送经串行化的消息。
参照图3B，客户端系统3002包括充当客户端的第二服务3052。第二服务3052包括业务逻辑3062以提供第二服务3052的功能。客户端系统3002包括IPC管理模块3102和网络接口3452。IPC管理模块3102是服务间通信管理模块的示例。IPC管理模块3102包括控制器3142。控制器3142被配置成控制由IPC管理模块3102执行的操作。IPC管理模块3101和IPC管理模块3102一起形成服务间通信管理系统。
第二服务3052可以包括IPC管理API 3202。IPC管理API 3202可以包括定义第一服务3052与IPC管理模块3102之间的交互的信息。IPC管理API 3202独立于当从服务器侧系统3001接收消息时要使用的IPC机制。
第二服务3052具有与其相关联的配置文件3162。配置文件3162可以相对于第二服务3052本地存储或者可以远程存储。配置文件3162包括指定一个或更多个输入IPC机制的信息。另外，配置文件3162可以包括指定一个或更多个输出IPC机制的信息。这样，第二服务3052可以被配置成充当服务器和客户端两者，因为第二服务3052可以经由输入IPC机制接收所发送的消息并且经由输出IPC机制输出要发送的消息。
参照图5，在步骤5.1，第二服务3052被配置成从与第二服务3052相关联的配置文件3162获得标识输入IPC机制的信息。在步骤5.2，第二服务3052请求在IPC管理模块3102处实体化IPC代理313。在步骤5.3，由IPC管理模块3102的控制器3142在IPC管理模块3102处对IPC代理313进行实体化。IPC侦听器3122也可以被实体化。IPC侦听器3122和IPC代理313各自与由第二服务3052的配置文件3162指定的输入IPC机制相关联。
IPC侦听器3122可以被配置成监测第一服务3051和与其相关联的存根311的连接状态。IPC侦听器3122可以被配置成向第二服务3052使用命令onConnect()通知第一服务3051和/或存根311已经连接，或使用命令onDisconnect()通知已经断开。IPC侦听器3122还可以被配置成向第二服务3052和/或IPC代理313使用命令onMessage()通知已经从第一服务3051转发了消息。
IPC代理313被配置成充当第二服务3052与IPC通道端点3402之间的接口。
在步骤5.4，控制器3142被配置成从与IPC代理313的IPC机制相关联的IPC API库360获得IPC API信息。在步骤5.5，控制器3142请求IPC通道端点3402的实体化。在步骤5.6，对IPC通道端点3402进行实体化。IPC通道端点3402可以被创建为指定以下参数中的一个或更多个：协议类型、IP地址和端口号。
客户端系统3002允许经由IPC机制的IPC通道接收消息并向第二服务3052转发该消息。参照图6B，在步骤6.7，在IPC通道端点3402处接收经串行化的消息。然后在步骤6.8，可以向与第二服务3052相关联的IPC管理模块3102的IPC代理313转发经串行化的消息。
在步骤6.9，在IPC代理313处接收该经串行化的消息。
在一些实施方式中，在步骤6.10，IPC代理313然后可以使用IPC绑定模块3102的串行化/去串行化单元3302将消息去串行化。然后在步骤6.11，向第二服务3052转发该消息。IPC侦听器3122可以使用命令onMessage()来警告第二服务3052关于已经从存根311接收到消息。该消息可以由IPC代理313或由IPC侦听器3122向第二服务3052转发。在步骤6.12，在第二服务3052接收消息。虽然在一些实施方式中，消息在IPC管理模块3102处被去串行化，但是在其他实施方式中，消息在第二服务3052处被去串行化。
在该示例中，第一服务3051向第二服务3052发送一个或更多个消息，因而第一服务3051可以被认为是服务器，而第二服务3052可以被认为是客户端。然而，第一服务3051还可以充当与第三服务(未示出)通信的客户端。照此，第一服务3051可以在IPC管理模块3101处实体化与由第一服务3051的配置文件指定的输入IPC机制相关联的IPC代理(未示出)。这允许第一服务3051经由输入IPC机制接收消息。与经实体化的IPC代理的IPC机制相关联的IPC通道端点(未示出)可以由控制器3141实体化。
此外，第二服务3052还可以充当关于第四服务(未示出)的服务器。这样，第二服务3052可以在IPC管理模块3102处实体化IPC存根。这种设置为IPC管理模块3102提供了经由输出IPC机制从第二服务3052向第四服务发送消息的功能。与经实体化的IPC存根的IPC机制相关联的IPC通道端点(未示出)可以由控制器3142实体化。
还应当理解，IPC存根、IPC侦听器、IPC代理和IPC通道端点的多个实例可以在服务器侧系统3001的IPC管理模块3101处和在客户端侧系统3002的IPC管理模块3102处实体化。具有多个实例允许服务器侧系统3001和客户端侧系统3002分别支持多个输出IPC机制和多个输入IPC机制。该规定是有利的，因为它允许服务同时经由不同的IPC机制发送和接收消息。
图7例示了根据本公开实施方式的系统700，其中在流水线配置下设置了第一服务7051、第二服务7052和第三服务7053。在根据各个服务的业务逻辑来在多个服务之间共享数据的情况下，这种流水线配置可以是很有用的。
系统700可以是载具的机载娱乐系统，其被配置成识别手势以控制其设置，例如音量设置或确认或取消指令。该系统可在操作上识别用于指示音量增大命令的手的顺时针旋转运动、用于指示音量减小命令的逆时针手运动、用于指示命令确认的拇指向上手势和/或用于指示命令取消的拇指向下手势。
在该示例中，第一服务7051可以是可在操作上捕获图像的CamerService(摄像头服务)，第二服务7052BodyKeyPointsService(身体关键点服务)可在操作上扫描由第一服务7051获得的所捕获的图像以识别已经做出手势。第三服务7053可以是用于分析手势含义的GestureService(手势服务)。这样，信息被从第一服务7051流水线传递到第三服务7053。
第一服务7051被配置成向第二服务7052发送消息。由第一服务7051发送的消息可以包括由摄像头获得的图像数据。在流水线的这一部分中，第一服务7051充当服务器，而第二服务7052充当客户端。第二服务7052还被配置成向第三服务7053发送消息。由第二服务7052发送的消息可以包括已经检测到手势的指示。这样，在第二服务7052和第三服务7053之间交换消息的流水线部分中，第二服务7052充当服务器，而第三服务7053充当客户端。
在各种实施方式中，第一服务7051还可以被配置成通过从充当服务器的服务(未示出)接收消息来充当客户端。类似地，第三服务7053还可以被配置成通过向充当客户端的服务(未示出)发送消息来充当服务器。
各个服务705具有相关联的配置文件716。各个配置文件为与其相关联的服务705指定输入IPC机制(这里也称为IPC类型)和输出IPC机制(这里也称为IPC类型)。在图7所示的示例中，用字段“IPC类型”来指定IPC机制。
例如，用于第一服务的配置文件7161指定输入IPC机制“IPC类型＝WebSockets”和输出IPC机制“IPC类型＝WebSockets”。因此，第一服务7051被配置成经由WebSockets接收消息，并且被配置成经由WebSockets输出消息。用于第二服务7052的配置文件7162指定输入IPC机制“IPC类型＝WebSockets”和输出IPC机制“IPC类型＝ZeroMQ”。因此，第二服务7052被配置成经由WebSockets接收消息，并且被配置成经由ZeroMQ输出消息。用于第三服务7053的配置文件7163指定输入IPC机制“IPC类型＝ZeroMQ”和输出IPC机制“IPC类型＝DBus”。因此，第三服务7053被配置成经由ZeroMQ接收消息，并且被配置成经由DBus输出消息。本领域技术人员将理解，也可以使用其它已知的IPC机制。可以在系统700的IPC管理层中提供用于各个所支持的IPC机制的API库，IPC管理层在图7中被称为IPC绑定层720，术语管理层和绑定层是可互换的。
IPC绑定层720的第一部分7201可以执行上述服务器侧IPC管理模块3101和客户端侧IPC管理模块3102的从第一服务7051向第二服务7052传输消息的操作。消息经由第一IPC通道7801来传输，在该示例中，第一IPC通道7801为WebSockets。
IPC绑定层720的第二部分7202可以执行上述服务器侧IPC管理模块3101和客户端侧IPC管理模块3102的从第二服务7052向第三服务7053传输消息的操作。消息经由第二IPC通道7802来传输，在该示例中，第二IPC通道7802为ZeroMQ。
与相应服务705相关联的配置文件716可与相应服务相关联地本地存储在存储器中。或者，配置文件716可以存储在远程位置。配置文件716可以被编辑，使得用户可以修改用于任何服务705的输入和/或输出IPC机制。
虽然以上描述描述了服务使用IPC机制彼此交互的实施方式，但是另选实施方式允许服务在不使用IPC机制的情况下交互。在这样的实施方式中，服务经由非IPC机制交互。非IPC机制可以被认为是服务器和客户端共享公共处理空间的通信机制，即通过直接函数调用可以在没有IPC的情况下进行通信。在这种情况下，客户端使用分配给服务器的唯一标识符来识别和建立连接。服务器的配置文件可以指定该服务器的标识符。客户端的配置文件还可以指定客户端要与之建立通信路径的服务器的标识符。维护数据库以在要建立相互通信路径的服务器和客户端之间建立逻辑连接。
图8是例示这种实施方式的示意性框图。在该实施方式中，服务器侧服务(也称为服务器)805和客户端侧服务(也称为客户端)815由具有控制器814的服务间通信管理模块810支持。服务间通信管理模块810是服务间通信管理系统的示例。
服务器侧服务805和客户端侧服务815中的每一者都具有配置文件816。各个配置文件816指定与其相关联的服务的服务间通信机制。配置文件816可以是可编辑的，使得用户可以改变配置文件以更新特定服务使用哪个服务间通信机制。
在该实施方式中，图8所示的各个服务器侧服务805具有配置文件816，其指定用于执行服务间通信的非IPC机制。为服务器805-1指定的服务间通信机制具有标识了服务器805-1的标识符Server1-id。为服务器805-2指定的服务间通信机制具有标识了服务器805-2的标识符Server2-id。
在服务间通信管理模块810处，控制器814实体化与服务器805-1相关联的存根811-1。控制器814实体化与服务器805-2相关联的存根811-2。
各个服务器805可以具有与其相关联的服务器侧侦听器817。各个服务器侧侦听器817被配置成警告服务器805关于客户端815已经请求了由服务器805提供的服务。例如，客户端815可以向服务器发送请求使用由服务器805提供的服务的请求消息。服务器侧侦听器可使用onMessage()命令来警告其相关联的服务器805。
图8中所示的各个客户端侧服务815具有指定用于执行服务间通信的非IPC机制的配置文件816。为客户端815-1指定的服务间通信机制具有标识了服务器805-1的标识符Server1-id。这意味着客户端815-1将使用由服务器侧服务805-1提供的服务。为客户端815-2指定的服务间通信机制具有标识了服务器805-2的标识符Server2-id。这意味着客户端815-2将使用由服务器侧服务805-2提供的服务。为客户端815-3指定的服务间通信机制具有标识了服务器805-3的标识符Server2-id。这意味着客户端815-3将使用由服务器侧服务805-2提供的服务。与客户端相关联的各个配置文件816可由用户更新，使得客户端可从使用由第一服务器提供的服务改变为使用由第二服务器提供的服务。此外，用户可以更新客户端侧服务的配置文件，使得客户端侧服务指定与服务器侧服务交互用的一个或更多个IPC机制。
各个客户端815可以具有与其相关联的客户端侧侦听器818。各个客户端侧侦听器818被配置成向其相应的客户端815警告客户端815要与之通信的服务器805要向客户端815提供消息。客户端侧侦听器可使用onMessage()命令来警告其相关联的客户端815。
在服务间通信管理模块810处，控制器814实体化与客户端815-1相关联的代理813-1。控制器814实体化与客户端815-2相关联的代理813-2。控制器814实体化与客户端815-3相关联的代理813-3。
控制器814还被配置成在服务间通信管理模块810处维护数据库820。数据库820包括提供服务器侧服务(或服务器)805和要使用由服务器805提供的服务的客户端侧服务(或客户端)815之间的逻辑链路的信息。数据库的每行提供服务器的标识符、与该服务器相关联的侦听器和与客户端相关联的侦听器间的逻辑链接。控制器814可以在存根811和代理813被创建时更新数据库820。
例如，数据库820的第一行将与服务器805-1相关联的标识符server1-id与服务器侧侦听器817-1和客户端侧侦听器818-1联系。数据库820的第二行将与服务器805-2相关联的标识符server2-id与服务器侧侦听器817-2和客户端侧侦听器818-2联系。
数据库820的第三行将与服务器805-2相关联的标识符server2-id与服务器侧侦听器817-2和客户端侧侦听器818-3联系。这样，数据库820可以列出一个服务器和多个客户端间的逻辑连接。
当在数据库820处建立了服务器侧服务805和客户端侧服务815间的逻辑连接时，可以在服务器侧服务805和客户端侧服务815之间交换消息。服务器805可以创建与要向客户端提供的服务有关的消息。例如，服务器805-1可创建包括要向客户端815-1提供的内容的消息。该消息被转发到与服务器805-1相关联的存根811-1。由于存根811-1与非IPC机制相关联，所以控制器814访问数据库820以确定与服务805-1逻辑连接的客户端侦听器818-1。控制器814向客户端侦听器818-1警告存根811-1要向代理813-1转发消息的事实。然后可以使用一个或更多个直接函数调用从与服务器805-1相关联的存根811-1向与客户端815-1相关联的代理813-1转发该消息。代理813-1然后可以向客户端815-1转发该消息。
除了从服务器向客户端发送消息，例如包括与服务器向客户端提供的服务有关的内容的消息，客户端还可以向服务器发送消息。例如，客户端815-1可向服务器805-1发送请求与服务器805-1提供的服务相关的内容的请求消息。客户端815-1可创建请求消息并向与客户端相关联的代理813-1转发该请求消息。控制器814在数据库820中搜索与客户端侦听器818-1具有逻辑连接的服务器侦听器817-1。服务器侦听器817-1然后警告存根811-1将从代理813-1向存根811-1转发请求消息。然后，可以由代理813-1经由一个或更多个直接函数调用向存根811-1转发请求消息。存根811-1然后可以向服务器805-1转发请求消息。服务器805-1然后可以通过向客户端发送响应消息来响应该请求消息。这样，该实施方式提供了服务器805-1和客户端815-1之间的双向通信。
图9是例示由服务间通信管理模块或系统执行以管理服务器侧服务与客户端侧服务之间的服务间通信的服务器侧操作的流程图。这种服务间通信可以经由IPC机制或非IPC机制。在步骤9.1，服务间通信管理模块获得指定用于从服务器侧服务向客户端侧服务发送一个或更多个消息的服务间通信机制的信息。该信息从与服务器侧服务相关联的配置文件获得。服务间通信机制可以是如上参照图2到图7所描述的特定类型的IPC机制。或者，服务间通信机制可以是如上参照图8所描述的非IPC机制。
在步骤9.2，在服务间通信管理模块处，实体化与配置文件所指定的服务间通信机制相关联的存根。存根可在操作上与服务器侧服务交互。在步骤9.3，在存根处从服务器侧服务接收要使用与存根相关联的服务间通信机制向客户端侧服务的代理转发的消息。在步骤9.4，根据由与服务器侧服务相关联的配置文件所指定的服务间通信机制，从存根向客户端侧服务的代理转发消息。
图10是例示由服务间通信管理模块或系统执行以管理服务器侧服务与客户端侧服务之间的服务间通信的客户端侧操作的流程图。这种服务间通信可以经由IPC机制或非IPC机制。在步骤10.1，服务间通信管理模块从服务器侧服务获得指定用于在客户端侧服务处接收一个或更多个消息的服务间通信机制的信息。该信息从与客户端侧服务相关联的配置文件获得。在步骤10.2，在服务间通信管理模块处，对代理进行实体化。代理与由客户端侧服务的配置文件指定的服务间通信机制相关联。代理可在操作上与客户端侧服务交互。在步骤10.3，在代理处根据由客户端侧服务的配置文件指定的服务间通信机制从服务器侧服务接收消息。在步骤10.4，从代理向客户端侧服务转发消息。
虽然已经参照图9描述了由服务间通信管理系统执行的服务器侧操作，并且已经参照图10描述了服务间通信管理系统的客户端侧操作，但是应当理解，可以将图9和图10中所示的操作组合成由服务间通信管理系统执行的单个方法。这样的系统可以是分布式系统或位于单个设备处的系统。
如上所述，本文描述的系统可以包括分布在网络上的计算设备。图11是例示示例计算设备1100的示意性框图。计算设备1100包括一个或更多个处理器1101、易失性存储器1102、非易失性存储器1103和输入/输出1104。非易失性存储器1103可以存储用于实现本文描述的本公开的各方面的计算机可读指令。计算机可读指令可以通过诸如光盘1105的任何适当介质提供给非易失性存储器。然而，可以使用任何其它合适的介质。
虽然本文已经描述了特定实施方式，但是对于本领域技术人员来说显而易见的是，在不脱离由所附权利要求限定的本发明的范围的情况下，可以进行许多变化和修改。
在前面的描述中，参考多个示例实施方式描述了示例方面。因此，说明书应被认为是说明性的，而不是限制性的。类似地，附图中示出的突出了示例性实施方式的功能和优点的图是仅出于示例性目的而呈现的。示例性实施方式的架构是足够灵活和可配置的，使得其可以以不同于附图中所示的方式来利用。
在一个示例性实施方式中，本文所呈现的示例的软件实施方式可以被提供为计算机程序或软件，诸如包括或存储在诸如机器可访问或机器可读介质，指令存储或计算机可读存储装置等制品中的具有指令或指令序列的一个或更多个程序，在一个示例性实施方式中，所述指令或指令序列中的每一个可以是非暂时的。非暂时机器可访问介质、机器可读介质、指令存储器或计算机可读存储装置上的程序或指令可用于对计算机系统或其它电子设备进行编程。机器或计算机可读介质、指令存储器和存储装置可以包括但不限于软盘、光盘和磁光盘或适于存储或传输电子指令的其它类型的介质/机器可读介质/指令存储器/存储装置。本文描述的技术不限于任何特定的软件配置。它们可以在任何计算或处理环境中找到适用性。本文所使用的术语“计算机可读”、“机器可访问介质”、“机器可读介质”、“指令存储”和“计算机可读存储装置”应包括能够存储、编码或传输指令或指令序列以供机器、计算机或计算机处理器执行并使机器/计算机/计算机处理器执行本文所述方法中的任一种的任何介质。此外，本领域中通常以一种形式或另一种形式(例如，程序、过程、进程、应用、模块、单元、逻辑等)将软件称为采取动作或导致结果。这样的表述仅仅是陈述由处理系统执行软件使得处理器执行动作以产生结果的速记方式。
一些实施方式还可以通过准备专用集成电路、现场可编程门阵列、或通过互连常规组件电路的适当网络来实现。
一些实施方式包括计算机程序产品。计算机程序产品可以是具有存储在其上或其中的指令的存储介质或多个存储介质，一个或更多个指令存储或一个或更多个存储装置，这些指令可以用于控制或致使计算机或计算机处理器执行本文描述的示范性实施方式的任何程序。存储介质/指令存储/存储装置可以包括，例如但不限于光盘、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、闪存、闪存卡、磁卡、光卡、纳米系统、分子存储器集成电路、RAID、远程数据存储/存档/仓储，和/或适于存储指令和/或数据的任何其它类型的设备。
存储在计算机可读介质或多个介质、一个或更多个指令存储或一个或更多个存储装置中的任一个上的一些实现方式包括用于控制系统的硬件和用于使系统或微处理器能够利用本文描述的示例实施方式的结果与人类用户或其他机制交互的软件。这种软件可以包括但不限于设备驱动程序，操作系统和用户应用程序。最后，这种计算机可读介质或存储装置还包括用于执行如上所述的本发明的示例方面的软件。
包括在系统的编程和/或软件中的是用于实现本文描述的过程的软件模块。在本文的一些示例实施方式中，模块包括软件，尽管在本文的其他示例实施方式中，模块包括硬件或硬件和软件的组合。
虽然上面已经描述了本发明的各种示例性实施方式，但是应当理解，它们是作为示例而非限制来呈现的。对于相关领域的技术人员显而易见的是，可以在其中进行形式和细节上的各种改变。因此，本发明不应当被任何上述示例性实施方式所限制，而应当仅根据所附权利要求及其等同物来限定。
此外，摘要的目的是使专利局和公众，尤其是不熟悉专利或法律术语或措辞的本领域的科学家、工程师和从业者能够从粗略的检查中快速地确定本申请的技术公开的本质和本质。摘要不旨在以任何方式限制在此呈现的示例实施方式的范围。还应当理解，在权利要求中叙述的任何过程不需要以所呈现的顺序执行。
尽管本说明书包括许多特定实施方式细节，但这些细节不应被解释为对任何发明或可能要求保护的范围的限制，而是作为对本文所述的特定实施方式的特定特征的描述。在单独实施方式的上下文中在本说明书中描述的某些特征也可以在单个实施方式中组合实现。相反，在单个实施方式的上下文中描述的各种特征也可以在多个实施方式中单独地或以任何合适的子组合来实现。此外，尽管特征可能在上文中被描述为在某些组合中起作用并且甚至最初被如此要求保护，但是来自所要求保护的组合的一个或更多个特征在某些情况下可以从该组合中删除，并且所要求保护的组合可以针对子组合或子组合的变体。
在某些情况下，多任务和并行处理可能是有利的。此外，上述实施方式中的各种组件的分离不应被理解为在所有实施方式中都需要这种分离，并且应当理解，所描述的程序组件和系统通常可以一起集成在单个软件产品中或封装到多个软件产品中。
现在已经描述了一些说明性的实施方式和多个实施方式，显然前述是说明性的而非限制性的，已经通过示例的方式呈现。特别地，尽管这里给出的许多示例涉及装置或软件元件的特定组合，但是这些元件可以以其它方式组合以实现相同的目的。仅结合一个实施方式讨论的动作、元件和特征不旨在被排除在其它实施方式或多个实施方式中的类似角色之外。
在不脱离其特征的情况下，本文描述的装置可以以其他具体形式实施。上述实施方式是说明性的而不是对所描述的系统和方法的限制。因此，本文描述的装置的范围由所附权利要求而不是前面的描述来指示，并且落入权利要求的等同物的含义和范围内的改变包括在其中。
说明书中的公开内容还包括以下有编号的条款：
条款1.一种管理服务器侧服务与一个或更多个客户端侧服务之间的进程间通信IPC的方法，该方法包括以下步骤：
在IPC管理模块处实体化与IPC机制相关联的存根，其中，所述存根可在操作上与所述服务器侧服务交互以及与同所述存根相关联的所述IPC机制的IPC通道的第一端点交互；
获得与同所述存根相关联的所述IPC机制相关的应用编程接口API信息；以及
根据与所述存根相关联的所述IPC机制的所述API信息，实体化与所述存根相关联的所述IPC机制的所述IPC通道的第一端点。
条款2.根据条款1所述的方法，所述方法还包括：
在所述存根处从所述服务器侧服务接收将经由与所述存根相关联的所述IPC机制向一个或更多个客户端侧服务发送的消息；
从所述存根向与所述存根相关联的所述IPC机制的所述IPC通道的第一端点转发所述消息；以及
从与所述存根相关联的所述IPC通道的所述第一端点向所述一个或更多个客户端侧服务发送所述消息。
条款3.根据条款1或条款2所述的方法，其中，所述服务器侧服务具有与其相关联的配置文件，所述配置文件包括标识用于从所述服务器侧服务向所述一个或更多个客户端侧服务发送一个或更多个消息的一个或更多个IPC机制的信息。
条款4.根据条款3所述的方法，其中，实体化与所述IPC机制相关联的所述存根的步骤包括由所述服务器侧服务指示所述IPC管理模块在所述IPC管理模块处，使用从与所述服务器侧服务相关联的所述配置文件获得的标识所述IPC机制的所述信息来对所述存根进行实体化。
条款5.根据前述条款中的任一项所述的方法，所述方法还包括：
在所述IPC管理模块处实体化多个存根，其中，各个存根与不同的IPC机制相关联；以及
在所述IPC管理模块处，实体化对应于相应存根的多个IPC通道端点。
条款6.一种管理客户端侧服务与一个或更多个服务器侧服务之间的进程间通信IPC的方法，该方法包括以下步骤：
在IPC管理层处对代理进行实体化，其中，所述代理可在操作上与所述客户端侧服务交互以及与同所述代理相关联的IPC机制的IPC通道的端点交互；
获得与同所述代理相关联的IPC机制相关的应用编程接口API信息；以及
根据与所述代理相关联的所述IPC机制的API信息，实体化与所述代理相关联的所述IPC机制的IPC通道的端点。
条款7.根据条款6所述的方法，所述方法还包括：
从与所述代理相关联的所述IPC机制的IPC通道的端点接收消息；以及
向所述客户端侧服务转发所述消息。
条款8.根据条款6或条款7所述的方法，其中，所述客户端侧服务具有与其相关联的配置文件，所述配置文件包括标识用于所述该客户端侧服务处从所述一个或更多个服务器侧服务接收一个或更多个消息的一个或更多个IPC机制的信息。
条款9.根据条款8所述的方法，其中，实体化与IPC机制相关联的所述代理的步骤包括由所述客户端侧服务在所述IPC管理层处，使用从与所述客户端侧服务相关联的所述配置获得的标识所述IPC机制的信息，对所述代理进行实体化。
条款10.根据条款6至9中任一项所述的方法，所述方法还包括：
在所述IPC管理模块处对多个代理进行实体化，其中，各个代理与不同的IPC机制相关联；以及
在所述IPC管理模块处，实体化对应于相应代理的多个IPC通道端点。
条款11.一种包括计算机可读指令的计算机可读介质，所述计算机可读指令在由一个或更多个处理器执行时使所述一个或更多个处理器执行前述条款中的任一项所述的方法。
12.一种用于管理服务器侧服务与一个或更多个客户端侧服务之间的IPC的进程间通信IPC管理模块，所述IPC管理模块包括存储器和控制器，所述控制器被配置成：
在IPC管理模块处实体化与IPC机制相关联的存根，其中，所述存根可在操作上与所述服务器侧服务交互以及与同所述存根相关联的所述IPC机制的IPC通道的第一端点交互；
获得与同所述存根相关联的所述IPC机制相关的应用编程接口API信息；以及
根据与所述存根相关联的所述IPC机制的API信息，实体化与所述存根相关联的所述IPC机制的IPC通道的第一端点。
条款13.根据条款12所述的IPC管理模块，其中，所述控制器还被配置成：
在所述存根处从所述服务器侧服务接收消息，所述消息将经由与所述存根相关联的所述IPC机制向一个或更多个客户端侧服务发送；
从所述存根向与所述存根相关联的所述IPC机制的IPC通道的第一端点转发所述消息；以及
从与所述存根相关联的所述IPC通道的所述第一端点向所述一个或更多个客户端侧服务发送所述消息。
条款14.一种用于管理客户端侧服务与一个或更多个服务器侧服务之间的进程间通信IPC的进程间通信IPC管理模块，所述IPC管理模块包括存储器和控制器，所述控制器被配置成：
在IPC管理层处对代理进行实体化，其中，所述代理可在操作上与所述客户端侧服务交互以及与同所述代理相关联的IPC机制的IPC通道的端点交互；
获得与同所述代理相关联的所述IPC机制相关的应用编程接口API信息；以及
根据与所述代理相关联的所述IPC机制的所述API信息，实体化与所述代理相关联的所述IPC机制的IPC通道的端点。
条款15.根据条款14所述的IPC管理模块，其中，所述控制器还被配置成：
从与所述代理相关联的所述IPC机制的所述IPC通道的端点接收消息；以及
向所述客户端侧服务转发所述消息。

Claims (15)

1.一种管理服务器侧服务与客户端侧服务之间的服务间通信的方法，所述方法包括以下步骤：
由服务间通信管理系统从与所述服务器侧服务相关联的配置文件获得指定第一服务间通信机制的信息，所述第一服务间通信机制要用于从所述服务器侧服务向所述客户端侧服务发送一个或更多个消息，其中，所述配置文件是能够被编辑的，使得用户能够更新所述服务器侧服务使用哪种服务间通信机制；
在所述服务间通信管理系统处实体化与由所述配置文件指定的所述第一服务间通信机制相关联的存根，其中，所述存根能够在操作上与所述服务器侧服务交互；
在所述存根处，使用与所述存根相关联的第一服务间通信机制从所述服务器侧服务接收要向所述客户端侧服务转发的代理的消息，其中，所述代理与所述第一服务间通信机制相关联；以及
根据与所述服务器侧服务相关联的配置文件指定的所述第一服务间通信机制，从所述存根向所述客户端侧服务的所述代理转发所述消息。
2.根据权利要求1所述的方法，其中，所述配置文件指定进程间通信IPC机制，并且其中，所述存根与所指定的IPC机制相关联，所述方法还包括：
获得与同所述存根相关联的所述IPC机制相关的应用编程接口API信息；以及
根据与所述存根相关联的IPC机制的所述API信息，实体化与所述存根相关联的IPC机制的IPC通道的第一端点。
3.根据权利要求2所述的方法，其中，从所述存根向所述代理转发所述消息的步骤包括：
从所述存根向与所述存根相关联的IPC机制的所述IPC通道的所述第一端点转发所述消息；以及
从与所述存根相关联的所述IPC通道的所述第一端点向与所述代理相关联的IPC通道的第二端点发送所述消息。
4.根据权利要求1所述的方法，其中，所述配置文件指定非IPC机制，并且其中，从所述存根向所述代理转发所述消息的步骤包括使用一个或更多个直接函数调用从所述存根直接向所述代理转发所述消息。
5.根据前述权利要求中的任一项所述的方法，所述方法还包括检测将所述服务间通信机制从所述第一服务间通信机制更新为第二服务间通信机制的、对所述服务器侧服务的配置文件的改变，并且响应于该检测，终止与所述第一服务间通信机制相关联的所述存根，并且实体化与所述第二服务间通信机制相关联的存根。
6.一种管理客户端侧服务与服务器侧服务之间的服务间通信的方法，所述方法包括以下步骤：
由服务间通信管理系统从与所述客户端侧服务相关联的配置文件获得指定第一服务间通信机制的信息，所述第一服务间通信机制用于在所述客户端侧服务处从所述服务器侧服务接收一个或更多个消息，其中，所述配置文件是能够被编辑的，使得用户能够更新所述客户端侧服务使用哪种服务间通信机制；
在所述服务间通信管理系统处实体化与由所述配置文件指定的所述第一服务间通信机制相关联的代理，其中，所述代理能够在操作上与所述客户端侧服务交互；
在所述代理处从与所述第一服务间通信机制相关联的存根接收消息；以及
从所述代理向所述客户端侧服务转发所述消息。
7.根据权利要求6所述的方法，其中，所述配置文件指定进程间通信IPC机制，并且其中，所述代理与所指定的IPC机制相关联，所述方法还包括：
获得与同所述代理相关联的所述IPC机制相关的应用编程接口API信息；以及
根据与所述代理相关联的IPC机制的所述API信息，实体化与所述代理相关联的IPC机制的IPC通道的第二端点。
8.根据权利要求7所述的方法，其中，在所述代理处从所述服务器侧服务接收消息的步骤包括由所述服务间通信管理系统使用与所述客户端侧服务相关联的侦听器来激活所述代理。
9.根据权利要求6所述的方法，其中，所述配置文件指定非IPC机制，并且其中，在所述代理处接收所述消息的步骤包括：在所述代理处从与所述服务器侧服务相关联的所述存根接收一个或更多个直接函数调用。
10.根据权利要求6至9中的任一项所述的方法，所述方法还包括检测将所述服务间通信机制从所述第一服务间通信机制更新为第二服务间通信机制的、对所述配置文件的改变，并且响应于该检测，终止与所述第一服务间通信机制相关联的所述代理，并且实体化与所述第二服务间通信机制相关联的代理。
11.一种计算机可读介质，所述计算机可读介质包括计算机可读指令，所述计算机可读指令在由一个或更多个处理器执行时使得所述一个或更多个处理器执行根据权利要求1至10中的任一项所述的方法。
12.一种用于管理服务器侧服务与客户端侧服务之间的服务间通信的服务间通信管理系统，所述服务间通信管理系统包括存储器和控制器，所述控制器被配置成：
从与所述服务器侧服务相关联的配置文件获得指定第一服务间通信机制的信息，所述第一服务间通信机制用于从所述服务器侧服务向所述客户端侧服务发送一个或更多个消息，其中，所述配置文件是能够被编辑的，使得用户能够更新所述服务器侧服务使用哪种服务间通信机制；
在所述服务间通信管理系统处实体化与由所述配置文件指定的所述服务间通信机制相关联的存根，其中，所述存根能够在操作上与所述服务器侧服务交互；
从与所述客户端侧服务相关联的配置文件获得指定所述第一服务间通信机制的信息，所述第一服务间通信机制用于在所述客户端侧服务处从所述服务器侧服务接收一个或更多个消息，其中，所述配置文件是能够被编辑的，使得用户能够更新所述客户端侧服务使用哪种服务间通信机制；
在所述服务间通信管理系统处实体化与由所述配置文件指定的所述第一服务间通信机制相关联的代理，其中所述代理能够在操作上与所述客户端侧服务交互；
在所述存根处，使用与所述存根相关联的所述第一服务间通信机制从所述服务器侧服务接收要向所述客户端侧服务发送的消息；
根据所述第一服务间通信机制从所述存根向所述代理转发所述消息；
在所述代理处根据所述第一服务间通信机制从所述存根接收所述消息；以及
从所述代理向所述客户端侧服务转发所述消息。
13.根据权利要求12所述的服务间通信管理系统，其中，所述第一服务间通信机制是进程间通信IPC机制，并且其中，所述存根和所述代理均与所述IPC机制相关联，所述控制器还被配置成：
获得与所述IPC机制相关的应用编程接口API信息；
根据与所述存根相关联的所述IPC机制的所述API信息，实体化与所述存根相关联的所述IPC机制的IPC通道的第一端点；以及
根据与所述代理相关联的IPC机制的API信息，实体化与所述代理相关联的所述IPC机制的所述IPC通道的第二端点。
14.根据权利要求12所述的服务间通信管理系统，其中，所述第一服务间通信机制是非IPC机制，并且其中，从所述存根向所述代理转发所述消息包括使用一个或更多个直接函数调用从所述存根直接向所述代理转发所述消息。
15.根据权利要求12至14中的任一项所述的服务间通信管理系统，所述控制器还被配置成：
检测将所述服务器侧服务的所述服务间通信机制从第一服务间通信机制更新为第二服务间通信机制的、对所述服务器侧服务的配置文件的改变，并响应于该检测，终止与所述第一服务间通信机制相关联的所述存根，并实体化与所述第二服务间通信机制相关联的存根；和/或
检测将所述客户端侧服务的所述服务间通信机制从第一服务间通信机制更新为第二服务间通信机制的、对所述客户端侧服务的配置文件的改变，并响应于该检测，终止与所述第一服务间通信机制相关联的所述代理，并实体化与所述第二服务间通信机制相关联的代理。
CN202210310505.2A 2021-03-26 2022-03-28 管理服务间通信的方法、服务间通信管理系统 Active CN115134406B (zh)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP21165340.7 2021-03-26
EP21165340 2021-03-26
EP22163826.5A EP4064053A1 (en) 2021-03-26 2022-03-23 Managing inter-service communication
EP22163826.5 2022-03-23

Publications (2)

Publication Number Publication Date
CN115134406A CN115134406A (zh) 2022-09-30
CN115134406B true CN115134406B (zh) 2024-01-09

Family

ID=75252479

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210310505.2A Active CN115134406B (zh) 2021-03-26 2022-03-28 管理服务间通信的方法、服务间通信管理系统

Country Status (3)

Country Link
US (1) US11785111B2 (zh)
EP (1) EP4064053A1 (zh)
CN (1) CN115134406B (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20010093465A (ko) * 2000-03-29 2001-10-29 윤종용 코버플락시모듈을 이용한 다양한 프로토콜 공통 서비스를위한 분산객체 지향 통신시스템 및 그 방법
CN103946833A (zh) * 2011-11-11 2014-07-23 摩博菲乐有限公司Dba摩博莱 管理专用缓存的系统和方法
CN104396220A (zh) * 2012-06-21 2015-03-04 思科技术公司 用于安全内容检索的方法和设备
KR101927721B1 (ko) * 2017-07-14 2019-02-27 한국과학기술원 어플리케이션 수행에 있어서 모바일 기기 간에 기능을 분배하는 방법
CN110647754A (zh) * 2018-06-27 2020-01-03 国际商业机器公司 用于数据机密性和完整性的文件系统视图分离
CN111181992A (zh) * 2020-01-03 2020-05-19 平安科技（深圳）有限公司 区块链中节点与链码的通信方法、装置、设备及存储介质

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5557798A (en) 1989-07-27 1996-09-17 Tibco, Inc. Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
CA2066538C (en) 1991-07-09 1997-12-23 Brian David Bolliger Mobile-telephone system call processing arrangement
US8726294B2 (en) * 2010-10-01 2014-05-13 Z124 Cross-environment communication using application space API
US7318083B2 (en) * 2001-08-27 2008-01-08 Ricoh Company, Ltd. Information processing system
US20100242099A1 (en) * 2002-04-05 2010-09-23 Tsao Sheng Tai Ted Method and apparatus of UI design for web-based computer user working environment
US7356562B2 (en) * 2003-04-30 2008-04-08 International Business Machines Corporation Dynamic generator for fast-client static proxy from service interface definition document
US7483438B2 (en) * 2005-04-14 2009-01-27 Alcatel Lucent Systems and methods for managing network services between private networks
US20080222659A1 (en) 2007-03-09 2008-09-11 Microsoft Corporation Abstracting operating environment from operating system
US8225085B2 (en) * 2007-06-05 2012-07-17 Blue Coat Systems, Inc. System and method for distributed SSL processing between co-operating nodes
US8862660B1 (en) * 2011-08-04 2014-10-14 Wyse Technology L.L.C. System and method for facilitating processing of communication
US9563488B2 (en) * 2014-05-29 2017-02-07 Apple Inc. Sharing extension points to allow an application to share content via a sharing extension
US9866521B2 (en) * 2015-07-30 2018-01-09 At&T Intellectual Property L.L.P. Methods, systems, and computer readable storage devices for determining whether to forward requests from a physical telephone number mapping service server to a virtual telephone number mapping service server
US10333985B2 (en) * 2017-01-09 2019-06-25 Microsoft Technology Licensing, Llc Distribution and management of services in virtual environments
US20200389469A1 (en) * 2017-12-24 2020-12-10 Arilou Information Security Technologies Ltd. System and method for tunnel-based malware detection
CN110688233B (zh) 2018-07-05 2022-05-10 武汉斗鱼网络科技有限公司 基于rxjs的客户端ipc通讯方法、存储介质、设备及系统
US10862998B2 (en) * 2018-11-06 2020-12-08 Citrtix Systems, Inc. Systems and methods for managing downloads from an embedded browser
US11457080B1 (en) * 2018-11-23 2022-09-27 Amazon Technologies, Inc. Service mesh management

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20010093465A (ko) * 2000-03-29 2001-10-29 윤종용 코버플락시모듈을 이용한 다양한 프로토콜 공통 서비스를위한 분산객체 지향 통신시스템 및 그 방법
CN103946833A (zh) * 2011-11-11 2014-07-23 摩博菲乐有限公司Dba摩博莱 管理专用缓存的系统和方法
CN104396220A (zh) * 2012-06-21 2015-03-04 思科技术公司 用于安全内容检索的方法和设备
KR101927721B1 (ko) * 2017-07-14 2019-02-27 한국과학기술원 어플리케이션 수행에 있어서 모바일 기기 간에 기능을 분배하는 방법
CN110647754A (zh) * 2018-06-27 2020-01-03 国际商业机器公司 用于数据机密性和完整性的文件系统视图分离
CN111181992A (zh) * 2020-01-03 2020-05-19 平安科技（深圳）有限公司 区块链中节点与链码的通信方法、装置、设备及存储介质

Also Published As

Publication number Publication date
CN115134406A (zh) 2022-09-30
US20220311835A1 (en) 2022-09-29
US11785111B2 (en) 2023-10-10
EP4064053A1 (en) 2022-09-28

Similar Documents

Publication Publication Date Title
JP7042317B2 (ja) ローカルまたは分散型コンピュータ・システムにおける柔軟なノード構成方法およびシステム
US10959089B2 (en) Data management microservice in a microservice domain
JP4638676B2 (ja) 共有リソースのための通知方法
US9246844B2 (en) Method for activating and deactivating client-side services from a remote server
CN110311983B (zh) 服务请求的处理方法、装置、系统、电子设备及存储介质
US20190132276A1 (en) Unified event processing for data/event exchanges with existing systems
JP4661774B2 (ja) 中継サーバ
US20120113459A1 (en) Protocol for interaction between wireless devices and other devices
CN111345008B (zh) 移动边缘主机服务通知方法和装置
US20100057827A1 (en) Extensible Network Discovery Subsystem
CN101160880A (zh) 通信设备与方法
CN109194589B (zh) 一种mdc实现方法及装置
US20190028414A1 (en) System And Method For Providing a Communications Layer to Enable Full Participation in a Distributed Computing Environment That Uses Multiple Message Types
JP2017208797A (ja) 不均一ネットワークにまたがる統合されたデータ・ネットワーキング
WO2018107433A1 (zh) 信息处理方法和装置
CN115134406B (zh) 管理服务间通信的方法、服务间通信管理系统
JP2007066061A (ja) データ送信装置、受信装置、送信システム、受信システム、方法及び端末装置
JPH11224226A (ja) クライアント・サーバ間のゲートウェイにおけるインタフェース及びクライアント・サーバ間のプロトコルマッピング方法
CN117527458B (zh) 一种多播数据分发方法、装置、电子设备及存储介质
JP7259099B2 (ja) マルチルート通信システムおよびルート選択システム
CN116996435A (zh) 一种报文处理方法及装置
CN113992492A (zh) 基于扩展tcp协议实现单地址单端口连接的管理方法
CN111258560A (zh) 数据存储装置、系统及方法
CN115617450A (zh) 基于Ivshmem的通讯方法、系统、设备及存储介质
JP2022090266A (ja) 情報処理装置、情報処理システム、情報処理方法及びプログラム

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
GR01 Patent grant
GR01 Patent grant