Apache Tuscany 2.x Domain/Node Raymond Feng: rfeng@apache.org Simon Laws: slaws@apache.org

Introduction

SCA Domain 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 whose components are deployed and running A set of installed contributions that contain composites, implementations, interfaces and other artifacts

Tuscany Node A Tuscany Node groups one or more top-level components from the SCA domain composite into a unit of deployment that can be started and stopped together in a runtime environment. The Node configuration captures: A collection of contributions (URLs) that are required to run the components on the node One or more deployable composites that describe the components (This is just a simple way to group the top-level components. With tools, we can potentially select the top-level components from the domain composite and generate a deployment composite to describe the group.)

Nodes within an SCA domain Nodes share metadata within the SCA domain

A Domain/Node Scenario

A sample scenario Two deployable composites (Payment and CreditCard) are added to the domain (uri=urn:MyDomain) The domain composite now has two top-level components (Payement and CreditCard components)

Deployment Option #1 One node for Payment and CreditCard components

Deployment Option #2 Two nodes from the same Tuscany runtime instance (node1: Payment, node2: CreditCard)

Deployment Option #3 Two nodes from two Tuscany runtime instances on the same JVM (node1: Payment, node2: CreditCard)

Deployment Option #4 Two nodes from two Tuscany runtime instances on two JVMs (node1: Payment, node2: CreditCard)

Tuscany Design

Primary Players for Domain/Node

Interaction Sequence #1 The JVM is started Tuscany runtime classes are loaded by the JVM into the one or more class spaces. Within a class space, there is at most one class for a given class name One class space per JVM (such as Tomcat deep integration or standalone Tuscany launcher) Multiple class spaces (such as Web applications that package the Tuscany jars)

Interaction Sequence #2 Tuscany runtime is bootstrapped and NodeFactory can be instantiated to encapsulate the ExtensionPointRegistry which manages all the extension points and extensions in Tuscany. In most cases, NodeFactory.getInstance() returns the shared NodeFactory You can also call NodeFactory.newInstance() to creates a new instance with different options

Interaction Sequence #3 TBD: The NodeFactory can be configured with a mapping between domainURIs and registryURIs so that NodeFactory knows the registryURI for a given domain. The initial mapping can be populated by the hosting environment (for example, from an property file) A map can be added to NodeFactory to allow it to be configured programmatically. The NodeFactory can eagerly lookup the DomainRegistryFactory and create/start EndpointRegistry without creating a Node. OSGi remote services needs to start to receive remote endpoints before any node is created. SCAClientFactory implementation may need to connect to a domain when it is created

Interaction Sequence #4 An EndpointRegistry is created (or reused) by a DomainRegistryFactory. The domainURI and domainRegistryURI are both passed in so that the DomainRegistryFactory can multiplex multiple SCA domains over the same physical transport. For example, both Tribes and Hazelcast allows us to get a map by name from the same multicast group. The map name can be used to represent an SCA domain. Zookeeper can have different roots to represent different SCA domains in the same ZooKeeper server.

Interaction Sequence #5 Nodes can be created from NodeFactory. If a Node doesn't configure with a domainRegistryURI, the EndpointRegistry will be looked up by the domain URI. NodeFactory maintains a list of Nodes (potentially by domain)

Connecting to a Domain Registry

Domain Registry Scheme (#1) P2P style (multicast, wka)

Domain Registry Scheme (#2) Centralized