Prof. Orhan Gemikonakli Module Leader: Prof. Leonardo Mostarda Università di Camerino

1. Distributed Object-based systems Prof. Orhan Gemikonakli Module Leader: Prof. Leonardo Mostarda Università di Camerino Prof. Orhan Gemikonakli - Camerino,

2. Last lecture Basic concepts Fault modelling Failure masking RPC Semantics in the Presence of Failures Reliable multicast schemes Virtual Synchrony Two phase commit |Three phase commit Checkpointing and Message logging Prof. Orhan Gemikonakli - Camerino,

3. Outline Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. 0-13-239227-5 Architecture Processes Communication Naming Synchronization Consistency and Replication Fault Tolerance Prof. Orhan Gemikonakli - Camerino,

4. Learning outcomes • To understand the basic concepts related to distributed object-based systems • To describe and discuss • Architecture • Processes • Communication • Naming • Synchronization • Consistency and Replication • Fault Tolerance as they apply to distributed object-based systems Prof. Orhan Gemikonakli - Camerino,

5. Distributed Object-based systems • A paradigm used to organise ditributed systems • The notion of object plays a key role in establishing distribution transparency • Everything is treated as objects • Clients are offered services and resources in the form of objects they can revoke. • Examples of object-based distributed systems • CORBA • Java-based systems • Globe Prof. Orhan Gemikonakli - Camerino,

6. Architecture • Object orientation plays an important part in software development • Functionality can be added as independent components • 1980s: Distributed Object-oriented systems started • An independent object hosted by a remote server • High degree of distribution transparency • An object • Encapsulates data (state) • Encapsulates operations on that data (methods) • May implement multiple interfaces Prof. Orhan Gemikonakli - Camerino,

7. Distributed Objects • Distributed object: an interface at one machine while the object resides on another machine • When a client binds to a distributed object an implementation of the object’s interface called proxy is then loaded into the client’s address space. • A proxy marshals method invocations and unmarshalls reply messages (similar to a stub in RPC) • Skeleton: The server-side stub • Objects: compile-time objects and run-time objects Prof. Orhan Gemikonakli - Camerino,

8. Distributed Objects Figure 10-1. Common organization of a remote object with client-side proxy. Prof. Orhan Gemikonakli - Camerino,

9. Example: Enterprise Java Beans (EJBs)) Figure 10-2. General architecture of an EJB server. Services: messaging, naming DB access etc. Prof. Orhan Gemikonakli - Camerino,

10. Four Types of EJBs • The use of services is automated, but a programmer should make a distinction between types of EJBs: • Stateless session beans • Stateful session beans • Entity beans • Message-driven beans Prof. Orhan Gemikonakli - Camerino,

11. Four Types of EJBs • Stateless session bean: a transient object; invoked once, does it work, gets discarded (e.g. an SQL query) • Stateful session bean: a persistent object; maintains client related state (e.g. electronic shopping cart). Yet, limited lifetime. • Entity bean: a long time persistent object (e.g. holding customer details in e-commerce) • Message-driven beans are used to program objects that should react incoming messages and send messages. Stateless. Prof. Orhan Gemikonakli - Camerino,

12. Example: Globe Distributed Shared Objects (1) • Globe: an object-based distributed system • Scalability plays a central role • Can support large-scale wide-area systems and huge numbers of users. • Objects (distributed shared objects) • encapsulate state and operations on that state. • Also encapsulate the policies on the distribution of an object’s state over its replicas • Physically distributed and replicated (the states) (no remote object model) • Have local implementations (with or without states) – only methods are visible • Primitive or composite local object Prof. Orhan Gemikonakli - Camerino,

13. Globe Distributed Shared Objects (2) Figure 10-3. The organization of a Globe distributed shared object. Prof. Orhan Gemikonakli - Camerino,

14. Globe Distributed Shared Objects (3) Figure 10-4. The general organization of a local object for distributed shared objects in Globe. Prof. Orhan Gemikonakli - Camerino,

15. Processes • Object servers play a key role in object-based distributed systems. • They are designed to host distributed objects • Services are implemented by objects and are easy to change • In multi-threaded object servers, each object can be assigned a thread, or each invocation can be assigned a thread. Prof. Orhan Gemikonakli - Camerino,

16. Processes: Object Adapter • Activation: decisions on how to invoke an object • Servant: piece of code that forms the implementation of an object (e.g. a java bean is a servant.) • Object Adapter (Object Wrapper): A mechanism to group objects per policy. • Controls one or more objects • They are generic but configurable • Several object adapters can exist in a server • Invocation requests are first dispatched to the appropriate object adapters. Prof. Orhan Gemikonakli - Camerino,

17. Object Adapter Figure 10-5. Organization of an object server supporting different activation policies. Prof. Orhan Gemikonakli - Camerino,

18. Example: The Ice Runtime System • Ice is a distributed object system • An object server in Ice is a process that starts by initialising Ice runtime system (RTS) • Communicator: a runtime component that manages resources (e.g. pool of threads) • Can specify maximum message length, maximum number of retries etc. • Can create an object adapter • Multiple communicators possible for an object server. • E.g. managing different thread pools. Prof. Orhan Gemikonakli - Camerino,

19. The Ice Runtime System Figure 10-6. Example of creating an object server in Ice. Prof. Orhan Gemikonakli - Camerino,

