WO2022012382A1

WO2022012382A1 - Method for enabling interaction between binder application and http application and related products

Info

Publication number: WO2022012382A1
Application number: PCT/CN2021/104803
Authority: WO
Inventors: Yiwei ZHAO; Xiaofeng Li
Original assignee: Guangdong Oppo Mobile Telecommunications Corp., Ltd.
Priority date: 2020-07-14
Filing date: 2021-07-06
Publication date: 2022-01-20

Abstract

A method for enabling interaction between a Binder application and a HTTP application and related products are provided. The method for enabling interaction between a Binder application and a HTTP application is applicable to a generic remote service gateway (GRSG), the GRSG includes a first component and a second component, and the method includes the following. A first connection between the GRSG and a client is established through the first component. A second connection between the GRSG and a service is established through the second component, so as to connect the client with the service through the first connection and the second connection. One of the client and the service is the Binder application and the other one is the HTTP application. As such, interaction between the Binder application with the HTTP application has been achieved.

Description

METHOD FOR ENABLING INTERACTION BETWEEN BINDER APPLICATION AND HTTP APPLICATION AND RELATED PRODUCTS

TECHNICAL FIELD

This disclosure relates to the field of communication technology, and more particularly to a method for enabling interaction between a Binder application and a hypertext transfer protocol (HTTP) application and related products.

BACKGROUND

Remote Procedure Call (RPC) is to enable a computer program to invoke a procedure (subroutine) to be executed on another computer. Since HTTP has been adopted as a fundamental protocol of web browsing, it is also widely accepted to construct RPC mechanism for web applications (i.e., HTTP applications) to enable web clients to invoke remote web service’s functions. Binder is a standard Inter-Process Communication (IPC) mechanism used in billions of Android devices.

Since client/server computing models are used by both Binder applications and HTTP applications, how to achieve interaction between a Binder application (i.e., an Android application) with a HTTP application has been a problem to be solved.

SUMMARY

Implementations provide a method for enabling interaction between a Binder application and a HTTP application and related products, which can achieve interaction between a Binder application and a HTTP application.

In a first aspect, a method for enabling interaction between a Binder application and a HTTP application is provided. The method for enabling interaction between a Binder application and a HTTP application is applicable to a generic remote service gateway (GRSG) , the GRSG includes a first component and a second component, and the method includes the following. A first connection between the GRSG and a client is established through the first component. A second connection between the GRSG and a service is established through the second component, so as to connect the client with the service through the first connection and the second connection. One of the client and the service is the Binder application and the other one is the HTTP application.

In a second aspect, a method for enabling interaction between a Binder application and a HTTP application is provided. The method is applicable to an electronic device with a Binder client, a generic remote service gateway (GRSG) , and a system server running thereon, the system server having an activity manager service (AMS) , a package manager service (PMS) , and a remote manager service (RMS) running thereon. The method includes the following. A request is sent through the Binder client to the AMS to set up a Binder connection with a web service, where the request contains an identity of the web service. The request is received through the AMS and the identity of the web service is sent, through the AMS, to the PMS, where the PMS is configured to manage all applications installed in the electronic device and store information of all registered service. Whether the web service is a local service is checked through the PMS. The RMS is controlled, through the PMS, to check whether the RMS has web service’s information in response to the web service being not the local service, where the RMS is configured to manage information of all remote services. GRSG information is returned, through the RMS, as the web service’s information and the GRSG information is returned, through the PMS, to the AMS. The request is passed, through the AMS, to the GRSG, where the GRSG includes a web component and a Binder component. A connection with the web service is established through the web component and a Binder stub is returned through the Binder component to the Binder client, so as to connect the Binder client with the web service.

In a third aspect, an electronic device is provided. The electronic device includes a processor, a memory configured to store one or more programs. The one or more programs are configured to be executed by the processor and the one or more programs include instructions for performing some or all operations of the method described in the first or second aspect.

In a fourth aspect, a non-transitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium is configured to store computer programs for electronic data interchange (EDI) . The computer programs include instructions for performing some or all operations of the method described in the first or second aspect.

In a fifth aspect, a computer program product is provided. The computer program product includes a non-transitory computer-readable storage medium that stores computer programs. The computer programs are operable with a computer to execute some or all operations of the method described in the first or second aspect.

In implementations of the present disclosure, a first connection between the GRSG and a client is established through the first component of the GRSG, a second connection between the GRSG and a service is established, so as to connect the client with the service through the first connection and the second connection. One of the client and the service is the Binder application and the other one is the HTTP application. As such, interaction between the Binder application with the HTTP application has been achieved.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe technical solutions of implementations more clearly, the following will give a brief description of accompanying drawings used for describing the implementations. Apparently, accompanying drawings described below are merely some implementations. Those of ordinary skill in the art can also obtain other accompanying drawings based on the accompanying drawings described below without creative efforts.

FIG. 1 is a diagram illustrating an Android Binder mechanism in the related art.

FIG. 2 is a diagram illustrating a process of defining a HTTP API and generating a skeleton implementation for a client and a server by taking a tool “OpenAPI Generator” as an example.

FIG. 3 is a diagram illustrating how to establish a Binder connection between two Binder applications on the android device in the related art.

FIG. 4 is a schematic flowchart of a method for enabling interaction between a connection between a Binder client and a web service.

FIG. 5 is a diagram illustrating how to connect a Binder client with a web service according to implementations.

FIG. 6 is a schematic flowchart illustrating establishing a connection between a Binder client and a web service according to implementations.

FIG. 7 is a schematic flowchart of a method for enabling interaction between a Binder application and a HTTP application according to implementations.

FIG. 8 is a schematic illustrating components in a GRSG according to implementations.

FIG. 9 is a schematic flowchart illustrating a process of a Binder client invoking web service’s procedures according to implementations.

FIG. 10 is a diagram illustrating a web service invoking callbacks according to implementations.

FIG. 11 is a diagram illustrating a case that a GRSG and a Binder client running on the same device according to implementations.

FIG. 12 is a diagram illustrating another case that a GRSG and a Binder client running on the same device according to implementations.

FIG. 13 is a diagram illustrating a case that a GRSG and a web service running on the same device.

FIG. 14 is a diagram illustrating another case that a GRSG and a web service running on the same device according to implementations.

FIG. 15 is a diagram illustrating how to connect a web client with a Binder service through a GRSG according to implementations.

FIG. 16 is a schematic flowchart illustrating a process of a web client invoking Binder service’ procedures according to implementations.

FIG. 17 is a schematic flowchart illustrating a process of a Binder service invoking callback functions according to implementations.

FIG. 18 is a diagram illustrating a case that a GRSG and a Binder service running on the same device according to implementations.

FIG. 19 is a diagram illustrating a case that a GRSG and a web client running on the same device according to implementations.

FIG. 20 is a diagram illustrating another case that a GRSG and a Binder service running on the same device according to implementations.

FIG. 21 is a diagram illustrating another case that a GRSG and a web client running on the same device according to implementations.

FIG. 22 is a diagram illustrating establishing a bi-directional HTTP connection between TLs according to implementations.

FIG. 23 is a schematic flowchart illustrating interactions between how TLs and GRSGs according to implementations.

FIG. 24 is a schematic flowchart illustrating a normal process of establishing connection between two devices’ TLs according to implementations.

FIG. 25 a diagram illustrating a web client browsing a Binder service’s API according to implementations.

FIG. 26 a schematic flowchart illustrating a process of a web client invoking Binder API according to implementations.

FIG. 27 is a schematic structural diagram of an electronic device according to implementations.

DETAILED DESCRIPTION

In order for those skilled in the art to better understand technical solutions of implementations, technical solutions of implementations will be described clearly and completely with reference to accompanying drawings in the implementations. Apparently, implementations hereinafter described are merely some implementations, rather than all implementations, of the disclosure. All other implementations obtained by those of ordinary skill in the art based on the implementations herein without creative efforts shall fall within the protection scope of the disclosure.

The terms “first” , “second” , “third” , and the like used in the specification, the claims, and the accompany drawings of the disclosure are used to distinguish different objects rather than describe a particular order. The terms “include” , “include” , and “have” as well as variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus including a series of steps or units is not limited to the listed steps or units. Instead, it can optionally include other steps or units that are not listed; alternatively, other steps or units inherent to the process, method, product, or apparatus can also be included.

The term “implementation” referred to herein means that a particular feature, structure, or character described in conjunction with the implementation may be contained in at least one implementation of the disclosure. The phrase appearing in various places in the specification does not necessarily refer to the same implementation, nor does it refer to an independent or alternative implementation that is mutually exclusive with other implementations. It is explicitly and implicitly understood by those skilled in the art that an implementation described herein may be combined with other implementations.

An electronic device referred to herein may include various handheld devices, in-vehicle devices, wearable devices, computing devices that have wireless communication functions or other processing devices connected to a wireless modem, as well as various forms of user equipment (UE) , mobile stations (MS) , mobile terminals, and the like. For ease of description, the above-mentioned devices are collectively referred to as an electronic device.

For ease of better understanding of implementations of the present disclosure, related technology involved in the present disclosure will be briefly introduced below.

Hereinafter, detailed description of implementations of the present disclosure will be given below.

In the present disclosure, the term “server” means an application or a process which can host one or more “services” . But in most cases, the “server” and “service” are interchangeable.

Remote Procedure Call (RPC) is to enable a computer program to invoke a procedure (subroutine) to execute on another computer. Since HTTP has been adopted as a fundamental protocol of web browsing, it is also widely accepted to construct RPC mechanism for web applications to enable web clients to invoke remote web service’s functions. Binder is a standard Inter-Process Communication (IPC) mechanism used in billions of Android devices. The inherent client/server computing models of both Binder and HTTP make it desirable if Android applications can interact with Web applications directly and transparently using their respective computing models. If this approach is possible, it opens the huge opportunity to reuse popular application inventory in both Android and web world. Unfortunately, so far there is no such a solution.

The present disclosure proposes a method for enabling interaction between a Binder application and a HTTP application and related products. That is, a Binder client can call a HTTP service (i.e., a web service) ; or a HTTP client (i.e., a web client) can browse a Binder service and invoke it. Furthermore, one Binder client can call another Binder service, which is running on another electronic device, by using HTTP as an underlying data transportation layer.

Because HTTP is mainly used in a HTTP application (i.e., web application) , in the present disclosure, “HTTP service” and “Web service” are interchangeable; similarly, “HTTP client” and “Web client” are interchangeable as well. When “HTTP API” is mentioned in the present disclosure, it normally means the APIs exported by a Web service which are implemented in the form of a HTTP method and a HTTP message.

