Simon Laws wrote:
In the distributed domain contributions and any updates have to be
provisioned to each node. There are many ways of doing this, ftp, http,
shred file system , etc. to the extent that Tuscany shouldn't really care
too much about how it is achieved. I would expect that at any give time a
domain at a node can be notified of its configuration given the URL(s) of
where to find its up to date contributions. For example, in the stand alone
case this could just resolve to the contributions in "file:///path to
sca-cntributions dir".
However I'm a little unclear how to deal with configuration updates. There
have been a number of posts recently about incremental updates to domains
[1] and [2]. I can see that contributions can be added and removed but the
implication of the discussion in [1] and the assembly spec (1.10.4.1)
implies that contributions can also be updated. Is there code to support
this in place already? I'm assuming the current approach is to drop the
current contribution and load the updated version rather than deal with
deltas.
Simon
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19979.html
[2] http://issues.apache.org/jira/browse/TUSCANY-1379
Simon,
I think it will pay to do a bit more thinking about all this. There are
going to be a range of different configurations to support, and so
thinking through the structure of the runtime nodes and how they
interact with the contributions in the Domain will pay off over time.
I think there is going to be too much to contain in one email, but I'll
start here. I think capturing the concepts on Wiki pages will pay off
in the long run, since I think that sorting through a load of emails to
find them will get hard.
So, if you are all seated comfortably, let us begin....
(Brits of a certain age will understand where that phrase comes from...)
We have the SCA Domain. This contains the configuration data, held as a
series of one or more contributions. On a single node runtime, the way
in which the Domain is held can be very simple indeed. Files on disk in
one or more directories will do fine.
Once we get a distributed runtime, things rapidly get more complex. The
one obvious thing is that it is almost inevitable that each runtime node
will need access to parts of the SCA Domain configuration that they
don't "own" - eg to make a wire from a component that one node runs to a
component running on another node.
How the SCA Domain is done for a distributed runtime is also variable -
it could be done in a number of ways. The trick is to provide
interfaces between the runtime node code and the "repository" that allow
for alternative implementations. This must include both the initial
configuration when the runtime node(s) start up and also what happens
when the Domain configuration changes.
I think that we must design interfaces that separate the organization of
the SCA Domain repository from the runtime code. These interfaces are
going to have to be two-way, in the sense that there is going to be both
pull and push aspects to them. ie A node can go pull configuration
information from the Domain, or it can have configuration thrown at it -
either as updates or by some provisioning manager that is tossing out
work to do.
Service interfaces seem like the right kind of things to do under the
covers inside the implementation of the Domain repository. Nodes in
principle need to talk with each other. We need to think through which
interfaces are needed first and then decide how they are dealt with in
terms of concrete service interfaces.
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
