The previous approach to Synapse was simple and clean with one object model (SynapseConfiguration) containing the definitions of all active mediation components at runtime. However, Jayathilaka points out that there were several disadvantages in this approach:
- Configuration management becomes a nightmare as the size of the synapse.xml grows. A typical heavy duty configuration would consist of dozens of proxy services, sequences and endpoints. When all these are packed into a single XML file, it becomes difficult to locate a single configuration item quickly.
- With all configuration artifacts stored in a single flat file, it is almost impossible to develop satisfactory tooling support for configuration development and maintenance.
- A team of developers cannot work on configuring a single Synapse instance at the same time.
- Hot deployment is a feature that Synapse has been lacking for years. Being able to hot deploy a proxy service or a sequence into Synapse without having to restart the service bus is a great convenience at development time. But a configuration model based on a single XML file is not at all capable of handling such requirements.
The latest build of Synapse now contains the new multi-XML model as the default. It loads the mediation config from a structured file hierarchy and not from a single XML. This approach mandates that each endpoint, sequence, and proxy service be defined in separate XML files. Here's the directory structure:
Each directory can have more than one XML config file (or none). A Java FileFilter ensures that each file must have the .xml extension to be recognized by Synapse. Jayathilaka explains how this new model has mitigated the prior drawbacks:
- With Synapse configuration broken down into smaller, manageable pieces the whole configuration becomes easier to manage and keep track of. As long as the XML files are named appropriately, it is extremely easy to quickly locate a particular configuration item. We recommend using the artifact names to name the corresponding XML files. For an example the file containing the definition of the FooProxy can be named FooProxy.xml.
- With the multi XML configuration builder, developing powerful and elegant tools for creating pieces of the service bus configuration becomes a trivial task. Also one can use conventional configuration management tools and version controlling systems such as Subversion to store and manage the configuration artifacts.
- A team of developers can now work on configuring Synapse. Each developer in the team can work on his own configuration file or set of files.
- Supporting hot deployment is now feasible. As a matter of fact, Ruwan implemented hot deployment and hot update support for Synapse based on the multi XML configuration builder a few weeks back. This feature is now available in the Synapse trunk and will be available for the next Synapse release.
Jayathilaka says that the Synapse developers have also provided a solution for backwards compatibility when migrating the single XML file. All you have to do is place the single synapse.xml file at the top level alongside registry.xml, and all the mediation components will be loaded to the service bus. The committers are also working on other migration tools.
Jayathilaka has also developed a XML config serializer that can save a SynapseConfiguration object model to a file hierarchy using the Apache Commons IO. There are hot deployment capabilities as well, based on Apache Axis2.