newton
Newton
 

Contracts And Features

Contracts, features and assessors are the mechanism via which a Newton Provisioner negotiates with other Newton instances to find a location to install a composite: features and assessors are properties of a specific Newton instance; contracts are associated with a specific composite.

Another way of saying this is that contracts specify the things a developer knows the composite requires in order to run, where as features and assessors specify the system administrators ability to provide such features on a given Newton instance.

Features

Newton instances are attributed with a list of features, these are key value pairs that describe details about the overall environment the instance provides. The list of features is extensible via the FeaturesProvider interface which is aggregated into the instance via the local OSGi registry.

Assessment

The CompositeAssesor interface is used to check whether or not a specified Composite may be installed within a Newton instance. CompositeAssessors are aggregated into the instance from the local OSGi registry.

Assessors are chained together in a list ordered via priority (highest priority first). Each assessor is queried in turn as to the cost - expressed as an integer value where -1 <= cost <= Integer.MAX_VALUE – to host a composite based on the list of current installs.

If -1 is returned this effectively means the cost is infinite and the composite should not be installed here at all and causes the Newton instance to stop querying the chain of assessors and simply rejects the composite install.

Any other value is summed onto the aggregate cost from all assessors in the chain. The total cost is returned to the provisioner which then installs the composite to the instance that provides the lowest cost.

Contract

Contracts allow the developer or user of a composite to specify details about how and where a composite should be installed. Contracts are marked up in system documents as xml elements of the following form:

<contract features=”” cancelationCost=”” lifetime=”” />

  • Features – an ldap expression evaluated against the list of features for the Newton instance, must evaluate to true for the composite to be installed on this instance.
    e.g. (&amp;(machine.arch=i386)(machine.availableProcessors>1)) specifies that the composite may only be installed on a Newton instance running on a multi CPU, Intel based architecture.

  • cancelationCost – an integer value that specifies whether or not a composite should be rebalanced (i.e. moved to another Newton instance) if a lower cost installation becomes available during the lifetime of the composite install. The value -1 may be used to specify that the composite should never be rebalanced. All other values are then used to calculate the required drop in cost before a composite will migrate to a new instance. The default is 1.

  • lifetime – this is a crude measure of how long a composite install should last – it is a fixed time in milliseconds after which the composite will be uninstalled from the container. This is an area of active development to extend the notion of lifetime for the next release so expect much richer patterns in the near future.