Architectural patterns and styles

Instructor's Guide

intro, components, case study, crossing boundaries, styles, platform, summary, Q/A, literature

Subsections:

 When constructing a system, how does one determine an appropriate style? There is no simple answer to this question. According to  [Practice], several forces play a role, for example quality requirements concerning availability and performance and technological constraints that have to do with the platform on which the system is intended to run. Also, as frankly admitted in  [Practice], personal experiences and preferences of the architect play a role.

Architectural choices lead to a particular decomposition into components and a characterization of the relation between components. Classifying groups of software architectures, we may speak of architectural styles, which may be defined, following  [Shaw96], as descriptions of component types and patterns of runtime control and data transfer.

In this section we will look at architectural styles for distributed object systems. Three styles will be introduced, and we will discuss how these styles are related to technological constraints imposed by particular component technologies. Then we will investigate how these styles work out in practice, by a simple case study in which we explore the consequences of a particular style for the solution of a specific problem, in our case the problem of dynamically changing a viewpoint or perspective in an interactive visualization system.

From technology to style

Instructor's Guide

intro, components, case study, crossing boundaries, styles, platform, summary, Q/A, literature
We distinguish between three different architectural styles: This distinction is arbitrary, in the sense that other distinctions are conceivable. However, the distinction above is well motivated by the technology matrix introduced in section Technology, as reflected in the feature-based description given below.
distributed objects downloadable code mobile objects
Componentobjectobject/classagent
ConnectorORBvariousmethods
Creationserverclientany
Locationserverclientany
Clientfixedextensibleextensible
Serverextensiblefixedextensible
slide: Feature classification

The distributed objects style comprises software architectures which consist of software components providing services to client applications. Each object is located at a single, fixed place. Objects on different machines are connected by an ORB (Object Request Broker). Example technologies supporting this architectural style are CORBA and DCOM.

The second architectural style is the (dynamically) downloadable code style. Classes may be downloaded, to be used on client machines for instantiating objects, which will run on the client machine. Example technologies supporting this style are Java applets, JavaBeans, and ActiveX controls.

Finally, in the mobile objects style, objects may migrate from host to host, carrying both functionality and data when they move. Consequently, mobile objects may communicate with the local objects of the host they currently reside on. Mobile objects are a means to implement agents which wander through a network, collecting information, negotiating with other agents, periodically reporting back results to the user who launched the agents. Technologies supporting the mobile object style are agent ORBs such as Voyager.

Features

In slide Features, an overview is given of the characteristic features of each style. Clearly, the styles differ in what are considered as constituent parts (components and connectors), location issues (which determine where objects are created and where they are located during their lifetime), and functionality issues (that is whether either the client or server is functionally extensible).

We may regard the location issues as the prime discriminators of the architectural styles discussed. Adopting the distributed objects architectural style, new objects can be added at the server-side, where they will stay for the remainder of their lifetime. In contrast, adopting the downloadable code style, objects may be created at the client-side, from classes obtained from the server. Most flexible is the mobile objects style, which allows for objects to reside on either server or client machines.

The location properties directly affect the way that the system is extensible with new functionality. Clearly, the mobile code style offers the maximum of flexibility and functional extensibility. Nevertheless, as we will discuss shortly, there are tradeoffs involved. The maximum in flexibility and extensibility does not necessarily offer the optimal solution!

Case study -- perspectives in visualization

Instructor's Guide

intro, components, case study, crossing boundaries, styles, platform, summary, Q/A, literature
To determine which architectural style to use, or which mix of styles, is to a large extent determined by practical experience. Nevertheless, at the end of this section, we will discuss some rules of thumb that may guide you in the choice of a particular style. However, first we will look at an example that illustrates the consequences of the choice of a particular style. The example comes from the distributed visualization architecture (DIVA) that is explained in more detail in section DIVA. DIVA is being developed in cooperation with ASZ/GAK, the largest social security provider in the Netherlands, for experimenting with business visualization to support decision making. Our case study focuses on how to support the sharing of perspectives in visualizing shared information. For example, one of the users discovers a new way to display information, uncovering aspects that would otherwise remain hidden. This new perspective must then be shared with other users to coerce them, so to speak, to this new point of view. What we will look at, here, is how the choice of a particular style affects the solution for the sharing of perspectives problem.
slide: Exchanging perspectives

Distributed objects style

New functionality can be added by creating a new object at the server. In this case, slide Perspectives(a), the user discovering a new perspective acts as the server. Then, assuming that the discovery of a new perspective is somehow announced to the other users, a user can connect to the server and request for that particular perspective (1). Then, a new visualization object is created (2), which is made accessible to the user requesting for the new perspective (3).

Downloadable code style

When a new visualization perspective is discovered, a class is created that can be downloaded by the interested user, slide Perspectives(b). The user connects to the server that contains the new visualization class (1), downloads the class, and instantiates a new visualization object (2). Finally, the information is retrieved from the shared information server and accordingly visualized (3).

Mobile objects style

Similar as in the downloadable code style, the new visualization perspective is downloaded from a server to the client, slide Perspectives(c). However, in this case, when a user requests for a new perspective (1), it is not a class, but an object, actually a clone of the object residing at the server, that is transferred to the client's machine (2). The clone, which contains all relevant information, does not have to contact the shared information server to update the user's visualization with a fresh viewpoint.

Guidelines for selecting a style

 In the DIVA system, we have experimented with all these styles. In our system, we eventually made a choice of the mobile object style for sharing perspectives, since it turned out to provide the most flexible solution. It was also the most natural solution to create display agents for managing perspectives. See section DIVA.

Nevertheless, for other parts of the system we were forced to choose a different solution. For example, since we use a C++ simulation library for obtaining the information, we had to use distributed objects (read CORBA) for making the information available. And for developing control applets, agent technology seemed to be a bit of an overkill so we restricted ourselves to plain Java technology, that is the downloadable code style.

Generalizing, from our experience we can formulate the following rules of thumb, listed in slide Guidelines.

Rules of thumb -- selecting an architectural style
  • Dedicated hardware or legacy code

    distributed objects


  • Strategic or secret code

    distributed objects


  • Many users

    downloadable code


  • Periodic updates

    downloadable code


  • Communication and negotiation

    mobile objects


slide: Rules of thumb
 Because interoperability is a key feature of distributed objects, the distributed objects style is particularly recommended for wrapping dedicated hardware or legacy software systems. Additionally, distributed objects only expose the interface and do not give away the implementation. This may be necessary for strategic or security reasons.

When a large amount of clients is running an application on a server, the server can easily become overloaded. In this case, moving the processing to the client, by deploying dynamically downloadable classes, is a natural solution. Additionally, when (parts of) an application are updated often, for example because of changing legislation, architectures based on downloadable code are much easier to keep up-to-date. Clients are then automatically using the latest version of the available software.

The latter guidelines hold for the mobile objects style as well. However, agent technology is much more complex. And there is, generally, an efficiency price to pay. So, it is reasonable to introduce agent technology only when real benefits can be expected from the migration of objects, for example when the communication and negotiation with local objects is substantial.

Concluding, we may state that the adoption of a style will often be dictated by the technological constraints a system must satisfy. Nevertheless, a word of warning is in place here. Choosing a style may well have consequences for the overall complexity of the system. Minimalism is to be strived for, in this respect. For example, adopting the mobile object style, that is the use of agents, may significantly complicate the semantics of the system, and consequently induce an increased verification and validation effort.