distributed objects and remote invocation

Distributed Objects and Remote Invocation

Source: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:(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

http://www.cdk5.net/wp/preface

http://www.cdk5.net/wp/preface

IntroductionDistributed ObjectsRemote InvocationCase Study: CORBA

Content

Introduction

This Chapter

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

IntroductionDistributed 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

IntroductionDistributed Object 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.

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.


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

Distributed 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 Objects

Distributed ObjectsTypes 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 ObjectsThe 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 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 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 ObjectsDistributed 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.



invocation

invocationremote

invocationremote

local

local

local

invocation

invocation

AB

C

D

E

F

Remote and local method invocations

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.


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.



interfaceremote

m1m2m3

m4m5m6

Data

implementation

remoteobject

{ of methods

A remote object and its remote interface


Content

how processes (or entities at a higher level of abstraction such as objects or services) communicate in a distributed system

Remote InvocationIntroduction

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 InvocationRequest-reply protocols

Based on 3 communication primitives - doOperation, getRequest and sendReply


doOperation methodIs used by clients to invoke remote operationsIts arguments specify the remote server, the

operation to invokeIts result is a byte array containing the reply

getRequest is used by a server process to acquire service requests

sendReplyIs used by the server to send the reply message to

the client


requestIdMessage identifierA unique identifier to the sender, and the

distributed system


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 request


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

protocol.


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


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


HTTP methods: resource- http://computing.dcu.ie/~humphrys/Notes/Networks/java.html


Source and further reading : http://www3.ntu.edu.sg/home/ehchua/programming/webprogramming/http_basics.html


Examples of other http status codes:

Remote Invocation

Code Description

200 OK

201 Created

400 Bad request

401 Unauthorized

403 Forbidden

… …

… ….

Request-reply protocols

Design issues for RPCProgramming with interfacesRPC call semanticsTransparency

Remote InvocationRemote Procedure Call

Programming 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 modules

modules 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 procedures


Programming 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 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


Programming with interfaces


RPC call semantics Possible implementation of sending request to remote

host


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?


Implementation 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 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 method invocation (RMI) is an improved version of RPCa calling object can invoke a method in a potentially

remote objectThe similarities in RPC and RMI

both 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-once

both offer a similar level of transparency – that is, local and remote calls employ the same syntax

Remote InvocationRemote Method Invocation

The 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


Design issues for RMIProgramming with interfaces, call semantics and

level of transparency (please refer to RPC)Object modelDistributed objectsDistributed object models


The object modelObject 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


Distributed ObjectsDistributed object systems may adopt the client-

server architectureObjects are managed by servers and their clients

invoke their methods using remote 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 invocations


The distributed object modelTwo 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


RMI ImplementationSeveral separate objects and modules are involved

to achieve a remote 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.


RMI 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).


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



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 proxy’s method.



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.



Content

In 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: CORBACORBA

4 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 CORBA

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


GIOP: 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.


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


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.


The architectureSkeletons (server)

An IDL compiler generates skeleton classes in the server’s language.

Dispatch RMI’s to the appropriate servant class. Client Proxies / Stubs

Generated 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


The architectureImplementation Repository

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


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


Server 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 CORBA

Server 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 object

ClientCreates 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 CORBA

Please refer to the following websites:http://www.dee.ufma.br/~dlopes/course/CORBA/

examples_CORBA_in_java.htmhttp://staff.science.uva.nl/~jvgemert/pub/learncor

ba.pdfhttp://www.wiley.com/legacy/compbooks/brose/c

hapter4.htmlwww.unf.edu/~sahuja/cis6302/corbaexample.doc

Case Study: CORBAExamples of CORBA Implementation

http://www.dee.ufma.br/~dlopes/course/CORBA/examples_CORBA_in_java.htm

http://www.dee.ufma.br/~dlopes/course/CORBA/examples_CORBA_in_java.htm

http://staff.science.uva.nl/~jvgemert/pub/learncorba.pdf

http://staff.science.uva.nl/~jvgemert/pub/learncorba.pdf

http://www.wiley.com/legacy/compbooks/brose/chapter4.html

http://www.wiley.com/legacy/compbooks/brose/chapter4.html

http://www.unf.edu/~sahuja/cis6302/corbaexample.doc



End of the chapter…

Thank you

distributed objects and remote invocation

Documents

objectbased middleware

objects objects

object interfaces

compatible object

objectbased systems

middleware solutions

programming complexity

distributed system developers