A space to capture thoughts and notes about how we bring the Tuscany SCA distributed runtime back to life. While the nature of a distributed runtime implies that more than one runtime of more than one type will be involved in a running SCA application I've put this page under the Java SCA subroject as it seems sensible to work with distributing one type of runtime (java) before branching out.
So from the mail thread 1 on this subject here are some initial thoughts and questions...
The assembly model specification 2 deals briefly with distributed runtimes in its discussion of SCA Domains
"An SCA Domain represents a complete runtime configuration, potentially distributed over a series of interconnected runtime nodes."
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 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 the issue of how 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.
1. SCA Artefacts (The SCA Domain/Assembly Model)
2. SCA runtime nodes
3. Physical Hardware/Scheduling/Virtualization
Lets worry about how 1 is mapped to 2.
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 we should be prepared to decide whether an indea is destined for the first pass or whether we should park is for the future.
Somehow we need to tell each runtime which parts of the SCA model to run. So, if CA is to run on N1 we have have two options.
The first option was chosed for the existing distributed runtime implementation. There would likely have to be a hierarchical nature to these annotations where you migh mark a composite as belonging to a node or the individual components of a composite. Services and referecence can be assumed to belong to nodes running the related components.
You can imagine, in the long 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 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 and determine what artefacts it's interested in. Not ncessarily very service oriented but gets us going.
It 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 consider the mechanism which configures a distributed nodes as replaceable. The default would be to read all of the contributes from an SCA domain on a file system and fire the resulting set of contribution requests into the node.
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 endpoint for the automaitcally creted 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.
So I would expect a manager of a distributed SCA runtime to go through a
number of stages in getting the system up and running.
Define an SCA Domain (Looking at the mailing list Luciano is thinking these thoughts also)
Add contributions to the domain
Add contributions to the Virtual Domain Level Composite
Manage the Domain
node -
1 http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg16971.html
2 http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications