Serverless Bridge for Unified Cloud Service Access
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Users face difficulties in accessing multiple cloud-based services through integrated application suites without the need for individual add-ins for each service, as some services may not be directly accessible by the client device.
Innovation Solution
The system enables access to additional services by launching local instances of service applications on the client device, which communicate through a temporary storage location, allowing data from a second server to be retrieved and made available to the integrated application suite without direct access to the second server.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If individual add-ins are created for each service, then direct access to each service is enabled, but the complexity of the integrated application suite increases significantly
Solution Approach 1:
The patent implements a universal bridge mechanism that can handle multiple different services through a single integrated interface. The bridge acts as a multi-functional component that dynamically routes requests to appropriate local server instances, eliminating the need for separate add-ins for each service while maintaining service-specific functionality.
Solution Approach 2:
The patent introduces a bridge as an intermediary component between the integrated application suite and multiple services. This mediator translates unified interface requests into service-specific communications, allowing the system to access numerous services without requiring individual add-ins for each one, thus reducing complexity while preserving accessibility.
2Ease of operation
If a unified interface is provided for multiple services, then ease of use is improved, but the ability to directly access all services is reduced
Solution Approach 1:
The bridge serves as a smart intermediary that maintains service access versatility while enabling unified interface management. It dynamically determines whether to handle requests directly or route them to appropriate local server instances, preserving adaptability to different services while providing simplified user interaction through a single interface.
Solution Approach 2:
The system dynamically adapts its behavior based on the type of service being accessed. The bridge can switch between handling requests directly and routing them to local server instances, allowing the unified interface to maintain versatility across different service types while keeping the user experience simple and consistent.
3Adaptability or versatility
If local server instances are launched for each service, then service access is enabled, but the number of running processes increases
Solution Approach 1:
The patent segments the service access architecture into two layers: a single bridge process that manages all service communications and multiple optional local server instances that handle specific services. This segmentation allows the system to launch only the necessary local server instances based on user needs, rather than running all possible service processes simultaneously, thus reducing the overall number of active processes while maintaining service accessibility.
Solution Approach 2:
The bridge is designed as a universal process that can handle multiple different service types through a single instance. Rather than requiring separate dedicated processes for each service, the bridge provides multi-functional capability to manage diverse service communications, reducing the total process count while maintaining versatility.
Data Source
AI summary
A cloud-based, integrated business application suite includes an add-in that enables access from a client device to a first server, but not a second server. A user accesses the first server through an interface of the integrated suite to request a webpage which launches a first local instance of a service application. The first local instance of the service application sets up a local storage location and provides this location to a URL that is used to launch a webpage that is a client of the second server. A second local instance of the service application which is aware of the storage location is launched and this instance stores data requested from the second server in the identified local storage location. The stored information is read from the storage location by the first instance of the service application and is provided to the integrated application suite.