1 / 70

Distributed Objects and Remote Invocation

Distributed Objects and Remote Invocation. Source: George Colouris , Jean Dollimore , Tim Kinderberg & Gordon Blair (2012). Distributed Systems: Concepts & Design (5 th Ed.). Essex: Addison-Wesley Chapter 8 & Chapter 5 Power point presentation was adapted from:

ikia
Download Presentation

Distributed Objects and Remote Invocation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Distributed Objects and Remote Invocation Source: George Colouris, Jean Dollimore, Tim Kinderberg & Gordon Blair (2012). Distributed Systems: Concepts & Design (5th Ed.). Essex: Addison-Wesley Chapter 8 & Chapter 5 Power point presentation was adapted from: http://faculty.ksu.edu.sa/metwally/Pages/IS335.aspx http://www.cdk5.net/wp/preface www.pcs.cnu.edu/~mzhang/CPSC450_550/2003CaseStudy/CORBA_Presentation_JeffOliver.ppt

  2. Content • Introduction • Distributed Objects • Remote Invocation • Case Study: CORBA

  3. Content • Introduction • Distributed Objects • Remote Invocation • Case Study: CORBA

  4. Introduction This Chapter

  5. Introduction • Distributed object middleware • allows programmers to adopt an object-oriented programming model that hide the underlying complexity of distributed programming • communicating entities are represented by objects • objects communicate using remote method invocation and other alternative communication paradigm

  6. Introduction • Distributed Object Middleware • Advantages: • Encapsulate programming complexity. • Allows programmers to focus on interface rather than the implementation such as the programming language and operating system used. • Encourage development of dynamic and extensible solutions, for example by enabling the introduction of new objects or the replacement of one object with another (compatible) object. • Middleware solutions based on distributed objects including Java RMI and CORBA

  7. Introduction • Component-based middleware • To overcome limitations in distributed object middleware • Limitations of distributed object middleware: • Implicit dependencies: Object interfaces do not describe what the implementation of an object depends on, making object-based systems difficult to develop (especially for third-party developers) and subsequently manage.

  8. Introduction • Component-based middleware • Limitations of distributed object middleware: • Programming complexity: Programming distributed object middleware leads to a need to master many low-level details associated with middleware implementations. • Lack of separation of distribution concerns: Application developers are obliged to consider details of concerns such as security, failure handling and concurrency, which are largely similar from one application to another.

  9. Introduction • Component-based middleware • Limitation of distributed object middleware: • No support for deployment: Object-based middleware provides little or no support for the deployment of (potentially complex) configurations of objects. • Examples: Enterprise JavaBeans and Fractal

  10. Content • Introduction • Distributed Objects • Remote Invocation • Case Study: CORBA

  11. Distributed Objects • Distributed object middleware • to provide a programming model based on object-oriented principles • to bring the benefits of the object oriented approach to distributed programming. • Benefit to distributed system developers: • More programming abstractions (using familiar programming languages such as C++ and Java) • use object-oriented design principles, tools and techniques (including UML) in the development of distributed systems software.

  12. Distributed Objects • Types of Distributed Objects

  13. Distributed Objects • The Functionalities of Distributed Objects • Inter-object communication - mechanisms for objects to communicate in the distributed environment • Lifecycle management - the creation, migration and deletion of objects • Activation and deactivation - the process of making an object active in the distributed environment by providing the necessary resources for it to process incoming invocations

  14. Distributed Objects • The Functionalities of Distributed Objects • Persistence – maintenance of state across possible cycles of activation and deactivation and system failures. • Additional services - provide support for the range of distributed system services including naming, security and transaction services

  15. Distributed Objects • Distributed Object Model • The logical partition of object-based programs into objects is naturally extended by the physical distribution of objects into different processes or computers in a distributed system. • Distributed object systems adopt the client-server architecture: • Objects are managed by servers and their clients invoke their methods using remote method invocation. • The client’s RMI request is sent in a message to the server managing the invoked method object. • The method of the object at the server is executed and its result is returned to the client in another message. • Objects in servers are allowed to become clients of objects in other servers.

  16. Distributed Objects • Distributed Object Model • Distributed objects can be replicated and migrated to obtain the benefits of fault tolerance, enhanced performance and availability. • Having client and server objects in different processes enforces encapsulation due to concurrency and heterogeneity of RMI calls.

  17. C local invocation E local remote invocation invocation F B remote A invocation local invocation D Distributed Objects • Distributed Object Model Remote and local method invocations

  18. Distributed Objects • Distributed Object Model • Each process contains a collection of objects, some of which can receive both local and remote invocations and others can receive only local invocations. • Objects that can receive remote invocations are called remote objects. • Other objects need to know the remote object reference in another process in order to invoke its methods. • A remote object reference is an identifier that can be used through a distributed system to refer to a particular unique remote object.

  19. Distributed Objects • Distributed Object Model • Every remote object has a remote interface to specify which of its methods can be invoked remotely. • Objects in other processes can invoke only the methods that belong to the remote interface of the remote object. • Local objects can invoke the methods in the remote interface as well as other methods of the remote object.

  20. Distributed Objects • Distributed Object Model remote object Data m4 { m1 implementation m5 m2 m6 remote of methods m3 interface A remote object and its remote interface

  21. Content • Introduction • Distributed Objects • Remote Invocation • Case Study: CORBA

  22. Remote Invocation • Introduction • how processes (or entities at a higher level of abstraction such as objects or services) communicate in a distributed system

  23. Remote Invocation • Request-reply protocols • support the roles and message exchanges in typical client-server interactions • A synchronous communication - the client process blocks until the reply arrives from the server • A reliable communication protocol - the reply from the server is an acknowledgement to the client that message has been received

  24. Remote Invocation • Request-reply protocols • Based on 3 communication primitives - doOperation, getRequest and sendReply

  25. Remote Invocation • Request-reply protocols • doOperation method • Is used by clients to invoke remote operations • Its arguments specify the remote server, the operation to invoke • Its result is a byte array containing the reply • getRequest • is used by a server process to acquire service requests • sendReply • Is used by the server to send the reply message to the client

  26. Remote Invocation • Request-reply protocols • requestId • Message identifier • A unique identifier to the sender, and the distributed system

  27. Remote Invocation • Request-reply protocols • Handling issues in the Request-reply protocols • Timeout - return the doOperation to the client indicating that it has failed or send multiple doOperationuntil response is received • Duplicate request messages – filter and discard the same doOperationwith same requestId. • Lost reply messages – send the copy of results, re-execute the request

  28. Remote Invocation • Request-reply protocols • 3 types of request behaviors using UDP: • the request (R) protocol • the request-reply (RR) protocol • the request-reply-acknowledge reply (RRA) protocol.

  29. Remote Invocation • Request-reply protocols • Request-reply protocols using TCP • allows arguments and results of any size to be transmitted • arguments and results are sent in streams between the client and server • It is a reliable protocol, hence, retransmission of messages and filtering of duplicates are not necessary

  30. Remote Invocation • Request-reply protocols • Request-reply protocols using HTTP • Implemented over TCP • uses persistent connections • connections that remain open over a series of request-reply exchanges between client and server. • A persistent connection can be closed by the client or server at any time by sending an indication to the other participant

  31. Remote Invocation • Request-reply protocols • HTTP methods: resource- http://computing.dcu.ie/~humphrys/Notes/Networks/java.html

  32. Remote Invocation • Request-reply protocols • Source and further reading : http://www3.ntu.edu.sg/home/ehchua/programming/webprogramming/http_basics.html

  33. Remote Invocation • Request-reply protocols • Examples of other http status codes:

  34. Remote Invocation • Remote Procedure Call • Design issues for RPC • Programming with interfaces • RPC call semantics • Transparency

  35. Remote Invocation • Remote Procedure Call • Programming with interfaces • Control the interactions between modules in a programming languages • interface of a module specifies the procedures and the variables that can be accessed from other modules • modules can run in separate processes in distributed systems • service interface - the specification of the procedures offered by a server, defining the types of the arguments of each of the procedures

  36. Remote Invocation • Remote Procedure Call • Programming with interfaces • An RPC mechanism can be integrated with a particular programming language if it includes an adequate notation for defining interfaces that is allowing input and output parameters to be mapped onto the language’s normal use of parameters • many existing useful services are written in C++ and other languages • Interface definition languages (IDLs) are designed to allow procedures implemented in different languages to invoke one another

  37. Remote Invocation • Remote Procedure Call • Programming with interfaces

  38. Remote Invocation • Remote Procedure Call • RPC call semantics • Possible implementation of sending request to remote host

  39. Remote Invocation • Remote Procedure Call • Transparency • RPC was designed to make remote procedure calls as much like local procedure calls as possible, with no distinction in syntax between a local and a remote procedure call • RPCs are more vulnerable to failure than local ones – as in involve with network. Network or server failure?

  40. Remote Invocation • Remote Procedure Call • Implementation of RPC • RPC is generally implemented over a request-reply protocol • The client that accesses a service includes one stub procedure for each procedure in the service interface • stub procedure –a procedure behaves like a local procedure to the client, but instead of executing the call, it marshals the procedure identifier and the arguments into a request message, which it sends via its communication module to the server

  41. Remote Invocation • Remote Procedure Call

  42. Remote Invocation • Remote Method Invocation • Remote method invocation (RMI) is an improved version of RPC • a calling object can invoke a method in a potentially remote object • The similarities in RPC and RMI • both support programming with interfaces • both typically constructed on top of request-reply protocols and can offer a range of call semantics such as at-least-once and at-most-once • both offer a similar level of transparency – that is, local and remote calls employ the same syntax

  43. Remote Invocation • Remote Method Invocation • The differences between RMI and RPC • RMI allows the programmer to pass parameters not only by value, as input or output parameters, but also by object reference

  44. Remote Invocation • Remote Method Invocation • Design issues for RMI • Programming with interfaces, call semantics and level of transparency (please refer to RPC) • Object model • Distributed objects • Distributed object models

  45. Remote Invocation • Remote Method Invocation • The object model • Object references - can be accessed via object references • Interfaces - provides a definition of the signatures of a set of methods (the types of their arguments, return values and exceptions) without specifying their implementation • Actions - is initiated by an object invoking a method in another object • Exceptions - provide a clean way to deal with error conditions without complicating the code • Garbage Collection – detect an object automatically when it is no longer accessible. It recovers the space and makes it available for allocation to other objects

  46. Remote Invocation • Remote Method Invocation • Distributed Objects • Distributed object systems may adopt the client-server architecture • Objects are managed by servers and their clients invoke their methods using remote method invocation

  47. Remote Invocation • Remote Method Invocation • The distributed object model • Each process contains a collection of objects, some of which can receive both local and remote invocations, whereas the other objects can receive only local invocations

  48. Remote Invocation • Remote Method Invocation • The distributed object model • Two components of distributed object model • Remote object references - an identifier that can be used throughout a distributed system to refer to a particular unique remote object • Remote interfaces - The class of a remote object implements the methods of its remote interface. Objects in other processes can invoke only the methods that belong to its remote interface

  49. Remote Invocation • Remote Method Invocation

  50. Remote Invocation • Remote Method Invocation • RMI Implementation • Several separate objects and modules are involved to achieve a remote method invocation

More Related