Android Binder is originally to support an Android application to invoke other Android applications’ procedures, and all the applications run on the same device. FIG. 1 is a diagram illustrating an Android Binder mechanism in the related art, as illustrated in FIG. 1, the Android Binder mechanism can be formulated as following. A Binder IPC interfaces between an android client and an android server is defined by Android interface definition language (AIDL) and is saved in a . aidl file. Input parameters and a returned value of a Binder interface should be defined as Java (or C++ or any language that supports Binder protocol) classes which implement a Parcelable specification. Android SDK tools will generate an interface skeleton implementation for both a client side (which can be called a proxy) a server side (which can be called a stub) based on an interface . aidl file. An actual implementation logic for the server and client will be developed based on generated skeleton codes.

HTTP functions as a request-response protocol in the client/server computing model. A client (e.g. a web browser, or a Progressive Web Application, or a single page application, etc. ) makes a HTTP request to a server; after processing the request, the server returns a response. The response contains the processing status (e.g. success, error) and/or results (e.g. data in hyper text markup language (HTML) , JSON, extensible markup language (XML) , or other formats) .

When a server uses HTTP to expose its services (e.g. RESTful web services, or SOAP, etc. ) , a HTTP API will be specified, which defines format/content of the HTTP requests and responses, and HTTP methods to issue a requested message.

Hypermedia as the engine of application state (HATEOAS) links are also part of the HTTP API. HATEOAS is widely supported by RESTful service. It allows the HTTP client to use server-provided links dynamically discovering all available resources or state changes in a HTTP server application.

Furthermore, when an event happens on the server, a notification with parameters may need to feed to client. It is a callback mechanism which also need APIs to specify the events and notifications.

There are some tools to facilitate developers to define the HTTP API and generate a skeleton implementation for the client and the server. FIG. 2 is a diagram illustrating a process of defining the HTTP API and generating a skeleton implementation for the client and the server by taking a tool “OpenAPI Generator” as an example. As illustrated in FIG. 2, the tool “OpenAPI Generator” uses Swagger Codegen to generate the API client libraries, server stubs, documentation and configuration automatically given an API spec.

The industry has extended Binder to be distributed Binder. Distributed Binder extends Android Binder IPC to be RPC across Android devices. It enables huge amount legacy android applications (that only run within a device) to execute in a distributed environment with minimum or zero changes. And because Binder is a widely accepted IPC mechanism in Android world, it is much more attractive for android developers to continue using Binder while creating novel experience for distributed environment.

Meanwhile, HTTP has been widely adopted and there are lots of HTTP-based web services available in distributed environment. On an android device, in order to access those web services, the Android application can integrate with a HTTP library that implements HTTP protocol, establish a security connection, maintain session, construct a HTTP request, and parse a HTTP response, etc.

Within a distributed environment, and application can access any available service no matter if the service is provisioned in a protocol of Binder or a protocol of HTTP. For example, a media browser service, no matter whether it is a Binder service or a HTTP service, should be accessible to a media player application, no matter whether it is a HTTP client or a Binder client. But currently, a HTTP client can only access the HTTP service, and a Binder client can only access the Binder service, they cannot do cross-accessing.

At the same time, as mentioned above, an API exported by a Binder service is defined in an AIDL file, from which the skeleton code will be generated, and both the client and the server need to build with the generated code. When the server runs in the device, developers have a method to find out what services are available in the device, but there are no ways for them to figure out what specific APIs the services have implemented/exported. The ability to retrieve/browse the APIs definition of a Binder service dynamically at runtime is important for developers to debug Binder applications. The ability also enables dynamic language to interact with Binder services with great flexibility.

In the present disclosure, a method for enabling interaction between a Binder application and a HTTP application and related products are provided to implement the cross-accessing between Binder and HTTP protocols. A Binder client can invoke HTTP services; and a HTTP client can browse Binder service’s API and invoke its functions.

Moreover, to build distributed Binder in a distributed environment, the system has to implement a robust communication mechanism across computing devices, on top of which the Binder client can call its Binder service. HTTP has already a robust implementation for cross-computer communication, a technical solution of running a distributed Binder over HTTP is also provided in the present disclosure.

By means of the method for enabling interaction between a Binder application and a HTTP application and related products, Binder applications can access HTTP services, HTTP clients can access Binder services, a distributed Binder (i.e., a Binder client accessing Binder services) can work over a HTTP connection so as to increase robustness of cross-computer communication, a HTTP client can browse Binder APIs.

First, we will talk about a general method of invocation bridging transformation between a Binder API and a HTTP API. It focuses on a conversion between a Binder’s function call and a HTTP’s request/response message.

A Binder API is defined in AIDL and has the following typical format:

returnType functionName (Type1 p1, …, in TypeN pN, …out TypeM pM) .

It is almost as same as normal function declaration in C/C++/Java language, except that there is a directional tag in front of the non-primitive parameters. The directional tag indicates which way the data goes and can be either in, out, or in-out.

A HTTP API defines HTTP messages exchanged between the client and the server. A HTTP message normally consists of start line, headers, and body. There are two types of message -request and response. For request message, the start line includes HTTP method, path, query string and HTTP version; for response message, the start line has HTTP version, status code (to indicate success or failure) and status text. Body is optional payload in a message.

Headers have lots of standard or non-standards parameters. Because HTTP is essentially a protocol to fetch remote resource in a session-less way and there are many parameters designed to deal with network transportation and to deal with session (e.g. caching, proxy, etc. ) , not all of parameters are necessary for typical RPC API design, which usually assumes to be session-based.

When we discuss the transformation between HTTP APIs and Binder APIs, we will strip the parts in HTTP messages which are not necessary to construct an RPC.

Convert HTTP APIs to Binder APIs

Here are rules to transform a HTTP API to a Binder API:

1. functionName will be composed of request message’s path and HTTP method. The path separator symbol “/” in the path will be replaced with “_” ; and the HTTP method with prefix “_” will be appended to the path. The parameters embedded in path will be encoded in function parameters.

2. the function parameters will be generated from the following HTTP parameters:

2.1. the parameters embedded in path;

2.2. the parameters in the request message’s query string;

2.3. some of the parameters in headers (details below) ;

2.4. the data in HTTP message body;

If the data is primitive type, the same type is used in Binder parameter. If the data have file type, URI objects will be created which will refence to the files, If the data is neither primitive type nor a file, new Parcelable classes will be created for them. Non-primitive type data in request body will be “in” parameter; and will be “out” parameter in response body.

3. returnType will contains the status information in the HTTP response message. All the APIs have same non-primitive return type, here we use HttpStatus to represent, which is a Parcelable class.

For example, sample 1 and sample 2 illustrate an exemplary HTTP request and an exemplary response respectively.

Sample 1-an exemplary HTTP request:

GET /v1/1340/userinfo? role=admin HTTP/1.1

Host: example. com

Cookie: debug=0; csrftoken=BUSe35dohU3O1MZvDCUOJ

Sample 2-an exemplary HTTP response:

HTTP/1.1 200 OK

Date: Sun, 10 Oct 2010 23: 26: 07 GMT

Server: Apache/2.2.8 (Ubuntu) mod_ssl/2.2.8 OpenSSL/0.9.8g

Last-Modified: Sun, 26 Sep 2010 22: 04: 35 GMT

Accept-Ranges: bytes

Content-Length: 65

Connection: close

Content-Type: application/json

The exemplary HTTP request and exemplary HTTP response above can have a following Binder API as illustrated in sample 3:

Sample 3:

HttpStatus v1_userinfo_get (int userid, in string role, out UserInfo userinfo, out Date last_modified) ;

The path “/v1/1340/userinfo” and method “GET” are combined to compose the function name “v1_userinfo_get” . Because “1340” is a parameter embedded in path, it is not encoded in function name, but will be a parameter in the API.

The query string “role=admin” has one string parameter, will be put into Binder API as input parameter.

Most of headers ( “Cookie” in request message, “Server” , “Accept-Ranges” , “Content-Length” , “Connection” , “Content-Type” in response message) are parameters to facilitate the connection with remote server or meta data to describe the server or data information. They are essentially part of HTTP protocol, but not part of RPC. So, they are not listed in the parameter list in the API above. The “Last_Modified” header in response is the date of when the “userinfo” is modified last time. It is sometimes optional in RPC API design. If the web service treats it as the parameters for client to use, it can have corresponding Binder API parameters as shown in sample 3 which illustrates an exemplary Binder API) .

The HttpStatus class will be defined as follows in sample 4:

Sample 4:

class HttpStatus implement Parcelable {

int status_code;

Date date;

}

The UserInfo class will be defined as follows in sample 5:

Sample 5:

class UserInfo implement Parcelable {

string name;

string address;

}

After converting all a HTTP service’s APIs to Binder APIs following the rules above, they will be grouped into a Binder interface class, the class can be named following a HTTP service name.

Convert Binder APIs to HTTP APIs

The rules to transform a Binder API to a HTTP API are listed below:

1 Request message will be composed as follows:

1.1 HTTP method can be any of “GET” , “POST” or “PUT” .

1.2 The path will be formed as follows:

“/grsg/” + “package name” + “/” + “service class name” + “/” + “function name”

Where “grsp” is a reserved keyword, and “service class name” are also referred as “Interface class name” or “Binder class name” .

1.3 Primitive and enum parameters will be encoded into query string; other “in” parameters (like objects, array) will be embedded in request body. For “in” URI if it references to a local file of the client device, the file will be embedded into the request body.

2 Response message will be composed as follows:

2.1 HTTP status code will reflect whether the request has been sent to remote Binder service and whether has been processed and returned.

2.2 All the “out” or returned objects in Binder API will be encoded in message body. Especially for the “out” URI, if it is reference to local file of the server device, the file will be embedded in the message body.

As discussed above, most of the headers are not suitable for an RPC call. An application can decide which header parameters should be used in an RPC. In any case, if a header parameter is used in RPC call (like the “Last_Modified” in previous example) , the Binder APIs should have a corresponding parameter, and they will be converted to headers while composing HTTP message.

The header “Content-Type” in HTTP message is to indicate the media type of resource. When encoding the Binder API parameters to HTTP message, “Content-Type” can be set as follows. For primitive data types, enum or it array, “application/x-www-form-urlencoded” or “text/plain” can be used. For objects, “multipart/form-data” or “application/json” or “application/xml” can be used as the encoding format of the objects. For Files, specific media type can be indicated based on its content.

Here is an example. Sample 6 describes a Binder API, and the class UserInfo is defined as described in Sample 5.

Sample 6:

package com. example. android;

interface IRemoteService {

int getUserInfo (int id, out UserInfo user) ;

}

