... snip > > Ok, i hadn't noticed that. They're quite similar, AFAICT the main > functional differences between the two approaches is that your one > enables contributions to be shared between nodes but at the expense of > having to explicitly list the contributions for a node in a config > file whereas the other approach you don't need any config file but if > a contribution needs to be used in more than one node then it needs to > be copied.
Yes, to add a bit of weight to this a scenario I had imagined was a distributed file system where the ops just set up the domain in one place by copying files into a folder. They then start nodes on various machines and, by simply matching the node name with the appropriate file on disc, the node is able to tell which composites to start. I'm not so concerned whether the node loads all or just some of the contributions but wanted to control what was actually running where. Also I wanted to be able to control the base URLs for the case where I start a node on a machine where, for example, the default HTTP ports are being used by some other non-SCA related software. I want to be specific and don't want our code just to choose a port because I have to also configure the firewall. > > To answer those other questions - You don''t need any configuration > file to say whats running where because all the contributions in the > directory are just installed in the Node. The Domain Node API supports > all of the things from section 10 in the Assembly spec so thats what i > wanted to try to get this file system approach to do with as little > other config as possible. So you can modify a contributions > sca-contribution.xml metadata by having an additional one as a side > file and this approach uses a side file with the contribution name but > with a .xml file type. And you can add additional deployable > composites to a contribution so thats what the .composite files are > for with the name starting with the contribution name and ending with > .composite and anything in the middle of the name which is ignore but > needed just to make the file unique. Ok, makes sense. > You can also explicitly define > the dependent contributions uri's for a contribution with a property > in the domain.properties file. What would that property look like? > So with that for example you could drop > any old non-sca jar into the folder and have it used in a domain, and > as required add side files for sca-contribution.xml or .composites > that use the jar. > > I can see advantages and disadvantages with both approaches. I guess > we could simply support both so perhaps if there is a file named > node.xml in the folder than use that for all the config otherwise do > it the way that createNode(File) is currently working. For simple > things you can probably get away without needing a node.xml but for > more complicated setups then node.xml might make it easier. +1 although, if we're not going with sub-directories, I would add a convention something like. nameofnode-node.xml or similar to cover the shared file system case. Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
