Software Design and

Architecture

Distributed
Architecture

Chapter 10 of Kia Qian Book

Overview
 In distributed architecture, components are presented on
different platforms and several components can cooperate with
one another over a communication network in order to
achieve a specific objective or goal.
 In this architecture, information processing is not confined to
a single machine rather it is distributed over several
independent computers.
 A distributed system can be demonstrated by the client-server
architecture which forms the base for multi-tier
architectures; alternatives are the broker architecture such as
CORBA, and the Service-Oriented Architecture (SOA).
Overview
 There are several technology frameworks to support distributed
architectures, including .NET, J2EE, CORBA, .NET Web
services, AXIS Java Web services, and Globus Grid services.
 Middleware is an infrastructure that appropriately supports
the development and execution of distributed applications. It
provides a buffer between the applications and the network.
 It sits in the middle of system and manages or supports the
different components of a distributed system. Examples are
transaction processing monitors, data convertors and
communication controllers etc.
Overview
The basis of a distributed architecture is its transparency,
reliability, and availability.
1 Access
Hides the way in which resources are accessed and the differences in data platform.
2 Location
Hides where resources are located.
3 Technology
Hides different technologies such as programming language and OS from user.
4 Migration / Relocation
Hide resources that may be moved to another location which are in use.
5 Replication
Hide resources that may be copied at several location.
6 Concurrency
Hide resources that may be shared with other users.
7 Failure
Hides failure and recovery of resources from user.
8 Persistence
Hides whether a resource ( software ) is in memory or disk
Overview

Advantages
 Resource sharing − Sharing of hardware and software resources.

 Openness − Flexibility of using hardware and software of different vendors.

 Concurrency − Concurrent processing to enhance performance.

 Scalability − Increased throughput by adding new resources.

 Fault tolerance − The ability to continue in operation after a fault has

occurred.

Disadvantages
 Complexity − They are more complex than centralized systems.

 Security − More susceptible to external attack.

 Manageability − More effort required for system management.

 Unpredictability − Unpredictable responses depending on the

system organization and network load.
Client-Server

• The client-server model is the most commonly distributed

system architecture.
• It is based on two communicating processes, usually running on
different processors, and thus decomposes a system into two
major subsystems: client and server.
• The first process, the client, issues a request to the second
process, the server.
• The server process receives the request (serving data from a
database, printing a document), carries it out, and sends a reply
to the client.
Client-Server
Client-Server
Thin-client model
 In thin-client model, all the application processing and data management is
carried by the server. The client is simply responsible for running the
presentation software.
 Used when legacy systems are migrated to client server architectures in
which 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.
Thick/Fat-client model
 In thick-client model, the server is only in charge for data management. The
software on the client implements the application logic and the interactions
with the system user.
 Most appropriate for new C/S systems where the capabilities of the client
system
are known in advance
 More complex than a thin client model especially for management. New
versions of the application have to be installed on all clients.
Client-Server
Advantages:
 Separation of responsibilities such as user interface presentation
and business logic processing.
 Reusability of server components.

Disadvantages:
 Security complications.
 Server availability and reliability.
 Testability and scalability.
 Fat clients with presentation and business logic together.
Multi-tiers
• Multi-tier architecture is a client–server architecture in which
the functions such as presentation, application processing,
and data management are physically separated.
• By separating an application into tiers, developers obtain the
option of changing or adding a specific layer, instead of
reworking the entire application.
• It provides a model by which developers can create flexible
and reusable applications.
Multi-tiers
Multi-tiers
Presentation Tier
Presentation layer is the topmost level of the application by which users can access
directly such as webpage or Operating System GUI (Graphical User interface).
The primary function of this layer is to translate the tasks and results to something
that user can understand. It communicates with other tiers so that it places the
results to the browser/client tier and all other tiers in the network.

Application Tier (Business Logic, Logic Tier, or Middle Tier)

Application tier coordinates the application, processes the commands, makes
logical decisions, evaluation, and performs calculations. It controls an
application’s functionality by performing detailed processing. It also moves and
processes data between the two surrounding layers.
Multi-tiers
Data Tier
In this layer, information is stored and retrieved from the database or
file system. The information is then passed back for processing and
then back to the user. It includes the data persistence mechanisms
(database servers, file shares, etc.) and provides API (Application
Programming Interface) to the application tier which provides
methods of managing the stored data.
Multi-tiers
Multi-tiers
Advantages
• Better performance than a thin-client approach and is simpler
to manage than a thick-client approach.
• Enhances the reusability and scalability − as demands increase,
extra servers can be added.
• Provides multi-threading support and also reduces network
traffic.
• Provides maintainability and flexibility

Disadvantages
• Unsatisfactory Testability due to lack of testing tools.
Broker Architectural Style
 Overview
 The broker architecture is a middleware architecture used in
distributed computing to coordinate and facilitate communication
between registered servers and clients.
 It can be used to structure distributed software systems with
decoupled components that interact by remote service
invocations.
 A broker component is responsible for coordinating
communication, such as forwarding requests, as well as for
transmitting results and exceptions.
 A broker can be either an invocation-oriented service, to which
