Page History

...

Component Instance - The running component that services requests. A single component definition in a SCDL file may give rise to one or more component instances depending on how the component is scoped (using the @Scope annotation).

Scenarios

1. Starting a runtime

Starting a runtime (collection of nodes) will be a manual task. This task could be automated in the future with some scheduling/provisioning system that is able to select appropriate processors for runtime execution.

Each node in the runtime will be started and will read its node configuration from a file. From this it is able to determine which domains and components it is responsible for and what the scheme edpoints are.

The contributions relating to the domains associated with the node are read from the file system.

Remote references are configured according to the default schemes and and SCDL based configuration.

Any cross node SCA bindings are converted into remote bindings using a point to point protocol. In the process
of doing this the component endpoints that are generated are registered in a central registry (do we need to do this? we could potentially derive them form the node all of the node configurations)

2. Stopping a runtime manually

Stopping a runtime is s manual task. Each node is killed independently.

3. Runtime failure

If a runtime fails then a new runtime is required to replace it. It is assumed that provisioning/deployment of the new runtime is handled by some other tool. When the new runtime startes it has to be able to take the place of the old one by

• loading the appropriate components for the node
• notify all remote refrencing components that the runtime is available
• resolving all reference remote components to other nodes in the runtime.

The configuration of the failed runtime comprises the initial configuration and subsequent configuration updates that the failed node was configured with. Implies that this configuration must be available somewhere.

4 Adding a contribution

Changes in configuration affect the distributed domain in the same way as a stand alone domain, e.g.

• New/Updated components must be activated
  • new services started
  • new references wired
• Removed components must be stopped
  • services stopped
  • references unwired
  • And components that depend on the removed component must also be stopped etc.

Also, with the distributed domain,

• new local references to services now on other runtimes must be resolved depending on SCA binding
  • by refering to local configuration
  • by refering to a registry of endpoints
• new enpoints for local wires must be exposed using the SCABinding
  • in some cases this will require registration of the new endpoint (either centrally or at the runtime holding the source of the wire)

5 Updating a contribution

6 Adding a component to a node

7 Managing service endpoints

7 Choosing a component instance

Cardinality

Image Added

In the non-distributed case a single runtime node loads all contributions and runs all components.
In the distributed case many runtime nodes will be active in a domain.

Each component must be associated (through specific configuration or some matching algorithm) with one or more nodes. Where a component appears in more than one node the runtime is responsible for deciding how messages are routed to the correct node

There is no restriction on the number of component instances a node can create, or indeed how these component instances are run. For example, all component instances could run in a single VM or be distributed across a number of VM's to provide improved performance or failover for example.

Some questions have been raised about cardinality

Should load balancing or HA type scenarios be able to be described in the topology by allowing components to be assinged to more than one node?
Should a runtime be able to run more than one domain?

Scoping The Disitribution Problem

...

So that leaves us to consider how the components of a domain are associated with the runtimes of a domain (2).

Cardinality

domain 1 - 1 runtime 1 - n runtime node

In the non-distributed case a single runtime node loads all contributions and runs all components. In the distributed case many runtime nodes will be active in a domain. Each component deployed in the domain will be associated with a single runtime.

There is no restriction on the number of component instances a runtime can create, or indeed how these component instances are run. For example, all components instances could run in a single VM or be distributed across a number of VM's to provide improved performance or failover for example.

Is is assumed that a component cannot be associated with more than one runtime node. The distribution of component (implementations) for reliability or performance reasons is a product of the implementation of a runtime node and not part of the configuration of the SCADomain.

Some questions have been raised about cardinality

Scenarios

Image Added

Scenarios

starting a node

Run a node exe giving it a node name

stopping a node

Stop a node exe

starting a runtime

All nodes for a runtime are started

stopping a runtime

All nodes for a runtime are stopped

starting a domain

Domain is established in all nodes of a runtime and configuration is provided regarding, for example, scheme base URLS

stopping a domain

All domain compnents are stopped

adding a contribution

The domain (each node in the domain) reads the contribution and makes assigned components ready for use

removing a contribution

All components assoicated with the contribution are stopped and removed

assignComponent

node failure

A new node is started and is configured to match the failed node

configuring endpoints

Service endpoints are configured based on the specified algorithm

choosing a component instance

If a component is assigned to multiple nodes then the runtime is responsible for selecting the appropriate node
based on, scope, conversational status of target component and also non specified goals such as load balancing
Likely to be implemented as a cluster hosting solutionShould load balancing or HA type scenarios be able to be described in the topology by allowing components to be assinged to more than one node
Should a runtime be able to run more than one domain.

SCA Binding

The SCABinding is the default binding used within an SCA assembly. In the runtime in a single VM case it implies local connections. In the distributed runtime case it hides all of the complexity of ensuring that nodes wired between runtimes are able to communicate.

...