Access service application components across multiple devices

Abstract

The mobile device implements an inter-process communication (IPC) mechanism through which services on each device in a cluster group can be accessed by other devices in the cluster group using intra-device IPC calls. The inter-device IPC mechanism extends the existing intra-device IPC mechanism so that existing applications between devices in the cluster group can use the mechanism with little or no modification to the applications. The mobile device establishes pseudo-tokens for objects on the mobile device and pseudo-handlers for objects on other devices. The mobile device can access multiple objects on other devices and can provide access to local objects for multiple other devices. Each object accessed through the inter-device IPC call is associated with a corresponding service adapter in the corresponding communication service gateway of each participating device.

Description

[0001] Cross-reference to related applications

[0002] none Technical Field

[0003] The present invention generally relates to enabling application service components to be accessible across devices. Specifically, the present invention relates to implementing an inter-process communication (IPC) mechanism that can be used by existing applications to enable access to service components and resources across multiple devices. Background Art

[0004] Mobile devices, such as smartphones and tablets, typically act as standalone devices, providing services to users. Because they can run many different types of applications, these devices present data security and reliability issues. To reduce the possibility of unwanted interactions between applications, the operating systems used by these devices typically isolate each executing application in a separate container, or sandbox.

[0005] As used herein, a container is a software package that includes an executable program as well as system tools, libraries, settings, and other data or code used by the software. A sandbox is a separate address space used by an application. Both containers and sandboxes isolate the programs they contain from other software and the operating system (OS). While these concepts are different, they both provide a mechanism for separating programs running in a common environment. Therefore, for simplicity, any use of the term container also includes sandbox functionality. Containers provide security advantages because they separate programs running on a mobile device, preventing software running in the container from affecting the host operating system or other programs running on the mobile device. While a program running in a container may change system settings and modify resources, the program only modifies settings within the container.

[0006] Multiple containers run on a shared OS kernel, each corresponding to a different application or service. Containers are implemented in a layer above the physical processing system and its host OS (such as Apple® iOS or Google® Android). Each container shares the host OS kernel and may share other software components, such as libraries. However, shared components are typically read-only to prevent interaction between applications running in separate containers.

[0007] Inter-process communication (IPC) is a fundamental mechanism used by operating systems to enable applications running in one container to communicate with applications running in another container on the same device. Through IPC, a service can interact with multiple clients on the same device. For example, on Android, the Binder service provides an IPC mechanism for client components to interact with service components. In Apple iOS, IPC can be implemented using Apple MACH messages and application extensions, which enable members of an application group to share a common container that can be used by applications to share data. Thus, IPC provides a mechanism for applications running in separate containers to communicate with each other. IPC enables client applications to bind to a service and then call data and / or methods exported by the service, even if the client and service are running in different containers. A bound service is an implementation of a service class that enables other applications to interact with the service; "binding" refers to the act of establishing a connection with a bound service. IPC drivers implemented in the kernel can provide links to different services accessible using IPC.

[0008] FIG1 is a block diagram of a mobile device 100 that includes processing hardware 122, an operating system kernel 118, and two applications: process A, which runs in a container 102 and has user data 104; and process B, which runs in a container 112 and has user data 114. In this example, process A (the client) wishes to access process B (the server)'s user data 114. Process A includes an IPC token 106 for user data 114, and process B includes an IPC handler 116 for user data 114.

[0009] A typical IPC system operates as follows. First, a client application establishes a communication channel with a server application. To do this, the client (process A) initiates the establishment request by sending an intent to the IPC driver 120, which includes information about the server (process B), such as the package name, service class name, and other data about the requested service. The IPC driver 120 polls the system server (not shown) to determine whether the server provides user data 114 as the requested service and has created an IPC handler 116 for the service. While Figure 1 illustrates user data 114 as a service, it is contemplated that the service could be a process or application running on the server and / or a database accessible on the server. Information about the service is registered with the system server on the mobile device 100 so that it can be accessed by other applications running on the mobile device 100. The IPC driver then creates an IPC token 106 and returns it to the client (process A). To access the service 114, process A encapsulates the call ID (an identifier describing the origin of the request and any parameters used by the service 114) into the package. Process A then passes the packet and IPC token 106 to the IPC driver 120. The IPC driver uses the IPC token to identify the corresponding IPC handler based on the previously established channel and passes the packet to the IPC handler 116 of process B. The IPC handler 116 then decapsulates the packet, processes the service request, and returns the result to the IPC driver 120 with the call ID. The IPC driver passes the result to process A based on the call ID. Because a server application can serve multiple clients, an IPC handler in a server application can be associated with many IPC tokens in different client applications. Summary of the Invention

[0010] The following example describes an apparatus and method for implementing an inter-device IPC mechanism that is compatible with existing intra-device IPC mechanisms. A mobile device registers objects on other devices and establishes pseudo-handlers for these objects. The mobile device also establishes pseudo-tokens for objects on the mobile device that can be accessed by other devices. The pseudo-token is a placeholder for the IPC token used to access the service. The pseudo-token exists on the server device and represents the IPC token in intra-device IPC calls for objects on the server device. The client device uses the IPC token and pseudo-handler to implement the intra-device IPC call on the client device. The communication link between the pseudo-handler on the client device and the pseudo-token on the server device links the client and server devices, thereby enabling inter-device IPC calls. The mobile device can access multiple objects on other devices and can provide multiple other devices with access to local objects on the mobile device. Each object accessed through an inter-device IPC call is associated with a corresponding service adapter in the corresponding communication service gateway of each participating device.

[0011] According to a first aspect of the present invention, a first device receives a first request from a second device via a communication service gateway of the first device to bind a first object on the first device. The first device assigns a first pseudo-token for the first object to the communication service gateway. The first device creates a first service context for the first object and associates the first service context with the first pseudo-token. The first device provides the first service context to the second device via the communication service gateway as a response to the first request to bind the first object.

[0012] According to the first aspect, in a first implementation of a first device, the first device obtains an inter-device IPC call and a first service context associated with the first object from the second device through the communication service gateway of the first device. The first device identifies the first pseudo-token as being associated with the first service context and obtains an inbound package including input parameters of the inter-device IPC call. The first device processes the inbound package and uses the first pseudo-token to initiate an intra-device IPC call using the processed inbound package of the first object. The first device obtains a reply to the intra-device IPC call, the reply including an outbound package. The first device processes the outbound package and provides the processed outbound package to the second device through the communication service gateway, the processed outbound package being provided using a response to the inter-device IPC call.

[0013] According to the first aspect, in a second implementation of a first device, the first device obtains a second request to bind a second object from an application running on the first device, and determines that the second object is a remote object on the second device. The first device generates a message including the second request and provides the message to the second device through the communication service gateway. The first device obtains a second service context of the second object from the second device as a response to the second request to bind the second object. The first device creates a first pseudo-handler for the second object and associates the second service context with the first pseudo-handler in the communication service gateway on the first device. The first device provides an IPC token corresponding to the first pseudo-handler to the application running on the first device.

[0014] According to the first aspect, in a third implementation of the first device, the first device obtains an intra-device IPC call of the second object on the second device from the application running on the first device. The first device calls the first pseudo-handler in the communication service gateway and identifies the second service context as associated with the first pseudo-handler. The first device obtains an outbound package including input parameters for the inter-device IPC call. The first device processes the outbound package and provides the inter-device IPC call to the second device through the communication service gateway using the processed outbound package and the second service context. The first device obtains a reply to the inter-device IPC call through the communication service gateway, the reply including an inbound package in the second device. The first device processes the inbound package and provides the processed inbound package to the application as a response to the intra-device IPC call.

[0015] According to the first aspect, in a fourth implementation of the first device, the first device obtains a third request to bind a third object on the first device from a third device via the communication service gateway. The first device assigns a second pseudo-token for the third object to the communication service gateway. The first device obtains a third service context for the third object and associates the third service context with the second pseudo-token for the third object. The first device provides the third service context to the third device via the communication service gateway as a response to the third request to bind the third object.

[0016] According to the first aspect, in a fifth implementation of the first device, the first device obtains a second request to bind the first object on the first device from a third device through the communication service gateway, and provides the first service context to the third device through the communication service gateway as a response to the second request to bind the first object.

[0017] According to the first aspect, in a sixth implementation manner of the first device, the third device includes the second device.

[0018] According to a second aspect of the present invention, a first device obtains a first request to bind a first object from an application running on the first device. The first device determines that the first object is a remote object on a second device and generates a message including the first request. The first device provides the message to the second device via a communication service gateway on the first device. In response to the message, the first device obtains a first service context for the first object from the second device. The first device creates a first pseudo-handler and associates the first pseudo-handler with the first service context in the communication service gateway. The first device provides a first IPC token corresponding to the first pseudo-handler to the application on the first device.

