Design Patterns for Distributed Systems

Introduction

In the last post we talked about Design Patterns as a strategy used for writing reusable code. The patterns listed are famous in general software development. However, you can find patterns for a specific kind of software like embeeded, distributed, real time softwares and so on. Today, we will be talking a little about patterns used to describe distributed systems, which are known as Remoting Patterns.

Distributed system is defined as set of computers connected to a network, working together to achive a single objective and equipped with a distributed software (middleware). They are commum used in nowadays’ solutions because of some basic advantages: performance, scalability, fault tolerance, location independence, maintainability. In the other hand, we get a lot of challenges in a distributed systems design, such as network latency, concurrency, security. To face with them, and with the same purpose of Design Patterns, Remoting Patterns help developers with cases of success in middleware design, demostrating approaches that worked in later projects and that are strictly recommeded. So, let’s start.

Remoting Patterns

The picture above shows the interaction among the basic Remoting Patterns. So, to develop a basic object-oriented middleware you should use the patterns:

Requestor: hides the details of the client side distributed object communication from clients. So, use a REQUESTOR for accessing the remote object. To invoke an operation on a remote object, the client passes the data necessary to invoke the operation to the REQUESTOR, who then send this invocation across the network. It handles the details of crossing the process/machine boundary.

Client Proxy: supports the same interface as the remote object. So, clients only interact with the local CLIENT PROXY, which represents the remote object from the client application. It uses the REQUESTOR to construct and send the remote invocation.

Invoker: accepts client invocations from REQUESTORS. REQUESTORS send requests acrros the network, the INVOKER reads the requests, demarshals it and dispatches the invocation to the remote object implementation. Result are returned as replies in the reverse direction.

Client Request Handler: responsible for opening and closing network connections to server applications, sending requests, receiving replies, and dispatching them back to the appropriate REQUESTOR.

Server Request Handler: deals with all the communications issues of a server application. So, it reveives messages from the network, combine the message fragments, and dispatch the messagens to the correct INVOKER for further processing.

Marshaller: use compatible MARSHALLERS on the client and server side that serialize invocation information.

Interface Description: serves as the contract between CLIENT PROXY and INVOKER. So, syncronize client and server with the existing remote invocations.

Conclusion

Distributed systems are becoming a very commun strategy in software development because of its skills like scalability, high performance, location independence. As a normal software application, designing distributed sytems is in the most of times a great challenge for programmers worried about reusability and maintainability. Because of that, Remoting Patterns were created to facilitate the development of this kind of systems with good practices and known design cases of success.

More information can be found in the book Remoting Patterns: Foundations of Enterprise, Internet and Realtime Distributed Object Middleware.


Fernando

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s