Archive:Hermes Subsystems
|
This article is being considered for deletion! Reason: openSUSE is not using Hermes anymore, development has stopped in 2013.. Please do not blank, merge, or move this article, or remove this notice. Refer to this article's discussion page and our deletion policy for more information. |
Hermes Subsystems
There are different subsystems making up the Hermes system. They're described briefly in this chapter.
- the herminator (the API that is notified by e.g. the buildservice to send messages)
- the generator (makes messages from the notifications that hermiantor recieved)
- the worker (sends out the messages as mail or rss or whatsoever)
- starship (a web application to configure at a recipient level which messages to receive in which way)
- the baselibs (well, baselibs)
- the database (the shared storage of all subsystems
Herminator
Directory: herminator
Herminator is the Hermes server offering a http interface to notify or send messages. Herminator was written in perl and uses the CGI::Application framework to implement the http server. Apache is recommended as http server to power Herminator.
Note that at the current stage Herminator *must not* be opened to the internet because that would be a perfect spamming platform: posting messages and notifications is not restricted at the moment. Of course it could be secured by basic auth via apache.
Herminator comes with a rudimentary admin interface that can inform about the latest posted messages and, more important atm, gives information about the http interfaces.
The Generator
Filename: hermesgenerator.pl
The Generator makes real messages out of incoming notifications. Since this process can take some time due to actions to create neccessary data for the notification it was decoupled from the worker and from herminator. That leads to a setup where herminator only stores notifications in a raw format into the database. The herminator is only writing the notification type and the according parameters and their values. This setup is *fast* and does not add dependencies.
Generator then goes through the database and finds new raw notifications that were added by herminator. Generator needs to find out which users are interested in receiving this notification. That depends on the parameter coming along with the notification and might require a time consuming action to decide. In case of the Buildservice for example, it needs to do a HTTP request to another web service. That can take some time. Finally if Generator decides to have some receivers for the notification it creates a real message in the database which is found by the worker.
The Worker
Filename: hermesworker.pl
The Worker is the script that actually sends out messages.
The Worker goes through the database and assembles messages that are ready to be sent. Worker runs in a loop in a console and does not end. Since Worker does the real job of sending mails, creating RSS etc. the worker needs access to the database and needs an environment where it is possible to send mail etc.
Starship
Directory: starship
Starship is a Ruby on Rails web application. It's main purpose is to enable people to maintain their subscriptions to certain notifications. Starship also acts as a Hermes message reading application.
Starship is based on Ruby on Rails. It also needs access to the database.
Hermes Baselibs
Directory: Hermes
The Hermes Baselibs are a set of perl modules. They are used both by Herminator, the Worker and the Generator. Possibly clients that want to send messages or notifications directly and not over http could also use it.
The Database
To store messages, subscriptions to messages, notification types etc. Hermes uses a database. By now, only mysql is supported. The database must be accessible to Herminator, Generator and The Worker. These processes communicate through the database.