[0019] According to the second aspect, in a first implementation of the first device, the first device obtains an intra-device IPC call of the first object on the second device from the application running on the first device. The first device calls the first pseudo-handler in the communication service gateway and identifies the first service context associated with the first pseudo-handler on the first device. The first device obtains an outbound package including input parameters of the inter-device IPC call, processes the outbound package, and provides the inter-device IPC call to the second device through the communication service gateway using the processed outbound package and the first service context. The first device obtains an inbound package from the second device as a reply to the inter-device IPC call. The first device processes the inbound package and provides the processed inbound package and the response to the intra-device IPC call to the application.

[0020] According to the second aspect, in a second implementation of a first device, the first device obtains a second request to bind a second object from the application and determines that the second object is a remote object on a third device. The first device generates a message including the second request and provides the message to the third device through the communication service gateway. The first device obtains a second service context of the second object from the third device as a response to the second request to bind the second object. The first device creates a second pseudo-handler and associates the second pseudo-handler with the second service context in the communication service gateway. The first device provides a second IPC token corresponding to the second pseudo-handler to the application.

[0021] According to the second aspect, in a third implementation manner of the first device, the third device includes the second device.

[0022] According to the second aspect, in a fourth implementation manner of the first device, the first device receives a third request to bind the first object from a second application running on the first device, determines that the first object is a remote object on the second device, identifies the first pseudo handler of the first object, and provides a third IPC token corresponding to the first pseudo handler to the second application.

[0023] According to the second aspect, in a fifth implementation of the first device, the first device obtains a fourth request from the second device to bind a third object on the first device via the communication service gateway of the first device. The first device assigns a second pseudo-token for the third object to the communication service gateway. The first device creates a third service context for the third object and associates the third service context with the second pseudo-token for the third object. The first device provides the third service context to the second device via the communication service gateway as a response to the fourth request to bind the third object.

[0024] According to the first aspect or the second aspect, in a first implementation of a first device, the first device processes the outbound package by identifying a marshaled object in the outbound package and determining that the marshaled object references a local data object outside the package. The first device further processes the outbound package by creating a local data object stub for the marshaled object and a reference to the local data object stub, and marshaling the reference to the local data object stub into the processed outbound package as a replacement for the marshaled object.

[0025] According to the first aspect or the second aspect, in a second implementation of the first device, the first device processes the outbound package by identifying a marshaled object in the outbound package and determining that the marshaled object is a data descriptor of a data value outside the outbound package. The first device further processes the outbound package by creating a reference to the data descriptor and marshaling the reference to the data descriptor into the processed outbound package as a replacement for the data descriptor.

[0026] According to the first aspect or the second aspect, in a third implementation of the first device, the first device processes the inbound package by identifying a marshaled object in the inbound package and determining that the marshaled object is a reference to a remote data object stub. The first device further processes the inbound package by creating a remote data object proxy linked to the remote data object stub to allow remote access to the remote data object referenced by the remote data object stub, and marshaling the remote data object proxy into the processed inbound package as a replacement for the marshaled object.

[0027] According to the first aspect or the second aspect, in a fourth implementation of the first device, the first device processes the inbound package by determining that a marshaled object identified in the inbound package is a reference to a data descriptor that references a data value outside the inbound package. The first device further processes the inbound package by obtaining and storing the referenced data value and creating a new data descriptor for the locally stored referenced data value. The first device marshals the new data descriptor into the processed inbound package as a replacement for the marshaled object.

[0028] According to the first aspect or the second aspect, in a fifth implementation manner of the first device, the first device processes the outbound package by determining that the marshaled object identified in the outbound package includes an IPC token object of another object local to the first device. The first device further processes the outbound package by creating another service context for the IPC token object, marshaling the another service context into the processed outbound package as a replacement for the IPC token object, and associating the another service context with the IPC token object.

[0029] According to the first aspect or the second aspect, in a sixth implementation of the first device, the first device obtains another inter-device IPC call and the another service context of the another object from the second device through the communication service gateway of the first device. The first device identifies the IPC token object as being associated with the another service context, and obtains another inbound package including input parameters of the another inter-device IPC call. The first device processes the another inbound package and uses the pseudo-token of the second object to initiate another intra-device IPC call using the processed another inbound package. The first device obtains another reply to the intra-device IPC call, the another reply including another outbound package; processes the another outbound package; and provides the processed another outbound package and the reply to the inter-device IPC call to the second device through the communication service gateway.

[0030] According to the first aspect or the second aspect, in a seventh implementation manner of the first device, when processing the inbound package, the first device determines that the marshaled object identified in the inbound package includes another service context of another object on the second device. The first device creates a service dummy handler for the other service context and marshals the service dummy handler into the processed inbound package as a replacement for the marshaled other service context. The first device associates the service dummy handler with the other service context.

[0031] According to the first aspect or the second aspect, in an eighth implementation of the first device, the first device obtains an intra-device IPC call of the other object on the second device. The first device calls the service pseudo-handler, identifies the other service context associated with the service pseudo-handler on the first device, and obtains another outbound package including input parameters of another inter-device IPC call. The first device processes the other outbound package and provides the other inter-device IPC call to the second device through the communication service gateway using the processed other outbound package and the other service context. The first device obtains another inbound package from the second device through the communication service gateway as a reply to the other inter-device IPC call. The first device processes the other inbound package and provides the processed other inbound package as a response to the intra-device IPC call.

[0032] This summary briefly introduces some concepts that will be further described in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The claimed subject matter of a patent application is not limited to implementations that solve any or all of the problems mentioned in the background. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The present invention in its aspects is illustrated by way of example and not limitation in the accompanying figures, in which like references indicate similar elements.

[0034] FIG. 1 (Prior Art) is a block diagram of an exemplary mobile device.

[0035] Figure 2 、 Figure 3 and Figure 4 is a block diagram of a system including an inter-device IPC mechanism provided by an exemplary embodiment.

[0036] Figure 5A 4 is a flowchart provided by an exemplary embodiment, which illustrates the operation of an inter-device IPC mechanism when establishing a channel for an inter-device IPC call.

[0037] Figure 5B FIG. 4 is a flowchart provided by an exemplary embodiment, which shows that an application on a client device calls a remote service through an established inter-device IPC call.

[0038] Figure 6 An exemplary embodiment provides a system in which multiple client applications bind common services using an inter-device IPC mechanism.

[0039] Figure 7 is a functional block diagram of a system 700 that includes a communication channel used by a client application to bind a service in a server application.

[0040] Figure 8 The RPC object package provided by the exemplary embodiment is shown.

[0041] Figure 9 is a flow chart of a method for processing an outbound package provided by an exemplary embodiment.

[0042] Figure 10 is a flow chart of a method for processing an inbound package provided by an exemplary embodiment.

[0043] Figure 11 is a flowchart provided by an exemplary embodiment, which shows an exemplary method for terminating an inter-device IPC service and reclaiming an inter-device IPC structure.

[0044] Figure 12 is a block diagram of a computing device provided by an exemplary embodiment. DETAILED DESCRIPTION

[0045] The IPC mechanisms used on mobile devices are designed to support interaction between processes running on the same operating system on a single device. Device services are typically not visible across device boundaries and cannot be used by client applications running on other devices via IPC. Currently, some applications exist that can work across devices. These applications use remote procedure call (RPC) or RESTful (Representational State Transfer) application programming interfaces (APIs) and / or specialized software development kits (SDKs) to implement special-purpose solutions. These specialized solutions often require significant programming effort and / or modifications to existing applications. The embodiments described below implement a protocol that allows devices to form cluster groups, each of which includes two or more devices. The protocol enables services on one device to be accessed by other devices within the cluster group. The protocol implemented in these embodiments extends the existing IPC mechanism so that existing applications between devices in the cluster group can use the mechanism with little or no modification to the applications. The exemplary protocol can be implemented in a manner that allows applications running on devices in a cluster group to access resources using an existing IPC framework, as a supplement to the OS kernel, and the existing IPC framework includes IPC tools for implementing IPC on each device. Because different devices may use different IPC tools, this application does not refer to specific tools, but rather to general tools such as IPC tokens, IPC handlers, and IPC drivers. In addition, this application describes additional IPC tools for inter-device IPC, including pseudo-tokens, pseudo-handlers, two communication service gateways, an RPC adapter, and communication services such as RPC services.

[0046] First, it should be understood that even though the following provides an illustrative implementation of one or more embodiments, the following description of the embodiments in conjunction with FIG. Figure 12 The disclosed systems, methods, and / or devices described may be implemented using any number of techniques, whether currently known or not yet in existence. The present invention should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

[0047] The following is a detailed description with reference to the accompanying drawings, which form a part of the description and illustrate, by way of illustration, specific embodiments that can be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the subject matter of the present invention, and it should be understood that other embodiments may be utilized and that structural, logical, and electrical changes may be made without departing from the scope of the present invention. Therefore, the following description of exemplary embodiments should not be construed in a restrictive sense, and the scope of the present invention is defined by the appended claims.

