Today:

Distributed Objects and Components

1

Me

Greg Paperin

MSci Computer Science

href=http://www.paperin.org

2

Contents

• Centralised Systems Problems and issues

• Solution – Distributed Systems (DS)

• Properties of DS• Software for DS - Components• Distributed Components – Objects

Communication, Transparency, Interfaces

• Distributed Software Technology – Middleware Issues & Examples

3

Centralised Systems’ Properties

• One physical device (all in one box) One physical location

• One or a few CPUs

• Shared memory, resources

• Shared busses / connections

• One-type architecture – non-heterogeneous.

4

Centralised Systems’ Issues

• One physical location vulnerable against threads from outside

• Shared resources & busses single point of failure

• One or a few CPUs single point of control,pseudo-concurrency

• Non-heterogeneous can’t mix specialized CPUs

5

Addressing problems of centralised systems (1)

• No real concurrency Multiple CPU help, but:

- resource allocation problems- connection (bus) allocation problems- control point problems (e.g. task allocation)

Solution: have own power supply, cache, memory, busses and other resources for each CPU

Result: many “small” separate systems

6

Addressing problems of centralised systems (2)

• Many “small” separate systems is good, but:

- how can they work together ?

Interconnected by a network (preferably a non-centralized one)

7

What we get from it

• No single point of failure• No single point of control• True concurrency• Resources not shared, but accessible• Can have a large number of CPUs• Subsystems / CPUs can be different – heterogeneity • Subsystems can be in different physical locations

A Distributed System 8

Properties of Distributed Systems

• The components (subsystems) of a DS are autonomous• Processes run in true concurrency on diff. subsystems• A DS is heterogeneous • A DS is open• A DS is scalable• A DS is Fault tolerant• A DS must be secure• Transparency

9

Transparency of Distributed Systems

•Access transparency

•Location transparency

•Concurrency transparency

•Replication transparency

•Failure transparency

•Migration transparency

•Performance & Scaling transparency 10

Identifying Components

What chunks can be distributed ?

Single commands- Too small

Threads- No encapsulation

Encapsulation? It rings a bell!- Yes, we distribute objects !!!

11

Components / Objects need to communicate

• Traditional approach –

Remote Procedure Call

• Object oriented elaboration is

Remote Method Invocation

12

Interfaces

• Heterogeneous environment• Different programming languages

Objects required to publish an interface in a

portable manner. Interface Definition Language

13

Binding

•Must be transparent

•Static vs. Dynamic

14

Dynamic Binding

•Servers publish supported interfaces

•Broker acts as a catalogue

•Binder locates required server

•Can happen on first invocation or every time

15

16

Advantages of Dynamic Binding

• It is flexible• It can support multiple servers supporting the same interface aiding transparency by:

- Using version IDs- Spreading load evenly over the servers- Pooling the servers periodically and automatically deregistering “dead” servers- Aiding in authentication and security by only connecting authorised servers with authorised users 17

Data passing

•Remote calls must be transparent•But:

- Client, Server or Network can crash- Client and Server run on two different processes

in two different address spaces on two different

architectures

18

Issues with data passing

• Machines might use different encoding

• Unknown point of failure

19

Solve encoding heterogeneity

Big endian Little endian 2’s complement 1’s complement

Marshalling / Unmarshalling

Calls by referenceReference flattening

20

21

Marshalling policy

• Canonical - Safe- Easy- Can be inefficient

• Informed- Everybody must know about all formats on the system- This might make scalability a difficult and expensive issue

22

Reference Flattening

•Resolve all references

•Pass everything by value

•Update changed parameters on return

•Use call-back for large objects (e.g. sparse arrays)

23

Reference Flattening example

24

FirstListItem=0x038B06

value = 82next = 0x110011

value = 11next = 0xE6C835

value = 19next = 0xNULL

FirstListItem = 0x2

value = 82next = 0x8

value = 11next = 0xD

value = 19next = NULL

Execution semantics (1)

No reply. What’s happened?

? A network error occurred and the server never received the request

? Server started the processing of the request but “crashed” during the execution

? Server successfully processed but the reply got lost due to a network failure

25

Execution Semantics (2)

What can we do:•Should requests and replies be confirmed ?•Should messages be retransmitted until a confirmation or timeout ?•Should servers memorise requests and reject duplicates ?•Should a history of replies be kept in order to retransmit them without re-executing operations ?

26

Execution Semantics (3)

•Maybe call semantics

•At-least-once call semantics

•At-most-once call semantics

27

Where does this all come from ?

Functionality must be transparent to programmer, i.e. automatic.• Generated by a compiler?

Too inflexible Middleware software system

Transparently handles:- RMI- Persistence- Security- etc.

28

Multi-Tier Software

• Persistence layer

• Business logic layer

• User Interface layer

29

The RMI part of middleware(deals with communication)

•Proxy-makes remote method invocation transparent to clients by behaving like a local object to the invoker.-forwards it in a message to a remote object-one each remote object

•Dispatcher-one for each class representing a remote object-receives the request message from the communication module

•Skeleton-implements the methods in the remote interface30

The RMI part of middleware functionality

31

Persistence in Middleware

•Persistent objects

•Persistent object store

•Persistent root

•Persistent interface

•Location service

•Objects run in “containers” monitoring object’s

states 32

Examples

• Common Object Model (COM) by Microsoft- Windows based

• Common Object Request Broker Architecture (CORBA) by OMG

- General platform and language independent standard

• Enterprise Java Bean (EJB) by Sun- Specific to Java

33

Summary

• Centralised vs. Distributed systems• Properties of DS • Identifying Distributed Components• Interfaces• Binding, Dynamic binding• Data passing

- Marshalling / Unmarshalling- Flattening

• Execution semantics• Multi-Tier Software Architecture• Services of Middleware

-RMI-Persistence

34

References

[1] Wolfgang Emmerich:Lecture slides for Distributed Systems for Communication

(1998).[See http://www.cs.ucl.ac.uk/staff/W.Emmerich/lectures/DS98-99/]

[2] Tanenbaum and van Steen:Distributed Systems: Principles and Paradigms [See http://db.uwaterloo.ca/~tozsu/courses/cs454/notes/3.invocation.pdf]

 [3] C.H. Kim:

Distributed Systems Lab, Chungnam National University[See http://flower.ce.cnu.ac.kr/~hchoi/class/AdDistSy/RMI.pdf]

 [4] Badri R. Narayanan:

Distributed Objects and Remote Invocation[See http://www.cs.stevens-tech.edu/~badri/CS649/DSRemoteInvocation.pdf]

35