HK1190530A - Enabling web clients to provide web services - Google Patents

Description

Enabling web clients to provide web services

Background

One very common programming model is to use HTTP as a transport when web servers are transacting with each other. For example, a first server may issue an HTTP GET request to request a representation of a particular resource from a second server. The second server may then respond with the resource representation. Transactions between servers may also occur in a more asynchronous manner. For example, the first server may issue an HTTP GET request and provide a return URL to the second server for use in a response. At some later time, the second server may asynchronously return to the first server using the URL provided by the first server. This process can also be easily operated in a reverse manner between servers.

Using this same model, a transaction between a client's application (such as a web browser) and a server can operate with the client application issuing HTTP GET requests and receiving responses from the server. However, the present transaction may not proceed in reverse of the process described above. In particular, a server typically may not issue HTTP GET or POST requests to client applications or web browsers, as web browsers typically do not run web servers, among other reasons. Even if they were running a web server, a firewall or other mechanism such as a Network Address Translation (NAT) device would render it virtually impossible for such transactions to occur.

Disclosure of Invention

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter.

Various embodiments enable a web client to provide web services. In one or more embodiments, a web client is configured to act as a server and can be used, among other things, for round-trip calls to web services supported by the web client. Such uses may include, by way of example and not limitation, pushing messages to and from the web client. The various techniques may utilize standard protocols and libraries without the need for any custom code or custom plug-ins.

In one or more embodiments, the intermediary server acts as an intermediary through which a persistent connection with the web client is established. The mediating server may then publish the web client to the world using, for example, the presence or address of the web client, such as a web service URL. Other web clients (e.g., browser-based clients) seeking to send messages to the first web client may use the published web service URL to invoke a predefined web service. The calling web client may also register with the same mediating server or a different mediating server and publish its web service URL. The first web client may then use the URL to push messages to the second web client.

Drawings

The detailed description is described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different instances in the description and the figures may indicate similar or identical items. The entities represented in the figures may indicate one or more entities and thus reference may be made interchangeably to singular or plural forms of such entities in discussion.

FIG. 1 is an illustration of an environment in an example implementation in accordance with one or more embodiments.

FIG. 2 is an illustration of another environment in an exemplary implementation in accordance with one or more embodiments.

FIG. 3 is a diagram of a communication flow between two web clients in accordance with one or more embodiments.

FIG. 4 is an illustration of an exemplary sequential flow between a caller, a tunnel service, and a web client in accordance with one or more embodiments.

Fig. 5 is a flow diagram depicting a procedure in an exemplary implementation according to one or more embodiments.

Fig. 6 illustrates an exemplary system comprising various components of an exemplary device that may be implemented as any type of computing device as described with reference to fig. 1 and 2 to implement embodiments of the techniques described herein.

Detailed Description

SUMMARY

Various embodiments enable a web client to provide web services. A web service is a program that can be invoked by sending it an HTTP request addressed to a particular URL and carrying input parameters within the fields of the HTTP request, including the URL, header and body. Output parameters that are the result of the program's computation are then returned within the fields of the HTTP response (including the status code, header, and body). In one or more embodiments, a web client is configured to act as a server and can be used for round-trip calls or the like for web services supported by the web client. Such uses may include, by way of example and not limitation, pushing messages to and from the web client. The various techniques may utilize standard protocols and libraries without the need for any custom code or custom plug-ins. The various techniques can be used, for example, to implement a browser-based chat client using standard protocols and libraries without requiring any custom code or plug-in installation in the browser. In at least some embodiments, standard HTTP techniques can be utilized without having to modify the structure of the HTTP communication that occurs.

In one or more embodiments, the intermediary server acts as an intermediary through which a persistent connection with the web client is established. The persistent connection may be established using any suitable technique or technology. By way of example, and not limitation, the skills or techniques may include COMET, WebSockets, and the like. The mediating server may then publish the web client to the world using, for example, the presence or address of the web client (such as a web service URL). Other web clients (e.g., browser-based clients) seeking to send messages to the first web client may use the published web service (web-service) URL to invoke a predefined web service. The calling web client may also register with the same mediating server or a different mediating server and publish its web service URL. The first web client may then use the URL to push messages to the second web client.

The techniques described herein may be utilized for numerous practical purposes. For example, the various embodiments may enable implementation of a browser-based client using standard web services techniques. Because the browser is able to invoke web services without any plug-in installation, the browser client can be designed to be very lightweight and can work on any device with a web browser. Thus, a wide variety of flexible usage scenarios may be provided. Furthermore, the techniques described in this document may be broadly applied to non-browser based scenarios. For example, the techniques may be utilized with any suitably configured device, including, by way of example and not limitation, embedded devices. For example, such embedded devices may take the form of those devices that may be utilized in a wide variety of scenarios, such as a "smart home" or "smart office" scenario, in which devices such as light switches, for example, may be configured as embedded devices to provide and use the web services described in this document.

