This page is in progress. Goal is to provide developers with a quick walk through of key methods so that they can get started coding/debugging. Please help update this page. Thanks.

Bringing Up A Standalone Tuscany Runtime.

When starting to look at the Tuscany SCA Java runtime it is useful to understand what top level calls are made and why. Currently there are several implementations of a "Domain" object that can be used to start up Tuscany.

• DefaultSCADomain - a simple domain implementation that hides most of the details. Used in most test cases to date
• EmbeddedSCADomain - used for embedding Tuscany into other systems
• HotUpdateSCADomain - an example that automatically loads contributions as they change
• EmbeddedNode - A node in a distributed domain

Looking at EmbeddedSCADomain gives a good view of what is necessary to bring up the runtime. The class can be seen in svn here and a test program that uses it can be seen here.

The EmbeddedSCADomain class provides an implementation of an SCA domain that holds all the parts of the runtime together within a single VM. Creating and embedded domain is straighforward.

domain = new EmbeddedSCADomain(cl, domainName);
domain.start();

Calling the start methd on the domain causes all the runtime artifacts to be built. In particular all the runtime extensions, e.g. implementation, binding, databinding, host, are loaded and initialized using the java META-INF/services mechanism.

The next thing to do is load and SCA application into the domain. SCA applications are deployed as contributions. A contribution brings together composite file with all the resources required by the composite file, e.g. .java, .xml. xsd. wsdl etc. in a structure defined by the SCA assembly specification. The EmbeddedSCADomain provides a contribution service for reading contributions. Here the contribution service is retrieved and a contribution, identified by a URL, is added to it.

ContributionService contributionService = domain.getContributionService();
Contribution contribution = contributionService.contribute("http://calculator",
                                                           contributionURL,
                                                           null, //resolver,
                                                           false);

This results in an in memory assembly model (see the assembly module).You can get at the deployable parts of the model by asking the resulting contribution.

Composite composite = contribution.getDeployables().get(0);

The root of the deployable model is a composite which contains a hierarchy of components that will run in the Tuscany runtime. Various steps are now taken to turn the logical assembly model into runnable artifacts so that the components can be started.

First the the model composite gets added to a top level composite that the local domain controls.

domain.getDomainComposite().getIncludes().add(composite);

Then there is a build stage where the parts of the logical model are linked together, references to services etc.

domain.getCompositeBuilder().build(composite);

Then finally the runtime artifacts are created based on the logical model, these include the service endpoints and clients.

domain.getCompositeActivator().activate(composite);

Once all this is done, each composite in the domain can be started independently. It is at this stage, for example, that the servlets required to support web services on an HTTP transport are actually deployed.

for (Composite composite : domain.getDomainComposite().getIncludes()){
    domain.getCompositeActivator().start(composite);
}

The Distrubuted Runtime

When a domain is distributed across more than one VM an extra step is required. Once the logical model has been through the build stage there is a step where information is provided to the runtime so that remote services can be resolved automatically across the network. I.e. we link all of the services and reference in the assembly model into the notion of a distributed domain.

distributedDomain.addDistributedDomainToBindings(composite);