In my previous post, I gave a high level overview of Roy Fielding's dissertation on Architectural Styles and the Design of Network-based Software Architectures (more commonly known as the REST thesis). In the paper a heady definition of architecture is put forward in which it must, among other things, be a run-time description. An architecture is not the organization of source code in text files. It also is not what you wish your run-time to be. It is a description of an actual application at run-time. This is in contrast to a style which is a group of constraints that induce properties. Styles, constraints, and properties are used to give a novel description of components. Together these concepts are used to abstract away unneeded details while focusing on desired affects in a system. I'll try to lift some simplified definitions of these concepts from the paper and put them here.
In the paper's methodology, elements are comprised of components, connectors, and data. A component is simply a transformer of data. A connector describes what glues the components together. Data is transformed by components, and transferred through connectors. If you are familiar with COM, DCOM, CORBA, or other component descriptions notice how the concept of data therein is usually absent or only vaguely described. This has important implications if the data being transferred through the system has a significant impact on the system. This fact is revisited throughout the paper specifically when talking about self describing messages.
An architectural style is a grouping of constraints on elements (components/connectors/data) that induce properties. A property (also known as a quality or attribute) is a desirable (or tolerable level of an) 'ility'. Some examples of an ility would be extensibility, evolvability, or performance. A constraint produces a property in the system. An example of a constraint would be adhering to the principle of separation of concerns, thereby separating the user interface from business logic, in order to increase maintainability, evolvability, and possibly security. A software engineer can take a style's constraints along with their respective properties and compare them to a run-time to see if it matches. A style can also be compared to other styles by using constraints and properties as a ubiquitous language to discuss architecture. Comparing the design trade-offs makes explicit the hard choices between architecture styles.
When focusing on a style (at least in a network application) it is useful to concentrate on one of three views of that style. A view is a perspective of an implemented style. A processing or component view would focus on how data is transformed in a component. A data view concentrates on the forms of data while abstracting away how and where the data is transformed. A connection view highlights state as well as interactions between components.
In order to evaluate a design for any architecture you must first decide on the type of application (and therefore that application's functional requirements). This limits the categories of architectures being considered. For instance, a text file editor usually doesn't need to be network aware and therefore doesn't need a network based architecture. After the application domain is determined, the non-functional requirements or properties need to be made explicit. An example would be an application service that starts with 10 requests per second but is expected to grow to eventually receive 10000 hits per second. This application would have a non-functional requirement of scalability. Each one of these concepts deserves its own article so I'll revisit them later. In my next post I'll go over the paper's view on network applications and the implications of networks on software architecture.
This article was originally published on wwatson.net