Objektorienteret netværkskommunikation Presentation: Architectures for Distributed Systems

Objektorienteret netværkskommunikation

Presentation:

Architectures for Distributed Systems

Ingeniørhøjskolen i ÅrhusSlide 2

Agenda

• Architectural models• OOA/OOD and distributed system diff.• Layering• Interface Partioning & Granularity• Adapting patterns for distributed usage

A few words of warning:Assumed students are knowledgeable about OOA/OODWe will only look at some aspects of distributed architectureNot much literature available on this subjectNo textbook solutions to this problemThis lecture is just for inspiration – not a dictate


Architectural models

• Architectural model: Description of the components of a system and the relationship between them.

• Describe the components of systems and their interaction; describe mapping of components to computers.

• Define useful patterns for the distribution of data and workload.

• Define the functional roles of components and the patterns of communication between them.


Basic architectural models

Server

Client

Client

invocation

result

Serverinvocation

result

Process:Key:

Computer:

Client-server: WWW, OO middleware, distributed systems in general

Others: service, peer-to-peer, proxy, mobile code, spontaneous network

Read more in Colourius et al.


Basic architectural models – multiple servers

Server

Server

Server

Service

Client

Client

Partition set of objects orreplicate set of objects


Basic architectural models – proxy server and caching

Client

Proxy

Web

server

Web

server

serverClient

Cache: Store of recently used data objectscloser than the objects themselves

Proxy servers increase performance and availability


Basic architectural models – peer processes

Coordination

Application

code

Coordination

Application

code

Coordination

Application

code


Other architectural models – mobile code, web applets

a) client requests results in the downloading of applet code

Web server

ClientWeb serverApplet

Applet code

Client

b) client interacts with the applet


Other architectural models – spontaneous networking

Internet

gateway

PDA

service

Music service

serviceDiscovery

Alarm

Camera

Guestsdevices

LaptopTV/PC

Hotel wirelessnetwork

Easy connection and integration; limited connectivity; problems withsecurity and privacy; discovery service with registration and lookup.


Designing Distributed Systems

• Use OOA/OOD (or other method)– Same procedure as with stand-alone system design– Use ”best-practices” aka ”design patterns”– BUT: beware of the pit-falls of distributed design– (Guerraoui & Fayad)

• Beware of “Gold Plating”– Do not use excessive amount of time on design


Basic OO Design – Use Case Driven

Use Case N

Actor 1

Use Casespec.

“Models” the domaine.g. an Account or

Sensor.

System/ActorInteraction

Use Case impl.Links Model & Boundry

«control»

«boundary»

«entity»

Domain Model for Use Case N

Logic DomainModel from the Analysis

OOA


Bruce Eckel’s ROPES ModelArchitecture design

Scope: nodes, packages (sub systems), components (e.g. a driver DLL), tasks

Mechanistic design

Scope: Group of collaboratingclasses Class

Class

Class

Class

Node

Package

ComponentActive object

Detailed designScope: Class

Class name

Attributes

Operations

Bd. s193


Use Sub-systems for Structuring

• At least you should have two sub-systems:– a client– a server

• More sub-systems may be introduced as needed


Getting Distributed

• Until now – stand-alone & single process• Distributed Systems are much more complex• We focus only on OO systems• How to make an optimal design?• What belongs on the client side – and what on the

server side?• At least three things to consider:

– Layering– Granularity issues– Adapting Design Patterns


Design by Layering

• Client Presentation tier– Provides a user interface to the end-users. – Thin/Rich. MVC.

• Server Side Presentation tier– Building a response to the Client Presentation tier.

• Server Side Business Logic tier– Use Case implementation. Control classes. Business logic.

• Server Side Domain Model tier– Domain Model. Entity classes.

• Enterprise Integration tier– Legacy system. Web services.

• Persistence tier / Resource layer– Relational Database. File-system.


Interface Partitioning & Granularity

• OOA/OOD teaches us to map real world model to domain model

• Granularity has always been an issue• In stand-alone / single process systems

– Should we have a fine-grained model – with one or more control classes pr use case and a detailed domain model?

– Should we have a corse-grained model with only a few classes?

– In distributed systems, this gets worse


Three Aspects of a Distributed Object System

Granularityof Model

Interface Design

SystemPartitioning

Three important aspects when producing a Distributed object Model which has impact on eachother

Anti-pattern: Round tripping vs. partition of resources vs. desired level of interface design resolution

(some might want to map system objects 1-1 with real world objects, accounts and transactions


Using Design Patterns

• Provides guidelines, not actual implementation • Proven track record• Reusable• Help you communicate your design ideas to other

designers

Anti-pattern: Gold Plating – spending excessive amount of time on design


Design Patterns Examples

• ”Classic Design Patterns”:– Singleton– Observer– Iterator– Facade– Proxy (you have already seen this)– Factory– Many others

• All may be used, but some must be adjusted• Remember: patterns are only for inspiration

– NOT dictate

• Lets look at a few


The Observer Pattern (GoF)

Publisher

Subscriber

Subscriber

Subscriber

Generates a lot of network trafficeven though the three subscribersresides in the same process space


Distributed version of Observer

channel

Subscriber

Subscriber

Subscriber Channel

Publisher

Only one notify message between thechannel objects as opposed to the naive Observer pattern.

channel

Subscriber

Subscriber

Subscriber Channel

Publisher

Only one notify message between thechannel objects


Iterator Pattern

Client Iterator Collection

1. Create iterator

2. Get next item3. Get next item4. …..

Generates a lot of network traffic


Distributed version of Iterator

Client Iterator Collec-tion

1. Create iterator

2. Query3. Get next item

4. Get next item

5. …….

Result of 2.

Only one call needed to transfer all objects


Façade Pattern (also GoF)

Used for encapsulation and decoupling – usually one pr sub-system- Session Façade pattern, Façade at the Distribution Boundary

Used for encapsulation and decoupling – usually one pr sub-system- Session Façade pattern, Façade at the Distribution Boundary

The entire Client sub-system is decoupled from the server sub-systemand a Client Proxy hides the complex network detail of a distributed system

By using Façade pattern, only a few objects needs to be made Remote

The entire Client sub-system is decoupled from the server sub-systemand a Client Proxy hides the complex network detail of a distributed system

By using Façade pattern, only a few objects needs to be made Remote


Factory Pattern

• How to create objects? Can not instantiate• We need a staging point – a Factory object

• Distributed version: Object Factory– For creating, finding & managing both DTO and remote objects– Often seen in conjunction with façade, replicating objects & proxy


Other

• Many others available. Read more in e.g.• CORBA Design Patterns (Mowbray & Malveau)

– Replication– Agent– Naming– Trader– Object Request Broker– Profile

• J2EE Design Patterns (Kaplan & Crawford)– Singleton– Front Controller– Dispatcher


Remember

• You have been presented with some basic input for the design of distributed systems

• This is only for inspiration not a dictate• Even though we have the ideals of transparency –

one must remember the differences that does exist

Documents

Objektorienteret netværkskommunikation Presentation: Architectures for Distributed Systems