Actors should not be used to replace traditional service components without considerations.
Most of the service components we write nowadays, by training, are stateless. Stateless service components are easier to manage (sans message class, etc) than actors. One of the things they lack though, when compare to actors, is asynchronous execution. But when clients are expecting the results to return synchronously most of the time, synchronous stateless service components are just fine for the job.
Actor is a good fit when there are internal states to manage. There is no need to do any synchronization inside "act()" to access internal states and to worry about race conditions. As long as "!?" is not used inside "act()", deadlocking should be minimized as well.
Actors should be wary of any blocking processing done while handling messages. Since actors process their messages sequentially, any time they are blocked waiting for I/O inside "act()", they can not process any other messages in their mailboxes. The Scala idiom to use here is to start another ad-hoc actor that does the actual blocking operation. This anti-pattern affects event-based(react) actor even more because it blocks the thread the event-based actor is piggy-backed on as well.
From what I can gather, all four of your calls to the service components are potentially blocking, so cares should be taken to make them scale when converting them to actors.
