Instead of saying statefulness is a necessary evil, what I really meant was:

if you really have to hold state, then
a) shield the back end from this detail by having a proxy hold state, and
b) then try your darndest to limit the interactions with the proxy to those which have no side-effects.
c) If they have to have side-effects, then present a tight script so that client can only talk to the proxy in a particular order

If I can find the right words, I’ll post more on why having less flexibility is important.

A post over at the counterpoint blog brings up Stateful Web Services.
After reading it over a few times, I believe the post asserts that:
1. SOA and Web Services lend themselves towards a course-grained API. (Which I think it means WS-*).
2. But user…