You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 25 Next »

Unable to render {include} The included page could not be found.

A space to capture thoughts and notes about how we bring the Tuscany SCA distributed runtime back to life. While the nature of a distributed runtime implies that more than one runtime of more than one type will be involved in a running SCA application I've put this page under the Java SCA subroject as it seems sensible to work with distributing one type of runtime (java) before branching out.

So from the mail thread 1 on this subject here are some initial thoughts and questions...

Distributed SCA Runtimes - Notes

The assembly model specification 2 deals briefly with distributed runtimes in its discussion of SCA Domains

"An SCA Domain represents a complete runtime configuration, potentially distributed over a series of interconnected runtime nodes."

The assembly spec, however, is not prescriptive about how an SCA Domain should be mapped and supported across multiple runtime nodes. Here I believe the term runtime node (or just node) is used to describe a process running an SCA runtime in which components can be run, e.g. the Java or C++ runtimes that Tuscany is developing.

Terminology

SCADomain, Composite, Component, Service, Reference - as used in SCA

Runtime - Provides the runtime environment for SCA component instances. May be as simple as a single Java VM or may be provided by a more scalable and reliable solution such as a compute cluster. Must be able to expose the endpoints required by the services of associated components. Must be able to support the client technology for the references of associated components.

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

Start a runtime

Starting a runtime will be a manual task initially. This task could be automated with some scheduling/provisioning system that is able to select appropriate processors for runtime execution.

  • a file describing the configuration
  • a reference to a registry/manager (or a mechanism for finding this reference) where it can
    • find the configuration information
    • register for configuration notifications or configuration update notifications

Stop a runtime

An manual task in the first instance. In the future would be done through notification.

  • runtimes that reference components in this runtime must be notified so that they can stop or reconfigure these components.

Configure a distributed SCA Domain

The user providing the initial configuration of the distributed domain must

  • annotate the SCDL to assign components to runtimes - the lightweight approach
    OR
  • create a separate configuration that describes this relationship
    • in a file
    • in a registry

Update the configuration of a distributed SCA Domain

Configuration of the domain can be changed in various ways

  • Install Contribution
  • Remove Contrbution
  • Update Contribution
  • Add Deployment Composite (not clear to me why this is different from updating contribution)
  • Update Deployment Composite (not clear to me why this is different from updating contribution)
  • Add component to runtime

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)

Runtime failure

In the case that a runtime fails for whatever reason a new runtime is required.

  • do nothing and raise an error
  • restart the failed rutime
    • taking all the appropriate actions to resolve local wires
    • notify all dependent runtimes of restart

To restart a runtime a model of the configuration of the failed runtime is required based on initial configuration and subsequent configuration updates.

Scoping The Disitribution Problem

There are many exisiting technologies that deal with managing compute nodes and job scheduling. So it's probably safe to start by ignoring the issue of how the system picks processors on which runtime nodes will run (1).

There are also many technologies that providing scalable, robust and/or high performance service hosting solutions. So we can probably also ignore the isssue of how component instances are actually constructed as the runtime representation of components deployed to a runtime (3).

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

Runtimes and Components

In the non-distributed case a single runtime loads all contributions and runs all components. In the distributed case many runtimes 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. The distribution of component (implementations) for reliability or performance reasons is a product of the implementation of a runtime and not part of the configuration of the SCADomain.

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.

When a message oriented binding is uses here we benefit from the abstract nature of the endpoints, I.e queues can be created given runtimeId/ServiceID and messages can be targetted at these queues without knowledge of where the message consumers are physically.

Whene a point to point protocol is used a physical endpoint is required. So a registry of enpoints to SCA bound service is required to allow the SCA binding to find the appropriate target. This registry can either be static, i.e. derived from the base urls given in the domain topology configuration, or dynamic in nature, i.e. set up at runtime.

Modelling The Distributed Domain

Using information from the SCA Assembly specification and the implied requirements of a distribute runtime we can determine what data is required to configure and control the distributed SCADomain. 

