Conceptually, the contributions are known to the SCA domain. But they don't
have to be physically stored with the nodes or a central place. We adopt the
URL idea to represent physical locations of contributions. A node just needs
to know a list of URLs for the contributions that can be loaded locally or
remotely. The list of contributions can be built following the import/export
statements of the installed contributions within an SCA domain.
Now it's a matter how a Node gets its contribution URLs. Such information is
part of the node configuration, which can be provided by one of the
following ways:
1) A local node.xml file to list the contribution locations
2) Programmatically configured using the NodeConfiguration model
3) Locally discovered from the classpath
4) Provisioned from the SCA domain dynamically
We already support 1, 2, and 3. Once we port SCA Domain Manager into 2.x and
(potentially) reuse the DomainRegistry to share the metadata in addition to
the runtime endpoint descriptions, we can support 4).
I don't expect the nodes in the peer to peer network become the store of
contributions though, as requiring a node to serve contributions archives is
too much, IMO.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Wednesday, February 10, 2010 8:18 PM
To: <[email protected]>
Subject: Re: Imports and exports in the distributed domain
Having a Node represent composites depending on multiple contributions
works ok in a single JVM domain but is that enough with a fully
distributed and dynamic domain? When a contribution has an export it
must be made available across the domain and contributions need to be
able to import those resources anywhere not just within a single Node,
right?
So one way that could be done is to have contribution exports
registered in the distributed registry with the key being the export
and the value being a URL where the exported resource is available
(we'd need some sort of embedded server to make those resources
available at that url). Then the import processing would look up the
resource in the registry and access the resource using the URL (eg
with a network classloader in the case of import.java/export.java).
That sounds similar to what you're suggesting with the SCA domain
functioning as a repository doesn't it? Not a trivial amount of work
to do but it seems like we need to do this if we're to have a complete
distributed domain story.
...ant
On Thu, Feb 11, 2010 at 11:01 AM, Raymond Feng <[email protected]>
wrote:
In Tuscany, we use a Node to represent a composite that depends on more
than
one contributions through the import/export. The list of contributions
(URLs) required for a composite are made available to the runtime that
hosts
the node.
SCA domain can also function as a repository of installed contributions.
The
node can pull in the contributions in advance (that's how Tuscany works
today) or on demand based on the import/export matching.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Wednesday, February 10, 2010 1:27 PM
To: <[email protected]>
Subject: Imports and exports in the distributed domain
Has anyone thought much about how imports and exports might work with
the distributed domain? What I'd like to get working is being able to
have a contribution in one runtime exporting some resources and have
other contributions running in other runtimes and JVMs able to import
those resources. Currently the Tuscany code is designed to expect all
the exported resources to be available from contributions in the same
Node as the contribution doing the importing so to support this the
code needs to be updated in similar ways as was done for the
distributed endpoint targets using the distributed registry and some
remote communication mechanisms. I'm playing around with this now but
i'd be interested in anyone else's thoughts about it.
...ant
