JEM is hosted at Sourceforge. Written by Chris Bitmead.
The JEM application acts as a warehouse for incoming messages which are subsequently processed. Currently these messages are email based but there is no reason other types of messages could not be supported if it became necessary.
When an email is received it is stored in the MSG table in the database. The email address the email was received on, determines which QUEUE the message is placed in. The QUEUE it is in determines which HANDLER is used to process it.
Processing consists of calling a HANDLER "plug-in" written in Java, otherwise known as a "jemlet". The jemlet has free reign, but it frequently consists of calling other jemlets to achieve its task. Built in jemlets include ones to:
Each jemlet is passed a set of CONFIG parameters that are based on which QUEUE the message is in. In turn, the allowed CONFIG parameters depends on which HANDLER can process this QUEUE and which PARAMETERs this HANDLER allows.
Because jemlets can call other jemlets, we have the concept of ordinary and "main" jemlets. A main jemlet is called directly by JEM, and is specified as a QUEUE's handler. Other jemlets are called as sub-procedures from main jemlets.
There is no difference between main jemlets and ordinary jemlets as far as gem proper is concerned. However the gem configuration screens group all the configuration parameters together under the banner of the main handler.
Once a message has been processed it is marked in the database as either successfully or unsucessfully processed along with any error messages.
When deployed on an NT box, gem runs as an NT service. It is designed to run 24x7 and recover from any errors.
JEM also contains a set of web servet administration pages for configuring Jemlets. Jemlets are passed a number of configuration parameters at runtime, and these can be configured on a per-queue basis using the front-end. The web servlets are a bit of a mess (I didn't write them :-). They only seem to work with Internet Explorer and the code is not nice. Don't judge the rest of the code by that!
Most of the documentation is within the javadoc. In particular there are global overview.html files as well as package.html files which summarise the system.