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.
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.
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.
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.
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.