Case Study - Evolution of an Architecture

“I have not failed. I’ve just found 10,000 ways that won’t work.”

- Thomas Edison

In the beginning…

• There was a contract: build a dedicated workstation– Offload the scanner for basic operations:

• Scan Review

• Printing

– Provide advanced algorithms• Fast multi-planar reformatting (MPR)

• Fast 3D visualization (later)

Business Case

• Customer:– Needed a bridge solution: designing their own “ultimate” solution

in-house, needed something quick to tide them over

• Contractor:– Needed credibility of successful delivery for large medical OEM

– Needed up-front payment, licenses

– Penalties (for late delivery) to be avoided

Technical Requirements

• Sun host

• Use proprietary hardware – VME bus– DVP (one or 2 per system)

• 8 DSP (per board) SMP architecture

• Each has access to 256 Mb shared memory, shared bus

– Additional boards:• Frame buffer (FB)

• Overlay buffer for GUI

• Printer interface

Surprise!

• Some contractual terms agreed to before requirements signed off– Delivery date – needed to solve their customer problem

– Penalties

• Requirements creep turned into a stampede– Undo/redo

– Multi-windows• Linked or unlinked

– Processing while “cine”

– Multiple screen layouts

– Etc.

Display

Rev 1 Architecture: Platform view

Sun host

Accelerator (VME backplane)

Frame bufferOverlay

[DVP 2]

DVP 1

VME

Accelerator – expanded view

Rev 1Architecture: Modules – hardware interface detail

FrameBuffer

App code

U-kernel

VM

E bus

DVP

App code

U-kernel

Ovl

Ovl Driver

DVP Driver

Application (Unix)

UI

Application Code

Rev 1 Architecture – Modules – UI Detail

Dispatcher Ovl DriverUser events

Undo Manager

ApplicationsOverlay display

Window Manager

Image display/processingDVP

OVL

Position and state

Rev 2 - Background

• Updated Business Proposition– 2 products in the pipe

• Contract

• In-house

– Many more planned• Radiology review

• Surgery

• Many more contracts

– Considerable overlap in functionality: reuse!• Create a software toolkit

– Opportunity: • We will market accelerated product development to get more contracts

• OR

• OEMs (Original Equipment Manufacturers) would buy the toolkit for their own product development

Toolkit vs. Platform

• Need to support a family of workstations, all requiring modular support for:

- Visualization

- Display of data sets

- Hardcopy

- Many x-ray printers, all with proprietary interfaces and incompatible functionality

- Database

- No decent support for images in the RDMS

- Want:

- Client/Server

- Asynchronous

- Caching

Toolkit vs. Platform

Toolkit Platform

Structure Collection of libraries Client side libraries, [server side processes]*

Design OOD OOD

Philosophy • More flexibility in design of application

• Many design decisions are made for the application (I.e. reuse at the design level)

• Can result in more rapid application development

*not a requirement of a platform/framework, but this is the architecture that was chosen

Visualization• Aim: produce different views of the acquired data

– 2D – from different viewpoints or– 3D

• Large data sets imply considerable processing time– 64 slices (256x256x12bits) = 6.2Mb– 100 slices (256x256x12bits) = 9.8 Mb– Algorithms: essentially random access through entire stack

• On a conventional workstation, updating the views was very slow – longer than the time required to send a computed image over a network

• Ahah!– Use a client-server architecture for the Visualization engine– A Visualization Server will accept multiple connections– Accept requests and provide images to clients– Will run on the fastest machine on the network – e.g. a machine

with an attached accelerator

Printing and Database

• Database – client /server (no brainer)– Optimized for medical images

• Handled bulks efficiently

• Extensive client side support for schemas naturally modeling image headers

• Printing?– Why not? Have one workstation attached to all the printers

– Have a Hardcopy Server running on the workstation

– Manages requests for printing• Asynchronous (non blocking)

• Does all the processing – offloads the display station (if separate)

• Can configure the workstation to handle this task optimally

Image Applications Platform

ApplicationOther

application

Visualization Hardcopy Database

Sockets

Screen DiskLaserImagers