In the discussion that follows, an exemplary environment that may utilize the techniques described herein is first described. Exemplary procedures that may be executed in the exemplary environment, as well as other environments, are then described. Thus, the performance of the exemplary process is not limited to the exemplary environment and the exemplary environment is not limited to the performance of the exemplary process.

Exemplary Environment

FIG. 1 is an illustration of an exemplary environment 100 in accordance with one or more embodiments. Environment 100 includes a caller 102, a client 104, and an intermediary server 106.

Callers 102 may comprise any suitably configured caller, such as, by way of example and not limitation, a client computing device, a server, or any other entity configured to invoke intermediary server 106. In one or more embodiments, the caller and client may comprise any suitable software agents running on any suitable computing device, examples of which are provided below. The proxy is configured to communicate using the methods described in this document (e.g., HTTP methods) as well as a variety of persistent connections for clients. In the illustrated and described embodiment, the client 104 includes a persistent connection with the broker server 106. Any suitable technique may be utilized to enable the persistent connection to be established. The mediating server 106 implements the tunnel service identified by the tunnel endpoint. As noted above, clients 104 may include any suitable type of client. In the various examples used in this document, the client 104 comprises a web client that may, but need not, exist as a proxy or web browser for communicating using browser-based technologies. However, client 104 need not communicate using browser-based technology. For example, the client 104 may exist in the form of a mobile client or embedded device that utilizes a native library to tunnel with the mediating server 106, as will be understood by those skilled in the art. The web client 104 registers with the broker server 106 using the tunnel ID.

In operation, caller 102 invokes a broker server 106 using standard verbs (standard verbs) using standard web protocols, such as HTTP or HTTPS. This can be achieved without any modification to the standard HTTP technology utilized to communicate. The call issued by caller 102 includes a tunnel endpoint associated with mediation server 106, a tunnel ID associated with web client 104, and a load that identifies the web service implemented by web client 104 and the data or information to be processed by the web service implemented by the web client. The mediating server 106 then processes the call by transforming the call into a standard web structure that can be processed by the web client. For example, the broker server 106 may serialize the call and encapsulate it in a standard web structure. The encapsulated structure is then passed (through a persistent connection) by the broker server 106 to the web client 104 for processing. When the web client 104 receives the encapsulated structure, it may utilize a library to invoke events to the web service for processing, the events including data or information received in the encapsulated structure. Once the data or information is processed by the web service, the web client 104 formulates a response comprising a packaged structure having a load. The formulated response is sent to the mediating server 106. The formulated response may be sent to the intermediary service using a standard connection, such as a TCP connection. The mediating server 106 then processes the response and formulates an HTTP response, which is then passed back to the caller 102.

Using this approach, web services supported by the web client 104 that exist behind firewalls can be leveraged and appear as fully functional HTTP endpoints. Further, by utilizing standard protocols, caller 102 and web client 104 may communicate through a NAT or other device that would otherwise disable such communication. Furthermore, because the described methods utilize standard protocols, no additional plug-ins or special techniques are utilized to affect communications, as will be understood by those skilled in the art.

Generally, any of the functions described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), or a combination of these implementations. The terms "module," "functionality," and "logic" as used herein generally represent software, firmware, hardware, or a combination thereof. In the case of a software implementation, the module, functionality, or logic represents program code that performs specified tasks when executed on a processor (e.g., CPU or CPUs). The program code can be stored in one or more computer readable memory devices. The features of the techniques described below are platform-independent, meaning that the techniques may be implemented on a variety of commercial computing platforms having a variety of processors.

For example, caller 102 and web client 104 may also include entities (e.g., software) that cause the hardware of the caller or web client 104 to perform operations, e.g., processors, function blocks, and so on. For example, the caller 102 and web client 104 may include computer-readable media that may be configured to maintain instructions that cause the associated computing device, and more particularly hardware of the computing device, to perform operations. Thus, the instructions function to configure the hardware to perform the operations and in this way cause the hardware to perform a transition in functionality. The instructions may be provided by the computer-readable medium to the computing device through a variety of different configurations.

One such configuration of a computer-readable medium is a signal bearing medium and thus is configured to transmit the instructions (e.g., as a carrier wave) to hardware of the computing device, such as via a network. The computer-readable medium may also be configured as a computer-readable storage medium and thus is not a signal bearing medium. Examples of computer readable storage media include Random Access Memory (RAM), Read Only Memory (ROM), optical disks, flash memory, hard disk memory, and other memory devices that may use magnetic, optical, and other techniques to store instructions and other data.

The processor is not limited by the materials from which it is formed or the processing mechanisms utilized herein. For example, a processor may be comprised of semiconductors and/or transistors (e.g., electronic Integrated Circuits (ICs)). In such a context, processor-executable instructions may be electronically-executable instructions. Alternatively, mechanisms of or for processors, and thus computing devices, may include, but are not limited to, quantum computing, optical computing, mechanical computing (e.g., using nanotechnology), and so forth.