The HTTP request message will be like Sample 7. “GET” method is used. The package, service and function names are encoded into the path. And parameter “id” is primitive type and inserted in the query string. The “out” object parameter “Userinfo user” will be embedded in response message. The HTTP response message will be like the Sample 2.

Sample 7:

GET /gtsg/com. example. android/IRemoteService/getUserInfo? id=1234 HTTP/1.1

Host: example. com

Cookie: csrftoken=BUSe35dohU3O1MZvDCUOJ

We will first brief how a traditional Binder connection is established between two Binder applications on an android device.

FIG. 3 is a diagram illustrating how to establish a Binder connection between two Binder applications on the android device. As illustrated in FIG. 3, a process of establishing a traditional Binder connection between two Binder applications on the android device in the related art can be formulated as following.

If a Binder application wants to provide a service to other components, it has to register its service information to the system (See “Register” in FIG. 3) . Package Manager Service (PMS) in System Server manages all the installed applications on an android device and has all the registered service information. When a client requests to establish Binder connection with a server, the request will be sent to activity manager service (AMS) ; AMS will ask for the service information from PMS. When PMS returns the service information, AMS can find out the real server (and launch it if it is not already running) and passes the request to it. And then, the server will return its Binder stub object; and finally, AMS will pass the Binder information to the client through OS kernel driver (which is not shown in FIG. 3) , and the client will get a Binder proxy object that can be used to make RPC call. Binder stub is a Binder object and held by the server; Binder proxy is a derived Binder object and held by the client. There are connection relations, which are managed by OS kernel driver, between Binder proxy and stub. When multiple clients access a service, the clients’ Binder proxies are essentially connected to the service’ Binder stub. Both Binder stub’s and proxy’s code are generated from . aidl file. For the proxy, the generated code implements the interfaces which can marshal requests into a parcel object and send it to the corresponding stub; for the stub, the generated code will unmarshall the received parcel, and invokes the server’s actual function implementation to handle the request, and finally sends response back to the Binder client.

Based on traditional Binder connection established between two Binder applications on an android device, how to establish the connection between a Binder application and a web service is provided.

FIG. 4 is a schematic flowchart of a method for enabling interaction between a connection between a Binder client and a web service. The method is applicable to an electronic device with a Binder client, a generic remote service gateway (GRSG) , and a system server running thereon, the system server having an activity manager service (AMS) , a package manager service (PMS) , and a remote manager service (RMS) running thereon. As illustrated in FIG. 4, the method includes the following.

At block 402, A request is sent through the Binder client to the AMS to set up a Binder connection with a web service, where the request contains an identity of the web service.

At block 404, The request is received through the AMS and the identity of the web service is sent, through the AMS, to the PMS, where the PMS is configured to manage all applications installed in the electronic device and store information of all registered service.

At block 406, Whether the web service is a local service is checked through the PMS.

At block 408, The RMS is controlled, through the PMS, to check whether the RMS has web service’s information in response to the web service being not the local service, where the RMS is configured to manage information of all remote services.

At block 410, GRSG information is returned, through the RMS, as the web service’s information and the GRSG information is returned, through the PMS, to the AMS.

At block 412, The request is passed, through the AMS, to the GRSG, where the GRSG includes a web component and a Binder component.

At block 414, A connection with the web service is established through the web component and a Binder stub is returned through the Binder component to the Binder client, so as to connect the Binder client with the web service.

Specifically, in order to make a web service accessible to the Binder client, the web service should register in local system, and be treated as normal Binder service from a Binder application’s perspective. FIG. 5 is a diagram illustrating how to connect a Binder client with a web service. As is illustrated in FIG. 5, new components are introduced in the present disclosure: generic remote service gateway (GRSG) and remote manager service (RMS) . The GRSG is a Binder service, which has a Binder stub object serving Binder client’s requests. The GRSG also works as a proxy of the real web service and maintains real connection with the web service; and it will register the web service information in RMS. RMS will manage all the remote services’ information. The information includes: server address and port number of all the services and service full name (i.e. Package name + Service name) of all the services.

FIG. 6 is a schematic flowchart of establishing a connection between the Binder client and the web service. When a client application tries to establish a connection with (i.e., to bind) a web service, it, as with a Binder service, will query AMS for the service by inputting the web service’s full name as parameter in the query. AMS will check with PMS whether it is a local service; if it is not, PMS will ask RMS to check whether there is remote server registered for it; if so, RMS will return web service information to PMS, which in turn sends the information to AMS If the service is a remote one, the AMS will always use GRSG as the target server to make the request for the client.

When GRSG gets to know a client is reaching it for a new Binder connection, GRSG will establish connection with the real web service, and then returns its own Binder stub object to the client (through OS kernel) . Finally, the client application will get the corresponding Binder proxy of GRSG. If any of the steps fails, GRSG will send a connection exception to the client.

The step of “GRSG setup the connection with web service” is to establish HTTP session which is normally to maintain contextual information about the user. In GRSG, there is a web component (see FIG. 8) which will setup the connection and maintain session information as a web client.

FIG. 7 is a schematic flowchart of a method for enabling interaction between a Binder application and a HTTP application according to implementations. The method for enabling interaction between a Binder application and a HTTP application can be applicable to a generic remote service gateway (GRSG) , the GRSG including a first component and a second component. One of a client and a service is the Binder application and the other one is the HTTP application. As illustrated in FIG. 7, the method for enabling interaction between a Binder application and a HTTP application includes the following.

At block 702, a first connection between the GRSG and a client is established through the first component.

At block 704, A second connection between the GRSG and a service is established through the second component, so as to connect the client with the service through the first connection and the second connection.

As an implementation, where when the client is the Binder application and the service is the HTTP application, the client is a Binder client and the service is a web service, the first component is a Binder component which is configured to handle a Binder connection between the GRSG and the Binder client, and the second component is a web component which is configured to handle a HTTP connection between the GRSG and the web service.

In Android standard Binder implementation, there are three stages for a Binder client to access a Binder service: the first step is to establish Binder connection between client and server; after connection is established, the Binder client and the Binder service can interact between each other through Binder object; and finally, the connection will be disconnected to release system resource.

There are similar three stages for a Binder client access a Web service in the present disclosure. A method to establish connection between an android Binder application (as a client) with a web service will be described first; how to make a Binder call to a web service and handle the returned links from web service will be discussed then; and furthermore, how to enable an android application to subscribe web events will be discussed.

As an implementation, the first connection between the GRSG and the client is established through the first component as following. A request for establishing a connection between the Binder client and the web service is received through the Binder component. A first Binder stub is returned though the Binder component to the Binder client, where the first Binder stub is configured for the Binder client to get a first Binder proxy corresponding to the first Binder stub.

As an implementation, the method further includes the following. After the first connection and the second connection are established, a parcel is received through the Binder component from the Binder client and a Binder stub method is invoked through the Binder component, where the parcel is obtained at the Binder client by marshalling at least one first parameter of a Binder call, and the Binder stub method corresponds to a first application programming interface (API) of the web component. The parcel is unmarshalled through the Binder component to get the at least one first parameter. The first API of the web component corresponding to the Binder stub method is invoked through the web component. A first HTTP request is composed through the web component based on the at least one first parameter. The first HTTP request is sent through the web component to the web service, where the first HTTP request is configured to request the web service to process the Binder call initiated by the Binder client.

After establishing connection between the Binder application and the web service, the Binder application can invoke the web service’s procedures. In this section, how a Binder call initiated by a Binder application is transformed to a HTTP request and sent to web service will be described below.

First, components in GRSG which are involved in the process will be described in detail. FIG. 8 is a schematic illustrating components in a GRSG according to implementations. As illustrated in FIG. 8, the GRSG includes a web component and a Binder component. The web component will handle the connection with web service; the Binder component will manage the connection with Binder applications. The Binder component has both Binder stub and proxy. But this section will mainly involve Binder stub.

In actual deployment, client and service are usually in different devices, while GRSG can stay on any device. It can stay on the same device as the client, or on the same device as the service, or on a different device from either. If the Binder client and GRSG are not in the same device, a Binder call is made across device between the client and GRSG. This requires support of distributed Binder.

FIG. 9 is a schematic flowchart illustrating a process of a Binder client invoking web service’s procedures according to implementations. As illustrated in FIG. 9, The web component in GRSG is to compose output HTTP request messages and send them to web services; and parse input HTTP response message and send the result to Binder component. Web component will also need to manage cache, cookie etc.

Web component in GRSG will implement APIs for the Binder stub to access. We call them WC_API. A WC_API is the bridge function from Binder stub method to web service API. That is, a Binder stub method calls the corresponding WC_API, which in turn invokes the web service API by making http request and receiving response. In an actual implementation, GRSG can choose to inline the WC_API functions into the corresponding Binder stub methods, so that, a Binder stub method can invoke the web service API directly, without going through the WC_APIs.

If the actual implementation chooses to use WC_API, the WC_API will be implemented by the web component as a web client to the web service. WC_API function will compose the path and method in HTTP request’s start line; and the API’s parameter will be used to compose query string, headers, or message body. The function will serialize the parameters and place them in the message following the “media type” defined in HTTP APIs. As mentioned in previous sections, most of the headers will not be exported to Binder APIs, it is the web component who will construct the headers based on the HTTP APIs. For URI parameters, if they reference to local files, web component will embed them into message body following their media type.

When a response message is received, web component will parse that message, deserialize its content and construct objects, and return to it corresponding Binder stub method to handle them. For the files embedded in the message body, they will be saved locally; and URIs will be generated for them and return to Binder stub method.

The web component also needs to handle HTTP specific feature besides composing or parsing HTTP messages. For example, session state will be maintained by web component; local cache could be used to optimize the performance.

As an implementation, the method further includes the following. After the first HTTP request is sent, through the web component, to the web service, a first response to the first HTTP request is received through the web component from the web service. The first response is parsed through the web component and at least one object is constructed through the web component based on the first response. The at least one object is transferred through the web component to the Binder component. The at least one object is marshalled through the Binder component to a returned parcel and the returned parcel is sent through the Binder component to the Binder client, where the returned parcel is configured to be unmarshalled to get the at least one object by the Binder client.

As an implementation, the first response includes multiple links, and the method further includes the following. After the first response is received through the web component from the web service, the first response converted through the web component into at least one second parameter in a Binder API definition and the at least one second parameter in the Binder API definition is sent through the Binder component to the Binder client. A second response to the at least one second parameter in the Binder API definition is received through the Binder component from the Binder client. At least one API of the web component is invoked through the web component for at least one of a plurality of Binder APIs, where the plurality of Binder APIs are created at the Binder client and correspond to the plurality of links, the at least one of the plurality of Binder APIs are determined based on the second response of the Binder client. At least one HTTP request corresponding to the at least one API of the web component is composed through the web component. The at least one HTTP request is sent through the web component to the web service.

