Hi Eric
If an administrator logs in to the administration console, everything is
read-only by default. If he would like to change any option, he had to
open a new change package. He can then change as many options as he
like. Every change will be part of the opened change package, but not
applied to any running instance of the esb. If the administrator decides
to activate a change package, a new configuration version will be
created and all changes will be applied. In some kind of history view
the admin could change to any of the former version and activate that.
What do others think about this suggestion?
You sound familiar with the BEA change control stuff :-) ?.. this is
exactly how they facilitate this - except for the rollback feature
unless there is an error..
Let me explain how we suggested the solution to this exact problem to
one company who deploys this into production. This reply will be
available publicly as an article shortly..
Although the specific client wanted even the core ESB engine to be
checked into version control, one can easily version control the
registry and the conf directory alone - e.g. into SVN. This way any
changes can be tested by developers and checked into SVN etc, and QA can
fetch it and validate and operations can shutdown or put the servers
into maintenance mode, and do an update from SVN and restart. If
something goes wrong, changes can be reverted back as well. As the core
ESB distribution is around 55M, checking in the complete distribution
will not be a problem at all either.
Maybe one could also consider between two modes of the administration
application - development (current behaviour) and production (my
suggestion) and switch between them.
I must state here that any changes we currently apply to the
configuration are atomic for a message... i.e. a message will not be
processed with configuration A during its inSequence etc, and an updated
configuration say B on its outSequence if the admin changed the config
during this time.. In this case the reply will continue through the same
configuration A and B will apply only for new messages
Currently I only see one problem. What should be considered to be the
configuration? Only synapse.xml? Probably not. What about
registry/repository?
Yes, basically the conf directory and the registry.. BTW, one can hold
the configuration totally in the registry as well.. and soon we will be
integrating closely with the new WSO2 Registry
(http://wso2.org/projects/registry) which has support for versioning,
rating and social registry stuff too :-) .. you should check it out if
you are interested in that space
asankha
_______________________________________________
Esb-java-user mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user