20. Communication • The mechanism of a client invoking a remote object is largely based on RPCs. • Binding a client to an object • Object references can be passed to processes and used for method invocations • A process holding an object reference first binds to the referenced object. • Binding results in a proxy been placed into the clients address space • Implicit binding: provides the client with a simple mechanism to invoke methods directly • Explicit binding: client first needs to call a function before binding. Prof. Orhan Gemikonakli - Camerino,

21. Binding a Client to an Object Figure 10-7. (a) An example with implicit binding using only global references. (b) An example with explicit binding using global and local references. Prof. Orhan Gemikonakli - Camerino,

22. Parameter passing • When invoking a method, objects may be passed with invocation • Local objects (usually small) are passed as a whole • Remote objects are passed by reference Prof. Orhan Gemikonakli - Camerino,

23. Parameter Passing Figure 10-8. The situation when passing an object by reference or by value. Prof. Orhan Gemikonakli - Camerino,

24. Object-Based Messaging • Remote Method Invocation (RMI) is the preferred way of handling communication in object-based distributed systems • CORBA messaging combines method invocation and message-oriented communication • Task: Compare and contrast RMI and CORBA in the context of handling communication in object-based distributed systems Prof. Orhan Gemikonakli - Camerino,

25. Naming • The interesting aspect of naming in object-based distributed systems evolves around the way that object references are supported. • As discussed, in Java, these object references correspond to portable proxy implementations. • Task: How are objects referenced in CORBA? Distinguish between referencing local, and remote objects. Prof. Orhan Gemikonakli - Camerino,

26. Synchronisation • Problem: Implementation details are hidden behind interfaces • When a process invokes a remote object, it has no knowledge whther that invocation will lead to invoking other objects. • If an object is protected against concurrent access, we may have cascading set of locks the invoking process is unaware of (Fig 10-a) • When dealing with data resources such as files or database tables that are protected by locks, the pattern for the control flow is visible to the process. (Fig 10-b) Prof. Orhan Gemikonakli - Camerino,

27. Synchronization Figure 10-14. Differences in control flow for locking objects Prof. Orhan Gemikonakli - Camerino,

28. Consistency and Replication • General approach to replicated objects: • Traditional approaches (as discussed in Chap 7) treating them as containers of data with their own operations • Consistency: Data-centric consistency comes in the form of entry consistency • No multiple invocations on the same object allowed • Ensure that all the changes to a replicated object are the same. Prof. Orhan Gemikonakli - Camerino,

29. Consistency and Replication • Consistency: • No multiple invocations on the same object allowed • Use locks to allow only one method execution at a time – use local locks • Recall that data is accessed through methods only, hence access to data is serialized • Ensure thatr all the changes to a replicated object are the same. • No two independent method invocations takes place on different replicas at the same time – order invocations so that each replica see them in same order. Use • Primary-based approach or • Totally ordered approach Prof. Orhan Gemikonakli - Camerino,

30. Entry Consistency Figure 10-15. Deterministic thread scheduling for replicated object servers. Prof. Orhan Gemikonakli - Camerino,

31. Replication Frameworks (1) • Invocations to objects are intercepted at three different points: • At the client side just before the invocation is passed to the stub – in case the caller is replicated • Inside the client’s stub, where the interception forms part of the replication algorithm – to forward or abort • At the server side, just before the object is about to be invoked. Prof. Orhan Gemikonakli - Camerino,

32. Replication Frameworks (2) Figure 10-16. A general framework for separating replication algorithms from objects in an EJB environment. Prof. Orhan Gemikonakli - Camerino,

33. Replicated Invocations (1) Figure 10-17. The problem of replicated method invocations. Prof. Orhan Gemikonakli - Camerino,

34. Replicated Invocations (2) Figure 10-18. (a) Forwarding an invocation request from a replicated object to another replicated object. Prof. Orhan Gemikonakli - Camerino,

35. Replicated Invocations (3) Figure 10-18. (b) Returning a reply from one replicated object to another. Prof. Orhan Gemikonakli - Camerino,

36. Fault Tolerance • Similar mechanisms used for other distributed systems are used for object-based DSs too. • CORBA: • Replicates objects into object groups • Object groups are referenced as a single object offering the same interface as replicas it contains • Different replication strategies are used • Primary-backup replication • Active replication • Quorum-based replication • Object groups are referenced using an Interoperable Object Group Reference (IOGR) Prof. Orhan Gemikonakli - Camerino,

37. Example: Fault-Tolerant CORBA Figure 10-19. A possible organization of an IOGR for an object group having a primary and backups. Prof. Orhan Gemikonakli - Camerino,

38. An Example Architecture Figure 10-20. An example architecture of a fault-tolerant CORBA system. Prof. Orhan Gemikonakli - Camerino,

39. Example: Fault-Tolerant Java • Causes for nondeterministic behavior: • JVM can execute native code, that is, code that is external to the JVM and provided to the latter through an interface. • Input data may be subject to nondeterminism. • In the presence of failures, different JVMs will produce different output revealing that the machines have been replicated. Prof. Orhan Gemikonakli - Camerino,

40. Summary • Distributed Object-based Systems • Architecture • Processes • Communication • Naming • Synchronization • Consistency and Replication • Fault Tolerance Prof. Orhan Gemikonakli - Camerino,

41. Next Lecture • Distributed File Systems • Architecture • Processes • Communication • Naming • Synchronization • Consistency and Replication • Fault Tolerance Prof. Orhan Gemikonakli - Camerino,