Lesson 02 -Distributed Systems Architectures

2.0 Introduction

In the second week of Advanced Software Engineering course, you will learn different
distributed architectures available and when those are used in the computer systems.
Also we will discuss distributed object architecture, service oriented architecture etc
in detail with practical applications.

Learning outcomes

After completing this lesson, you would be able to describe the advantages,
disadvantages, usage of different distributed architectures. Further you will be able
to apply the concepts of distributed architectures in providing software solutions in
different environments.

Further, you would be able to,

• Explain the advantages and limitations of different distributed systems
architectures
• Discuss client-server and distributed object architectures
• Describe object request brokers and the principles underlying the CORBA
standards
• Introduce peer-to-peer and service-oriented architectures as new models of
distributed computing.
• Apply the concepts of distributed architectures in developing software solutions
for practical problems

Almost all the organizations use information system to conduct day-to-day business
activities. Earlier days, most of information systems were deployed in a single
computer called as Legacy or centralized systems. Now a day, it has been changed and
almost all the systems use distributed architecture in information system deployment.

For example, if you think about a withdrawing a cash from a ATM, it involves many
distributed servers, components, modules and objects where, main customer data will
be available in clustered database, ATM host application will be in a separate server

Distributed System Architecture Page 1 of 15

and main banking application will be available in a separate server. When you access,
a simple functionality though ATM, it invokes any processers across the network,
deployed in many servers.

It can be seen, that due to various reasons, distributed computer systems are
becoming popular than legacy systems. This provides facility to jointly work all
computer system to perform a single business function, where proper coordination is
required.

If we take modern e-commerce site, which enables you to purchase products and
deliver goods to your doorsteps can be taken as another example for distributed
system architecture. Can you imagine why it can be considered as a distributed
system? It involves many computers together in order to presume a single functionality
which is “Buying a good”. The system allows users to check availability of goods
connecting and retrieving inventory system, accepting orders in the e-commerce site
itself, performing payments by connecting banking systems, sending confirmation via
e-mail server, and finally it connects to courier service system to inform about your
order and facilitates the delivery.

With above examples, you can understand how distributed system architecture exists
in real world and the importance of considering such architecture into you software
engineering, especially in architectural design phase.

Advantages of Distributed Systems

• Resource sharing
Distributed systems allows sharing of hardware and software resources such as
printers, files, processers, computing power that are associated with computers
on the network. You can find some courier systems are allowing functionality to
other e-commerce web applications integrate so that Courier Company can
focus on their business while others can access courier service and place orders
which enables them to improve sales while reducing cost .

Distributed System Architecture Page 2 of 15

 • Openness
Distributed systems are normally open systems which allow use of equipment
and software from different vendors. You can find that open protocols are being
used in connecting heterogeneous systems into distributed systems. You will find
many e-commerce web applications are integrated using SOAP protocol in order
to access and share web services between those applications. So that it can be
connected to any system easily.

• Concurrency
In distributed environment several processors can be operated simultaneously
on separate computers in the network. As many processors running parallel you
can experience concurrent processing to enhance performance of the business
functions. When you are placing an order in an e-commerce web site, while
payment is being processed, application can connect to courier service and
place the delivery order which enhance the performance.

• Scalability
As the distributed nature of the architecture you can easily add new resource
such as hardware, software, services which will increase overall throughput.

• Fault tolerance
Since the availability of several computers in the network which as integrated as
distributed system, replication of information and software can be done so that
systems can be tolerant for some hardware and software failures.

So far we discussed the beauty and the power of distributed systems but we can find
some disadvantages also in this system which are given below,

• Complexity
Typically, distributed systems are more complex than centralised systems. It
involves in connecting heterogeneous systems together using different protocols
through computer network. Such system’s performance may depend on speed of
each processors, network bandwidth and throughput.

Distributed System Architecture Page 3 of 15

• Security
More susceptible to external attack as it connects though computer network and
typically connects using standard protocols so that the system is vulnerable for
network attacks such as denial of service attacks.

• Manageability
More effort required for system management as the computers in the
distributed environment will have many types of operating systems, versions,
patch levels etc. Fault in one may lead to many or unknown exception. Also you
need to monitor and manage many systems in distributed architecture where as
traditional systems are centralized so that no need to have many skills to
manage such systems.

• Unpredictability
Unpredictable responses depending on the overall load in the system, system
organisation and network load. As all of these may change over a short period,
response time to user may vary dramatically from one request to another.

You need to design your systems in the distributed architecture for better
performance, minimise risks and problems. In order to so, you need to understand how
distributed architecture works, their advantages and disadvantages. Now we are going
to learn about two generic distributed architectures such as,
I. Client server architecture
You can find distributed services are available in servers which are called on by
clients. Servers that provide services are treated differently from clients that
use services.
For example, web pages are stored in Web server and through the http server,
clients or browser can make http service request to get Web pages.

II. Distributed object architecture

