Developers Guide - motown-io/motown GitHub Wiki

The Motown Platform comes with a number of Add-Ons, which can be configured into the system. In order to create your own eMobility system using Motown you will have to determine which Add-Ons apply to your situation.

The listing of components below describes each of the available Add-Ons. In case the default Add-Ons do not meet your needs, it is possible to [create your own custom Add-On](Creating a custom Add-On).

Motown consists of several components. Each of these has their distinct part to play in a Motown system.

Motown focusses on the backend communication for eMobility Systems, and therefore does not come with a User Interface, user management, or an authentication mechanism. This way you have all the freedom to create a User Interface that meets your needs.

You can connect your User Interface to Motown through the Operator API. The samples folder contains a basic User Interface that connects to the Operator API.

To integrate your own applications into Motown the Motown APIs can be used.

The following APIs are available:

• Core API - For connecting your custom Add-Ons with the Motown Core.
• Configuration API - For adding Charging Station configurations.
• Operator API - For performing operator tasks, like unlock connector or remote start transaction.

Security within Motown has three levels:

• Authentication on JSON REST API's
• Authorization on Motown core
• Authorization of add-ons (currently not implemented)

Motown does not come with a default mechanism to enable authentication on JSON REST API's like the Configuration and Operator APIs. The sample-configurations do come with a sample on how this could be implemented using a servlet filter. As these samples are for demonstration purposes only it should be mentioned not to use the authentication code in live environments and should just be used to demonstrate a concept.

The Motown Core has a mechanism that checks if a user is allowed to execute the provided command on the charging station. When sending a command into the core, an UserIdentity has to be provided in the IdentityContext.

The Operator API provides a mechanism to grant and revoke user permissions to execute certain commands. For each of the users of your custom built User Interface, you have to grant the required permissions. When using the Operator API it is required to pass a UserIdentity with each call, allowing the Motown Core to check the permission.

At the moment there is no authorization on Add-On level. Due to the fact that the Add-Ons primarily will be running in a controlled environment, this will not be necessary by default. For future use, each Add-On provides an IdentityContext containing an Add-On identifier.

The Motown artifacts are made available on Maven central. To use Motown components check Maven central for the latest available version.

For example, to use the Motown OCPP 1.5 SOAP module version 0.8.2 in a Maven project the following should be in your pom.xml:

<properties>
   <motown.version>0.8.2</motown.version>
   <!-- other properties -->
</properties>

<dependencies>
   <dependency>
      <groupId>io.motown.ocpp</groupId>
      <artifactId>ocpp-v15-soap</artifactId>
      <version>${motown.version}</version>
   </dependency>
   <!-- other dependencies -->
</dependencies>

If you are using Motown in a Grails project, the following example adds a dependency to the operator API module:

compile 'io.motown.operator-api:operator-api-json:0.8.2'

To see other dependency samples please refer to the Maven central website. To see a sample using a complete Motown stack using dependencies please refer to the configuration samples: single app or distributed.