|
|
DataBus Documentation
|
Introduction
Features
DataBus is a Java class library for developing highly dynamic, universal and modular applications. It allows
software modules (called components) to talk to each other, exchanging data or sending events, without knowing anything from each other.
They only thing these components needs to know is the type of data to exchange (the event type). For each event, there can be
an unlimited number of consumers and producers. Consumers can also generate new events, acting as producers (such
components are called filters).
Think of the DataBus as a number of whiteboards (one board for each type of event), where all producers can write down their data, and the
consumers can read from there (and write their responses or new data down).
- unlimited number of event types, producers and consumers
- event handling is done asynchronously (the producers do not wait for the consumers to catch up)
- each consumer has its own event handler queue, decoupling its event handling method from the bus
- recevining event order is the same for all consumers
- event receving is decoupled from the consumerss event handling
- it is possible to send events synchronously, reading a response object
- the DataBus configuration is read from a single configuration file
- each component can have a descriptor file, containing
- name of the component
- the class name of the component
- additional information
- information about the configuration of the component
Why use DataBus?
DataBus allows to build applications in a higly modular fashion. Because the individual components communicate with each other only through the
events, they are independant of each other. They can be easily exchanged, without any other component noticing. This can even
be done during runtime.
Communcation via events also requires the careful definition of the interfaces between the components. This will lead to higher code quality,
because it requires more thinking before coding. It also allows for easier testing, because the interfaces are really simple.
Using events more communication makes the components simpler - they just dont't need to know much about other components.
APD as an example
The APD program contains the following components:
- MP3 player (MADLibPlayerService or MPG123PlayerService)
- playlist handler (PlayListManager)
- LIRC remote control handler (LircControlService)
- LCDProc status consumer (LcdProcPlayStatusWriter)
- play status handler (QueueService)
These components use the following events:
- PlayStatusEvent
- PlayerEvent
playing MP3s
The registered MP3 playing component receives Player events. The play status handler
sends a 'PLAY' command after the startup, conbtaining the first file to be played. The MP3 player then
sends regularly the curent play status, which is used by the play status handler
to determine when a song is finished. Then it sends a new 'PLAY' command, which contains the next file.
showing the curent status
The current play status send by the MP3 player is also received by the LCDProc status consumer. When
the current song changes, the new title and artist are displayed in the LCD. Additionally, each second the
time left for playing the current song is updated.
remote control
The LIRC remote control handler just takes the commands from the LIRC daemon, and sends the corresponding
play commands.
other modules
Instead of using the LIRC service to control APD with a remote control, there are two additional modules:
- LCDProcControlService, which interprets keypresses from LCDProc as play command
- RemoteControlService, shich allows the control with a remote AWT client, connect via TCP
Both modules simply send PlayerEvents. So the MP3 player just doesn't need to know about these modules, as it just cares about events.
|
|