"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"[1] 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.
[1]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).
No comments:
Post a Comment