In this environment we will not find any distinction between clients and servers.
Any object on the system may provide and use services from other objects. The
components in a distributed system may be implemented in different
programming languages and may execute on completely different types of
Distributed System Architecture Page 4 of 15
 processors. Also model of data, information representation and exchange,
protocols for communication may be different. In order to communicate and
exchange message between each of distributed system, separate software
called middleware is needed. Middleware is general-purpose that are available
to support distributed computing and typically bought off-the-shelf rather than
written especially by developers.
Typically distributed systems are developed using object oriented approach and
those are loosely couple, independent parts, and each of which may interact
with users or with other parts of the system.

Now let’s discuss few distributed architectures available.

2.1 Multiprocessor architectures

Multiprocessor architecture is the simplest distributed system model where the system
composed of multiple processes which may (but need not) execute on different
processors. This is the architectural model of many large real-time systems. We can
find that the distribution of process to processor may be pre-ordered or may be under
the control of a dispatcher. For example, consider an e-commerce based order
processing system, which has been integrated with suppliers of goods, courier to
deliver goods, payment gateways to process payments etc. In this example, different
services are installed in different servers, in order to provide business functionality.

Figure 2.1 - multiprocessor traffic control system

Distributed System Architecture Page 5 of 15

A multiprocessor traffic control system is given in the figure 2.1 where you can see
there three servers are available to process different tasks. The sensor processor is
connected with sensors and processing of sensors will be done in that server. You can
find light control process is controlled by Traffic light control processor and Traffic
Flow processor does the display process. In distributed architecture preset server
processors are installed in each of these three servers.

2.2 Client-server architectures

When we consider client-server architecture the application is modelled as a set of
services that are provided by servers and a set of clients that use these services. In
order to access service offered by server, clients should know the server details such
as location, protocol, ports etc in order to communicate but servers need not know of
clients.
• In this architecture clients and servers are logical processes where one
distributed computer can be a client for one service where as for some other
server same computer can be a server to offer service.
• There is no need to map processors to processes where one client can access
many servers and a given server will be serviced for many servers.

Figure 2.2 – client-server system

Clients and servers are separate processors as shown in figure 2.2 which is a logical
model of distributed client-server architecture. Each of those servers processor can
run on a single server so that there is no need to have 1:1 mapping between

Distributed System Architecture Page 6 of 15

 processes and processors in the system. The figure 2.3 shows the physical
architecture with six client computers and two server computers.

Figure 2.3 - Computers in a C/S network

The design of client-server systems should reflect the logical structure of the
application being developed and a way to look at the logical application structure is
shown in figure 2.4. According to the figure, application has been structured into 3
layers namely presentation layer, business layer and data management layer where
each of these layers has separate duties to perform.

Figure 2.4 - Layered application architecture

Distributed System Architecture Page 7 of 15

Table 2.1 Summary of responsibility of each layer
Layer Responsibility
Presentation layer Concerned with presenting the results of a
computation to system 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.

Two-tier client server architecture is the simplest client-server architecture which can
be have two forms as given in figure 2.5

Figure 2.5- thin and fat clients

Thin-client model
In a thin-client model, all of the application processing and data management is
carried out on the server. The client is simply responsible for running the
presentation software. Most of the time, we can see this architecture being
used when legacy systems are migrated to client server 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 the network.

Distributed System Architecture Page 8 of 15

Fat-client model
• In this model, the server is only responsible for data management. The
software on the client implements the application logic and the interactions
with the system user. Applications developed using C, C++, VB, Java Swings
are some examples where more processing is delegated to the client as the
application processing is locally executed.
• Most suitable for new Client-Server systems where the capabilities of the
client system are known in advance and most of the processing are done in
client PC.
• You can find more complex than a thin client model especially for
management where if you are having a branch network in different
geographical location, you will find difficulty as the new versions of the
application have to be installed on all clients.

You may remember that we discussed about 3 layers where in client server
architecture two tires are mapped into ether into the server or in the client. This can
be the major disadvantage of client-server architecture where there is a need to have
3-tired architecture which is given in figure 2.6

Figure 2.6 - 3-tired architecture

Three-tier architectures

For example, if we consider Internet banking application, given in figure 2.7, where all
processing are happening in side the server and client simply uses Web browser.
• In three-tier architecture, each of the application architecture layers may
execute on a separate processor.
• Allows for better performance than a thin-client approach as business logic are
executed in a high power server.
Distributed System Architecture Page 9 of 15
 • It is simpler to manage than a fat-client approach as you can maintain all your
application components in single location than in each client machine.
• A more scalable architecture - as demands increase, extra servers can be added.
• Web server contains the application potion and database contains the data
related to the application. Sometimes we can find application logic also build
into database where such systems are developed using stored procedures to
write the business logic.

Figure 2.7- 3 tire architecture in Internet Banking Application

