Session expiration Your session is going to expireClick here to extend


1.500 - 3.000

Pubblicato il

18/04/16 9.48

Questo progetto è iniziato

Pubblica un progetto simile e ricevi velocemente offerte non vincolanti.

Pubblica ora il tuo progetto simile


Ricerchiamo consulenza per lo sviluppo di un app basata su Web service REST/JSON nell’ambito di un progetto medicale con partner internazionali per cui è richiesta l'interazione in lingua inglese. 

Implementazione del progetto: entro Settembre 2016.

Luogo per incontri tecnici di progetto: Peschiera Borromeo (MI)


General Project Overview

The project combines in one device three sub-devices, one common user interface, common data storage and analysis software will make the dense information from project available to the end-user in a single working step. Since such sub-modules work independently as a single device, enabling

such common platform rises several advanced challenges, namely:

1. How to enable communication between devices?

2. How to combine data from different devices?

3. How to enable devices’ orchestration?

In order to overcome such problems, it will be used a simple but effective solution: each sub-device

should integrate a common communication interface. That way, all sub-devices will use the same

communication protocol (HTTP REST) and will exchange data in the same format (JSON).

However, such communication interface does not solve the orchestration problem, since a software controller is necessary to indicate when each device should do what, creating logical processing pipelines. For example, if a device needs to be cleaned, it must be the software controller to order to device to perform the cleaning task. Such requirements fit perfectly the master/slave communication model, where one device has unidirectional control over other devices. Ther master/slave model is therefore applied to the project, where all devices are slaves, and the software controller is the master that will orchestrate operations, managing dependencies and processing workflows.



Slave (sub-device)

Following the proposed communication model, every slave will be directly integrated with every device in the project. Moreover, the slave must be started together with the device, making the device ready to receive commands and to process blood samples. This means that the slave must be listening the network to receive orders.

A slave is characterized by its current status, and the methods that can change its behaviour. Thus, it have been defined in detail the several status and methods associated with a slave, the information that it stores, and the approach to implement it on every device.


Storage of data

The slave is not responsible for storing any information generated by the device. The slave only provides the interfaces to enable communication between the various slaves and the master. Thus, each device is responsible to store the results of processing the sample sample. Thus, after processing the sample, the master will communicate with the slave to request access to the results in the device. Afterwards, the results are provided to the master and stored in the central knowledge base together with all the studies processed previously.



To facilitate the development of the communication interface on each device, it has  already been implemented a functioning skeleton project respecting the previously described statuses and methods. It was developed in Java 7, using Maven as the build manager, Jetty as the server, and Jersey to easily implemented the REST services.



The source code is available in a Git repository at a specific server, in order to keep versioning of the software and to update it as needed. That way, it is possible to have continuous access to the latest versions of the software. In order to download the source code, instructions will be made available in order to configure SSH access as well as instructions to build the source code and to run a slave instance.



To create a custom slave instance specific for each device, it must been created a project based on the available skeleton. Afterwards, customization should be performed on the “Resources” class, where methods are implemented. Each method indicates where one should add its own implementation to execute the tasks on the device. That way, it will necessary to deal with the specifics of the device, without taking care of the communication layer.

When adding custom code to communicate with the device,  special attention shall be placed on intercepting errors and propagating them to the entity that is calling the methods. This means that every error should be provided as a response of the method, using the “ErrorMessage” class and the appropriate HTTP response codes.



As a recommendations, it is highly important to document every statuses changes and requirements for each method.

 A list of restrictions have been defoned and have to be precisely followed in order to keep protocol consistency and communication stability.