Fork me on GitHub

Documentation >

Archetype specification

The Archetype definition

<cube xmlns:core="fr.liglab.adele.cube.core" xmlns:osgi="org.osgi.cube">
  <archetype id="..." name="..." version="...">

  </archetype>
</cube>

We start by writing the cube tag with the different namespaces of the different extensions that will be used. In the above example, we have used two extensions, the core extension and an osgi extension. We will see after how to use the elements provided by these extensions.

After that, we write the archetype tag with three attributes: id the identifier of the archetype, name a symbolic name and version the version of the archetype.

The archetype definition contains three sub-sections:

archetype definition

Types

In this section, the user declares different types of the managed elements.

  <types>
    <osgi:osgi-gateway id="HomeGateway"/>
    <core:node id="PC"/>
    <core:node id="Server"/>
    <core:component id="CPUTemeratureMeter"/>
    <core:component id="CPUTemeratureAlarm"/>
    <core:scope id="LAN"/>      
  </types>

The managed elements are provided by the different cube extensions (see Managed Elements Catalog). They are abstractions of the real world managed elements.

In this section of the archetype, we create types specific to the use case to manage by combining the different managed elements abstractions. For instance, we have specified above two different nodes (PC and Server) where different self-management policies will apply to each type (See constraints sub-section below).

The core extension provides three main managed element abstractions (or meta-types):

archetype types
  • component: this is an abstraction of software components.
  • node: represents deployment platform or physical devices where component instances execute. Nodes can be organized into virtual groups called Scopes.
  • scope: represents various types of application deployment areas.

At execution time, the different types will be instanciated to represent what is happening in the real managed system. The instantiation is controlled by the Cube agent's Resolver, which validate each occcured instance against a set of user-specified constraints (see Constraints sub-section below).

archetype type instances

Constraints

See Constraints Catalog

archetype constraints

Here is a detailed schema of the Connect constraint and how it integrates to the Cube Resolution Process.

archetype constraints 2

Global-configs

Full Example

<cube xmlns:core="fr.liglab.adele.cube.core" xmlns:osgi="org.osgi.cube">
  <archetype id="net.debbabi.cube.demo" name="Demo Application" version="1.0">

    <types>
      <osgi:osgi-gateway id="HomeGateway"/>
      <core:node id="PC"/>
      <core:node id="Server"/>
      <core:component id="CPUTemeratureMeter"/>
      <core:component id="CPUTemeratureAlarm"/>
      <core:scope id="LAN"/>
    </types>

    <constraints>
      <variables>
        <var id="hg" type="HomeGateway"/>
        <var id="pc" type="PC"/>
        <var id="tm" type="TemperatureMeter"/>
      </variables>
      <core:on-node v1="tm" v2="pc"/>
      <osgi:has-bundle v="hg" b="cilia.jar"/>
    </constraints>

    <global-configs>
      <core:topscopeleader url="cube://localhost:38000"/>
    </global-configs>

  </archetype>
</cube>