[0048] Figure 2 FIG2 is a block diagram of a system 200 including an inter-device IPC mechanism provided by an exemplary embodiment. The exemplary inter-device IPC mechanism is transparent and compatible with existing intra-device IPC mechanisms. Therefore, for many existing client applications, the same code can be used for both intra-device and inter-device IPC communications. Figure 2 The exemplary system shown includes two mobile devices: a client device 202 and a server device 222. The description below uses the labels "client" and "server" to describe users and providers of services. Any of the devices described below can operate as a client, a server, or both. The exemplary client device 202 includes hardware 218 and an OS kernel 214 that includes an IPC driver 216. The client device 202 includes a client application 204 having user data 206 and an IPC token 208. The exemplary client device 202 also has a communication service gateway 210 that includes a pseudo handler 212, which will be described in detail below. The communication service gateway 210 in the client device 202 supports inter-device IPC with little or no changes to the client application 204. The communication service gateway 210 uses the existing native IPC driver 216 to provide access to services, such as the user data object 226 of the server application 224. The exemplary server device 222 includes hardware 238, a kernel 234 including an IPC driver 236, and a server application 224 including a user data object 226 and an IPC handler 228. The server device also includes a communication service gateway 230 having a pseudo token 232, both of which are described below. The client device 202 is coupled to the server device 222 via a communication channel 240. The communication channel used in the exemplary embodiment is an RPC channel using a socket connection. For example, the channel 240 may include a RESTful API.

[0049] In the exemplary system 200, a server device 222 advertises the available services (e.g., user data objects 226) provided by its server application 224 when joining a cluster group. In some exemplary embodiments, multiple server applications 224 can provide the services advertised by the server device 222. Figure 3 and Figure 5A As described above, client device 202 registers these services so that they can be accessed using the IPC tools of client device 202. Client application 204 requests access to registered user data object 226 and obtains an IPC token 208 corresponding to the registered service. IPC driver 216 sends the request to communication service gateway 210 using standard IPC mechanisms. Communication service gateway 210 creates a dummy handler 212 on client device 202 corresponding to registered user data object 226. Thus, client application 204 uses IPC token 208 and the existing IPC driver 216 to access user data object 226 as if the user data object 226 were hosted by the client device. Dummy handler 212 processes the request for user data object 226 and sends it to server device 222. In an exemplary embodiment, communication is carried out using a communication channel 240 (e.g., an RPC channel) between client device 202 and server device 222. When the server device receives the request via the communication channel 240, it unpacks the request and establishes a communication service gateway 230 that includes a pseudo token 232 for the user data object 226. The pseudo token 232 corresponds to the pseudo handler 212. The communication service gateway 230 uses the pseudo token 232 and the IPC driver 236 to access the user data object 226 using the IPC handler 228 according to the normal intra-device IPC mechanism of the server device 222. Figure 2 In the example shown, the communication service gateway sends a request for a user data object 226 along with a pseudo token 232 to an IPC driver 236. The IPC driver, in turn, sends the request to an IPC handler 228. The IPC handler 228 uses the IPC driver 236 to provide the requested data object 226 to the communication service gateway 230. The communication service gateway 230 then processes the data for transmission to the client device via a communication channel 240. The communication service gateway 210 on the client device 202 unpacks the data and provides it to the client application 204 via the pseudo handler 212 and the IPC driver 216. The communication service gateway 210, the pseudo handler 212, the communication channel 240, the communication service gateway 230, and the pseudo token 232 act as a nominal middleman service that is transparent to the processes running on the client device 202 and the server device 222.

[0050] Figure 3 FIG3 is a block diagram of a system 300 for implementing protocols for cross-device service management provided by an exemplary embodiment. These protocols include, but are not limited to, elements such as data modeling, service publishing, service browsing and / or discovery, and remote messaging and / or execution. Figure 3 A method of registering a nominal service on a client device and publicly making the service available on a server is shown. Figure 3 Two mobile devices 302 and 322 are included. Device 302 includes hardware 340 and OS kernel 310. Similarly, device 322 includes hardware 350 and OS kernel 330. In this example, process B in container 304 of mobile device 302 has services that can be provided to other devices in the cluster group. As described above in conjunction with Figure 1, each mobile device includes a system server. Figure 3 In the example, device 302 includes a system server 314 with a service manager 312, and device 322 includes a system server 332 with a service manager 334. Container 304's registration link 306 uses kernel support 308 to allow process B to register its services with system server 314's service manager 312. The service manager, in turn, uses kernel support 316 to allow communication service gateway 320 to query for available services. In this embodiment, device 302 advertises its services to device 322. This occurs via a query 318 generated by communication service gateway 320 and sent to the communication service gateway 324 of client device 322 via communication channel 240 (e.g., an RPC service). At client device 322, upon discovering an available service from device 302, communication service gateway 324 registers the service with system server 332's service manager 334 using register 326 via kernel support 328 of client device 322.

[0051] 1 , when a client process on device 322 accesses a service, the IPC tool on device 322 looks for the service registered with service manager 334. When the client process discovers that the service is on device 302, it sends a request to access the service through communication service gateway 324, which accesses the service through communication service gateway 320 on device 302 using communication channel 240. Figure 3 An example is shown in which device 302 advertises its services to other devices in a cluster group. Alternatively, device 322 can send a discovery query (not shown) to device 302 to discover available services. Through service advertisements from communication service gateway 320 and / or discovery from communication service gateway 324, multiple devices can form a cluster group to support service sharing among the devices in the cluster group. The cluster group can expand or contract as devices join or leave. As described below, each member of a cluster group can provide different types of services to other members of the group. These services typically involve data transmitted between server devices and client devices. For example, data shared across devices can include simple data, data references (e.g., access references or file descriptors), results of methods executed on device 302, and / or database references. As described in the examples below, different types of data are handled differently based on policies and data attributes (e.g., size, type, and access latency sensitivity), ensuring that data can be properly shared and accessed between devices.

[0052] Figure 3 The system shown in may include multiple RPC adapters ( Figure 3 ), each service being accessed on device 302 corresponds to an RPC adapter. In addition, device 302 may include multiple unassigned RPC adapters (not shown), each of which includes code and data structures for implementing the RPC adapter. When an application running on device 302 exposes a service for use by other devices upon request, one of these unassigned RPC adapters is assigned to the newly exposed service. Similarly, device 322 may include multiple RPC adapters ( Figure 3 ), there is one RPC adapter for each service accessed by an application running on device 322. Device 322 may also include multiple unassigned RPC adapters (not shown). The communication service gateway 324 may allocate one of these unassigned RPC adapters in response to a request for a service from one of the applications running on device 322. Typically, each device 302 includes a set number of unassigned RPC adapters. When all RPC adapters on a server device are allocated, the device will not be able to provide any more inter-device services. When all RPC adapters on a client device are allocated, the device will not be able to access any more inter-device services. As described below with reference Figure 11 As described above, when an application stops using a service, the RPC adapter associated with the service is returned to the device as an unassigned RPC adapter. Similarly, when an application stops providing a service, the RPC adapter associated with the service is returned to the device as an unassigned RPC adapter.

[0053] Figure 4 is a block diagram of a system 400 including an inter-device IPC mechanism provided by an exemplary embodiment. Figure 4 The system in FIG4 includes a client device 402 and a server device 430. Client device 402 includes applications 404 and a system server 420, which may be part of an OS kernel (not shown). Applications 404 include client applications 406 and a communication service gateway 410. Client applications 406 include an IPC token 408 for services available on server device 430. In addition, communication service gateway 410 includes an RPC adapter 412 coupled to an RPC service 416. RPC adapter 412 includes a dummy handler 414. System server 420 of the client device includes a service manager 422 and a remote service manager 424.

[0054] The exemplary server device 430 includes a server application 432 having IPC handlers 433 for available services. The server device 430 also includes a communication service gateway 434 that corresponds to the communication service gateway 410 of the client device. The communication service gateway 434 includes an RPC adapter 436 and an RPC service 440. The RPC adapter 436 includes a pseudo token 438 that corresponds to the pseudo handler 414 of the client device 402. The two RPC services 416 and 440 are coupled via a communication channel 240. In this example, the communication channel 240 includes a command channel 240C and a data channel 240D. In the exemplary embodiment, both channels 240C and 240D are network socket connections that connect the client device 402 to the server device 430. Figure 5A and Figure 5B The operation of system 400 in establishing and using a remote IPC channel is described. Although the exemplary embodiment describes an RPC service using a socket connection, it is contemplated that other types of communication services may be used, such as, but not limited to, RESTful APIs, gRPC, or desktop bus (D-Bus).

