qewd-ripple: The Ripple OSI Middle Tier

Copyright © 2016 M/Gateway Developments Ltd

qewd-ripple

The Ripple OSI Middle Tier

Rob TweedDirector, M/Gateway Developments Ltd

Twitter: @rtweed


What is qewd-ripple?

• Demonstration version of the Node.js-based middle tier for the Ripple OSI Application– http://rippleosi.org/

• Built using the QEWD framework– http://www.mgateway.com

• Integrates multiple OpenEHR Servers– Ripple's UI presents a unified interface

• REST-based


Installing qewd-ripple

• See instructions at:– https://github.com/RippleOSI/Qewd-Ripple

• The built-in installer script creates a fully-working system– Ubuntu 16.04– Raspberrry Pi

• Could be easily adapted for use with other flavours of Linux


qewd-ripple

• Linux installation: components installed include:– Node.js 6.x– QEWD– Redis or GT.M: "Global Storage" NoSQL

database– MySQL– Ripple UI:

• HTML, JavaScript, CSS files


Node.js

• Server-side JavaScript


QEWD• Node.js-based module• Used as the REST platform for qewd-ripple• Provides an outward-facing HTTP/REST

interface– Courtesy of Express, the standard Node.js web server

• Provides the run-time environment for Ripple's REST API handler functions– Written in JavaScript

• Acts as a proxy to and integrates multiple OpenEHR (and potentially other) servers


GT.M

• Used by QEWD as an embedded, in-process, persistent JSON store and Document Database, for:– Session management– OpenEHR data cacheing

• On a per-user basis


Redis

• Redis– High-performance key/value store– ewd-redis-globals module:

• Gives Global Storage functionality to Redis– Used by the Raspberry Pi version of qewd-

ripple– Alternative to GT.M for Linux version of qewd-

ripple• Behaves identically to GT.M as far as qewd-ripple

is concerned


MySQL

• Used in the Ripple OSI Demonstrator for PAS functionality


Starting qewd-ripple

• cd ~/qewd• Demo-mode:

– node ripple-demo• Secure mode

– node ripple-secure


Running Ripple OSI

• Point a browser at the IP address or host name of the server running qewd-ripple, eg:

– http://192.168.1.100


Ripple Demo Mode

• Simulates a user with full access to all patient data– IDCR mode


Ripple Secure Mode

• User identity management taken care of by a 3rd party service– The qewd-ripple demonstrator uses Auth0

• Users can have two alternative modes of access:– IDCR: clinical user, with full access to all

patient data– PHR: an individual patient, with read access

to his/her own data only


qewd-ripple architecture

• Extends QEWD• Uses it for REST access only• Implements handlers for the Ripple OSI

REST APIs


QEWD (using Redis/GT.M)

Node.js Worker Process

Master Node.js Process

Queue

Queueprocessor/dispatcher

qewd

ewd-qoper8-gtm

Redis/GT.M

ewd-document-store

GlobalStorage

ewd-session

Express

HTTP(S)Interface

RES

T C

lient

Custom WorkerModule

ewd-qoper8

Constructed from a number of EWD 3 modules


QEWD's Architecture

• Master Process– Handles all incoming REST requests

• Via Express• Queues and dispatches requests to worker

processes

• Worker Processes– You define how large a pool of workers you

require– Each worker handles just one request



Queue


Ripple RESTRequest

QEWD Architecture

Every incoming requestis passed from Expressand placed in a queue

No further processingof requests occurs inthe master process


QEWD ArchitectureMaster Node.js Process

Queue


Queue dispatcher isinvoked whenever arequest is added tothe queue


QEWD Architecture



Queue


Worker processstarted if none

available


QEWD Architecture



Queue


qewd-rippleHandler module

Redis/GT.M

QEWD &qewd-ripple-specific

Modules loaded

and connected todatabase:

Redis or GT.M


QEWD Architecture



Queue


CustomWorkerModule

Node.js Worker ProcessCustomWorkerModule

Redis/GT.M

Request passedto worker


QEWD Architecture



Queue


CustomWorkerModule

Worker flagged as Unavailable


Redis/GT.M

Begin processing message



Queue


Unavailable / processingAnother incomingRippleREST request



Redis/GT.M


QEWD Architecture



Queue


CustomWorkerModule

Unavailable / processing



Redis/GT.M


Redis/GT.M

If worker pool size not exceeded,another worker is startedand request passed to it



Queue





Redis/GT.M

If entire Worker Pool is busy:




Redis/GT.M




Redis/GT.M



Queue





Redis/GT.M

If entire Worker Pool is busy:




Redis/GT.M




Redis/GT.M

New requests remain

in queue



Queue





Redis/GT.M

As soon as a worker is available again,a queued message can be passed to it




Redis/GT.M

Available


Redis/GT.M



Queue


Finished




Redis/GT.M

A user's handler function signalscompletion using the function:

finished(responseObject);

This returns the responseobject to the master

process



Queue


Finished




Redis/GT.M

And the response ispassed to Express which

returns it to the clientthat sent the original request



Queue


