Hi Eric, If I got your requirement correctly, you want to store the XML fragments like proxy definitions sequence definitions and so on in a database (or in the file system) and build up the configuration? Is that so?
If it is the case you can do this by writing your own ConfigurationFactory and ConfigurationSerializer which collects the fragments from the database and build up the SynapseConfiguration. Even though this is theoretically possible, there will be certain generalizations that we will have to do at the synapse level because it is tightly coupled with XML configurations for the moment. So if this is what your requirement is, then I would like to go through the synapse configuration building logic and re factor the code in a way it can be generally used to write a new configuration medium than XML. At the same time I would like to know the limitations of the Registry that permits you in using that to achieve your requirements. Thanks, Ruwan. On Fri, May 16, 2008 at 10:26 PM, Hubert, Eric <[EMAIL PROTECTED]> wrote: > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Ruwan Linton http://www.wso2.org - "Oxygenating the Web Services Platform"