A web Service may return links to the web client for some requests. Here is an example:

Sample 8

HTTP Request:

Sample 9

In this example, when the web client requests the information of account 12345, web service returns the account data and the “links” which are the actions that the web client can take on this account.

Those links are HTTP APIs as well. A link has its HTTP method, parameters, and response when it is invoked. So, each of the link should be able to be converted to a Binder API following the method described above. For example, assuming POST method is defined to be used in those HTTP APIs, those links in the example has the following Binder APIs:

Sample 10

Interface AccountActions {

HttpStatus_accounts_deposit_post (int account_id, string currency, float value) ;

HttpStatus accounts_withdraw_post (int account_id, string currency, float value) ;

HttpStatus accounts_transfer_post (int account_id, string currency, float value) ;

HttpStatus accounts_close_post (int account_id, string currency, float value) ;

}

The parameter “int account_id” comes from the parameter in the links (Sample 9) ; and the other parameters “string currency, float value” are examples that clients may provide those information to server when they take the actions.

Those Binder APIs are defined in an interface class (e.g. AccountActions in Sample 10) . The APIs in the interface class should have the same signature because the consistency will make it easy for server to return suggested parameters (see later descriptions on Sample 11) . If the parameters are meaningless for some APIs, they can be ignored in the API’s implementation. For example, the parameters “string currency, float value” for “accounts_close_post () ” function are meaningless and will be unused in the implementation.

The web component will have WC_APIs for those Binder APIs and implement them by composing and sending corresponding HTTP requests to HTTP server. It has been discussed in previous section.

Those links, which are returned in response body (Sample 9) , should have corresponding parameter in Binder API definition, so that the Binder client can get to know which actions (i.e. links) are available and what parameters are suggested by a HTTP server. The parameter in the Binder API will include the following data:

1. A “IBinder” object, which will be a Binder proxy to access the interfaces (e.g. AccountActions in Sample 10) ; and the corresponding Binder stub is created by GRSG’s Binder component.

2. An object array, and the size of the array is the maximum amount the links that the response can return. Each object will have the following properties:

2.1 A flag to indicate whether the link is available when the function returns. If it is true, the index of the object in the array can be used to identify which link API is functional when the response comes.

2.2 An object which includes all the parameters returned from server. As mentioned in previous paragraph, all the APIs in this interface class have the same signature, so the same type of object can contain the parameters for each API.

So, the example HTTP messages (Sample 8, Sample 9) can have the following Binder API:

Sample 11

HttpStatus accounts_get (int account_id, out Balance balance, out AccountActionLinks link) ;

When the Binder API returns, the Binder client can invoke any of valid functions based on its business logic. For example, if user decides to withdraw money and the corresponding API “accounts_withdraw_post” is valid (which is indicated by the “valid” flag in corresponding LinkObject) , then Binder client can invoke this API with necessary parameters.

As an implementation, the method includes the following. After the first connection and the second connection are established. A second Binder stub is received through the Binder component from the Binder client. The second Binder stub is converted through the Binder component to a second Binder proxy. A first Binder class name is determined through the Binder component based on the second Binder proxy and a mapping relationship between Binder class names and Binder proxies, where a first Binder class is composed of at least one method, and each of the at least one method is configured to define an event subscribed by the Binder client. The first Binder class name is sent through the Binder component to the web component. At least one path is constructed through the web component for each of the at least one method in the first Binder class and the at least one path is registered through the web component as at least one endpoint of at least one local web service. A second HTTP request is generated through the web component based on the first Binder class name and the second HTTP request is sent through the web component to the web service to subscribe the at least one event.

A web client may subscript some events, which are managed or monitored by web services. The subscription normally will have the web client register some URLs to the server; when an event happens, THE web service will notify the web client by sending a HTTP request with URL (a.k.a. callback) . Here is an example:

Sample 12-Client Subscribes

POST /v1/service/subscribe

Host: my. example. com

Content-Type: application/json

{

“inProgressUrl” : “https: //myserver. com/inProgress/callback/here”

“failedUrl: ” : “https: //myserver. com/failed/callback/here”

}

Sample 13-Server Makes Callback for “inProgressUrl”

POST /inProgress/callback/here

Host: : myserver. com

Content-Type: application/json

{

“progress” : 80

}

Sample 14-Server Makes Callback for “failedUrl”

POST /failed/callback/here

Host: : myserver. com

Content-Type: application/json

{

“error” : “Something Wrong”

}

In the example above, the client first subscribes the two events “inProgressUrl” , and “failedUrl” . When “inProgressUrl” or “faieldUrl” event happens, it will POST a message with the registered URL as the path in start line.

How to handle the subscription can be divided into two steps: subscription and invoking callbacks. A process of the Binder client subscribing web events will be described first in detail.

Binder supports callback mechanism, which normally needs the client application to construct a Binder stub object which implements the callback interface and send the Binder stub object to the Binder service which will invoke the callback interface when needed.

Web events subscription is also a kind of HTTP API. We can leverage Binder callback mechanism to support web events callbacks. A Binder class should be defined for those web events callback APIs, and the Binder class should have a unique class name. And the APIs defined in the Binder class should follow the rules below:

Return an integer whose different values indicate different status mapped to HTTP response status.

The name of function is arbitrary.

The parameters of the function should be defined following rules discussed in “Convert HTTP APIs to Binder APIs” . The HTTP requests are sent by web services to the Binder client through GRSG, and its response are returned from the client.

For the example above (Sample 12, Sample 13, and Sample 14) , the Binder class can be defined in an . aidl file as follows:

Sample 15

Interface WebCallback {

Int inProgressCallback (int progress) ;

Int failedCallback (string error) ;

}

When supporting callbacks, the Binder client behaves like a Binder service that implements the callback interface, although it is not real Binder service, but a client that implements the interface in a Binder stub object. The subscription is initiated when the client sends the Binder stub object to GRSG, and then GRSG will handle the subscription.

When the Binder stub object is passed to the GRSG Binder component, it will be converted to a Binder proxy by OS kernel driver. Then Binder component will manage the Binder proxy and pass the name of the Binder class to Web component.

The Binder component will expose APIs for web component to access. We call those APIs as BC_APIs. A BC_API is the bridge function from a web component method to a Binder proxy API or a group of Binder proxies’ APIs. That is, web component calls the corresponding BC_API, which in turn invokes the Binder proxy API (or a group of proxies’ APIs) . In an actual implementation, GRSG can choose to inline the BC_API functions into the corresponding web component methods, so that, a web component method can invoke the Binder proxy APIs directly, without going through the BC_APIs.

The Binder component will also maintain the relationship among “Binder class name” and “Binder proxy” , for example, it has the table which have the following columns:

Bind Class Name

List of Binder Proxies

The table will maintain the list of the Binder proxies which has corresponding Binder clients subscribe the same events that are indicated by the “Binder class name” .

When a BC_API is invoked, it will use “Binder class name” to search for the list of the Binder proxies, and then invoke corresponding API for each of the proxy in the list.

Web component has the knowledge of the Binder class. To support the subscription of the web events, web component will construct unique path for each method in the Binder class. For example, it could be constructed as the following rule:

“/” + Binder class name +” /” + API function name

Web component will register those paths as endpoints of local web service; and the handler for each of the endpoint will defined as follows. Parse the request message to get Binder class name, function name and the input parameters. Invoke corresponding BC_API.

Then the web component will enable local web service to accept those requests (pointed by the paths) ; and finally, the web component will send a HTTP request to web service to subscribe the events.

As an implementation, the method includes the following. After the second HTTP request to the web service is sent through the web component to subscribe the at least one event, a third HTTP request is received through the web component from the web service and a second Binder class name is obtained through the web component by parsing the third HTTP request. A first API of the Binder component corresponding to the third HTTP request is invoked through the web component and the second Binder class name is sent through the web component to the Binder component. A third Binder proxy corresponding to the second Binder class name is determined through the Binder component. The third Binder proxy is processed through the Binder component by invoking a callback function of the Binder client. A third response is sent through the Binder component to the web component in response to the third Binder proxy having been completely processed and the third response is sent through the web component to the web service.

After the subscription above, web service can invoke the registered callbacks when events happen. FIG. 10 is a diagram illustrating a web service invoking callbacks.

As a web service, web component has handler for each exported endpoint. The handle will parse the request message to get the Binder class name, function name and input parameters; and then invoke corresponding BC_API. BC_API will find out corresponding list of the Binder proxies and invoke their method one by one. Furthermore, the method “onTransact () ” of the client’s Binder component (i.e. a Binder stub) will be invoked and it will invoke the real callback function eventually. After all registered Binder proxies have processed, a response will be returned to web service.

As an implementation, where the GRSG is configured to run in one of: a first electronic device in which the web service runs, a second electronic device in which the Binder client runs, or a third electronic device except the electronic device in which the web service runs and the electronic device in which the Binder client runs.

The technical solution described above do NOT assume where the GRSG will run. The GRSG can run in either client device or web service device or even a third device.

FIG. 11 is a diagram illustrating a case that a GRSG and a Binder client running on the same device. As discussed above about establishing connection, the GRSG is responsible to register web service information to a local device, maintain the HTTP connection with the remote Web services. It is possible to enable multiple clients to access the same web service. FIG. 12 is a diagram illustrating another case that a GRSG and a Binder client running on the same device. Binder client1 and Binder client 2 on device1 can share a single GRSG to access the web service on device2; and meanwhile, the Binder client 3 on device3 can access the same web service through the device3’s GRSG.

As an implementation, when the GRSG runs in the first electronic device, the second electronic device runs a GRSG counterpart which cooperates with the GRSG, and the GRSG counterpart is configured to register web service information to the second electronic device.

When GRSG run in the web service’s device, there will be another GRSG counterpart run on the client device. FIG. 13 is a diagram illustrating a case that a GRSG and a web service running on the same device. The GRSG counterpart in Binder client device has simplified functions and is mainly responsible to register the web service information to local device and maintain the “distributed Binder” connection with the remote GRSG. All the methods proposed in previous sections are still workable. Because “distributed Binder” will make sure that the connection between client’s Binder and remote GRSG’s Binder compatible with local Binder connection.

FIG. 14 is a diagram illustrating another case that a GRSG and a web service running on the same device. As can be seen from FIG. 14, multiple Binder clients can access the same web services if the GRGS runs in web service device.

When the GRSG is running in a separate device, it can connect with the Binder client over “distributed Binder” and connect with the web service with normal http. This configuration is a combination of configurations above.

As an implementation, when the client is the HTTP application and the client is the Binder application, the client is a web client and the service is a Binder service, the first component is a web component which is configured to handle a HTTP connection between the GRSG and the web client, and the second component is a Binder component which is configured to handle a Binder connection between the GRSG and the Binder service.

In descriptions about converting Binder APIs to HTTP APIs, how to convert existing Binder APIs to a form of HTTP APIs is provided. We will discuss how to let the web client use the HTTP APIs to access Binder services below. How to establish connection between web clients and Binder services, how to invoke Binder service’s procedures, how to handle callback functions will be mainly described in detail.

As an implementation, where the first connection between the GRSG and the client is established through the first component by receiving, through the web component, from the web client a fourth HTTP request for a session setup with the GRSG, to establish the first connection between the GRSG and the web client. The second connection between the GRSG and the service is established through the second component by binding, through the Binder component, the GRSG to the Binder service.

FIG. 15 is a diagram illustrating how to connect a web client and a Binder service through a GRSG. As illustrated in FIG. 15, the connection between the web client and the Binder service also needs to be relayed by the GRSG.

GRSG’s web component will mainly work as a web service to maintain the connection between web client and GRSG. GRSG’s Binder component will mainly play the role of a Binder proxy to setup the Binder connection with the Binder service. If GRSG and the Binder service runs in separated devices, their connection will be handled by distributed Binder.

HTTP is stateless protocol, but the connection between web client and web service has sessions, which allow the web service to maintain user identity and session state, and will expire over a specified period.

There is not session concept in Binder connection, but a client needs to bind the server before the client can start to invoke server’s procedures and unbind the server after finish, to release system resource.

When a web client initiates the first HTTP request to setup a session with GRSG, its web component will ask the GRSG’s Binder component to start to bind the Binder service; when the session expires, web component will ask the Binder component to unbind. When there are multiple web clients connected with GRSG’s web component to bind the same server, the last session’s expiration will trigger web component to ask Binder component to unbind. In other words, there is a mapping between web session and Binder connection.

Binder component maintains the information of the Binder services. For binding a local Binder service, the information includes the package name, service name; and for remote Binder service, the information also includes the server address (e.g. hostname) and port number, and the credential to establish secured Binder connection with remote service.

After the successful binding, Binder components will return a SessionId to web component. A “SessionId” is an integer to identify the connection between the web component and a specific Binder service. After establishing the Binder connection, any subsequent bind requests to the same service will return the same SessionId unless the connection is destroyed.

The interfaces for web component to ask Binder component to bind and unbind service can be defined as follows:

Sample 16

int estblishConnectionWithBinderService (string serviceName) ;

void destroyConnectionWithBinderService (int sessionid) ;

The “serviceName” consist of package name and service class name, and the “service class name” is normally as same as the “interface class name” which is used descriptions about converting Binder APIs to HTTP APIs. “esblishConnectionWithBinderService () ” will return the SessionId. Binder component will save the mapping among the service information, the Binder proxy and SessionID in such a table like this:

serviceName

SessionId

Binder Proxy

“destroyConnectionWithBinderService () ” will unbind the service, and its input parameter is the returned SessionId from “estblishConnectionWithBinderService () ” .

As an implementation, the method further includes the following.

After the first connection and the second connection are established, a fifth HTTP request is received through the web component from the web client. The fifth HTTP request is parsed through the web component to obtain an interface class name, a first function name, and at least one third parameter. A second API of the Binder component corresponding to the interface class name is invoked through the Binder component. A fourth Binder proxy is determined through the Binder component based on the interface class name and a mapping relationship between interface class names and Binder proxies. A Binder proxy’s API is invoked through the Binder component with the at least one third parameter, where the Binder proxy’s API is used to make the Binder service process a call corresponding to the fifth HTTP request.

As an implementation, the method further includes the following. After the Binder service has processed the call corresponding to the fifth HTTP request, a result of call processing is received through the Binder component from the Binder service. The result is sent through the Binder component to the web component. A fourth response is composed through the web component by processing the result. The fourth response is sent through the web component to the web client.

As discussed in descriptions about converting Binder APIs to HTTP APIs, the APIs exported by a Binder service will have corresponding HTTP APIs, the web client will be programmed with those HTTP APIs. FIG. 16 is a schematic flowchart illustrating a process of a web client invoking Binder service’ procedures according to implementations. As illustrated in FIG. 16, the process of a web client invoking Binder service’ procedures can be formulated as following.

Binder component will expose the BC_APIs, which we have discussed in section about handle subscription. Every HTTP API will have corresponding BC_API. A BC_API will find out the Binder proxy using the “service Name” and invoke a specific Binder API through the Binder proxy.

The web component in GRSG will play the role of web service. As a middleman between web client and Binder component, when web component receives the HTTP request from web client, it will parse the request message to figure out interface class, function and parameters (based on the rule discussed in section “Convert Binder APIs to HTTP APIs” ) , and then invoke corresponding BC_API which will then further invoke Binder proxy’s Binder API; and eventually, the corresponding Binder service’s procedure will be invoked.

When Binder service’s procedure returns, Binder component will pass the results to web component, which will further process the returned value to compose a HTTP response message and send the response to web client.

As we have discussed before, GRSG can choose to inline the BC_API functions into the corresponding web component methods, so that, a web component method can invoke the Binder proxy APIs directly, without going through the BC_APIs.

As an implementation, the method further includes the following. A sixth HTTP request with a Binder object is received through the web component from the web client. For each of at least one API of the web client, a second API of the web component is created through the web component, where the at least one API of the web client corresponds to at least one callback function defined in the Binder object. A third Binder class name is obtained through the web component by processing the Binder object. A third API of the Binder component is invoked through the web component and the third Binder class name is sent through the web component to the Binder component. A third Binder stub corresponding to the third Binder class name is determined through the Binder component, where the third Binder stub is configured to implement at least one API defined in a third Binder class corresponding to the third Binder class name. A remote procedure call (RPC) to the Binder service with the third Binder stub as an input parameter is invoked through the Binder component.

Binder APIs can have a Binder object as an input parameter, in which way the interfaces defined in the Binder object will be transmitted from the Binder client to Binder service, and those interfaces are implemented by the Binder client, and they can be invoked as callback functions by the Binder service. Based on callback functions in the related art, how make the web client to register its URL as callback functions to the Binder service is provided below.

In descriptions about converting Binder APIs to HTTP APIs, a general rule to generate HTTP APIs based on the Binder APIs have been discussed. But there is special case not touched yet, that is, the input parameter could be a Binder object.

As an input parameter, a Binder object can be treated as a group of interfaces embedded in the object which will be sent from the caller to the callee. So, when composing the HTTP request message for an API which has a Binder object, the Binder object should be represented by an object in the request body with the following rule (like HTTP subscription) :

1. the name of the object is the Interface class name (i.e. its Binder class name)

2. each of the API in the Binder object will have a name-value pair item, the name is the API function name, and the value is the URL which could be anywhere defined by web client and it will be invoked by web service.

For example, here is a Binder API setCallback () in service “ExampleService” which has a Binder object as input parameter:

Sample 17

Interface ExampleCallback {

Int methodA (int progress) ;

Int methodB (string error) ;

}

void setCallback (int id, ExampleCallback ck) ;

The HTTP Request Message will be like this:

Sample 18

POST /ExampleService/setCallback? id=1234

HOST my. example. com

Content-Type: application/json

