In jPOS versions earlier than 1.5.0, the +main+ for the jPOS application
was a component called **QSP**. 

[NOTE]
======
The term **QSP** comes after the hamradio Q-signal codes and
it means "Relay message for free". Because jPOS was used to
'relay messages', and it is free software, in the deep nerdy
mind of the author, the term **QSP** made sense
footnote:[ http://en.wikipedia.org/wiki/Q_code ].

That's one of the reasons you'll see so many _Q_s in the code
(QServer, QMUX, Q2 ...).
======

After deploying QSP in several mission-critical applications, we found that
including all the components in a single [huge] XML configuration file
was not a good idea.

*  Although several QSP components supported some limited ReConfiguration, 
   many others didn't. As a result, major changes usually involved restarting 
   the application (a very costly operation in a 24/7 system). 

*  If for some reason, the changes involved went beyond just tweaking a 
   configuration file and required additional changes in a supporting 
   jar file, the application had to be restarted (QSP didn't support 
   dynamic classloading). 

*  Having a single big configuration file has proven to be error-prone. 
   Although initially intended to be accessible to system operators, 
   changing QSP files on critical systems became an  _art_ reserved for 
   experienced operators.

Therefore, we've decided to use a simpler approach: A new container (called Q2,
short for QSP version 2) with a file per component and a very simple lifecycle
to ease the implementation of such components, called *QBeans* (Q2 Beans). 

[NOTE]
====
We use the terms *QBeans*
and *Q2 service* interchangeable.
====

QBeans are MBeans (see JMX specs) that implement the Q2's lifecycle
(init/start/stop/destroy) set of operations. Q2 takes care of 
registering them with the system's MBeanServer. 


