Servers initiate processing within a Thera application, usually in reaction to an inbound (originated by other application) request.

A server refers to an operation, a request format and a response format. An example of a server is TCP/IP server that listens for TCP messages on a given TCP port. When a message is received, the server creates and initializes an instance of the operation together with a context that contains it. (This context may also contain data structures to hold the message data.) Then the data of the request message is parsed using the request format. The request format therefore specifies how the message should be parsed and relates the portions of the message to Thera data elements into which the data are loaded. Then the operation is started.

After the operation finishes its execution, the server formats response message (as defined by the associated response format) and replies it to the entity that originated the processing.

Data values in a Thera configuration are realized by DataItem component. Its purpose is to hold a single piece of data; it is in fact a variable. It is capable of holding data of any type, be it text, number, date or whatever. The way the value is treated is determined by a format or operation step that works with the DataItem.

Data can form groups of variable length (arrays, vectors). This is realized by DataVector. A DataVector can hold other data, the number of which is unknown or may change during the execution of an application. The elements are accessed by a zero based index.

Data can also form groups with a known set of sub-elements that are accessed by their names (entities, records). An example of this is a set of customer personal data that contain sub-elements like name, address, SSN, etc. This is realized by DataMap.

A format defines relation between data and a specific representation of the data by providing means of transcribing the data into the given representation (called formatting) and vice versa (called unformatting, or parsing).

For most of the formats, this representation is a String. So, an Int format defines a relation between a DataItem and a String: it provides a format() method that reads the value of associated DataItem and converts it to a String, and it provides an unformat() method that takes a String, parses it as a string representation of an integer number, creates an Integer with the number parsed from the string and sets the value of associated DataItem to this Integer.

Another example is RecordSet format: it defines a relation between a DataVector and a String. It provides a format() method that reads all elements of the associated DataVector, formats each element as a String and as the result returns the concatenation of these Strings. It also provides an unformat() method that takes a String, parses the data from it, creates the corresponding data structures and appends them to the associated DataVector.

Thera provides out-of-the-box a rich set of operation steps. They include

• Steps for manipulating the data (eg ClearData, Increment, Sum, SetValue, Pick, Lookup, StringClassify, Timestamp, XSLT).
• Steps to call services (ServiceCall, ServiceCallVariable, ModalServiceCall).
• Steps providing control of flow of execution (eg Call, Loop, IfEqual, Compare, Throw, Catch, Timeout, Delay).

Services provide means to access the system from a Thera application. A service is in a way a counterpart of a server: while server solves inbound (external entity originated) communication, service solves outbound (Thera application originated) communication.

A service is called from an operation step with a request and a response format. An example of a service is StandardIO, which interacts with the standard input and output of the Thera application. When the service is called, the request string is formatted according to the request format and written as a line to the standard output (ie generally displayed on console). Then a line is read from the standard input (ie generally from the keyboard) and unformatted according to the response format.

Context is a basic organizing element of the configuration file. It contains all other elements, like data, formats, services etc. Contexts form a tree structure with a single root context.

Contexts that contain operations (or have any parent that does) are dynamic: they are created and initialized dynamically when the flow of control requires to execute an operation contained in the context.

Contexts that are not dynamic are called static. Static contexts are created and initialized on application startup. Root context must be static.

Static contexts contain elements that have application-wide validity, while dynamic contexts contain elements specific to the operation in the context. Multiple instances of a single operation can be launched at parallel: every operation instance gets created its own instance of the container dynamic context.

Next: Thera development

Back to home