See full MIT license text here.
See instructions to retrieve all the third party licences here
The Nordic Way Interchange Node (NWIXN) is a message broker that enables location-based exchange of traffic data. Nordic Way partners send traffic information to the broker in the form of AMQP messages. These messages are distributed to subscribing partners.
Messages are produced and exchanged over AMQP 1.0. Message content is not examined, but all messages must provide header attributes as specified in the client specification.
Traffic message formats supported are DATEX2, DENM, IVI, SPATEM, MAPEM, SREM, SSEM, and CAM.
Neighbour nodes registered in the DNS (domain name server) will be discovered via a control channel.
All neighbours must present the message types they produce - capabilities - in this discovery process.
Neighbours also has a set of message types they are interested in - subscriptions. If a neighbour produces a message type we are interested in, we issue a subscription request to the neighbour.
Accepted subscriptions will be set up by the Routing Configurer so finally the messages can be collected by the Message collector.
More information on the concepts and the open source implementation of the interchange node is found on the Github Wiki
Additional information about the Nordic Way Interchange Node can be found here.
For any questions please contact
- Christian Berg Skjetne: christian.berg.skjetne@vegvesen.no
- Maven 3.5.x or later
- Java 11
- Docker Engine 18.06.1-ce and Docker Compose 1.22.0 or later
The maven build uses testcontainers in the integration test stage, so you will need Docker installed locally
in order to run the integration tests.
To build the project without integration test, use mvn package, and to run the integration tests, run mvn verify.
All the docker images specified in the github https://github.com/NordicWayInterchange/interchange/ is automatically built by GitHub and published to the container registry europe-west4-docker.pkg.dev/nw-shared-w3ml/nordic-way-interchange/ on each commit. Each component in the system has its own registry.
All the images are tagged with git commit hash, and branch name. Branch "federation-master" is considered to be the stable branch.
Unit tests are run in the maven 'test' stage, and integration tests are run in the 'verify' stage.
The profile "IT" separates the unit tests from the integration tests by ensuring the integration tests are run in the 'verify' stage. The profile "IT" is defined in the top pom and is always activated.
We use junit5 in our tests. https://junit.org/junit5/
We aim at using fluent assertions using assertj. We use the version of assertj-core defined by spring-boot-starter-test.
Helm uses Charts to pack all the Kubernetes components for an application to deploy, run and scale. This is also where the configuration of the application can be updated and maintained.
The helm templates is provided under helm/interchange/templates. See the example values file helm/interchange/example_values.yml
To get a list of the third-party licenses used in the project, run (in bash):
mvn license:add-third-party
followed by:
find . -name THIRD-PARTY.txt -exec cat {} \; | sort | uniq