Having considered an exemplary operating environment, consider now a specific example in which a web client in the form of a computing device and a caller communicate using a web browser.

FIG. 2 is an illustration of an environment 200 in an example implementation that is operable to utilize techniques described herein. The illustrated environment 200 includes: a computing device 202, 220, a mediating server 230, 240, and a network 250 (such as the internet) communicatively linking the mediating server 230, 240. The computing devices 202, 220 are configured to implement web services as described below.

Computing device 202 includes computer-readable storage media 204, which in turn includes operating system 206, one or more applications 208, and web browser 210. Computing device 220 includes a computer-readable storage medium 222, which computer-readable storage medium 222 in turn includes an operating system 224, one or more applications 226, and a web browser 228. Various resources of the computing device (e.g., the operating system, operating system resources, applications, and/or web browser) may be represented by web URLs, as will become apparent below. In this way, web services may be exposed at a variety of levels of granularity, examples of which are provided below.

The operating systems 206, 224 are configured to abstract underlying functionality of their respective computing devices to respective applications or web browsers executable on the computing devices. For example, the operating systems 206, 224 may abstract the processing, memory, network, and/or display functionality of their respective computing devices such that the applications may be written without knowing how such underlying functionality is implemented. The application may, for example, provide data to the operating system for presentation and display by a display device associated with the computing device without understanding how the presentation is to be performed.

The operating system may also represent a wide variety of other functionality, such as functionality utilized to manage a user interface and file system that may be navigated by a user of the computing device.

The mediating server 230 includes a tunnel service 232 and the like. Likewise, the mediating server 240 includes a tunnel service 242. Any suitable number of computing devices and/or intermediary servers may be utilized. In the illustrated and described embodiment, the computing devices 202, 220 represent client computing devices, examples of which are provided below.

The computing devices 202, 220 may be configured as computers capable of communicating over the network 250, such as desktop computers, mobile stations, entertainment appliances, set-top boxes communicatively coupled to display devices, wireless telephones, game consoles, and so forth. Thus, the computing devices 202, 220 may range from full resource devices with substantial memory and processor resources (e.g., personal computers, gaming machines) to low-resource devices with limited memory and/or processing resources (e.g., traditional set-top boxes, hand-held gaming machines).

Although the network 250 is described as the internet, the network may take on a wide variety of configurations. For example, the network 250 may include or otherwise utilize a Wide Area Network (WAN), a Local Area Network (LAN), a wireless network, a public telephone network, an intranet, or the like. Further, although a single network 250 is shown, the network 250 may be configured to include multiple networks.

In operation, as described in more detail below, various embodiments enable web clients, such as browser-based clients like browsers 210, 228 (and other non-browser-based clients), to provide web services. The browsers 210, 228 are configured to act as servers and may be used for round-trip calls or the like for web services supported by the browser-based clients. Such uses may include, by way of example and not limitation, pushing messages from one browser to another. The various techniques described may be used, for example, to implement a browser-based chat client using standard protocols and libraries without requiring any custom code or plug-in installation in the browser, as noted above.

The mediating servers 230, 240 function as intermediaries and are configured to enable the browser-based client to establish a persistent connection with the corresponding mediating server, here represented at 260, 262, respectively. As noted above, the persistent connection may be established using any suitable technique or technology. By way of example, and not limitation, such tricks or techniques may include COMET, Web sockets, and the like. The mediating server may then publish the browser-based client to the world using, for example, the presence or address of the browser (such as a web service URL). Other web service clients (e.g., another browser-based client) seeking to send messages to the first browser-based client may use the published web service URL to invoke a predefined web service. The invoking browser-based client may also register with the same mediating server or a different mediating server and publish its web service URL. The first browser-based client may then use the URL to push messages to the second browser-based client.

In operation, the persistent connections 260, 262 are utilized to create tunnels from web clients, such as web browsers 210, 228, to respective intermediary servers using respective tunnel services 232, 242. The persistent connection may be utilized to receive requests from various entities. For example, the persistent connection may be utilized to enable browser-based clients as well as non-browser-based clients to receive web service requests from other callers, including other browser-based and non-browser-based clients. The mediating server acts as an HTTP endpoint that is externally and continuously available. This then allows emulation of what will happen if the browser is able to open a socket and locally launch a web server for receiving synchronous requests from the server or processing responses to asynchronous requests.

