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
An account is a person or a company using Automation Server.
A service is a configuration/installation/setup on a resource (for example a web site 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.
A package is basically a set of limitations that applies to account owning that package (for example, 5 web sites, 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.
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.
The package description lists available services (services defined in the service description) and their limitations.
The resource description lists available resources.
The service description lists available services and their relations.
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.
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.
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
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.
![[Important]](important.png) | Examples |
|---|---|
|
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:
An organization using Atomia Automation server must model its own services according to their specific needs.
Internally, Atomia Automation Server has two types of service representations:
Logical service representation
Physical service representation
Logical and physical representations are shown below:
The image above shows an example of the 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
DnsRecord
services. 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:
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.
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:
|
Service |
Quantity |
|
E-mail Accounts |
2000 |
|
FTP Accounts |
Unlimited |
|
MySQL Databases |
10 |
|
Addon Domains |
Unlimited |
|
Sub Domains |
Unlimited |
|
Parked Domains |
Unlimited |
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.
Atomia uses a Resource Description File to describe available resources for simple services.
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.
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.
The Resource Description Examples page shows different ways to create a resource description file.
Visit the Provisioning Description Examples page to view more examples on how to create Service and Package description sections.