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 > >