As an example, consider the following. The computing device 202 may establish a persistent connection 260 with the mediating server 230. The web browser 210 may register with the mediating server 230 through the persistent connection 260. Likewise, the computing device 220 may establish a persistent connection 262 with the mediating server 240. The web browser 228 may likewise register with the broker server 240 via the persistent connection 262. When web browser 210 wishes to communicate with web browser 228, web browser 210 obtains a web service URL associated with web browser 228. This may be accomplished, for example, through a registry maintained by the mediating server 240. The browser 210 can then use the web service URL to invoke a web service published by the web browser 228 to deliver data or other information to the web browser 228. Along with the delivered data, web browser 210 may also provide its web service URL to web browser 228. The web browser 228 can then use the web service URL of the web browser 210 to communicate data or other information to the web browser 210. In one or more embodiments, the web service URL is an address associated with the mediating servers 230, 240, respectively. The web service URL is configured to include an identification of the associated browser to enable the mediating server through its respective tunnel service 232,242 to determine where to deliver data that is the subject of a web service call. The request made to the tunnel service may be made using a standard TCP connection with the mediating server. The mediating server may then deliver the request to the intended recipient using a persistent connection with the recipient. Responses from the intended recipients may be sent back to the intermediary service using a standard TCP connection.

FIG. 3 is an illustration of an exemplary environment 300 in accordance with one or more embodiments. The environment 300 includes a web browser 302 having a library 304, a web browser 306 having a library 308, and an intermediary server 310 implementing a tunnel service 312. In this example, the two web browsers (i.e., web clients) each implement one or more web services and wish to communicate with each other.

In the illustrated and described embodiment, the web browsers 302, 306 each include a persistent connection with the mediating server 310, which is indicated by the arrow. The persistent connection may be utilized to receive a web service request from a caller through the intermediary server. Any suitable technique may be utilized to enable the persistent connection to be established. In addition, each of the web browsers registers with the broker server 310 using a corresponding tunnel ID.

In operation, web browser 302 (and web browser 306) utilize standard web protocols to issue calls in the form of HTTP requests. In this particular example, the HTTP request takes the form:

http://tunnel-endpoint/<tunnel-ID>/service/message。

the calls issued by web browser 302 include: a tunnel-endpoint ("tunnel-endpoint") that is associated with the mediating server 310 and identifies the mediating server 310; a tunnel-ID ("tunnel-ID") associated with the web browser 306; and a load that identifies the web service implemented by web browser 306 and the data or information ("service/message") to be processed by the web service implemented by the web browser.

The mediating server 310 and its tunnel service 312 then process the call by transforming it into a standard web structure that can be processed by the web browser. For example, the HTTP request includes a method, a URL, a body (body), and a header (header). These are utilized to build a JavaScript structure, which is essentially a dictionary with keys and content corresponding to the method, URL, body and header. The JavaScript structure is then serialized and encapsulated using JavaScript object notation (JSON) to provide an encapsulated request structure. The encapsulated request structure is then passed by the mediating server 310 to the web browser 306 for processing using the persistent connection. When the web browser 306 receives the encapsulated request structure, it may utilize a library 308 to invoke events to the web service for processing, the events including data or information received in the encapsulated request structure (i.e., "service/message"). Once the data or information is processed by the web service, the web browser 306 formulates a response comprising a packaged response structure having a load, e.g., a response structure packaged using JSON. The encapsulated response structure is sent to the mediating server 310. The encapsulated response structure may be sent to the mediating server using a standard TCP connection. The broker server 310 then processes the encapsulated response structure and formulates an HTTP response, which is then passed back to the web browser 302. The HTTP response may be processed by web browser 302 in a conventional manner.

Further, the two web browsers 302, 306 may communicate directly with each other by making an HTTP request to each other, using the following format:

http://tunnel-endpoint/<respective-tunnel-ID>。

furthermore, in at least some embodiments, if the web service is implemented using node.js, (which is the server-side JavaScript programming language and execution environment), the same code can be moved from the server to any browser client by simply replacing the server instance library with the tunnel endpoint library, as will be understood by those skilled in the art. Thus, instead of registering to receive an incoming web request, registration may occur with a client JavaScript implementation of the tunneling software that generates exactly the same events that would have been generated if the software had been running in the node.

Fig. 4 illustrates an exemplary sequence diagram, generally at 400, showing how an external HTTP request is encapsulated within JSON and then sent to a client, such as a web browser, over a persistent connection. In this example, authentication is performed but not illustrated. In particular, authentication may be performed by restricting authorized callers from sending messages to the client, either on the tunnel service, or on the client itself (e.g., a browser), or both.

In the example, many actions are illustrated as being performed by entities, including callers, tunnel services, and clients. Each of the actions is enumerated with a number enclosed, which is then qualified below. As noted above, the caller may comprise any suitable entity including, by way of example and not limitation, an end-user computing device, a server, a suitably-configured application executing on the computing device or server, a web browser, and the like. First, the caller makes an HTTP request at "1". This may, but need not, occur over a persistent connection. For example, the HTTP request may be made over a TCP connection that enables communication with the tunnel service. In this example, the HTTP request is a POST and has the form shown directly below the illustration. The "connID" corresponds to a tunnel ID with which the client is registered. The "myURL" corresponds to a "service/message" that is part of the payload.

