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