Loosely coupled interfaces

I posted a short while back an entry about designing generic service interfaces. By chance I happened to come across this (rather old) blog entry by Carlos E. Perez in which he proposes extending speech acts to define loosely couple interfaces. He bases it on a paper by researchers at Stockholm University in which they try to provide a universal framework for human communication in an economic domain, i.e. the business world (the paper is still marked as work-in-progress, so I guess it hasn't been peer reviewed). To do this they use a a triple:

(intention, action, object).

The values each element can take on are:

	Intention		Action
	propose		create
	accept		change
	reject		cancel
	declare		none
	query
	reply
	assert

So, to create a new customer record the triple could be:

(propose, create, aCustomer)

the service could then return with:

(accept, create, aCustomer)

or, in the case of an error could return:

(reject, create, aCustomer)

You can have a lot of fun thinking up new combinations. One thing to notice is that services themselves don't seem to have names. Instead, one could envision a dispatcher which takes each received triple and then finds the correct service implementation.

If this would work out in practice, I do not know. But it seems to aid support to my argument that the REST vs SOAP debate is about which technology should be used, and not about designing interfaces to achieve loosely coupled services. How to achieve this should be the real debate.