Why Akka

This article is about the reason, why we use Akka for the communication with the Freeplane Remote Plugin.
Akka is a library, which can be used for asynchronous message processing and is also able to handle messages that come from a remote place.

Why not Jersey

Originally we started implementing the plugin with an RESTful webservice based on Java Jersey. It fitted our original specifications, where the remote plugin would have handled request from a client (Docear Desktop or Online Viewer) directly. It was also already used by the Docear-team and would have been a known technology.
Over the time the specifications changed and for better maintenance and scalability we put all request handling into the Frontend/API-Server, where it belongs. This way the remote plugin does not need to be accessible from the outside, which makes it harder to attack.

Biggest issue

The key problem, why we had to switch to another library was that jersey as a stateless web service is based on multi threading and accepts more than on request at a time. At the time of writing this Docear is still a single threaded applications, which makes it impossible to handle several request at a time. This big difference between Jersey and Docear made us switch to another library.

Why Akka

The main communication with the remote plugin is done by the Frontend/API-Server, which is based on the Play Framework. The Play Framework is already based on Akka for request and job handling. Akka is also configurable to only accept one message at a time, which is currently necessary. Through the mailbox system that is used by Akka it would also be possible to prioritize messages of a certain kind.

Pros

• Used by Play Framework
  • easy and fast way to communicate
• The API is defined through Java Objects, which can be imported by a Java / Scala application and easily used to create calls
• Can process a single message at a time
• Could prioritize messages if necessary
• Can be used for regular occuring events (e.g. checking for unused mind maps)

Cons

• Only accessible via Java / Scala application
  • Not a problem, because only Frontend/API-Server has to access the remote plugin