Integration Guides › ADL Reference Guide › Application Descriptor Language (ADL) Overview

Application Descriptor Language (ADL) Overview

ADL is a language for describing applications within the CA AppLogic application model, where applications are built out of multiple components, with each component being an instance of a virtual appliance with its own OS and application software. In the interpretation of ADL, host and hardware or any type of resource do not necessarily correspond to physical resources. They may be virtual devices that share the same hardware.

ADL is based on UDL - a generic language for describing hierarchically structured data in plain ASCII text form. You can find the description of UDL in a separate document; however, understanding UDL in general is not necessary. This document contains a complete description of the ADL syntax.

This section contains the following topics:

Descriptor Types

Syntax Rules That Apply to All Descriptor Types

Future Directions

Unresolved

Descriptor Types

The following is a list of the descriptor types defined in ADL:

Component: Describes a simple component, which is running on a single host. Typically, a component is a single network appliance that performs one specific service, such as an HTTP server or a database server. Component descriptors are either written manually by a developer or produced by a GUI tool.
Assembly: Describes a composite component consisting of several interconnected components (either simple components or other assemblies). An assembly descriptor is also used to describe the structure of an entire application. Assembly descriptors are either written manually by a developer or produced by a GUI tool.
Package: Package descriptors are used as table of contents for an application, a catalog (catalogs are sets of re-useable components that can be shared among applications), or for data caches used internally by the CA AppLogic software. The package descriptors contain configuration information and a list of component and assembly descriptors. They can also include binding information linking the abstract descriptors to installed boot volume images for the components.

Syntax Rules That Apply to All Descriptor Types

As ADL is based on UDL, all of its descriptor files share common syntax properties.

Lexemes

Here are the smallest units of grammar used in the ADL language, defined as Perl-style regular expressions:


Reg expr	Sym	Use	Notes
[A-Za-z_][A-Za-z0-9_]*	SIDENT	entity name, entity type	A simple identifier. This is the identifier sub-set that is acceptable to most text-based languages used, including shell command interpreters (bash, csh), Perl,C, Java, and so on. Most user-defined names in the ADL language are of this type (exceptions are noted, where needed).
[A-Za-z_$.-] [A-Za-z0-9_$.-]*	IDENT	entity name, attribute name	An identifier. Similar to a C identifier, but '-', '$' and '.' are also valid characters.
[^,"'>=#\s]+	STR	attribute value	A bare string. A string that is not quoted is allowed as a value for an attribute, if it does not contain any special characters.
'[^']' or "(\\["]!\\t! \\n!\\r![^"])"	STR	attribute value	A quoted string, with two variants - single-quoted and double-quoted, interpreted in a manner similar to Perl - the single-quoted string recognizes no special meta-characters and can quote any printable characters except a single quote; the double-quoted string recognizes the \ meta-character and allows quoting of the double-quote itself and some non-printable characters.
[\]\[{}:,='"]		punctuation	See the Punctuation Details section below.
=>		punctuation	Association separator
[ ]+		whitespace	Whitespace is a syntax separator, whenever two adjacent lexemes cannot be distinguished otherwise (for example, two identifiers). In all other cases, whitespace between lexemes is simply ignored.
\n		separator	A newline or the EOF assertion. Multiple newlines are treated as one.

Punctuation Details

ADL is line-oriented and treats the newline character differently from other whitespace. In all the syntax descriptions below, the newlines are significant and the presence of a newline in a syntax example indicates it is required.

Here is the meaning of other punctuation characters in ADL:

:	Separates an entity definition from an in-line list of attributes for that entity
,	Separates attributes in an attribute list following an entity definition (in-line attributes)
{}	Block separators. These must appear alone on a line. A pair of braces encloses a set of attributes and sub-entities related to the entity after which they appear. Only one block is allowed per entity and only a single pair of braces should be used to enclose it, that is, constructs like these below are invalid: input X { { # double brace - illegal protocol=http } } input X { } { # second block for same entity - illegal protocol=http }
[]	Array block separators. A pair of square brackets following an entity heading identifies it as an array entity. Like the { } separators, these must appear alone on a line. Each line in the [ ] block is a comma-separated list of attributes for a single array element.
\	When found at the end of a line, this is a line continuation character. The next line is treated as part of the current line.
#	Comment separator. All characters following #, up to the end of line are ignored (including the \ line continuation character).

Descriptor Structure

Each descriptor file has the following overall structure:

entity-type entity-name
   {
    attributes-and-subentities
   }

Where:

entity-type is one of component, assembly or package and identifies the type of descriptor that is contained in the file.
entity-name is the name of the entity being described in this file (SIDENT).
attributes-and-subentities is an unordered set which contains any number of attributes and sub-entities. Each attribute is on a single-line and has the form: name=value., where name is an identifier (IDENT) and value is a string value (STR). Each sub-entity has one of the following forms:
```
name : attributes

type name :attributes 
name
   {
    attributes-and-subentities
   } 
type name
   {
    attributes-and-subentities
   } 
```
type and name are the type and the name of the sub-entity, respectively.

Attributes is a comma-separated list of name=value pairs. Attributes can also be specified in the { } block following the entity heading line. When attributes are specified on the same line as the entity definition (after the colon), binary attributes can be specified without a value (just the attribute name, meaning 'set to 1'), for example,

   volume boot: dev=/dev/hda1, ro

is the same as

   volume boot: dev=/dev/hda1, ro=1

Each subentity type defines a namespace, and within that namespace only one subentity of a given name can exist. That applies to the sub-entities with no type at all (one can think of the subentities with no type as having the empty string as the type).

Specifying attributes both in-line and in the { } block is allowed, it should be avoided except in the cases where one particular attribute should stand out (for example, the .class attribute in a subordinate component's specification); otherwise for simpler sub-entities with few attributes the inline syntax is preferred; for more complex entities that have many attributes or sub-entities, use the { } block.