You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2011/05/20 11:16:49 UTC
EndpointRegistry / DomainRegistry
I've now renamed the old EndpointRegistry to be DomainRegistry [1] as has
been discussed a while back on the ML.
I've also been adding methods to that to better support distributed
runtimes. The main things added are:
- methods about installed contributions and a new SPI class
InstalledContribution [2] which holds information about the contributions
attributes. Looking at that now perhaps InstalledContribution would be
better renamed to something like ContrbutionDescription. The registry needs
to know about the contributions so distributed runtimes can find out about
available contributions to use, the attributes are needed so that those
distributed runtimes don't have to actually load in the entire contribution
themselves. The registry also now has a ContributionListener, thats needed
so that distributed runtimes can find out when a contribution has been
updated and clear out any local cache they might have of the old
contribution. Besides for performance they need to cache the contribution so
that when starting multiple composites in a runtime they all use the same
contribution and classloader for that contribution (compliance JCI100010).
- methods about running composites. These are needed so that runtimes can
see composites are running elsewhere in the domain and so prevent a
composite being started multiple times, and so that the domain composite can
be created from anywhere based on whats currently running.
- methods about what "members" are active in the domain and a way to send
commands to remote members. These are used for starting and stopping
composites on remote runtimes. The name "members" is just to avoid confusion
with the word "node".
This is where i've got to so far, I think there is refactoring that could be
done but this is the current state.
One thing thats not there yet which might be useful is something like a
pluggable contribution repository. Currently the URL used when installing a
contribution is what is shared in the registry, so
"file:/C:/Tuscany/SVN/trunk/samples/getting-started/helloworld" is only
going to work if all runtimes have access to that filesystem, if they don't
then you need to use something they do all have access to, eg "
https://repository.apache.org/content/groups/snapshots/org/apache/tuscany/sca/samples/helloworld/2.0-SNAPSHOT/helloworld-2.0-SNAPSHOT.jar".
If there was a pluggable repository (or repository manager?) then it could
sort out ensuring things like file:/C:/... are installed and made available
with an URL accessible domain wide.
Another point is that although the above might sound specific to the
DomainNode APIs virtually all the important logic is within the Tuscany
runtime. So for example it would be relatively simple to have this also work
with the NodeFactory/Node APIs by adding a NodeFactory.createNode method
which takes contrbution URIs instead of URLs and have createNode just look
up the contributions from the DomainRegistry.
...ant
Re: EndpointRegistry / DomainRegistry
Posted by ant elder <an...@apache.org>.
On Thu, Jun 9, 2011 at 2:05 PM, Simon Laws <si...@googlemail.com> wrote:
> On Thu, May 26, 2011 at 12:41 PM, ant elder <an...@gmail.com> wrote:
>> On Fri, May 20, 2011 at 10:16 AM, ant elder <an...@gmail.com> wrote:
>>
>>> This is where i've got to so far, I think there is refactoring that could be
>>> done but this is the current state.
>>>
>>
>> It seems like there are now several types of things in the domain
>> registry, theres info about installed contributions, there's info
>> about the distributed domain - eg what composites are running where,
>> and there is info about the active endpoints. I wonder if those should
>> be three separate things? One of the refactorings could be to separate
>> out the things like the contribution information from the runtime
>> information, so perhaps have something like a ContributionRepository
>> which holds the ContributionDescriptions and provides access to the
>> actual contribution contents.
>>
>> ...ant
>>
>
> Looking at the DomainRegistryFactory there are operations...
>
> DomainRegistry getEndpointRegistry(String endpointRegistryURI,
> String domainURI);
> Collection<DomainRegistry> getEndpointRegistries();
>
> Any reason I can't change these to getDomainRegistry etc. or was this
> left in case the idea of having a ContributionRepository takes hold?
>
No reason, i guess those just got missed in the refactor which changed
EndpointRegistry to DomainRegistry.
...ant
Re: EndpointRegistry / DomainRegistry
Posted by Simon Laws <si...@googlemail.com>.
On Thu, May 26, 2011 at 12:41 PM, ant elder <an...@gmail.com> wrote:
> On Fri, May 20, 2011 at 10:16 AM, ant elder <an...@gmail.com> wrote:
>
>> This is where i've got to so far, I think there is refactoring that could be
>> done but this is the current state.
>>
>
> It seems like there are now several types of things in the domain
> registry, theres info about installed contributions, there's info
> about the distributed domain - eg what composites are running where,
> and there is info about the active endpoints. I wonder if those should
> be three separate things? One of the refactorings could be to separate
> out the things like the contribution information from the runtime
> information, so perhaps have something like a ContributionRepository
> which holds the ContributionDescriptions and provides access to the
> actual contribution contents.
>
> ...ant
>
Looking at the DomainRegistryFactory there are operations...
DomainRegistry getEndpointRegistry(String endpointRegistryURI,
String domainURI);
Collection<DomainRegistry> getEndpointRegistries();
Any reason I can't change these to getDomainRegistry etc. or was this
left in case the idea of having a ContributionRepository takes hold?
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: EndpointRegistry / DomainRegistry
Posted by ant elder <an...@gmail.com>.
On Fri, May 20, 2011 at 10:16 AM, ant elder <an...@gmail.com> wrote:
> This is where i've got to so far, I think there is refactoring that could be
> done but this is the current state.
>
It seems like there are now several types of things in the domain
registry, theres info about installed contributions, there's info
about the distributed domain - eg what composites are running where,
and there is info about the active endpoints. I wonder if those should
be three separate things? One of the refactorings could be to separate
out the things like the contribution information from the runtime
information, so perhaps have something like a ContributionRepository
which holds the ContributionDescriptions and provides access to the
actual contribution contents.
...ant
Re: EndpointRegistry / DomainRegistry
Posted by ant elder <an...@gmail.com>.
On Fri, May 20, 2011 at 10:16 AM, ant elder <an...@gmail.com> wrote:
> . . . a new SPI class
> InstalledContribution [2] which holds information about the contributions
> attributes. Looking at that now perhaps InstalledContribution would be
> better renamed to something like ContrbutionDescription.
InstalledContribution has now been renamed to ContrbutionDescription.
...ant