Distributed Objects and Remote Invocation

of 70/70
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: (i)http://faculty.ksu.edu.sa/metwally/Pages/IS335.aspx (ii) http:// www.cdk5.net/wp/preface (iii) www.pcs.cnu.edu/~mzhang/CPSC450_550/2003CaseStudy/ CORBA_Presentation_JeffOliver.ppt
  • date post

    23-Feb-2016
  • Category

    Documents

  • view

    43
  • download

    0

Embed Size (px)

description

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: - PowerPoint PPT Presentation

Transcript of Distributed Objects and Remote Invocation

Slide 1

Distributed Objects and Remote InvocationSource:George Colouris, Jean Dollimore, Tim Kinderberg & Gordon Blair (2012). Distributed Systems: Concepts & Design (5th Ed.). Essex: Addison-WesleyChapter 8 & Chapter 5

Power point presentation was adapted from:http://faculty.ksu.edu.sa/metwally/Pages/IS335.aspxhttp://www.cdk5.net/wp/prefacewww.pcs.cnu.edu/~mzhang/CPSC450_550/2003CaseStudy/CORBA_Presentation_JeffOliver.ppt

IntroductionDistributed ObjectsRemote InvocationCase Study: CORBAContentIntroductionDistributed ObjectsRemote InvocationCase Study: CORBAContentIntroduction

This Chapterallows 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 paradigmIntroductionDistributed 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 CORBAIntroductionDistributed Object MiddlewareTo 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.

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

IntroductionComponent-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 FractalIntroductionComponent-based middlewareIntroductionDistributed ObjectsRemote InvocationCase Study: CORBAContentDistributed object middlewareto 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 ObjectsDistributed ObjectsTypes of Distributed Objects

Inter-object communication - mechanisms for objects to communicate in the distributed environmentLifecycle management - the creation, migration and deletion of objectsActivation 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 ObjectsThe Functionalities of Distributed ObjectsPersistence 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 ObjectsThe Functionalities of Distributed Objects

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 clients 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 ObjectsDistributed Object ModelDistributed 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.

Distributed ObjectsDistributed Object ModelDistributed ObjectsDistributed Object Model

invocationinvocationremoteinvocationremotelocallocallocalinvocationinvocationABCDEFRemote and local method invocationsEach 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 ObjectsDistributed 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 ObjectsDistributed Object Model

Distributed ObjectsDistributed Object Model

