You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Hubert, Eric" <er...@jamba.net> on 2008/05/16 15:24:51 UTC
Synapse-Configuration with external XML entities
Hi Synapse Devs,
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.
Is the only way to achieve this to register a custom entityresolver to the xmlparserconfiguration? One way could be to extend the XMLGrammarCachingConfiguration. Is there a better approach? Or can this work somehow out of the box?
Regards,
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Synapse-Configuration with external XML entities
Posted by Paul Fremantle <pz...@gmail.com>.
Ruwan
Actually I believe the design of the Registry provider supports this,
if you don't mind serializing your data into OMElements. So the
Registry asks for a key and gives you an OMElement. The OMElement
doesn't *need* to be generated from an HTTP GET of XML - it could be
serialized from a database. (In fact, it could use a data service
potentially)
This was always how I imagined we would support UDDI. UDDI doesn't
provide Endpoint definitions in the Synapse format, but we could
basically take the UDDI data and fudge it into the right format during
the Registry lookup process.
I think you can do the other approach, but this might save you
rewriting the whole of the Synapse.xml in the new model, because of
course the Registry model handles fragments.
Paul
On Sat, May 17, 2008 at 3:24 AM, Ruwan Linton <ru...@gmail.com> wrote:
> 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 <er...@jamba.net>
> 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: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Synapse-Configuration with external XML entities
Posted by Ruwan Linton <ru...@gmail.com>.
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 <er...@jamba.net>
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: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
RE: Synapse-Configuration with external XML entities
Posted by "Hubert, Eric" <er...@jamba.net>.
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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Synapse-Configuration with external XML entities
Posted by "Asankha C. Perera" <as...@wso2.com>.
Hi Eric
> 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?
If so, we cannot currently do it, but you can store the synapse.xml in
the registry and the sequences, endpoints etc as fragments again in the
registry, and refer to these using keys from the main synapse.xml
However, you cannot currently load Proxy services off the registry
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?
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org