1 Using m ultiple database Three-tier architecture / 2 servers - - PDF document

1

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 1

MORE ON ARCHI TECTURES

• The main reasons for using an architecture are

maintainability and performance.

• We want to structure the software into reasonably

independent parts for easy maintenance.

• We want to be able to increase performance if
• needed. A suitable architecture allows us to

increase processing power where it is needed.

• A good architect knows different architectural

styles (which are like design patterns) and understands the technology and application to identify the potential performance bottlenecks.

• Let’s discuss some models and history…

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 2

Monolithic Architecture / 1

• Monolithic systems are not divided into

independent parts. They typically run on a single processing unit (computer).

• There was a time when computers typically did not

talk that much with each other.

• This made monolithic systems more or less the
• nly choice.
• Lack of complicated communication speeds up

processing, but it is hard to improve performance in any other way than increasing processing power for that one computer.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 3

Monolithic Architecture / 2

• Typically and historically, the monolithic system

talks with fairly dumb clients (like terminals).

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 4

Client/ Server Architecture / 1

• When terminals were replaced by microcom puters,

they started to have processing power.

• To use this power just to run a terminal program

was a waste of processing capabilities.

• Consequently, the microcomputers were used to

run a client program, which talked with the mainframe server.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 5

Client/ Server Architecture / 2

• Fat clients contained more functionalities and data.
• Thin clients contained more or less terminal-type

functionalities.

• Client/ Server (C/ S) computing was the first step

towards multi-tier (multi-layer) architectures on processing unit level.

• It allowed a better division of work.
• However, fat clients also needed maintenance and

installations to keep up with current versions.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 6

Three-tier architecture / 1

• The server side was still monolithic in a basic C/ S

architecture, which created a performance bottleneck.

• As the applications usually had a database,

multiplying the database is hard in many cases, which makes it hard to multiply the servers.

• However, by having a separate database server it

was possible to have multiple application servers.

DATABASE SERVER APPLI CATI ON SERVERS

2

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 7

Three-tier architecture / 2

• The database server only runs the database, as

having several of them is difficult.

• If there are database server performance

problems, get a more powerful server!

• You may use several servers for backup to always

have a backup server on-line ready for action.

• The three-tier architecture is fairly common.
• To make client installation easier, it is possible to

have a client server (or UI server), from which the client is software is loaded for execution (like an applet to be executed in the browser).

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 8

Using m ultiple database servers

• If data is replicated to several databases, updating

them correctly is a problem – in particular if the replicas must be consistent.

• If data is replicated, then it should be easily found
• somehow. Like assume a library keeps books with

title starting with ”A” on one data server, ”B” on a second server, and so on.

• Queries based on other selection criteria or data

from several servers are problematic.

A B C Z . . .

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 9

Peer-To-Peer Com puting

• The above processing architectures have assumed

that we have separate servers and clients and the configuration of the system is controlled in a centralised fashion.

• In Peer-To-Peer computing, each computer (node) is

equal, and the nodes may ask each other for processing services.

• The nodes may contact each other flexibly and

forward processing requests, which removes a fixed configuration for processing.

• Grid com puting (”a software infrastructure enabling

flexible, secure and coordinated resource sharing”)

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 10

Processing Unit vs. Softw are Architecture

• If an architecture divides processing into different

types of processing units (clients and various servers), then of course this division im plies also a division of the software functionalities.

• However, there is also architectural structural

decisions, which do not need to be based on the processing unit architecture.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 11

Dividing the tiers

• As an example, we may divide the

application server functionalities into domain tier and control (application)

• tier. Typically it is the domain tier,

which talks to the database.

• It makes a big difference, how the

layers talk with each other.

• It is typically seen as a good thing, if

the layers call each other in top-down fashion and the calls do not pass-by layers (e.g. application layer does not call database layer).

• Makes maintenance easier.
• Performance may suffer.

Database tier Domain tier Application tier Client tier

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 12

I ssues w ith m ulti-layer architectures

• Number of layers
• Error/ exception management (what to pass on,

what to process)

• Callback from lower layers.
• Interfaces between layers / encapsulation of

layers.

• Maintenance knock-on effects (do changes of one

layer imply changes in other layers?)

3

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 13

FRAMEW ORKS

• A an application framework contains core parts for

an application.

• The framework serves as a starting-point for

application development.

• We add new things to the core.
• In case of OO software development, a framework

may contain a set of core classes.

• Naturally, the new system inherits the basic

architecture from the framework.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 14

Black-box vs. w hite-box fram ew orks

• In black-box frameworks, we just build things on

top of the framework without a need to see the implementation details in the framework.

• Easy to use
• In white-box frameworks, we typically im plement

new subclasses based on the classes in the framework.

• More flexible

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 15

Fram ew orks vs. com ponents

• When you use components, you typically write the

“main programs” yourself and call the services from the components.

• When you use frameworks, the framework

includes the “main programs” and you im plement the application-specific special services, which the framework calls.

• The so-called Hollywood principle: “Don’t call us,

we call you”.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 16

Fram ew orks – conclusions

• It is harder to write a good application framework

than it is to write a good application.

• However, if it succeeds, a lot of effort can be

saved in producing future applications based on the framework.

• In particular, it is possible to get the products out

earlier (a time-to-market improvement).