[0055] like Figure 4As shown, each device includes a communication service gateway and may include multiple RPC adapters. Each RPC adapter may, in turn, include multiple pseudo-handlers and pseudo-tokens. For example, client device 402 includes communication service gateway 410, which includes multiple RPC adapters, such as RPC adapter 412. RPC adapter 412 includes multiple pseudo-handlers 414 and multiple pseudo-tokens 415. Other RPC adapters may also include multiple pseudo-handlers and / or multiple pseudo-tokens. Similarly, device 430 includes communication service gateway 434, which includes multiple RPC adapters, such as RPC adapter 436. Each RPC adapter may include multiple pseudo-handlers and / or multiple pseudo-tokens, such as pseudo-handler 439 and pseudo-token 438 for RPC adapter 436. Each pseudo-handler 414 enables applications running on client device 402 to access services on a separate server device (e.g., server device 430), where the services are registered on client device 402 and linked to RPC adapter 412. Each pseudo-token 415 enables an application running on another device to access a service on client device 402. Each service is associated with a separate RPC adapter. Multiple applications on client device 402 can each use a different pseudo-handler in pseudo-handler 414 to access the same service on server device 430. Similarly, multiple applications running on another device or multiple other devices can use different pseudo-tokens in pseudo-token 415 to access a service on client device 402. Communication service gateway 434, RPC adapter 436, pseudo-handler 439, and pseudo-token 438 operate in the same manner as communication service gateway 410, RPC adapter 412, pseudo-handler 414, and pseudo-token 415.

[0056] Figure 5Ais a flowchart provided by an exemplary embodiment, illustrating the operation of an inter-device IPC mechanism when establishing a channel for inter-device IPC calls. In operation 502, client application 406 initiates a request including an intent and an action to bind to a target service provided by server application 432 on server device 430. In operation 504, client application 406 sends information about the target service (e.g., package name and service name) to service manager 422. In operation 506, service manager 422 provides information to remote service manager 424 to determine whether the target service is a remote service (e.g., a service that is not available on the client device but is available on another device (e.g., server device 430)). If the target service is a remote service, remote service manager 424 identifies an RPC adapter 412 to handle local access to the remote service. As described above, device 402 may include multiple unassigned RPC adapters 412. When no RPC adapter is assigned to a remote service, the communication service gateway may assign one of the unassigned RPC adapters 412 to the remote service. When the target service has an assigned RPC adapter 412, service manager 422 composes an intent for RPC adapter 412 at operation 508, appends the original request to the intent, and sends the composed intent to RPC adapter 412. In operation 510, RPC adapter 412 processes the original request and identifies server application 432 running on server device 430 as the server to handle the action indicated in the original request. Operation 510 also creates a dummy handler 414 to act as a proxy on client device 402 for the service on server application 432 of server device 430. In operation 512, dummy handler 414 of RPC adapter 412 and communication service gateway 410 compose a message including the original request and send the message and associated data to server device 430 via RPC service 416 using communication channel 240.

[0057] In operation 514, RPC service 440 of server device 430 receives the message and retrieves the original request from the message. Based on the original request, RPC service 440 identifies an existing RPC adapter 436 if the target service has been previously accessed, or assigns an unassigned RPC adapter to become RPC adapter 436 if no other device is currently accessing the target service. RPC service 440 then sends the request to the identified or assigned RPC adapter 436. In operation 516, RPC adapter 436 binds to the target service and creates a new service context for the target service, as well as a pseudo-token 438. As used herein, a service context provides information about a service (including a service ID, service type, and any other relevant information) to identify, connect to, and access the service. Furthermore, a service context includes information about the device associated with the service. RPC adapter 436 associates the service context with pseudo-token 438. Operation 516 returns the service context to RPC service 440. In operation 518 , the communication service gateway 434 associates the service context with the RPC adapter 436 , and the RPC service 440 sends a response (with the service context) to the client device 402 .

[0058] In operation 520, the client device 402 receives the response and sends the response to the RPC adapter 412. The RPC adapter 412 associates the service context with the dummy handler 414. In operation 522, the communication service gateway 410 generates an IPC token 408 associated with the dummy handler 414 and returns the IPC token 408 to the client application 406. Once the channel is established, the client application 406 can use the IPC token to access the service, as described below with reference to Figure 5B As stated.

[0059] A service context (SC) includes information identifying the location of a service. In one example, the SC includes the address of a server device providing the service and information identifying the service on the server device. Exemplary embodiments map SCs between client devices and service devices to establish a connection to the service. Table 1 describes an exemplary SC mapping.

[0060] Table 1

[0061]

[0062] When establishing inter-device IPC, the mapping operations shown in Table 1 are performed (for example, operation 516 performs mapping 2, Figure 5A Operation 518 performs mapping 1, and operation 520 performs mapping 3). When transferring IPC tokens between devices, mapping operations may also be performed, as described below with reference to Figure 9 and Figure 10 As stated.

[0063] Figure 5B FIG. 4 is a flowchart provided by an exemplary embodiment, which shows that an application on a client device calls a remote service through an established inter-device IPC link. Figure 5B The operations shown can be performed using Figure 4 In this embodiment, the service has been bound to the client, so Figure 5B The flowchart shown in does not refer to Figure 4 420, service manager 422, or remote service manager 424 shown in FIG. In operation 532, client application 406 invokes an intra-device IPC call and encapsulates the call's input parameters in a data package. Using the conventional IPC framework in the OS kernel, operation 534 identifies dummy handler 414 as associated with the service context and sends the data package to dummy handler 414 identified in communication service gateway 410 via IPC token 408. Operation 534 also generates a request for RPC service 416 to access server device 430 and sends the request and package to RPC service 416. In operation 536, RPC service 416 identifies server device 430 from the service context associated with dummy handler 414 and sends the request, package, and service context as an inter-device call to RPC service 440 of server device 430 and communication service gateway 434 using channel 240. In this case, the request and service context are sent via command channel 240C, and the associated data is sent via command channel 240C or data channel 240D, depending on its content.

[0064] In operation 538, RPC service 440 of server device 430 receives the request and processes it to retrieve the service context. Operation 538 uses the service context to identify RPC adapter 436 to handle the inter-device IPC call. Operation 538 then sends the package to RPC adapter 436 of communication service gateway 434. In operation 540, RPC adapter 436 in communication service gateway 434 decapsulates the request and identifies pseudo-token 438 from the service context. Operation 540 then uses the traditional IPC framework on server device 430 to call the target service. The IPC framework uses the pseudo-token 438 associated with the request and package to route the call to the target service. In operation 542, server application 432 receives the request and package, processes the request, and, using the IPC framework, returns the result to RPC adapter 436 of communication service gateway 434 as a reply to the inter-device IPC call. Processing the reply may include generating a reply package containing data to be returned to client application 406. In operation 544, communication service gateway 434 and RPC service 440 send the reply with the reply package to communication service gateway 410 on client device 402 via channel 240 and RPC service 416. In operation 546, communication service gateway 410 sends the reply package to RPC adapter 412. In operation 548, RPC adapter 412 uses the IPC framework in the kernel of client device 402 to send the reply package to client application 406 as a response to the intra-device IPC call in accordance with traditional IPC operations.

[0065] Figure 6 FIG. 6 shows a system 600 provided by an exemplary embodiment in which multiple client applications bind common services using an inter-device IPC mechanism. Figure 6In the illustrated example, three client applications 604, 608, and 624 on two client devices 602 and 622 bind to a service provided by a server application 644. Client application 604 binds to the service via IPC token 606, and client application 608 binds to the service via IPC token 610. IPC tokens 606 and 610 are both linked to a pseudo-handler 616 of an RPC adapter 614 for the service in a communications services gateway 612. Similarly, client application 624 on client device 622 binds to the service via IPC token 626, which is linked to a pseudo-handler 632 of an RPC adapter 630 in a communications services gateway 628 on client device 622. RPC adapter 614 sends requests received from client applications 604 and 608 to RPC service 618 for transmission via channel 240 to server device 642, while RPC adapter 630 sends requests received from client application 624 via RPC service 634 via channel 240 to server device 642. Both RPC service 618 and RPC service 634 communicate with RPC service 654 of communication service gateway 648. RPC service 654, in turn, sends service requests from client applications 604, 608, and 624 to RPC adapter 650. RPC adapter 650 includes a pseudo-token 652 that binds the service on server device 642 via IPC handler 646 of server application 644. Thus, a single communication service gateway 648 on server device 642 can link to multiple communication service gateways 612 and 628 on client devices 602 and 622, respectively.

[0066] Exemplary embodiments may be, but are not limited to, for a device to share and process files on another device, for a device to prompt a security credential challenge on another device, or for a device to present user interface (UI) elements (e.g., a keyboard) and receive input on another device for remote interaction. Each of these embodiments transfers different types of data between a client application and a server application.

[0067] Figure 7 、 Figure 8 、 Figure 9 and Figure 10The present invention describes how different types of data can be processed and shared between client and server applications using channel 240 according to an exemplary embodiment. The described embodiment handles three types of data transfers: first, when simple data is sent directly over command channel 240C; second, when a data reference (e.g., an access reference or file descriptor) is sent over command channel 240C and the data content is sent over data channel 240D; and third, when a remote access reference is sent over command channel 240C.

