On Sat, Jan 23, 2010 at 4:47 PM, Raymond Feng <[email protected]> wrote: > Please see my comments inline (not in a mode to write long text on Saturday > :-). > > Thanks, > Raymond > -------------------------------------------------- > From: "ant elder" <[email protected]> > Sent: Saturday, January 23, 2010 12:41 AM > To: <[email protected]> > Subject: Re: Changing the endpoint registry usage to be based on the > discovered impl not the domain uri scheme > >> On Thu, Jan 21, 2010 at 5:28 PM, Raymond Feng <[email protected]> wrote: >>> >>> More comments inline. >>> >>> -------------------------------------------------- >>> From: "ant elder" <[email protected]> >>> Sent: Thursday, January 21, 2010 9:03 AM >>> To: <[email protected]> >>> Subject: Re: Changing the endpoint registry usage to be based on the >>> discovered impl not the domain uri scheme >>> >>>> On Thu, Jan 21, 2010 at 4:44 PM, Raymond Feng <[email protected]> >>>> wrote: >>>>> >>>>> There are two use cases that led the current scheme-based delegation: >>>>> >>>> >>>> Heh, isn't it just because I started using using the scheme based >>>> approach in various places as an easy way to get the tribes registry >>>> configured? >>>> >>> >>> You don't like your idea any more :-)? >>> >> >> I'm not sure :) At the time there was no other way to configure the >> SCAClient, with the SCA API updates a few days ago the Properties >> passed in to the SCAClientFactory newInstance are now propagated to >> our code so you could do something like: >> >> Properties properties = new Properties(); >> properties.setProperty("registry", "tuscany"); >> properties.setProperty("listenPort", "1234"); >> properties.setProperty("remotes", "9.20.1.1:1234"); >> SCAClientFactory factory = SCAClientFactory.newInstance(properties, >> URI.create("myDomain") >> >> however it still seems a lot more concise and convenient to also support: >> >> SCAClientFactory factory = >> >> SCAClientFactory.newInstance(URI.create("tuscany:myDomain?listen=1234&remotes=9.20.1.1:1234"); >> >> Thats especially true for the command line utilities we have, and if >> we support it anywhere its probably best to be consistent and support >> it everywhere, even if there are also other ways to get the runtime >> configured as well. > > Sorry, my view is slightly different: > Properties properties = new Properties(); > properties.setProperty("domainRegistryURI", "<physical URI for the > registry>"); > SCAClientFactory factory = SCAClientFactory.newInstance(properties, > URI.create("myDomain")); >
That doesn't seem so different, it comes down to we can either encode everything needed in the domainURI, or use the domainURI along with some extra config such as one or more properties. If we're using extra config then there is less need to encode all the registry configuration in a single string. The further we stray from using just the SCAClientFactory domain uri the less portable the user application becomes. Its easy for an application to look up a single domain uri string from something like jndi, env-entry or whatever suits the environment and that makes the application easily configurable for different domains and runtimes, but using extra config makes that harder to do, and, it becomes non-standard - instead of using the OASIS SCAClient API they might as well just use the Tuscany API directly. Anyway, over on the other thread about this we already agreed to support both ways so lets not rehash this here. >> >>>> >>>>> There are a few tweaks we can do to make the current code more flexible >>>>> though: >>>>> >>>>> a) Add an extension point named DomainRegistryProviderExtensionPoint >>>>> >>>>> b) Rename DomainRegistryFactory to be DomainRegistryProvider. The >>>>> providers >>>>> will be registered to the DomainRegistryProviderExtensionPoint. Each >>>>> provider can support one or more URI schemes. The >>>>> DomainRegistryProviderExtensionPoint can either lookup the >>>>> DomainRegistryProvider by scheme, or simply loop through the >>>>> DomainRegistryProvider instances to find the provider that can handle >>>>> the >>>>> registry URI. >>>>> >>>>> c) DomainRegistryProvider will have a method >>>>> getDomainRegistry(domainURI) >>>>> to return an EndpointRegistry (should be renamed to DomainRegistry) >>>>> instance >>>>> for the given SCA domain. >>>>> >>>> >>>> We can add another extension point, and thats what I was about to do >>>> but it seems unnecessary so I thought i first try posting about >>>> cleaning this up and simplifying things. >>>> >>>> There is a lot of old code around this that we really should clean up, >>>> left from the various attempts to get pieces of the distributed domain >>>> working and most of it has no tests or doc or use cases or ML >>>> discussion. We don't have support for running multiple impls >>>> concurrently of anything else - host-jetty/tomcat or any other >>>> extension - is this registry case really so different? >>> >>> It's a different case than Tomcat/Jetty. The domain registry can use >>> different protocols but both Tomcat and Jetty are implementation of HTTP >>> server. >>> >>> Even for Tomcat/Jetty, I remember that we made some changes to allow both >>> modules in the same distro. >>> >> >> The Tomcat/Jetty servletHosts are a good example of what I mean of >> just adding code and function without clear use cases or cleaning up: >> Some of the old code that handles multiple ServletHost impls is still >> around, but doesn't work properly, so the new extension ranking value >> was came up with to help fix that, but it turns out that doesn't work >> either as its the environment that determines which host should be >> used so a build time static doesn't work, so the name attribute was >> added to the servlet host extensions as well, which also didn't work >> properly either because extensions have no way of knowing which they >> should choose, and all those ways sit on top of an >> "ExtensibleServletHost" which is some really old code for supporting >> multiple hosts that know one really understands and there is no way >> for extensions to knowing which to use anyway so _everything_ just >> did servletHosts.get(0)! So to fix all that theres now the hacky >> ServletHostHelper which just uses a system wide static to say which to >> use, which is similar to what the code originally did and kind of >> defeats the purpose of all the other mechanisms and the idea of the >> runtime being all stateless and sharing things. >> >> Coming back to the multiple endpoint registries, if we're to support >> multiple implementations concurrently i think we need to understand >> why and what the use cases are. Would endpoints be shared across the >> registries when the same domain name is used? If so how, and if not >> why not? One thing that would be useful is domain federation across >> different runtimes but i'm not sure that we need multiple concurrent >> registry impls to do that and it would be easier and clearer to do >> that with a "bridge" extension that is just a regular Tuscany >> extension that can connect to the foreign registry and keeps the local >> registry in sync with the foreign one as endpoint changes happen. > > My use case is simple: > > Two nodes using the same Tuscany runtime wants to connect to two different > SCA domains, one using multicast while the other using zookeeper. If you can > propose > a simple solution that works without two EndpointRegistry implementations, > I'll be happy to support it. > It sounds like we don't really need multiple registries concurrently in the same runtime but whats really wanted is a way to have separately configurable Tuscany runtime instances from the same set of Tuscany jars. That would be really useful, it would simplify a a lot of our code, it would fix other cases where this has been an issue like the ServletHost problems mentioned above, and it would help with some other things i've never been able to find easy ways to do with the current configuration options. So - How about we add an optional config properties to the NodeFactory API so that you can pass in arbitrary configuration options when creating a NodeFactory instance. An example of one of those options would be a way to override the default behavior of the service discovery, for example, by changing the ranking value of an extension. ...ant
