# Services in Caplin Trader 3

This page describes the different types of service that are used in Caplin Trader, and how they relate to each other. You might also find it helpful to read [how Caplin Trader’s services are implemented and displayed in a browser](ct3-how-ct3-works-in-a-browser.md).

## Overview

Services use standard interfaces to make shared resources available to multiple display components. The implementation of a service may be swapped as long as each implementation complies with the rules defined by the interface.

For example, one implementation of a _persistence service_ might save user data to local storage, while another might save the data on a remote server via a web service. Your app’s "main" class can register whichever service implementations are required. Services may call other services, and we can categorize them as shown in the diagram below.

![ct3_ov_diagram_services](../../images/ct3_ov_diagram_services.png)

## Data Services

As soon as it’s been created, the _XmlResourceService_ performs an asynchronous HTTP request, and retrieves the XML bundle file from the app-server. It parses the XML and makes the resulting XML document objects available on request.

Similarly, the _HtmlResourceService_ performs an asynchronous HTTP request and retrieves the HTML bundle file from the app-server. When HTML is requested from the service, a DOM element is returned. It is important that you do not make direct changes to the returned DOM element, but make a copy of it, and make any necessary alterations to the copy. Changes to the original will interfere with other code that requests the same DOM element. The HTML service translates any embedded internationalisation tokens.

The _MessageService_ makes data available from COMET servers, via a simple publish/subscribe style interface. Caplin provides a default implementation that uses _StreamLink_ to communicate with our _Liberator_ server.

## Application Services

The _ComponentService_ creates instances of Caplin display components from their serialised XML form, which is retrieved from the _XmlResourceService_. Caplin provides a single implementation of this service that should not be replaced. This implementation holds a registry of factories that are used to create the components. Each factory must register itself with the component service on start-up, indicating the component type it can create; e.g: _grid_. When the component service receives a request, it parses the top-level XML element name, and treats that as the component type. It then consults the registry, and instructs the appropriate factory to manufacture an instance of the required component.

* The _AppService_ provides information about the current status of the app. It maintains a set of named properties that can be used to configure the behaviour of any part of the app.
* The _UserService_ provides access to information about the currently logged in user.
* The _PreferencesService_ allows the user to change and save information about the app’s behaviour. Currently it is used by our localisation feature, to change the theme and date/time formatting, according to the user’s locale.

## Domain Services

Several of the _Caplin Trader_ libraries define one or more services, and provide default implementations for business domain level features. These include:

* _Trading Library_: Allows trades to be executed on remote servers.
* _FX library_: Provides the data required for Foreign Exchange trading; e.g: Currency Pairs, Business Dates etc...
* _Security Library_: Provides permissions data, so the UI only shows features for which the user has authorisation.

[Learn about _Caplin Libraries_ in CT3...](ct3-caplin-libraries-and-ct3.md)