Gregory M. Kapfhammer

Associate Professor of Computer Science

http://www.cs.allegheny.edu/~gkapfham/

  
View  Edit  Uploads  History  Top  Changes  Search

Chapter Two: Architectural Styles

  • Select one software architecture and clearly explain it. Make sure that each person's response covers a separate software architecture.

A layered system is based on a hierarchy where each layer provides some service to the layer above it and is a client to the layer below it. Only adjacent layers interact, and the connections between each layer are based on a set protocol. Layered systems are often used in communication protocols. Some advantages of the layered system are: the ability to support designs based on increasing levels of abstraction, the ability to change and enhance the system while only affecting layer above and below what is changed, the ability to reuse and provide different implementations of the same layer interchangeably. Not all systems, though, can be layered and there might be performance issues if a system is layered. Also, determining where to draw the line of each layer of abstraction poses a problem.

Matt DeNapoli

Just as a note, it is also possible to organize operating systems in this fashion. Silberschatz and Galvin have a discussion in their operating systems text about the THE operating system and it's usage of layers. Greg

The pipes-and-filters software architecture is broken up into components that each have their own set of inputs and outputs. These components read steams of input and produce streams of output by applying a local transformation to the input streams and computing incrementally. This way output can begin before all the input is consumed. These components are called filters. The connectors that transmits the output stream from one filter to the input stream of another are called pipes. The filters must not share states with other filters and also they must not know the identity of their input or output streams which would restrict the input and make the output predictable. Also on the same note, the correctness of the output should not depend on the order in which filters perform their incremental processing. There are various specific variations of the pipes-and-filters software architecture. The first is pipelines which restricts the topologies to linear sequences of filters. When using pipelines you must be careful that each filter does not process all of the input data as a single entity. This is call a batch sequential system which is a different software architecture. The second is bounded pipes which restrict the amount of data that can reside on a pipe. The last one is typed pipes which require that the data passed between two filters have a well-defined type. Now why would some one want to use a pipes-and-filters software architecture? First off, they break down the system into the filters which makes the input/output behavior of a system easier to understand. Second, they support reuse, since they are incremental made, so one can attach any two filters with a pipe as long as those filters agree on the data transmitted. Third, since they are incrementally made new filters can easily be added as well as old ones replaced. Forth, they allow certain kinds of specialized analysis (throughput, deadlock). Finally, as was stated earlier each filter is independent they support concurrent execution, which means they can be implemented and separate tasks or in parallel with other filters. For these reasons, pipes-and-filters are often used for compilers, parallel programming, signal-processing domains, functional programming, and distributed systems. There are although disadvantages to pipes-and-filters architecture. First, they often lead to batch organization of processing and are often not good at handling interactive applications since each filter must completely transform the input to output. Second, they can be reach conflicts by having to maintain correspondences between two separate, but related streams. Finally, depending on their implementation, they can lead to lowest common denominator on data transmission which can lead to loss of performance and added complexity in the filters that follow.

Brian McAlister

Very good. What kinds of techniques might be useful if we really do need to maintain some type of correspondence between the streams of data that are moving through filters? Greg

In event-based implicit invocation, the modules' interfaces usually provide a collection of procedures and a set of events that they use to interact with one another. There is, however, an alternative method to combine modules known as implicit invocation, reactive integration, and selective broadcast. In this method, a component can broadcast an event to which other components may have associated methods. Methods for a broadcast are instantiated by the system. The modules that produce the broadcast have no idea what other components will interact with the events; they cannot make assumptions about what processing will take place or the order in which the actions will occur. For this reason, most implicit invocation based architectures often also allow explicit based invocation. A notable benefit of an implicit invocation based architecture is that it is supportive of object reuse. A new component can be introduced by labeling it as an event of that system. Furthermore, system maintenance is made easier because the modules only interact with one another through their interfaces. Thus, components can be altered or replaced without directly affecting the other components. The primary drawback to implicit invocation is that components surrender control over computation. Once a module announces an event it has no control over the results. The module cannot check if any modules will respond to the broadcast nor what alterations they may make to the data. Furthermore, there is not necessarily a uniform way in which data is shared. Sometimes data may be passed as an event and in other situations it may be placed in a common repository. Another consideration is that it is hard to assure the correctness of a system using this kind of architecture. One cannot simply check the pre- and post-conditions of modules since the context of the modules binding affects the operations performed on the data.

Matt Rummel

Just a note: several people have written papers about the development of event-based distributed systems. In these types of systems, processes are able to communicate simply because they are designed to receive certain types of messages. Of course, there must be some type of delivery mechanism to broadcast messages to the appropriate destinations. Indeed, there is even a workshop associated with building distributed systems of this nature: International Workshop on Distributed Event-based Systems Greg


  • Garlan and Shaw discuss the blackboard software architecture. Briefly describe this architecture and comment on the technologies that could be used to make it a reality.


