User Tools

Site Tools


principles:law_of_leaky_abstractions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
principles:law_of_leaky_abstractions [2013-10-08 12:21]
christian example 3
principles:law_of_leaky_abstractions [2018-04-11 11:57] (current)
84.46.93.199 [Example 1: Distributed Objects]
Line 88: Line 88:
 ==== Example 1: Distributed Objects ==== ==== Example 1: Distributed Objects ====
  
-There is plenty of middleware which centers around the notion of distributed objects: RMI, CORBA, DCOM, ... These technologies abstract away from the fact that the objects are not local but distributed over the network. They create the illusion that calling all objects are local. But all these technologies are leaky abstractions. There is no way to abstract ​fro the fact that calling a remote object may fail. The network connection may break down, the remote machine may not be available, etc. Furthermore there are completely different performance characteristics of remote calls. There is some unavoidable latency and no abstraction what so ever can change this.+There is plenty of middleware which centers around the notion of distributed objects: RMI, CORBA, DCOM, ... These technologies abstract away from the fact that the objects are not local but distributed over the network. They create the illusion that calling all objects are local. But all these technologies are leaky abstractions. There is no way to abstract ​from the fact that calling a remote object may fail. The network connection may break down, the remote machine may not be available, etc. Furthermore there are completely different performance characteristics of remote calls. There is some unavoidable latency and no abstraction what so ever can change this.
  
 This does not mean that these technologies are generally bad. There is a value in these abstractions but the leaks have to be kept in mind. Ignoring the fact that remote calls may fail will result in fragile systems. If the distributed system to develop should be robust, there has to be code handling failing remote calls. And for performance reasons, remote interfaces have to be crafted in a way that remote calls are minimized. So for example [[patterns:​Data Transfer Objects]] are employed in order to transfer larger chunks of data instead of making a remote call for every access to a getter method. This does not mean that these technologies are generally bad. There is a value in these abstractions but the leaks have to be kept in mind. Ignoring the fact that remote calls may fail will result in fragile systems. If the distributed system to develop should be robust, there has to be code handling failing remote calls. And for performance reasons, remote interfaces have to be crafted in a way that remote calls are minimized. So for example [[patterns:​Data Transfer Objects]] are employed in order to transfer larger chunks of data instead of making a remote call for every access to a getter method.
principles/law_of_leaky_abstractions.txt · Last modified: 2018-04-11 11:57 by 84.46.93.199