You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2010/01/21 17:44:49 UTC
Re: Changing the endpoint registry usage to be based on the discovered impl not the domain uri scheme
There are two use cases that led the current scheme-based delegation:
1) One NodeFactory in the JVM can host nodes that connect to different SCA
domains. Different SCA domain might use different endpoint registry
implementations.
2) Allowing multiple endpoint registry implementation in the runtime allows
me to test the Tribes/Hazelcast/Zookeeper based registry by just changing
the domain registry URI, especially for the all-in-one distro.
What problems do you see with the scheme-based approach?
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.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Thursday, January 21, 2010 6:57 AM
To: <de...@tuscany.apache.org>
Subject: Changing the endpoint registry usage to be based on the discovered
impl not the domain uri scheme
> I'd like to change the way the endpoint registries are used so that it
> just uses which ever registry impl is discovered using the standard
> Tuscany discovery mechanism instead of having the registry looked up
> by the domain uri scheme. I don't think we need the scheme based
> lookup as theres no real need to support multiple registry
> implementations within the runtime and having the discovered registry
> handle all URIs gives it the flexibility to handle both in-VM and
> distributed domains.
>
> ...ant
Re: Changing the endpoint registry usage to be based on the discovered impl not the domain uri scheme
Posted by Raymond Feng <en...@gmail.com>.
I'm starting to introduce the DomainRegistryFactoryExtensionPoint, stay
tuned :-).
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Tuesday, January 26, 2010 6:39 AM
To: <de...@tuscany.apache.org>
Subject: Re: Changing the endpoint registry usage to be based on the
discovered impl not the domain uri scheme
> The key technical requirement AIUI is to support multiple
> domain/contribution/composite applications with plugable
> implementations of all the runtime extensions to do that. But that
> doesn't mean supporting multiple different extension implementations
> concurrently in the same active runtime, and so far when we've tried
> to do that we've never been very successful - eg the multiple
> ServletHost or SCA bindings impls. The runtime is pretty lightweight
> and has lazy loading of things all over the place so its probably not
> much overhead to run several instances, and its also unlikely that
> there would ever be very many different endpoint registry impls wanted
> to be run concurrently so its not really going to be a lot of overhead
> to use separate runtimes. I can see you're keen to do this though so
> why don't you go ahead and implement the tweaks you talked about in
> the first email in this thread.
>
> What i do think would be good though is if we could just pick one
> registry impl and make it work consistently for all the main use cases
> we have instead of trying to maintain several different ones each with
> separate capabilities and limitations and test and samples and ways of
> being configured.
>
> ...ant
>
> On Mon, Jan 25, 2010 at 4:54 PM, Raymond Feng <en...@gmail.com> wrote:
>> Come on, Ant. I'm talking about a key technical requirement here:
>>
>> 1) Now we have the ability to run a shared Tuscany runtime in a JVM and
>> it
>> can be used to create multiple nodes, with each of them running a
>> composite
>> application from one or more SCA domains.
>>
>> 2) The Tuscany runtime (NodeFactory and the ExtensionPointRegistry)
>> doesn't
>> keep any application related states, including the
>> domain/contribution/composite. This is keen to be able to embed Tuscany
>> in a
>> managed container such as Web or OSGi so that one shared instance of
>> Tuscany
>> runtime to work with multiple composite apps.
>>
>> 3) Requiring different Tuscany runtime instances for composite
>> applications
>> from different SCA domains will definitely increase the memory footprint
>> and
>> the overhead to bootstrap more Tuscany runtime instances.
>>
>> 4) I'm not against the possibility to use different Tuscany runtime
>> instances at the application scope, for example, each web app can
>> potentially package Tuscany runtime in the WAR. But for the shared
>> Tuscany
>> runtime case, I want the feasibility to use a singleton to deal with
>> multiple composite apps from one or more SCA domains that require
>> different
>> protocols for the endpoint registry.
>>
>> Thanks,
>> Raymond
>> --------------------------------------------------
>> From: "ant elder" <an...@apache.org>
>> Sent: Monday, January 25, 2010 1:49 AM
>> To: <de...@tuscany.apache.org>
>> Subject: Re: Changing the endpoint registry usage to be based on the
>> discovered impl not the domain uri scheme
>>
>>> On Sun, Jan 24, 2010 at 5:55 PM, Raymond Feng <en...@gmail.com>
>>> wrote:
>>>>
>>>> [[SNIP]]
>>>>
>>>>> 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 -
>>>>
>>>> NO! Why do we have to clone Tuscany runtime instances in the same JVM
>>>> for
>>>> the mere purpose of supporting multiple domains? Please remember that
>>>> all
>>>> the code in the extension point registry is stateless and independent
>>>> of
>>>> the application state (domain/node/contribution/composite).
>>>>
>>>
>>> Thats a strawman argument Raymond so I'm not going to get drawn into it.
>>>
>>> ...ant
>>
>>
Re: Changing the endpoint registry usage to be based on the
discovered impl not the domain uri scheme
Posted by ant elder <an...@apache.org>.
The key technical requirement AIUI is to support multiple
domain/contribution/composite applications with plugable
implementations of all the runtime extensions to do that. But that
doesn't mean supporting multiple different extension implementations
concurrently in the same active runtime, and so far when we've tried
to do that we've never been very successful - eg the multiple
ServletHost or SCA bindings impls. The runtime is pretty lightweight
and has lazy loading of things all over the place so its probably not
much overhead to run several instances, and its also unlikely that
there would ever be very many different endpoint registry impls wanted
to be run concurrently so its not really going to be a lot of overhead
to use separate runtimes. I can see you're keen to do this though so
why don't you go ahead and implement the tweaks you talked about in
the first email in this thread.
What i do think would be good though is if we could just pick one
registry impl and make it work consistently for all the main use cases
we have instead of trying to maintain several different ones each with
separate capabilities and limitations and test and samples and ways of
being configured.
...ant
On Mon, Jan 25, 2010 at 4:54 PM, Raymond Feng <en...@gmail.com> wrote:
> Come on, Ant. I'm talking about a key technical requirement here:
>
> 1) Now we have the ability to run a shared Tuscany runtime in a JVM and it
> can be used to create multiple nodes, with each of them running a composite
> application from one or more SCA domains.
>
> 2) The Tuscany runtime (NodeFactory and the ExtensionPointRegistry) doesn't
> keep any application related states, including the
> domain/contribution/composite. This is keen to be able to embed Tuscany in a
> managed container such as Web or OSGi so that one shared instance of Tuscany
> runtime to work with multiple composite apps.
>
> 3) Requiring different Tuscany runtime instances for composite applications
> from different SCA domains will definitely increase the memory footprint and
> the overhead to bootstrap more Tuscany runtime instances.
>
> 4) I'm not against the possibility to use different Tuscany runtime
> instances at the application scope, for example, each web app can
> potentially package Tuscany runtime in the WAR. But for the shared Tuscany
> runtime case, I want the feasibility to use a singleton to deal with
> multiple composite apps from one or more SCA domains that require different
> protocols for the endpoint registry.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "ant elder" <an...@apache.org>
> Sent: Monday, January 25, 2010 1:49 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: Changing the endpoint registry usage to be based on the
> discovered impl not the domain uri scheme
>
>> On Sun, Jan 24, 2010 at 5:55 PM, Raymond Feng <en...@gmail.com> wrote:
>>>
>>> [[SNIP]]
>>>
>>>> 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 -
>>>
>>> NO! Why do we have to clone Tuscany runtime instances in the same JVM for
>>> the mere purpose of supporting multiple domains? Please remember that all
>>> the code in the extension point registry is stateless and independent of
>>> the application state (domain/node/contribution/composite).
>>>
>>
>> Thats a strawman argument Raymond so I'm not going to get drawn into it.
>>
>> ...ant
>
>
Re: Changing the endpoint registry usage to be based on the discovered impl not the domain uri scheme
Posted by Raymond Feng <en...@gmail.com>.
Come on, Ant. I'm talking about a key technical requirement here:
1) Now we have the ability to run a shared Tuscany runtime in a JVM and it
can be used to create multiple nodes, with each of them running a composite
application from one or more SCA domains.
2) The Tuscany runtime (NodeFactory and the ExtensionPointRegistry) doesn't
keep any application related states, including the
domain/contribution/composite. This is keen to be able to embed Tuscany in a
managed container such as Web or OSGi so that one shared instance of Tuscany
runtime to work with multiple composite apps.
3) Requiring different Tuscany runtime instances for composite applications
from different SCA domains will definitely increase the memory footprint and
the overhead to bootstrap more Tuscany runtime instances.
4) I'm not against the possibility to use different Tuscany runtime
instances at the application scope, for example, each web app can
potentially package Tuscany runtime in the WAR. But for the shared Tuscany
runtime case, I want the feasibility to use a singleton to deal with
multiple composite apps from one or more SCA domains that require different
protocols for the endpoint registry.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Monday, January 25, 2010 1:49 AM
To: <de...@tuscany.apache.org>
Subject: Re: Changing the endpoint registry usage to be based on the
discovered impl not the domain uri scheme
> On Sun, Jan 24, 2010 at 5:55 PM, Raymond Feng <en...@gmail.com> wrote:
>> [[SNIP]]
>>
>>> 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 -
>>
>> NO! Why do we have to clone Tuscany runtime instances in the same JVM for
>> the mere purpose of supporting multiple domains? Please remember that all
>> the code in the extension point registry is stateless and independent of
>> the application state (domain/node/contribution/composite).
>>
>
> Thats a strawman argument Raymond so I'm not going to get drawn into it.
>
> ...ant
Re: Changing the endpoint registry usage to be based on the
discovered impl not the domain uri scheme
Posted by Simon Laws <si...@googlemail.com>.
I'm not quite sure what questions are being asked here. It seems that
the following is being discussed:
1/ Whether it's possible to support more than one type of endpoint
registry at the same time within the context of a NodeFactory (single
JVM)
2/ Whether we should use a provider approach and present endpoint
registry as an extension point
3/ Whether endpoint registry should be called domain registry
4/ How configuration should be specified to include domain URI and
endpoint registry configuration
Some of these are clearly related but first did I miss anything?
Simon
Re: Changing the endpoint registry usage to be based on the
discovered impl not the domain uri scheme
Posted by ant elder <an...@apache.org>.
On Sun, Jan 24, 2010 at 5:55 PM, Raymond Feng <en...@gmail.com> wrote:
> [[SNIP]]
>
>> 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 -
>
> NO! Why do we have to clone Tuscany runtime instances in the same JVM for
> the mere purpose of supporting multiple domains? Please remember that all
> the code in the extension point registry is stateless and independent of
> the application state (domain/node/contribution/composite).
>
Thats a strawman argument Raymond so I'm not going to get drawn into it.
...ant
Re: Changing the endpoint registry usage to be based on the discovered impl not the domain uri scheme
Posted by Raymond Feng <en...@gmail.com>.
[[SNIP]]
> 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 -
NO! Why do we have to clone Tuscany runtime instances in the same JVM for
the mere purpose of supporting multiple domains? Please remember that all
the code in the extension point registry is stateless and independent of
the application state (domain/node/contribution/composite).
>
> 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
Re: Changing the endpoint registry usage to be based on the
discovered impl not the domain uri scheme
Posted by ant elder <an...@gmail.com>.
On Sat, Jan 23, 2010 at 4:47 PM, Raymond Feng <en...@gmail.com> wrote:
> Please see my comments inline (not in a mode to write long text on Saturday
> :-).
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "ant elder" <an...@apache.org>
> Sent: Saturday, January 23, 2010 12:41 AM
> To: <de...@tuscany.apache.org>
> 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 <en...@gmail.com> wrote:
>>>
>>> More comments inline.
>>>
>>> --------------------------------------------------
>>> From: "ant elder" <an...@gmail.com>
>>> Sent: Thursday, January 21, 2010 9:03 AM
>>> To: <de...@tuscany.apache.org>
>>> 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 <en...@gmail.com>
>>>> 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
Re: Changing the endpoint registry usage to be based on the discovered impl not the domain uri scheme
Posted by Raymond Feng <en...@gmail.com>.
Please see my comments inline (not in a mode to write long text on Saturday
:-).
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Saturday, January 23, 2010 12:41 AM
To: <de...@tuscany.apache.org>
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 <en...@gmail.com> wrote:
>> More comments inline.
>>
>> --------------------------------------------------
>> From: "ant elder" <an...@gmail.com>
>> Sent: Thursday, January 21, 2010 9:03 AM
>> To: <de...@tuscany.apache.org>
>> 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 <en...@gmail.com>
>>> 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"));
>
>>>
>>>> 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.
>
> ...ant
Re: Changing the endpoint registry usage to be based on the
discovered impl not the domain uri scheme
Posted by ant elder <an...@apache.org>.
On Thu, Jan 21, 2010 at 5:28 PM, Raymond Feng <en...@gmail.com> wrote:
> More comments inline.
>
> --------------------------------------------------
> From: "ant elder" <an...@gmail.com>
> Sent: Thursday, January 21, 2010 9:03 AM
> To: <de...@tuscany.apache.org>
> 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 <en...@gmail.com> 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
Re: Changing the endpoint registry usage to be based on the discovered impl not the domain uri scheme
Posted by Raymond Feng <en...@gmail.com>.
More comments inline.
--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Thursday, January 21, 2010 9:03 AM
To: <de...@tuscany.apache.org>
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 <en...@gmail.com> 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 :-)?
>
>> 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.
>
> ...ant
Re: Changing the endpoint registry usage to be based on the
discovered impl not the domain uri scheme
Posted by ant elder <an...@gmail.com>.
On Thu, Jan 21, 2010 at 4:44 PM, Raymond Feng <en...@gmail.com> 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?
> 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?
...ant