WIISARD Core Architecture

Steven Brown <swbrown@ucsd.edu>7/27/2005

WIISARD Core Architecture

● Goal: To handle sporadic connectivity, small writes, and multiple writers in a somewhat chaotic situation for multiple applications– Connectivity assumed bad

● Minimize impact on user– No perceived latency

– Small changes, not forms● No 'submit' forms, changes are individual and instant

– Easier to collaborate– No partially filled then forgotten forms

– Possibly more than one writer on one patient● Locking is inappropriate with poor connectivity● 'Small changes' lets us use a version control metaphor

– Minimize work for applications to support this

Components 1/2

● Client Library– Application interface to the system

● Remoted object model● Built-in transparent connectivity● Data persistence● Replay prevention● Consistency

● Server– Persists state into the database– Relays data updates from the database to clients– Supports 'push' model

● Database– SQL database

● Provides read/write support in such a way it works smoothly with the server

– Support for non-WIISARD applications● Logging of all changes

Components 2/2

Application/Client view of WIISARD

● Applications link to the Client Library– All data is presented as object models

● Think ORM● Getters/setters

– Modifications understood by the Client Library● Performs the predicted action immediately

– Updates via Observer Pattern– Network details are hidden

Hidden network details

● Layered architecture● Minimizes need to modify applications when

the architecture changes– It might not even be over a network!

● What /does/ need exposed?– 3 key properties:

● 1: “Are there actions I have taken that have not yet been synchronized?”

● 2: “If I take an action, will it probably synchronize immediately?”

● 3: “Is the data I am looking at no more than X seconds out of sync?”

Key properties

● Examples:– Access point that wants to set only its current

location● Property 1/2 – is there no unsynchronized data, and

will my change be immediate– If not, don't change the model – prevents backlog.

– Access point that wants a trail● Continuously adding location entries regardless of

Client Library state– Provider handheld

● Property 3 – is the data synchronized?– Currently, a green icon in the taskbar represents this – if

green, the data is no more than 15 seconds out of date.

Client Library internals 1/2

● First, a description of the parts, then tied together by examples

● 'Command's for each possible action– “->setName(...)”

● 'Message's for RMI● 'Model's for representing remote object state.● 'RootModel's for representing collections of all

Models of a type.● 'Wiisard2' for holding a base link to all

RootModels, and other information about the connection

● 'Conduit' for synchronizing the Wiisard2 model.

Client Library Internals 2/2

● 'CommandQueue' for queuing Commands to be synchronized– Also for Command Pattern to handle updates

● Local commands are unrolled before applying server updates, then re-rolled (think version control)

● 'Transport' for the transport-level connection to the remote state

● 'TransferQueue' for Messages currently considered on the wire

● Derivations of Messages, Conduits, and Transports for specific encodings (like SOAP)– Core logic is encoding-neutral

Reliable messaging

● Some RMI Messages are unreliable– The login protocol

● This is repeated on connection● Some are reliable

– Commands● Must be resent if the connection broke before the

server got it● Result must be re-queried if the connection broke

before the client got it● Session 'position'

– Monotonically increasing enumeration of Commands

● Keep track of what Commands are known to both parties

Client Library – example model

● Class PersonModel {– ...– setName(...)– ... getName()– ...– signal updated– signal stateChanged– ...

● };● Signals (Observer Pattern)

– “updated” for data updates– “stateChanged” for metadata updates

Publish/Subscribe

● Client Library follows Pub/Sub pattern– Allows synchronization with subsets of the full

model● You might want to synchronize:

– all access points, but not their locations– All patients but not access points– A single access point

● “Agents”● gpsadapter

● Subscription to models via “->subscribe()”– 'stateChanged' on subscription

● Updates of the data itself trigger 'updated'

Client-side geolocation by pub/sub

● Client subscribes to access point mac addresses and locations

● Client has a trilateration geolocator built-in● Can geolocate online and /offline/

– Assume access points move infrequently● Offline cache of old access point locations fairly

accurate– No extra work on the part of the application

● Client Library takes care of this transparently

Example to put it together

● We'll go over the same example at multiple detail levels– Basic, Detailed

● We're ignoring the derivations for specific encodings, as they're not that interesting, so would waste space in the description.– (The client's Conduit would be derived for a

SOAP encoding, and has overridden virtual methods to create messages of that specific encoding, and to create a derived Transport for the Transport in use)

Example (Basic)

● Initially: Jose Sanchez and Gene Scott have provider devices – Jose is offline, Gene is online.

