Chapter 7: Distributed System Design

Chapter 7 - Distributed System Design
byAndrew Filevet al.?
Wrox Press ©2002

	Team FLY

Overview

Designing a distributed system is an iterative process starting from requirements analysis to modular breakdown and to packaging and deployment strategies. The process is largely the same as the process for designing a non-distributed system, a system whose objects are all running in the same process. However, there are inherent differences between a distributed systems and a non-distributed one as pointed out in a seminal paper, "A Note on Distributed Computing" by Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall. (This paper can be found at: http://research.sun.com/features/tenyears/volcd/papers/intros/15Waldo.pdf as well as at other sites.)

The main differences are latency, different memory access model, concurrency, and partial failure. We'll have more detailed explanations of those differences later in the chapter. For now, the point is that designing a distributed system is different from designing a non-distributed one and those differences cannot be completely papered over by framework modules. Designers of distributed systems therefore have to take extra precautions and take into account those factors specific to distributed systems.

Fortunately, most knowledge we gained from designing non-distributed systems can be carried over. UML would be of little value if it required us to use a very different set of tools for different tasks. All the materials covered in previous chapters of this book are still valid no matter if we are designing a distributed system or a non-distributed system. With the help of good infrastructures, distributed systems require only some extra treatments and those extra treatments are mainly in the component packaging and distribution stages. Here our infrastructure of interest is of course the .NET Framework.

In this chapter, we will use a common Bank application built upon the .NET Framework as an example to demonstrate the various design decisions a designer will face in the process of designing a distributed system. However, because the initial stages like preparing use cases, class diagrams, and activity diagrams are the same no matter what system we're designing, we are not going to cover the whole design process from head to toe. Instead, we will put emphasis on the parts that are pertinent to distributed systems.

The structure of this chapter is like this: We'll first deal with terminology issues and explain what we mean by distributed system. Then we'll have some discussions on .NET's distributed infrastructure, namely .NET Remoting, that will be used in the later parts of the chapter.

After that, we look at the Bank example application. Through the example, we'll see how to decide which classes should be .NET Remoting types, how to decide the activation mode of each .NET remoting type, what code elements should be grouped in a component, how to prepare a component diagram, the technical details of compiling a component, and how to prepare a deployment diagram.

We'll cover the technical details of compiling and distributing .NET assemblies, NET's mapping of UML components.

	Team FLY