Remoting Patterns

Foundations of Enterprise, Internet and Realtime Distributed Object Middleware

Markus Völter, Michael Kircher, Uwe Zdun

• Publisher: Wiley
• Year: 2013
• ISBN:
  9781118725856
• Edition: 1
• Topic: Ciencia de la computación
• Subtopic: Programación orientada a objetos

Remoting offers developers many ways to customize the communications process, for efficiency, security, performance and power, and allows seamless integration of components running on several computers into a single application. This book exposes the full power of remoting to developers working in mixed platform environments in a way that will ensure they have a deep understanding of what remoting is capable of, and how they can make it work the way they want.

Chapter 1

Introduction To Distributed Systems

In this chapter we introduce distributed systems briefly. In particular, we describe the fundamental challenges addressed by the patterns in this book, and introduce important terminologies and concepts. This chapter, however, cannot provide a complete introduction to the broad field of distributed systems. More extensive introductions to these topics can be found in other books, such as Tanenbaum and van Steen’s Distributed Systems: Principles and Paradigms [TS02].

Distributed Systems: reasons and challenges

This section provides an introduction to distributed systems, the reasons why they exist, and the challenges in their design.

Application areas for distributed systems

The application areas for distributed systems are diverse and broad. Many major large and complex systems in use today are distributed systems. Below we provide examples to illustrate this.

The Internet can be seen as a large distributed system with a huge number of servers, providing services via a set of communication protocols such as HTTP, FTP, Telnet, and SMTP, to an even larger number of clients. The protocols used in the Internet are simple, rugged, and proven.

Telecommunication networks use digital switches that run software to provide communication facilities. That is, telecommunications networks depend heavily on distributed communication. As development cycles in this domain become shorter, the use of low-level programming and communication is replaced by object-oriented programming languages and corresponding distributed object middleware technologies. Those allow for higher programming efficiency, though often at the cost of memory overhead and somewhat reduced execution performance.

Business-to-business (B2B) collaboration systems, conducting electronic commerce among businesses, are an important application area for distributed systems. Today Electronic Data Interchange (EDI) [Ans04] is heavily used for electronic commerce, but Web-based technologies such as XML-based Web Services will probably be used in the future in this area (see for example [CFH+02]).

International financial transactions are executed via a distributed system provided by SWIFT (Society of Worldwide Interbank Financial Telecommunication). SWIFT is an industry-owned cooperative supplying secure, standardized messaging services and interface software to financial institutions. In 2002 more than 7,500 financial institutions in 200 countries were connected to SWIFT, processing about 7 million messages daily [Swi02]. The system was originally established to simplify the execution of international payments. Several financial and infrastructure services have been added to its portfolio recently.

Embedded systems, such as in-vehicle software, elevator control systems, household appliances, mobile devices, and many others, have crucial requirements for distributed communication. For example, modern cars contain a complex network of electronic control units (ECU). These ECUs run software that controls a particular aspect of the car. The features of a car typically are interrelated: for example, you should not be able to switch critical ECUs into diagnostic mode while the car is in use. The ECUs must therefore communicate with each other. As for other embedded systems, strict timing requirements have to be obeyed. More and more embedded systems are becoming network-aware, and therefore require efficient programmability of distributed communication. The upcoming AUTOSAR middleware standard [Aut04] addresses these concerns in the context of in-vehicle software.

Many scientific applications, such as DNA analysis, extraterrestrial signal interpretation, or cancer research, need massive amounts of computational power and thus cannot easily be run on a single machine. Clusters, Grids, or distributed peer-to-peer systems are commonly used to solve these types of problem collaboratively.

These are only a few examples of distributed systems – many other fields use distributed systems as well. We hope this incomplete list of examples nevertheless gives you an idea of the diversity and complexity of distributed systems.

Reasons for using distributed systems

Why do we use distributed systems? There are many reasons why distributed systems are used today. In general, we can distinguish problem-related reasons and property-related reasons, which often occur together.

Problem-related reasons for distributed systems occur when we face problems that are inherently distributed. For instance, if a computer user in Europe wants to read a Web page that is located on a server in the USA, the Web page has to be transported to the remote user – there is no way around that, it is simply the purpose of the system.

There are also property-related reasons for using distributed systems – that is, reasons that are motivated by a particular system property that should be improved by distributing the system. Examples of such system properties are:

