Chapter 10

DISTRIBUTED ARCHITECTURE
 Objectives
 Introduce the client-server and multi-tier
architectures
 Introduce the broker architectures
 Introduce the service-oriented architecture
 Agenda
• Distributed System Introduction
• Client-Server architecture
• Multi-Tiers architecture
• Broker architecture
• Service oriented architecture
 Introduction
• A distributed system
– a collection of computational and storage devices
connected
• through a communications network.
– data, software, and users are distributed.
– sub-systems or components communicate with each
other by
• Message Passing
• Remote procedure call
• Remote method invocation, etc.
– 2 important issues for designing a distributed system
• Network Topology
– The way in which entities are organized to form a connected network.
• Communications Mode
– The method by which components communicate with each other.
• Can be modeled by
– The client-server architecture
– and this forms the basis for multi-tier architectures;
– The broker architecture
• Common Object Request Broker Architecture (CORBA)
– Service-Oriented Architecture (SOA).
– Web services
– Grid services.
• The important features are
– service location transparency
– services reliability
– services availability.
• There are several technology frameworks to
support distributed architectures
– .NET
– J2EE
– CORBA
– .NET Web services
– AXIS Java Web services
– GloBus Grid services.
Client-Server
 Client-Server
• Benefits
– Separation of responsibilities such as user interface
presentation and business logic processing.
– Reusability of server components.

• Limitations
– Lack of heterogeneous infrastructure to deal with the
requirement changes.
– Security complications.
– Server availability and reliability.
– Testability and scalability.
– Fat clients with presentation and business logic together.
Multi-tiers
 Multi-tiers
• Benefits
– Enhancement reusability and scalability.
• Adding middle tier
– Have Portable design & Implementation
– Provide multi-threading supports for scalability.
– Reduce the traffic on the network
• Limitations
– Testability
• Lack of testing tools
– Server reliability and availability is more
critical issue.
 Broker Architectural Style
• A middleware architecture used in
distributed computing
– to coordinate and facilitate communication
between registered servers and clients.
 Broker Architectural Style
• A broker
– An invocation-oriented service
• clients send invocation requests for brokering
– A document or message- oriented broker
• clients send a message (such as an XML document).
• The most important quality attributes is
– Better decoupling between clients and servers
• clients and server components are decoupled through the
use of a broker.
• Called the proxy-based system.
 Broker Architectural Style
• Servers register and publish their interfaces with
the broker.
• Clients can look-up and request the services of
servers from the broker.
• A broker component is responsible for
coordinating communications
– Brokering the service requests
– Locating a proper server
– Forwarding and Dispatching requests
– Sending responses or exceptions back to clients.
Figure 10.3 Broker model
Service 1
2
1
request Broker 1 3
Service 2
5
response 4
Service 3

Broker 2
 Broker Architectural Style
• With the broker pattern, a distributed client can
access distributed services
– Simply by calling a remote method of a remote object
• just as if it were a local method call.
– The clients can dynamically invoke the remote
methods
• even if the interfaces of the remote objects are not available
at the compilation time
– Note: only need to obtain a reference to the
appropriate object, instead of writing detailed code for
protocol-oriented communication.
 Broker Architectural Style
• Similar to
– Remote Procedure Call (RPC) in Unix
distributed structured programming
– Remote Method Invocation (RMI) in Java
distributed object-oriented programming.
• CORBA (Common Object Request Broker
Architecture) is a good implementation example.
 Connected brokers with client-server proxy

Server
Client Broker-1
proxy proxy

Server
bridges Broker -2
proxy

Client
proxy
Client Broker -3
proxy

Server
proxy
Broker class diagram
Server registration
Client requests service
Broker forwards request
Broker with client-server proxy
• Decompose the broker architecture into 5 sub-
components:
– Broker:
• Co-ordinates communications
– passes on requests and returns replies.
• Keeps all servers registration information
– including their functionality and services as well as location
information.
• provides APIs for
– clients to request
– servers to respond
– registering or unregistering server components
– transferring messages
– locating servers
Broker with client-server proxy
– Stub (client-side proxy):
• Mediates between client and broker
• 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
– performs marshalling of parameter values
– Performs unmarshalling of results from the server.
• Is generated at the static compilation time and deployed to the
client side to be used as a proxy for the client.
Broker with client-server proxy
– Skeleton (server-side proxy):
• Is statically generated by the service interface compilation and
then deployed to the server side.
• Encapsulates low-level system-specific networking functions
• Provides high-level APIs to mediate between the server and the
broker.
• Receives the requests, unpacks the requests, unmarshals the
method arguments, and calls the appropriate service.
• Marshals the result before sending it back to the client.
Broker with client-server proxy
– Bridges:
• optional components are used to hide implementation details when two
brokers interoperate.
• Encapsulates underlying network detail implementation and mediates
different brokers such as
– DCOM.
– .NET Remote brokers.
– Java CORBA brokers.
• Take requests and parameters in one format and translate them to another
format.
• Can connect two different networks based on different communication
protocols.
– Network: The connections between the components are the
network with designated protocol standards such as
• TCP/IP – Internet protocol
• SOAP – Simple Object Access Protocol.
Broker with client-server proxy
 Broker with client-server proxy
• Benefits
– Server component implementation and location transparency.
– 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.

• Limitations
– Inefficiency
• due to the overhead of proxies
– Low fault-tolerance
– Difficulty in testing
• due to the amount of proxies
 Service-Oriented Architecture
(SOA)
• A service is a business functionality
– Well-defined
– Self-contained
– Independent from other services,
– published and available
• to be used via a standard programming interface.
• Software manages business processes through
a SOA
– with well-defined and standard interfaces
• can build, enhance, and expand their existing infrastructure
more flexible.
Service-Oriented Architecture
(SOA)
• SOA services can be
– Extensively reused within
• a given domain
• 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
• SOAP Web service protocol
– which can deliver requests and responses between services loosely.
– Can be established statically or dynamically.
Service-Oriented Architecture
(SOA)
Service-Oriented Architecture
(SOA)
Service-Oriented Architecture
(SOA)
• Benefits:
– Loosely-coupled connection:
• Loose-coupling is the key attribute of SOA.
– Each service component is independent from
other services
• Due to the stateless service feature.
– Much easier to evolve and update.
• The implementation of a service will not affect the
application of the service
– as long as the exposed interface is not changed.
Service-Oriented Architecture
(SOA)
• Benefits:
– Interoperability: Technically any client or any service
can access other services regardless of their
• Platform
• Technology
• Vendors
• Language implementations.
– Reusability: 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.
– More efficient in term of time and cost
Service-Oriented Architecture
(SOA)
• Benefits:
– Scalability: Loosely coupled services make
themselves easy to scale.
• The coarse-grained, document-oriented, and
asynchronous service features enhance the
attribute.