Post on 17-Jan-2016
transcript
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
IntroductionDistributed ObjectsRemote InvocationCase Study: CORBA
Content
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.
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 Fractal
IntroductionComponent-based middleware
IntroductionDistributed ObjectsRemote InvocationCase Study: CORBA
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.
Distributed ObjectsDistributed Object Model
Distributed ObjectsDistributed Object Model
invocation
invocation
remote
invocation
remote
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.
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
interfaceremote
m1
m2
m3
m4m5m6
Data
implementation
remoteobject
{ of methods
A remote object and its remote interface
IntroductionDistributed ObjectsRemote InvocationCase Study: CORBA
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
Remote InvocationRequest-reply protocols
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
Remote InvocationRequest-reply protocols
requestIdMessage identifierA unique identifier to the sender, and the
distributed system
Remote 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 request
Remote 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.html
Remote InvocationRequest-reply protocols
Source and further reading : http://www3.ntu.edu.sg/home/ehchua/programming/webprogramming/http_basics.html
Remote InvocationRequest-reply protocols
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
Remote InvocationRemote Procedure Call
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
Remote InvocationRemote Procedure Call
Programming with interfaces
Remote InvocationRemote Procedure Call
RPC call semantics Possible 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 call
RPCs are more vulnerable to failure than local ones – as in involve with network. Network or server failure?
Remote InvocationRemote Procedure Call
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 InvocationRemote Procedure Call
Remote 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 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
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 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 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 invocation
Remote 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 invocations
Remote InvocationRemote Method Invocation
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
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 Invocation
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).
Remote InvocationRemote Method Invocation
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.
Remote InvocationRemote Method Invocation
RMI 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 proxy’s method.
Remote InvocationRemote Method Invocation
RMI 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 Invocation
IntroductionDistributed ObjectsRemote InvocationCase Study: CORBA
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.
Case Study: CORBAThe Components of CORBA
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.
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 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
Case Study: CORBAThe Components of CORBA
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.
Case Study: CORBAThe Components of CORBA
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.
Case Study: CORBAThe Components of CORBA
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
End of the chapter…
Thank you