This article is about terminology used in System Analysis and Design activities. It started from the never-really-answered question: “What is SOA?” which lead to even harder questions like “What is Software Architecture?” To answer I relied on three sources: Roy Fielding’s Ph. D Thesis, UML Specification and SoaML Specification.

Roy Thomas Fielding’s Ph. D Thesis[1] is well-known because introduced REST to the world, but has a much broader scope, including a categorization in the software architecture domain. Fielding defines the following terms:

software architecture – an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture

software architecture elements – components, connectors, and data–constrained in their relationships in order to achieve a desired set of architectural properties.

component – an abstract unit of software instructions and internal state that provides a transformation of data via its interface.

connector – an abstract mechanism that mediates communication, coordination, or cooperation among components.

datum – an element of information that is transferred from a component, or received by a component, via a connector

configuration – the structure of architectural relationships among components, connectors, and data during a period of system run-time

architecture style – a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.

pattern – (a) an important and recurring system construct; (b) the process of solving a problem by following a path of design and implementation choices

One interesting and useful aspect about these definitions is that they are recursive. That may be confusing in a definition but it allows the terminology to scale with the size of the system it describes. For example, a large system has an architecture containing components, connectors and data, then each component has an architecture made of components, connectors and data, etc. This fits well with the refining method used in system analysis and with the bottom-up approach in building systems.

Another thing that I like is the concept of architecture style. Fielding’s thesis describes a few of them: Client-Server, Layered System and proposes a new one – REST. For me it is important to have a name for these “things” often used in conversations about system architecture. For example I can say about a component design that it uses the REST architecture-style.

Another source of definitions is the UML specification. Besides the visual notation, UML also defines terms for the Object Oriented software architecture. Some of the terminology is common between UML and RF (component, connector) but often with some subtle semantic differences. Besides that, I use:

interactions – sequence of communications between components which can be described in Sequence Diagrams, Interaction Overview and Communication Diagrams (CG)

colaboration – a collection of elements that colaborate to implement a piece of system functionality(CG)

As I mentioned before, one reason for starting this inventory of terms is because I wanted a definition for SOA. The SoaML Specification [2] describes SOA in Section 7.1 as:

[…] a way of organizing and understanding organizations, communities, and systems to maximize agility, scale, and interoperability […].

SOA has been associated with a variety of approaches and technologies. The view expressed in this specification is that SOA is foremost an approach to systems architecture, where architecture is a way to understand and specify how things can best work together to meet a set of goals and objectives. Systems, in this context, include organizations, communities, processes as well as information technology systems. […]. Some other views of SOA and “Web Services” are very technology focused and deal with the “bits and bytes” of distributed computing. These technology concerns are important and embraced, but are not the only focus of SOA as expressed by SoaML.

This is a description not a formal definition. If I employ the RF and UML vocabulary, I can make a better definition of SOA:

SOA is an [RF]architectural style in which large distributed software systems are constructed as loosely coupled, coarse grained [RF]components called services.

The SoaML specification defines a few other terms that I find useful:

Service Architecture – a [UML]collaboration between [SoaML]services

Service Contract – defines the terms, conditions, interfaces, and choreography that interacting participants must agree to (directly or indirectly) for the service to be enacted.

SoaML addresses some of the complexity that exists in that in real systems not always covered in SOA presentations. For example, the interactions between services are not just simple synchronous calls. Sometimes they are asynchronous request-response, sometimes more complex. The specification calls the later interactions a choreography represented by a UML behaviour diagram (Sequence, Communication or Interaction Diagrams).

Besides the terms that I mentioned above I am also using the following terms with a looser definition:

application – [RF]component that is a unit of administration: build, deployment, packaging, documentation.

sub-system – [RF]components that correspond to a business or technology domain. They are the building blocks for a [CG]system.

system – [RF]component used to represent the scope of a large project.

References

[1] Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, 2000, http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

[2] Service oriented architecture Modeling Language (SoaML), http://www.omg.org/spec/SoaML/1.0/Beta1/PDF