{

“ExampleCallback” {

“methodA” : “https: //myserver. com/methodA/callback “

“methodB” : “https: //myserver. com/methodB/callback “

}

The input parameter “id” is put in query string; the parameter “ck” is a Binder object of type “ExampleCallback” , which is placed in request body in JSON.

The callback function itself (i.e. the methodA, methodB in the example above) should also have corresponding HTTP API. The HTTP requests should be sent by a web service, and response will be returned from a web client. The HTTP API should be defined following the rule below:

1. HTTP method can be “POST” ;

2. The path could be anywhere defined by web client (but should match the “value” of the name-value pairs in the Binder object) ;

3. The parameters of the callback function will be converted to HTTP query string, headers or message body following rules discussed in section “Convert Binder APIs to HTTP APIs” .

As such, the HTTP request message for method A is like the following

Sample 19

POST /methodA/callback? progress=90

HOST myserver. com

The path “/methodA/callback” match the “URL” in “ExampleCallback” / “methodA” ’s value “https: //myserver. com/methodA/callback ” . And the query string has the input parameter “progress” .

The HTTP request message for methodB:

Sample 20

POST /method/callback

HOST myserver. com

Content-Type: application/json

{

“error” : “Invalid Parameter”

}

The parameter “string error” in API “methodB” is placed in request body.

When a web client send HTTP request (Sample 18) to GRSG’s web component, it’s essentially to invoke an API with a Binder object (Sample 17) , Web component, as a web service, will receive the request and handle it in the way that we have discussed in the section “Invoke Binder Service’ Procedures” .

While processing the input parameters in the HTTP request message, for the Binder object parameter, web component will handle it in the following way:

1. The Binder class name and “name-value” pair will be saved in the table like below:

Binder Class Name

Function Name

List of URLs

If there are multiple web clients that invoke the API which have the same type of Binder objects, that means, different web clients register their own URLs for corresponding events. So, the list of different URLs will be saved for each of the function in the Binder class.

2. For each API (e.g. method A, method B) , corresponding WC_API (as we have discussed section Invoke Web Service’s Procedures) is constructed . Besides the input parameters defined in corresponding callback API (e.g. “int progress” for “method A” ) , the WC_API also receive the Binder class name and function name as input parameters. Basically. WC_API will be implemented as follows:

2.1 Use the Binder class name and function name to search for the List of the URLs in the table above. For each URL:

2.11 Compose the HTTP request using the URL and input parameters

2.12 Sent out HTTP Request and handle its response

Then, as described in descriptions about Invoking Binder Service’ Procedures, web component will invoke corresponding BC_API (e.g. for setCallback () ) . In the BC_API, the Binder object parameter will be replaced with the Binder class name. It means web component will send the Binder class name to Binder component through the BC_API.

When Binder component receives the Binder class name (e.g. ExampleCallback in Sample 18) . it will create a new Binder stub (e.g. for ExampleCallback class) if it has not been created yet, and save the map between Binder class name and Binder stub in a table like this:

Bind Class Name

Binder Stub

The Binder stub will implement the APIs defined in its Binder class (e.g. ExampleCallback class) as follows

2.2 Get input parameters

2.3 Invoke the WC_API with input parameters plus its Binder class name and function name.

Finally, GRSG’s Binder component will invoke the RPC (e.g. setCallback () in Sample 17) to the real Binder service, which have the Binder stub as input parameter.

As an implementation, the method further includes the following. After the RPC to the Binder service with the third Binder stub as the input parameter is invoked through the Binder component, a handler of a fourth Binder stub of the Binder component is invoked through the Binder component upon the Binder service invoking a callback function. A third API of the web component is invoked through the Binder component with input parameters, a fourth Binder class name, and a second function name. At least one uniform resource locator (URL) is searched for through the web component by using the fourth Binder class name and the second function name. For each of the at least one URL, a seventh HTTP request with the URL and input parameters is composed through the web component. At least one seventh HTTP request is sent through the web component to the web client. A fifth response is received through the web component from the web client. The fifth response is sent through the web component to the Binder component and the fifth response is sent through the Binder component to the Binder service.

After the Binder object has been sent to Binder service, Binder service will be able to invoke functions inside the Binder object as callback functions. FIG. 17 is a schematic flowchart illustrating a process of a Binder service invoking callback functions according to implementations.

As illustrated in FIG. 17, when Binder service invokes the callback function, the corresponding handler inside of GRSG’s Binder component’s Binder stub will be invoked. The handler will invoke corresponding WC_API which will search for the URLs using its current Binder class name and function name. For each URL web component will compose HTTP request with the URL and input parameters; and the HTTP request will be sent to web client. After web client processing, web component will get its response. After all URLs have been processed, web component will return to Binder component, then further return to the Binder service.

As an implementation, the GRSG is configured to run in one of: a first electronic device in which the web client runs, a second electronic device in which the Binder service runs, or a third electronic device except the electronic device in which the web client runs and the electronic device in which the Binder service runs.

The technical solution discussed to enable web clients to access Binder services do NOT assume where the GRSR will run. The GRSR can run in a web client device or a Binder service device. FIG. 18 and FIG. 19 have illustrated the two different configurations. FIG. 18 is a diagram illustrating a case that a GRSG and a Binder service running on the same device. FIG. 19 is a diagram illustrating a case that a GRSG and a web client running on the same device.

When there are multiple clients to access the Binder service, the configurations have been illustrated in FIG. 20 and FIG. 21. FIG. 20 is a diagram illustrating another case that a GRSG and a Binder service running on the same device. As illustrated in FIG. 20, if the GRSG runes in Binder service device, multiple clients can establish HTTP connection with GRSG. FIG. 21 is a diagram illustrating another case that a GRSG and a web client running on the same device. As illustrated in FIG. 21, if the GRSG runes in client device, multiple GRSG will setup distributed Binder connection with the Binder service.

As an implementation, when the GRSG runs in the first electronic device, the second electronic device runs a GRSG counterpart which cooperates with the GRSG.

As an implementation, the GRSG connects with and transports a message with the GRSG counterpart through transport layers (TLs) of the first electronic device and the second electronic device by using HTTP.

Android applications on different devices can make RPC among each other using distributed Binder. Distributed Binder also needs a Transport Layer (TL) to transport the commands and data among the devices. This section will discuss the method on how to use HTTP to work as TL for distributed Binder.

The GRSG has Binder proxies to handle the RPC called from other devices; and has Binder stubs to forward the RPC towards other devices. All the in/out RPC will go through the Transport Layer. So, there will be a bi-directional HTTP connection established between TLs. FIG. 22 is a diagram of establishing a bi-directional HTTP connection between TLs.

HTTP has evolved. HTTP1.1 was first documented in 1997; HTTP/2 specification was published in May 2015; and HTTP/3 is not yet standard. Both HTTP/2 and 3 have improved the efficiency of data transportation, and meanwhile maintain high-level compatibility with HTTP 1.1 (e.g. HTTP methods, status codes, URIs, and most header fields) .

The bi-directional HTTP connection will be implemented int the way that TL will play the roles of both web service and client. The method we proposed is mainly based on basic HTTP1.1. They should be supported by later versions.

Although HTTP/2 provide the feature of “Server Push” which allows server to send resource to a client before the client requests them, it is helpful in load resources but not in bi-directional RPC over HTTP.

What APIs between the TL and GRSG will be presented first, then how to implement them based on HTTP will be proposed.

TL will provide the following generic APIs for GRSG:

NodeInfo openConnection (SevInfo serviceinfo, ) ;

void closeConnection (NodeInfo nodeId) ;

int remoteCall (NodeInfo nodeId, int serviceId, int codeId, byte [] inputparcel, byte [] outputparcel, uri []

inputfiles, uri [] outputfiles)

The openConnection () will establish connection with a remote server (indicated by a SevInfo object) ; after connection established, an NodeInfo object will returns. How the SevInfo and NodeInfo are defined depends on the implementation. SevInfo should have the address information of the remote device and the authentication information for establish security connection. NodeInfo should be able to identify the remote device.

closeConnection () will close the connection which is indicated by the nodeId that is returned from openConnection () .

For remoteCall () , the “nodeId, serviceId, codeId, inputparcel, inputfiles” are all input parameters; the “outputparcel, outputfiles” are output parameters, which will reference to returned objects. The integer returned from the function will indicate success when it is zero or error when non-zero.

This is a synchronous API meaning that when GRSG invokes it, GRSG will block until returning from the function. TL should support for multiple threads to access this API concurrently and multiplex the transportation channel.

Meanwhile, GRSG should implement the following interface, TL will invoke it when get request message from remote device:

int processRequest (NodeInfo nodeId, int serviceId, int codeId, byte [] inputparcel, byte [] outputparcel, uri []

inputfiles, uri [] outputfiles)

When TL invokes the interface above, the nodeId is the id of the source device which initiates the request; the input parameters (i.e., serviceId, codeId, inputparcel and inputfiles) comes from the request from original device. GRSG will implement the API and return the objects through output parameters (i.e. outputparcel, outputfiles) . The integer returned from the function will indicate success when it is zero or error when non-zero.

FIG. 23 is a schematic flowchart illustrating interactions between how TLs and GRSGs. Specifically, FIG. 23 has illustrated the sequence of how TL and GRSG interact with the interfaces of remoteCall () and processReqeust () . Any GRSG can initiate a call remoteCall () to another GRSG which is addressed by nodeId; and the GRSG on destination device will be notified by invoking its processRequest () .

The input parameters and output parameters (i.e. returned results) should be processed by TL. The processing includes:

1. nodeId: in remoteCall () , it indicates the destination device; and in processRequest () , it indicates the source device.

2. inputFiles and OutputFiles: both are arrays of URIs, which reference to local files. They should be processed in the same way. Let us take inputFiles as an example. When remtoeCall () is invoked, TL needs to transport those files referenced by inputFiles from local device to the remote device; and on destination device, the TL needs to receive those file and generate new URIs to replace the elements in inputFiles so that the URIs will meaningfully reference to the files received and saved on destination device.

3. serviceId and codeId; as primitive data, they should be transported without change.

4. Inputparcel and outputparcel: both are byte array and should be transported to destination device without change.

The APIs discussed above can be categorized into 2 parts: openConnection () and closeConnection () , which are to manage the connections among devices; remoteCall () and processRequest () , which are to transport the messages among devices.

As an implementation, the GRSG connects with the GRSG counterpart through the TLs of the first electronic device and the second electronic device by using HTTP includes the following. An eighth HTTP request is sent by the fist electronic device to the second electronic device at the TLs, where the eighth HTTP request is configured to connect the GRSG to the GRSG counterpart. A sixth response corresponding to eighth HTTP request is received by the fist electronic device at the TLs from the second electronic device. A ninth HTTP request is received by the fist electronic device at the TLs from the second electronic device. The ninth request HTTP request is processed by the first electronic device and a seventh response corresponding to ninth request HTTP is sent to the second electronic device, to establish a HTTP connection between the GRSG and the GRSG counterpart.

FIG. 24 is a schematic flowchart illustrating a normal process of establishing connection between two devices’ TLs. As can be seen from FIG. 24, when a connection is established with another device, since a bi-directional connection is required, the remote destination device need to connect back to the source device.

NodeInfo object is the identification of the device. It is not necessary to be universal unique or unique within grouped devices. Instead, since server address (i.e. maintained in SevInfo) is global unique, the NodeInfo object (assigned and associated with the SevInfo) could be unique within local device. For HTTP implementation, it could be an integer (NodeId) and work as a local handle in other APIs.

TL will have a dedicated endpoint for other TL (as a web client) to access. For example, it could be “/dBinder/transportlayer” . So, the HTTP request for open connection will be like this:

Sample 21

GET /dBinder/transportlayer HTTP/1.1

HOST mydevice2. example. com

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

The HOST header will indicate the server; and Authorization header is an example for authentication.

Fig 21 only illustrates z normal workflow. In case there are errors while processing those HTTP requests, the open connection process will fail. So, only the following two conditions has been satisfied, will Device1’s TL assign NodeId for Device2:

Condition 1: The Device1’s HTTP Request for open connection with Device2 has get success response (200) .

Condition 2: The Device1 has receive Device2’s request for open connection, processed and return success.

After assigning NodeId, the mapping between NodeId and corresponding SevInfo will be saved. Meanwhile, TL will maintain session state between the devices (e.g. using cookie) until closeConnection () is invoked.

As an implementation, the GRSG transports the message with the GRSG counterpart through the TLs of the first electronic device and the second electronic device by using the HTTP includes the following. A call is initiated through the GRSG, where the call is configured to be processed, at a TL corresponding to the GRSG and to obtain at least one fourth parameter, the at least one fourth parameter being configured to be composed into a tenth HTTP request to be transmitted at a TL corresponding to the GRSG to a TL corresponding to the GRSG counterpart; where the tenth HTTP request is configured to be received and processed at the TL corresponding to the GRSG counterpart and invoke a request interface, the request interface being configured for the GRSG counterpart to process a call from the GRSG.

When remoteCall () is invoked, TL needs to compose a HTTP request message which will have all the input parameters and data as payload. And TL will find out the SevInfo associated by NodeId; and the SevInfo can be used to compose HOST header and part of the URL.

After processRequest () returns, TL needs to compose a HTTP response message, which will have output objects embedded in response body.

The HTTP messages can be composed using the method proposed in descriptions about converting Binder APIs to HTTP APIs” .

As an implementation, where the GRSG counterpart is provided an API which is added in an interface class, where the API has an output parameter in a byte array which contains meta data of the API.

A Web client can browse Binder services running in the current electronic device and Binder APIs exported by those Binder services.

Different from the process of web clients accessing Binder services described above, some modification can be further made. FIG. 25 a diagram illustrating a web client browsing a Binder service’s API. As illustrated in FIG. 25, the GRSG has a web component and a Binder component, however the Binder service’s Binder module will be modified to add new special APIs

There will be a new special API added in AIDL defined interface class, which is defined as follows:

public int getAPIInfo (out byte [] apiInfo) ;

The function will return an integer, which is zero meaning success and non-zero meaning errors. The output parameter is a byte array which will contains each API’s meta data in a specific format (e.g. YAML, JSON, XML) .

For each API, the meta data should:

1. describe the API’s method id, function name, function description (optional) , schema of return type, schema of each parameter.

2. describe a schema of a parameter (or return type) which includes:

2.1 direction (only for top-level parameter type, in, out, or inout)

2.2 description (optional)

2.3 name

2.4 type.

2.4.1 for primitive type, give its name.

2.4.2 for the non-primitive types: for object parameter, further recursively breakdown its schema; for array, further breakdown each item’s schema; for Enum, list all Enum options

The output apiInfo can be compressed to save space and transportation bandwidth.

This API’s implementation and its data (i.e. apiInfo) will be generated by AIDL compiler and will be built into released library.

GRSG’s web component will take the role of web service to support the capability of browsing the Binder APIs. It will export a group of endpoints and handle related “GET” requests.

The new endpoints will support the following requests:

Starting from “/grsg/packages” , a web client can browse all the accessible services’ Binder APIs in local device.

After web clients get a service’s API meta data, it can construct API parameters and invoke the API through the help of GRSG. FIG. 26 a schematic flowchart illustrating a process of the web client invoking Binder API. As illustrated in FIG. 26, the process of the web client invoking Binder API can be formulated as following.

A web client will compose a “POST” request message in the following way:

1. the endpoint is in the format of “/grsg/ {package} / {service} /function name” . The “function name” can be found in the API meda data.

2. method id, which can also be found in the API medta, will be a parameter in the query string.

3. all the “in” direction parameters will be marshalled into the byte array (following parcel format) , and the byte array will be embedded into the request body.

When GRSG’s web component receives the request, it will check its device , package and service, if the connection hasn’t established with the service, it will establish it (see the method in section “Establish connection to Binder Services” ) .

Then, web component will get its method id and parameter byte array. Since web client has encoded input parameter into byte array following parcel format, there will be a special BC_API provided by Binder component for web component. The BC_API will accept the method id and parameter byte array as input; and then invoke Binder proxy’s transact () command to send method id and the byte array (as a parcel) to the Binder service.

When transact () returning, output parcel will be returned from BC_API to web component, which will further embed the parcel data (as a byte array) into response body and send it back to web client.

Web client will unmarshall the byte array following API meta data and get real result.

The code for marhshall (to parcel) and unmarshall (from parcel) will be generated based on the API meda data. The generated code can be sent to web client, and then the action of marshalling and unmarshalling can be done in the client. The workflow above assumes the generated code in web client. Or, the generated code can be in GRSG’s web component, and then web client can send the parameters to GRSG’s web component, and web component will handle the marshalling and unmarshalling.

The process of the web client invoking Binder API discussed herein has enabled the Binder service to provide RESTful APIs for web clients to access. Web clients can dynamically get Binder services’ API information, and invokes the APIs based on its own business logic. It also enables people to develop more generic web clients to interact with Binder services seamlessly and transparently.

To sum up, both Distributed Binder and HTTP provide applications the capability of making RPC in a distributed environment. This present disclosure provides a method to support interaction between two different RPC systems.

First, the present disclosure provides a method for android applications to use Binder RPC to access web services. Specifically, web services can register in android system, and application can bind the web service in the same way as bind to normal android service. Binder application can invoke web services’ procedures as normal Binder RPC through the GRSG. Binder application can handle the links, which are returned from web service, as Binder RPCs. Binder application can subscribe web events and receive the web service’s callbacks. Multiple applications on one device or several different devices can use Binder RPC to access one or more web services on a remote device.

Second, the present disclosure provides a method for a web client to use HTTP messages to access Binder services. Specifically, web client can browse the Binder APIs exported by local or remote Binder services; and get their APIs’ meta data. Web client can invoke Binder services’ procedures as normal HTTP request; and get the returns as normal HTTP response, and there are two methods are proposed: Based on API meta data, web client compose parameters in the HTTP request and parse the returned data in the HTTP response; without API meta data, web client composes, and parses HTTP messages based on predefined rules, sends and receives normal HTTP messages, and GRSG will handle the data conversion between HTTP message and Binder APIs. Web client can register its links to Binder service; and Binder service can invoke them as callback functions. Multiple web clients on one device or several different devices can access one or more Binder services on a remote device.

The method to transform between HTTP APIs and Binder APIs are handled by GRSG, and its code can be generated from tools instead of manual coding.

The present disclosure also provides the method to use HTTP to construct a Transport Layer (TL) on which application on different devices can make Binder RPC among each other over HTTP.

Because Binder IPC can work also on other platforms than just android, the methods in this invention are applicable to any platform which has Binder IPC enabled.

The foregoing solution of the implementations of the present disclosure is mainly described from the viewpoint of execution process of the method. It can be understood that, in order to implement the above functions, the electronic device includes hardware structures and/or software modules corresponding to the respective functions. Those skilled in the art should readily recognize that, in combination with the example units and scheme steps described in the implementations disclosed herein, the present disclosure can be implemented in hardware or a combination of the hardware and computer software. Whether a function is implemented by way of the hardware or hardware driven by the computer software depends on the particular application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each particular application, but such implementations should not be considered as beyond the scope of the present disclosure.

According to the implementations of the present disclosure, functional units may be divided for the first wireless earphone in accordance with the foregoing method examples. For example, each functional unit may be divided according to each function, and two or more functions may be integrated in one processing unit. The above-mentioned integrated unit can be implemented in the form of hardware or software functional units. It should be noted that the division of units in the implementations is schematic, and is merely a logical function division, and there may be other division manners in actual implementation.

FIG. 27 is a schematic structural diagram of an electronic device according to implementations. As illustrated in FIG. 27, the electronic device 270 includes a processor 271, a memory 272, a communication interface 273, and one or more programs 274 stored in the memory 272 and executed by the processor 271. The one or more programs 274 include instructions for performing some or all operations of the method for enabling interaction between a Binder application and a HTTP application as described in the above-described method implementations.

A non-transitory computer storage medium is also provided. The non-transitory computer storage medium is configured to store programs which, when executed, are operable to execute some or all operations of the method for enabling interaction between a Binder application and a HTTP application as described in the above-described method implementations.

A computer program product is also provided. The computer program product includes a non-transitory computer-readable storage medium that stores computer programs. The computer programs are operable with a computer to execute some or all operations of the method for enabling interaction between a Binder application and a HTTP application as described in the above-described method implementations.

It is to be noted that, for the sake of simplicity, the foregoing method implementations are described as a series of action combinations. However, it will be appreciated by those skilled in the art that the present disclosure is not limited by the sequence of actions described. According to the present disclosure, certain steps or operations may be performed in other order or simultaneously. Besides, it will be appreciated by those skilled in the art that the implementations described in the specification are exemplary implementations and the actions and modules involved are not necessarily essential to the present disclosure.

In the foregoing implementations, the description of each implementation has its own emphasis. For the parts not described in detail in an implementation, reference may be made to related descriptions in other implementations.

In the implementations of the present disclosure, it is to be noted that, the apparatus disclosed in implementations provided herein may be implemented in other manners. For example, the device/apparatus implementations described above are merely illustrative; for instance, the division of the unit is only a logical function division and there can be other manners of division during actual implementations; for example, multiple units or components may be combined or may be integrated into another system, or some features may be ignored, omitted, or not performed. In addition, coupling or communication connection between each illustrated or discussed component may be direct coupling or communication connection, may be indirect coupling or communication among devices or units via some interfaces, and may be electrical connection, mechanical connection, or other forms of connection.

The units described as separate components may or may not be physically separated, and the components illustrated as units may or may not be physical units, that is, they may be in the same place or may be distributed to multiple network elements. All or part of the units may be selected according to actual needs to achieve the purpose of the technical solutions of the implementations.

In addition, the functional units in various implementations of the present disclosure may be integrated into one processing unit, or each unit may be physically present, or two or more units may be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or a software function unit.

The integrated unit may be stored in a computer-readable memory when it is implemented in the form of a software functional unit and is sold or used as a separate product. Based on such understanding, the technical solutions of the present disclosure essentially, or the part of the technical solutions that contributes to the related art, or all or part of the technical solutions, may be embodied in the form of a software product which is stored in a memory and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, and so on) to perform all or part of the steps described in the various implementations of the present disclosure. The memory includes various medium capable of storing program codes, such as a USB (universal serial bus) flash disk, a read-only memory (ROM) , a random access memory (RAM) , a removable hard disk, Disk, compact disc (CD) , or the like.

