- Updates to a graphical configuration is sometimes difficult
- Graphical models are not easily unit testable
- How do you debug graphical models?
- Graphical models cannot be version controlled easily, or backed-up and restored for production system changes quickly
- Graphical models does not allow easily inserted and usable comments
- Graphical models are vendor specific “language”s you need to learn from the start
- Text based configurations support – visual code review and auditing of changes
- Real world management of graphical configurations are more difficult
- Graphical tools are sometimes limited on extensibility
- Vendors ship some IDE based “Studio” which may not be user friendly to some
Now if you'd want to know what I am talking about, do a Google search for "ESB (Studio OR IDE)" and look at the results of the Image search.. You will find plenty from some ESB vendors.
In-contrast, an UltraESB configuration is held in files
In contrast, The UltraESB configurations are held in one or more configuration files. These files are human readable and understandable, and are Spring framework configuration files already familiar to many developers. Typically a configuration is split into two files namely ultra-root.xml to define the more
static aspects such as transports, JMX configuration etc, while the ultra-dynamic.xml defines the more dynamic aspects such as services, mediation sequences and endpoints of the business scenario. Where required the dynamic components can be split into any number of sub configurations.
Changes to the dynamic aspects does not require a server re-start, and can be applied to live production servers without disrupting existing or in-flight messages, and the UltraESB guarantees that a message flow will only use the configuration version available at the start of its processing. This makes the
configuration updates both safe and efficient, and is much more than whats typically offered as 'hot-deployment' by some products.
Holding the configuration in a concise XML document makes it easy to quickly:
– Understand the flow
– Take a backups
– Track changes across versions
– Add new services, change/remove/disable or co
Yet, still the UltraESB allows auto-completion and step-through debugging with your preferred IDE - See this 5 minute screen cast!
Comparison with Graphical Drag-and-Drop tools
The graphical tools will present themselves as “easy to use for any beginner” - which I do not contradict. However is its usefulness also limited when you are not a beginner anymore?
When you move into real world usage you will quickly understand that:
- Updates to a configuration (e.g. disabling an address from a load balance endpoint in a production system) will require a developer to open up a heavy weight IDE Studio, open up the latest version of the project, make the necessary change, build a new deployable binary artifact and then deploy this to a production server.
- When this needs to be done quickly for emergency changes etc, it would be difficult for a system administrator, or just "any" developer to do – the availability of a configured developer environment would be needed to effectively use the graphical Studios.
- Furthermore, a binary deployable artifact generated by a developer would be difficult to verify for correctness. It will also depend on the developers local user settings and local properties files etc. used at the build time, and may not be the ideal artifact with the correct settings for quick production deployments.
- As an exercise: Ask any other ESB vendor how they suggest that you perform unit testing, and automated end-to-end configuration testing. Try out their suggestions by yourself, and verify how effectively they will work in your real world use
- As all UltraESB configurations are simple and human readable and understandable XML files, changes can be checked into any version control system such as CVS, SVN, Mercurial, GIT etc, and tagged after development for QA testing, staging and production deployments. This allows one to quickly undo changes to revert back to a previous configuration level within a matter of seconds.
- Here is a sample diff for you to verify which shows some changes over time on a UltraESB configuration. Our large enterprise users integrate the ESB configuration into version control systems for better management, visibility/openness and control of changes and auditing.
- The UltraESB conf/ directory is typically checked into a version control system. When developers make changes they can commit locally (i.e. with Mercurial etc) and when ready push changes for QA / integration testing. Once changes are accepted for deployment, they would then be tagged by QA. The operations teams would map the source repository to the conf/ directory of the live servers, and to deploy changes, they would pull changes from the source repository. Depending on the change, a simple UTerm “cau – Configuration Add or Update” command or a graceful restart (e.g. if third party JARs etc are required for a new change) can then be initiated. Before updates, the configuration can be easily backed up, and if something goes wrong, the configuration can just as be easily reverted to the previous tag or restored configuration file which was backed up before.
- As the UltraESB configuration is in Java, you can use concepts you already know such as:
- Exception handling with a try-catch-finally
- Easily refer to all possibilities of the API using Javadocs
- Easily calling external libraries from within the in-line code you are writing etc. (Compare to calling an external Java library from one of the graphical models)
- Furthermore, some tools may not allow you flexibility. As an example, consider you are getting a message header “XXX-NNN-YYY” and you want conditionally perform a routing just looking at the “NNN” part. If your graphical editor provides a “if-then-else” construct, most definitely if will allow you to check if this complete header is equal to something or not. (See example screenshot). However, your mind will tell you that you just need to perform a substring(4,7) on the header and do the comparison. This is easily possible with the UltraESB configuration, where-as fixed UI “components” of most vendors would not allow you to go deeper than the beginner level use.
- With the UltraESB, you are at the actual execution code level. You can set real breakpoints, evaluate variables, and step-through debug as you've always known with your favorite IDE. Ofcourse, you can start the ~35 MB UltraESB within the IDE in its full glory, so you do not end-up having to remotely debug a monster server running with elsewhere.