3 ms·

Got you. I just want to point out the absurdity of it. Java microservices commonly use Javascript Object Notation for their data transfer. How is that the right

by jseban 5y ago

Got you. I just want to point out the absurdity of it. Java microservices commonly use Javascript Object Notation for their data transfer. How is that the right tool for the job. With all the translations that are needed, why don't they use RMI/RPC? And why even spend all that development time on something that you can solve in an afternoon with a JDBC connection anyway.

rswail 5y ago
Because the paradigm of RPC is not about data transfer (which is the serialization protocol). RPC is one architectural style. It's pretty undefined other than "call/response". Marshalling of arguments is just a serialization issue. RMI/RPC doesn't work well across firewalls or org boundaries. It doesn't support separating internal and external host identification, so when you try to RMI to a host in another DNS domain that has a local name, there's all sorts of nonsense to get the Java runtime to understand it can have multiple DNS names and be associated with multiple network interfaces. JSON/protobuf/cap'nproto/ONC-XDR/XML are about serializing data (whether it's a resource or a marshalled argument/result for RPC).
- jseban 5y ago
  So basically: it doesn't work well if you want to reach every IP on the whole internet. Yeah I suppose that's correct, but we are talking about internal service-to-service communication so why would you have those requirements in the first place? It's only call/response because that's all you ever need if you can call any arbitrary function by it's name. That's infinitely more powerful than any other protocol that restricts you to a limited grammar.
- DeathArrow 5y ago
  >RMI/RPC doesn't work well across firewalls or org boundaries. According to Wikipedia, even CORBA managed to solve the issues with firewalls: https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...
DeathArrow 5y ago
But do we have a modern, efficient, simple RPC framework not using HTTP as transport?

by jseban 5y ago

rswail 5y ago

Because the paradigm of RPC is not about data transfer (which is the serialization protocol). RPC is one architectural style. It's pretty undefined other than "call/response". Marshalling of arguments is just a serialization issue. RMI/RPC doesn't work well across firewalls or org boundaries. It doesn't support separating internal and external host identification, so when you try to RMI to a host in another DNS domain that has a local name, there's all sorts of nonsense to get the Java runtime to understand it can have multiple DNS names and be associated with multiple network interfaces. JSON/protobuf/cap'nproto/ONC-XDR/XML are about serializing data (whether it's a resource or a marshalled argument/result for RPC).

jseban 5y ago
So basically: it doesn't work well if you want to reach every IP on the whole internet. Yeah I suppose that's correct, but we are talking about internal service-to-service communication so why would you have those requirements in the first place? It's only call/response because that's all you ever need if you can call any arbitrary function by it's name. That's infinitely more powerful than any other protocol that restricts you to a limited grammar.
DeathArrow 5y ago
>RMI/RPC doesn't work well across firewalls or org boundaries. According to Wikipedia, even CORBA managed to solve the issues with firewalls: https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

DeathArrow 5y ago

But do we have a modern, efficient, simple RPC framework not using HTTP as transport?