Case Study- Evolution of an Architecture “I have not failed. I’ve just found 10,000 ways that...
-
Upload
jayson-sharp -
Category
Documents
-
view
214 -
download
1
Transcript of Case Study- Evolution of an Architecture “I have not failed. I’ve just found 10,000 ways that...
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