Hacker News Reader

Comment by mkleczek | Hacker News Reader

Mobile code and "agent systems" were very fashionable 20 years ago. Java introduced built-in RMI with automatic stub downloading. In 1998 Sun published https://en.wikipedia.org/wiki/Jini that was an extension of this idea. Several higher level frameworks emerged (JavaSpaces among the most prolific).

Reading the paper two thoughts come to mind:

- "What's old is new again"

- "those who do not learn from history are doomed to repeat it"

There were several attempts in history to implement transparent RPC (new again). All failed due to https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu... (learn from history)

Looks like any abstraction trying to hide distribution is inherently too leaky.

View on HN

I find it very amusing that most of the people who abhor dynamic linking of libraries and executables as an over-complex, error-prone mistake of computer history these days seem to have not the faintest trace of restraint when they're about to turn EVERYTHING into a RPC/RMI over complex, multi-layer (and I don't mean OSI), often completely proprietary and opaque network abstractions like there's no tomorrow.

> - "those who do not learn from history are doomed to repeat it"

or as mark-twain would (probably) say

"History Does Not Repeat Itself, But It Rhymes"

On the same vein, I now take a kick out of people criticizing Java and .NET application servers, while at the same time praising delivering WASM containers with Kubernetes YAML spaghetti into production.

Need to get that VC money into the hot WASM space.

Let's be honest - deployment story with J2EE application servers was total mess and I still have nightmares.

But you're right - today's world of YAML programming is no better.

Nix and Guix are steps in the right direction (but both have their fair share of issues)

I rather deal with Websphere 5 (on purpose not the later much improved 6 and 7) than Kubernetes.

> trying to hide distribution

The paper unfortunately hides that in reality you have to pass a context object in your RPC calls, hence there is no ambiguity whether you are calling a potentially remote object.

It's in the example on the project home page: https://serviceweaver.dev/

  // The "RPC" handler
  func (adder) Add(_ context.Context, x, y int) (int, error) {
      return x + y, nil
  }

  // The call-site
  var adder Adder = ... // See documentation
  sum, err := adder.Add(ctx, 1, 2)

Regarding the comparison with RMI, the authors did mention it:

> Java RMI use a programming model similar to ours but suffered from a number of technical and organizational issues [58] and don’t fully address C1-C5 either

Apart from that, it looks like Java RMI allowed remote objects returning other remote objects, rather than only immutable values. With that you could abuse it by making a call to one java.rmi.Remote object, getting another java.rmi.Remote object in response, then passing it around, and then finding a totally different subsystem suddenly make RPCs (however, such abuse probably would be easy to spot in a code review, as it requires a modification to the remote object interface).

---

The authors also acknowledge that it doesn’t solve the distributed computing challenges:

> our proposal does not solve fundamental challenges of distributed systems [53, 68, 76]. Application developers still need to be aware that components may fail or experience high latency

I think at least in terms of latencies their platform can occasionally inject latencies into some percentage of the tasks, then verifying if any alerts fire, if there is a fear the components become dependent on a certain deployment shape (within a cluster).

> Apart from that, it looks like Java RMI allowed remote objects returning other remote objects, rather than only immutable values.

Actually this is a very powerful concept as it allows one to achieve high level of reuse. Jini (https://jan.newmarch.name/java/jini/tutorial/Jini.html) made mobile objects the core idea of its architecture.

How powerful the approach is one can see when looking for example at Jini concept of a Lease and LeaseRevenewalService:

a server program can register an object (client side implementation of a service) in ServiceRegistrar (to make it discoverable and downloadable). Registration is lease based so the server has to renew it periodically. But it can be delegated to a LeaseRenewalService that can do it on its behalf so that the server can go to sleep (ie. not use any server machine resources).

All of the above happens without any party a-priori knowledge about any code that needs to be present at use site - code is downloaded automatically on-demand - the only thing common to client and service is a Java interface.

Your last sentence is almost the only reply the article requires.

Reply on news.ycombinator.com