Dale Asberry talks about some reasons why he feels distributed systems are so hard to work with.Introduction
In one sentence, here's why: humans are notoriously bad at keeping "self" distinct from "other". Egomania, projection (transference), and enmeshment are well-known symptoms of this problem. OK, so I hear you saying, "yeah, but what does this have to do with programming?" It certainly seems absurd to suggest that if we are bad at something we know the most about (our "selves"), how could we possibly say that we have a good approach for the programming analogues - objects, modules, etc.Conclusion
Hopefully it isn't too difficult to see that people are bad at recognizing differences between self and others. It should also not be too hard to see that these difficulties would spill over into programming.
We should also recognize that other factors aggravate the problem and further discourage decoupling. One, it's a hard problem to see, let alone, to solve. Two, if developers don't keep on top of, and continually remove, dependencies, the harder it gets to remove them. Third, these problems are exacerbated by the fact that the original team (and especially consultants) leave the project taking hard-learned domain expertise with them sometimes to avoid the negative consequences of blame.
Distributed applications are particularly hard-hit by these things. Distributed applications are inherently more difficult than "standard" applications because they simply cannot be built without making them very decoupled. (See Carlos' coupling table above).
On the positive side, many very bright people have seen solutions to overcoming these dependency problems. The solutions are subtle and complex which means that they can't be applied in cookie-cutter fashion. If developers assimilate these solutions into their personal knowledge base then all types of applications can be taken to the next level of complexity.
Read Why is Distributed so Hard?
I disagree with the concept of "self" and "other" being
the source of strife with regard to Distributed Computing.
I also don't go for the anthropomorphic (egomania, transference)
It is more (in my mind) a concept of "here" and "there".
When designing and implementing distributed applications,
architects and developers need to understand the concepts
and the fundemental differences between a logical application
and a physical deployment.
Whilst designing a distributed application from the logical
sense, everthing happens in one place, i.e. a single address
space. However, when it come to deployment, the single logical
application should be able to be "split" with its various parts
physically residing in multiple address spaces.
It is still a single logical application, but physical distributed.
J2EE helps in a large part to make this location transparency
possible and distributed computing (in the Java sense) practical.
Design as if everything happens "here". Implement with a mind
to it actually happening "here" and (possibly) "there".
With that said, it has been my experience that some (not all)
organisations I have come across actually do not do distributed
Case 1. An application is completely self-contained in a single EAR
file deployed on a single server. Single address space. May be on a remote
server, but it does not qualify as distributed computing.
Case 2. An application is completely self-contained in a single EAR
file and deployed to every node in a cluster. Still single address
space (on a single node) and thus does qualify as distributed. Just
like Case 2, just n times, but more available.
Case 3. A (single logical) application composed of two or more
EAR files is depolyed on different nodes. This is distributed computing.
It is here that issues such as serialisation become very important. That
"bread crumbs" you persisted locally in component X which is needed
by component Y may not be found because it is not running "locally"...
It not a matter of "self" and "other", but "here" not being where
you put it, or expected it, because "here" is now "there".
Just my thoughts.
In my own post I noticed that I dropped
an important word. The word "not".
The phrase in Case 2 "...and thus does qualify..."
should have read "...and thus does not qualify...".
Too quick on the "send" button.
Jim Waldo, et al answered this question in 1994:http://research.sun.com/techrep/1994/smli_tr-94-29.pdf
Read and learn.
I'd strongly recommend people take a look at Erlang's model for developing concurrent and distributed applications. No thread, no shared state, only message passing, concurrent activities are modeled with lightweight processes. Each process is easier to write, reason and maintain.http://c2.com/cgi/wiki?ErlangLanguage
I don't really think the philosophical concepts of 'self' and 'other' apply to distributed computing. I can see why you'd want to use them but it doesn't make sense.
One of the typical arguments regarding personal identity theory, existentialism, etc., etc., is the fact the we can't really divulge the purposes within another's mind. Levinas is fairly much a great thinker in this regard.
Using an API, which charts the behaviour of an interface, in a business orientated machine is far different. It states purpose.