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

Compare with Current View Page History

« Previous Version 18 Next »

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.

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

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

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

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 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 domains 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

 SCA Domain/Node Diagrams (PDF) (OpenOffice odg File)

 Composite Application Deployment with SCA Domain

Players:

  • Domain Manager
  • Endpoint Registry
  • Node
  • TuscanyKernel (NodeManager)
  • JVM

Domain:

1) Deployment: Manage SCA contributions, composites and node configurations.

This is the deployment manager that helps SCA assemblers/deployers to
partition the domain composite into smaller composite applications that can
be deployed a specific runtime unit. For example, the administrator can
starts with a deployable composite. The domain manager can then find the
required contributions based on the import/export. The composite application
can then be allocated a node. It ends up with a configuration for a node.

A node can have a fixed configuration to a given composite application. Or
the domain can assign a composite application to the node dynamically based
on the capability of the node (such as implementation/binding/policy types).

In a node-centric view, node configurations can be manually crafted
(programmatically or via node.xml) or locally discovered (from the
classpath).
In a domain-centric view, node configurations are received from the domain
(by connecting to the domain deployment manager or taking a pre-built xml
document).

2) Runtime: Share service descriptions so that we can perform SCA
domain-level wiring. This can be done in "online" mode or "offline" mode.

Online mode: There is a live service registry (centralized or distributed)
that keeps up-to-date information of the domain-level service descriptions.
Offline mode: The domain-level service descriptions are pre-built (or even
pre-resolved) and a SNAPSHOT of that is used. For example, some XML
documents (such as a deployment composite with all the SCA endpoints)
resolved are used to store the domain metadata.

Variations of use cases at different levels

Contributions


Case

Options

a1

A single contribution

a2

Multiple dependent contributions

where each contribution can be directories, jar, zip, bundle, war, ear...

Composites (when one or more are present in a contribution)


 

 

 

b1

one or more composite files but which are not listed in
META-INF/sca-contribution.xml

 

b2

one or more composite files but which are listed in
META-INF/sca-contribution.xml

 

b3

one or more composite files but which are present in
META-INF/sca-deployables (is this still supported?)

 

Nodes (where node = the wrapper for an instance of Tuscany runtime)


 

 

 

c1

node(s) with contributions passed in on command line,
programmatically, in node.xml or discovered from classpath

 

c2

node(s) with contributions pulled from domain manager
(configuration is a URL)

 

c3

node(s) in a webapp

 

c4

node(s) as eclipse project(s)

 

c5

node(s) integrated into Tomcat and Geronimo plugin

 

c6

node(s) as OSGi service listeners? (is that the right term?)

 

c7

node(s) in cloud (what does this mean)

 

One or more nodes may run in a single VM

Scenarios (and implications for what the runtime has to do)


 

 

 

 

1 node configured from command line, programmatically, in node.xml (c1)
1 or more contributions are described in a node configuration
node is started with node configuration
services are immediately accessible

 

 

1 node configured from command line, programmatically, in node.xml (c1)
each node has separate node configuration detailing domain name and
contributions
each node is started with node configuration
nodes exploit distributed registry to locate remote service
endpoints in same domain during wire resolution

 

 

1 node packaged with webapp (c3)
webapp is configured with a filter to run webapp contents as SCA application
webapp deployed to unchanged container

 

 

tomcat instance as a domain (c5)
Webapp (jars/zips) equate to contributions
tomcat extenstion runs contributions in nodes in single JVM
nodes form domain using local version of registry in single JVM

 

 

eclipse workspace as domain (c4)
click on composite and start node
nodes communicate using local registry (simplification of domain
manager approach that is in 1.x)

 

 

 

 

As a review exercise can we correct/complete this list by getting all
of the scenarios people have in their heads out on the table. I
believe we have all imagined different scenarios.

APIs (Resulting from above)

This is a TODO for this review. This is a mildly enhanced version of
what we already have or have discussed at various times.

 

Entities

Operations

Descriptions

Node

Create with configuration
Create with URL of configuration
start
stop

 

Endpoint Registry (should this be domain registry now)

Add/remove/query endpoints
Add/remove/query domain policy (new)

 

Domain Manager

Add/Remove contribution
Add/remove node
Deploy/undeploy composite and associate with node
Start/Stop node (do we need to maintain this in the domain manager?)
Query (some work has been done on this but I've not tried it)
(the domain manage is really made up of a number of service
interfaces including these here and the endpoint registry)

 

  • No labels