44
Effective Architecture for Distributed Computing System

Effective Architecture for Distributed Computing System

  • Upload
    others

  • View
    3

  • Download
    0

Embed Size (px)

Citation preview

Effective Architecture for Distributed Computing System

건대DMS

건대DMS

건대DMS

건대DMS

Modern Architectures

• Vertical Distribution

◼ Placing logically different components on different machines

• 3-Tier Architecture

건대DMS

3-Tier System Architecture

Web Server

Application

Server

LAN

Customers

B-Partners

Suppliers

oracle

JD

BC

Da

ta S

ou

rce

Ob

jec

t

SQL

SAP

Legacy

Note

...

Clients Servers Storage

IntenetIntranet

건대DMS

Modern Architectures

• Horizontal Distribution

◼ A client or server may be physically split up into logically equivalent parts, but each part is operating on its own share of the complete data set, thus balancing the load

건대DMS

Modern Architectures

◼ Horizontal Distribution of a Web Server

건대DMS

Modern Architectures

• Horizontal Distribution of Clients

◼ Peer-to-Peer Distribution

◼ Collaborative applications

◼ Ex)

◼ P2P

◼ Chatting

건대DMS

3-Tier System Architecture

Web Server

Application

Server

LAN

Thin Client

Fat Client

Employees

Customers

B-Partners

Suppliers

oracle

JD

BC

Da

ta S

ou

rce

Ob

jec

t

SQL

SAP

Legacy

Note

...

Clients Servers Storage

IntenetIntranet

건대DMS

Positioning Middleware

◼ General structure of a distributed system as middleware.

1-22

건대DMS

Middleware and Openness

◼ In an open middleware-based distributed system, the protocols used by each middleware layer should be the same, as well as the interfaces they offer to applications. This is a much higher level of abstraction than (for instance) the NOS Socket API.

1.23

건대DMS

건대DMS

건대DMS

건대DMS

건대DMS

건대DMS

Proxy Architecture Style

건대DMS

Synopsis

◼ The proxy pattern forces method calls to an object to occur indirectly through a proxy object that acts as a surrogate for the other object, delegating method calls to that object

◼ Proxy objects generally share a common interface or superclass with the service-providing object

건대DMS

Context

◼ Transparent management of another object’s services is the basic reason for using a proxy

◼ Different types of service management◼ A proxy makes a method that can take a long

time to complete appear to return immediately

◼ A proxy creates the illusion that an object that exists on a different machine is an ordinary local object (Remote Proxy)

◼ A proxy controls access to a service-providing object (Access Proxy)

◼ A proxy creates the illusion that a service object exists before it actually does (Virtual Proxy)

건대DMS

Context

건대DMS

Solution of Proxy Pattern

건대DMS

건대DMS

건대DMS

Remote Procedure Call

communicationmodule

client

procedure call

client stubbindmarshalserializesend

client process

communicationmodule

server

procedure

server stub

unmarshaldeserializereceive

server process

dispatcher(selectstub)

Basic functioning of RPC

건대DMS

communicationmodule

client

procedure call

client stubbindmarshalserialize2. find5. send

client process

communicationmodule

server

procedure

server stub0. registerunmarshaldeserialize7. receive

server process

dispatcher(selectstub)

3. query for serverimplementingthe procedure

4. address of server

6. invoke procedure

name and directory service (binder)

1. registerserver andprocedure

Copyright Springer Verlag Berlin Heidelberg 2004 Dynamic binding

Dynamic Binding in RPC Architecture

건대DMS

건대DMS

Broker Architecture Style

Synopsis• A middleware architecture used in distributed computing to coordinate

and facilitate communication between registered servers and clients.

• The Broker architectural pattern 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

Client

Broker

Server Server Server

Broker: Solution - Structure

Design broker component to decouple clients from servers•Servers• Register with broker

• Present method interfaces to clients

•Clients• Access server’s methods via broker

• Uses same form to call server’s methods

•Broker’s Tasks• Locating appropriate server

• Forwarding requests to server

• Transmitting results and exceptions to client

31

Client

Broker

Server Server Server

Broker: Solution 1 - Static

Six types of participating components: clients, servers, brokers, bridges, client-side proxies and server-side proxies

Broker Architecture Style

Decompose the broker architecture into subcomponents: • Broker : coordinates communications, passing on requests and returning

replies.

• The broker stares 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 (client-side proxy): mediates between the client and the broker and provides additional transparency between them.

• To the client, a remote object appears like a local one.

• The proxy hides the interprocess communication at protocol level, marshals parameter values, and unmarshals 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.

Broker Architecture Style

Skeleton (server-side proxy): 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 the client-

proxy and provides high-level APIs to mediate between the server and the broker.

• It receives and 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 : are optional components used to hide implementation details when two brokers interoperate. • Bridges encapsulate underlying network detail implementation and mediate

different brokers such as DCOM, .NET Remote, and Java CORBA brokers.

• They can translate requests and parameters from one format to another.

• A bridge can connect two different networks based on different communication protocols.

Network : connects components using designated protocol standards such as TCP/IP, IIOP, or SOAP. • The request carries data in a message document or method invocation

format.

Broker: Solution 1 - Dynamics

Scenario 1 : Server Registration

35

Broker: Solution 1 - Dynamics

Scenario 2 : Service Process

36

Sending request

Receiving Request and Doing Response

Getting Response

Forwarding Request from Client to Server

Forwarding Response from Server to Client

37

Broker: Solution 1 - Dynamics

Scenario 3 : Service Process via Bridge

37

Broker: Solution 1 - Overall

건대DMS

건대DMS

건대DMS

건대DMS

건대DMS

Application Server Architecture

oracle

JD

BC

Da

ta S

ou

rce

Ob

jec

t

SQL

SAP

Legacy

Note

...

TP

Mo

nito

r

Me

ss

ag

e Q

We

b L

iste

ne

r

Dis

pa

tch

er

Component Container

Component

Component

Business

Process

Data

건대DMS

Three Major Component Models

• OMG’s CORBA Component Model (CCM/CORBA)◼ entered from a corporate enterprise

perspective

◼ CORBA-based standards, standard IDL

◼ specification first, then implementation

• MS’s COM+/DNA or C#/.NET◼ entered from a desktop perspective

◼ COM/CLR-based standards, binary standard

◼ platform dependent

• SUN’s Enterprise Javabeans (EJB/J2EE) ◼ entered from an Internet perspective

◼ Java-based standards, platform independent

◼ Language dependent