Hi Asankha, > 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.. No, I'm not familiar with BEA change control, but that's interesting to here. The really cool thing of WSO2 is the web console which eases the administration job and gives some basic usage monitoring ability. Unfortunately we could not use such administration console on a production or pre production environment if it is that easy to change the current configuration. So one could only use wso2 esb admin console in a development/test environment as a web frontend which helps editing synapse.xml. All statistics views are then more or less useless from my point of view. What do you think? You than can check in synapse.xml in your version control and promote everything via shell scripts.
> 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. Yeah, I understand what you mean. I currently put the repository, the registry as well as the tomcat/conf and webapp/WEB-INF/classes/conf to a shared storage and created symlinks instead. The only thing I had to change was to introduce the option "allowLinking" in tomcat's context.xml. Now every configuration part is separated from the application. Furthermore I changed from the integrated derby db to an external oracle db. > 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 Yeah, all other implementation I would consider to be a bug. ;-) > > 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. Oh, I was not aware of this option. This option sounds interesting. Where can I find more information about how to do this? > 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 Yes, Paul already pointed me to that project. But currently you don't have caching support for external registries, if I got it right. That's why I postponed this a bit. Is the integration of the WSO2 registry also on your agenda for version 1.7? Regards, Eric _______________________________________________ Esb-java-user mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
