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