A blackboard architecture is one of two types of repositories mentioned by Garlan and Shaw. The other is a traditional database architecture. But unlike databases where inputs affect the state of the data source and cause selection processes to execute, blackboards support an architecture where the state of the data source causes the selection processes to execute. Blackboards have three major parts: a knowledge source (separate, independent parcels of information; interaction takes place through the blackboard), the blackboard data structure (problem solving state data; knowledge sources make changes to the blackboard), and control (driven by the state of the blackboard; knowledge sources respond when changes to the blackboard are applicable). Distributed technologies such as agents and spaced based computing could be considered blackboards (based on their implementations) because they provide concessions where their (agents/spaces) states can notify clients/servers (knowledge sources and controls) to perform a certain task.

Matt DeNapoli

The blackboard software architecture is a specific type of repository style. The blackboard architecture is used when the current state of the central data structure is the main trigger for selecting processes to execute. The blackboard model is presented in three parts: the knowledge sources, the blackboard data structure, and control. The knowledge sources are all the separate parcels of application-dependant knowledge which go into the blackboard. The blackboard data structure is the problem-solving state date which is organized into an application-dependant hierarchy. The knowledge sources that go into the blackboard make changes to it lead incrementally to a solution to the problem. The control is how the knowledge reacts to the changing state of the blackboard. Certain knowledge sources will respond to the blackboard when changes in the state make them applicable. Blackboard software architectures are traditionally used for applications requiring complex interpretations of signal processing, like speech and pattern recognition. So far the only main technology used for this architectures is Nii.

Brian McAlister

What is "Nii"? I did a search and only found that Nii was the last name of an author who wrote some papers about blackboard systems. Can you post a link to the site that you were referencing when you created this response? Greg

In repository style architecture, there are two parts: a central data structure that represents the current state and components that operate on that structure. The control of data and state in the repository can be implemented in two different ways. The traditional way is to have incoming data determine what processes to execute with results stored as the current state in the central data structure. The other method is the blackboard data structure, where the current state in the central structure determines which processes to execute. Examined with more detail, the blackboard model is composed of three parts. The first part is knowledge sources, which are the individual pieces of application data. The second part is the blackboard data structure, which is a problem solving state data organized in a hierarchical manner based on its type of application. The knowledge sources make changes to the blackboard incrementally, eventually leading to a solution. The third part is control, which is determined by the state of the blackboard. Knowledge sources are self-activated when changes in the blackboard make them applicable. Traditionally, blackboard systems have been used for applications requiring complex analysis of signal processing and systems that involve shard access to data with loosely bound components. This makes it ideal for systems that require resolving conflicts and face possible uncertainties. I am not sure, but perhaps expert system technology could be applied to make blackboard architectures work. The part about individual knowledge sources interacting and incrementally determining a solution reminds me of our brief discussion on expert systems.
Matt Rummel

  • The authors discuss several "familiar architectures." Select one architecture and provide a brief discussion of it. Please comment on tools and/or frameworks that might enable the implementation of software systems that adhere to this architecture.


The client/server architecture is one of the types of distributed systems. In this architecture, servers provide services for clients without knowledge of what kind or how many clients it will be servicing (and if it is constantly running, when it will have to provide service). Clients, obviously, to use the service must know the identity of the service and its access protocol. Jini provides a framework that enables implemenation of software that adheres to the client/server architecture.
Matt DeNapoli

Does the Jini network technology only facilitate the creation of client/server systems? Or, is it possible to build an event-based distributed system with Jini? Several people have written that Jini does not build client/service sytstems by service/service systems. Why might this be the case? Greg

One of the “familiar architectures” is the main program/subroutine organization. This is essentially the basic organization of written code that is taught at a basic level. The system is often organized in a fashion where a main program acts as a driver for a set of subroutines. These subroutines each do different calculations or computations and the main program calls these subroutines in an organized, controlled fashion. For programming languages that use modularization, this technique is used less in its traditional form, but more in fashion of a main class calling other classes it wishes to use. Even within these classes, subroutines may be used.

Brian McAlister

The domain-specific architecture provides a structure suited for a family of applications. A domain model is a representation of what happens in a specific domain, including the functions being preformed and the information and entities that flow from these functions(1). The idea behind this design is that by focusing the architecture on a specific domain, it is possible to standardize the problem-domain terminology and semantics as well as optimize the systems operations for the given family of operations (1). A framework that utilizes domain specific architecture would likely need a tool such as a Domain Definition Language (DDL) to provide a definition of the software design domain at the architectural level(2). In such systems, the architecture is sometimes restricted enough that a complete system can be generated from using such architectural descriptions.


(1) http://sunset.usc.edu/~neno/teaching/s99/February2.pdf


(2) http://www.umcs.maine.edu/~ftp/wisr/wisr8/papers/whiteS/whiteS.html

Matt Rummel

Link to this Page

  • Software Design last edited on 14 October 2004 at 2:29 pm by aldenv28.allegheny.edu