Concepts and relationships

As part of my brief to look at structuring the concepts and 
relationships I have made the following thought experiment.

1. We can partition the architecture into a collection of 5 
architectural `regions', as illustrated in:

Each of these bubbles represents a distinct aspect of the overall 
architecture. This is a super-concept diagram -- each bubble is a 
collection of concepts that has internal coherence; and yet there are 
well defined links between the super-concepts. The arrows represent 
dependencies/uses relationships between the bubbles (note that in 
actuality this is probably a maximally connected graph).

Going around semi-clockwise from the Message Oriented architecture:

2. The MOA focuses on messages, their structure, processing etc. With 
*no* implied semantics as to the purpose, wether it is part of the 
choreography etc. This is illustrated in the diagram:

This diagram is abstracted from the UML diagram of SOAP generated by 
Martin C.

3. Service Oriented Architecture. The SOA is `all about' action. It 
`floats on top of' the MOA, but in considering the SOA we add the 
concepts of action, interface and service description. This is 
illustrated in the diagram:

Notice that we do not particularly need to refer to messages when 
thinking at the level of service; and we especially are not concerned 
with intermediaries. We are concerned with interfaces, actions, agents, 
etc.

4. Resource Oriented Architecture. The ROA is `all about' resources. 
This is an attempt to capture the essence of the REST architecture as 
it relates to resources. The ROA adds the fundamental concept of 
resource (which is not inherent to service), together with a related 
`service model' of actions such as GET and PUT. This is illustrated in:

5. The Policy Architecture. The PA is `all about' security. However, at 
an architectural level of abstraction, security is well captured by the 
notion of a policy: which is a constraint on the behavior of agents in 
terms of the actions that they may perform. There are many kinds of 
policy, not just the ACL (Access Control List) notion but also QoS 
notions of policy and even application-level policies (my personal 
favorite is the `Lawyer service' that has a policy of ignoring every 
message that does not include a dollar bill in it.) The policy 
architecture is illustrated in:

5. The Management Architecture. The MA is `all about' managing deployed 
or deployable resources. It floats on many of the other regions; making 
particular use of messaging, policies, resources and service. This is 
illustrated in the diagram:

Note that each of these regions is both quite self-contained and yet 
has clear connections to other regions. I believe that organizing the 
concepts and relationships in a way that is similar to this would 
result in a clearer architecture, that is easier to understand.