Distributed Architecture

Post on 13-Jan-2016

33 views 0 download

Tags:

description

Distributed Architecture. Objective. Introduce Distributed Arch. Client/Server Multi-tier Broker Service Oriented Discuss Pros and Cons. Introduction. Distributed System Computers connected through network Components are distributed Two important issues: - PowerPoint PPT Presentation

transcript

Distributed Architecture

ObjectiveIntroduce Distributed Arch.

Client/ServerMulti-tierBrokerService Oriented

Discuss Pros and Cons

IntroductionDistributed System

Computers connected through network

Components are distributedTwo important issues:

Topology: the way components connectedMode: the way they communicate with each other

Many models availableEach has pros and cons

Client/ServerThe most commonly distributed system architectureIt has two communicating processes

Running on different processorsSo, it is decomposed into two major subsystems: Client Server

Server process receives the request, carries it out, and sends a reply to the client

Client/ServerTwo tier: client and server

user interfacebusiness rulesdata access

user interface business rulesdata access

Data ServerFat client

net

net

Front-end tier focuses on the user interaction

Back-end tier focuses on business logic and database management

Client/Server Summary

Advantages:Responsibility separation such as user interface presentation and business logic processing Reusability of server components

Disadvantages:Lack of heterogeneous infrastructure to deal with the requirement changesSecurity complicationsServer availability and reliabilityTestability and scalability

Multi-tierAt least 3 tiers

Front-end tier - User interface presentation tierMiddle-end tier - Business logic tier Manages business logic and execution

Back-end tier - DB management tier Handles database

Multi-tier

thin client

user interface

net

application server

net

business rule data access

data server

front-end tier back-end tiermiddleware tier

Multi-tierAdvantages of multi-tier over two-tier architecture.

Enhanced reusability and scalability by adding the middle tierMiddle layer is easy to changeHave portable and nonproprietary design and implementationMiddle layer can provide multi-threading supportReduces traffic on the network

ConsDifficulty in testing due to lack of testing toolsAdding multiple servers in the system makes the server reliability and

availability even more critical

The Broker architectural patternTransparently distribute aspects of the software system to different nodes

An object can call methods of another object without knowing that this object is remotely located.CORBA is a well-known open standard that allows you to build this kind of architecture.

Example of a Broker system

Broker StyleTypical middleware arch. from mid 1990’sKey Idea:

Service provider register services through brokerClients discover services through brokerClients submit requests to brokerBroker massages requests from clients and relay results from service provider

Typical examples:CORBA, RPC, and RMI

Broker ArchitectureSub-components include

Broker – provide service registrationStub (client-side proxy) – provide “stub” version of remote services, responsible for massaging messagesSkeleton (server-side proxy) – encapsulates lower network details, dispatch requests to local service objectsBridges (optional) – for interaction with brokersNetwork – for interaction with brokers

Broker ArchitectureBroker

It coordinates communications, passing on request and returning repliesIt stores all servers’ registration information, their functionalities and location information

It provides APIs for clients to request, servers to respond, registering or unregistering server components, transferring messages, and locating servers.

Broker ArchitectureStub (Client-side proxy)

Mediates between the client and the broker and providing additional transparency between them.To the client, a remote object appears like a local one.The proxy hides inter-process communication at protocol level, marshals the parameter values, and unmarshals results from the server.The stud is generated at compilation time and deployed at client side to be used as a proxy for client

Broker ArchitectureSkeleton (server-side proxy)

It is also generated by service interface compilation and deployed at server sideEncapsulates low-level system specific networking functions like client proxy and provides high level APIs to mediate between the server and the brokerIt receives and unpacks the requests, unmarshals the arguments, and calls the appropriate service. When receives the result back from the server, it also marshals results before sending it back to the client.

Broker ArchitectureBridges

Optional componentHide implementation details when two brokers interoperatesCan translate requests and parameters from one format to another

Broker ArchitectureNetwork

Connects components using designated protocol standards such as TCP/IP OIIP SOAP

The request carries data in a message document or method invocation format.

Broker ArchitectureExample – Broker Model

Broker 1Broker 1

Broker 2Broker 2

1Request

5Response

Service 1

Service 2

Service 3

2

3

4

Broker ArchitectureConnected Broker with client-server proxy

Broker 1Broker 1

Broker 3Broker 3

Bridges Broker 2Broker 2

Client Proxy

Client Proxy

Client Proxy

ServerProxy

ServerProxy

ServerProxy

Summary – Broker Style

AdvantagesServer component implementation and location transparency,Changeability and extensibility,Feasibility of run time changes of server components (add or remove server components)

Disadvantages:Inefficiency due to the overhead of proxiesLow fault toleranceDifficulty testing

Broker Example – CORBA

CORBA – Common Object Request Broker Architecture

Software bus

client Server

Stub Skeleton

IFR

Operation , args

Returnvalue, out args

Interface Repository

Static Remote Invocation in CORBASteps to make things work

1. service published using IDL (Interface Definition Language)2. service implemented by extending Servant class and registered

by extending Service class3. client implemented by locating name service and invoke

service

Dynamic CORBA Invocation

Dynamic?The invoker does not have to know all details of service provider, e.g., parameter formatInformation is disclosed by broker at run time

Relies on 3 componentsCORBA Interface Repository (IFR)Dynamic Invocation Interface (DII)Dynamic Skeleton Interface (DSI)

Message Broker Architecture

Message: formatted information e.g., XML

Application 1

parser transformer router

Message Broker 2

Message Broker n

Parsed & transformeddata

Application 2

Message broker 1

message

Message Broker Architecture