HTTP Service Multiplexer for Cross-Platform Service Access
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing communication systems across computer networks, such as RPC systems, are complex, proprietary, and difficult to manage across different languages, frameworks, and operating systems, limiting their usefulness in turning desktop applications into web-aware applications.
Innovation Solution
A HyperText Transfer Protocol (HTTP) service multiplexer (HSM) that provides a single entry point for accessing multiple services by using a recognizable Uniform Resource Identifier (URI), allowing services to register, discover, launch, and redirect requests using HTTP, enabling access to both local and remote services.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If RPC systems (COM, CORBA, D-Bus, Gconf) are used for inter-application communication, then service localization and binding are achieved, but system complexity increases and cross-language/framework/OS adaptability decreases
Solution Approach 1:
The patent introduces an HTTP Service Multiplexer as an intermediary layer between clients and services. This multiplexer receives HTTP requests, resolves service URIs to actual service locations, and forwards requests to the appropriate services. By centralizing this mediation function, the system eliminates the need for clients to directly manage complex RPC binding mechanisms, thereby simplifying service access while maintaining underlying system complexity in a centralized manner.
Solution Approach 2:
The patent makes HTTP the universal communication protocol for service interaction, replacing multiple proprietary protocols (COM, CORBA, D-Bus, Gconf). HTTP's universal support across languages, frameworks, and operating systems enables a single protocol to handle all service communication needs. The multiplexer leverages HTTP's existing infrastructure (URLs, request-response cycles, standard libraries) to provide service localization, binding, and invocation functions that previously required language-specific RPC frameworks.
2Adaptability or versatility
If proprietary protocols (CORBA, COM, D-Bus, Gconf) are used, then service binding and localization are achieved, but cross-platform and cross-language adaptability decreases
Solution Approach 1:
The patent changes the fundamental parameter of the communication protocol from proprietary binary interfaces (COM, CORBA) to standardized HTTP text-based protocols. This parameter change enables the same communication mechanism to work across all languages, frameworks, and operating systems without requiring language-specific bindings or configurations. The HTTP protocol's standardization means that any client with basic HTTP support can interact with services, eliminating the need for complex protocol implementations in each language runtime.
3Reliability
If manual binding into libraries or frameworks is required for RPC APIs, then service communication is established, but ease of service discovery and registration decreases
Solution Approach 1:
The patent implements self-service mechanisms where services automatically register themselves with the HTTP Service Multiplexer by publishing their locations through standard HTTP channels. Services don't require manual configuration or binding by developers; they simply make themselves available via HTTP, and the multiplexer automatically discovers and routes requests to them. This self-registration approach maintains communication reliability through proper service location tracking while dramatically simplifying service deployment and discovery.
Data Source
AI summary
A system and method for registering one or more services at a location where clients can access the services both locally and remotely is provided. A HyperText Transfer Protocol (HTTP) service multiplexer (HSM) may be accessed at a recognizable location, which may be any suitable location or resource that a client can locate on a local system. The HSM may make a plurality of services available at the recognizable location by binding the location (e.g., a Uniform Resource Identifier (URI)) to URLs or other resources associated with the services. In this manner, the HSM functions similarly to a domain name service, as HTTP redirections can be issued to enable a single well-known resource to be used for accessing the plurality of registered services.