Hello,
I have been using both AF and SMO for different projects. I started using SMO because it seemed easier and then used AF for some specific projects.
Here are my two cents:
- I agree with François that the SMO is simplier to apprehend than AF.
- There is a nice UI to create SMOs (with templates) and messages, which smooths up the first use of the framework. That UI gets however, very slow as the project grows to a point where it is not usable anymore. AF as some scripting tools to help you create actors and messages, not as fancy as the SMO tools but they do not get slow when the project grows.
- SMO automatically creates for you a launcher to test your SMO. It's not a lot of work to create a launcher with AF but still...
- SMO tends to use a reactive programing paradigm: what is shared between actors is data. While AF uses an imperative programing paradigm: what is shared is commands, each actor tells what to do to other actors (except when using abstrac messages).
- Decoupling processes is natural with SMO while with AF you have to go through the process of creating abstract messages which is painful and takes a lot of time (if there is a way to do that without having to find the parent class on the harddrive, please do tell me!).
- It is easy to just add one SMO to an existing application that wasn't programmed with SMO or AF in mind. For instance when revamping parts of a legacy code. It's not that easy to add an Actor to an application that wasn't programmed with AF from the ground up (it is possible, though).
- Managing static nested processes is very easy with SMO: just add the static dependecy inside a cluster and that's it. It makes it very easy to create mediators processes. One downside is that is it not possible to apply a pre-launch configuration to the nested dependency. With AF, it is not that difficult to create nested dependency but is is not automatic.However it is possible to modify the private data of an actor before launching.
- I don't think there is a robust way to make sure an Actor of the AF has stopped (without modifying the framework). Because you never know if all the helper loops have stopped. SMO, out of the box provides an "SMO state" information which is very useful.
- In the same idea: SMO gives you the opportunity to abort a process that did not stop correctly. This is very handy. I don't think there is the equivalent in AF.
- the SMO class is programmed with many hooks. This is good because when you know where to add a functionnality, it is very straightforward. However as mentionned by someone else, documentation is a bit lacking.
- SMO use events as transport mechanism for the messages, while AF use queues. Using events makes it easy to implement an observer pattern: many processes listening to the same event generated by one process. But it is harder to track when messages are consumed.
- I find intra-process communication easier with AF, mostly because of the use of the command pattern. Creating relatively complex state machines with AF seems easier than whith SMO.
- When inheriting from an SMO, the parent SMO runs in parallel with the child. When inheriting from an actor of the AF, the messages of the child actor are processed in series with the messages of the parent actor. Having the parent and child SMO running in parallel means that a bit extra work is needed when you try to synchronize the work of the parent and the child.
- One big-big plus of the AF is the documentation and the tools that the community created around it. For instance Monitored Actors, Panel Actors, MVA framework,... are really worth checking out.
This is not exhaustive and I guess there are many more differences. I something I wrote is wrong, please tell me, I'd be happy to know how to get around some of the issues I mentionned.
Best regards
