6 ms·

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://

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 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_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu... (learn from history) Looks like any abstraction trying to hide distribution is inherently too leaky.

signa11 3y ago
> - "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"
pjmlp 3y ago
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.
- mkleczek 3y ago
  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)
  - pjmlp 3y ago
    I rather deal with Websphere 5 (on purpose not the later much improved 6 and 7) than Kubernetes.
c0l0 3y ago
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.
projectileboy 3y ago
Your last sentence is almost the only reply the article requires.
deleted 3y ago
[deleted]
dti 3y ago
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).
- mkleczek 3y ago
  > 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 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.
dti 3y ago
> 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/ 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)

signa11 3y ago

> - "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"

pjmlp 3y ago

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.

mkleczek 3y ago
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)
- pjmlp 3y ago
  I rather deal with Websphere 5 (on purpose not the later much improved 6 and 7) than Kubernetes.

c0l0 3y ago

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.

projectileboy 3y ago

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

deleted 3y ago

[deleted]

dti 3y ago

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).

mkleczek 3y ago
> 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 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.

dti 3y ago

> 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/ 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)