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.
>>
>>> 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.
...ant
