I must admit that I'm not all that familiar with Akka. I checked their project site just now and it does look interesting. One question in my mind though is at what level does it integrate with SwitchYard? What are the features of Akka that you think are most relevant as a service implementation? I did check out your test code, but I think the test was meant to be a simple validation vs. highlighting a specific feature of Akka itself.
I must admit that I'm not all that familiar with Akka.
I've only been playing around it and I'm by no means an expert and still learning. I've read about Akka and its Actors model previously, and it caught my attention again when reading "Camel in Action" which has an appendix about Akka.
One question in my mind though is at what level does it integrate with SwitchYard?
I see this as a way for users to have more choice in Service Implementations. Users might have existing services that use Akka or want to build new service implementations that use Akka.
What are the features of Akka that you think are most relevant as a service implementation?
The main features that I see is Akka's Actors model and having a service implementation would let SwitchYard users take advantage of Akka's event driven architecture, it's fault tolerance and scalability.
As I mentioned earlier there is already integration between Camel and Akka, which SwitchYard users could certainly use, but there might be cases where users don't want to bing in another framework (Camel) just to use Akka. Just like the integration between Akka and Camel, where Akka can receive/send messages to/from Camel endpoints, this would do the same for Akka and SwitchYard.
I did check out your test code, but I think the test was meant to be a simple validation vs. highlighting a specific feature of Akka itself.
Yep, this was mainly just to get the communication working and validate. I could expand on this and make this into a more real world use case?
It's been a while since I've messed around with Akka, and I didn't get very far, but I think it would be best suited as an alternate implementation of the core. I think it's strengths lie in threading, queuing and management of workers (actors).
Since we're talking a lot about actors, i think it's important to note that the actor just performs an action on an event, much the same as a processor in camel (or esb). The key strength of Akka, I believe, is the supporting infrastructure for receiving an event, getting it to an actor and dealing with any problems along the way.
My two cents...