Table 2.2 Use of Client-Server architectures
Architecture Applications
Two-tier C/S Legacy system applications where separating application
architecture with processing and data management is impractical.
thin clients Computationally-intensive applications such as compilers with
little or no data management.
Data-intensive applications (browsing and querying) with little or
no application processing.
Two-tier C/S Applications where application processing is provided by off-the-
architecture with
shelf software (e.g. Microsoft Excel) on the client.
fat clients
Applications where computationally-intensive processing of data
(e.g. data visualization) is required.
Applications with relatively stable end-user functionality used in
an environment with well-established system management.
Three-tier or Large scale applications with hundreds or thousands of clients
Distributed System Architecture Page 10 of 15
multi-tier C/S Applications where both the data and the application are volatile.
architecture
Applications where data from multiple sources are integrated.

So far we discussed client-server and 3 tires architectures and how those are used in
different applications. In this architecture you can find clients and servers where
clients retrieve the service offered by servers. Now, we are going to discuss another
architecture called distributed object architecture where distinction between client
and server are removed.

2.3 Distributed object architecture

In a distributed object architecture (figure 2.8), the fundamental system components
are objects that provide an interface to set of services that they provide. Other
objects call on these services with no logical distinction between a client and a server.
Objects may be distributed across a number of computers on a network and
communicate through a middleware. The middleware is called as the object request
broker and it provides a seamless interface between objects.

Figure 2.8 – Object request broker

Distributed System Architecture Page 11 of 15

Advantages of distributed object model

• It allows the system designer to delay decisions on where and how services
should be provided so that distinction between fat and thin client model
become inapplicable because no need to decide in advance where client
application logic object objects are located.

• It is a very open system architecture that allows new resources to be added

to it as required. Objects are communicated using standard protocols so that
easily new objects can be added and provide service. So that this
architecture provides the system flexibility and scalability.

• It is possible to reconfigure the system dynamically with objects migrating

across the network as required. A service-providing object can migrate to
the same processor as the service-requesting objects, which helps to
improve the performance of the system.
CORBA

Figure 2.9 – The structure of a CORBA based distributed applications

Distributed System Architecture Page 12 of 15

 Common Object Request Broker Architecture (CORBA) is practical implementation
of object broker architecture and following are some of characteristics of CORBA.
• CORBA is an international standard for an Object Request Broker -
middleware to manage communications between distributed objects.
• Middleware for distributed computing is required at 2 levels:
• At the logical communication level, the middleware allows objects on
different computers to exchange data and control information;
• At the component level, the middleware provides a basis for developing
compatible components. CORBA component standards have been defined.

When we consider application which users CORBA, we can find following

characteristics of them,
• Application object are standard objects, defined by the OMG, for a specific
domain e.g. insurance.
• Application are fundamental CORBA services such as directories and security
management.
• Horizontal (i.e. cutting across applications) facilities such as user interface
facilities.
Applications use CORBA objects and those objects are,
• CORBA objects are comparable, in principle, to objects in C++ and Java.
• They MUST have a separate interface definition that 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 languages can communicate with each other. In
order to communicate each other Object Request Broker handles the communication
between objects and it knows all objects in the system and their interfaces. Using an
ORB, the calling object binds an IDL stub that defines the interface of the called
object. Calling this stub results in calls to the ORB which then calls the required object
through a published IDL skeleton that links the interface to the service
implementation.

Distributed System Architecture Page 13 of 15

 Figure 2.10 – ORB-based object communications

CORBA services
• Naming and trading services
• These allow objects to discover and refer to other objects on the network.
• Notification services
• These allow objects to notify other objects that an event has occurred.
• Transaction services
• These support atomic transactions and rollback on failure.

Web services

In addition to object broker model, Service Oriented Architecture (SOA) also becoming
industry standard for distributed computing. Before we discuss about SOA, we need to
understand a term of service, which is the foundation for SOA.

A generic service
An act or performance offered by one party to another. Although the process may be
tied to a physical product, the performance is essentially intangible and does not
normally result in ownership of any of the factors of production. Usually service
provision is therefore independent of the application using the service.

Distributed System Architecture Page 14 of 15

 Figure 2.11 – Web Service architecture
As you can see in figure 2.11, SOA is based on three components namely, Service
Registry, Service Requestor and Service Provider. Beauty of this architecture is that
provider is independent where provider registers with the services offered with the
service registry. The requester will inquire available services with the service registry
and run-time bind the available services.

There are services standards available in order to publish as well as access. Basically
services are based on agreed; XML-based standards so can be provided on any platform
and written in any programming language. Following standers are used in SOA.
Key standards for Web Services are,
• SOAP - Simple Object Access Protocol;
• WSDL - Web Services Description Language;
• UDDI - Universal Description, Discovery and Integration.

Summary
In this chapter we discussed about distributed systems and how it supports resource
sharing, openness, concurrency, scalability, fault tolerance and transparency. We
started the discussion with understanding client-server architectures and then you
learnt 3-tire architecture with some practical examples.
Also in this session you had opportunity learn about distributed object systems
where requires middleware to handle object communications and to add and remove
system objects.
Finally we discussed about service-oriented systems which are created by linking
software services provided by different service suppliers.

Distributed System Architecture Page 15 of 15