And a stranger from my network said 'Hi' to my JVM

This is exam time and I am still continuing with Scala and Akka adventure.(No regrets). The actor model did impress me pretty well but after reading about remoting and location transparency through akka, I realized that it actually is a big deal.

Remote Actors:
Akka Remoting is a communication module for connecting actor systems in a peer-to-peer fashion, and it is the foundation for Akka Clustering. The design of remoting is driven by two (related) design decisions:

1. Communication between involved systems is symmetric: if a system A can connect to a system B then system B must also be able to connect to system A independently.

2. The role of the communicating systems are symmetric in regards to connection patterns: there is no system that only accepts connections, and there is no system that only initiates connections.

The consequence of these decisions is that it is not possible to safely create pure client-server setups with predefined roles (violates assumption 2). For client-server setups it is better to use HTTP or Akka I/O.

So, I tinkered a little by following the tutorial here and tried a few examples, and was more than happy to see it working. But in those examples(there are plenty of them on interwebz), a file named 'application.conf' was being used to enable the remoting functionality and declaring some important properties like hostname and port. 

This follows from their notion of transparency.

We took the idea of transparency to the limit in that there is nearly no API for the remoting layer of Akka: it is purely driven by configuration. Just write your application and then specify remote deployment of actor sub-trees in the configuration file. This way, your application can be scaled out without having to touch the code.

This published paper brings forward the ideology behind the akka remoting and also mentions the problems with current approach of distributed computing. Quoting the abstract:

"We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure."

" Further, work in distributed object-oriented systems that is based on a model that ignores or denies these differences is doomed to failure, and could easily lead to an industry-wide rejection of the notion of distributed object-based systems."

Here's my remoting code which establishes a P2P connection between two remote actors. And yes, it also builds the configuration at runtime, removing the dependency from a static hardcoded file(application.conf).