2.x Version2 - 08/09/2010

Overview

This is a review of where we are with the domain support. We have two node style APIs so we need to understand the overall picture and how we can rationalize what we have to clarify and simplify. Here's an updated overview.

Image Added

The following are manually drawm UML style diagrams of the two approaches that are currently working in the code base.

o.a.t.s.node actors (from modules/node-api)

Image Added

o.a.t.s.node2 actors (from modules/domain-node)

Image Added

Some Definitions

From the two node implementations I've tried to draw out the pertinent points and position some SPIs / APIs accordingly for discussion.

domain - as the spec says "a complete runtime configuration, potentially distributed over a series of interconnected runtime nodes."
In Tuscany there may (not yet in 2.x) or may not be a centralized representation of the domain. We have a domain registry (currently just
embodied in the endpoint registry) that provides an interface for accessing information about the domain.

domain uri - the unique identifier of the domain. May or may not contain parameters to configure the domain.

domain name - Not sure but I would say domain uri minus any attached configuration parameters, i.e. the bit after the ? (see http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax)

node - the domain's representative in a class loading space

node factory - creates nodes, associates them with domains and configures them

installed contribution - contribution who's resources are available for use in the domain (in a node)

deployed composite - composite that's deployed into the domain level composite (in a node)

domain registry - an interface that nodes use to share domain level information

The assembly spec defines a running start but it is difficult to distinguish between deployed and running.

Basic SPIs

Embodied on the deployer

load contribution
determine contribution dependencies
build composite
start composite
stop composite

following APIs are built on these

Basic APIs

Sometimes orthoganol to the definitions above

manage domain configuration (currently done through createNode/SCAClient)

• Set domian URI
• Set parameters that describe how to connect to the domain registry

manage node configuration (TBD)

• Associate with domain configuration (via domain URI)
• Specify contributions to pre-load
• Specify composites to deploy
• Specify extension defaults, e.g. binding root URLs

create node (nodeFactory)

• Empty - createNode()
• Preloaded - createNode() taking a variety of parameters

managing contributions - (node)

• add/update/remove contributions

manage composite

• start() / deploy()
• stop() / undeploy()
• could be at domain, node or individual composite level

manage domain

• we don't support a domain manager as yet in 2.x
  The approach thus far is that the individual views of the domain (node) control their part of the domain
  and share information (endpoints) via the domain registry as required. This doesn't rule out the
  domain being managed elsewhere with the nodes being told to run a pre-canned configuration it's just that
  we don't do that at the moment. We should look at what the complete domain registry interface looks like

domain registry

• endpoints - for reference target resolution
• TODO - system level intents and policies - for reference target resolution
• TODO - interface descriptions (as WSDL) - for reference target resolution
• TODO - installed contributions
• TODO - deployed composites
• TODO - nodes - record of running nodes (specifically config, i.e. installed contributions and deployed composites)

2.x Version1 - 26/8/2009

Need to define what the different parts do and if they are all required

...