Atomia Automation Server

A complex service represents a group of services which are not directly provisioned on a resource. It consists of part services which are grouped together to represent one logical unit. A complex service has the following structure:

<complexService name="ComplexService" friendlyName="Complex service example">
<complexServicePropertyList>
<!-- List of complex service properties -->
</complexServicePropertyList>
<partList>
<!-- List of part services which form this complex service -->
<partList>
<init>
<!-- Initialization section. When complex service is added, this section must be executed too, i.e. add some part services with predefined property values. -->
</init>
<actionHooks>
<!-- Registered action hooks for this type of service. -->
</actionHooks>
</complexService>

A basic implementation of the complex service could look like this:

<complexService name="CsWindowsBinding" friendlyName="IIS website binding">
<complexServicePropertyList>
<complexServiceProperty name="Sitename" friendlyName="Site to bind to" />
<complexServiceProperty name="Hostname" friendlyName="Binding Hostname" key="true" />
<complexServiceProperty name="DnsZone" friendlyName="DNS Zone to add binding to" />
</complexServicePropertyList>
<partList>
<partService name="IISApplicationPool" equivalenceCriteriaParams="Name" min="1" max="1">
<partList>
<partService name="IISWebSite" min="1" max="1" equivalenceCriteriaParams="Name">
</partService>
</partList>
</partService>
</partList>
<init>
...
</init>
</complexService>

The example above shows a complex service CsWindowsBinding with a part service IISApplicationPool and one child part service IISWebSite . One important feature must be explained here. Simple child services are declared and defined directly under thechildServiceList subsection of the parent owner service. Part services of a complex service are defined outside of thepartList subsection where they are just referenced with their parent-child, whole-part relations preserved. In the given example, it is assumed that IISApplicationPool and its child service are defined outside of the partList subsection. This means thatIISApplicationPool could not be a subpart of the IISWebSite service, since later it is the child service of theIISApplicationPool . Part services can also be other complex services, but they too must be defined outside the partListsubsection. Basically, there are no child complex services. All complex services are root service, but can be referenced as part services of another complex service. The consequence of this is that root part services can only be complex services or root simple services.

Part service property values can be transformed using Atomia provisioning element transformations, see Provisioning Description – Full Example.

Example of partList subsection:

<complexService name="CsWindowsBinding" friendlyName="IIS website binding">
...
<partList>
<partService name="IISApplicationPool" equivalenceCriteriaParams="Name" min="1" max="1">
<propertyTransformation>
<simpleTransformer>
<serviceProperty name="Name">
<expression>#Account()+AppPool</expression>
</serviceProperty>
<serviceProperty name="Username">
<expression>#Account()</expression>
</serviceProperty>
<serviceProperty name="Password">
<expression>$CsWindowsBinding::ADPassword</expression>
</serviceProperty>
</simpleTransformer>
</propertyTransformation>
<partList>
<partService name="IISWebSite" min="1" max="1" equivalenceCriteriaParams="Name">
<propertyTransformation>
<simpleTransformer>
<serviceProperty name="Name">
<expression>$CsWindowsBinding::Sitename</expression>
</serviceProperty>
</simpleTransformer>
</propertyTransformation>
</partService>
</partList>
</partService>
</partList>
...
</complexService>

The subsection init defines part service instances that should be added when an owner complex service is added. It is possible to predefine service property values and patterns for these values using Atomia provisioning element transformations, see Provisioning Description – Full Example. During the addition of part services, Atomia Provisioning will use these transformations to calculate part service property values. Note that part services must keep their parent-child, whole-part structure here also.

Here is an example of the complex service init subsection for the above example:

<complexService name="CsWindowsBinding" friendlyName="IIS website binding">
...
<init>
<add partName="IISApplicationPool" instanceName="CsWindowsBindingAppPoolInstance">
<initPropertyList>
<propertyTransformation>
<simpleTransformer>
<serviceProperty name="Name">
<expression>$CsWindowsBinding::Hostname</expression>
</serviceProperty>
<serviceProperty name="Username">
<expression>#Account()+AppPool</expression>
</serviceProperty>
</simpleTransformer>
</propertyTransformation>
</initPropertyList>
<add partName="IISWebSite">
<initPropertyList>
<propertyTransformation>
<simpleTransformer>
<serviceProperty name="Name">
<expression>$CsWindowsBinding::Hostname</expression>
</serviceProperty>
<serviceProperty name="HomeDirectory">
<expression>\/mnt\/content\/+$CsLinuxWebsite::Sitename</expression>
</serviceProperty>
</simpleTransformer>
</propertyTransformation>
</initPropertyList>
</add>
<add partName="IISWebSite">
<initPropertyList>
<propertyTransformation>
<simpleTransformer>
<serviceProperty name="Name">
<expression>$CsWindowsBinding::Hostname</expression>
</serviceProperty>
<serviceProperty name="HomeDirectory">
<expression>\/mnt\/content\/+$CsLinuxWebsite::Sitename+\.preview</expression>
</serviceProperty>
</simpleTransformer>
</propertyTransformation>
</initPropertyList>
</add>
</add>
</init>
</complexService>

The difference between the  partList and init subsections is that the former describes the complex service structure, that is, it describes how the complex service is structured and what its parts are. Later on, it provides a tree of part service instances which must be added when the complex service owner is added.