A social model

This diagram attempts to explicate the fundamental relationships 
between agents, owners and  actions undertaken by services.

The critical concept here is actually social fact. An example of a 
social fact is a policy (i.e., an agreed constraint on the behavior of 
services etc.), a signed contract, and so on. Social facts really 
represent the shared state between the various players.

Note that it is useful to remember the distinction between signing a 
contract, telling someone that you have signed the contract and the 
signed document itself.

In order to establish a social fact two things are required: one or 
more actions (typically in the form of sending messages to Web service 
providers or requesters) and the requisite authority. For example, if I 
send a purchase order message to a widget selling Web service then that 
is the required action to place an order; however, if I do not have a 
legitimate account with the Web service, or if I am under the age of 
18, then I haven't actually placed the order. The establishment of the 
order (or policy etc.) is called the *enactment* of the purchase order.

Social facts are always interpreted relative to a social domain (or 
even a domain of computers). Consequently, authority is also relative 
to a social domain (the president of the USA has no authority in 
Venezuela).

Authority is also linked to the roles in a transaction; the president 
may have the right to appoint a judge, but doesn't have the right to 
make legal judgements in a court of law.

=============
This model is useful as a way of capturing the necessary relationships 
between agents, policies, policy declarations, and valid constraints. 
Asserting a policy is an example of enacting a social fact. The entity 
declaring the policy has to perform the requisite action and have the 
required authority (otherwise the policy is not, in fact, a valid 
policy).

I am aware that the scope of this model goes way beyond SOAP, WSDL, 
etc. However, I offer it as a way of gaining clarity on some important 
aspects of the architecture which *do* impinge pretty directly on SOAP 
etc.

Frank