Visualization: Architectural Decisions

• Time frame: 1990

• OOD– this was not taken for granted!

• Language– C++/Objective C – neither mature, neither established

– Performance could not be compromised

– Only option was to implement OOD via C• Not as ridiculous as it sounds!

• No inheritance needed

– Well maybe it would have been nice

• Information hiding via structs; methods managed via naming conventions

Visualization : Architectural Decisions• User (note – not end-user!) paradigm:

– Users will create applications using Visualization server by creating objects and connecting them

– The connections enable data to flow

– Order of connection determines topology and direction of data flow

– Once network of objects is created, load data into system, and processing proceeds according to the topology

– Change data at any point in the system, all downstream objects are notified of the change (in the proper sequence of course)

– User could trade off image quality against performance• Specify low quality during “interactive” operations

• Once user stopped interaction (button up) or paused (settable policy) high quality compute would begin – but be discarded if interaction started again

Example Visualization Application

Display ScreenRaster

Stack

Raster

MPR

Client (UI)

Annotate Geom2

Server

sockets

Visualization: Architectural Decisions

• Asynchronous interaction between client and server– Why? Performance!

• Image data will be supported in native format– 12 bits (signed and unsigned), 16 bits (s + u), 8 bits, binary

– Turned out to be a hugely significant decision

– Multiple implementations of every algorithm

– Why? Performance!

• Memory Management– add some intelligence (understanding of the application) to the file

system• Write out data structures, not just pages

• Garbage collection

Visualization Server: Architectural Decisions

• Parallelism:– All algorithms written so inner loops are parallelized– Number of threads configurable at run-time so performance can be

optimized for architecture– Client and server interact asynchronously

• Client loads data into server– Shared memory if same host– Sockets otherwise

• Client sends processing requests to server– Processing happens asynchronously

– Support for our proprietary hardware PLUS– Support for any other SMP

• Display– Visualization Server can display via X-server if supported– Otherwise uses native display support

• Optimized wherever possible

How did it work?• Very well – especially for prototyping and demonstrations

– But – that’s not what it was designed for!

• Problem: memory– Application developers would load up all the objects in such a way that all

data was locked in memory– Subverted memory management– Could result in Terrible performance– Solution: Training and Support (note – revenue source)

• Problem: bugs– C – error prone

• Many data structures were dynamically created arrays• Lots of opportunities for running past ends of arrays

– Plus: asynchronous• Sometimes very hard to reproduce bugs! (never know where it will crash)

• Problem: testing– Huge number of combinations– Lots of platforms to support – regression tests had to run on all of them– Lots of customer – all had their own schedules

• 50 releases in 1 year!

How did it work?

• In the end, applications built internally worked very well

• External development teams fared less well

• Why?– Access to developers

– Fast turn around on bug fixes

– Very nice programming paradigm• Easy to change behaviour of application

Evolutionary architecture: from Platform to Framework

• Recall (from Gamma et al):– “A Framework is a set of cooperating classes that make up a

reusable design for a specific class of software.”

• In this case the class of software is medical imaging applications

• Lots of similarities between Platform and Framework

• Difference is mostly in the degree of abstraction

Medical Imaging Application Framework

UI

Framework

Platform Client API

Visualization Printing Database

Framework – Theory vs. Reality

• Theory: Framework will speed up application development• Reality: not as much as hoped

– Unstable – Features in development – usual delays

• Many customers- low priority customers get ignored

– Debugging – much harder• Extra layer – where’s the bug?• Partly management mistake – organizational “wall” between Platform

and Framework teams

– Only benefits the “shared” functionality covered by Framework• Each application has its own unique requirements

– Look and feel– Interfaces– Custom processing

Framework and Platform – Lessons Learned

• Developing applications on top of Platforms that are under development requires resources allocated to support

• Every layer compounds debugging effort considerably– Internally: Framework is one more customer of Platform group

– Externally: one company – fix the problem

• Client-server architecture for Visualization cost more than it was worth– Complexity of maintaining both client and server side libraries

– Debugging overhead

– Multiple connections – never used