I agree. It is a matter of separation of different concerns.
IMO, the registry layer provides the infrastructure to share information
(like a virtual map). The information can be any metadata that are relevant
to the SCA domain. We can use that to do different things, such as:
* Share endpoint descriptions and policy definitions for all running
components in the domain
* Share contributions and composites
* Share node configurations
Both Tribes and ZooKeeper provide such capabilities within their boundaries.
The registry SPI at this point only deal with endpoints. The same utility
can be used to build a domain registry that manages
contributions/composites/nodes.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Wednesday, November 11, 2009 9:50 AM
To: <[email protected]>
Subject: Re: svn commit: r834683 - in
/tuscany/java/sca/modules/endpoint-zookeeper
It would be worth discussing what those Tuscany functions might be in
the context of [1]. Having said this the diagram there is a little
biased. I'm concerned that there is a temptation to believe that we
are either building a distributed domain infrastructure that is
controlled from a central domain manager (maybe using zookeeper to
support the distribution) or that has no central point of control
(maybe using tribes to support the distribution). I think it would
serve us well if we support both (at the same time technology
permitting).
I would like to be able to say If I want to add a contribution to a
specific node and hence directly influence where it will run then
sure. Maybe I want to do that with a webapp for example. Alternatively
if I want to add it to a central domain manager and have it pick a
node for me then that's great too.
I'm advocating that we avoid building registry APIs that are topology
specific if we can avoid it.
Simon
[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Domain
