Requirements Modelling and Specification for Service Oriented Architecture

2.4. Architecture and SOA

Let us look at two, quite similar, definitions of software architecture. As we saw earlier, the SEI say that the software architecture of a program or a computer system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the connexions among them. The first version of Catalysis (D'Souza and Wills, 1999) regarded the architecture of a system as consisting of the structure or structures of its parts, the nature and relevant externally visible properties of those parts, and the relationships and constraints between them.

Apart from noting the woeful absence of architectural vision from these definitions^[], we should note that both of them are about building systems from components: black boxes that have externally visible properties. Services satisfy these criteria perfectly. So, as we have seen, SOA is about building systems from loosely coupled services, which in turn are built from black boxes (components) that implement service operations, possibly (but invisibly) by delegation. Adding to this the requirement that services should be reusable leads to the conclusion that, for ease of construction and maintenance, the components too should be loosely coupled.

^[] Actually it was present in Catalysis but hidden away in the Catalysis notion of a 'kit of components'.

As a corollary of this, a good approach to SOA is to separate service design from system design.

We should build ...