Hi Asankha, > > is there a way to split the synapse configuration into several files? > Our plan is to include some generated fragments. Relative paths should be > used. > > > Are you suggesting, or looking for a way, to dynamically discover the > full configuration to be applied, looking at a bunch of fragments found > at some location? Yes, exactly.
> We should be able to improve this area without affecting the core engine > easily, and we welcome your suggestions for improvement.. Could you > share a sample configuration you are looking for with a bunch of > fragments? I'll try to describe the situation. We have hundreds of services and of course even more physical endpoints. Our deployment model is stored in a relational database. There we have also added information about the services within one deployment. We need this model for several reasons and it will be automatically kept up-to-date. So there we have the data about all services and their endpoints. It is not a registry but it somehow provides the data typically stored in a registry. So we need a strategy to couple the ESB registry with our data. One approach could be to implement synapse registry interfaces and provide an own registry implementation. Another approach could be to try to couple the WSO2 ESB database-backed registry with our own database. No matter which approach we would choose, it would take some time to get something which works reliably. Though we don't plan to integrate all of our services right from the beginning, it would be good to take advance of the data stored within our deployment model to avoid redundant information. So the basic idea is to provide something as a kind of intermediate solution. This could be an export and transformation of our data in the database to the format of the synapse configuration file. We could export an XML-fragment with proxy definitions and endpoint definitions and put them under version control. We than could release such a version and replace the existing fragment which a new one. Each fragment would be included in the synapse.xml. So in fact we would only use the local registry with synapse. Later on we can decide how to proceed for a better solution. Does this make sense? Or do you have better ideas? What I forgot... part of our database model is also a routing definition. So we have a kind of routing table we can use to generate the configuration for a switch mediator inside a service proxy definition. Some parts of our configuration will be rather static and not part of the database model. Like the configuration of custom tracing and statistic mediators. Maybe we will end up using an alternate approach were we don't include fragments but rather generate a full synapse.xml by putting fragments together. Some kind of templating mechanism. We have to think about different possibilities. Any feedback and ideas are greatly appreciated. Regards, Eric _______________________________________________ Esb-java-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
