ServiceMix has two deployment models:
- you use the JBI compliant way, which is you install component at run-time and deploy service assemblies into them
- you use a static configuration (servicemix.xml) file. This mainly happens when you will run a single application for testing purposes, or when you embed ServiceMix in a web application for example.
Components in ServiceMix comes in two different flavours:
- standard JBI compliant components (servicemix-jms, servicemix-http, servicemix-jsr181, ...) that can accept ServiceMix unit deployments and are in the JBI spec spirit (they are containers). These components are implemented using the servicemix-common module and are packaged as JBI components (with a jbi.xml descriptor file in the zip file)
- lightweight components (or pojo components) are JBI components (they implement the needed interfaces) but can not be deployed at runtime (no packaging) and do not support service unit deployments. These components usually inherit the ComponentSupport class (maybe indirectly) and are mainly in the servicemix-components module.
Lightweight components have been designed to be used in a static configuration file (second deployment model) whereas standard components have been designed to be used in a JBI compliant container (first deployment model).
As these two different deployment models seems a bit incompatible, there are two different ways to bridge both component worlds:
- you can deploy lightweight components at runtime on the servicemix-lwcontainer (lightweight container) JBI component
- you can configure standard components to be used in a static servicemix.xml configuration file
Now you can imagine some edge case where you would deploy standard jbi components configured statically in the lightweight container ... 