Case Study - Evolution of an Architecture

1. Case Study - Evolution of an Architecture “I have not failed. I’ve just found 10,000 ways that won’t work.” - Thomas Edison

2. 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)

3. 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

4. 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

5. 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.

6. Frame buffer Display Overlay [DVP 2] DVP 1 Rev 1 Architecture: Platform view Accelerator – expanded view Sun host VME Accelerator (VME backplane)

7. Application (Unix) UI Application Code Rev 1Architecture: Modules – hardware interface detail Frame Buffer VME bus Ovl U-kernel App code Ovl Driver DVP U-kernel App code DVP Driver

8. Rev 1 Architecture – Modules – UI Detail Dispatcher OVL User events Ovl Driver Window Manager Undo Manager Position and state Applications Overlay display DVP Image display/processing

9. 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

10. 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

11. Toolkit vs. Platform *not a requirement of a platform/framework, but this is the architecture that was chosen

12. 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

13. 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

14. Image Applications Platform Application Other application Sockets Visualization Hardcopy Database Disk Screen Laser Imagers

15. 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

16. 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

17. Raster Example Visualization Application Client (UI) Server sockets Stack Screen Display MPR Annotate Raster Geom2

18. 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

19. 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

20. 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!

21. 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

22. 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

23. Medical Imaging Application Framework UI Framework Platform Client API Visualization Printing Database

24. 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

25. 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