Page History

...

The assembly spec, however, is not prescriptive about how an SCA Domain should be mapped and supported across multiple runtime nodes. Here I believe the term runtime node (or just node) is used to describe a process running an SCA runtime into in which components can be run, e.g. the Java or C++ runtimes that Tuscany is developing.

There are many exisiting technologies that deal with managing compute nodes and job scheduling so it's probably safe to start with to ignore by ignoring the issue of how the system picks processors are picked on which runtime nodes will run and concentrate on how the SCA Domain itself is allocated to the available runtimes. Of the three main layers (are there more?) in the problem.

...

In the first instance we should set the bar fairly low. I.e have the target be running a sample application across two SCA runtimes supporting java component implementations. This pretty much picks up where we were with the distribution support before the core modularization effort and so allows us to leverage the work already done where appropriate. In true don't run before you can walk style we can add more complex features once we can satisfy the simple scenarios. As we pull these ideas together we should be prepared to decide whether an indea idea is destined for the first pass or whether we should park is it for the future.

Distributing SCA Artefacts

...

1. Annotate the existing metadata (the SCDL) with the information
2. Create separate metadata that maps N1 to CA

The first option was chosed chosen for the existing distributed runtime implementation. There would likely have to be a hierarchical nature to these annotations where you migh might mark a composite as belonging to a node or the individual components of a composite. Services and referecence references can be assumed to belong to nodes running the related components.

Notfifying Nodes of Allocations

You can imagine, in the long longer term, a scheme where running nodes are notified what components they should be running. This implies a number of service interfaces and a set of interacting services to maintain this information. In the first instace we could take the simpler approach of using a (shared) file system to pass our messages share the message about what node is running what. In fact we could have each node read all of the model information. In that way each node is able to read the allocation annotaion annotation and determine what artefacts it's interested in based on its allocated name. Not ncessarily very service oriented but gets us going.

It Each node will also be able tell which nodes are running the other artefacts in the domain. This is importation as each node has to invent remote wires to replace the local wiring between components being distributed. CA and CB in our case.

As we may want to swap out this approach in the future we could should consider the mechanism which configures a distributed nodes as replaceable. The default would be to for a node read all of the contributes contributions from an SCA domain on a file system and fire consume the resulting set of contribution requests into the nodetaking note of which ones it has to run itself and, based on this information, which local wires need replacing with remote wires.

Default Binding

Where two components that are connected locally in the SCDL are run on different node we would expect the runtime to be smart enough to invent a remote connection between the two. For the time being we can make some rules about what type of connection is constructued in these circumstances. For example, we could assume that the protocol is going to be WebServices and that each node will be configured with the information required to derive the required host name, port and path required to create and an endpoint for the automaitcally creted automatically created bindings. We don't have to use web services. Anything that works now is an option. We should just pick the one we think will be simplest to use.

...