SCADomain
  Name (DomainA)
  BaseURI
  Domain Level Composite
    Component (ComponentA)
      implementation
        composite
      Service
      Reference
  Installed Contributions
    Initial Package
      Contribution (file system, jar, zip etc)
        URI (ContributionA)
        /META-INF/
          sca-contribution.xml
            deployable (composite QName)
            import (namespace, location)
            export (namespace)
          sca-contribution-generated.xml
            deployable (composite QName)
            import (namespace, location)
            export (namespace)
          deployables
            *.composite
        *.composite
          URI
          Component (ComponentA)
            Service
            Reference
        Other Resources
          URI
    Dependent Contributions
      Contribution snapshot
    Deployment-time Composites
      *.composite

  Runtime
    name (runtimeA) 
    configuration
      scheme http://localhost:8080/acbd
      scheme https://localhost:442/abcd
      OR
      information about how to get this configuration
    topology 
      DomainA/ComponentA
      DomainA/ComponentB
      OR 
      information about how to get the topology
        binding.ws http://my.registry.com

(question) What else is required?

We already know how SCDL is used to represent the application composites. The runtime configuration presents a new set of components, interfaces, services and references.

A discussion is ongoing re. how the runtime meta data should be represented. 3. For example;

File based configuration - using a semi-SCDL like format.

<domain name="domainA">
  <runtime name="runtimeA">
    <scheme name="http" baseURI="http://$host:8080/acbd">
    <scheme name="https" baseURI="https://$host:8090/acbd">
    <component name"topology"/>
      <implementation.java class="???"/>
      <reference name="registry">
        <binding.inline>
           <component name="CalculatorServiceComponent"/>
           <component name="AddServiceComponent"/> 
        </binding.inline>
      </reference>
    <component>   
  </runtime>
  
  <runtime name="runtimeB">
    <scheme name="http" baseURI="http://$host:8080/acbd">
    <scheme name="https" baseURI="https://$host:8090/acbd">
    <component name"topology"/>
      <implementation.java class="???"/>
      <reference name="registry">
        <binding.inline>
          <component name="AddServiceComponent"/> 
        </binding.inline>
      </reference>
    <component>   
  </runtime>
</domain>

If we wanted to go the whole hog and imply that the binding for retrieving component assignments can be changed we may want to do something like:

      <component name"topology"/>
        <implementation.java class="???"/>
        <reference name="registry">
          <message name="getAssignedComponents">
            <response>
              <component name="CalculatorServiceComponent"/>
              <component name="AddServiceComponent"/> 
            </reponse>
          </message>
        </reference>
      <component>

Message Based Configuration

If we wanted to make the component assignement message driven then of course we could define a service interface for the topology service. With suitable methods:

assignComponent()
removeComponent()

Other Services

With this kind of approach we could also define other useful services for the runtime, for example, management and notification.

We do need to work out how these services are managed by the runtime. How much special treatment do they need.

Network based configuration

Managing The Distributed Domain

Incremental Steps

Stage 1 - 1st pass simple scenario

  • Domain Configuration - a text editor
  • Events - only provided at runtime startup
  • Configuration - a file system
  • Messages - JMS

Stage 2 - More efficient SCABinding implementation

  • Domain Configuration - a text editor
  • Events - only provided at runtime startup
  • Configuration - a file system
  • Messages - a faster point to point protocol, e.g. JSONRPC, required some endpoint registry

Stage 3 - Integration with management/provisioning
?

Stage 4 - Dynamic configuration

  • Domain Configuration - A tool for creating changes and events
    • What sort of events should be supported here
  • Events - initial startup and changes
  • Configuration - repository
  • Messages - a faster point to point protocol, e.g. JSONRPC, required some endpoint registry

Stage 1 Code Changes

Currently the runtime has the following structure

SCADomain
ReallySmallRuntime
Contribution
Assembly Model
DomainComposite (from domain)
Deployed composites refering to activated assembly model

Adding the distributed dimension to this we get something like

DistributedSCADomain
Topology
Runtime Model
Component mapping
Binding URL config
DistributedRuntime
Contribution
Assembly Model
DomainComposite (from domain)
Deployed composites based on topology

References

1 http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg16971.html
2 http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
3 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18613.html

  • No labels