The tunnel service receives the HTTP request and selects a connection at "2" that matches "connID". At "3", the tunnel service serializes the HTTP request and encapsulates it within JSON. The serialized encapsulated request structure is shown directly below the illustration. The client receives the encapsulated request structure over a persistent connection and processes the encapsulated request structure using a suitably configured library and fires appropriate events containing information and data to enable web services supported by the client to process the information and data. The client then prepares an encapsulated response structure, which is encapsulated in JSON, and returns the encapsulated response structure to the tunnel service at "4". The structure of the encapsulated response structure is shown directly below the illustration. The response may be sent to the tunnel service using a standard TCP connection.

The tunnel service then processes the encapsulated response structure and prepares an HTTP response, which is sent to the caller at "5". The structure of the HTTP response is shown directly below the diagram. The response includes an HTTP status code 200 indicating that the request has been fulfilled, along with a load that includes information and data resulting from the processing of the caller's request by the web service. The response can now be processed by the caller as a typical HTTP response.

In addition to the above discussion, additional considerations may be taken into account. As an example, consider the following.

Other considerations

Regarding safety precautions, consider the following. In one or more embodiments, to facilitate privacy, communications between callers and the intermediary server, as well as communications between the intermediary server and clients, may occur via secure transports, such as, by way of example and not limitation, utilizing secure transport layer protocols (TLS) or Secure Sockets Layer (SSL). In the case of HTTP communication, HTTPs is utilized. Further, to ensure that service requests are restricted to authorized systems, service accounts may be utilized. The service account may utilize an account key. In this way, the caller of the service can sign its HTTP request with this key, thus facilitating proof that it indeed processed the key and associated account. This signature may be implemented using any suitable encryption method, such as HMAC (hash-based message authentication code). Such a signature may be appended to the HTTP request with an additional authentication header. This signature may be checked by the service after receiving the request, and if the check is successful, the service request may be filled.

Furthermore, if the caller of the service is a client rather than a server, additional terms may be utilized to ensure the security of the account key. On the client, the key typically cannot be assumed to be securely stored as it would if it were stored on the server. For this purpose, the temporary account key plus the process for obtaining these in exchange for other security credentials may be utilized. Such keys may have a limited validity period, for example, by expiring after a day or within a predefined time period. Furthermore, the client connected to the service may also be required to authorize itself using the same techniques as the temporary key mentioned above.

Further, from a security standpoint, the tunnel service may utilize mechanisms to ensure that authorized systems can have their web service requests relayed to any given client. This may be done cryptographically using a random connection ID, which is assigned to the client connection and embedded in the client's personalised service URL. The client only gives this URL that it wants to send a request to the system. Any other system will not be able to make a request based on the simple fact that it does not know or guess the service URL/connection ID assigned to the client.

From an extensibility standpoint, consider the following. As noted above, a caller may comprise any suitable type of entity. For example, in the discussion above, a web browser is used to initiate a call to a particular web service or other web browser. Consider the situation where the operating system itself may maintain a persistent connection with a suitably configured intermediary server. In this example, the operating system may expose its personalized resources as URLs, which may be accessed using the techniques described above. For example, a tile (tile) of a personality that may appear on a display screen may be associated with a URL of the personality. Content associated with tiles of the personality may be updated by the service using the push mode. For example, rather than having the operating system actively fetch or otherwise obtain updates, updates may be pushed to operating system resources at their associated URLs. Thus, for example, if a tile is to be updated, the web service may use the tile's associated URL and make an HTTP POST request that is tunneled to the particular tile. For example, a computing system may have tiles associated with weather updates. Rather than having to retrieve the weather updates, such updates may be pushed to the tiles using the techniques described above.

As another example, consider a call service. With the call service, clients may call each other using, for example, voice over internet protocol (VoIP). In these scenarios, rather than utilizing a dedicated call server if the client has an incoming call, the techniques described above may be utilized with an HTTP-based call server to enable direct transmission of HTTP requests associated with the incoming call to the client, resulting in a push call notification.

For a web browser scenario, consider the following. RTC-Web (real-time collaboration on the world wide Web) is an effort to implement a standardized infrastructure in a Web browser on which real-time interactive communications between users of the Web can be implemented. Using the RTC-Web, peer-to-peer audio and video media sessions can be established between Web browsers. Using the data channel established between browsers over the RTC-Web, Web services supported by the Web browsers can communicate with each other bypassing the intermediary server using the techniques described above. In this manner, library functions implemented by the web browser may make HTTP calls to each other and access and utilize web services supported by the web browser.

Furthermore, the techniques described above greatly facilitate scalability. For example, as clients or callers grow, intermediary servers that expose tunneling services can easily be added to accommodate this growth. With this type of scalability, the processing overhead associated with the load balancer can be greatly reduced. In particular, load balancers are typically used in large systems to determine where to call directly. Once the load balancer determines a connection to the intermediary server in response to the call, load balancing need not be utilized for the caller in the future. That is, once the connection is determined, subsequent calls may be made directly to the mediating server without having to utilize the load balancer.

For scalability, consider the following. Extensibility can be supported and built into the way tunnel URLs are established. For example, the tunnel URL may have the form shown directly below:

http://trouterX.trouter.net/connectionID 。