interfaceremotem1m2m3m4m5m6Dataimplementationremoteobject{of methodsA remote object and its remote interfaceIntroductionDistributed ObjectsRemote InvocationCase Study: CORBAContenthow processes (or entities at a higher level of abstraction such as objects or services) communicate in a distributed systemRemote InvocationIntroductionsupport the roles and message exchanges in typical client-server interactionsA synchronous communication - the client process blocks until the reply arrives from the serverA reliable communication protocol - the reply from the server is an acknowledgement to the client that message has been receivedRemote InvocationRequest-reply protocolsBased on 3 communication primitives - doOperation, getRequest and sendReplyRemote InvocationRequest-reply protocols

* Premitives in this context refer to basic elements of communication24doOperation methodIs used by clients to invoke remote operationsIts arguments specify the remote server, the operation to invokeIts result is a byte array containing the replygetRequest is used by a server process to acquire service requestssendReplyIs used by the server to send the reply message to the clientRemote InvocationRequest-reply protocols

requestIdMessage identifierA unique identifier to the sender, and the distributed systemRemote InvocationRequest-reply protocols

Handling issues in the Request-reply protocolsTimeout - return the doOperation to the client indicating that it has failed or send multiple doOperation until response is received Duplicate request messages filter and discard the same doOperation with same requestId. Lost reply messages send the copy of results, re-execute the requestRemote InvocationRequest-reply protocols

3 types of request behaviors using UDP:the request (R) protocolthe request-reply (RR) protocolthe request-reply-acknowledge reply (RRA) protocol.

Remote InvocationRequest-reply protocols

Request-reply protocols using TCPallows arguments and results of any size to be transmittedarguments and results are sent in streams between the client and serverIt is a reliable protocol, hence, retransmission of messages and filtering of duplicates are not necessary

Remote InvocationRequest-reply protocols

Request-reply protocols using HTTPImplemented over TCPuses 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 InvocationRequest-reply protocols

HTTP methods: resource- http://computing.dcu.ie/~humphrys/Notes/Networks/java.htmlRemote InvocationRequest-reply protocols

Source and further reading : http://www3.ntu.edu.sg/home/ehchua/programming/webprogramming/http_basics.htmlRemote InvocationRequest-reply protocols

Examples of other http status codes:

Remote InvocationCodeDescription200OK201Created400Bad request401Unauthorized403Forbidden.Request-reply protocols

Design issues for RPCProgramming with interfacesRPC call semanticsTransparencyRemote InvocationRemote Procedure CallProgramming with interfacesControl the interactions between modules in a programming languagesinterface of a module specifies the procedures and the variables that can be accessed from other modulesmodules can run in separate processes in distributed systemsservice interface - the specification of the procedures offered by a server, defining the types of the arguments of each of the proceduresRemote InvocationRemote Procedure CallProgramming with interfacesAn 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 languages normal use of parametersmany existing useful services are written in C++ and other languagesInterface definition languages (IDLs) are designed to allow procedures implemented in different languages to invoke one anotherRemote InvocationRemote Procedure CallProgramming with interfaces

Remote InvocationRemote Procedure Call

RPC call semanticsPossible implementation of sending request to remote host

Remote InvocationRemote 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 callRPCs are more vulnerable to failure than local ones as in involve with network. Network or server failure?Remote InvocationRemote Procedure CallImplementation of RPCRPC is generally implemented over a request-reply protocolThe client that accesses a service includes one stub procedure for each procedure in the service interfacestub 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 serverRemote InvocationRemote Procedure CallRemote InvocationRemote Procedure Call

Remote method invocation (RMI) is an improved version of RPCa calling object can invoke a method in a potentially remote objectThe similarities in RPC and RMIboth support programming with interfacesboth typically constructed on top of request-reply protocols and can offer a range of call semantics such as at-least-once and at-most-onceboth offer a similar level of transparency that is, local and remote calls employ the same syntaxRemote InvocationRemote Method InvocationThe differences between RMI and RPCRMI allows the programmer to pass parameters not only by value, as input or output parameters, but also by object reference

Remote InvocationRemote Method Invocation

Design issues for RMIProgramming with interfaces, call semantics and level of transparency (please refer to RPC)Object modelDistributed objectsDistributed object models

Remote InvocationRemote Method Invocation

The object modelObject references - can be accessed via object referencesInterfaces - provides a definition of the signatures of a set of methods (the types of their arguments, return values and exceptions) without specifying their implementationActions - is initiated by an object invoking a method in another objectExceptions - provide a clean way to deal with error conditions without complicating the codeGarbage Collection detect an object automatically when it is no longer accessible. It recovers the space and makes it available for allocation to other objectsRemote InvocationRemote Method Invocation

Distributed ObjectsDistributed object systems may adopt the client-server architectureObjects are managed by servers and their clients invoke their methods using remote method invocationRemote InvocationRemote Method Invocation

The distributed object modelEach process contains a collection of objects, some of which can receive both local and remote invocations, whereas the other objects can receive only local invocationsRemote InvocationRemote Method Invocation

The distributed object modelTwo components of distributed object modelRemote object references - an identifier that can be used throughout a distributed system to refer to a particular unique remote objectRemote 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 InvocationRemote Method Invocation

Remote InvocationRemote Method Invocation

RMI ImplementationSeveral separate objects and modules are involved to achieve a remote method invocation

Remote InvocationRemote Method Invocation

RMI ImplementationCommunication modules:Responsible for providing a specified invocation semantics.Carry out the request-reply protocol to transmit request and reply messages between the cooperating server and client.Use only the first three items of the request and reply messages: message type, request id, and the invoked remote object reference.Select the dispatcher software for the invoked object class in the server.

Remote InvocationRemote Method InvocationRMI ImplementationRemote reference modules:Translate between local and remote object references and create remote object references. Have a remote object table in each process to support the translation.An entry for all the remote objects held by the server in its table.An entry for each local proxy held by the client in its table.Create a remote object reference and add it to the table when a remote object is passed in a request or a replay message for the first time.Translate the remote object reference to the corresponding local object reference which refer either to a remote object (in the server) or to a proxy (in the client).

Remote InvocationRemote Method InvocationRMI ImplementationRMI Software:Proxy:Make remote method invocation transparent to clients by behaving like a local object to the invoker.Forward the call in a message to the remote object and hiding all in-between operations (send, receive, marshalling, and unmarshalling) from the client.A client has one proxy for each remote object to hold its remote reference and implement the methods in its remote interface. Marshal a reference to the target object, its own methodId and its arguments into a request message and send it to the target then await the reply message to unmarshal it and return the result to the invoker.

Remote InvocationRemote Method InvocationRMI ImplementationRMI Software:Dispatcher:A server has one dispatcher for each class representing a remote object.Receive the request message from the communication module and use the methodId to select the appropriate method in the skeleton and passing on the request message.Skeleton:Each class representing a remote object has a skeleton in the server to implement each method in the remote interface.Unmarshal the argument in the request message and invoke the corresponding method in the remote object.Await the invocation to complete to marshal the result in the reply message to the client proxys method.

Remote InvocationRemote Method InvocationRMI ImplementationRMI Software:The classes of the proxy, skeleton, and dispatcher used in RMI are generated automatically by an interface complier.The server program contains the classes for the dispatchers and skeletons together with the implementations of the classes of all remote objects that it supports servant classes.The client program contains the classes of the proxies for all the remote objects that it will invoke and use a binder to look up remote object references.

Remote InvocationRemote Method InvocationIntroductionDistributed ObjectsRemote InvocationCase Study: CORBAContentIn 1991, the CORBA (Common Object Request Broker Architecture) specification was developed by the Object Management Group (OMG) . CORBA was developed based on the object request broker (ORB), that intended to help a client to invoke a method on an object (following the RMI style)CORBA is a language-independent RMI

Case Study: CORBACORBA4 components of CORBAAn interface definition language (IDL)An architecture The General Inter-ORB Protocol (GIOP)The Internet Inter-ORB Protocol (IIOP)

Case Study: CORBAThe Components of CORBAAn interface definition language (IDL)Provides an interface consisting of a name and a set of methods that a client can request.IDL supports fifteen primitive types, constructed types and a special type called Object. Primitive types: short, long, unsigned short, unsigned long, float, double, char, boolean, octet, and any. Constructed types such as arrays and sequences must be defined using typedefs and passed by value.Interfaces and other IDL type definitions can be grouped into logical units called modules.

Case Study: CORBAThe Components of CORBAGIOP: General Inter-ORB Protocol are the standards (included in CORBA 2.0), which enable implementations to communicate with each other regardless of who developed it.IIOP: Internet Inter-ORB Protocol is an implementation of GIOP that uses the TCP/IP protocol for the Internet.

Case Study: CORBAThe Components of CORBA

ORB core Object Adapter (server)Skeletons (server) Client Proxies / Stubs

Case Study: CORBAThe Components of CORBA

The architectureORB core Carries out the request-reply protocol between client and server.Provide operations that enable process to be started and stopped.Provide operations to convert between remote object references and strings.

Case Study: CORBAThe Components of CORBA

The architectureSkeletons (server) An IDL compiler generates skeleton classes in the servers language. Dispatch RMIs to the appropriate servant class. Client Proxies / StubsGenerated by an IDL compiler in the client language. A proxy class is created for object oriented languagesStub procedures are created for procedural languages. Both are responsible for marshalling and unmarshalling arguments, results and exceptions

Case Study: CORBAThe Components of CORBAThe architectureImplementation RepositoryActivates registered servers on demand and locates servers that are currently running.Interface RepositoryProvides information about registered IDL interfaces to the clients and servers that require it. Optional for static invocation; required for dynamic invocation.

Case Study: CORBAThe Components of CORBAGIOPGeneral Inter-ORB Protocol are the standards (included in CORBA 2.0), which enable implementations to communicate with each other regardless of who developed it.

IIOPInternet Inter-ORB Protocol is an implementation of GIOP that uses the TCP/IP protocol for the Internet.

Case Study: CORBAThe Components of CORBAServer must include IDL interfaces in the form of servant classes. An interface compiler generates:the program(Java or C++) interfacesserver skeletons for each IDL interfaceproxy classes (or client stubs) for each IDL interfaceA Java / C++ class for IDL defined structhelper classes for each IDL defined type

Case Study: CORBAHow to Use CORBAServer Creates and initializes the ORBCreates an instance of servant class, which is registered with the ORB. Servant class extends the corresponding skeleton class and implementation methods of an IDL interface.Makes a CORBA objectClientCreates and initializes the ORBContacts Naming service to get reference to the serverInvokes methods on the server

Case Study: CORBAHow to Use CORBA

Used primarily as a remote method invocation of a distributed client server system. Can communicate between clients and servers on different operating systems and implemented by different programming languages (Java cannot do this).Has many standards and services useful in implementing distributed applications.Process can be both server and client to another serverIdeal for a heterogeneous distributed system like the Internet.

Case Study: CORBAApplication of CORBAPlease refer to the following websites:http://www.dee.ufma.br/~dlopes/course/CORBA/examples_CORBA_in_java.htmhttp://staff.science.uva.nl/~jvgemert/pub/learncorba.pdfhttp://www.wiley.com/legacy/compbooks/brose/chapter4.htmlwww.unf.edu/~sahuja/cis6302/corbaexample.doc

Case Study: CORBAExamples of CORBA ImplementationEnd of the chapterThank you