This section gives a system overview of the Atomia Automation Server.
The following are key concepts in understanding the Atomia Automation Server, all of which will be described in detail below.
- service description
- package description
- resource description
- An account is a person or a company using Automation Server.
- 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.
- 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.
- 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.
WebSite is the name of one simple service.
WebSite has the following properties:
VirtualDirectory is the child of a service
VirtualDirectory cannot exist without
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.
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:
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:
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.
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:
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.
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.
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.