It will be noted by those of ordinary skill in the art that all or a part of the various methods of the implementations described above may be accomplished by means of a program to instruct associated hardware, where the program may be stored in a computer-readable memory, which may include a flash memory, a read-only memory (ROM) , a random-access memory (RAM) , a disk or a compact disc (CD) , and so on.

The implementations of the present disclosure are described in detail above, specific examples are used herein to describe the principle and implementation manners of the present disclosure. The description of the above implementations is merely used to help understand the method and the core idea of the present disclosure. Meanwhile, those skilled in the art may make modifications to the specific implementation manners and the application scope according to the idea of the present disclosure. In summary, the contents of the specification should not be construed as limiting the present disclosure.

Claims

A method for enabling interaction between a Binder application and a hypertext transfer protocol (HTTP) application, applicable to a generic remote service gateway (GRSG) , the GRSG comprising a first component and a second component, and the method comprising:

establishing, through the first component, a first connection between the GRSG and a client; and

establishing, through the second component, a second connection between the GRSG and a service, so as to connect the client with the service through the first connection and the second connection;

wherein one of the client and the service is the Binder application and the other one is the HTTP application.
The method of claim 1, wherein when the client is the Binder application and the service is the HTTP application, the client is a Binder client and the service is a web service, the first component is a Binder component which is configured to handle a Binder connection between the GRSG and the Binder client, and the second component is a web component which is configured to handle a HTTP connection between the GRSG and the web service.
The method of claim 2, wherein establishing, through the first component, the first connection between the GRSG and the client comprises:

receiving, through the Binder component, a request for establishing a connection between the Binder client and the web service; and

returning, though the Binder component, a first Binder stub to the Binder client, wherein the first Binder stub is configured for the Binder client to get a first Binder proxy corresponding to the first Binder stub.
The method of claim 2 or 3, further comprising:

