Introduction

Apache ACE consists of a number of components, which can be deployed more-or-less independently.

Overview

ACE consists of several components, distributed over a number of nodes in the network. The image above shows the most elaborate situation, consisting of five nodes, each running their part of some functionality of ACE.

Nodes

• Client A client system has functionality for altering the configuration of the deployment process.
• Server The server contains all necessary metadata to allow provisioning, and acts as a hub for logging information.
• Relay A relay server keeps a copy of the metadata of the server, and can provide a target with all functionality a 'regular' server can. Note that this allows for offline provisioning, and note that there can be a chain of relay servers.
• Target The target is the system to which software is to be provisioned.
• OBR The OBR contains the actual software to be provisioned.

Functionality

• Deployment See below.
• Logging See below.
• Identification Each target needs a unique name; the Identification components provide this functionality.
• Discovery Targets and relays need to find the next server 'upstream' from the current node.
• Configuration ACE uses its own configuration mechanism, which works by reading configuration files, and putting that information into Config Admin.
• Scheduling Some components needs to have scheduled actions to allow logging and provisioning; the Scheduling component helps with that.

Alternative topologies

TODO show the possible topologies: single server and gateway, separate OBR, several relays, where does the client fit in, how to work behind a firewall, etc.

Provisioning

Software provisioning is the main task of ACE. The provisioning components are responsible for determining the set of bundles to be deployed to a given target, creating a deployment package, and feeding the deployment package to the Deployment Admin.

Components

TODO show the components of the provisioning mechanism, and where they operate. Remember to point out that the gateway contains separate bundles, but there is also an integrated management agent.

Further reading

TODO create a child page that describes the provisioning part in more detail

Logging and reporting

ACE contains a logging and reporting facility. This mechanism allows a target to send back logging information to the server, and allows the storing of arbitrary key-value pairs.

The logging mechanism is extensible with extra logging information. The basic implementation will log framework events (e.g., starting and stopping of bundles), and deployment events.

Components

• o.a.a.server.log The server's log bundle handles the access to the access logs on the server, and provides a servlet that is used for synchronizing logs between target (or relay) and server.
• o.a.a.server.log.store Stores the log on the file; this functionality is separated to allow some other storage mechanism than the file system.

• o.a.a.server.log.task This task is provided to the o.a.a.scheduler so the relay server can synchronize its logs with the 'master' server.

• o.a.a.log Contains general interfaces for the gateway's logs.
• o.a.a.log.listener Listens for framework events, and logs those to the gateway log.
• o.a.a.gateway.log Provides a Log service to which events can be logged.
• o.a.a.gateway.log.store Stores the logs on the gateway until they can be synchronized.

• o.a.a.scheduler The scheduler is used to, configurably, run a task with a given interval. This is used by both the gateway and the relay to synchronize the log.

Further reading

TODO create a child page that shows what the logging is about, and how to add your own logging to the mechanism.