wherein trouterx. trouter. net is the domain name of a specific instance of a server hosting (host) a persistent connection. This allows all servers to operate independently without having to find each other and delegate the web service request to each other. The work of finding the correct server is handed over to the internet (e.g., DNS). In this embodiment, the system has no shared state between the server instances. This is a prescription of infinite extensibility, as will be understood by those skilled in the art.

This is for example different from some alternative method in which the URL might take the form:

http://alternativeservice.net/app-assigned-ID 。

in this approach, the request is first routed to a random server, which typically does not have the connection. Therefore, the random server must find the connection owner and delegate it to it. The situation is further exacerbated by the tunnel/connection ID selected by the application, thus preventing the service from embedding the routing information in the URL. This results in the need for persistent storage to hold the routing information, which is keyed by the "app-assigned-ID," as will be understood by those skilled in the art.

Having considered an exemplary sequence diagram and other considerations in accordance with one or more embodiments, consider now a discussion of exemplary processes that may be implemented in accordance with one or more embodiments.

Exemplary procedure

FIG. 5 depicts the flow of communications that occur between a caller, a tunnel service, and a client in a manner that enables the client to provide web services. The communication flow may be implemented using the previously described systems and devices. Aspects of each of the processes may be implemented in hardware, firmware, or software, or a combination thereof. The processes are illustrated as a set of blocks that specify operations performed by one or more devices and are not necessarily limited to the orders shown for performing the operations represented by the respective blocks.

At block 502, the caller generates an HTTP request associated with a web service provided by an appropriately configured web client. Examples of HTTP requests are provided above. Block 504 sends the HTTP request to a tunnel service. This request may be sent over a standard TCP connection.

Block 506 receives the HTTP request and block 508 processes the HTTP request to identify the client. This may be performed in any suitable way, examples of which are provided above. Block 510 serializes the HTTP request and block 512 encapsulates the serialized HTTP request in a request structure. This may be performed in any suitable manner. In at least some embodiments, the serialized HTTP request is encapsulated in JSON, as described above. Block 514 sends the encapsulated request structure to the client. In one or more embodiments, the encapsulated request structure is sent over a persistent connection that is maintained between the tunnel service and the client.

Block 516 receives the encapsulated request structure at the client. Block 518 processes (at least in part) the encapsulated request structure using a web service. Block 520 prepares an encapsulated response structure that includes at least data and information associated with execution of the web service. Block 522 sends the binned response structure to the tunnel service. In one or more embodiments, the encapsulated response structure may be sent over a standard TCP connection.

Block 524 receives the encapsulated response structure at the tunnel service. Block 526 processes the encapsulated response structure and sends an HTTP response to the caller. Examples of how this can be achieved are provided above.

Block 528 receives the HTTP response at the caller and block 530 processes the HTTP response. This may include processing data and information included in the HTTP response as a result of the client executing the web service.

Having described exemplary processes in accordance with one or more embodiments, consider now exemplary systems and devices that can be utilized to implement the above-described embodiments.

Exemplary System and device

FIG. 6 illustrates an exemplary system, generally at 600, that includes an exemplary computing device 602 that represents one or more computing systems and/or devices that may implement the various techniques described herein. The computing device 602 may be, for example, a server of a service provider, a device associated with a client (e.g., a client device), a system on a chip, and/or any other suitable computing device or computing system.

The exemplary computing device 602 as illustrated includes a processing system 604, one or more computer-readable media 606, and one or more I/O interfaces 608, which are communicatively coupled to each other. Although not shown, the computing device 602 may also include a system bus or other data or command transfer system that couples the various components one to another. A system bus can include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures. A variety of other examples are also contemplated, such as control and data lines.

The processing system 604 represents functionality to perform one or more operations using hardware. Thus, the processing system 604 is illustrated as comprising a hardware unit 610, which hardware unit 610 may be configured as a processor, a functional block, etc. This may include implementation in hardware as an application specific integrated circuit or other logic device formed using one or more semiconductors. The hardware units 610 are not limited by the materials from which they are formed or the processing mechanisms utilized herein. For example, a processor may be comprised of semiconductors and/or transistors (e.g., electronic Integrated Circuits (ICs)). In this context, processor-executable instructions may be electronically-executable instructions.

The computer-readable storage medium 606 is illustrated as including a memory/storage 612. The memory/storage 612 represents memory/storage capacity associated with one or more computer-readable media. The memory/storage component 612 may include volatile media (such as Random Access Memory (RAM)) and/or nonvolatile media (such as Read Only Memory (ROM), flash memory, optical disks, magnetic disks, and so forth). The memory/storage component 612 may include fixed media (e.g., RAM, ROM, a fixed hard drive, etc.) as well as removable media (e.g., flash memory, a removable hard drive, an optical disk, and so forth). The computer-readable medium 606 may be configured in a variety of other ways, as described further below.