clients send invocation requests for brokering, or a document or
message- oriented broker to which clients send a message (such as
an XML document).
 Client and the server never interact with each other directly.
 A broker system is also called the proxy-based system.
Broker Architectural Style
 Servers make their services available to their clients
by registering and publishing their interfaces with the
broker.
 Clients can request the services of servers from the
broker statically or dynamically by look-up.
 A broker component is responsible for coordinating
communications – brokering the service requests,
locating a proper server, forwarding and dispatching
requests, and sending responses or exceptions back
to clients.
 CORBA (Common Object Request Broker
Architecture) is a good implementation example of
the broker architecture.
Broker Architectural Style
 Client has a direct connection to its client-proxy and server
has direct connection to its server-proxy.
 The proxy talks to the mediator-broker.
Broker Architectural Style
Components:
 Broker
 Stub
 Skeleton
 Bridge
 Network
Broker Component
 Co-ordinates communications – passes on
requests and returns replies.
 The broker keeps all servers registration
information including their functionality and
services as well as location information.
 The broker provides APIs for clients to
request, servers to respond, registering or
unregistering server components, transferring
messages, and locating servers.
Stub Component
 Client-side proxy: It mediates between client and broker and
provides additional transparency between them.
 To the client, a remote object appears like a local one.
 The proxy hides the inter-process communication at protocol
level and performs marshalling of parameter values and
unmarshaling of results from the server.
 The stub is generated at the static compilation time and deployed
to the client side to be used as a proxy for the client.
Skeleton Component
 Server-side proxy: It is also statically generated by the
service interface compilation and then deployed to the
server side.
 It encapsulates low-level system-specific networking
functions like what client-proxy does and provides high-
level APIs to mediate between the server and the broker.
 It receives the requests, unpacks the requests, unmarshals
the method arguments, and calls the appropriate service.
 When it receives the result back from the server it also
marshals the result before sending it back to the client.
Bridges
 These optional components are used to hide
implementation details when two brokers
interoperate.
 It encapsulates underlying network detail
implementation and mediates different brokers
such as DCOM, .NET Remote and Java CORBA
brokers.
 They can take requests and parameters in one
format and translate them to another format.
 A bridge can connect two different networks based
on different communication protocols.
Network Component
 Network: The connections between the
components are the network with designated
protocol standards such as TCP/IP or SOAP.
 The request carries data in a format of message
document or method invocation.
Broker model
Service
1
2
1
reque Broker 3
Service
st 5 1
2
respo 4
nse
Service
3

Broker 2
Brokers with client-server proxy

Client Broker-1 Server

proxy proxy

Se r ver
bridges Broker -2

p ro xy

C lie nt

Broker -3 pr oxy
C lient

pr oxy

Server
proxy
Brokers with client-server proxy
Brokers with client-server proxy
Brokers with client-server proxy
Advantages
 Changeability and extensibility.
 Simplicity for clients to access server and server portability.
 Interoperability via broker bridges.
 Reusability.
 Feasibility of runtime changes of server components (add or
remove server components on the fly).
Disadvantages:
 Inefficiency due to the overhead of proxies
 Low fault-tolerance
 Difficulty in testing due to the amount of proxies
CORBA
Service-Oriented Architecture
(SOA)
 Overview
 A Service Oriented Architecture (SOA) starts with
a businesses process.
 A service is a business functionality that is well-defined, self-
contained, independent from other services, and published
and available to be used via a standard programming
interface.
 Software manages business processes through a SOA with
well-defined and standard interfaces that can build,
enhance, and expand their existing infrastructure more
flexible.
Service-Oriented Architecture
(SOA)
 SOA services can be extensively reused within a given domain or
product line, and even among legacy systems.
 Loose coupling of service–orientation provide great flexibility for
enterprises to make use of all available service recourses regardless
of platform and technology restrictions.
 The connections between services are conducted by common and
universal message oriented protocols such as the SOAP Web
service protocol, which can deliver requests and responses between
services loosely.
 A connection can be established statically or dynamically.
Service-Oriented Architecture
(SOA)
Service-Oriented Architecture
(SOA)
Features of SOA
 Distributed Deployment − Expose enterprise data and business logic as
loosely, coupled, discoverable, structured, standard-based, stateless units
of functionality called services.
 Composability − Assemble new processes from existing services that
are exposed at a desired granularity through well defined, published,
and standard complaint interfaces.
 Interoperability − Share capabilities and reuse shared services across a
network irrespective of underlying protocols or implementation
technology.
 Reusability − Choose a service provider and access to existing
resources exposed as services.
Service-Oriented Architecture
(SOA)
Advantages:
 Loose-coupling is the key attribute of SOA.
 Each service component is independent from other services due to the
stateless service feature.
 The implementation of a service will not affect the application of the service
as
long as the exposed interface is not changed.
 A client or any service can access other services regardless of their
platform, technology, vendors, or language implementations.
 Any service can be reused by any other service. Because clients of a
service only need to know its public interfaces, service composition and
integration become much easier.
 SOA based business application development comes much more efficient
in
term of time and cost.
 Loosely coupled services make themselves easy to scale.