1. Today: Distributed Objects and Components 1

2. Me Greg Paperin MSci Computer Science href=http://www.paperin.org 2

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. Transparency of Distributed Systems Access transparency Location transparency Concurrency transparency Replication transparency Failure transparency Migration transparency Performance & Scaling transparency 10

11. Identifying Components What chunks can be distributed ?  Single commands - Too small  Threads - No encapsulation  Encapsulation? It rings a bell! - Yes, we distribute objects !!! 11

12. Components / Objects need to communicate Traditional approach – R emote P rocedure C all Object oriented elaboration is R emote M ethod I nvocation 12

13. Interfaces Heterogeneous environment Different programming languages  Objects required to publish an interface in a portable manner.  I nterface D efinition L anguage 13

14. Binding Must be transparent Static vs. Dynamic 14

15. 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. 16

17. 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

18. 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

19. Issues with data passing Machines might use different encoding Unknown point of failure 19

20. Solve encoding heterogeneity  Big endian  Little endian  2’s complement  1’s complement  Marshalling / Unmarshalling  Calls by reference  Reference flattening 20

21. 21

22. 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

23. 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

24. Reference Flattening example 24 FirstListItem=0x038B06 value = 82 next = 0x110011 value = 11 next = 0xE6C835 value = 19 next = 0xNULL FirstListItem = 0x2 value = 82 next = 0x8 value = 11 next = 0xD value = 19 next = NULL

25. 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

26. 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

27. Execution Semantics (3) Maybe call semantics At-least-once call semantics At-most-once call semantics 27

28. 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

29. Multi-Tier Software Persistence layer Business logic layer User Interface layer 29

30. 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 interface 30

31. The RMI part of middleware functionality 31

32. Persistence in Middleware Persistent objects Persistent object store Persistent root Persistent interface Location service Objects run in “containers” monitoring object’s states 32

33. 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

34. 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

35. 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