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

MORE ON ARCHI TECTURES Monolithic Architecture / 1 • The main reasons for using an architecture are • Monolithic systems are not divided into maintainability and performance . independent parts. They typically run on a single • We want to structure the software into reasonably processing unit (computer). independent parts for easy maintenance. • There was a time when computers typically did not • We want to be able to increase performance if talk that much with each other. needed. A suitable architecture allows us to • This made monolithic systems more or less the increase processing power where it is needed. only choice. • A good architect knows different architectural • Lack of complicated communication speeds up styles (which are like design patterns) and understands the technology and application to processing, but it is hard to improve performance identify the potential performance bottlenecks. in any other way than increasing processing power • Let’s discuss some models and history… for that one computer. 4.10.2004 Software Engineering 2004 1 4.10.2004 Software Engineering 2004 2 Jyrki Nummenmaa Jyrki Nummenmaa Monolithic Architecture / 2 Client/ Server Architecture / 1 • Typically and historically, the monolithic system • When terminals were replaced by microcom puters, talks with fairly dumb clients (like terminals). 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 3 4.10.2004 Software Engineering 2004 4 Jyrki Nummenmaa Jyrki Nummenmaa Client/ Server Architecture / 2 Three-tier architecture / 1 • Fat clients contained more functionalities and data. • The server side was still monolithic in a basic C/ S architecture, which created a performance • Thin clients contained more or less terminal-type bottleneck. functionalities. • As the applications usually had a database, • Client/ Server (C/ S) computing was the first step multiplying the database is hard in many cases, towards multi-tier (multi-layer) architectures on which makes it hard to multiply the servers. processing unit level. • However, by having a separate database server it • It allowed a better division of work. was possible to have multiple application servers. • However, fat clients also needed maintenance and installations to keep up with current versions. APPLI CATI ON SERVERS DATABASE SERVER 4.10.2004 Software Engineering 2004 5 4.10.2004 Software Engineering 2004 6 Jyrki Nummenmaa Jyrki Nummenmaa 1

Using m ultiple database Three-tier architecture / 2 servers • The database server only runs the database, as • If data is replicated to several databases, updating having several of them is difficult. them correctly is a problem – in particular if the replicas must be consistent. • If there are database server performance problems, get a more powerful server! • If data is replicated, then it should be easily found somehow. Like assume a library keeps books with • You may use several servers for backup to always title starting with ”A” on one data server, ”B” on a have a backup server on-line ready for action. second server, and so on. • The three-tier architecture is fairly common. • Queries based on other selection criteria or data • To make client installation easier, it is possible to from several servers are problematic. 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). Z A B C . . . 4.10.2004 Software Engineering 2004 7 4.10.2004 Software Engineering 2004 8 Jyrki Nummenmaa Jyrki Nummenmaa Processing Unit vs. Softw are Peer-To-Peer Com puting Architecture • The above processing architectures have assumed • If an architecture divides processing into different that we have separate servers and clients and the types of processing units (clients and various configuration of the system is controlled in a servers), then of course this division im plies also a centralised fashion. division of the software functionalities. • In Peer-To-Peer computing, each computer (node) is • However, there is also architectural structural equal, and the nodes may ask each other for decisions, which do not need to be based on the processing services. processing unit architecture. • 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 9 4.10.2004 Software Engineering 2004 10 Jyrki Nummenmaa Jyrki Nummenmaa I ssues w ith m ulti-layer Dividing the tiers architectures • As an example, we may divide the • Number of layers Client tier application server functionalities into • Error/ exception management (what to pass on, domain tier and control (application) Application tier what to process) tier . Typically it is the domain tier, which talks to the database. • Callback from lower layers. Domain tier • It makes a big difference, how the • Interfaces between layers / encapsulation of layers talk with each other. Database tier layers. • It is typically seen as a good thing, if • Maintenance knock-on effects (do changes of one the layers call each other in top-down fashion and the calls do not pass-by layer imply changes in other layers?) layers (e.g. application layer does not call database layer). - Makes maintenance easier. - Performance may suffer. 4.10.2004 Software Engineering 2004 11 4.10.2004 Software Engineering 2004 12 Jyrki Nummenmaa Jyrki Nummenmaa 2

Black-box vs. w hite-box FRAMEW ORKS fram ew orks • A an application framework contains core parts for • In black-box frameworks, we just build things on an application. top of the framework without a need to see the implementation details in the framework. • The framework serves as a starting-point for - Easy to use application development. • In white-box frameworks, we typically im plement • We add new things to the core. new subclasses based on the classes in the • In case of OO software development, a framework framework. may contain a set of core classes. - More flexible • Naturally, the new system inherits the basic architecture from the framework. 4.10.2004 Software Engineering 2004 13 4.10.2004 Software Engineering 2004 14 Jyrki Nummenmaa Jyrki Nummenmaa Fram ew orks vs. com ponents Fram ew orks – conclusions • When you use components, you typically write the • It is harder to write a good application framework “main programs” yourself and call the services than it is to write a good application. from the components. • However, if it succeeds, a lot of effort can be • When you use frameworks, the framework saved in producing future applications based on includes the “main programs” and you im plement the framework. the application-specific special services, which the • In particular, it is possible to get the products out framework calls. earlier (a time-to-market improvement). - The so-called Hollywood principle : “Don’t call us, we call you”. 4.10.2004 Software Engineering 2004 15 4.10.2004 Software Engineering 2004 16 Jyrki Nummenmaa Jyrki Nummenmaa 3