Hi, Simon.

The idea of the Launcher is to provide a simple way to launch an SCA node without dragging in Tuscany dependencies at compile time. We can pass arguments to the launcher from the command line with simple types that can be represented in string. The launcher can be invoked programmatically too, for example, by the tools. We don't need to have Tuscany jars on the classpath as the launcher will try to discover them for the runtime.

There are two possible layers for the metadata to start an SCA node:

* Raw configuration: Names or locations of the SCA contributions and composites. Tuscany will use the contribution facility to load the artifacts into memory to build up the Contribution/Composite models.

* Loaded configuration: Contribution/Composite models that are created programmatically. Tuscany can directly use these model objects to create an SCA node. With this capability, we could allow the on-the-fly generation of SCA composite applications or allow Tuscany embedders to interact with the SCA node.

To some extent, we can view the SCANodeFactory as the SPI that supports programmatic construction of the SCA nodes. At this moment in 1.x, the SCANodeFactory/SCANode is somewhat overlapping with the SCA NodeLauncher as the SCANodeFactory/SCANode doesn't expose the functions to directly take Contribution/Composite models.

In 2.x, we're starting to explore how we can support the "raw" and "loaded" configurations at different layers. For example, we now have the NodeConfiguration/ContributionConfiguration in the node-api to represent the raw configurations so that a composite application can be loaded from the archives. On other hand, we also use the NodeFactory to take the loaded Contribution objects to support the on-the-fly composite generation from OSGi properties.

Thanks,
Raymond

--------------------------------------------------
From: "Simon Nash" <[email protected]>
Sent: Saturday, August 01, 2009 5:38 AM
To: <[email protected]>
Subject: Calling NodeLauncher vs. calling SCANodeFactory

There seems to be quite a bit of overlap between the APIs in
NodeLauncher and SCANodeFactory.  Specifically, the following
pairs of API calls seem to do the same thing.

 NodeLauncher.createNodeFromURL(url)
 SCANodeFactory.createSCANodeFromURL(url)

 NodeLauncher.createNode(uri, contribution...)
 SCANodeFactory.createSCANode(uri, contribution...)

 NodeLauncher.createNode(uri, content, contribution...)
 SCANodeFactory.createSCANode(uri, content, contribution...)

 NodeLauncher.createNodeFromClassLoader(uri, classloader)
 SCANodeFactory.createSCANodeFromClassLoader(uri, classloader)

Is there any difference between calling NodeLauncher and
calling SCANodeFactory in these cases?  Our samples and tests
use both approaches.  Which should we be telling users to use?

  Simon

Reply via email to