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 BladeRunnerJS, you’ll have a number of files in the BladeRunnerJS 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.

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 BladeRunnerJS 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 BladeRunnerJSLibraries expect to be defined are:

  1. The XmlResourceService, which provides access to XML bundled by the XML Bundler. This is sometimes used to load configuration files.

  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.

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

Custom Services

There are a number of other services that the BladeRunnerJSLibraries use, and you can also define your own and use those too. Here’s an example of using one of the other 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 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.

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 br.user-service alias to point to your implementation. Once you’ve done this, all your code (including the BRJS Trader libraries) will start using your implementation.

<aliases xmlns="">
    <alias name="br.user-service" class="mynamespace.MyUserService"/>

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

this.userService = br.core.ServiceRegistry.getService("br.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 documentation on

See also: