SCA Java Get Started with Coding (TUSCANY) edited by Dan Becker
Page:
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Get+Started+with+Coding
Changes:
http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=64177&originalVersion=2&revisedVersion=3
Content:
---------------------------------------------------------------------
(on) 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.*
h1. 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|http://svn.apache.org/repos/asf/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/sca/host/embedded/impl/EmbeddedSCADomain.java]
and a test program that uses it can be seen
[here|http://svn.apache.org/repos/asf/tuscany/java/sca/modules/host-embedded/src/test/java/org/apache/tuscany/sca/host/embedded/SCADomainTestCase.java].
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.
{code}
domain = new EmbeddedSCADomain(cl, domainName);
domain.start();
{code}
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.
{code}
ContributionService contributionService = domain.getContributionService();
Contribution contribution = contributionService.contribute("http://calculator",
contributionURL,
null, //resolver,
false);
{code}
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.
{code}
Composite composite = contribution.getDeployables().get(0);
{code}
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.
{code}
domain.getDomainComposite().getIncludes().add(composite);
{code}
Then there is a build stage where the parts of the logical model are linked
together, references to services etc.
{code}
domain.getCompositeBuilder().build(composite);
{code}
Then finally the runtime artifacts are created based on the logical model,
these include the service endpoints and clients.
{code}
domain.getCompositeActivator().activate(composite);
{code}
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.
{code}
for (Composite composite : domain.getDomainComposite().getIncludes()){
domain.getCompositeActivator().start(composite);
}
{code}
h1. 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.
{code}
distributedDomain.addDistributedDomainToBindings(composite);
{code}
---------------------------------------------------------------------
CONFLUENCE INFORMATION
This message is automatically generated by Confluence
Unsubscribe or edit your notifications preferences
http://cwiki.apache.org/confluence/users/viewnotifications.action
If you think it was sent incorrectly contact one of the administrators
http://cwiki.apache.org/confluence/administrators.action
If you want more information on Confluence, or have a bug to report see
http://www.atlassian.com/software/confluence