[0068] As mentioned above Figure 5B As described, the client device encapsulates the input parameters of the IPC procedure call into a package. When the server returns its result, the result is also a package that can include parameters or objects. The system processes the object before transmitting the package to the remote device. The operation of encapsulating data into a package is called marshaling the data into the package. Marshaling is the process of converting the memory representation of an object into a data format suitable for storage or transmission. Marshaling is often used when data must be moved between different parts of a computer program or from one program to another in a single device. As mentioned below Figures 7 to 10 As mentioned above, object marshaling for inter-device IPC differs from traditional marshaling. In a device-independent IPC context, there can be two types of objects. One type of object is an IPC token object. When the sending device processes the IPC token object, it converts the IPC token object into a service context and sends the service context to the receiving device. The IPC token object is valid only within the sending device. The other type of object is a data reference (for example, a file descriptor (FD)). In the Android context, an FD encapsulated in a package can be created for a real file, anonymous shared memory (ASHMEM), ION memory, or a socket. An FD is valid only within a process. Within a device, when an FD moves across process boundaries (for example, to another container), the OS kernel allocates a new FD for the receiving process. When an FD is sent from one device to another, it must be properly processed and translated to ensure that the data remains accessible on the receiving device through the FD reference and that the actual data content (for example, file contents, memory, or socket) is operable (for example, via local or remote access).

