Object-Based Distributed Systems in .NET

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

	Team FLY

In this section, we'll lay the groundwork for discussion by answering the following two questions:

• What do we mean by distributed systems?

• What are the major issues that challenge designers of robust and reliable distributed systems?

Distributed Systems and Local Systems

So, what exactly is a distributed system and what is a local system? Simply put, a distributed system consists of components that run in different processes possibly (but not necessarily) on different machines. In other words, it consists of components that access different address spaces. In contrast, all components of a local system only run in one process, and are confined to a single address space. Therefore, to tell if a system is local or distributed a simple rule of thumb is to ask whether a pointer to a memory address will be valid if it's passed to another component of the system. Here, a component is a part of a system. It can be an executable, an exposed function or object in a dynamic linking library (DLL), an HTML page in a browser, etc. Take HTML pages for example. Say you have an HTML page on your machine's hard drive. You open it up with IE (Microsoft Internet Explorer) browser. When opened, the HTML page will load a COM component and invoke a method on one of the component's COM objects. Together the HTML page, the IE browser, and the COM component form an application system.

The system can be local or distributed depending on IE and the COM component. In our example, the system is distributed if the COM component is in an EXE file (we call this type of COM components out-of-process components); local if the COM component is in a DLL file (we call this type of COM components in-process components). However, if IE were implemented in a way that it would load the HTML page in one process and the COM component in another, then the system would be distributed no matter what COM component is loaded.

There is more than a single way to categorize distributed systems. For example, we can have a category for 'locally distributed systems' (sometimes referred to as logical distributed systems) that have components running in different processes on the same machine and another category for 'generally distributed systems' (sometimes referred to as physical distributed systems) that have components running in different processes on different machines.

ORPC (Object Remote Procedure Call) Protocols

Another way to categorize distributed systems is to categorize them according to the ways remote components are consumed. For example, some distributed systems make a remote function call look like a function call in the same address space. Remote procedure call (RPC)-based systems fall into this category. Other distributed systems make remote objects (instances of types) look like local objects. Components that make up this type of system communicate at an object-oriented level. Systems based on object RPC (ORPC) protocols such as DOOM and CORBA's IIOP/GIOP (Internet Inter-ORB Protocol/General Inter-ORB Protocol) are examples of this category. Readers interested in knowing more details about these protocols, their similarities, and their differences can refer to a MSDN article by Don Box, "A Young Person's Guide to the Simple Object Access Protocol", MSDN Magazine, March 2000 issue: http://msdn.microsoft.com/msdnmag/issues/0300/soap/soap.asp.

Another example of ORPC protocols is SOAP (Simple Object Access Protocol), the standard at the heart of Web Services. What makes SOAP different from the other ORPC protocols is its transport-neutral nature and the way it uses XML as the data format for recording payload information. For example, you have a HelloWorld Web Service that accepts requests from clients and returns a greeting message. The message in a request the HelloWorld service receives will be something that looks like the following.

      <SOAP-ENV:Envelope xmlns:xsi='http://www.w3.org/1999/XMLSchema- instance'      xmlns:xsd='http://www.w3.org/1999/XMLSchema'         xmlns:SOAP-ENC='http://schemas.xmlsoap.org/soap/encoding/'        xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/'        SOAP-ENV:encodingStyle='http: //schemas.xmlsoap.org/soap/encoding/'>      <SOAP-ENV:Body>         <Hello xmlns="http://tempuri.org/">             <Name>UML</Name>         </Hello>      </SOAP-ENV:Body>      </SOAP-ENV:Envelope> 

We can easily decrypt the request XML message and tell something about the interface of the HelloWorld service - the interface has a Hello method that accepts a Name parameter. The payload that the HelloWorld service will put in the XML message it returns to the client in response to the above request message will be something that looks like the following. The result of the Hello method call on the HelloWorld object is a greeting that says "Hello UML!"

      <soap: Envelope xmlns: soap="http: //schemas. xmlsoap. org/soap/envelope/"      xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"      xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"      xmlns:xsd="http://www.w3.org/1999/XMLSchema">        <soap:Body>          <HelloResult xmlns="http://tempuri.org/">            <result>Hello UML!</result>          </HelloResult>        </soap:Body>      </soap:Envelope> 

