Distributed Systems Architecture in Software Engineering Se11 12587

8/6/2019 Distributed Systems Architecture in Software Engineering Se11 12587

1/44

Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 1

Distributed Systems Architectures

Architectural design for software

that executes on more than one processor


2/44


Objectives

To explain the advantages and disadvantages of distributed systems architecturesTo describe different approaches to thedevelopment of client-server systemsTo explain the differences between client-server and distributed object architectures

To describe object request brokers and the principles underlying the CORBA standards


3/44


Topics covered

Multiprocessor architecturesClient-server architectures

Distributed object architecturesCORBA


4/44


Distributed systems

Virtually all large computer-based systems arenow distributed systemsInformation processing is distributed over severalcomputers rather than confined to a singlemachineDistributed software engineering is now very

important


5/44


System types

Personal systems that are not distributed and thatare designed to run on a personal computer or workstation.

Embedded systems that run on a single processor or on an integrated group of processors.

Distributed systems where the system softwareruns on a loosely integrated group of cooperating

processors linked by a network.


6/44


Distributed system characteristics

Resource sharingOpenness

ConcurrencyScalabilityFault toleranceTransparency


7/44


Distributed system disadvantages

ComplexitySecurity

ManageabilityUnpredictability


8/44

Issues in distributed system design

Design issue Description Resourceidentification

The resources in a distributed system are spread across differentcomputers and a naming scheme has to be devised so that users candiscover and refer to the resources that they need. An example of such a naming scheme is the URL (Uniform Resource Locator) thatis used to identify WWW pages. If a meaningful and universallyunderstood identification scheme is not used then many of theseresources will be inaccessible to system users.

Communications The universal availability of the Internet and the efficientimplementation of Internet TCP/IP communication protocols meansthat, for most distributed systems, these are the most effective way

for the computers to communicate. However, where there arespecific requirements for performance, reliability etc. alternativeapproaches to communications may be used.

Quality of service The quality of service offered by a system reflects its performance,availability and reliability. It is affected by a number of factors suchas the allocation of processes to processes in the system, thedistribution of resources across the system, the network and thesystem hardware and the adaptability of the system.

Softwarearchitectures

The software architecture describes how the applicationfunctionality is distributed over a number of logical components andhow these components are distributed across processors. Choosingthe right architecture for an application is essential to achieve thedesired quality of service.


9/44


Distributed systems archiectures

Client-server architecturesDistributed services which are called on by clients. Servers that

provide services are treated differently from clients that use

servicesDistributed object architectures

No distinction between clients and servers. Any object on thesystem may provide and use services from other objects


10/44


Middleware

Software that manages and supports the differentcomponents of a distributed system. In essence, itsits in the middle of the systemMiddleware is usually off-the-shelf rather thanspecially written softwareExamples

Transaction processing monitorsData convertorsCommunication controllers


11/44


Multiprocessor architectures

Simplest distributed system modelSystem composed of multiple processes whichmay (but need not) execute on different

processorsArchitectural model of many large real-timesystems

Distribution of process to processor may be pre-ordered or may be under the control of adespatcher


12/44


A multiprocessor traffic control system

Traffic lights

Lightcontrolprocess

Traffic light controlprocessor

Traffic flowprocessor

Operator consolesTraffic flow sensors

and cameras

Sensorprocessor

Sensorcontrolprocess

Displayprocess


13/44


Client-server architectures

The application is modelled as a set of servicesthat are provided by servers and a set of clientsthat use these servicesClients know of servers but servers need notknow of clientsClients and servers are logical processes

The mapping of processors to processes is notnecessarily 1 : 1


14/44


A client-server system

s1

s2 s3

s4c1

c2 c3 c4

c5

c6c7 c8

c9

c10

c11

c12

Client process

Server process


15/44


Computers in a C/S network

Network

SC1SC2

CC1 CC2 CC3

CC5 CC6CC4

Servercomputer

Clientcomputer

s1, s2 s3, s4

c5, c6, c7

c1 c2 c3, c4

c8, c9 c10, c11, c12


16/44


Layered application architecture

Presentation layer Concerned with presenting the results of a computation tosystem users and with collecting user inputs

Application processing layer Concerned with providing application specific functionality e.g.,in a banking system, banking functions such as open account,close account, etc.

Data management layer Concerned with managing the system databases


17/44


Application layers

Presentation layer

Application processinglayer

Data managementlayer


18/44


Thin and fat clientsT hin-client model

In a thin-client model, all of the application processing and datamanagement is carried out on the server. The client is simply

responsible for running the presentation software.F at-client model

In this model, the server is only responsible for datamanagement. The software on the client implements theapplication logic and the interactions with the system user.


19/44


Thin and fat clients

Thin-clientmodel

Fat-clientmodel Client

Client

Server

Data managementApplicationprocessing

Presentation

Server

Data

management

PresentationApplication processing


20/44


Thin client model

Used when legacy systems are migrated to clientserver architectures.

The legacy system acts as a server in its own right with a

graphical interface implemented on a client

A major disadvantage is that it places a heavy processing load on both the server and thenetwork


21/44


Fat client model

More processing is delegated to the client as theapplication processing is locally executedMost suitable for new C/S systems where thecapabilities of the client system are known inadvanceMore complex than a thin client model especially

for management. New versions of the applicationhave to be installed on all clients


22/44


A client-server ATM system

Account server

Customeraccountdatabase

Tele-processing

monitor

ATM

ATM

ATM

ATM


23/44


Three-tier architectures

