Basic Symphony concepts

Application

A service-oriented application is a type of application software, where the business logic is encapsulated in one or multiple software programs called services that are separated from its client logic.

Application profile

The application profile is an XML file that defines the properties of a Symphony application, including the name of the service that performs the calculation and the scheduling parameters to apply.

The application profile contains runtime parameters for workload, service, and the middleware that define how Symphony runs workload. An application profile provides flexibility to dynamically change application parameters without requiring you to change your application code and rebuild the application.

An application profile is associated with an application. An application is associated with one consumer. You must register the application profile of every application you want Symphony to manage.

Symphony client application

A program or executable that needs work done through a service. Requests are submitted via an API to the service.

Symphony service

A service is a self-contained business function that accepts one or more requests and returns one or more responses through a well-defined, standard interface.

The service performs work for a client program. It is a component capable of performing a task, and is identified by a name. Platform Symphony runs services on hosts in the cluster.

The Symphony service is the part of your application that does the actual calculation. The service encapsulates business logic.

Session

A group of tasks that share common characteristics, such as data.

Connection

The connection on which a session is created provides a conduit for the tasks.

Task

A task is the unit of work that runs on each individual host when Symphony workload is running. The task consists of a message request (input) and, when completed by a service, a response (output).

Consumer

A consumer is a generalized notion of something that uses resources.

Log files and levels

The integration software uses the log4j logging framework. Log classes can be found in the log4j properties files located in the conf directory. Here are the most commonly-used logging levels in the log4j framework:

  • ALL has the lowest possible rank and is intended to turn on all logging.

  • DEBUG level designates fine-grained informational events that are most useful for debugging an application.

  • ERROR level designates error events that might still allow the application to continue running.

  • FATAL level designates very severe error events that will presumably lead the application to abort.

  • INFO level designates informational messages that highlight the progress of the application at coarse-grained level.

  • TRACE level designates finer-grained informational events than the DEBUG level.

  • WARN level designates potentially harmful situations.