Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Module description/purpose

The main purpose of the Movement module is the storage and retrieval of position reports regarding movements for ships.

 

To save valuable calculation capacity for modules requesting position data some enriching and calculations is done before persisting the position reports. Enriching of areas, harbors, and countries etc. where the position is currently located is done by querying the spatial module and passing the longitude and latitude from the position report.

 

One important thing to understand about the movement module are movements, segments and tracks.

 

 

 

 

 

 

 

 

 

 

 


All movements are calculated to be a part of a segment and a track. Calculations can then be made to control the reported speeds and courses to the actual speed and courses that are calculated. More of this can be read on the Javadoc.

 

The movement module can also store searches that a user makes on positions for later retrieval so the user don´t have to fill all fields again when making a search.

 

The movement module has functionality for storing temporary ( manual ) positions. These positions can be created saved and retrieved for later processing. When the user wants to he or she can execute the movement. When the movement is executed it is sent to the exchange module who in turn processes the position report.

Module dependencies

 

Name

Description

Spatial

Retrieve Spatial enrichment data regarding areas for a movement. This is due to pre calculation of spatial data that is stored in the movement database

Exchange

When sending a temporary movement that movement is sent to exchange who in turn processes the movement like a movement retrieved from any system o plugin

Audit

Audit logs are sent to the audit module. Audit logs are created when actions that changes data in the database are made.

User

All requests to the REST api is authenticated via the user module. If the user module is undeployed the rest api for the movement module will not work

 

 

JMS-Queue dependencies

 

The jndi name example is taken from wildfly8.2 application server

 

Name

Jndi name example


Description

UVMSMovementEvent

java:/jms/queue/UVMSMovementEvent

 

Request queue to this module

UVMSMovement

java:/jms/queue/UVMSMovement

 

Response queue to this module

UVMSMovementModel

java:/jms/queue/UVMSMovementModel

 

Request queue to the Database module

UVMSAuditEvent

java:/jms/queue/UVMSAuditEvent

 

Request queue to the Audit module

UVMSSpatialEvent

java:/jms/queue/UVMSSpatialEvent

 

Request queue to the Spatial module

UVMSExchangeEvent

java:/jms/queue/UVMSExchangeEvent

 

Request queue to the Exchange module

 

Datasource dependencies

 

The jndi name example is taken from wildfly8.2 application server

 

Name

Jndi name example

 

uvms_movement

java:jboss/datasources/uvms_movement

 

 

 

 

 

 

 

 

 

 

 

 

Tested compatabilities

 

Applicationserver

  • Wildfly 8.1
  • Wildfly 8.2

Database

  • Postgres 9.4.4 with PostGis extension

JMS provider

  • ActiveMq 5.0

 

Availabale database modules

 

All database modules can be found under the DB folder

 

Name

Purpose

Compabilities

movement-dbaccess

Middlehand between movement module and database

Postgres 9.4.4 with PostGis extension

 

Available proxy modules

 

All proxy modules can be found under the PROXY folder

 

Name

Purpose

N/A

N/A

 

Avaliable plugin modules

 

All plugin modules can be found under the PLUGIN folder

 

Name

Purpose

N/A

N/A

 

Liquibase – database compability

 

All Liquibase scripts can be found under the LIQUIBASE folder

 

Database

version

Postgres

9.4.4 with PostGis extension

  • No labels