Akka Peer-to-Peer (Remoting) vs. Client-Server (Websockets)

Question

My app requires bidirectional continuous communication with a high volume of clients (which are java agents installed on user machines) in addition it includes a spring mvc webapp which provides a standard jsp UI to manage these agents. I've only looked at the basics of java akka (no time to learn scala for this project). But it seems like a good choice to handle the high volume of client agents. I've looked at akka spring integration module and akka-spring-java examples and using akka on the spring side seems pretty straight forward.

I thought using akka remoting with the client agent side might also be a good idea, the agent which will likely be embedded in another app basically runs a thread needs watch various processes in the user's jvm and communicates with services on server. Using location transparency would simplify the architecture conceptually and possibly be more efficient.

This article suggests this may not be the correct approach

Peer-to-Peer vs. Client-Server

The alternative to using remoting would to use camel websockets which seem to be associated with the akka spring integration module.

What would be the best direction to take in the context of my app given it's tech stack?

Answer 1

You probably don't want to use remoting for a server-clients situation. Remoting gives both sides the same rights and privileges. It was designed for clusters and peer-to-peer.

Take a look at Akka I/O . It gives you asynchronous actors on both sides, but fits the server-client use case better. You wouldn't have to worry about threads and processes.

Also remember, that even when using Akka with Java you need the Scala library as a dependency.