Asynchronous Channel Bus Bridge for UI Decoupling
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Building integrated user interfaces (UIs) for distributed systems is challenging due to the difficulty in sourcing, delivering, and sharing multiple streams of real-time data across various layers of middleware, leading to tightly coupled services and modularity issues, especially in large applications like vSphere Webclient.
Innovation Solution
The implementation of a bridge and an asynchronous channel-based bus (Bifröst) enables UI-to-UI, Service-to-UI, and UI-to-Service asynchronous communication, allowing dynamic channel creation and message broadcasting, decoupling services and views, and using STOMP and ReactiveX for seamless communication across different technologies.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Speed
If real-time data communication is implemented across distributed systems, then data freshness and responsiveness are improved, but system complexity and coupling increase
Solution Approach 1:
The system segments data communication into independent channels that can be created, managed, and destroyed dynamically. Each channel represents a discrete communication path between UI components, services, or views, allowing the system to maintain real-time data flow while avoiding monolithic complexity. Channels can be selectively activated based on specific data needs rather than maintaining all possible connections continuously.
Solution Approach 2:
The patent introduces an intermediary channel management layer that sits between distributed system components. This mediator handles channel creation, message routing, and data distribution automatically, shielding individual components from the complexity of direct peer-to-peer connections. The intermediary abstracts the communication infrastructure, allowing components to subscribe to needed data channels without managing the underlying connection complexity.
2Loss of information
If multiple data streams are shared across UI layers, then real-time visibility is improved, but service coupling increases
Solution Approach 1:
The channel infrastructure is designed to be dynamic rather than static. Channels can be created on-demand when specific data streams need to be shared, and destroyed when no longer needed. Subscriptions to channels can be added or removed independently, allowing UI components to receive only the specific data streams they require at any given time. This dynamic approach ensures complete data visibility for subscribed components while maintaining loose coupling, as components interact through standardized channel interfaces rather than direct dependencies.
3Productivity
If asynchronous communication is implemented, then system responsiveness is improved, but implementation complexity increases
Solution Approach 1:
The asynchronous channel system implements self-service mechanisms where channels automatically manage their own message queues, delivery timing, and acknowledgment workflows. Once a channel is created and components subscribe, the infrastructure handles asynchronous message routing, delivery guarantees, and error handling without requiring manual intervention or complex coordination logic in individual components. This self-managing approach enables asynchronous communication while keeping implementation complexity localized to the channel infrastructure rather than propagating throughout the entire system.
Data Source
AI summary
In a system and method for providing UI-to-UI asynchronous communication, a bridge is coupled to an asynchronous channel based bus that has at least one Galactic channel. The bridge receives each message on the Galactic channel, and converts each message from a channel message format used by the Galactic channel to a common message format. The bridge utilizes a socket to broadcast each converted message to, and receive messages from, the one or more other bridges. The bridge determines that a message received from the one or more other bridges is destined for the Galactic channel. The bridge converts the message into the channel message format used by the Galactic channel. The bridge distributes the converted message to the at least one Galactic channel.