Chapter 11. Running and embedding Tuscany
- Understanding basics of the Tuscany runtime environment
- Running Tuscany in a standalone, web, or distributed environment
- Embedding Tuscany within a managed application container
Tuscany can be hosted in many different environments. It can be run standalone or invoked programmatically as a library. Tuscany is integrated with web containers such as Tomcat, Jetty, and WebSphere to enable web applications with SCA. Tuscany can also be embedded within other application containers such as Java EE or OSGi-based containers. When running Tuscany standalone, you use the Tuscany launcher to run an SCA application from the command line or within an IDE. In the other cases, the host environment manages the Tuscany runtime and SCA applications.
All of these options give you the flexibility to run your SCA applications in the environment of your choice. You aren’t restricted to a single way of starting the runtime. If you find that you need to embed the runtime to suit your particular needs, then Tuscany provides a set of APIs to allow you to do this.
In this chapter we’ll walk through the various options that Tuscany provides for running SCA applications. Some of the options have been used in previous chapters. You can find various samples in the following locations:
- launchers/*
- contributions/creditcard-payment-webapp
Let’s start by looking at the nodes and the SCA domain within which they run.
11.1. Understanding the Tuscany runtime environment
In chapter 3 you learned how to run an SCA composite application in a local domain with a single execution node or as a distributed domain with multiple execution nodes. Before we start to explore different options to host Tuscany, you’ll first need to understand the key actors, such as the SCA domain and the Tuscany node, that make up the runtime environment for SCA applications. We’ll explain what the domain and node are, what information needs to be configured for a node, and how the hosting environment controls the node and interacts with other nodes in the same SCA domain.
11.1.1. The SCA domain and Tuscany nodes
An SCA domain manages a set of composite applications that can be connected using SCA wires and constrained by the same policy definitions. An SCA domain consists of the following:
- A virtual domain-level composite (that is, a domain composite) whose components are deployed and running
- A set of installed contributions that contain composites, implementations, interfaces, and other artifacts
An SCA domain represents a complete configuration of the SCA assembly. The components within an SCA domain can be hosted by one or more runtime environments that provide the necessary technology infrastructure. Tuscany introduces the node concept to represent a group of components (typically declared in the same composite) that can be started, executed, and stopped together on a Tuscany runtime. Figure 11.1 illustrates an example of such mapping. The composites are part of the TuscanySCATours scenario. It deals with travel booking, and it depends on the Payment composite to handle payments made by the customer. The CreditCardPayment composite is a service provider that processes credit card transactions.
Figure 11.1. SCA Composite applications managed by the SCA domain are run on Tuscany nodes.
In this example, three Tuscany nodes are used to run the applications. Two nodes are run on one JVM (JVM1). Node1 hosts the components from the SCATours composite whereas Node2 hosts components from the Payment composite. Node3 is started on a different JVM (JVM2) to run components from the CreditCardPayment composite.
Tuscany is quite flexible in how it maps the domain composite to different node topologies. For example, you can run all three composites on one single node or run each of the composites on a different node. These mappings can be described in the Tuscany node configuration.
11.1.2. Tuscany node configuration
A Tuscany node is configured to run a composite application, which could be the entire SCA domain composite or a subset of this composite. The configuration captures the following information:
- A collection of contributions that are required to run the components on the node
- One or more deployable composites that describe the components
- A list of binding base URIs that tells Tuscany what addresses are used to publish the service endpoints
To map an SCA domain to Tuscany nodes, you can partition the domain composite into one or more groups of components (denoted by composites) that are suitable to be run together. Each group of composites is configured as a Tuscany node.
SCA components typically depend on artifacts from SCA contributions such as the interface, Java implementation class, or XML schema. A list of installed contributions will be selected from the SCA domain for a node.
You can also specify the default configuration for the communication infrastructure that a node provides. For example, a service with binding.ws can be published on one node as http://node1:8080/component1/service1/binding1 and on another node as http://node2:8085/component1/service1/binding1. The node configuration defines which HTTP ports to use by default.
The node configuration can be manually defined, automatically discovered, or provided by the domain manager online or offline, depending on how the node is run. We’ll explore the various options in the next sections.
11.1.3. Hosting options for a Tuscany node
The hosting environment for Tuscany controls how to configure, create, start, and stop a node. Each environment uses various approaches to handle the following aspects:
- How to create a node configuration
- From a configuration file
- From the domain manager
- From a list of command-line arguments
- From what’s in the environment (classpath, repository, and so on)
- How to control the lifecycle of a node
- Start/stop the node using a launcher
- Start/stop the node explicitly within the embedding application
- Start/stop the node from a lifecycle listener of the host environment, such as the ServletFilter or ServletContextListener or the OSGi Bundle Activator, Service Listener, or Bundle Listener
- Are there SCA wires that go across components that are hosted on different nodes?
- Components in the node access services only in the same node.
- Components that are wired by SCA run on different nodes.
- How to find endpoint descriptions of other SCA services in the same domain but running on a different node
- From a domain registry
- From a local file
- How to initiate component interactions
- Access the SCA services from a remote client
- Access the SCA services locally
- From a component that’s early initialized
- From a launcher that knows the client component
These options are illustrated in figure 11.2.
Figure 11.2. The SCA domain is mapped to a set of Tuscany nodes to be run in different environments, which can use different ways to configure, create, start, and stop a node.
As shown in figure 11.2, the SCA assembly represented by the domain composite (A) can be partitioned into groups of components. This is typically done by using one or more composites that define the components. You can also use a deployment composite to regroup the components. Each group will be hosted by a Tuscany node (F). You’ll define the domain/node mapping using the node configurations (B). You can bootstrap the Tuscany runtime in different environments (D) to provide the infrastructure (E) for one or more nodes. Depending on the hosting environment, you can provide the configuration for a node using different mechanisms (C) and then create and start nodes to run the components.
Tuscany provides the SCANodeFactory and SCANode APIs so that different hosting environments can use them to create an SCANode from a node configuration and start or stop the SCANode to run the composite application. Each form of hosting option for Tuscany ultimately calls the SCANodeFactory and SCANode APIs.
In the following sections we’ll look at the hosting options Tuscany provides to help you understand and decide which one best fits your needs.
11.2. Running Tuscany standalone
Let’s start with the simplest form: running the SCA application from the command line. Tuscany comes with a launcher that supports many implementation and binding types out of the box in a standalone JVM process. You can start your SCA application using a Java command, passing the list of SCA contributions as a parameter. No external application servers or installation steps are required. Let’s give it a try with the creditcard-payment-jaxb contribution. To run it with the Tuscany node launcher from the command line, type
java -jar <TUSCANY_HOME>modules uscany-node-launcher-<version>.jar
creditcard.composite scatours-contribution-creditcard-payment-jaxb.jar
The precise location of the contribution JAR file will vary depending on whether you have the src or binary sample distribution. When this command is issued, the Tuscany node launcher creates a node configuration using the arguments that are passed in for the deployable composite and contributions. The launcher discovers the JARs in the Tuscany distribution and uses them to bootstrap the Tuscany runtime. The configured node is created and started in order to run the application. You can verify it by pointing your browser to http://localhost:8082/CreditCardPayment?wsdl to get the WSDL document for the service.
The standalone Tuscany runtime can embed other frameworks such as Tomcat/ Jetty, Axis2, and ActiveMQ to provide protocol stacks such as HTTP, SOAP, or JMS for SCA bindings. It can also embed Spring for implementation.spring and Apache ODE for implementation.bpel. The node launcher is illustrated in figure 11.3.
Figure 11.3. The Tuscany node launcher bootstraps the Tuscany runtime and creates a node to load and run the composite application.
The launcher operates as a container where SCA components can expose services with certain protocols using bindings. In the credit card payment application, a web service is published on behalf of the binding.ws configuration for the CreditCardPayment service. There’s no need to start an HTTP server manually.
It’s also possible to run a composite application with multiple contributions. For example, you can run the Payment and CreditCardPayment composites as follows:
java -jar <TUSCANY_HOME>modules uscany-node-launcher-<version>.jar -
scatours-contribution-payment-java.jar scatours-contribution-creditcard-
payment-jaxb.jar
In this case you omit the deployable composite (using – as the first argument) and use two JARs as the contributions.
The Tuscany node launcher provides a simple way to run SCA composite applications directly from one or more contributions in a standalone JVM process. It provides the infrastructure out of the box for the common implementation and binding types without extra installation and configuration of the stacks. This hosting option is useful if the application is built using SCA to expose services with protocols that can handle requests from external clients. Because the launcher is running as a standalone JVM, you’ll need to invoke SCA components from a remote client.
The Tuscany node launcher shields user applications from setting up the Tuscany runtime and calling Tuscany APIs to control the node. There are also use cases where programmatic access to the Tuscany runtime is required.
11.3. Running Tuscany using APIs
Certain types of application need to invoke Tuscany programmatically by using Tuscany as a library for embedding an SCA runtime. Here are some examples:
- The application is managed or launched by another means such as the OSGi framework, Eclipse RCP, or JUnit runner.
- The application needs to access SCA services locally so that SCA components can be triggered without a remote client.
- The application needs to start or stop Tuscany programmatically for testing and debugging purposes.
Tuscany provides a simple node API to bootstrap the runtime and manage nodes. It gives users, developers, and embedders the ability to interact with Tuscany with full control. Figure 11.4 shows a simple customized launcher from the TuscanySCATours application to demonstrate how to interact with Tuscany node APIs.
Figure 11.4. Tuscany nodes can be programmatically configured and created. Application code uses the node APIs to start the node, look up a service, invoke it, and stop the node.
As illustrated in figure 11.4, the typical sequence of Tuscany API calls is as follows:
1. Create one or more SCAContribution instances using the contribution URI and location URL.
2. Create an instance of SCANodeFactory and use it to create an instance of SCA-Node from the deployable composite and one or more SCAContribution instances.
3. Start the SCANode.
4. Get a local proxy for the given SCA component.
5. Invoke the service to perform business logic.
6. Stop the SCANode.
Steps 1 and 2 can be triggered by hooking the methods to lifecycle events of the hosting environment. The following example uses JUnit 4 annotations to start Tuscany with a local contribution under the target/classes folder, test the service calls, and then stop.
Listing 11.1. A JUnit test case that calls Tuscany APIs
The JUnit code uses a method annotated with @BeforeClass to start the Tuscany node 
. One test method looks up the CreditCardPayment SCA service 
and invokes the authorize() method 
. Finally, the Tuscany node is shut down by the method annotated with the @AfterClass annotation 
.
As an alternative to using a standalone application, many hosting environments provide a means to manage applications, including deployment and lifecycle. It’s often desirable to leverage these capabilities to make Tuscany’s SCA execution environment available for such applications. Java EE web containers are one of the popular technologies for hosting applications. Let’s explore how to integrate Tuscany with web applications.
11.4. Running Tuscany with web applications
Web applications have evolved beyond the HTML-based presentation layer. More and more web applications integrate with backend enterprise services to provide business services over HTTP. With the emergence of cloud computing and the availability of cloud infrastructure such as Amazon EC2 and the Google App Engine platform, it’s often desirable to enable service construction and composition in a simple and flexible way so that you can mash up business applications.
What help can Tuscany and SCA provide for web applications? You can develop composite applications using the SCA programming model to assemble components, access existing web services or EJB session beans, and expose SCA component services over HTTP-based protocols such as Web Services, JSON-RPC, and Atom or RSS feeds. SCA can leverage the security and transaction infrastructure to enforce quality of service (QoS) in a consistent fashion. In this section we’ll look at how to package Tuscany SCA applications inside Java EE web application archive (WAR) files.
To enable SCA within web applications, Tuscany provides a simple mechanism for packaging the runtime JARs together with the application artifacts into WAR files. An SCA composite is packaged inside a WAR file alongside the application artifacts and the Tuscany JARs and their dependencies. You can directly deploy the WAR file to standards-based web containers such as Tomcat, Jetty, and IBM WebSphere. Container-specific deployment descriptor files may also be added.
As we mentioned in chapter 8, a Tuscany-provided servlet filter is configured to start up or shut down the Tuscany runtime when the web application is started or stopped. The Tuscany filter is also responsible for dispatching HTTP requests to HTTP-based bindings such as Web Services, JSON-RPC, and Atom/RSS Feed bindings. Figure 11.5 shows how the Tuscany servlet filter bridges between the web application framework and SCA.
Figure 11.5. Tuscany runtime JARs are packaged in the WAR to allow the web application to run as an SCA contribution.
Let’s look at the structure of the Tuscany-enabled web application. There are a few important files and folders in the WAR, as shown in table 11.1.
Table 11.1. Important files in a Tuscany SCA–enabled web application
|
File in the WAR |
Description |
|---|---|
| META-INF/sca-contribution.xml | Defines the deployable composites for a given contribution |
| WEB-INF/web.composite | Describes the assembly for the web application |
| WEB-INF/web.xml | Configures the web application with a Tuscany servlet filter |
| WEB-INF/lib | Contains all the required Tuscany JARs and their dependencies |
As shown next, you configure the web.xml file with a Tuscany servlet filter, which is responsible for managing the node and dispatching HTTP requests to the corresponding SCA service-binding listeners.
11.4.1. Configuring WEB-INF/web.xml
To enable a web application with Tuscany SCA, you’ll need to configure a servlet filter from Tuscany in the WEB-INF/web.xml file. The following listing shows an example.
Listing 11.2. Sample web.xml for a Tuscany-enabled web application
The filter will be triggered upon the first HTTP request to this web application and will create and start a Tuscany node. The node instance is set in the servlet context as an attribute so that it can be accessed later by JSPs and servlets. When the web application is stopped, the filter is called to stop and destroy the Tuscany node.
11.4.2. Customizing class loading policy
The Tuscany runtime JARs and their dependencies are packaged in the WEB-INF/lib folder within the WAR file. Some third-party JARs such as the stax-api and Woodstox implementations might conflict with those from the web container. The good news is that most Java EE application servers, such as Apache Geronimo and IBM WebSphere, allow different settings for the class-loading policy. To ensure that the Tuscany runtime and its dependency classes will be loaded from the WEB-INF/lib folder, you’ll need to configure the class-loading policy so that it creates an isolated environment for the Tuscany runtime without interference from other JARs shipped by the application server (for example, the Axis2 JARs shipped by Geronimo). Listing 11.3 gives an example of the Geronimo deployment descriptor. The <d:inverse-class-loading> element is used to indicate that classes from the web application should be loaded in preference to classes provided by the application server.
Listing 11.3. Sample WEB-INF/geronimo-web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0"
xmlns:d="http://geronimo.apache.org/xml/ns/deployment-1.2">
<d:environment>
<d:moduleId>
<d:groupId>org.apache.tuscany.sca</d:groupId>
<d:artifactId>sample-calculator-ws-webapp</d:artifactId>
<d:version>1.0-SNAPSHOT</d:version>
<d:type>war</d:type>
</d:moduleId>
<d:inverse-classloading />
</d:environment>
</web-app>
Please note that Tomcat, by default, has the child-first class-loading policy (where the classes packaged in the WAR file take precedence) for web applications, so no extra class loader configuration is needed.
11.4.3. Deploying Tuscany-enabled web applications
After the WAR file is created, you can deploy it to the web container. For Tomcat, you can copy it into the webapps folder. When the web container starts, the Tuscany node will be created and started for the web application when the application is started.
Using this approach, the Tuscany runtime is enclosed within the web application and isolated from other web applications. You can deploy more than one Tuscany-enabled web application in the same web container without them interfering with each other.
Hosting Tuscany using a web application provides a simple but powerful option to run SCA applications within a web container. It’s easy to produce a WAR file. With SCA, web applications can compose business logic, invoke external services, and expose services to a Web 2.0 frontend or to business partners. Meanwhile, you’ll get the HTTP-based binding and policy infrastructure for free because they’re part of the web container. Tuscany-enabled applications can leverage the Web Services, JSON-RPC, and Atom bindings out of the box.
So far we’ve explored the hosting options for Tuscany nodes that have been pre-configured and resolved. These nodes don’t rely on the information from other nodes in the same SCA domain. In the following section, you’ll learn how to configure and run distributed nodes.
11.5. Configuring distributed nodes
In chapter 3, we created an SCA domain from scratch using the Tuscany Domain Manager GUI and ran a distributed Tuscany application using the Tuscany domain manager. The Domain Manager GUI saves the domain configuration as a number of XML files. As an alternative to using the Domain Manager GUI to create and update the configuration files, you can edit the domain configuration files directly. Editing the configuration files can be a simpler way of creating or modifying a domain configuration than using the Domain Manager GUI, especially if you need programmatic control of the contents of these files. In addition, editing these files provides additional flexibility (for example, when configuring bindings) that isn’t possible when using the Domain Manager GUI as it stands at the time of writing.
To help you understand how to edit these configuration files, this section describes what the files contain. After creating or editing the files as described in the rest of this section, you can run the Tuscany domain in exactly the same way as we described in chapter 3 except for omitting the steps that refer to using the Domain Manager GUI.
There are two important words of warning before we dive into the details of the configuration files: Be careful! The format and contents of the configuration files are straightforward, and it isn’t difficult to create or modify them using a text editor. But if you make a mistake when doing this (even the tiniest typo), the domain manager won’t work properly. It’s likely to malfunction in mysterious ways with no indication of what’s causing the problem. So if things aren’t working correctly after you’ve edited the configuration files, go back and double-check the contents of these files. If you can’t see a problem, check them again!
In the following sections, we’ll walk you through the manual steps required to define an SCA domain, including installed contributions, deployed composites, runtime nodes, and base URIs of published services for each binding type. The files are needed in Tuscany to run a distributed composite application within an SCA domain. We’ll start by defining which contributions are part of the domain.
11.5.1. Defining the contents of the domain code repository
The domain code repository is defined by the contents of the workspace.xml file. The following listing shows an example.
Listing 11.4. Example workspace.xml file for a domain with three installed contributions
In listing 11.4, each contribution installed in the domain code repository is defined by a <contribution> element within the <workspace> element. In this example the contribution locations are specified as "file:" URLs relative to the domain manager’s execution directory. There’s also a special <contribution> element that’s used internally by the domain manager.
11.5.2. Specifying the deployed composites
The deployed composites are listed in the domain.composite file. An example of this file is shown here.
Listing 11.5. Deployed composites are listed in the domain.composite file.
<?xml version="1.0" encoding="UTF-8"?>
<composite local="true" name="domain"
targetNamespace="http://tuscany.apache.org/xmlns/sca/1.0"
xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:ns1="http://www.osoa.org/xmlns/sca/1.0">
<include name="ns2:Trips" uri="introducing-trips"
xmlns:ns2="http://goodvaluetrips.com/"/>
<include name="ns2:Tours" uri="introducing-tours"
xmlns:ns2="http://tuscanyscatours.com/"/>
<include name="ns2:Client" uri="introducing-client"
xmlns:ns2="http://client.scatours/"/>
</composite>
Listing 11.5 is the domain manager’s definition of the SCA domain composite. It contains <include> elements for all the composites that have been deployed to the domain. The uri attribute on the <include> element is a Tuscany extension to SCA and is used to specify the URI of the contribution that contains the composite.
11.5.3. Defining the nodes in the execution cloud
The last file in the domain manager’s working directory is called cloud.composite, and it contains a list of execution nodes for deployed composites. The following listing shows an example of this file.
Listing 11.6. Execution nodes for deployed composites
<?xml version="1.0" encoding="UTF-8"?>
<composite local="true" name="cloud"
targetNamespace="http://tuscany.apache.org/xmlns/sca/1.0"
xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:ns1="http://www.osoa.org/xmlns/sca/1.0">
<include name="ns2:TripsNode"
uri="http://tuscany.apache.org/cloud"
xmlns:ns2="http://tuscany.apache.org/cloud"/>
<include name="ns2:ToursNode"
uri="http://tuscany.apache.org/cloud"
xmlns:ns2="http://tuscany.apache.org/cloud"/>
<include name="ns2:ClientNode"
uri="http://tuscany.apache.org/cloud"
xmlns:ns2="http://tuscany.apache.org/cloud"/>
</composite>
Listing 11.6 is the domain manager’s definition of the execution cloud (distributed network of execution nodes) for the domain. Each execution node is represented by an <include> element giving the name of the node. The uri attribute and XML namespace of an execution node are always "http://tuscany.apache.org/cloud".
11.5.4. Configuring bindings for the nodes in the execution cloud
In addition to the three configuration files in the working directory of the domain manager, the working directory has a cloud subdirectory, which contains a file for each execution node. These files have a file extension of .composite and a filename corresponding to the node name. The next listing shows the TripsNode.composite file, which represents the TripsNode execution node.
Listing 11.7. The TripsNode.composite file representing the TripsNode execution node
In listing 11.7 the TripsNode composite contains a single special component that’s also called TripsNode to describe the node configuration
using XML. This component has an implementation type of implementation.node.[1] The <implementation.node> element has a composite attribute specifying the name of the composite that will be run by this execution node and a uri attribute identifying the contribution that contains this composite. There’s a single service named Node with a binding element for each binding used by services running on this node. This binding element has a uri attribute with the protocol, host, and port used by the node’s runtime to expose services with this binding type.
1 The <implementation.node> element is defined in a Tuscany-specific XML namespace instead of the regular SCA namespace because it’s a Tuscany extension that isn’t part of the SCA specifications.
The Domain Manager GUI always creates node configuration files with binding elements for binding.sca, binding.ws, binding.http, binding.jsonrpc, and binding.atom, with all of these having the same protocol, host, and port information as shown in listing 11.7. However, the domain manager runtime can handle any combination of binding elements in the node configuration file, with either the same settings for protocol, host, and port for all bindings or different settings for protocol, host, and port for different bindings. Any bindings that aren’t used by this execution node don’t need to appear in its Node service configuration. For example, the Node service could be defined as follows:
<service name="Node">
<binding.sca uri="http://node1.mydomain.com:8091" />
<binding.ws uri="http://node2.mydomain.com:8092" />
<binding.foo uri="foo://node3.mydomain.com:8093" />
</service>
This means that any service endpoints using binding.sca are hosted on port 8091 of node1.mydomain.com, any service endpoints using binding.ws are hosted on port 8092 of node2.mydomain.com, and any service endpoints using binding.foo (a user-defined binding) use the foo: protocol and are hosted on port 8093 of node3.mydomain.com.
The domain manager uses the node configuration endpoint information to customize the service and reference bindings in the deployed composites that are passed to the execution nodes. In this way all of the services of the nodes in the distributed runtime will expose unique endpoints and can communicate with each other. You saw some examples of doing this in section 3.2.5, so we won’t repeat them here.
In this section you’ve seen how you can modify or create a domain configuration without going through the Domain Manager GUI. This can be useful either for automating the domain configuration process or for providing more flexibility than the Domain Manager GUI can support.
Next, we’ll look at how the Tuscany runtime can be embedded into other containers such as a Java EE container.
11.6. Embedding Tuscany with a managed container
We’ve explored several options provided by Tuscany out of the box for running SCA composite applications. With this understanding of the responsibilities for a host environment and how it interacts with Tuscany, it’s time to add a bit more information for those who want to embed Tuscany in their own managed environment, such as an OSGi framework or Java EE container. Let’s recall the roles of a host environment:
1. Configure the node—Find out the deployable composites and required contributions that constitute the group of components to be run on this node.
2. Provide the infrastructure for a node—Plug in host-* modules to provide hooks for binding protocols, QoS system services, and implementation engines/frameworks.
3. Control the lifecycle of a node—Leverage the SCANodeFactory and SCANode APIs to create, start, or stop a node.
These responsibilities are illustrated in figure 11.6.
Figure 11.6. A managed container that embeds Tuscany and provides infrastructure for SCA. It calls Tuscany APIs to manage the configuration, creation, and lifecycle of the node.
To embed Tuscany, you’ll typically need to plug code into the hosting environment. First, you’ll choose how to group components from the SCA domain composite to configure a node. This configuration information can be retrieved from the domain manager or can be loaded from a local file. Second, a managed environment typically has a way to control the lifecycle of the applications it manages. For example, an OSGi bundle listener or web application context listener are able to listen for the addition or removal of applications. The host can associate Tuscany nodes with such a boundary and call node APIs to create, start, or stop the node appropriately.
Tuscany binding, implementation, and policy features can be provided in different ways by different hosting environments. You can build new extensions for the Tuscany extension APIs to provide these features in host-specific ways if required. For example, a web container host can provide an HTTP service as a servlet, whereas an OSGi container can use the OSGi HTTP service. Chapter 13 discusses the extension APIs in more detail.
11.7. Summary
As you’ve learned in this chapter, SCA applications can be run in different environments using the various hosting options that Tuscany provides. The environment can be as simple as a command-line launcher or a web application where the SCA application will run in a single node in a single JVM.
For more complex and distributed scenarios, the Tuscany domain manager provides a mechanism for deploying SCA applications in a distributed environment within an SCA domain. It achieves this by configuring the composite files that are deployed to a set of distributed nodes.
If none of the hosting options provided by Tuscany suit your needs, you can also embed Tuscany in your own container to add the power of SCA into your application server.
Now that you understand how to start the Tuscany runtime in various environments, let’s move on and pull some of the strands of the book together by taking a look at the TuscanySCATours travel-booking application in all its glory.