Arnon Rotem-Gal-Oz is a software architect who writes on distributed systems, REST, and the Fallacies of Distributed Computing.
HN links his fallacies paper as a reference on distributed computing, with commenters adding how networks fail in varying degrees.
I'm sorry, I think I don't understand the point you are trying to make. Are you really complaining that Java doesn't do messaging? Surely not, because that would be like saying that Lisp is okay, but it would be better with a heap more parenthesis.
When you get down to it, pretty much any language with even a rudimentary ability to manipulate strings and connect to a socket can do messaging. But right from day one Java has had the capability of communicating with remote machines baked in.
Oh wait, I just checked, I'm wrong. The Remote and Serializable interfaces date since Java 1.1, NOT since day 1. My bad. Of course 1.1 was released Feb 19, 1997 so RMI is almost exactly 14 years old at this point.
So my conclusion is that if you've been living under a rock for exactly 14 years, you have an excuse when you say that Java can't do messaging.
----
Someone always comes along and says "what about $blindingly_obvious_thing and gets massive amounts of karma for doing so, so let me just say that yes, I am aware of... bugger it, I'll do it myself and reap the karma. Muahahahaha!
...
...dang, there's no reply to my own message option. (For obvious reasons) Oh well, we'll have to settle for option #2 which is that someone comes along and posts an objection which has nothing to do with any of the posts before it, and gets masses of karma for it.
----
Addendum:
If you're implementing a messaging system in your handy dandy language with sockets and strings, and you…
MVC doesn't have anywhere in it for a client-server relationship. This is because MVC is actually a desktop app model, designed for things like CAD programs. Client-server connections are too important to gloss over, because you can't gloss over the Fallacies of Distributed Computing: http://www.rgoarchitects.com/Files/fallacies.pdf And your architecture must actually handle those issues, which means it's not going to be MVC.
MVC makes sense for a pure Javascript app that uses the server only as a DB server (if that). It can at least be jammed into a classic old-style pure server application. But if your app actually spans the two, you haven't got MVC anymore... or you've got an app scoring 8 out of 8 on the network fallacies, probably by virtue of trying to wrap all network access behind an "RPC" interface, which tries to represent network interaction as local function calls, which one of the easiest ways to score an 8 out of 8 on the fallacies list.
Because of the way MVC tends to afford glossing over the network fallacies, I tend to consider it an inferior design for almost any web application. It's a lot of code busywork to try to sort of kind of (probably not actually, assuming the MVC one is starting with is even MVC in the first place and not just "vaguely MVCish in name only") conform to a particular architecture, requiring at least three moving pieces to do anything (one in each letter of the acronym, in practice, often a view on the server and on the client)…
Personally I started investigating and using a production system[1] which introduced a bunch of basic concepts and I read a few papers such as the Dynamo paper[2]. Then I went deeper into riak_core[3] and Erlang/OTP. At this point I have a context in which to read and understand more papers (such as those OP linked) and I've studied concepts such as Eventual Consistency, Vector Clocks, Map Reduce, Gossip Protocols, etc.
I'm not an expert by any means but I found this route to be a fun one and the riak/erlang related irc channels are awesome (and helpful) to hang around in.
[1] Riak: http://docs.basho.com/riak/latest/downloads/
[2] http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf
[3] https://github.com/basho/riak_core
[4] http://www.rgoarchitects.com/Files/fallacies.pdf
For example, the pairing of PUT with 'update' , with only POST allowed to create new resource, versus allowing clients to PUT a new resource (effectively creating them) when given the proper URL.
See, for example, http://www.rgoarchitects.com/nblog/2009/06/23/CRUDIsBadForREST.aspx
and in particular the idea that REST is about documents, not databases. "The data model is _not_ the resource model," as one comment there puts it.
Also, CRUD makes no allowance for HEAD and OPTIONS, as if they don't even exist.
I see too, in digging around for links, that this has been discussed on HN before (big surprise, no?):
http://news.ycombinator.com/item?id=629843
What @saryant said.
In addition, the network isn't just up or down. It's varying shades (dare I say, 50 shades?) of down or broken. A single machine might not be accessible due to a switch issue. An entire rack or aisle might be compromised by a bad router or faulty routing table. A network cable might be flaky. The truth is you just don't know, and that's all inside a single LAN.
Your service discovery system could be able to see service {A,B,C}, but service A can't talk to B or C due to network issues. It happens.
http://www.rgoarchitects.com/Files/fallacies.pdf
Is this "the paper"?
http://www.rgoarchitects.com/Files/fallacies.pdf
"This whitepaper is based on a series of blog posts that first appeared in Dr. Dobb's Portal http://www.ddj.com/dept/architect*