after the first connection and the second connection are established:

receiving, through the Binder component, a parcel from the Binder client and invoking, through the Binder component, a Binder stub method, wherein the parcel is obtained at the Binder client by marshalling at least one first parameter of a Binder call, and the Binder stub method corresponds to a first application programming interface (API) of the web component;

unmarshalling, through the Binder component, the parcel to get the at least one first parameter;

invoking, through the web component, the first API of the web component corresponding to the Binder stub method;

composing, through the web component, a first HTTP request based on the at least one first parameter; and

sending, through the web component, the first HTTP request to the web service, wherein the first HTTP request is configured to request the web service to process the Binder call initiated by the Binder client.
The method of claim 4, further comprising:

after sending, through the web component, the first HTTP request to the web service:

receiving, through the web component, a first response to the first HTTP request from the web service;

parsing, through the web component, the first response and constructing, through the web component, at least one object based on the first response;

transferring, through the web component, the at least one object to the Binder component; and

marshalling, through the Binder component, the at least one object to a returned parcel and sending, through the Binder component, the returned parcel to the Binder client, wherein the returned parcel is configured to be unmarshalled to get the at least one object by the Binder client.
The method of claim 5, wherein the first response comprises a plurality of links, and the method further comprises:

after receiving, through the web component, the first response from the web service:

converting, through the web component, the first response into at least one second parameter in a Binder API definition and sending, through the Binder component, the at least one second parameter in the Binder API definition to the Binder client;

receiving, through the Binder component, a second response to the at least one second parameter in the Binder API definition from the Binder client;

invoking, through the web component, at least one API of the web component for at least one of a plurality of Binder APIs, wherein the plurality of Binder APIs are created at the Binder client and correspond to the plurality of links, the at least one of the plurality of Binder APIs are determined based on the second response of the Binder client;

composing, through the web component, at least one HTTP request corresponding to the at least one API of the web component; and

sending, through the web component, the at least one HTTP request to the web service.
The method of any of claims 2 to 6, further comprising:

after the first connection and the second connection are established:

receiving, through the Binder component, a second Binder stub from the Binder client;

converting, through the Binder component, the second Binder stub to a second Binder proxy;

determining, through the Binder component, a first Binder class name based on the second Binder proxy and a mapping relationship between Binder class names and Binder proxies, wherein a first Binder class is composed of at least one method, and each of the at least one method is configured to define an event subscribed by the Binder client;

sending, through the Binder component, the first Binder class name to the web component;

constructing, through the web component, at least one path for each of the at least one method in the first Binder class and registering, through the web component, the at least one path as at least one endpoint of at least one local web service; and

generating, through the web component, a second HTTP request based on the first Binder class name and sending, through the web component, the second HTTP request to the web service to subscribe the at least one event.
The method of claim 7, further comprising:

after sending, through the web component, the second HTTP request to the web service to subscribe the at least one event:

receiving, through the web component, a third HTTP request from the web service and obtaining, through the web component, a second Binder class name by parsing the third HTTP request;

invoking, through the web component, a first API of the Binder component corresponding to the third HTTP request and sending, through the web component, the second Binder class name to the Binder component;

determining, through the Binder component, a third Binder proxy corresponding to the second Binder class name;

processing, through the Binder component, the third Binder proxy by invoking a callback function of the Binder client; and

sending, through the Binder component, a third response to the web component in response to the third Binder proxy having been completely processed and sending, through the web component, the third response to the web service.
The method of any of claims 2 to 8, wherein the GRSG is configured to run in one of: a first electronic device in which the web service runs, a second electronic device in which the Binder client runs, or a third electronic device except the electronic device in which the web service runs and the electronic device in which the Binder client runs.
The method of claim 9, wherein when the GRSG runs in the first electronic device, the second electronic device runs a GRSG counterpart which cooperates with the GRSG, and the GRSG counterpart is configured to register web service information to the second electronic device.
The method of claim 1, wherein when the client is the HTTP application and the client is the Binder application, the client is a web client and the service is a Binder service, the first component is a web component which is configured to handle a HTTP connection between the GRSG and the web client, and the second component is a Binder component which is configured to handle a Binder connection between the GRSG and the Binder service.
The method of claim 11,

wherein establishing, through the first component, the first connection between the GRSG and the client comprises:

receiving, through the web component, from the web client a fourth HTTP request for a session setup with the GRSG, to establish the first connection between the GRSG and the web client; and

wherein establishing, through the second component, the second connection between the GRSG and the service comprises:

binding, through the Binder component, the GRSG to the Binder service.
The method of claim 11 or 12, further comprising:

after the first connection and the second connection are established:

receiving, through the web component, a fifth HTTP request from the web client;

parsing, through the web component, the fifth HTTP request to obtain an interface class name, a first function name, and at least one third parameter;

invoking, through the Binder component, a second API of the Binder component corresponding to the interface class name;

determining, through the Binder component, a fourth Binder proxy based on the interface class name and a mapping relationship between interface class names and Binder proxies;

invoking, through the Binder component, a Binder proxy’s API with the at least one third parameter, wherein the Binder proxy’s API is used to make the Binder service process a call corresponding to the fifth HTTP request.
The method of claim 13, further comprising:

after the Binder service has processed the call corresponding to the fifth HTTP request:

receiving, through the Binder component, a result of call processing from the Binder service;

sending, through the Binder component, the result to the web component;

composing, through the web component, a fourth response by processing the result; and

sending, through the web component, the fourth response to the web client.
The method of any of claims 11 to 14, further comprising:

receiving, through the web component, a sixth HTTP request with a Binder object from the web client;

for each of at least one API of the web client, creating, through the web component, a second API of the web component, wherein the at least one API of the web client corresponds to at least one callback function defined in the Binder object;

obtaining, through the web component, a third Binder class name by processing the Binder object;

invoking, through the web component, a third API of the Binder component and sending, through the web component, the third Binder class name to the Binder component;

determining, through the Binder component, a third Binder stub corresponding to the third Binder class name, wherein the third Binder stub is configured to implement at least one API defined in a third Binder class corresponding to the third Binder class name; and

invoking, through the Binder component, a remote procedure call (RPC) to the Binder service with the third Binder stub as an input parameter.
The method of claim 15, further comprising:

after invoking, through the Binder component, the RPC to the Binder service with the third Binder stub as the input parameter:

invoking, through the Binder component, a handler of a fourth Binder stub of the Binder component upon the Binder service invoking a callback function;

invoking, through the Binder component, a third API of the web component with input parameters, a fourth Binder class name, and a second function name;

searching, through the web component, for at least one uniform resource locator (URL) by using the fourth Binder class name and the second function name;

for each of the at least one URL, composing, through the web component, a seventh HTTP request with the URL and input parameters;

sending, through the web component, at least one seventh HTTP request to the web client;

receiving, through the web component, a fifth response from the web client; and

sending, through the web component, the fifth response to the Binder component and sending, through the Binder component, the fifth response to the Binder service.
The method of any of claims 11 to 16, wherein the GRSG is configured to run in one of: a first electronic device in which the web client runs, a second electronic device in which the Binder service runs, or a third electronic device except the electronic device in which the web client runs and the electronic device in which the Binder service runs.
The method of claim 17, wherein when the GRSG runs in the first electronic device, the second electronic device runs a GRSG counterpart which cooperates with the GRSG.
The method of claim 18, wherein the GRSG connects with and transports a message with the GRSG counterpart through transport layers (TLs) of the first electronic device and the second electronic device by using HTTP.
The method of claim 19, wherein the GRSG connects with the GRSG counterpart through the TLs of the first electronic device and the second electronic device by using HTTP comprises:

sending, by the fist electronic device, an eighth HTTP request to the second electronic device at the TLs, wherein the eighth HTTP request is configured to connect the GRSG to the GRSG counterpart;

receiving, by the fist electronic device, a sixth response corresponding to eighth HTTP request at the TLs from the second electronic device;

receiving, by the fist electronic device, a ninth HTTP request at the TLs from the second electronic device, wherein the ninth HTTP request is configured to connect the GRSG counterpart to the GRSG; and

processing, by the first electronic device, the ninth request HTTP request and sending a seventh response corresponding to ninth request HTTP to the second electronic device, to establish a HTTP connection between the GRSG and the GRSG counterpart.
The method of claim 19 or 20, wherein the GRSG transports the message with the GRSG counterpart through the TLs of the first electronic device and the second electronic device by using the HTTP comprises:

initiating, through the GRSG, a call, wherein the call is configured to be processed, at a TL corresponding to the GRSG and to obtain at least one fourth parameter, the at least one fourth parameter being configured to be composed into a tenth HTTP request to be transmitted at a TL corresponding to the GRSG to a TL corresponding to the GRSG counterpart; wherein the tenth HTTP request is configured to be received and processed at the TL corresponding to the GRSG counterpart and invoke a request interface, the request interface being configured for the GRSG counterpart to process a call from the GRSG.
The method of claim 17, wherein the GRSG counterpart is provided an API which is added in an interface class, wherein the API has an output parameter in a byte array which contains meta data of the API.
A method for enabling interaction between a Binder application and a hypertext transfer protocol (HTTP) application, applicable to an electronic device with a Binder client, a generic remote service gateway (GRSG) , and a system server running thereon, the system server having an activity manager service (AMS) , a package manager service (PMS) , and a remote manager service (RMS) running thereon, and the method comprising:

sending, through the Binder client, a request to the AMS to set up a Binder connection with a web service, wherein the request contains an identity of the web service;

receiving, through the AMS, the request and sending, through the AMS, the identity of the web service to the PMS, wherein the PMS is configured to manage all applications installed in the electronic device and store information of all registered service;

checking, through the PMS, whether the web service is a local service;

controlling, through the PMS, the RMS to check whether the RMS has web service’s information in response to the web service being not the local service, wherein the RMS is configured to manage information of all remote services;

returning, through the RMS, GRSG information as the web service’s information and returning, through the PMS, the GRSG information to the AMS;

passing, through the AMS, the request to the GRSG, wherein the GRSG comprises a web component and a Binder component; and

establishing, through the web component, a connection with the web service and returning, through the Binder component, a Binder stub to the Binder client, so as to connect the Binder client with the web service.
An electronic device comprising a processor, a memory configured to store one or more programs, wherein the one or more programs are configured to be executed by the processor, and comprise instructions for performing the method of any of claims 1 to 22 and the method of claim 23.
A non-transitory computer-readable storage medium configured to store computer programs for electronic data interchange (EDI) which, when executed, are operable with a computer to perform the method of any of claims 1 to 22 and the method of claim 23.