InfoBus Architecture
A tiny Java library for asynchronously communicating service threads
Description
This library allows creation of any number of service threads that can send messages (called here items) to one another asynchronously using the so-called InfoBus architecture. Each service thread has its own communication queue inside InfoBus which is completely transparent to a user.
Service threads sleep all the time while there are no items in their communication queue.
ServiceLauncher class provides functionality to start service threads and to stop them in a number of ways (see API documentation).
ServiceLauncher also provides a failover architecture: if any of the
service threads fail on an uncaught exception, it will restart this
service immediately.
The library is very small (~11 Kb) but it proved to be extremely useful
and is working in several commercial projects and real-time systems.
A note for the developer
Programming under this framework requires certain paradigm shift:
the logic of the application is encapsulated in the items (or messages)
that the service threads send to each other. It means each service
thread sends some pieces of logic to other service threads whom it
regards as the proper context of executing each particular piece of
code.
Let's take as an example the application which will periodically query
a database, construct some kind of message for its client using this
data and finally will send this message to the client through a socket.
We can imagine three service threads here: first service thread will
query the database using an open database connection, second one will
construct messages and third one will keep the communication channel to
the client and send the data to it. We will call them Database service
thread, Message Builder service thread and Socket service thread.
In this case, after getting the database data the Database service
thread will send a communication queue item to the Message Builder
service thread which will encapsulate both the data received from the
database and the logic of the message construction which has to be
executed in the context of the Message Builder service. The latter
service thread will pick this item up from its communication queue and
execute its logic, i.e. it will construct the message using the given
data. Then, the same item's code will send yet another item to the
Socket service thread which will encapsulate both the message that was
constructed and the logic of sending this message to the client via a
socket. The Socket service thread will pick this item up from its
communication queue and, in turn, execute its logic, thus sending the
message to the client.
Finally, the last item will have yet another instruction: it will send
a new item to the Database service notifying it that the database
should be queried again. As you can already guess, this item will
contain the logic necessary for querying the database.
Note, that none of the service threads is ever blocked after sending
the communication queue item to another service thread. Thus, after
sending the data received from the database to the Message Builder
service, the Database service can continue to do whatever it chooses
to: database connection maintenance, logging, or it can just sleep.
Whenever a new request arrives from the Socket service, the Database
service will pick it up from the queue at the time of its own
convenience, but the Socket service does not care either: its job would
be only to drop a message and to continue its own way.
Immediate note is required here: we have just said that the Database
service can do whatever it wants after sending the data to the Message
Builder. But remember again: service thread does not do anything
by itself - it will only perform the work contained in its
communication queue items. So, in order to make the Database service
thread to perform, for example, some logging, yet another party should
drop an item into the Database service's communication queue. It can be
the primary application thread, or better yet it can be a Logging
service thread or a Monitor service thread.
Contact: catpad@gmail.com