Java back-end developer
Looking for senior Java or C++ software engineers experienced in SOA and/or Data Distribution Services. Candidates need to
have strong design as well as implementation skills in these or equivalent areas. Need to support the entire software
development lifecycle from requires, design, implementation and testing. Testing will involve implementing automated testing at
both the software unit as well as system level using technologies such as BDD, xUnit and custom tools.
Individual will work within an existing software engineering team. The team follows an Agile Scrum process for planning and
executing tasks on a 3-week Sprint cadence. Work within a Sprint falls into one or more of the following areas:
Creating and documenting software designs
Holding design and code reviews
Implementation of new software functionality
Implementation of fixes for software bugs
Implementation of automated unit tests (e.g. JUnit)
Implementation of automated BDD tests
Implementation of performance and reliability tests
Documenting and executing manual test procedures
Strong Java or C++ design and implementation skills for backend services
Experienced with service-oriented architectures and microservices
Experienced with Docker and Docker containers
Experienced with using Spring Boot
Experienced with implementing RESTful web services
Able to develop in a Linux-based environment
Able to develop using Git for software configuration management
Able to implement automated tests using BDD and xUnit frameworks
Experience with the Data Distribution Services (DDS) standard or similar
Experience debugging memory leaks within C++ or Java applications
Experience with using REST UI front-ends
These contractor positions will be joining an existing software development team. The software development team is one of
many teams working on the AMS program developing a new patient monitoring system. The new patient monitoring system
consists of three basic subsystems:
1. Hub - A mobile device that acquires and displays physiological data for a single patient.
2. Viewer - A web-based viewer application that allows clinicians to view multiple patients by displaying the data provided
by each Hub associated with each patient.
3. Platform - A collection of microservices that provide the backend functionality that support the Viewer and Hub
The work for this team falls into general areas:
Core Microservices & Communication Library
This team works solely on the Platform subsystem and is responsible for delivering the follow core Software Units:
Core Communication Library - This library is based on the Data Distribution Service (DDS) standard. Communication
between microservices, Hubs and Viewers leverage the DDS publish and subscribe framework to exchange real-time
data encoded in a proprietary format.
Patient Management Microservices - A collection of microservices that provide the ability to associate a Hub to a patient
allowing other services like the Viewer to determine what Hubs and patients are currently being monitored within the
Configuration Microservice - A microservice that is responsible for providing the default configurations for the System.
For example, the Hub will consult this microservice to determine how it should configure itself within the System as well
as default patient monitoring configuration settings.
Much of the implementation of these Software Units are in place, however the AMS Program is still in the early phases of
overall system integration. Therefore, much of the work involves creating automated white and black box tests using BDD and
xUnit frameworks. Additionally, the team is involved with investigating, root causing and fixing issues that are discovered as
part of system integration testing. These issues could be related to functional failures, performance bottlenecks or resource
Platform Subsystem Test Tool
The team is responsible for building a custom standalone test tool used to automate or semi-automate Subsystem level test
scenarios. These test scenarios are intended to ensure the integrated Platform Subsystem is functioning as expected,
performance is stable over time and is reliable under various stress conditions (e.g. network failures, component failures,
The standalone test tool include mock implementations of the Viewer (Java) and Hub (C++) subsystems. These mock
implementations are dockerized and have a REST-based interface which allows automated scripts to be written for the various
test scenarios. Tests scenarios and mock instances are orchestrated using a framework based on Spring Boot (Java).
There is also a request to put a UI front-end on top of this tool which would allow a user to manually configure the mock
instances of the Viewer or Hub. The current thought is to leverage a third-party tool for this (e.g. Postman), since their
interfaces would be REST-based.