Input/output interface 608 represents functionality that allows a user to enter commands and information to computing device 602, and also allows information to be presented to the user and/or other components or devices using various input/output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone, a scanner, touch functionality (e.g., capacitive or other sensors configured to detect physical touches), a camera (e.g., which may utilize visible or invisible wavelengths such as infrared frequencies to recognize motion as a gesture that does not involve touch), and so forth. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, a haptic response device, and so forth. Thus, the computing device 602 may be configured to support user interaction in a variety of ways as described further below.

Computing device 602 also includes one or more web services 613 that it can provide, and the web services 613 can be utilized by various callers using the techniques described above.

Various techniques may be described herein in the general context of software, hardware elements, or program modules. Generally, such modules include routines, programs, objects, units, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The terms "module," "functionality," and "component" as used herein generally represent software, firmware, hardware, or a combination thereof. The features of the techniques described herein are platform-independent, meaning that the techniques may be implemented on a variety of commercial computing platforms having a variety of processors.

Implementations of the described modules and techniques may be stored on or transmitted across some form of computer readable media. The computer-readable media may include a variety of media that can be accessed by the computing device 602. By way of example, and not limitation, computer-readable media may comprise "computer-readable storage media" and "computer-readable signal media".

"computer-readable storage medium" may refer to media and/or devices that enable persistent and/or non-transitory storage of information, as opposed to merely signal transmission, carrier wave, or signal itself. Accordingly, computer-readable storage media refer to non-signal bearing media. The computer-readable storage media include hardware, such as volatile and nonvolatile, removable and non-removable media, and/or storage devices implemented in methods or techniques suitable for storing information, such as computer-readable instructions, data structures, program modules, logic units/circuits, or other data. Examples of computer readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical storage, hard disks, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other storage devices, tangible media, or an article of manufacture suitable for storing the desired information and accessible by a computer.

"computer-readable signal medium" may refer to a signal-bearing medium configured to transmit instructions to the hardware of the computing device 602, such as via a network. Signal media may typically embody computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave, data signal, or other transport mechanism. Signal media also includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, or wireless media such as acoustic, RF, infrared and other wireless media.

As previously described, the hardware unit 610 and the computer-readable medium 606 represent modules, programmable device logic, and/or fixed device logic implemented in hardware that may be utilized in some embodiments to implement at least some aspects of the techniques described herein, such as to execute one or more instructions. The hardware may include components of an integrated circuit or system on a chip, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), Complex Programmable Logic Devices (CPLDs), and other implementations using silicon or other hardware. In this context, the hardware may operate as a processing device to perform program tasks defined by the instructions and/or logic embodied by the hardware, as well as the hardware utilized to store the instructions for execution (e.g., the computer-readable storage media described previously).

Combinations of the foregoing may also be utilized to implement the various techniques described herein. Thus, software, hardware, or executable modules may be implemented as one or more instructions and/or logic embodied on some form of computer-readable storage medium and/or may be implemented by one or more hardware units 610. The computing device 602 may be configured to implement particular instructions and/or functions corresponding to the software and/or hardware modules. Thus, implementations of modules executable by the computing device 602 as software may be implemented at least in part in hardware (e.g., using computer-readable storage media and/or hardware elements 610 of the processing system 604). The instructions and/or functions may be executable/operable by one or more articles of manufacture (e.g., one or more computing devices 602 and/or processing systems 604) to implement the techniques, modules, and examples described herein.

As further illustrated in fig. 6, the exemplary system 600 enables a ubiquitous environment for a seamless user experience when running applications on a Personal Computer (PC), television device, and/or mobile device. When transitioning from one device to the next while utilizing an application, playing a video game, watching a video, etc., the service and the application operate substantially similarly in all three environments for a common user experience.

In the exemplary system 600, multiple devices are interconnected through a central computing device. The central computing device may be local to the plurality of devices or may be remotely located from the plurality of devices. In one embodiment, the central computing device may be a cloud of one or more server computers connected to the plurality of devices through a network, the internet, or other data communication link.

In one embodiment, this interconnect architecture enables functional performance to be delivered across multiple devices in order to provide a common and seamless experience to users of the multiple devices. Each of the multiple devices may have different physical requirements and capabilities, and the central computing device uses a platform that enables the delivery of experiences to the device, both tailored to the device and common to all devices. In one embodiment, a class of target devices is created and experiences are customized for the generic class of devices. The class of devices may be defined by physical characteristics, the type of use, or other common characteristics of the devices.

In various embodiments, the computing device 602 may assume a variety of different configurations, such as for computer 614, mobile 616, television 618, and embedded device 619 uses. Each of these configurations includes devices that may typically have different constructs and capabilities, and thus the computing device 602 may be configured according to one or more of the different device classes. For example, the computing device 602 may be implemented as the computer 614 class of devices that includes personal computers, desktop computers, multi-screen computers, laptop computers, netbooks, and so forth.

