On Thu, May 28, 2009 at 11:39 AM, Simon Laws <[email protected]> wrote: > Regardless of the interesting technical choices we could make to allow > us to build a co-operating group of nodes the important first step is > more architectural in nature and I think embodied in these two > thoughts... > > snip.. >>> As the starting point, I'm thinking of making the SCA service registry >>> remotely accessible. It can serve the service descriptions to SCA nodes or >>> clients. The service registry can be managed by an SCA domain manager which >>> receives publication of services from the nodes. > > ...snip... > >> itest\nodes\two-nodes-test which starts to try to use two Nodes in a >> simple inVM domain, > > I'd like to expand a little on what actual scenarios are being > discussed here.. E.g from our *many* previous conversations on this > subject. > > A) domain centric > > Start domain > Add contributions to domain > Start node given domain URL/Node ID > Node pulls contribution from domain > Node resolves unresolved endpoint references via the domain (using > some iface TBD) - this is not in our code today > > B) Node centric - this is not in our code today > > Start domain (could be part of the nodes or the container the nodes > run in and hence started automaitcally) > Start a node given domain URL/Node ID > Add a contribution to the node > Node registers itself with the domain (using some iface TBD) > Node registers information from deployed composites with the domain > (using some iface TBD) > Node resolves unresolved endpoint references via the domain (using > some iface TBD) > > I'd like to be able to do both of these so that, as well as what we > can do today, I can just fire up nodes with contributions and have > them be part of the domain, i.e no need to manually configure domain. > > Above is just a first step that makes management more node centric and > allows for incremental construction of a domain via late reference > resolution. It doesn't say anything about a really dynamic domain, > e.g. where wires can come and go. So lets be clear about what we mean > when we are talking about dynamic behaviour and extend this list > accordingly. > > Simon >
Good points, I need to mull on this some more before responding. In the meantime I will point out that the two-nodes-test is as it is right now just because the Tuscany "Node" is all we have to play with and not because the testcase is intentionally trying to promote a "Node centric" view. While we think about all this its worth being aware of what the spec says: http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd03.pdf Some relevant sections are: 4770 B.10 Domain 3738 11.7 Dynamic Behaviour of Wires in the SCA Domain 3597 11.3 Installed Contribution 3629 11.4 Operations for Contributions There's not much guidance on dynamic operation, 11.7 does say: 3738 For components with references which are at the Domain level, there is the potential for dynamic 3739 behaviour when the wires for a component reference change (this can only apply to component 3740 references at the Domain level and not to components within composites used as implementations): There are only two mentions of a "node" in the specs that i've found: 1198 composite can run in different operating system processes and they can even run on 1299 different nodes on a network. and 3330 An SCA Domain represents a complete runtime configuration, potentially distributed over a series 3331 of interconnected runtime nodes. Both of those use node with a lowercase 'n' so maybe we shouldn't be considering the existing Tuscany Node as such a first class construct. ...ant