Available


Redis/GT.M

The finished() functionalso automatically returnsthe worker process back

to the available pool

So it can now handlethe next queued request



Queue


Available


Redis/GT.M

Worker processes, once started, are persistent

No start-up / tear-down cost

Workers will automatically close themselves down if they are

inactive for more than a pre-setthreshold time period



Queue


Available


Redis/GT.M

Worker processes only handlea single request at a time

Completely isolated run-timeenvironment for handler functions

No need for concerns aboutNode.js concurrency, so

synchronous APIs can be used



Queue


Available


Redis/GT.M

Long-running or CPU-intensivelogic has no direct impact on

other worker processes



Queue


Node.js concurrency is handledby the master process.

100% asynchronous logic

The master process doesalmost nothing

No CPU-intensive or long-running tasks, so very

high-performance

All the work happens in theisolated worker processes

MultipleConcurrentIncoming

REST requests


qewd-ripple Session Management

• Everything begins with receipt of /api/initialise request, sent from the Ripple UI


The /api/initialise API

• If:– qewd-ripple is running in demo mode; and– this is the first time the browser has connected

• Then:– the middle tier starts a new QEWD Session which creates a

token• The token is a random uuid-formatted string

– A hard-coded set of user credentials are stored in the Session (an IDCR-mode user)

– The Session token is returned in the response to the UI• The UI stores this as a cookie named JSESSIONID

– All subsequent requests will include this cookie



• If:– qewd-ripple is running in secure mode; and– this is the first time the browser has connected

• Then:– the middle tier passes control to Auth0– User logs in via Auth0– If successful, the credentials are passed back to qewd-ripple– qewd-ripple creates a new QEWD Session and saves the

credentials in the user's Session– The Session token is returned in the response to the UI

• The UI stores this as a cookie named JSESSIONID


The /api/initialise API

• If:– The request includes a JSESSIONID cookie containing a

currently valid, unexpired QEWD Session token• Then:

– the middle tier returns an OK response that also tells the UI the user's mode:

• IDCR or PHR



• On successful receipt of the /api/initialiseresponse, the UI issues an /api/user request– This request will now include the JSESSIONID cookie

• So qewd-ripple can identify the user's Session

• The middle tier retrieves the user's credentials from the Session and returns them to the UI

• The UI can now display the user's details



• The UI can now start issuing its REST APIs to the middle tier

• Every request will include the JSESSIONID cookie which contains the user's QEWD Session token, allowing the request's handler to access the user's QEWD Session:– To retrieve data– To cache data


Accessing OpenEHR ServersBrowser QEWD

GT.M orRedis

ewd-qoper8queue

qewd-rippleModule

Express

Worker

Puls

eTile

UI REST/

HTTP

Incoming request for somepatient heading data

eg Allergies



GT.M orRedis

ewd-session

ewd-qoper8queue

qewd-rippleModule

Express

Worker

Puls

eTile

UI

Is the allergies data in the user'sQEWD Session storage?



GT.M orRedis

ewd-session

ewd-qoper8queue

qewd-rippleModule

Express

Worker

Puls

eTile

UI


No



GT.M orRedis

ewd-qoper8queue

qewd-rippleModule

Express

OpenEHRServer

AQL overHTTP(S)

Worker

Puls

eTile

UI

OpenEHRServer

Fetch the allergies datafrom the OpenEHR

servers



GT.M orRedis

ewd-qoper8queue

qewd-rippleModule

Express

OpenEHRServer

HTTP(S)

Worker

Puls

eTile

UI

OpenEHRServer

And save it in theuser's QEWD

Session storage

ewd-session



GT.M orRedis

ewd-session

ewd-qoper8queue

qewd-rippleModule

Express

Worker

Puls

eTile

UI

Repeat the logic…




GT.M orRedis

ewd-session

ewd-qoper8queue

qewd-rippleModule

Express

Worker

Puls

eTile

UI

Repeat the logic…


Yes



GT.M orRedis

ewd-session

ewd-qoper8queue

qewd-rippleModule

Express

Worker

Puls

eTile

UI

Return it to theBrowser that made

The request

Map OpenEHRfield-names toUI field-names



GT.M orRedis

ewd-qoper8queue

qewd-rippleModule

Express

Worker

Puls

eTile

UI REST/

HTTP

If a later request arrivesfrom this user for

Allergies data



GT.M orRedis

ewd-session

ewd-qoper8queue

qewd-rippleModule

Express

Worker

Puls

eTile

UI


Yes



GT.M orRedis

ewd-session

ewd-qoper8queue

qewd-rippleModule

Express

Worker

Puls

eTile

UI

Return it to theBrowser that made

The request

Map OpenEHRfield-names toUI field-names


QEWD Session = Headings Cache

• Each user's QEWD Session acts as a high-performance cache of headings data– Minimises "round-trips" to OpenEHR servers

• QEWD Session storage:– Persistent JSON storage– Document database– GT.M and Redis behave identically as far as

qewd-ripple is concerned

Software

qewd-ripple: The Ripple OSI Middle Tier