1 / 20

Construction & Integration of Distributed Systems

This book explores the challenges and solutions in constructing and integrating heterogeneous distributed systems. It covers topics such as maintainability, simulation and debugging, and optimization of integrated systems.

camerona
Download Presentation

Construction & Integration of Distributed Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Construction & Integration of Distributed Systems Jerry James Oct. 30, 2000

  2. Outline • Constructing Distributed Systems • Maintainability • Simulation & debugging • Integrating Distributed Systems • Predicting integration effects • Optimizing integrated systems

  3. Constructing distributed systems • Explosion of heterogeneous distributed systems: • E-commerce (e.g., web-based businesses) • Distributed databases (e.g., reservation systems) • Collaborative systems (e.g., shared calendars) • Proposed solutions: CORBA, DCOM, Java RMI • Complex APIs, difficult interaction • Need for fault tolerance • Overlap communication and computation for performance reasons (e.g., with multithreading)

  4. The Maintainability Problem • Complex APIs make programming more difficult, but increase software maintenance costs even more • The need to conform to a programming model often precludes performance-enhancing optimizations • Making software fault tolerant further increases software complexity • Asynchrony (e.g., from multithreading) can be dealt with, but procedures that are always safe are rarely efficient

  5. Language-level solutions • Use a language approach, rather than an API approach • Hide complexity from the user: • object-oriented programming interface • automatically apply optimizations • hide failures • manage distribution

  6. The Kan System (http://www.ittc.ukans.edu/kan/) Kan source Kan compiler Java bytecode + Kan run-time libraries JVM JVM JVM Java Sockets

  7. High-level distributed programming • Assembly language / high-level language analogy • Code in a high-level language almost always • Code in assembly language only: • for highly performance-critical routines • when the higher-level language lacks expressiveness • Likewise, use a high-level approach to distribution, dropping to the (current) low level only: • when performance is very bad • when the high-level approach lacks expressiveness

  8. Outline • Constructing Distributed Systems • Maintainability • Simulation & debugging • Integrating Distributed Systems • Predicting integration effects • Optimizing integrated systems

  9. Simulation of distributed systems • Predict system performance before going to the expense of building it • Need to ensure that numerous factors are realistic for results to be applicable, e.g.: • Execution time for program components • Network performance under program load, including effects of network congestion • This is a hard problem!

  10. Debugging distributed systems • True asynchrony: multiple events happening in multiple places simultaneously • Event ordering is difficult to determine • No analog of single-stepping with a debugger • No analog of watch points • No global breakpoints

  11. The Reactor: simulation & debugging Code for Process 1 Code for Process 2 Code for Process 3 Post ticket REACTOR Activate ticket Network Model Ticket queue Code for Process N-2 Code for Process N-1 Code for Process N

  12. The Reactor: deployment Process 1 Process 2 Process 3 Post ticket REACTOR Activate ticket Ticket queue Process N-2 Process N-1 Process N

  13. The Reactor, continued • The code for the processes does not change: more accurate simulation • Most programmers are not comfortable with reactive programming: a little preprocessing converts from a multithreaded programming style • This means that multithreaded programs can reap the same benefits • Joint work with Dr. Niehaus of ITTC

  14. Outline • Constructing Distributed Systems • Maintainability • Simulation & debugging • Integrating Distributed Systems • Predicting integration effects • Optimizing integrated systems

  15. Integration of distributed systems • Relational databases (and transaction processing systems in general) have well-understood semantics, including failure semantics • Virtually synchronous systems have well-understood semantics, including failure semantics • Shared memory systems have well-understood semantics, including failure semantics • Other types of systems, also • But the semantics are all different!

  16. Integrating distributed systems • What happens if: • a computation running on a shared memory multiprocessor  • accesses a view serializable database  • by sending requests across an ordered multicast system  • which manages failures with a virtually synchronous controller? • Nobody knows! • Solution: throw in lots of synchronization, timeouts, and pessimistic failure handlers whenever system borders are crossed • Inefficient, and we still don’t know if it is safe!

  17. The history algebra • Although the semantics are different, every kind of system shares the notion of a history • Generalize this notion • Find basic operations that manipulate histories • Determine how to talk about consistency and failures in a general way • Result: an algebra that computes the behavior of an integrated system • Work in progress

  18. Outline • Constructing Distributed Systems • Maintainability • Simulation & debugging • Integrating Distributed Systems • Predicting integration effects • Optimizing integrated systems

  19. Optimizing integrated systems • With the history algebra, we can compute when optimizations (e.g., reducing synchronization) are safe for system boundary-crossing operations. • This is a big job; we need tool support. • Future investigation: what optimizations are desirable and when can we prove that they are safe?

  20. Conclusion • Construction of distributed systems can be made easier by programming at a higher level, dropping down to the lower level to handle performance and expressiveness problems • Simulation & debugging can be aided with the Reactor pattern • Predicting the behavior of integrated systems is on the horizon • Using such predictions to optimize performance remains to be addressed

More Related