Atomia Automation Server

This section gives a system overview of the Atomia Automation Server.

Key concepts

The following are key concepts in understanding the Atomia Automation Server, all of which will be described in detail below.

• accounts
• service description
• package description
• resource description
• module

Image 1: Automation Server key concept flowchart.

1. An account is a person or a company using Automation Server.
2. A service is a configuration/installation/setup on a resource (for example a website on a web server, or a DNS zone on a name server). Every service belongs to some account. Available types of services are listed in the Service Description – an XML definition of available service types. A set of services that one account may have is limited by packages activated for that account.
3. A package is basically a set of limitations that applies to account owning that package (for example, 5 websites, 100 email accounts, and 3 databases). One account may have several packages. All available packages are listed in the package description – XML file with definition of available packages.
4. A resource has services configured (provisioned) on it (example resources: web server, name server, storage, mail server, etc.). For a device to be considered a resource, Automation Server must know how to communicate with it.
5. The package description lists available services (services defined in the service description) and their limitations.
6. The resource description lists available resources.
7. The service description lists available services and their relations.
8. A module is a software plugin used by the Atomia Automation Server to perform actions on a resource. Both the resource description and the service description depend on the module.

Accounts

An Atomia account is a container of packages, services and settings for one company/person. All services must belong to an account, which in turn can have one or more packages.

Service description

The Atomia Automation Server uses Provisioning Description files to describe available services, their relations, limitations, initialization instructions and termination instructions. There are two types of services:

• Simple services
• Complex services

Simple service

A simple service is a single Atomia building block. It can represent one e-mail account, one domain name, one DNS record or one Linux website – anything that can be configured on a resource. It is described with a name and a list of properties. Simple services have a parent-child structure. A child service can not be added without a parent service being added first.

Example: WebSite is the name of one simple service. WebSite has the following properties: Name, PortNumber, etc. VirtualDirectory is the child of a service WeSite, henceVirtualDirectory cannot exist without WebSite.

Image 2: Simple service building blocks.

Complex service

A complex service consists of a set of complex services, simple services and their configuration. It also contains limitations which apply to enclosed services, property transformations (how you can “calculate” properties of enclosed services based on the complex service property values) and initialization instructions. In general, a complex service is not located on a particular resource, but rather it’s simple services are.

Here is a simplified illustration for a Windows Hosting Service:

Image 3: Complex service building blocks.

An organization using Atomia Automation server must model its own services according to their specific needs.

Logical and physical structure of service representation

Internally, Atomia Automation Server has two types of service representations:

• Logical service representation
• Physical service representation

Logical and physical representations are shown below:

Image 4: Logical structure of services.

The number or letter in the right bottom corner of each box represents the type of service specified: complex services are marked with letters, simple services with numbers. As you can see, the complex service WebSite has two DnsRecord services. The complex service MailSupport also has two DnsRecordservices. One of these records is the same for both. Also, the parent of these records – DnsZone – is the same. So, the physical structure of these services will be:

Image 5: Physical structure of services.

The logical structure of these services is important because the system must know the logical relations between services. For example – if a user wants to delete MailSupport , the system should only delete DnsRecord with ID 4 and the MailSupport complex service. DnsZone , DnsRecord with ID 2 and DnsRecord with ID 3 are required for the WebSite complex service.

Package description

Simply put, a package is something a customer buys. The package description contains a list of services, their limitations and the service settings values. An extra package is a package that can extend other packages.

Example of a hosting package:

Resource description

A resource description describes resources that the Atomia Automation Server knows about, binding a resource with a specific module. A resource is defined by a list of properties that helps the system to determine where to configure a specific service. As explained previously, a resource can be a server, a file, an ADSL central, etc.

Module

A module is a plugin used by the Atomia Automation Server to perform actions on a resource. Each module works with one type of resource. For example, the IIS module configures websites and bindings on a IIS server resource, the MSSQL module configures databases and database users on a MSSQL server resource, etc.

Image 6: Provisioning modules.

The Atomia Automation Server sends a provisioning request to the Provisioning module every time it needs a service on some resource. Communication between the Atomia Automation Server and the Provisioning module is based on Service Description XML which describes services that can be or are provisioned. The provisioning module then parses the request and calls an agent to do the actual provisioning. Then it returns information about the provisioned service.

The Atomia Automation Server will always send a whole Module Service subtree to the module. E.g. if the Automation Server wants to add a new service, it will send the appropriate Module Service with all its child services. The module must make sure the service it received contains all children and whether it should execute module commands for each one.

Resource description examples

The Resource Description page shows different ways to create a resource description file.

Provisioning description examples

Visit the Provisioning Description page to view more examples on how to create Service and Package description sections.