Yes, although completely reloading the root configuration will affect all services hosted on the instance, you can still manage most of the elements via JMX without causing downtime. For example, individual transports maybe stopped, paused, resumed etc without affecting other services that are not directly dependent on that transport. e.g. The http transports maybe shutdown and restartd, while file, JMS and email based services runs smoothly.

We fully believe that JMX is the way for management of a runtime instance, and thus have invested a lot of time to develop JMX support in the core itself. The built-in support uses newer MXBeans instead of MBeans. UTerm command line client is a JMX client that is able to interact with an UltraESB instance interactively or from within a script. The cluster management mechanism again uses the same JMX management beans to perform cluster wide operations.

No matter how Proxy Services, Sequences and Endpoints were deployed (i.e. via the root configuration or deployment units), they can be readily managed via JMX at runtime. Hence one could stop a running sequence, change its Java code,  or start it again without shutting down the server. Similarly, one may stop a Proxy service from serving clients. An endpoint maybe put into maintenance, or started, and a suspended Address made alive again, or a new address added to an existing endpoint altogether, via JMX and the web based console.

We also suggest that the conf directory containing the configuration be checked into a version control system or shared across within instances in a cluster via a shared mount, so that configurations can be easily managed across multiple nodes. Use of a version control system has the added advantage of rolling back a configuration anytime, and to allow a QA team to verify updates on a staging environment before being applied to production system, and to tag changes being deployed to a large cluster.

If all your Proxy services, Endpoints and Sequences are developed and rolled out together, it would be easier to keep the configuration in just two files and the default deployment unit configuration.

Thus you will use the "conf/ultra-root.xml" to define the transports and other fairly static elements that are specific to the core UltraESB, and the "conf/ultra-custom.xml" to define custom beans and other customizations and Spring beans. You will then use the "conf/deployments/default/ultra-unit.xml" (default deployment unit configuration) to define Proxy Services, Endpoints, Sequences and any other custom Spring beans used by your services. To keep a large configuration in a manageable state, you may import other fragments from the "ultra-unit.xml" using the Spring "<import>" element. However, all these will be considered as parts of one single deployment unit (default in our case) which could be undeployed or redeployed. If you would like to be able to load another configuration - say a deployment unit named test1 separately, then you can include it as a separate deployment unit. If you are not familiar with the default configuration files conf/ultra-root.xml, conf/ultra-custom.xml and default deployment unit, please spend a few minutes to go through the documented defaults.

e.g. Assume you are using the default approach to define services to support reloadability. You could still use Spring "imports" from your ultra-unit.xml to import services defined in "internal-services.xml" and "external-services.xml" as shown in the snippet below within the default deployment unit. However, you cannot undeploy just the services of the "internal-servicex.xml" for example, as its statically imported from the ultra-unit.xml of the default deployment unit. In this example, the services are split into internal-services.xml and external-services.xml just to ease the development and management of the services - and not for hot deployment or update.

Root (Boot) Configuration

Deployment Unit

To support hot deployment, the above configuration maybe loaded as follows:

Root (Boot) Configuration

Deployment Units

When deployed as three separate deployment units, the deployment units "default", "internal-services", and "external-services" can be loaded, unloaded and reloaded independently of each other as desired at runtime. However, as usual the root configuration cannot be changed without a restart. With the above configuration, if internal-service-2 requires some changes, to its sequences and endpoints, one can unload the complete "internal-services" deployment unit (also unload and refresh internal-service-1 and 2 etc) and reload an updated configuration again from disk.

Refer to the UTerm documentation for resources on using the Runtime Configuration Management aspects and also connect via JMX (i.e. jconsole) to see the core management APIs that facilitates the run-time management behavior.