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

Reply via email to