● Jose changes the name of patient 'swb' to 'Steven Brown'.

● Jose becomes connected– This happens transparently when Jose is in

range of the network● Gene sees the updated name

– Again, this happened transparently, and instantly ('push')

Example (Detailed) 1/7

● Initially: Jose Sanchez and Gene Scott have provider devices – Jose is offline, Gene is online.

● Jose changes the name of patient 'swb' to 'Steven Brown'.– A 'Set name' Command is generated and added

to the CommandQueue.– The Conduit sees the CommandQueue updated

● - The Command's predicted action is performed on the local model

– So no observable latency by the user

● Jose becomes connected– Each second, the Client Library has been

transparently trying to do a DNS resolution and connect

– The TCP connection connects– The Transport is instantiated– The Conduit begins the login protocol

● Phase: Connected, LoggingIn– LoginMessage is generated and added to the

TransferQueue● Username, password, session UUID, preserved session

position● The position is used for crash recovery – the Conduit

tells the server what position it last persisted

Example (Detailed) 2/7

– The Transport asynchronously packages and relays this Message to the Server as an RMI of the 'login' method

– The Server's 'login' method creates a new session if it hadn't seen the UUID, and returns the session position of the session

– The transport notifies listeners of the receipt of the reply (The Conduit is listening for it)

● Phase: Connected, Synchronizing– The Conduit checks the server's idea of the position against

its own to see if replies to Commands had been lost in flight ● If so, it requests those lost replies before continuing

● Phase: Connected, Subscribing– All Models that had been subscribed to are resubscribed– The Conduit waits for all the updates to the Models to arrive

and be applied before continuing● Phase: Ready

– The Conduit can now communicate normally

Example (Detailed) 3/7

– The Conduit relays the pending 'set name' command

● A CommandMessage wrapping the Command is generated and placed in the TransferQueue.

● The Transport relays the message in the TransferQueue it to the Server, invoking the 'setName' method (RMI)

● The server checks the preconditions for the Command

– Think version control conflicts● The Server performs a SQL operation on the

Database to 'UPDATE' that patient.

Example (Detailed) 4/7

– The Database updates the patient, and causes two triggers● One trigger writes the time, user, and transaction number

to keep track of who did what● The other trigger writes the table-level operations and a

copy of the data into a log table for history, and generates an asynchronous event(s) to notify any listeners on the table(s)

● The Server returns an acknowledgment to the Command

● The Conduit marks the Command as completed– It knows it no longer needs to resend it on loss of

connection.● Gene sees the updated name

– The asynchronous event generated by the Database from the 'set name' Command is received by the Server

Example (Detailed) 5/7

– The Server sees that Gene and Jose are subscribed to that patient

– The Server's Conduit collects the data needed to represent the Model that changed

● May be multiple tables, think ORM– The Server's Conduit packages this in a

PatientUpdateMessage and places it on the TransferQueue

– The patientUpdate method on the Client's Conduit is invoked

● The Message is translated into a Model and placed on the UpdateQueue

Example (Detailed) 6/7

– The Server sees no other Model updates made in that transaction, so generates an EventsCompleteMessage.

– The Client Conduit's eventsComplete method is invoked

● All updates in the UpdateQueue are applied to the local set of Models

– The modification to the PatientModel Jose and Gene's provider application is subscribed to causes a 'updated' event

● The provider application is called back from the 'updated' event, and updates the display with the model's content

Example (Detailed) 7/7

Equivalency to other designs

● Many designs can be implemented on top of the WIISARD architecture

● Soft exclusive locking– Preconditions of a command would be the entire

Model● Sensor command and control

– Sensors subscribe to a Model of themselves● Reflection of sensor options● Reflection of sensor state

● Alerts– Applications subscribe to a Model that acts as a

bulletin board for alerts● Agents

Agents

● Using agents, functionality can be implemented outside of the core architecture– Independent servers that use the Client Library

● Could have an agent that subscribes to patients/locations, watches for a particular condition, and posts an alert

● “GPSAdapter”– Agent server running on the access points– Subscribes to the Model representing its mac

address– Updates the Model from GPS information captured

locally– Could also be given commands reliably through the

Model

Work to be done

● Expose subset synchronization– Small API change

● “->subscribe()”– Currently subscribes to everything

● Add geolocator to the client– ActiveCampus's geolocator

● Maybe Intel's PlaceLab later● Push collision resolution to the user

– So solvable by GUI● Rename 'Map' to 'Subscribe'

– Folks are confused when I say 'Map'