UI Bus
UI Bus defines the UI Model and realizes the UI bus on top of the middleware provisions (the RDF-based data representation and the bus model for realizing the needed message brokering mechanisms).
UI bus enables communication between applications (residing in application layer) that need to reach human users (meaning present something to them and/or asking them for some input) and UI handlers (presentation layer). This bus is a call-based bus without any support for synchronized delivery of replies (replies will always be delivered in a new thread). It defines protocols for suspending and resuming dialogs, dynamic adaptation of "rendering" by a previously selected UI handler during the dialog is running, and transfer of responsibility to another UI handler. It accepts registration parameters from UI handlers (when they register to the bus) and allows removing and/or updating of these parameters. It takes the adaption parameters from the Dialog Manager and finds the UI Handler that is most suitable to process a certain UI request.
| Artefact: UI Bus | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.bus.ui {.core/.osgi} |
| Pax Composite bundle | scan-composite:mvn:org.universAAL.middleware/mw.bus.ui.osgi/x.y.0/composite |
| Karaf Feature | - |
| Maven Site | https://universaal.github.io/middleware/middleware.osgi/mw.bus.ui.osgi/index.html |
- Provides (defines) a UI model for the independence between application layer and presentation layer,
- Facilitates the integration of "applications" and UI Handlers possibly running on different nodes in different execution environments while hiding the possible distribution and heterogeneity of the related HW/SW artefacts, and
- Provides a context-aware and personalized brokering mechanism between the presentation and application layers based on the UI model that effectively contributes to the adaptation of presentation to the user situation, capabilities, and preferences.
Applications can use this artefact by implementing UICaller interface since only instances of this class can send UI requests (instances of UIRequest containing dialog's object, addressing user, dialog priority, preferred language and privacy lever). UI Bus adds current adaptation parameters to the call (with the help of Dialog Manager) and then selects appropriate UI Handler (within UI Strategy) to forward a call to.
UI Handlers implement UIHandler interface since only instances of this class can handle UI requests. UI Handlers announce their capabilities when registering with the UI bus.
When UI Caller send abstract representation of user interface to the bus there is no notion of how this will be rendered at the end so in case some additional (not obligatory) "instructions" want to be sent to UI Handler recommendation ontology can be used (see ont.recommendations )
The initial implementation was taken from PERSONA but was upgraded in universAAL.
After the Input and output buses of PERSONA where merged into the UI bus, there where some further adaptations needed (specially bug fixing). This adaptations resulted in a stacked bus strategy where each part of the stack takes care of a specific part of the protocol, some of the stack components can be generalized for other buses:
- Coordination Management: a generalizable stack component. Implements the communications undertaken by peers to decide who is the coordinator, generally by run configuration there is only one coordinator node, that is the one running the Dialog Manager. Improvements:
- Coordinator can resign, enabling restarting of the DM (because it failed, it was updated, ...) without the need to restart all of the uSpace nodes' UI bus
- Coordination negotiation: when 2 or more nodes attempt to cease Coordinator status, only one of them is granted.
- Coordinator loss actions: when the coordinator is lost (because it resigned or because the communication is lost) the bus returns to a safe state waiting for a new coordinator
- Coordinator automatically sends coordinator notification message to joining nodes (avoiding sending a request).
- Registration Management: a generalizable stack component based on the Coordinated nature of the bus. Implements the registration and deregistration of bus members, in this case the UI Handlers need to be registered so they can be assigned UIRequests. Improvements:
- when the coordinator looses communication with a node it automatically assumes all registered components of that node to be deregistered, maintaining bus consistency.
- when a peer looses a coordinator it automatically reschedules a new registration for all of its previously registered components
- Handler Management: the UI specific component that implements the communications between the DM and the handlers. Some properties:
- improved cut message, cut can no be without data response (needed for extreme cases)
- when coordinator looses connection with handlers it automatically re assigns the lost requests in the process
- when a peer looses connection with coordinator, handlers are notified to cut all dialogs
- Caller Management: the UI specific component that implements the communications between the DM and the UI Callers.
- when the coordinator instance detects a node leaving the uSpace, it automatically aborts all of the pending UI Requests
- when a peer detects the coordinator is lost it automatically notifies all of its callers that the dialog has been aborted.