|Apache Tuscany > Home > SCA Overview > SCA Java > Java SCA Documentation Menu > SCA Java Get Started with Coding||User List | Dev List | Issue Tracker|
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.
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.
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.
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.
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.
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.
Then there is a build stage where the parts of the logical model are linked together, references to services etc.
Then finally the runtime artifacts are created based on the logical model, these include the service endpoints and clients.
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.
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.