Did you ever thought of an ESB that could do live configuration update? The first answer for this would be "Haah.. yeah I do. I know many systems which support that". Think twice about what they offer, most of the time they offer hot deployment or hot update of the configuration artifacts or the configuration versioning.
Think of what will happen to the messages in-flight if you do not put the server into a mode which does not accept any more messages and do the configuration update, after you processed all the accepted messages. You will consistently be using the same configuration for all the messages, if you do the above. The catch with that approach is that it introduces a downtime, but it guarantees the correctness. If you do not follow this approach, ESB is at an unknown state from the messages point of view, as the message will see different configurations through its life-cycle.
"Now, the world is evolving, and the technology should too.. So do you want to stick to that same technique?". We at adroitlogic asked this question from our selves. I must mention hear that the original thought actually was initiated by a smart enterprise user of the product. We found that, a good architecture and design would allow us to do the configuration update without any downtime yet guaranteeing the absolute correctness.
The next task was to see if we have the right design to implement this on our ESB which has the identifier UltraESB, and we found we do have the just right design for that, and we implemented that.
So with UltraESB 1.6.0, the latest release which went live today contains this feature and you can try it by downloading the release from adroitlogic downloads page.
The implementation guarantees that the updating configuration is prepared as a new configuration and at the point it is available, it is used to dispatch the new messages, while the old configuration will be used to process any accepted messages before that point. The logic is quite simple but implementation could be really hard if not, impossible on an ESB which doesn't think of this from the design itself. This again emphasises that the UltraESB is the future ESB.
With that I would like to introduce the new release of the UltraESB which has the following enhancements and features in addition to this.
![]()
Think of what will happen to the messages in-flight if you do not put the server into a mode which does not accept any more messages and do the configuration update, after you processed all the accepted messages. You will consistently be using the same configuration for all the messages, if you do the above. The catch with that approach is that it introduces a downtime, but it guarantees the correctness. If you do not follow this approach, ESB is at an unknown state from the messages point of view, as the message will see different configurations through its life-cycle.
"Now, the world is evolving, and the technology should too.. So do you want to stick to that same technique?". We at adroitlogic asked this question from our selves. I must mention hear that the original thought actually was initiated by a smart enterprise user of the product. We found that, a good architecture and design would allow us to do the configuration update without any downtime yet guaranteeing the absolute correctness.
The next task was to see if we have the right design to implement this on our ESB which has the identifier UltraESB, and we found we do have the just right design for that, and we implemented that.
So with UltraESB 1.6.0, the latest release which went live today contains this feature and you can try it by downloading the release from adroitlogic downloads page.
The implementation guarantees that the updating configuration is prepared as a new configuration and at the point it is available, it is used to dispatch the new messages, while the old configuration will be used to process any accepted messages before that point. The logic is quite simple but implementation could be really hard if not, impossible on an ESB which doesn't think of this from the design itself. This again emphasises that the UltraESB is the future ESB.
With that I would like to introduce the new release of the UltraESB which has the following enhancements and features in addition to this.
- Failover nodes automatically, in a clustered deployment
- Introduction of the minimal distribution (nearly 6MB)
- Ability for a server to run as another server
- Improved connection debug information
- New theme for the UConsole
- New commands on UTerm, allowing the server management
- Custom password encryption utility
- and many more enhancements...
