On Thu, Feb 18, 2010 at 5:31 PM, Hiranya Jayathilaka <hira...@wso2.com>wrote:
> Hi Folks, > > With registry separation work shaping up we need to rethink how we are > going to handle dynamic sequences and endpoints in the ESB. Earlier users > were able to save sequences and endpoints anywhere in the registry and refer > to them using keys as shown below. > > <endpoint key="/foo/bar/endpoint"/> > <sequence key="/foo/bar/sequence"/> > > The WSO2Registry adapter class in the mediation registry component mapped > the above dynamic entires to resources stored in the registry. With Carbon > now having three separate registries, things become more complicated. We > definitely need to rewrite the WSO2Registry adapter to be aware of the three > registries. Right now it's using the System registry (which is deprecated) > and we should always specify absolute paths in the Synapse config as > follows. > > <endpoint key="/_system/config/foo/bar/endpoint"/> > > IMO users should be able to store dynamic entries in any of the registries > depending on the situation. For instance if the endpoint/sequence is a > simple static one it can be stored in the config registry. In situations > where such entries need to be governed it should go in the governance > registry. WSO2Registry adapter should be able to load resources from any of > the registries. The sequence and endpoint UI should be updated to reflect > these changes as well. Currently they only show dynamic entries saved in the > config registry. > > So all in all we need a mechanism for enabling the mediation registry > adapter to load resources from all registries. In an offline discussion > Sumedha proposed the following path format for dynamic resources: > > gov:foo/bar/endpoint (Points to foo/bar/endpoint in governance registry) > +1 > conf:foo/bar/endpoint (Points to foo/bar/endpoint in config registry) > +1 > local:foo/bar/endpoint (Points to foo/bar/endpoint in local repo) > Users must not store in the server local space. This is exclusive for the node's use. However, if this is stored by the components then I'm +1 for this. > foo/bar/endpoint (Same as local:foo/bar/endpoint - For backward > compatibility) > +0. However, IMO, this should be config:foo/bar/endpoint, since it is the config registry that maps most closely to the former system/user registries. The local repository is a much more restricted version, and should not be used for such purpose. > > This looks like a fairly good approach to me. Thoughts? > +1. It would be great if the other component authors could do a similar evaluation of their components, and let us know whether such changes should be done to those as well. Thanks, Senaka. > > Thanks > -- > Hiranya Jayathilaka > Software Engineer; > WSO2 Inc.; http://wso2.org > E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 > Blog: http://techfeast-hiranya.blogspot.com > > _______________________________________________ > Architecture mailing list > architect...@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Senaka Fernando Software Engineer WSO2 Inc. E-mail: senaka AT wso2.com; Mobile: +94 77 322 1818 http://www.wso2.com/ - "Lean . Enterprise . Middleware"
_______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
