DISTRIBUTED COORDINATION BASED MODELS

1. DISTRIBUTED COORDINATION BASED MODELS TIB JINI

2. INTRODUCTION • Here we look at only one type(web,object,file). • Clear separation between computation and coordination exists. • A distributed system is a collection of processes.

3. INTRODUCTION • Each process is concerned with a specific computational activity. • which in principle is carried out independently from other activities of other processes.

4. INTRODUCTION • We are trying to separate computation from coordination. • The coordination part of distributed system handles the communication and cooperation between the processes.

5. TYPES

6. INTRODUCTION • Referential coupling generally appears in the form of explicit referencing in communication. • Sender is in need to know the identifier of receiver. • Ex: A process can communicate only if it knows the name or identifier of the other process.

7. INTRODUCTION • Temporal coupling means that processes that are communicating will both have to be up and running. • Sender and Receiver needs to be active and are running.

8. COORDINATION MODELS • TIB • JINI

9. TIB • Coordination model: Meeting Oriented Model • Makes use of subject based addressing, leading to what is known as publish/subscribe architecture. • Receiving a message on subject X is possible only if the receiver had subscribed to it. • Publishing a message on subject X means that the message is sent to all subscriber to X.

10. TIB Architecture

11. Architecture • TIB uses multicasting to forward messages to subscribers. • To cross-large scale networks, it effectively builds an overlay network with proprietary multicast routers.

12. WAN Architecture

13. Communication • Events : Publish – subscribe systems are ideally supported by means of events: you are notified when someone publishes a message that is of interest to you. • Listener Events: Local object that registers a call back for a specific subject.

14. Communication

15. Communication • Event Scheduling: Events for the same listener event are handled one after the other. • They may also be lost/ignored if listener event is destroyed at the wrong time

16. Communication

17. NAMING • Names are important as they form address of the address of the message. • Filtering facilities ensure that right messages reach right subscribers.

18. NAMING

19. NAMING

20. Transactional Messaging • Ensures that the messages sent by a single process are delivered only if the sender commits. • Store published messages until commit time and only then make them available to subscribers.

21. Transactional Messaging

22. Fault Tolerance: Multicasting • TIB relies on multicasting for publishing messages to all subscribers. • This mechanism needs to be extended to wide area networks and requires reliable multicasting. • How?

23. Fault Tolerance: Multicasting • Solution: • Pragmatic General Multicast(PGM) • A NACK based scheme in which receiver tells the sender that they are missing something

24. Fault Tolerance: Multicasting

25. SECURITY • Goal: establish a secure channel between a publisher and a subscriber • Referential decoupling between publisher and subscriber is lost • Sender publishes encrypted data including its identity

26. SECURITY • Each subscriber sets up a secure channel with the sender • All subscribers share the same key to decrypt messages

27. SECURITY • Diffie-Helman key exchange + public-key cryptography • Assume Alice and Bob already: • obtained certificates containing each-other public key • established a shared key KA,B using Diffie-Helman

28. SECURITY • Establish a secure channel between a specific publisher and specific subscriber.

29. TIB-SUMMARY • Architecture • Communication • Naming • Transactional Messaging • Fault Tolerance • Security

30. JINI • Generative Communication Model. • Temporal and Referential uncoupling by means of javaspaces, a tuple based storage system. • Tuple? • A Tuple is typed set of references to objects.

31. JINI • Tuples are stored in serialized, that is, marshalled from into javaspace. • To read a tuple, construct a template, with some fields left open. • Match a template against a tuple through a field by field comparision.

32. JINI • write(): create an object copy and store it in JavaSpace • read(): return tuples from JavaSpace that match a template • take(): like read, but removes tuple from JavaSpace

33. JINI

34. JINI • Write : A copy of tuple is stored in javaspace. • Read : A template is compared to tuple instances; the first match returns a tuple instance. • Take : A template is compared to tuple instances; the first match returns a tuple instance and removes the matching instance from javaspace.

35. Entry JavaSpace Example: JavaSpace “Hello World” public class Message implements Entry { public String content; public Message() { } } Message msg = new Message(); Msg.content = “Hello World”; JavaSpace space = SpaceAccessor.getSpace(); Space.write(msg, null, Lease.FOREVER); Write entry

36. Example: JavaSpace “Hello World” • Use pattern matching to get desired objects from the space • “null” value represent wildcard • A message object with the “content” field set to “null” will return any message object • A message object with the content field set to “Berkeley” will only return a message object with the content set to that value

37. JavaSpace Example: JavaSpace “Hello World” Message template = new Message(); //Content is null Message result = (Message)space.read( template, null, Long.MAX_VALUE); System.out.println(result.content); “Hello World” Read entry Entry Long.MAX_VALUE - timeout parameter

38. Communication : Notifications • A Process can register itself at an object to be notified when ever the event happens. • Uses a callback mechanism through listener objects. • A callback is implemented as an RMI.

39. Layered Architecture of Jini

40. Events • A client can register with an object that has events of interest • A client can tell object to pass event to another process • Notification implemented by remote call

41. Using Events with JavaSpaces

42. JavaSpace Implementation • Replicate JavaSpace at all machines • Store tuples locally, search everywhere • Partial replication and searching • Use DHTs?

43. Replicate Everywhere

44. Search Everywhere

45. Partial Replication and Searching

46. Lookup Service • Can be implemented using JavaSpaces • Each service inserts a tuple describing itself • JavaSpace notifies interested clients when service becomes available • Instead, Jini provides a specialized lookup service • A service registers itself using (attribute, value)-pairs • E.g., service parameters, location

47. Service Item Predefined tuples:

48. Transactions • Aim to provide ACID properties • Atomicity: all operations of a transaction take place, or none of them do • Consistency: completion of a transaction must leave the participants in a ``consistent'' state • Isolation: activities of one transaction must not affect any other transactions • Durability: results of a transaction must be persistent

49. Transactions • Jini • Supply the mechanism of two-phase commit protocol • Leave the policy to the participants in a transaction

50. Transactions • A transaction is represented by a long identifier, obtained from a transaction manager • Each transaction is associated a lease; if lease expires, transaction is aborted