In contrast, other ORPC protocols do not use XML as the data format for recording payload information. DOOM uses a format called Network Data Representation (NDR) for its payload and IIOP/GIOP uses a format called Common Data Representation (CDR). Later, in the next section, we'll see that .NET Remoting as an infrastructure for object-based distributed systems supports SOAP among other protocols as the ORPC protocol for remote object communication. Interested readers can find the SOAP protocol specification at the W3C web site. (http://www.w3.org)

As we know, UML is an object-oriented analysis and design method. Applying UML to our design of a distributed system is most appropriate if the components of the distributed system we are designing communicatesat an object-oriented level. Therefore, in this chapter when we say distributed systems, we obviously mean object-based distributed systems.

Major Issues that Challenge Designers of Robust and Reliable Distributed Systems

The next question we want to answer relates to the major issues that challenge designers of robust and reliable distributed systems. We've mentioned the four major differences between local and distributed systems at the beginning of this chapter. Those differences are latency, different memory access model, concurrency, and partial failure. In addition to those four differences, one also needs to be careful about aspects such as security and transaction in a distributed environment if the system in question requires those features.

Below is a list with brief explanations of the major issues that will often concern us when we design a distributed system. We'll also see what issues on the list are taken care of at the system level by the .NET infrastructure. This is very important to know because if the infrastructure you rely on does not help with a certain issue on the following list, you as a designer have to solve that at the application level.

• Performance, including latency, network traffic, load balancing, and object pooling. Latency is the time-period of inactivity a user experiences from sending a request until receiving the response to the request. Load balancing is a performance boosting technique that dispatches client requests to the least busy service. Object pooling is also a performance boosting technique that eliminates the cost of object construction and destruction by keeping a pool of reusable object instances in memory. Features like load balancing and object pooling are usually provided by system-level infrastructures. To reduce the latency of a remote method invocation, you have to spend money on expensive network equipment. Latency of a remote method invocation has to do with network speed, while latency of a local method invocation has to do with the local machine's processing power. Network traffic flowing among components of a distributed system depends greatly on the system's design. A well-designed system will boost the system's performance by reducing the network traffic flowing among components. During the proof-of-concept stage, it's a good idea to prototype the system, deploy the system's components in a representative network, and see if the quality of service meets requirements.

• Memory Access Model. Remote components run in different processes and each process has its own address space. A pointer to a memory address is not valid in another process's address space. In .NET, things are a bit more complicated because of the introduction of AppDomain and Context. In .NET, a process can be divided into one or more AppDomains. Each AppDomain can be divided into one or more Contexts. Method invocations on objects in other AppDomains are remote calls. Method invocations across Contexts are remote calls as well. Those remote method calls have to go through the same marshaling and unmarshaling steps as all cross-process remote method calls do. Readers interested in knowing more about AppDomains and Context can refer to the .NET Documentation for more details.

• Concurrency. Parts of a distributed system are running in different processes possibly on different machines concurrently. At implementation time or detailed technical design phase, concurrency issues that need to be addressed are threading, execution synchronization, race conditions, deadlocks, etc. However, when working with UML in Visio, we approach problems at a more abstract level where concurrency doesn't necessarily map to programming threads. Sometimes it is sufficient to set to check the IsActive checkbox of the class shape in a Class diagram to mark classes whose instances might be accessed concurrently.

• Partial failure. Distributed systems introduce new types of failures that are not present in local systems. For example, a network link that connects two remote objects might go down. A remote machine might be powered off or crash. For a client of an object on a remote machine, it's very difficult to tell whether the problem is the network link, the remote or something else when the remote object is dead.

• Distributed security and distributed transaction. These two features are usually provided by system-level infrastructure.

UML is not tailored for the design of a particular type of application systems. One can use it to design a local system as well as a distributed system. Its generalization allows us to apply it to various kinds of system designs. It's a great bonus that UML is flexible and extensible. It allows the addition of new elements into design artifacts when necessary. Later in this chapter, we'll show how to document our design decisions on the issues listed above in UML diagrams when we come to the Bank example.

	Team FLY