# Service architecture

The first thing that should happen when your application is loaded is the registration of services' implementations so that they are then accessible from anywhere within the application. This section explains how to bootstrap the required and custom services at the app’s entry-point.

Once you’ve created your application in _BladeRunner_, you’ll have a number of files in the _BladeRunner_ Application directory structure. If you look at the MyApp/default-aspect/**index.html** file, you’ll see it includes the CSS, the JavaScript and then, in a script tag, creates an **App** using code loaded from your project (e.g. `myapp.App`). This code is defined in **_App.js_** in your _MyApp/default-aspect/src/myapp_ directory.

_Caplin Libraries_ do not do anything when loaded, it’s up to the person writing the application to create and wire up the parts of the libraries and services you are using.

## Standard Services

Services are used for two things: configuring the implementation of methods relied on by the _Caplin Libraries_ (e.g. loading XML or HTML files), or allowing **blades** to provide services to other blades without creating a hard dependency between the blades. Services that many _Caplin Libraries_ expect to be defined are:

1. The `[XmlResourceService,opts="nofollow"](https://docs.caplin.com/developer/api/caplin_trader/3/caplin.services.xmlresourceservice)`, which provides access to XML bundled by the **XML Bundler**. This is often used to load configuration files, e.g. for **Grids** or other caplin components.
2. The `HtmlResourceService`, which allows code to get the contents of HTML files that have been bundled together. This is typically used to load templates for **Presenter**.
3. The `[PermissionService,opts="nofollow"](https://docs.caplin.com/developer/api/caplin_trader/3/caplin.services.security.permissionservice)`, which allows you to find out what the currently logged-in user is allowed to do. This can be useful if you want to remove UI facilities for things the user is prohibited from doing.
4. The `[AppService,opts="nofollow"](https://docs.caplin.com/developer/api/caplin_trader/3/caplin.services.appservice)`, which allows you to retrieve application property values, usually used to configure your application.

Because these services are needed by many parts of the _Caplin Libraries_, we provide default implementations for them.

## Custom Services

There are a number of other services that the _Caplin Libraries_ use, and you can also define your own and use those too. Here’s an example of using one of the other Caplin defined services.

Many applications need to know the user name of the currently logged in user. In the following example a message displayed when a user trades should include the user’s name.

The `UserService` interface is defined in the library as having a single function, `getLoginName`, which returns a string. [_Caplin Trader_](../index.md) provides an implementation of this, but you can create your own implementation of the `UserService` and register it. Below is the simplest possible `UserService`, but it’s also possible to create one that gets the login name via an XHR to a protected servlet or uses a streaming connection.

```js
mynamespace.MyUserService = function() {};
mynamespace.MyUserService.prototype = {
    getLoginName: function() {return "Bob";}
};
```

To use your new `UserService` you edit the `aliases.xml` file, in your default aspect’s resources directory. This will re-map the `caplin.user-service` alias to point to your implementation. Once you’ve done this, all your code (including the Caplin Trader libraries) will start using your implementation.

```xml
<aliases xmlns="http://schema.caplin.com/CaplinTrader/aliases">
    <alias name="caplin.user-service" class="mynamespace.MyUserService"/>
</aliases>
```

This service can then be used in the code that generates the message:

```js
this.userService = caplin.core.ServiceRegistry.getService("caplin.user-service");
var buySellMessage = this.m_mTradeDetails['side'] == 'BUY' ? 'bought ' : 'sold ';
var sMessage = this.userService.getLoginName() + ' ' + buySellMessage + ' ' + this.m_mTradeDetails['amount'] + ' ' + this.m_mTradeDetails['dealtCurrency']
    + ' at the rate ' + this.m_mTradeDetails['rate'];
```

There are other services you may want to use, or for which you might want to provide custom implementations. For details on those, see the [Available Services](base-library-available-services.md) documentation.

## Logging

To get log messages in the JavaScript console from _Caplin Libraries_, you create and register a `[ConsoleLogger,opts="nofollow"](https://docs.caplin.com/developer/api/caplin_trader/3/caplin.core.log.consolelogger)`. During initial development, you will most likely want to use the `[ConsoleLogger,opts="nofollow"](https://docs.caplin.com/developer/api/caplin_trader/3/caplin.core.log.consolelogger)` that we provide, but later on you may want to use the `[StoreLogger,opts="nofollow"](https://docs.caplin.com/developer/api/caplin_trader/3/caplin.core.log.storelogger)`, or your own logger so that end users can see log messages for fault diagnosis.

The logging system uses services and the event hub underneath, but for basic usage, you can just use the methods on `[caplin.core.log.Log,opts="nofollow"](https://docs.caplin.com/developer/api/caplin_trader/3/caplin.core.log.log.html)`. You can get started with the `[ConsoleLogger,opts="nofollow"](https://docs.caplin.com/developer/api/caplin_trader/3/caplin.core.log.consolelogger)` with the following piece of code in your App initialisation:

```js
caplin.core.log.Log.register(new caplin.core.log.ConsoleLogger());
```