Architectural patterns and styles
subsections:
When constructing a system, how does one determine an appropriate style? There is no simple answer to this question. According to
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
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
We distinguish between three different architectural styles:
- the distributed objects style
- the (dynamically) downloadable code style
- the mobile objects style
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
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!
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.
distributed objects distributed objects downloadable code downloadable code mobile objects
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.
(C) Æliens
04/09/2009
Case study -- perspectives in visualization
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.
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
Rules of thumb -- selecting an architectural style