To me, the Service example you gave was actually another form of a controller, albiet one that is not a classic, HTTP-oriented, stateless controller. I have not

To me, the Service example you gave was actually another form of a controller, albiet one that is not a classic, HTTP-oriented, stateless controller. I have not thought this through yet -- but I suspect the state machines that manage lifecycles would be better implemented as separate set of controllers; "services" is an OK name for this abstraction, but there is probably a better one. Rails 3 makes it easier to swap out controllers and routers. (It also loads everything under app/ by default, so you can name app/observers or app/services without having to add in extra load paths by hand). It should not be difficult to implement a parallel workflow engine, for example, that uses a shared persistence stack (models) yet manages data lifecycle, and respond to messages rather than stateless RESTful resource APIs. Good thoughts, good article.