How can OSGi and Akka benefit from each other? How is this structured?

Question

Following up my rather illogical question, asking to use OSGi or Akka, I was advised that the two can be used together, and that they each solve a different problem. I could use OSGi to provide modularity and updatability, and Akka to provide scalability and performance. As there hasn't been a lot of experimenting with combining OSGi and Akka, I still have a couple of questions.

How can OSGi and Akka be used together and benefit from each other? How is this structured? Do all your actors reside in one OSGi bundle, do they each get a separate bundle, is there a hybrid solution or isn't there really a 'right' way to do it?

I would divide the big components in different OSGi bundles. Each bundle exists of different Akka actors. Each bundle can then be scaled separately from each other in function of the load on that bundle. In each bundle transparent load balancing can be used to spread the load over different actors. Would this be a correct and realistic way of doing this?

EDIT

Thoughts after implementation: They clearly complement each other! I divided my application into big blocks, which I then injected into parts of the application using Spring. Inside the big blocks I solely used Akka. The gates to the blocks are Typed Actors. To make my system completely asynchronous I had to implement some extra functionality. So no blocking calls remain all interface methods should return the void type. Couldn't find any other way. You can then pass a message through the interface as an attribute that gets carried around for the whole journey of the request, which gets registered into a "Responder" at the beginning of the request. At the end a DeferredResult object gets successfully returned or an error/timeout is returned.

Answer 1

Here's how I use the two together.

Think of it like this...

Object-Oriented Programming introduced new layers of encapsulation. At the object level (with private members). OSGi just enables JAR-level encapsulation. Without OSGi, as soon as its compiled, it all melts into one pot. OSGi enforces the interface at the JAR level. And because of that, you have cleaner modularity and better code (for the same reasons any type of encapsulation is good).

I only use OSGi to do the JAR-level encapsulation. Any features that overlap such as scaling up certain modules based on usage, I do in Akka, because the API is higher-level and so easier to do and maintain.

But, many things about them don't overlap, so you should be able to see what goes where pretty easily with that rule of thumb in mind.

OSGi is to me just very useful for enforcing a good design, because it has rules for how I can consume a service... enforcing an interface at the JAR-level.

I'd say your last paragraph explains it well. Just modularize it like you would for any large-scale software. But now they are OSGi bundles instead.

If you have follow-up questions, please do comment. I can edit to say more. I've been using the two together for a while now.

Edit: Response to comments

Reading your question, it seems you may know some things I don't. Which I can't be sure of, so let me know if this post misses its mark. I'm an Akka guy who later did some OSGi, if you did that the other way around, you may be aware of options that I am not.

sharing the actor system is trivial. OSGi bundles don't cause inversion of control like a framework. You just call it like any other library code.

Wherever you are creating the actor uses system.actorOf calling the class of an actor in another bundle, and that's it. Your question seems to imply you know more about other OSGi options or perhaps are thinking that OSGi will do inversion of control and so each bundle would be stuck with its own actor system.

If it's still unclear, I'd recommend a quick prototype. Just pass the first end-to-end test that uses the design and then refactor adding in OSGi.