Programacion

Fallacies of Distributed Computing Explained
(The more things change the more they stay the same) Arnon Rotem-Gal-Oz [This whitepaper is based on a series of blog posts that first appeared in Dr. Dobb's Portal www.ddj.com/dept/architect] The software industry has been writing distributed systems for several decades. Two examples include The US Department of Defense ARPANET (which eventuallyevolved into the Internet) which was established back in 1969 and the SWIFT protocol (used for money transfers) was also established in the same time frame [Britton2001]. Nevertheless, In 1994, Peter Deutsch, a sun fellow at the time, drafted 7 assumptions architects and designers of distributed systems are likely to make, which prove wrong in the long run - resulting in all sorts of troubles andpains for the solution and architects who made the assumptions. In 1997 James Gosling added another such fallacy [JDJ2004]. The assumptions are now collectively known as the "The 8 fallacies of distributed computing" [Gosling]:
1. 2. 3. 4. 5. 6. 7. 8. The network is reliable. Latency is zero. Bandwidth is infinite. The network is secure. Topology doesn't change. There is one administrator. Transportcost is zero. The network is homogeneous.

This whitepaper will looks at each of these fallacies, explains them and checks their relevancy for distributed systems today.

The network is reliable
The first fallacy is "The network is reliable." Why is this a fallacy? Well, when was the last time you saw a switch fail? After all, even basic switches these days have MTBFs (Mean Time BetweenFailure) in the 50,000 operating hours and more. For one, if your application is a mission critical 365x7 kind of application, you can just hit that failure--and Murphy will make sure it

happens in the most inappropriate moment. Nevertheless, most applications are not like that. So what's the problem? Well, there are plenty of problems: Power failures, someone trips on the network cord, all of asudden clients connect wirelessly, and so on. If hardware isn't enough--the software can fail as well, and it does. The situation is more complicated if you collaborate with an external partner, such as an e-commerce application working with an external credit-card processing service. Their side of the connection is not under your direct control. Lastly there are security threats like DDOS attacksand the like. What does that mean for your design? On the infrastructure side, you need to think about hardware and software redundancy and weigh the risks of failure versus the required investment. On the software side, you need to think about messages/calls getting lost whenever you send a message/make a call over the wire. For one you can use a communication medium that supplies full reliablemessaging; WebsphereMQ or MSMQ, for example. If you can't use one, prepare to retry, acknowledge important messages, identify/ignore duplicates (or use idempotent messages), reorder messages (or not depend on message order), verify message integrity, and so on. One note regarding WS-ReliableMessaging: The specification supports several levels of message guarantee--most once, at least once, exactlyonce and orders. You should remember though that it only takes care of delivering the message as long as the network nodes are up and ru n n i g , i d oesn ’ h an d l p ersi n t t e sten cy an d you stil n eed to take care of l that (or use a vendor solution that does that for you) for a complete solution. To sum up, the network is Unreliable and we as software architect/designers need to addressthat.

Latency is zero
The second fallacy of Distributed Computing is the assumption that "Latency is Zero". Latency is how much time it takes for data to move from one place to another (versus bandwidth which is how much data we can transfer during that time). Latency can be relatively good on a LAN--but latency deteriorates quickly when you move to WAN scenarios or internet scenarios....