In a three-tier architecture, each of theapplication architecture layers may execute on aseparate processor Allows for better performance than a thin-clientapproach and is simpler to manage than a fat-client approach

A more scalable architecture - as demandsincrease, extra servers can be added


24/44


A 3-tier C/S architecture

Client

Server

Datamanagement

PresentationServer

Applicationprocessing


25/44


An internet banking system

Database server

Customeraccountdatabase

Web server

Client

Client

Client

Client

Account serviceprovision

SQLSQL query

HTTP interaction


26/44


Use of C/S architecturesArchitect re Appl icatio sTwo-tier C/Sarchitecture withthin clients

egacy system applications where separating application processing and data management is impracticalComputationally-intensive applications such as compilers withlittle or no data management

ata-intensive applications (browsing and querying) with littleor no application processing.Two-tier C/Sarchitecture withfat clients

pplications where application processing is provided byC TS (e.g. icrosoft Excel) on the client

pplications where computationally-intensive processing of data (e.g. data visualisation) is required.

pplications with relatively stable end-user functionality usedin an environment with well-established system management

Three-tier or multi-tier C/Sarchitecture

arge scale applications with hundreds or thousands of clients pplications where both the data and the application are

volatile. pplications where data from multiple sources are integrated


27/44


Distributed object architectures

There is no distinction in a distributed objectarchitectures between clients and serversEach distributable entity is an object that providesservices to other objects and receives servicesfrom other objectsObject communication is through a middleware

system called an object request broker (software bus)However, more complex to design than C/Ssystems


28/44


Distributed object architecture

Software bus

o1 o2 o3 o4

o5 o6

S (o1) S (o2) S (o3) S (o4)

S (o5) S (o6)


29/44


Advantages of distributed object architecture

It allows the system designer to delay decisionson where and how services should be providedIt is a very open system architecture that allowsnew resources to be added to it as requiredThe system is flexible and scaleableIt is possible to reconfigure the system

dynamically with objects migrating across thenetwork as required


30/44


Uses of distributed object architecture

As a logical model that allows you to structureand organise the system. In this case, you think about how to provide application functionalitysolely in terms of services and combinations of servicesAs a flexible approach to the implementation of client-server systems. The logical model of thesystem is a client-server model but both clientsand servers are realised as distributed objectscommunicating through a software bus


31/44


A data mining system

Database 1

Database 2

Database 3

Integrator 1

Integrator 2

Visualiser

Display

Report gen.


32/44


Data mining system

The logical model of the system is not one of service provision where there are distinguisheddata management servicesIt allows the number of databases that areaccessed to be increased without disrupting thesystem

It allows new types of relationship to be mined byadding new integrator objects


33/44


CORBA

CORBA is an international standard for an ObjectRequest Broker - middleware to managecommunications between distributed objectsSeveral implementation of CORBA are availableDCOM is an alternative approach by Microsoft toobject request brokers

CORBA has been defined by the ObjectManagement Group


34/44


Application structure

Application objectsStandard objects, defined by the OMG, for aspecific domain e.g. insuranceFundamental CORBA services such as directoriesand security managementHorizontal (i.e. cutting across applications)

facilities such as user interface facilities


35/44


CORBA application structure

CORBA services

Object request broker

Domainfacilities

HorizontalCORBA facilities

Applicationobjects


36/44


CORBA standards

An object model for application objectsA CORBA object is an encapsulation of state with a well-defined, language-neutral interface defined in an IDL (interfacedefinition language)

An object request broker that manages requestsfor object servicesA set of general object services of use to many

distributed applicationsA set of common components built on top of these services


37/44


CORBA objects

CORBA objects are comparable, in principle, toobjects in C++ and JavaThey MUST have a separate interface definitionthat is expressed using a common language (IDL)similar to C++There is a mapping from this IDL to

programming languages (C++, Java, etc.)Therefore, objects written in different languagescan communicate with each other


38/44


Object request broker (ORB)

The ORB handles object communications. Itknows of all objects in the system and their interfacesUsing an ORB, the calling object binds an IDLstub that defines the interface of the called objectCalling this stub results in calls to the ORB which

then calls the required object through a publishedIDL skeleton that links the interface to the serviceimplementation


39/44


ORB-based object communications

o1 o2

S (o1) S (o2)

IDLstub

IDLskeleton

Object Request Broker


40/44


Inter-ORB communications

ORBs are not usually separate programs but are aset of objects in a library that are linked with anapplication when it is developedORBs handle communications between objectsexecuting on the sane machineSeveral ORBS may be available and each

computer in a distributed system will have itsown ORBInter-ORB communications are used for distributed object calls


41/44


Inter-ORB communications

o1 o2

S (o1) S (o2)

IDL IDL


o3 o4

S (o3) S (o4)

IDL IDL


Network


42/44


CORBA services

Naming and trading servicesThese allow objects to discover and refer to other objects on thenetwork

Notification servicesThese allow objects to notify other objects that an event hasoccurred

Transaction services

These support atomic transactions and rollback on failure


43/44


Almost all new large systems are distributedsystemsDistributed systems support resource sharing,openness, concurrency, scalability, fault toleranceand transparencyClient-server architectures involve services being

delivered by servers to programs operating onclientsUser interface software always runs on the clientand data management on the server

Key points


44/44


Key points

In a distributed object architecture, there is nodistinction between clients and serversDistributed object systems require middleware tohandle object communicationsThe CORBA standards are a set of middlewarestandards that support distributed object

architectures

Documents

Distributed Systems Architecture in Software Engineering Se11 12587