In reading this blog post:
http://davidpallmann.spaces.live.com/blog/cns%21E95EF9DC3FDB978E%21257.entry
David asserts that a service contract should have a theme, and all the operations should fit in with the theme. I couldn't agree more, and it sounds remarkably like long-standing guidance found in the OO world.
To summarize, SRP, or the Single Responsibility Principle:
. . . every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility
Service Oriented Architecture isn't a wholesale shift from OO, but it's a compliment that focuses on system-to-system interaction instead of object-to-object interaction, and the SRP holds true with this focus as well.
In software, we create units (whether they be systems or objects), and each unit does something over, and over, and over, and over. In factories (think Ford), each unit (person) on the assembly line does something over, and over, and over. Like Tom DeMarco, Ford found that the whole factory functioned better when every unit(object or person) had a single responsibility and performed that responsibility well. So now, with SOA, each service should have a single responsibility and perform that responsibility well.
To expand this thought, perhaps the SRP can be applied to any situation where the tasks are known ahead of time and repeated exactly the same over, and over, and over.
Question to readers: Are there situation in creating OO software (that might function within an SOA) where SRP does not or should not apply?