[0069] Figure 72 is a functional block diagram of a system 700, which includes a communication channel 240 used by a client application 702 (APP A) on a client device 701 to bind to a service in a server application 712 (APP B) on a server device 711. The client application 702 is linked to an RPC adapter 706 in a communication service gateway 704. As described above, the RPC adapter 706 of the communication service gateway 704 communicates with the RPC adapter 710 of the communication service gateway 708. The server application 712 accesses the RPC adapter 710. The RPC adapters 706 and 710 communicate via the corresponding RPC services ( Figure 7 (not shown) coupled to the command channel 240C and the data channel 240D of the channel 240. The exemplary RPC adapter 706 implements the outbound packet processing method 900, and the exemplary RPC adapter 710 implements the inbound packet processing method 1000. These methods respectively control the generation of outbound data packets on the sending device to produce processed outbound packets, and the processing of inbound data packets on the receiving device through the inter-device IPC mechanism to produce processed inbound packets. Figure 9 and Figure 10 Describe methods 900 and 1000. It should be noted that, Figure 7 Shown is sending a package from the client application 702 and receiving a package on the server application 712. A similar process applies when sending a package from the server application 712 and receiving a package on the client application 702.

[0070] Figure 7The processing of three different data types is illustrated. For simple data, the data content is marshaled into a parcel and sent over command channel 240C. For data suitable for replica access based on the data's policy and attributes (e.g., size, type, access latency sensitivity, etc.), a local data object 718 is processed by RPC adapter 706 and sent over data channel 240D, while a data reference is marshaled into a parcel and sent over command channel 240C. When server device 711 receives the parcel, RPC adapter 710 creates a corresponding remote data object 720 and updates the corresponding data reference to reflect the remote data object 720. An example of a data object suitable for replica access is a small file. The small file is sent to server device 711, which creates a corresponding FD to allow server application 712 to access the data in the small file. For data not suitable for replica access based on the above criteria, RPC adapter 706 creates a local data object stub 722 to represent the data and sends the relevant context parameters over data channel 240D. RPC adapter 706 marshals the local stub reference into the parcel and sends the parcel over command channel 240C. When server device 711 receives the package and context parameters, RPC adapter 710 creates a corresponding remote data object proxy 724 and updates the corresponding stub reference (not shown) to reflect the remote data object proxy 724. Remote data object proxy 724 and local data object stub 722 are RPC-enabled components that communicate with each other using a simple socket connection (or other defined communication service, such as gRPC) to enable cross-device data access. An example of a data object that is not suitable for replica access is a database on client device 701. Instead of sending the database from client device 701 to server device 711, system 700 establishes a local data object stub 722 on client device 701 and a remote data object proxy 724 on server device 711 to enable remote access to the database.

[0071] Because existing IPC tools are designed to run on a single device, objects transferred between devices are handled differently than they currently marshal data before sending the package to the remote device. Figure 8An exemplary embodiment provides an RPC object package 800 that allows objects to be transferred across device boundaries. The RPC object package includes an RPC object header 802 and a marshaling package 814. The RPC object header 802 includes a flag field 804 that identifies the package as an RPC object package and a number of objects field 806 that includes the number of marshaled objects in the marshaling package 814. The number of objects field is followed by one or more object pointer fields 808, 810, and 812. Each of these fields points to a corresponding marshaled object stored at a corresponding location in the marshaling package 814. As described above, the marshaling object can be a set of data values, an FD, or an IPC object token. The RPC object package is transmitted via the command channel 240C.

[0072] Figure 9 Flowchart of an exemplary outbound package processing method 900. The outbound package processing method 900 is paired with the inbound package processing method 1000, which is referred to below. Figure 10 Description. Although Figure 7 An outbound package processing method 900 implemented in the client device 701 and an inbound package processing method 1000 implemented in the server device 711 are shown, but both the client device 701 and the server device 711 can implement both methods 900 and 1000. Intra-device IPC calls can be synchronous or asynchronous. In a synchronous call, the client waits for the IPC call until a response is received from the server. In an asynchronous call, the client sends an IPC token to the server and returns immediately from the IPC call without waiting for a response. The server processes the request and then uses the IPC token to call back the client in response. The outbound package processing method 900 and the inbound package processing method 1000 convert the IPC token object into a service context to create a mapping between the server device 711 and the client device 701, thereby enabling a cross-device IPC callback mechanism.

[0073] As mentioned above Figure 7 As described, method 900 is performed by RPC adapter 706 of communication service gateway 704. Method 900 is called for each object to be placed in RPC object package 800. In operation 902, RPC adapter 706 accesses the objects of the IPC package sent from client application 702 on client device 701 to be included in RPC object package 800, such as Figure 8As shown. In operation 904, the RPC adapter 706 of the communication service gateway 704 determines whether the object to be sent is a data object. If the object is not a data object, the RPC adapter 706 determines in operation 906 whether the object is an IPC token. When the object is neither a data object nor an IPC token, the method ends in operation 908, and the object is not processed by the outbound package processing method 900. When the RPC adapter 706 identifies the object as an IPC token in operation 906, the RPC adapter 706 creates a new service context for the object in operation 910, and in operation 912, replaces the IPC token with the service context and marshals the service context into the RPC object package 800. In operation 914, the RPC adapter 706 then associates the service context with the current RPC adapter and IPC token, and the method ends in operation 908.

[0074] If, at operation 904, RPC adapter 706 determines that the object is a data object, method 900 proceeds to operation 916. In operation 916, RPC adapter 706 determines whether the object is suitable for replica access, i.e., whether the object is suitable for replicating the data object to another device based on policy and data attributes (e.g., size, type, access latency sensitivity, etc.). If so, method 900 proceeds to operation 922; otherwise, method 900 proceeds to operation 918. If replica access is not suitable, RPC adapter 706 creates a local data object stub to access the data in operation 918, and marshals the local data object stub reference into RPC object wrapper 800 in operation 920 for transmission to another device.

[0075] When replica access is appropriate, RPC adapter 706 determines in operation 922 whether the data can be sent directly over the command channel (e.g., the data can be included as a data set in RPC object wrapper 800) or whether the data is to be accessed by reference (e.g., by accessing a reference or FD). When the data is to be accessed by reference, the data is sent over the data channel (operation 924), and in operation 920, RPC adapter 706 marshals the reference to the data into RPC object wrapper 800. Similarly, when the data is to be sent directly over the command channel, the data object is self-contained, so in operation 920, the data set is marshaled into RPC object wrapper 800. After marshaling the reference or data set, in operation 920, the method ends in operation 908.

[0076] Figure 10 Flowchart of an inbound package processing method 1000 provided for an exemplary embodiment. The method 1000 may be implemented by the RPC adapter 710 of the communication service gateway 708, such as Figure 7 The inbound package processing method is performed by the RPC adapter 710 for the inbound package (for example, Figure 8 Method 1000 describes the processing of a single object. This method may be executed several times, as indicated by the number of objects field 808 of the RPC object package 800, as shown in FIG. Figure 8 As shown. Operation 1002 accesses the inbound RPC object package 800 and extracts the object. The RPC adapter 710 determines whether the object is a data object in operation 1004. When the object is not a data object, the RPC adapter 710 determines whether the object is a service context of the service in operation 1006. When the object is neither a data object nor a service context, the object is not processed and the method 1000 ends, as shown in operation 1008. When the RPC adapter 710 determines in operation 1006 that the extracted object is a service context, the RPC adapter 710 creates a new pseudo handler for the object based on the extracted service context in operation 1010 and associates the service context with the pseudo handler. In operation 1012, the RPC adapter 710 replaces the service context in the RPC object package 800 with the pseudo handler.

[0077] If, in operation 1004, RPC adapter 710 determines that the object is a data object, RPC adapter 710 determines, in operation 1014, whether the object is suitable for replica access. If the object is not suitable for replica access, RPC adapter 710 creates a remote data object proxy based on the received context parameters in operation 1016, and updates the reference in RPC object package 800 with the remote data object proxy in operation 1018. After operation 1018, method 1000 ends. If, in operation 1014, RPC adapter 710 determines that the object is suitable for replica access, RPC adapter 710 determines, in operation 1020, whether the data is to be accessed directly or by reference. If the data is to be accessed directly, the data object is self-contained in RPC object package 800, and RPC adapter 710 sends the data in RPC object package 800 to the target application in operation 1022. Method 1000 ends in operation 1008. When RPC adapter 710 determines in operation 1020 that the data will be accessed via a reference, RPC adapter 710 receives the data content via a data channel in operation 1024. For example, RPC adapter 710 receives the data content from data channel 240D and stores the data locally. In operation 1026, RPC adapter 710 creates a local reference for the received data content and, in operation 1028, updates the reference in RPC object package 800 with the newly created reference. After updating the reference, method 1000 ends in operation 1008.

[0078] Figure 11is a flow chart illustrating an exemplary method 1100 for reclaiming an inter-device IPC structure when a corresponding IPC service is terminated. Figure 11 This function can be called when a server leaves a cluster group or terminates a service, so that the inter-device IPC structure (e.g., communication service gateway) that supports access to the service can be recycled so that other inter-device IPC services can use it. Figure 6 In operation 1102, the RPC adapter 650 on the server device 642 receives a notification of service termination. In operation 1104, the RPC service 654 coupled to the RPC adapter 650 then terminates the RPC adapter 650 to reclaim system resources. The RPC service 654 then broadcasts the termination notification to the connected client devices 602 and 622 in operation 1106. After broadcasting the termination notification, the RPC service 654 clears the RPC adapter 650 of the dummy token 652 and returns the RPC adapter 650 to the unassigned RPC adapter pool.

[0079] Each client device's RPC service, such as RPC service 618 of client device 602, receives the termination notification in operation 1108. Client device 602 then identifies the RPC adapter 614 corresponding to the terminated service and terminates adapter 614 in operation 1110 to reclaim system resources on the client device (e.g., returning RPC adapter 614 to a pool of unallocated RPC adapters). Terminating the RPC adapter includes notifying client applications 604 and 608 of the termination. Client applications 604 and 608 handle the termination by deleting corresponding IPC tokens 606 and 610 in operation 1112.

[0080] Figure 12 1 is a block diagram of a computing device 1200 provided in an embodiment. Similar components can be used in the exemplary computing devices described herein. For example, the client, server, and network resources can be used respectively. Figure 12 The components shown in and / or Figure 12 A computing device similar to computing device 1200 may be used to implement Figure 2-Figure 4 、 Figure 6 and Figure 7 Client and / or server devices as shown.

[0081] An exemplary computing device 1200 may include a processing unit 1202 (eg, one or more processors and / or CPUs), memory 1203, removable storage 1210, and non-removable storage 1212 communicatively coupled by a bus 1201. Although various data storage elements are shown as part of computing device 1200.

[0082] Memory 1203 may include volatile memory 1214 and / or non-volatile memory 1208. Computing device 1200 may include or have access to a computing environment that includes various computer-readable media, such as volatile memory 1214, non-volatile memory 1208, removable memory 1210, and / or non-removable memory 1212. Computer memory includes random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disk (DVD) or other optical disk storage devices, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium capable of storing computer-readable instructions. The memory 1203 also includes program instructions for the OS kernel 1220 and the application 1218 , which implement any of the above methods and / or algorithms alone or in conjunction with other devices.

[0083] The computing device 1200 may include or have access to a computing environment that includes an input interface 1206, an output interface 1204, and a communication interface 1216. The output interface 1204 may provide an interface to a display device such as a touch screen, which may also be used as an input device. The input interface 1206 may provide an interface to one or more of a touch screen, a touchpad, a mouse, a keyboard, a camera, one or more device-specific buttons, one or more sensors integrated within the server computing device 1200 or coupled to the server computing device 1200 via a wired or wireless data connection, and / or other input devices. The input interface 1206 and the output interface 1204 may provide input and output interfaces to other types of devices, such as, but not limited to, video streaming devices, Internet of Things (IoT) devices, wearable devices, or augmented reality (AR) devices. The computing device 1200 may operate in a network environment using the communication interface 1216. The communication interface may include one or more interfaces to a local area network (LAN), a wide area network (WAN), a cellular network, a WLAN network, and / or a Bluetooth® network. The computing device 1200 uses the communication interface to establish communication channels 240 with one or more other computing devices, including a command channel 240C and a data channel 240D.

[0084] In one exemplary embodiment, a computing device 1200 includes: a request module that obtains a first request to bind a first object from an application running on a first device; an object determination module that determines that the first object is a remote object on a second device; a message generation module that generates a message including the first request; a message transmission module that provides the message to the second device via a communication service gateway on the first device; a service context module that obtains a first service context for the first object from the second device in response to the first request to bind the first object; a pseudo-handler module that creates a first pseudo-handler; an association module that associates the first service context with the first pseudo-handler in the communication service gateway; and a token module that provides a first IPC token corresponding to the first pseudo-handler to the application on the first device. In some embodiments, the computing device 1200 may include other or additional modules for performing any or any combination of the steps described in the embodiments. Furthermore, any additional or alternative embodiments or aspects of the method as shown in any of the figures or recited in any of the claims are also contemplated to include similar modules.

[0085] Any one or more of the modules described herein (e.g., programs, methods, and / or processors) may be implemented using hardware (e.g., a processor of a machine, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or any suitable combination thereof). Furthermore, any two or more of these modules may be combined into a single module, and the functionality of a single module described herein may be subdivided among multiple modules. Furthermore, according to various exemplary embodiments, modules described herein as being implemented within a single machine, database, or device may be distributed across multiple machines, databases, or devices. As described herein, a module may include hardware and / or software designed to perform one or more functions (e.g., one or more functions described herein related to providing secure and accountable data access).

[0086] Although several embodiments have been described in detail above, other modifications are possible. Figure 5A 、 Figure 5B 、 Figure 9 and Figure 10 The flowcharts described herein do not require the particular order shown or sequential order to achieve the desired results. Additional steps may be provided or steps may be removed from the described flows, and additional components may be added to or removed from the described systems. Other embodiments may be within the scope of the following claims.

[0087] It should also be understood that software comprising one or more computer-executable instructions that facilitate the processing and operations described above in connection with any or all of the steps of the present invention can be installed in and provided with one or more computing devices consistent with the present invention. Alternatively, the software can be obtained and loaded into one or more computing devices, including obtaining the software via physical media or a distribution system, including, for example, obtaining the software from a server owned by the software creator or from a server not owned by the software creator but used by the software creator. For example, the software can be stored on a server for distribution via the Internet.

[0088] In addition, it will be understood by those skilled in the art that the present invention is not limited in its application to the construction and arrangement details of the components set forth in the specification or illustrated in the drawings. The embodiments herein are applicable to other embodiments and can be practiced or executed in various ways. In addition, it should be understood that the wording and terminology used herein are for descriptive purposes and should not be considered restrictive. The use of "including", "comprising" or "having" and their variations in this article is intended to cover the items listed thereafter and their equivalents as well as other items. Unless otherwise limited, the terms "connect", "couple" and "install" and their variations are widely used in this article and cover direct and indirect connections, couplings and installations. In addition, the terms "connect" and "couple" and their variations are not limited to physical or mechanical connections or couplings.

[0089] The components of the illustrative devices, systems, and methods used in accordance with the described embodiments may be implemented at least partially in digital electronic circuitry or in computer hardware, firmware, software, or a combination thereof. For example, the components may be implemented as a computer program product (e.g., a computer program, program code, or computer instructions) tangibly embodied in an information carrier or in a machine-readable storage device for execution by, or to control the operation of, a data processing apparatus (e.g., a programmable processor, a computer, or multiple computers).

[0090] A computer program can be written in any form of programming language (including compiled or interpreted languages) and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, method, object, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed in one computer or in multiple computers at one site, or it can be distributed at multiple sites and interconnected by a communication network. The method operations associated with the illustrative embodiments can be performed by one or more programmable processors, thereby executing computer programs, codes, or instructions to perform functions (e.g., by operating on input data and / or generating output). For example, the method operations can also be performed by dedicated logic circuitry (e.g., a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)), and the apparatus for performing the method can be implemented as the dedicated logic circuitry.

[0091] The various illustrative logical blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed using a general-purpose processor, a digital signal processor (DSP), an ASIC, an FPGA, or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a single-core or multi-core microprocessor, and alternatively, the general-purpose processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in combination with a DSP core, or any other similar configuration.

[0092] For example, processors suitable for executing computer programs include general-purpose and special-purpose microprocessors, as well as any one or more processors of any type of digital computer. Typically, a processor will receive instructions and data from read-only memory or random access memory, or both. Elements of a computer include a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer also includes one or more mass storage devices (e.g., magnetic, magneto-optical, or optical disks) for storing data, or is operatively coupled to one or more mass storage devices for storing data to receive data from and / or transmit data to the mass storage devices. Information carriers suitable for embodying computer program instructions and data include various forms of non-volatile memory, including, for example, semiconductor memory devices such as electrically programmable read-only memory or electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory devices, and data storage disks (e.g., magnetic disks, internal hard disks, or removable magnetic, magneto-optical, CD-ROM, and DVD-ROM disks). The processor and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0093] Those skilled in the art will appreciate that information and signals may be represented using any of a variety of different technologies and techniques. For example, the data, instructions, commands, information, signals, bits, symbols, and chips referenced in the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or optical particles, or any combination thereof.

