Communication Hub for IT Services via Event Bridge
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current systems face challenges in flexible communication between front-end and back-end applications, requiring frequent updates to back-end APIs and being inflexible to accommodate various user devices, leading to bottlenecks and inefficient handling of device-specific requirements.
Innovation Solution
A communication hub that includes a message broker, event bridge with a rules engine, and query application, which processes requests based on business rules and opt-in parameters, enabling adaptable and device-agnostic communication by queuing messages, validating authorization, and sending tailored responses across multiple devices.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If synchronous point-to-point communication is used between front-end and back-end applications, then direct and immediate data exchange is achieved, but the system becomes inflexible and requires frequent updates to back-end APIs to accommodate various user devices
Solution Approach 1:
The patent introduces an event bridge as an intermediary component between front-end applications and back-end services. This event bridge receives events from front-end apps, processes them according to business rules, and generates appropriate back-end API calls. This mediator layer decouples the front-end from the back-end, allowing the system to adapt to different user devices without requiring frequent updates to back-end APIs, as the event bridge handles the translation and adaptation logic
Solution Approach 2:
The system is segmented into distinct functional layers: front-end applications, event bridge (with event processing and rules engine), and back-end services. This segmentation allows each component to be independently developed, maintained, and updated. The event bridge specifically handles device-specific variations, isolating the complexity of device adaptation from the core back-end logic and reducing the need for frequent back-end API updates
2Productivity
If the system processes requests synchronously, then immediate response is provided, but bottlenecks occur and efficiency decreases when handling multiple device-specific requirements
Solution Approach 1:
The system implements asynchronous periodic action by publishing events to a message queue and processing them at appropriate intervals. Instead of blocking the front-end application waiting for back-end responses, events are queued and processed periodically by the event bridge. This allows multiple device-specific requirements to be handled efficiently without creating bottlenecks, as processing occurs in a non-blocking, periodic manner rather than synchronous sequential execution
3Adaptability or versatility
If back-end APIs are updated frequently to support new devices, then device compatibility is improved, but system stability and maintenance become problematic
Solution Approach 1:
The event bridge serves as a stable intermediary layer that absorbs the variability of device requirements. By implementing device compatibility logic in the event bridge rather than in back-end APIs, the system maintains stable back-end services while still achieving broad device compatibility. The event bridge can be updated independently to support new devices without affecting the stability of the core back-end system
Solution Approach 2:
The event bridge is designed as a universal component that handles multiple types of events from various user devices through a single interface. It provides multi-functionality by processing different event types (button presses, form submissions, navigation) and routing them to appropriate back-end services. This universal approach improves device compatibility without requiring multiple specialized back-end APIs, thereby maintaining system stability
Data Source
AI summary
A method of multilayer communication between a front-end application and at least one back-end includes receiving a message by a communication message broker that executes on a computer system from the front-end application, sending information of the message to an event bridge that executes on a computer system, parsing the information by the event bridge to determine at least one request, prompting a rules database by the event bridge to look up a rule, identifying the rule that applies to the at least one request by the rules database, processing the at least one request by the event bridge in response to the rule, sending the at least one processed request from the event bridge to a query application that executes on a computer system, and resolving at least one query by the query application to send at least one call to at least one back-end application.