The computing device 602 may also be implemented as the mobile 616 class of devices, which includes mobile devices such as mobile phones, portable music players, portable gaming devices, tablets, multi-screen computers, and so on. The computing device 602 may also be implemented as the television 618 class of device, which television 618 class of device includes devices that typically have or are connected to larger screens in casual viewing environments. These devices include televisions, set-top boxes, game consoles, and the like.

The computing device 602 may also be implemented as an embedded system or embedded class of devices 619. Embedded devices are typically designed for specific control functions. As such, embedded devices may typically be dedicated to handling a particular task. The range of embedded devices can be widely used for such things as digital watches, media players, light switches, traffic lights, factory controls, telephone switches, various other types of consumer electronics, GPS receivers, printers, household appliances such as microwave ovens, washing machines, dishwashers, HVAC systems including networked thermostats, home automation devices using wired or wireless networking to control such things as lights, climate, security, audio/visual, monitoring, etc. Other embedded devices may be used in transportation systems, various types of automobiles, medical devices for such things as vital signs monitoring, medical imaging, and the like.

The techniques described herein may be supported by these various configurations of the computing device 602 and are not limited to specific examples of the techniques described herein. This functionality may also be implemented in whole or in part using a distributed system, such as on the "cloud" 620 via platform 622 as described below.

The cloud 620 includes and/or represents a platform 622 for resources 624. The platform 622 abstracts underlying functionality of hardware (e.g., servers) and software resources of the cloud 620. The resources 624 may include applications and/or data that may be utilized when computer processing is executed on a server remote from the computing device 602. Resources 624 may also include services, such as web services, provided over the internet and/or provided over a subscriber network, such as a cellular or Wi-Fi network.

The platform 622 may abstract functions and resources that connect the computing device 602 with other computing devices. The platform 622 may also be used for abstract scaling of resources to provide a corresponding level of scale to encountered needs for the resources 624, which resources 624 are implemented via the platform 622. Thus, in an interconnected device embodiment, implementations of functionality described herein may be distributed throughout the system 600. For example, the functionality may be implemented in part on the computing device 602 and via the platform 622, the platform 622 abstracting the functionality of the cloud 620.

Conclusion

Various embodiments enable a web client to provide web services. In one or more embodiments, a web client is configured to act as a server and can be used for round-trip calls or the like for web services supported by the web client. Such uses may include, by way of example and not limitation, pushing messages to and from the web client. The various techniques may utilize standard protocols and libraries without the need for any custom code or custom plug-ins.

In one or more embodiments, the intermediary server acts as an intermediary through which a persistent connection with the web client is established. The mediating server may then publish the web client to the world using, for example, the presence or address of the web client, such as a web service URL. Other web clients (e.g., browser-based clients) seeking to send messages to the first web client may use the published web service URL to invoke a predefined web service. The calling web client may also register with the same mediating server or a different mediating server and publish its web service URL. The first web client may then use the URL to push messages to the second web client.

Although various embodiments have been described in language specific to structural features and/or methodological acts, it is to be understood that the embodiments defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the various claimed embodiments.

Claims (10)

1. A method, comprising:

generating (502) an HTTP request associated with a web service provided by a web client;

sending (504) the HTTP request to an intermediary server implementing a tunnel service;

receiving (528) an HTTP response associated with the HTTP request from the tunnel service; and

processing (530) the HTTP response, the HTTP response including data and information associated with a result of execution of a web service by the web client.

2. The method of claim 1, wherein the HTTP request includes a tunnel endpoint associated with the intermediary server, a tunnel ID associated with the web client, and a load that identifies the web service and includes data or information to be processed by the web service.

3. The method of claim 1, wherein the generating, sending, receiving, and processing are performed by a caller comprising a client computing device.

4. The method of claim 1, wherein the generating, sending, receiving, and processing are performed by a caller comprising a browser.

5. The method of claim 1, wherein the generating, sending, receiving, and processing are performed by a caller comprising a browser, and the web client comprises another browser.

6. The method of claim 1, wherein the generating, sending, receiving, and processing are performed to implement a browser-based chat between two web browsers.

7. One or more computer-readable storage media embodying computer-readable instructions that, when executed, implement a method comprising:

receiving (506), on a tunnel service, an HTTP request from a caller, the HTTP request prepared for a web client supporting a web service;

serializing (510) the HTTP request;

encapsulating (512) the serialized HTTP request in a request structure;

sending (514) the encapsulated request structure to the web client;

receiving (524), on the tunnel service, an encapsulated response structure from the web client, the encapsulated response structure comprising data or information associated with execution of the web service; and

processing (526) the encapsulated response structure to provide an HTTP response and sending the HTTP response to the caller, the HTTP response including the data or information.

8. The one or more computer-readable storage media of claim 7, wherein the encapsulating is performed by encapsulating the serialized HTTP request in JavaScript Object Notification.

9. The one or more computer-readable storage media of claim 7, wherein the caller comprises a browser.

10. The one or more computer-readable storage media of claim 7, wherein neither the caller nor the web client comprise a browser.