[0094] As used herein, a "machine-readable medium" or "computer-readable medium" refers to a device capable of temporarily or permanently storing instructions and data, and may include, but is not limited to, random-access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, other types of memory (e.g., erasable programmable read-only memory (EEPROM)), and / or any suitable combination thereof. The terms "machine-readable medium" or "computer-readable medium" should be understood to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that can store processor instructions. A machine-readable medium or computer-readable medium should also be understood to include any medium (or combination of multiple media) that can store instructions that are executable by one or more processors, which, when executed by the one or more processors, causes the one or more processors to perform any one or more of the methods described herein. Accordingly, a machine-readable medium or computer-readable medium refers to a single storage device or device, as well as a "cloud-based" storage system or storage network comprising multiple storage devices or devices. As used herein, the terms "machine-readable medium" and "computer-readable medium" do not include signals themselves.

[0095] In addition, without departing from the scope of the present invention, the techniques, systems, subsystems, and methods described and illustrated as discrete or separate in the various embodiments may be combined or integrated with other systems, modules, techniques, or methods. Other items shown or described as coupled to each other, or directly coupled to each other, or communicating with each other may be indirectly coupled or communicated with each other electrically, mechanically, or otherwise through some interface, device, or intermediate component. Other examples of variations, substitutions, and modifications may be determined by those skilled in the art and may be exemplified without departing from the scope of the present invention.

[0096] Although the present invention has been described with reference to the specific features and embodiments of the present invention, it is obvious that various modifications and combinations of the present invention can be formulated without departing from the present invention. For example, other components can be added to or removed from the described method, module, device and / or system. Therefore, the description and the drawings are only regarded as the description of the present invention limited by the appended claims, and are intended to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention. Other aspects may be within the scope of the appended claims.

Claims

1. A first device for implementing inter-process communication, characterized in that: include: memory, including program instructions; One or more processors, coupled to the memory, configured to execute the program instructions to perform operations including: Obtaining, from a second device through a communication service gateway of the first device, a first request to bind a first object on the first device; the communication service gateway comprising a plurality of RPC adapters, each RPC adapter comprising a plurality of pseudo-handlers and a plurality of pseudo-tokens, one RPC adapter corresponding to each service; assigning a first pseudo-token of the first object to the communication service gateway; The pseudo token is a placeholder for an IPC token used to access a service, so that an application running on the second device can access a service on the first device; the first pseudo token corresponds to a pseudo handler in the second device; the pseudo handler is used to act as a proxy on the first device to provide the first object to the application running on the second device; creating a first service context for the first object; associating the first service context with the first pseudo-token of the first object; providing, by the communication service gateway, the first service context to the second device as a response to the first request to bind the first object; Obtaining, from the application running on the first device, a second request for binding a second object; determining that the second object is a remote object on the second device; generating a message including the second request; providing the message to the second device through the communication service gateway on the first device; obtaining, from the second device, a second service context of the second object as a response to the second request to bind the second object; creating a first dummy handler for the second object; associating the second service context with the first dummy handler in the communication service gateway on the first device; An IPC token corresponding to the first dummy handler is provided to the application on the first device.

2. The first device according to claim 1, characterized in that The operations further include: Obtaining an inter-device inter-process communication (IPC) call and the first service context associated with the first object from the second device through the communication service gateway of the first device; identifying the first pseudo-token as being associated with the first service context; Obtain an inbound package including input parameters for the inter-device IPC call; Processing the inbound package to provide a processed inbound package for use by an IPC call within the device; Using the first pseudo-token, initiating the intra-device IPC call using the processed inbound package of the first object; Obtaining a response to an IPC call within the device, the response including an outbound package; Processing the outbound package to provide a processed outbound package for responding to the inter-device IPC call; The processed outbound package is provided to the second device using the response to the inter-device IPC call through the communication service gateway.

3. The first device according to claim 1, characterized in that The operations further include: Obtaining, from the application running on the first device, an intra-device IPC call to the second object on the second device; Invoking the first pseudo-handler in the communication service gateway; identifying the second service context associated with the first pseudo handler; Get outbound packages including input parameters for inter-device IPC calls; Processing the outbound package to provide a processed outbound package for use in the inter-device IPC call; providing, by the communication service gateway, the inter-device IPC call to the second device using the processed outbound package and the second service context; Obtaining a reply to the inter-device IPC call from the second device via the communication service gateway, the reply including an inbound package; processing the inbound package to provide a processed inbound package; The processed inbound packet is provided to the application as a reply to the IPC call within the device.

4. The first device according to any one of claims 1 to 3, characterized in that The operations further include: Obtaining, from a third device through the communication service gateway of the first device, a third request for binding a third object on the first device; assigning a second pseudo-token of the third object to the communication service gateway; creating a third service context for the third object; associating the third service context with the second pseudo-token of the third object; The third service context is provided to the third device by the communication service gateway as a response to the third request to bind the third object.

5. The first device according to any one of claims 1 to 3, characterized in that The operations further include: Obtaining, from a third device through the communication service gateway of the first device, a second request for binding the first object on the first device; The first service context is provided to the third device by the communication service gateway as a response to the second request to bind the first object.

6. The first device according to claim 4, characterized in that The third device includes the second device.

7. A first device for implementing inter-process communication, characterized in that: include: memory, including program instructions; One or more processors, coupled to the memory, configured to execute the program instructions to perform operations including: Obtaining a first request for binding a first object from an application running on the first device; determining that the first object is a remote object on a second device; generating a message including the first request; providing the message to the second device through a communication service gateway on the first device; The communication service gateway includes a plurality of RPC adapters, each RPC adapter includes a plurality of pseudo-handlers and a plurality of pseudo-tokens, and each service corresponds to an RPC adapter; obtaining, from the second device, a first service context of the first object as a response to the first request to bind the first object; Create the first pseudo-handler; The first pseudo handler corresponds to a first pseudo token in the first device; The pseudo-token is a placeholder for an IPC token used to access the service, so that an application running on the second device can access the service on the first device; The first pseudo-handler is used to act as a proxy on the first device to provide the first object to the application program in the second device; associating the first service context with the first dummy handler in the communication service gateway; providing a first IPC token corresponding to the first pseudo handler to the application on the first device; Obtaining a second request to bind a second object from the application; determining that the second object is a remote object on a third device; generating a message including the second request; providing the message to the third device through the communication service gateway on the first device; obtaining, from the third device, a second service context of the second object as a response to the second request to bind the second object; Create a second pseudo-handler; associating the second service context with the second dummy handler in the communication service gateway; A second IPC token corresponding to the second dummy handler is provided to the application on the first device.

8. The first device according to claim 7, characterized in that The operations further include: Obtaining, from the application running on the first device, an intra-device IPC call to the first object on the second device; Invoking the first pseudo-handler in the communication service gateway; identifying the first service context associated with the first pseudo handler on the first device; Get outbound packages including input parameters for inter-device IPC calls; Processing the outbound package to provide a processed outbound package for use in the inter-device IPC call; providing, by the communication service gateway, the inter-device IPC call to the second device using the processed outbound package and the first service context; Obtaining a response to the inter-device IPC call from the second device via the communication service gateway, the response including an inbound package; Processing the inbound packet to provide a processed inbound packet for use in replying to the IPC call within the device; The processed inbound packet and the reply to the intra-device IPC call are provided to the application.

9. The first device according to claim 7, characterized in that The third device includes the second device.

