Node.js Ripple OSI Middle Tier Demo

Copyright © 2016 M/Gateway Developments Ltd
qewd-ripple
The Ripple OSI Middle Tier
Rob Tweed
Director, 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
Queue
processor/
dispatcher
qewd
ewd-qoper8-gtm
Redis/GT.M
ewd-document-store
Global
Storage
ewd-session
Express
HTTP(S)
Interface
RESTClient
Custom Worker
Module
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
Queue
processor/
dispatcher
Ripple REST
Request
QEWD Architecture
Every incoming request
is passed from Express
and placed in a queue
No further processing
of requests occurs in
the master process

QEWD Architecture
Queue
Queue
processor/
dispatcher
Queue dispatcher is
invoked whenever a
request is added to
the queue

QEWD Architecture
Queue
Queue
processor/
dispatcher
Worker process
started if none
available

QEWD Architecture
Queue
Queue
processor/
dispatcher
qewd-ripple
Handler module
Redis/GT.M
QEWD &
qewd-ripple-specific
Modules loaded
and connected to
database:
Redis or GT.M

QEWD Architecture
Queue
Queue
processor/
dispatcher
Custom
Worker
Module
Custom
Worker
Module
Redis/GT.M
Request passed
to worker

QEWD Architecture
Queue
Queue
processor/
dispatcher
Custom
Worker
Module
Worker flagged as Unavailable
Custom
Worker
Module
Redis/GT.M
Begin processing message

QEWD Architecture
Queue
Queue
processor/
dispatcher
Unavailable / processing
Another incoming
Ripple
REST request
Custom
Worker
Module
Custom
Worker
Module
Redis/GT.M

QEWD Architecture
Queue
Queue
processor/
dispatcher
Custom
Worker
Module
Custom
Worker
Module
Custom
Worker
Module
Redis/GT.M
Custom
Worker
Module
Redis/GT.M
If worker pool size not exceeded,
another worker is started
and request passed to it

QEWD Architecture
Queue
Queue
processor/
dispatcher
Custom
Worker
Module
Custom
Worker
Module
Redis/GT.M
If entire Worker Pool is busy:
Custom
Worker
Module
Custom
Worker
Module
Redis/GT.M
Custom
Worker
Module
Custom
Worker
Module
Redis/GT.M

QEWD Architecture
Queue
Queue
processor/
dispatcher
Custom
Worker
Module
Custom
Worker
Module
Redis/GT.M
If entire Worker Pool is busy:
Custom
Worker
Module
Custom
Worker
Module
Redis/GT.M
Custom
Worker
Module
Custom
Worker
Module
Redis/GT.M
New
requests
remain
in queue

QEWD Architecture
Queue
Queue
processor/
dispatcher
Custom
Worker
Module
Custom
Worker
Module
Redis/GT.M
As soon as a worker is available again,
a queued message can be passed to it
Custom
Worker
Module
Custom
Worker
Module
Redis/GT.M
Available
Custom
Worker
Module
Redis/GT.M

QEWD Architecture
Queue
Queue
processor/
dispatcher
Finished
Custom
Worker
Module
Custom
Worker
Module
Custom
Worker
Module
Redis/GT.M
A user's handler function signals
completion using the function:
finished(responseObject);
This returns the response
object to the master
process

QEWD Architecture
Queue
Queue
processor/
dispatcher
Finished
Custom
Worker
Module
Custom
Worker
Module
Custom
Worker
Module
Redis/GT.M
And the response is
passed to Express which
returns it to the client
that sent the original request

QEWD Architecture
Queue
Queue
processor/
dispatcher
Available
Custom
Worker
Module
Redis/GT.M
The finished() function
also automatically returns
the worker process back
to the available pool
So it can now handle
the next queued request

QEWD Architecture
Queue
Queue
processor/
dispatcher
Available
Custom
Worker
Module
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-set
threshold time period

QEWD Architecture
Queue
Queue
processor/
dispatcher
Available
Custom
Worker
Module
Redis/GT.M
Worker processes only handle
a single request at a time
Completely isolated run-time
environment for handler functions
No need for concerns about
Node.js concurrency, so
synchronous APIs can be used

QEWD Architecture
Queue
Queue
processor/
dispatcher
Available
Custom
Worker
Module
Redis/GT.M
Long-running or CPU-intensive
logic has no direct impact on
other worker processes

QEWD Architecture
Queue
Queue
processor/
dispatcher
Node.js concurrency is handled
by the master process.
100% asynchronous logic
The master process does
almost nothing
No CPU-intensive or long-
running tasks, so very
high-performance
All the work happens in the
isolated worker processes
Multiple
Concurrent
Incoming
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/initialise
response, 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 Servers
Browser QEWD
GT.M or
Redis
ewd-qoper8
queue
qewd-ripple
Module
Express
Worker
PulseTile
UI
REST/
HTTP
Incoming request for some
patient heading data
eg Allergies

Browser QEWD
GT.M or
Redis
ewd-session
ewd-qoper8
queue
qewd-ripple
Module
Express
Worker
PulseTile
UI
Is the allergies data in the user's
QEWD Session storage?

Browser QEWD
GT.M or
Redis
ewd-session
ewd-qoper8
queue
qewd-ripple
Module
Express
Worker
PulseTile
UI
No

Browser QEWD
GT.M or
Redis
ewd-qoper8
queue
qewd-ripple
Module
Express
OpenEHR
Server
AQL over
HTTP(S)
Worker
PulseTile
UI
OpenEHR
Server
Fetch the allergies data
from the OpenEHR
servers

Browser QEWD
GT.M or
Redis
ewd-qoper8
queue
qewd-ripple
Module
Express
OpenEHR
Server
HTTP(S)
Worker
PulseTile
UI
OpenEHR
Server
And save it in the
user's QEWD
Session storage
ewd-session

Browser QEWD
GT.M or
Redis
ewd-session
ewd-qoper8
queue
qewd-ripple
Module
Express
Worker
PulseTile
UI
Repeat the logic…

Browser QEWD
GT.M or
Redis
ewd-session
ewd-qoper8
queue
qewd-ripple
Module
Express
Worker
PulseTile
UI
Repeat the logic…
Yes

Browser QEWD
GT.M or
Redis
ewd-session
ewd-qoper8
queue
qewd-ripple
Module
Express
Worker
PulseTile
UI
Return it to the
Browser that made
The request
Map OpenEHR
field-names to
UI field-names

Browser QEWD
GT.M or
Redis
ewd-qoper8
queue
qewd-ripple
Module
Express
Worker
PulseTile
UI
REST/
HTTP
If a later request arrives
from this user for
Allergies data

Browser QEWD
GT.M or
Redis
ewd-session
ewd-qoper8
queue
qewd-ripple
Module
Express
Worker
PulseTile
UI
Yes

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

Node.js Ripple OSI Middle Tier Demo

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Node.js Ripple OSI Middle Tier Demo

Similar to Node.js Ripple OSI Middle Tier Demo (20)

More from Rob Tweed

More from Rob Tweed (11)

Recently uploaded

Recently uploaded (20)

Node.js Ripple OSI Middle Tier Demo