Restructuring concepts and relations

Mike and I have been noodling a little on the overall bag of concepts 
and relationships.

Enclosed is a super-concept diagram (v. incomplete as yet) that 
highlights one possible breakdown of the architecture:

The idea is that the WSA can be partitioned as a kind of 
system-of-systems. There is a fairly densely connected set of 
dependencies between these areas but generally each can also be viewed 
in as independent systems.

Each of these bubbles has a key concept `called out'; this is my 
opinion of what might be called the `salient' concept of each of these 
areas.  For example, the Message Oriented Architecture is all about 
sending messages. However, at the level of message sending the content 
of the message is not really `of the essence'; on the other hand 
reliability, integrity, privacy certainly is.

The Service oriented architecture is all about actions. Of course, to 
properly talk about it we also need to cover a lot of other concepts - 
such as agent, MEPs, choreography(*), etc.

The Resource Oriented Architecture is all about resources. This is my 
place holder for the REST architecture (at least the aspect that 
defines the concepts of resource, representation, identifier etc. and 
limited uniform vocabulary for dealing with resources)

The Security architecture is really a poor name. It is really 
attempting to capture policies, privacy (at a different level to that 
in the MOA), legal accountability (**), etc. A better name would be the 
Institutional Architecture but that name may confuse a bunch of people.

The management architecture focuses on the deployed aspects of Web 
services. It deserves its place as a first class system for a couple of 
reasons: it addresses a key aspect of Web services and it is not a 
proper sub-system of any of the others.

A couple of technical points:

The relationship between these systems is a kind of `uses' 
relationship. The technical term is `supervenes'; which has a couple of 
key characteristics:

A system supervenes over another system if:
a. A behavior in the lower system affects the higher system
b. You can replace the lower system with another that has equivalents 
for each of the properties depended on by the higher system.

Property b. implies that the higher system has predictive properties 
that are actually independent of the details of the lower system. 
Property a. implies that the `full impact' of a behavior in the lower 
system can often only be understood in terms of the context that it 
occurs in -- i.e., the supervening system it impacts.

A comment: I believe that, for the most part, those concepts that 
people might call `core concepts' often reduce down to what I have 
called the MOA. However, that reduction does not do proper justice to 
the importance of the concepts appearing in other parts of this 
diagram. Hence you will not see `Core architecture' here: it is all 
`core' :-)

Frank