Before we start to refactor the NodeFactory/Node API, let me explain how the
current ones are defined.
1) A NodeFactory represents an instance of the Tuscany kernel with an
ExtensionPointRegistry to access all extension points and extensions.
2) A Node is a unit of work that consists of a group of top-level components
from the SCA domain composite that can be started/stopped together. It's
typically configured as a list of contributions with deployable composites
that contain the group of top-level components.
3) A NodeConfiguration model is defined to capture all the attributes for
the configuration of a Node. NodeFactory can be used as the factory to
create NodeConfiguration instances. The NodeConfiguration provides a Java
DSL style methods to set the attributes. For example,
NodeConfiguration configuration =
NodeFactory.newInstance().createNodeConfiguration().setDomainURI("domain1").setURI("node1")
.setDomainRegistryURI("tribes://...").addContribution("c1",
"file://.../contribution1");
4) A NodeConfiguration can be populated from various sources, such as the
command-line arguments, an XML node.xml, a feed, or classpath discovery.
5) NodeFactory.createNode(NodeConfiguration config) is the ultimate method
that all other flavors of createNode() methods will delegate to. Each flavor
of the createNode() API is just to provide a convenient way to populate a
NodeConfiguration.
6) The following is a list of createNode() methods:
Create a node instance from the NodeConfiguration model. This is the
canonical API.
createNode(NodeConfiguration):
The following methods create a NodeConfiguration from the deployment
composite (which can be the URI within a contribution, an absolute URL, or
the content) and a list of contributions (uri for the id and url for the
location).
createNode(Contribution...):
createNode(String, Contribution...)
createNode(String, String[])
createNode(String, String[], String[])
createNode(InputStream, Contribution...)
createNode(Reader, Contribution...)
createNode(Reader, String[], String[])
Please note it's a combination of different ways to provide the deployment
composite and contributions. For example, we can use the
uri/reader/inputstream for the composite. For contributions, they can be
passed in as an array of Contribution (uri+location) obects, two arrays of
contribution uris and locations (String[], String[]) or an array of
contribution locations (String[], the uri is default to the location).
The next two methods allows a Node to created from the node.xml.
createNode(InputStream)
createNode(URL)
The last two methods are shortcuts to discover the node configuration from
the classpath.
createNode() - using META-INF/sca-contribution.xml as the resource to look
up the contribution on the classpath.
createNode(String, ClassLoader) - using the deployment composite uri as the
resource name and the classloader to look up a contribution on the
classpath. The location of the contribution is the classpath entry to the
resource name.
I'm open to refine some of the createNode() flavors.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Wednesday, December 09, 2009 7:09 AM
To: <[email protected]>; <[email protected]>
Subject: Re: [2.x] node configuration attributes
- createNode(URI uri, String... contributionLocations);
where the uri is the config uri that can be used to configure things
like the domain name and registry. That would match the SCAClient API
that takes the the similar uri to connect to the running services
+1 It would seem sensible that all the atributes (that started this
discussion) should be able to be provided via the API as well as via
the XML file. So we should support uri, domainURI, domainRegistryURI
(I haven't gone back and looked at the difference yet)
- it would useful and consistent to have a way to use Nodes with the
objects created from the Deployer so for example you can doing things
like Deployer.loadContribution, fiddle about with the Contribution and
then use that object in a Node. I'm not suggesting a method signature
for this yet as this opens up quite a lot of interesting options. For
example, all the NodeFactory methods about attaching or adding
deployment composites could then be done via the Deployer instead of
all the overloaded createNode methods. To do this well requires quite
a lot of changes to the Node APIs but after some playing around it
looks to me like it could make the APIs much cleaner with the simple
uses clear and obvious and the more complex cases more consistent and
powerful.
Interesting. Sounds like you have examples. Can you post? Need to be
careful about dependencies, i.e. to use the API what dependencies do
you need to include. We have a workspace manager in 1.x that combines
deployer type features with the ability to interact with the
runtime/exntrsion points. No precisely what you are suggesting but I
remember there were a lot of dependencies. Let discuss more and see
where it goes.
- rename createNode(URL) to match the other loadConfiguration method,
or rename both to something like createNodeFromConfig
Didn't spot those methods down at the bottom of NodeFactory. So we also
have...
public abstract Node createNode(NodeConfiguration configuration);
node configuration object
public abstract NodeConfiguration loadConfiguration(InputStream
xml, URL base);
XML = node config xml? base = ?
createNode would be more consistent
Some to remove:
- all the ones using classloaders
- the Client Interface and just add the getService method to Node
Can we return an SCA client factory instance for the node
- the destroy method
- the getInstance(String domainURI) as there's the createNode that
includes the URI
...ant