• Performance and Scalability. If a system has to cope with sufficiently heavy loads that a single machine cannot cost-effectively solve the problem, the problem is divided and assigned to several machines to share the load. To allow these to efficiently handle the computing load, the machines have to be coordinated in some way. This process is called ‘load balancing’, and results in a distributed system. For example, most Web sites with very high hit rates are served by more than one machine. Another example is the area of super-computing: Grids of smaller machines are assembled to provide a performance unattainable by any single machine. We discuss availability and scalability patterns in Chapter 13, Related Concepts, Technologies, and Patterns.
• Fault Tolerance. Another reason for using distributed systems is fault tolerance. All hardware devices have some Mean Time Between Failure (MTBF) that is smaller than infinity. Software can also fail: a program might have a bug or some non-deterministic behavior that results in a failure, or in strange behavior that may happen only occasionally. As a consequence, every machine, or a part of it, will fail at some time. If the overall system should continue working in such an event, it must be designed so that the system does not fail completely when a partial failure occurs. One approach to this is to distribute the software system over many machines, and ensure that its clients do not notice when a specific machine fails. The coordination between different software components running on individual machines results in a distributed system Note that there are ways to provide fault tolerance other than hardware redundancy. For more details, refer to Chapter 13, Related Concepts, Technologies, and Patterns.
• Service and Client Location Independence. In many systems the location of clients and services is not known in advance. In contrast to classical mainframe or client/server systems, services can be transparently executed on remote hosts equipped with more storage or computing power. For example, in a peer-to-peer system, new distributed or local peers providing additional services might join and leave the system at any time.
• Maintainability and Deployment. Deployment of software to a large number of machines is a maintenance nightmare that increases the total cost of ownership (TCO) of a system. An alternative solution is to provide thin clients that only accept user input and present output, and locate the business logic remotely on central servers. Changes to the business logic thus do not affect clients. Enterprise systems use this thin client approach, keeping the system functionality and the data on one or more central machines.
• Security. Another reason for using a distributed system is security. Security information, such as user credentials, might be consistently kept at a central site and accessed from many remote locations. Alternatively, for security reasons, some information or functionality might not be kept at a single site only, but instead distributed over a number of nodes, perhaps administered by different people and organizations. Some machines that store critical data might be located in specially secured computing centers, for example a restricted area that requires a special key for access and is monitored with security cameras. Such secured machines often need to be accessed by other nodes of the system. To coordinate the nodes, remote communication is again necessary.
• Business Integration. In the past business was mainly achieved by people interacting with each other, either directly, by surface mail, or by phone. When e-mail started to appear, some business was carried out via e-mail, but orders were still entered by people using personal computers. In recent years the term Enterprise Application Integration (EAI) has been introduced. EAI is about integrating the different systems in enterprises into one coherent, collaborating ‘system of systems’. This integration involves communication between the various systems using different remoting styles, as well as data mapping and conversions, without human intervention.

Challenges in distributed system design

Compared to traditional, non-distributed systems, additional challenges arise when engineering distributed systems, such as:

• Network Latency. A remote invocation in a distributed system takes considerably more time than an invocation in a non-distributed system. If a certain performance level is required from the distributed system, or when strict deadlines have to be met, this additional time delay must be taken into account.
• Predictability. The time it takes to invoke an operation differs from invocation to invocation, because it depends on the network load and other parameters, such as the location of the remote process, how fast the invocation travels across the network, and how fast it is processed by the remote process. The network can even fail. Lacking end-to-end predictability of remote invocations is especially problematic for systems with hard real-time requirements that mandate specified deadlines that must not be missed, which would constitute a system failure. Guaranteeing real-time requirements is a major challenge in many distributed real-time embedded systems, such as aircraft flight control.
  Note that predictability cannot be assumed in non-distributed systems either. An operation’s invocation time is influenced by many factors, such as processor load or the status of a garbage collector. However for many systems these times can be assumed to be very small and constant, and thus can be neglected in practice. Such assumptions cannot be made in a distributed system. Though, predictable transmission times in distributed systems can be provided by using time-triggered communication [Kop97], which is increasingly used in safety-critical real-time applications.
• Concurrency. Other problems arise from the fact that there is real concurrency in a distributed system. In contrast to multi-threaded or multi-process systems running on a single-processor machine, in distributed systems several processing steps can happen at the same time. Coordinating such systems is far from simple. Even basic coordination, such as providing a common time reference, requires sophisticated protocols. Concurrency can cause a number of problems, such as non-determinism, deadlocks, and race conditions.
• Scalability. Since different parts of a system, such as clients and servers, are distributed and therefore more or less independent systems themselves, it is not always possible to know in advance how many of these different systems are actually available, and how high the communication load is going to be at a certain time. For example, it is hard to determine the number of clients for a Web server: at certain peak times, many more clients than expected might want to access a Web site. The software, the hardware, and the network must be able to scale up to handle this additional load at any time – or at least fail gracefully.
• Partial Failure. In systems that run on a single machine, ideally in a single process, a failure such as a hardware problem or a fatal software bug usually has a simple consequence: the program stops running completely. It is not possible for only parts of the program to stop, which is what partial failure is all about. In distributed systems, this is different: it is quite possible for only a part of the overall system to fail.
  However, in many systems it can become very difficult to determine which part of the system has actually failed, and how to recover. For example, if a client communicates with a server and does not receive a reply, this can have many reasons: the server process may have crashed, or the server hardware may have gone down. Or maybe the process has not crashed, but is only overloaded, and may merely take longer to respond to the request. Finally, there might be no problem with the server at all, but the network itself might be broken, overloaded, or unreliable.
  Depending on how the system fails, different ways of recovery are necessary. Therefore the real problem is to determine the real cause of the failure. But it is sometimes impossible for clients to detect the causes of failures. There are many algorithms for detecting such problems [TS02], but none of them is simple, and all imply an additional performance overhead.

The ‘bottom line’ is that you should only distribute your system if distribution is really needed. Distribution adds complexity concurrency inefficiency and other potential problems to your application that would not occur in a non-distributed context. We do not advocate avoiding the use of distributed systems, it’s just important to carefully evaluate when and what to distribute. Check Fowler’s First law of distributed object design in [Fow03], Don’t distribute your objects!

Communication middleware

Distributed systems can be built directly on top of low-level network protocols. For example, communication can be based on TCP/IP sockets, which allow distributed processes to pass each other messages using send and receive operations directly [Ste98]. But this raises a number of problems, because developers have to deal with low-level networking details. In particular, such systems:

• Are usually not easy ...