1. PALM-3000 Software Architecture T. TRUONG Team Meeting #7 27 February 2008

2. PALM-3000 Agenda Architectural Goals Constraints and Strategies System Architecture Database Architecture GUI Architecture Toolchain

3. PALM-3000 3 Architectural Goals Ranked in order of decreasing importance: Performance –Split-phased, active-message based architecture, improved database engine. Modular construction –Component based architecture. Flexible composition –Interface-driven, distributed architecture. Reliability –No dynamic memory allocation after initialization. Extensibility –Table driven command processor, component based architecture Maintainability –Automated document generation similar to JavaDoc.

4. PALM-3000 Architectural Constraints & Strategies Within the schedule and budget constraints for 2009 delivery. Reuse existing code wherever appropriate. Incorporate publicly available proven toolchains and libraries. Incremental delivery if necessary.

5. PALM-3000 Software Context Overview P3K AO TCS Science Instruments LGS BTO Control Data AOOperator

6. PALM-3000 6 Architectural Highlights The PALM-3000 software architecture is… Component-based Interface-driven Split-phased Distributed Active-message-based

7. PALM-3000 Component-Based Architecture Similar to objects –Define functions and allocate state. –State variables are strictly private. Different from objects –Components are singletons – can’t instantiate them. –Modeled after hardware – can’t instantiate control regs and output pins. –Code reuse via templates and parameterized interface. Use purely local namespace –A calls C and B calls C. Yet A and B refer to different implementations of C. Encourage modular design

8. PALM-3000 Interface-Driven Architecture Components interact via bidirectional interfaces An interface = {commands} U {events} –Command = function to be implemented by the interface’s provider. Calls down the component graph. –Event = function to be implemented by the interface’s user. Calls up the component graph. A component must implement the events in order to call the commands of the interface. A component may use or provide multiple interfaces. Separate construction from composition. Enable dynamic composition. Allow underlying implementations to be replaced easily.

9. PALM-3000 Split-Phased Architecture Invocation and completion split into two separate phases of execution –For a long-running operation, the call returns immediately. The called abstraction issues a callback (event) when it completes. Fully event-driven Keep the system responsive –There is never a situation when an application needs to take an action but all of its threads are tied up in blocking calls Save memory –Determining the exact stack size is difficult in case of a blocking operation. The OS often chooses a very conservative and therefore large size. –Creating large variables on the stack is rarely necessary.

10. PALM-3000 Distributed Component Architecture Based on proxy components –Shield the client/user components from the fact that the underlying components are remote. All components have proxy capability. Use common library to enable proxy capability.

11. PALM-3000 Active-Message-Based Architecture Active Messages provide the enabling mechanism for low-latency remote procedural calls. Provide messaging functionality for proxy components.

12. PALM-3000 Implementation View

13. PALM-3000 Database Architectural Highlights Consists of two main components –AODR: Data recorder component. –AODS: Data server component. Provides publish-subscribe capability. Embeddable, in-memory, not client-server –Components may link directly into the application. –Run in the same address space as the application. –No interprocess-communication required.

14. PALM-3000 Database Architectural Highlights (Continued) Simple function-call API –Simple key/value lookup and store. –No query language (SQL) to parse. –No execution plan to produce. –Not a relational database –API binding for C, Java,and IDL language. Data stored in application-native format –No translation or mapping required. Configurable Cache –Provides fast access to memory-resident data. –Minimizes data stores to disk. –Exploits temporal locality of reference.

15. PALM-3000 Database Architectural Highlights (Continued) High concurrency –Multiple processes (readers and writers) on a single machine, or multiple threads in a single process, can all use the same database concurrently. Transactions and recovery –Permit multiple changes appear at once. –Guarantee the database is complete and usable after a system or application crash. Hot backups –Support backups while the database is in use, using standard Unix utilities (dump, tar, cpio, cp, …) Nothing more than key/value lookups with cache management plus transaction and locking support

16. PALM-3000 Graphical User Interface Support multiple GUI clients –One controller with multiple viewers. Thin Java clients –No automation logic. –Decouple automation logic from GUI logic. XML-based user interface –Develops much faster and more easily than in ordinary Java. –Allows data binding (properties updated in real-time as values of expressions change). –Supports powerful CSS stylesheet (enables skinning). –Separates logic from presentation.

17. PALM-3000 Open Source Toolchain nesC –A component-oriented programming language, C-extension. –Compiler is an extension of GCC. –Compiler outputs C code or object code. nesdoc –Generate code documentation using simple tags. –Same concept as JavaDoc. –Can generate a component graph using dot. Berkeley DB –“The most efficient, most scalable, and fastest database engine available today.”