We continue in the chapter Distribution Strategies 😉
A. The Problem
The author says :
However, distribution of objects, or indeed of anything else, has a lot more pitfalls than many people realize [Waldo et al.], especially when they’re under the influence of vendors’ cozy brochures. This chapter is about some of these hard lessons
The point is : How can we make distribution of objects efficient in our system ?
B. The Bad
The most popular way is to take each Object and put them in a seperate node for performance , like in the image below :
But the author says :
Transparency is valuable, but while many things can be made transparent in distributed objects, performance isn’t usually one of them. Although our prototypical architect was distributing objects the way he was for performance reasons, in fact his design will usually cripple performance, make the system much harder to build and deploy, or, usually, do both.
N.B: Why putting everything in a single node is bad ? :
Simply because local call and remote call on the point of performance are not same :
The primary reason that the distribution by class model doesn’t work has to do with a fundamental fact of computers. A procedure call within a process is very, very fast. A procedure call between two separate processes is orders of magnitude slower. Make that a process running on another machine and you can add another order of magnitude or two, depending on the network topography involved.
C. The Good
The way is to be proficient with our multiple processors environment and the author says :
Hence, we get to my **First Law of Distributed Object Design: Don’t distribute your objects! How, then, do you effectively use multiple processors? In most cases the way to go is clustering. Put all the classes into a single process and then run multiple copies of that process on the various nodes. That way each process uses local calls to get the job done and thus does things faster.**
D. Be Pragmatic with Clustering
Because there will always be case where distribution is inevitable for objects and the author to say The rub is that there are limits to that approach—that is, places where you need to separate the processes.
Some examples :
1. Separation is between the traditional clients and servers of
business software
2. Separation between server-based application software (the application server) and the database
Colleen Roe’s memorable phrase, is to be “parsimonious
with object distribution.”
E. Minimizing the coupling in distribution
As you design your system you need to limit your distribution boundaries as much as possible, but where you have them you need to take them into account. We can do it with some solutions :
E.1. Remote Facade
The coarse-grained objects don’t really do anything but
delegate so they act as a facade for the fine-grained objects. This facade is there only for distribution purposes—hence the name Remote Facade (388). Using a Remote Facade (388) helps minimize the difficulties that the coarsegrained interface introduces. This way only the objects that really need a remote service get the coarse-grained method, and it’s obvious to the developers. Remote Facade
E.2. Data Transfer Object
You usually can’t send the domain object itself, because it’s
tied in a Web of fine-grained local inter-object references. So you take all the data that the client needs and bundle it in a particular object for the transfer—hence the term Data Transfer Object (401). (Many people in the enterprise Java community use the term value object for this, but this causes a clash with other meanings of the term Value Object (486)). The Data Transfer Object (401) appears on both sides of the wire, so it’s important that it not reference anything that isn’t shared over the wire. This boils down to the fact that a Data Transfer Object (401) usually only references other Data Transfer Objects (401) and fundamental objects such as strings. DTO
Finally what we can say that these are the patterns to be efficient with distribution of objects !
End of that chapter , See you ❤️
Top comments (3)
love how straight-up this is about the real costs behind distribution, being too clever with splitting stuff always burned me before
Glad you love !
I totally agree and for me also the way of distributing objects has changed !
The costs are real if it's done the wrong way
Yo crypto fam! collect your free token airdrop in blockchain rewards ending soon! — Join now! Sign with wallet to verify and claim. 👉 duckybsc.xyz