Wednesday, August 25, 2004

Resources and services

Mark Baker says:

    "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. (especially slides 9 and 11).

No comments: