790 likes | 1.08k Views
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:
E N D
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
Content • Introduction • Distributed Objects • Remote Invocation • Case Study: CORBA
Content • Introduction • Distributed Objects • Remote Invocation • Case Study: CORBA
Introduction This Chapter
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
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
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.
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.
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
Content • Introduction • Distributed Objects • Remote Invocation • Case Study: CORBA
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.
Distributed Objects • Types of Distributed Objects
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
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
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.
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.
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
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.
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.
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
Content • Introduction • Distributed Objects • Remote Invocation • Case Study: CORBA
Remote Invocation • Introduction • how processes (or entities at a higher level of abstraction such as objects or services) communicate in a distributed system
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
Remote Invocation • Request-reply protocols • Based on 3 communication primitives - doOperation, getRequest and sendReply
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
Remote Invocation • Request-reply protocols • requestId • Message identifier • A unique identifier to the sender, and the distributed system
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
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.
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
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
Remote Invocation • Request-reply protocols • HTTP methods: resource- http://computing.dcu.ie/~humphrys/Notes/Networks/java.html
Remote Invocation • Request-reply protocols • Source and further reading : http://www3.ntu.edu.sg/home/ehchua/programming/webprogramming/http_basics.html
Remote Invocation • Request-reply protocols • Examples of other http status codes:
Remote Invocation • Remote Procedure Call • Design issues for RPC • Programming with interfaces • RPC call semantics • Transparency
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
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
Remote Invocation • Remote Procedure Call • Programming with interfaces
Remote Invocation • Remote Procedure Call • RPC call semantics • Possible implementation of sending request to remote host
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?
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
Remote Invocation • Remote Procedure Call
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
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
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
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
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
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
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
Remote Invocation • Remote Method Invocation
Remote Invocation • Remote Method Invocation • RMI Implementation • Several separate objects and modules are involved to achieve a remote method invocation