"Show me a message(*) and I'll show you a representation of the state of some resource."
I agree with that but would add that in my conceptualisation of SOA, a "resource" is some business meaningful concept like a customer or a widget.
A "service" is what you get when you bind such a resource to an asynchronous communications channel that you then expose to HTTP.
Simply put, business resources should be "one step back" from HTTP IMHO. When you send non-safe messages to a resource (e.g. POST/PUT), you send them to its inward bound, asynch message queue. You do not directly interact with the business resource.
What you get back from a resource with an idempotent GET, is a "stable data" representation of the resource at time T. It may or may not be the same as the current resource and it certainly does not take account of any pending non-idempotent updates.
I find this resource/service distinction useful and find the temporal decoupling absolutely invaluable. It is, as far as I am concerned a cornerstone of any useful SOA.
I recommend Microsoft's Pat Helland on the subject of "stable data" e.g. http://prade.microsoftemea.com/content/ARCSYM1_Helland.ppt (especially slides 9 and 11).