tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Feng" <enjoyj...@gmail.com>
Subject Re: Calling NodeLauncher vs. calling SCANodeFactory
Date Mon, 03 Aug 2009 18:52:00 GMT
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.


From: "Simon Nash" <nash@apache.org>
Sent: Saturday, August 01, 2009 5:38 AM
To: <dev@tuscany.apache.org>
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

View raw message