In general, an imposed workflow would imply that your services are not stateless. Statefulness isn't necessarily an anti-pattern but it is undesirable as it makes scaling your design much more difficult. Statelessness in this context is the lack of server state between calls. If you move session state to a database, for example, it isn't considered stateful from a service perspective. If I make 3 calls, it shouldn't matter if they are satisfied by three different servers. If you can eliminate sessions, that's even better but if not, moving them to a shared datastore eliminates most of the issues.
I'm not sure what to make of "For example, we load in memory a set of parameters associated with the machine session that should remain constant during the application usage." Is this something that the client is providing or is it something server side is determining?
In the former case, can the client provide it on every call? The extra overhead could very-well be worth the elimination of server-side state. What prevents you from doing it when the first 'real' service is called?
Perhaps scaling and fault-tolerance are not of much importance here but making services stateless will greatly simplify the overall design.