On 7/27/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > On 7/24/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > To get the distributed domain support up to a level that is suitable for > > including in the next release I think we need to make the node configuration > > and management more dynamic. > > > > Scenarios > > -------------- > > The current scenario being used to test distributed support is the > > calculator-distributed sample where the CalculatorComponent runs in nodeA > > and the AddComponent and SubtractComponent run on NodeB and NodeC > > respectively. This is a simple stand alone application and I think we should > > continue with it. > > > > There has also been conversation on the list about how the distributed > > domain can help when working in a web app environment. What are the salient > > points here we need to consider? > > > > SCA Binding > > ------------------ > > Currently the code uses JMS to implement the default remote SCA binding. > > The remote SCA binding is used when the system finds that two components > > that are wired together locally are deployed to separate Nodes. As an > > alternative it would be good to support web services here also and have this > > fit in with the new SCA binding mechanism that Simon Nash has been working > > on. > > > > To make a web services SCA binding work we need an EndpointLookup > > interface so that components out there in the distributed domain can locate > > other components that they are wired to. > > > > Node Management > > --------------------------- > > Currently each node runs in isolation and starts a local SCA domain > > configured from .topology and .composite files. It would be good to define > > NodeMaganement interfaces so that this information can be provided remotely > > and so that the node can expose remotely accessible management interfaces, > > for example. > > Join a domain > > Start/Stop domains and components in domains > > Retrieve domain topology and topology changes relevant to the node > > Retrieve default domain URIs for this node > > Record any events that occur in the domain (could be offered as a > > feed) > > > > The domain management interface Ant has recently been added that may > > help us shape this. Also Sebastien's work to allow local domains to be > > modified more dynamically should help make this work. > > > > Distributed Domain Management > > ----------------------------------------------- > > The notion of a distributed domain running across a series of nodes > > gives us the opportunity to provide some centralized control, for example > > Accept configuration changes > > Notify interested nodes/domains that configuration changes are > > available > > Record the endpoints of services offered by each Node/Domain > > Collect together events that occur in nodes (again could be offered > > as a feed) > > > > For both NodeManagment and DistributedDomainManagement, SCA itself seems > > to provide a good foundation for implementing the various management > > services that are required. This is how the implementation to date > > implements its component registry. Defining such components allows us to > > provide different implementations, for example, we could retain the file > > based management we have now for batch operation and create network based > > management components for dynamic runtime environments. > > > > Anyhow, if anyone has any thoughts about what is required or wants to > > get involved in moving this forward then you are most welcome > > > > Simon > > > A few more thoughts > > I am building a few interfaces to formalize the messages involved in > getting the distributed runtime going in its more dynamic guise. Generally I > want to accommodate the case where the nodes of the distributed domain can > run based either on configuration from file or from a central distributed > domain management function. So I want the interfaces to be implementable in > each node or to be proxyable to a distributed domain management function. > The flexibility in the way that the distributed domain runs should be > achievable by choosing different implementations for the management > components. I say should as I don't have an end to end demo working of this > dynamic approach yet. All help gratefully received;-) > > SCABinding > ------------------ > Ant has started work on making the WebService binding work without WSDL > which will make the work on getting the remote SCABinding up much easier. > For endpoint discovery we need something like > ServiceDiscovery > > - FindServiceEndpoint(distributedDomainUri, serviceName) > - RegisterServiceEndpoint(distributedDomainUri, serviceName, url) > > This could also be bought into play in the special case of each Node > discovering the endpoint of the distributed domain management function. In > the case where that configuration is not available locally you would expect > a remote endpoint to be provided > > Node Management > --------------------------- > > The minimum interface for node management could look something like > Node > > - start(nodeName) > - stop() > - JoinDomain(distrbutedDomainUri) > - DomainNodeConfigurationChange(distributedDomainUri) > > So the node operation can be started or stopped. Starting a node would > cause it to go and discover and register with the distributed domain > management service. The node can be asked to join a domain and it can be > notified if there are any domain configuration changes that affect it. > Changes would be retrieved by the node form the distributed domain. Changes > would be provided to the domain implementation at the node though an > interface like > DomainNode > > - createDomainNode(distributedDomainUri) > - SetBaseUri(distributedDomainUri, protocol, uri) > - AddContribution(distributedDomainUri, contributionUri) > - RemoveContribution(distributedDomainUri, contributionUri) > - AddComponent(distributedDomainUri, componentUri) > - RemoveComponent(distributedDomainUri, componentUri) > - StartDomainNode(distributedDomainUri, distrbutedDomainUri) > - StopDomainNode(distributedDomainUri, distributedDomainUri) > - StartComponent(distributedDomainUri, componentUri) > - StopComponent(distributedDomainUri, componentUri) > > I'm not sure how much of this interface should be offered remotely by a > node. Initially the configuration will be offered en masse and only the node > will be interested in pushing configuration through this interface and on > into the various interfaces offered by Tuscany already. I'm a little > confused by the granularity that is intended for incremental updates but > that is a separate thread. > > Distributed Domain Management > ----------------------------------------------- > Distributed Domain > > - GetDomainNodeConfiguration(distributedDomainUri, nodeUri) > - RegisterNode(nodeUri) > > This is minimal as currently I expect the distributed domain management to > simply accept node registrations and then provide their configuration on > request. I.e. no incremental updates in the first instance. > > I'll implement these interfaces in the distributed package and welcome any > feedback. > > Simon > > > I've checked the first pass of these interfaces in [1]. Needless to say they are different from the previous post as I've split them up a bit. Anyhow feedback welcome. The most interesting issue raised in doing this is around contribution provision and the nature of updates that can be made to these contributions. I'll start a separate thread on that. Now onto providing some basic implementation behind this in order to bring up the calculator-distributed sample again.
Simon [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed/src/main/java/org/apache/tuscany/sca/distributed/management/