10. The first device according to any one of claims 7 to 9, characterized in that The operations further include: Obtaining, from a second application running on the first device, a second request for binding the first object; determining that the first object is a remote object on the second device; identifying the first pseudo handler for the first object; A second IPC token corresponding to the first dummy handler is provided to the second application on the first device.

11. The first device according to any one of claims 2, 3 or 8, characterized in that The operation of processing the outbound package includes: identifying a marshaled object in the outbound package; determining that the marshaled object references a local data object outside of the outbound package; creating a local data object stub for the marshaled object and a reference to the local data object stub; The reference to the local data object stub is marshaled into the processed outbound package as a replacement for the marshaled object.

12. The first device according to any one of claims 2, 3 or 8, characterized in that The operation of processing the outbound package includes: identifying a marshaled object in the outbound package; determining that the marshaled object is a data descriptor of a data value outside of the outbound package; creating a reference to said data descriptor; The reference to the data descriptor is marshaled into the processed outbound package as a replacement for the marshaled object.

13. The first device according to any one of claims 2, 3 or 8, characterized in that The operations of processing the inbound package include: identifying a marshaled object in the inbound package; determining that the marshaled object is a reference to a remote data object stub; creating a remote data object proxy linked to the remote data object stub to allow remote access to the remote data object referenced by the remote data object stub; The remote data object proxy is marshaled into the processed inbound package as a replacement for the marshaled object.

14. The first device according to any one of claims 2, 3 or 8, characterized in that The operations of processing the inbound package include: identifying a marshaled object in the inbound package; determining that the marshaled object is a reference to a data descriptor that references a data value outside of the outbound package; Obtaining the reference data value; locally storing the reference data value; creating a new data descriptor for the locally stored reference data value; Marshal the new data descriptor into the processed inbound package as a replacement for the marshaled object.

15. The first device according to any one of claims 2, 3 or 8, characterized in that The operation of processing the outbound package includes: identifying a marshaled object in the outbound package; determining that the marshaled object includes an IPC token object of another object local to the first device; Creating another service context for the IPC token object; marshaling the other service context into the processed outbound package as a replacement for the marshaled IPC token object; The other service context is associated with the IPC token object.

16. The first device according to claim 15, characterized in that The operations further include: Acquire another inter-device IPC call and the another service context of another object from the second device through the communication service gateway of the first device; identifying the IPC token object as being associated with the other service context; Obtain another inbound package including input parameters of the another inter-device IPC call; Processing the other inbound packet to provide another processed inbound packet for use in an IPC call within another device; Using the pseudo token of the other object, initiate the other intra-device IPC call using the processed other inbound package of the other object; Obtain another reply to the IPC call within the another device, the another reply including another outbound package; Processing the other outbound packet to provide another processed outbound packet for another response to the another inter-device IPC call; The processed another outbound package and another response to the another inter-device IPC call are provided to the second device through the communication service gateway.

17. The first device according to any one of claims 2, 3 or 8, characterized in that The operations of processing the inbound package include: identifying a marshaled object in the inbound package; determining that the marshaled object includes another service context for another object on the second device; creating a service dummy handler for said another service context; Marshaling the service pseudo-handler into the processed inbound package as a replacement for the marshaled another service context; The service dummy handler is associated with the other service context.

18. The first device according to claim 17, characterized in that The operations further include: Acquire from another device IPC call of the another object on the second device; calling the service pseudo-handler; identifying the other service context associated with the service pseudo handler on the first device; Get another outbound package including input parameters of another inter-device IPC call; processing the other outbound package to provide another processed outbound package; providing, by the communication service gateway, the another inter-device IPC call to the second device using the processed another outbound package and the another service context; Obtaining another inbound package from the second device via the communication service gateway as a response to the inter-device IPC call; processing the other inbound package to provide a processed another inbound package; Providing the processed another inbound packet as a reply to the IPC call within the another device.

19. A method performed by a first device for implementing inter-process communication, characterized in that: include: Obtaining a first request for binding a first object from an application running on the first device; determining that the first object is a remote object on a second device; generating a message including the first request; providing the message to the second device through a communication service gateway on the first device; The communication service gateway includes a plurality of RPC adapters, each RPC adapter includes a plurality of pseudo-handlers and a plurality of pseudo-tokens, and each service corresponds to an RPC adapter; obtaining, from the second device, a first service context of the first object as a response to the first request to bind the first object; Create the first pseudo-handler; The first pseudo handler corresponds to a first pseudo token in the first device; The pseudo-token is a placeholder for an IPC token used to access the service, so that an application running on the second device can access the service on the first device; The first pseudo-handler is used to act as a proxy on the first device to provide the first object to the application program in the second device; associating the first service context with the first dummy handler in the communication service gateway; providing a first IPC token corresponding to the first pseudo handler to the application on the first device; Obtaining, from a second application running on the first device, a second request for binding the first object; determining that the first object is a remote object on the second device; identifying the first pseudo handler for the first object; A second IPC token corresponding to the first dummy handler is provided to the second application on the first device.

20. The method according to claim 19, characterized in that Also includes: Obtaining, from the application running on the first device, an intra-device IPC call to the first object on the second device; Invoking the first pseudo-handler in the communication service gateway; identifying the first service context associated with the first pseudo handler on the first device; Get outbound packages including input parameters for inter-device IPC calls; Processing the outbound package to provide a processed outbound package for use in the inter-device IPC call; providing, by the communication service gateway, the inter-device IPC call to the second device using the processed outbound package and the first service context; Obtaining a response to the inter-device IPC call from the second device via the communication service gateway, the response including an inbound package; Processing the inbound packet to provide a processed inbound packet for use in replying to the IPC call within the device; The processed inbound packet and the reply to the intra-device IPC call are provided to the application.

21. The method according to claim 20, characterized in that Processing the outbound package includes: identifying a marshaled object in the outbound package; determining that the marshaled object references a local data object outside of the outbound package; creating a local data object stub for the marshaled object and a reference to the local data object stub; The reference to the local data object stub is marshaled into the processed outbound package as a replacement for the marshaled object.

22. The method according to claim 20, characterized in that Processing the outbound package includes: identifying a marshaled object in the outbound package; determining that the marshaled object is a data descriptor of a data value outside of the outbound package; creating a reference to said data descriptor; The reference to the data descriptor is marshaled into the processed outbound package as a replacement for the marshaled object.

23. The method according to claim 20, characterized in that Processing the inbound package includes: identifying a marshaled object in the inbound package; determining that the marshaled object is a reference to a remote data object stub; creating a remote data object proxy linked to the remote data object stub to allow remote access to the remote data object referenced by the remote data object stub; The remote data object proxy is marshaled into the processed inbound package as a replacement for the marshaled object.

24. The method according to claim 20, wherein Processing the inbound package includes: identifying a marshaled object in the inbound package; determining that the marshaled object is a reference to a data descriptor that references a data value outside of the outbound package; Obtaining the reference data value; locally storing the reference data value; creating a new data descriptor for the locally stored reference data value; Marshal the new data descriptor into the processed inbound package as a replacement for the marshaled object.

25. The method according to claim 20, wherein Processing the outbound package includes: identifying a marshaled object in the outbound package; determining that the marshaled object includes an IPC token object of another object local to the first device; Creating another service context for the IPC token object; marshaling the other service context into the processed outbound package as a replacement for the marshaled IPC token object; The other service context is associated with the IPC token object.

26. The method according to claim 25, characterized in that Also includes: Acquire another inter-device IPC call and the another service context of another object from the second device through the communication service gateway of the first device; identifying the IPC token object as being associated with the other service context; Obtain another inbound package including input parameters of the another inter-device IPC call; Processing the other inbound packet to provide another processed inbound packet for use in an IPC call within another device; Using the pseudo token of the other object, initiate the other intra-device IPC call using the processed other inbound package of the other object; Obtain another reply to the IPC call within the another device, the another reply including another outbound package; Processing the other outbound packet to provide another processed outbound packet for another response to the another inter-device IPC call; The processed another outbound package and another response to the another inter-device IPC call are provided to the second device through the communication service gateway.

27. The method according to claim 20, characterized in that Processing the inbound package includes: identifying a marshaled object in the inbound package; determining that the marshaled object includes another service context for another object on the second device; creating a service dummy handler for said another service context; Marshaling the service pseudo-handler into the processed inbound package as a replacement for the marshaled another service context; The service dummy handler is associated with the other service context.

28. The method according to claim 27, characterized in that Also includes: Acquire from another device IPC call of the another object on the second device; calling the service pseudo-handler; identifying the other service context associated with the service pseudo handler on the first device; Get another outbound package including input parameters of another inter-device IPC call; processing the other outbound package to provide another processed outbound package; providing, by the communication service gateway, the another inter-device IPC call to the second device using the processed another outbound package and the another service context; Obtaining another inbound package from the second device via the communication service gateway as a response to the inter-device IPC call; processing the other inbound package to provide a processed another inbound package; Providing the processed another inbound packet as a reply to the IPC call within the another device.

Images