A deployment unit is a directory or a zip/uda (ultra deployment archive) archive containing a file named ultra-unit.xml on its root. Deployment units are placed in the conf/deployments directory of the UltraESB installation. Deployment units can be provisioned/added, unloaded or updated at runtime. Apart from the mandatory ultra-unit.xml configuration file which consists of proxy services, sequences and endpoints a deployment unit can optionally have mediation classes, third party or custom libraries and any resources used by the deployment unit artifacts such as WSDL, WADL, schemas or XSLTs etc.

The structure of a typical deployment unit is as follows;

Deployment unit file structure

conf/deployments/

    default/         ultra-unit.xml         classes/         lib/         src/         resources/

Name of the deployment unit is determined by the name of the directory or archive (without extension). So the above example directory structure creates a deployment unit named "default".

Artifact configurations such as sequences and endpoints are locally scoped within the deployment units by default. This is to make sure a given deployment unit is self contained and can be easily updated/reloaded at runtime, without an external consumer seeing a service down time.

Any libraries or classes placed into the deployment units lib or classes directory is also loaded at the local scope of the deployment unit. This allows one to use 2 different versions of the same library to be used within 2 deployment units, or even 2 deployment unit versions of the same UltraESB server runtime.

The ability to do hot updates of a deployment unit enables the administrators to deploy/update the configurations without worrying about the availability of not just other deployment units but also the deployment unit being updated.

While the update is in-progress the messages received to the proxy service of that deployment unit are accepted and processed by the already existing configuration. The update actually is building a new version of the deployment unit configuration, and the already existing configuration is maintained as it is. Once the configuration preparation is done, the newly built configuration is attached to the deployment unit, and the previous configuration is marked as outdated, upon which any new message will be dispatched to the new proxy services defined in the new configuration.

Even after this point, the previous configuration is maintained in-tact, as the already accepted messages by the proxy services of that previous configuration will transactionally use the same configuration, even though any new message is using the new version. This guarantees the operation and mediation correctness, while making sure the system is 100% available while doing an update.