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...

Distributing SCA Artifacts

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.

Incremental Steps

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.

Allocating Components To Nodes

Consider the following:

Default Binding

User Experience

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)

• domain definition
• as simple as a file structure (based on hierarchy from assembly spec) in a shared file system.
• could implement more complex registry based system
• allocate nodes to the domain
• As simple as running up SCA runtime on each node in the domain.
• For more complex scenarios might want to use a scheduling/management system

Add contributions to the domain

• Identify contributions required to form running service network
  (developers will build/define contributions)
• Contribution these contributions to the domain
• in the simple shared file system scenario I would image they just
  end up in on this file system available to all nodes in
  the domain.

Add contributions to the Virtual Domain Level Composite

• At this point it think we have to know where artifacts are physically
  going to run
• It could be that all runtimes load all contributions and only expose
  those destined for them or, I.e. each node has the full model loaded but
  knows which bits it's running.
• Alternatively we could target each node specifically and ask it to load
  a particular installed contribution and define
  a distributed model.

Manage the Domain

• Need to be able to target the logical service provided by the domain at
  the appropriate runtime node

Terminology

node -

References

1 http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg16971.html
2 http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications