Post on 17-Jan-2016
transcript
Chapter 4: Distributed Objects &
Remote Invocation
Distributed Objects & Remote Invocation
Introduction
Communication between distributed objects
Remote procedure call
Events & notification
Objectives To study communication between distributed objects and the integration of remote method invocation into a programming language.
To explore the extension of the event-based programming model in order to apply to distributed event-based programs.
Introduced communication between distributed objects by means of remote method invocation (RMI)
Objects that can receive remote method invocation are called remote objects
~ implement a remote interface
RMI have different semantic from local call because of possibility of independent failure of invoker & invoked objects
Remote procedure call ~ RMI as procedure call to object invocation
Introduction
Concern with programming model in DS:
Remote procedure call model: ~allow client program to call procedure in server program running in separate process and generally in different computer from client.
Object based programming model: ~ allow objects in different processes to communicate with one another by means of RMI.
Introduction (cont).
Remote method invocation (RMI)- extension of local method invocation - allows an object living in one process to invoke the methods of an object living in another process
Introduction (cont).
Distributed event-based programming model:
~ allow objects to subscribe to event occurring at remote objects of interest & in turn to receive notifications when such event occur.~ events and notification provide a way for heterogeneous objects to communicate with one another asynchronously.
Introduction (cont).
Figure 5.1Middleware layers
Applications
Middlewarelayers Request reply protocol
External data representation
Operating System
RMI, RPC and events
Software that provides a programming model above the basic building blocks of processes and
message passing is called middleware.
Middleware Programming Models
Distributed objects & remote object invocation is model explained as illustrated by Java RMICORBA:~ it provides remote object invocation
between a client program written in one language and a server program written in another language
~ another language commonly used is C++Other programming models~ remote event notification~ remote SQL access~ distributed transaction processing
InterfaceTo control the possible interactions between module-explicit interface is designed for each module.Specifies the procedures and variables that can be access from other module.2 types of interface in DS :
Service interfaces~ Used in client-server model~ Refer to the specification of procedures offered by
server and define input and output arguments. ~ Each server provides a set of procedures for client use
Fig. 5.2: CORBA IDL Examplestruct Person {
string name; string place;long year;
} ;interface PersonList {
readonly attribute string listname;void addPerson(in Person p) ;void getPerson(in string name, out
Person p);long number();
};
Remote interface: ~ specifies the methods of an object available for remote invocation
~ Can pass object as arguments and result of methods~ an interface definition language (or IDL) is used to specify remote interfaces. Ex: the above in CORBA IDL.~Java RMI have a class for Person, but CORBA has a struct
parameters are in, out or inout
remote interface
remote interface defines methods for RMI
CORBA has a struct
Communication Between Distributed
Object Model
Communication between Distributed Object
Object based model for DS extend oriented programming language to make it apply the to distributed objects.We address communication between distributed objects by mean RMI. The material is presented under:~ the object model~ distributed objects~ the distributed object model~ design issue~implementation~ distributed garbage collection
Communication between Distributed Object (Cont.)
Object ModelCommunicate with other by invoking their methodsCan encapsulate(summarize) their data and codeConsists of collection of interacting object :
- Object references - object can be accessed via object ref. - first class values, assigned to variables, pass as
arguments, and return as result.- Interfaces - definition of the signatures of a set of methods without
specifying their implementation. - object provide interface if its class contains code that implement the method of that interface.
Communication between Distributed Object (Cont.)
- Action - is initiated by an object invoking a method in a another object. - Invocation included additional info needed to carry out
the method.- Exception - provide the clean way to deal with error without
complicating the code. - throw and catches – define a block of code- Garbage collection - freeing the space occupied by object when they are no longer needed.
Communication between Distributed Object (Cont.) Distributed object:
~ the state of an object consist of the value of its intense value.
~ adopt the client server architecture~ objects are managed by server~ clients invoke method by using RMI~ in RMI, client’s request to invoke a method of an object is
sent in a message to the server managing the object.~ execute method of object at server – result is return to
client in a another message ~ object in server are allowed to become client of object
in other server.
Communication between Distributed Object (Cont.)The distributed object model:
~each process contains a collection of object.~can receive both ; local & remote invocation.RMI = method invocation between object in different process, whether in comp or not LMI = method invocation between object in same process
invocation invocation
remote
invocationremote
local
local
local
invocation
invocation
AB
C
D
E
F
each process contains objects, some of which can receive remote invocations, others only local invocationsthose that can receive remote invocations are called remote objects.- Object B and F are remote object.- Object C must have reference to object E to invoke their methods.objects need to know the remote object reference of an object in another process in order to invoke its methods.- A remote object for B must be available to A.remote interface specifies which methods can be invoked remotely.- Object B and F must have remote interface.
Fig. 5.3: Remote & local method invocations
Communication between Distributed Object (Cont.)
Remote Interface - specifies the methods of an object that are available for invocation
by remote objects in other processes. - Interface definition languages (or IDLs) are designed to allow
objects in different languages to invoke one another. - Object in other process can remote only the method belong to it
remote interface.- The semantics of parameter passing are adjusted to suit the
separation of client and remote object.- Input and output parameters are used, and pointers cannot be
passed.
Communication between Distributed Object (Cont.)Remote Object
- Object that can receive remote invocations.- one that can be invoked from another process.
Remote Object Reference- an identifier for a remote object - used to refer to a particular remote invocation.- Diff from local object references.- can be passed as an argument or result of a remote invocation. - clients need it in order to invoke remote objects.- may be obtained from a binder or as the result of an RMI.
Fig. 5.4: A remote object & its remote interface
interfaceremote
m1m2m3
m4m5m6
Data
implementation
remote object
{ of methods
-Object in other processes can invoke only the methods that belong to it remote interface
Communication between Distributed Object (Cont.)Actions in distributed object system:- Object involved in a chain of related invocations may be
located in different process or different computer- When invocation crossed boundary of a process or
computer, RMI is used and remote references of the object must available to invoker.
- Object A needs to hold a remote object reference to object B.(refer to Fig 5.3)
- Object A may obtain a remote reference to object F from object B.(refer to Fig 5.3)
Fig. 5.5: Instantiation of remote objects
C
NM
Kinvocationremote
invocationremote
L
instantiateinstantiate
Distributed application may provide remote object with method for instantiating objects which can be accessed by RMI.Example:
~ Object L contains a method for creating remote object~ Remote invocation from method C and K could lead to instantiation
of the object M and N respectively.
Communication between Distributed Object (Cont.)Garbage collection distributed object system:
- Allow garbage collection of remote object - Cooperating existing local garbage collector & added module.
Exception: - process contains remote object – crashed/to busy/result
message lost -must be able to raise exception.
Design issues for RMI
The choices of invocation semantic
The level of transparency that is desirable for RMI
RMI Invocation Semantics
Apply request-reply protocol.DoOperation implemented in different way to provide different delivery guarantees are:
Retry request message – retransmit the request message until either a reply is received or the server is assumed to have failedDuplicate filtering – when retransmission, it filter out duplicate request at server.Retransmission of result – keep history of result message, to enable lost result to be retransmitted without executing the operation at server.
Fig. 5.6: Invocation Semantics
Fault tolerance measures Invocation semantics
Retransmit request message
Duplicate filtering
Re-execute procedure or retransmit reply
No
Yes
Yes
Not applicable
No
Yes
Not applicable
Re-execute procedure
Retransmit reply At-most-once
At-least-once
Maybe
Local invocations are executed exactly once
The Request-reply protocol can apply fault-tolerance measures
Invocation Semantics: Failure Model
Maybe, At-least-once and At-most-once can suffer from crash failures when the server containing the remote object fails.
Maybe - remote method my be executed once or not at all- arise when none of the fault tolerance measures is applied- if no reply, the client does not know if method was executed or not~ omission failures if the invocation or result message is lost
- no retries after timeout ~ 2 situation (invocation message lost, method not executed or method
executed, result message lost) give impact to crash failure.- use fro apps which occasional failed invocation acceptable
Invocation Semantic: Failure Model
At-least-once - the client gets a result (and the method was executed at least once) or an
exception (no result)- suffer from arbitrary failures. If the invocation message is retransmitted, the remote object may execute the method more than once, possibly causing wrong values to be stored or returned. - if idempotent operations are used, arbitrary failures will not occur- idempotent operations, one that can be performed repeatedly with the
same effect although it have perform exactly once.- use in Sun RPC
At-most-once - the client gets a result (and the method was executed exactly once) or an exception (instead of a result, in which case, the method was executed once or not at all)- achieved by using all fault tolerance measure ~ prevent arbitrary failure – ensure each RMI method execute only once.- applied in JAVA RMI and CORBA, but CORBA allows maybe – requested method that do return result.
Call semantics cannot be `exactly once'. The
semantics achieved (e.g. `at-most-once') depends on the
approach to dealing with failures of processes and
communication.
Transparencyoriginator aimed to make RPC same as LPCHide marshalling, message passing, task of locating and contacting a remote objectRMI more vulnerable to failure than local invocation .Why?RMI latency is greater than local- to minimize, caller able to abort RPC that taking a lot of time.To differentiate the syntax of RMI with LMI
Implementation of RMI
Roles of components that involve in implementation of RMI
Implementation of RMI(cont.)
Communication Module- Define the client and the server- Use only first 3 items – specify msg type, requestID and remote reference.- Responsible to provide a specified invocation semantics
Remote reference module- responsible to translate between local and remote object references- create remote object reference- each process have remote object table
Implementation of RMI(cont.)
Servant - an instance of class which provide the body of remote object- handles the remote request pass and live within a server process- deleted after being used.
The RMI software- consist a layer of software between apps level object-
communication- remote reference modules- Proxy
~ make RMI transparent to client- behave like local object and hide details- Dispatcher
~ receive request msg from comm. module ~ use methodID to select appropriate method in
skeleton
object A object Bskeleton
Requestproxy for B
Reply
CommunicationRemote Remote referenceCommunication
module modulereference module module
for B’s class& dispatcher
remoteclient server
RMI software - between application level objects &communication & remote reference modules
carries out Request-reply protocol
translates between local and remote object references and creates remote object references. Uses remote object table
Fig. 5.7: The role of proxy & skeleton in remote method invocation
Proxy - makes RMI transparent to client. Class implements remote interface. Marshals requests & unmarshals results.Forward requestDispatcher - gets request from communication module and invokes method in skeleton (using methodID in message).
Skeleton - implements methods in remote interface. Unmarshals requests and marshals results. Invokes method in remote object.
Distributed Garbage Collection
To ensure a local or remote reference to an object remain exist if still in useAs soon no object any longer hold a reference to it, the object will be collected and memory uses is recovered.
Remote Procedure Call Very similar to remote method
invocation Generally implemented in request-reply
protocol Client program calls a procedure in
another program running in server process
Its service interface have lack of ability to create new instance of object – do not support remote object references
Implemented over request –reply protocol- same content but object reference field is omitted(lost).
Remote Procedure Call
Client Stub procedure- Similar to proxy method- Behave like local procedure to client- Marshall procedure identifier and the argument in request msg
Server stub procedure- similar to skeleton method- unmarshals argument in the request msg, call coresponding service procedure and marshal return value for reply msg
Fig. 5.8: Role of client & server stub procedures in RPC in the context of a procedural language
client
Request
Reply
CommunicationCommunication
module module dispatcher
service
client stub
server stubprocedure procedure
client process server process
procedureprogram
Distributed event-based systems
- use the publish-subscribe paradigm - event-generating object publishes type of events that will be available for other objects.
- Object that receive notification of publishes event subscribe the types of their interest event. - 2 main characteristics: i) heterogeneous; ii) asynchronous- useful for communication between heterogeneous components - their asynchronous nature allows publishers and subscribers to
be decoupled.
Events And Notification
Generally implemented in request-reply protocol
Fig. 5.10: Dealing Room SystemDealer’s computer
Informationprovider
Dealer
External
source
External
source
Informationprovider
Dealer
Dealer
Dealer
Notification
Notification
Notification
Notification
NotificationNotification
Notification
Notification
Dealer’s computer
Dealer’s computerDealer’s computer
NotificationNotification
The figure shows an example of distributed event-based systems.
- Allows user to see the latest info about the market price- Market price are represent by an object with instance variables.- Info have been updated and collected by information provider.
- 2 different task create here : i. - information provider update to the appropriate stock object - update to stock object regards as an event - notify all the dealer who have subscribe - for each external source there will be separate info provider process
ii. - dealer create object to represent named stock - local object subscribe to the relevant info provider object - receive info sent to it in notification and display to user
Dealing Room System
Fig. 5.11: Architecture for distributed event notification
subscriberobserverobject of interest
Event service
object of interest
object of interest observer
subscriber
subscriber
3.
1.
2. notification
notification
notification
notification
• The object of interest – an object that experience change of state• Event – occur at an object of interest as the result of completion of
method execution• Notification – an object that contain info about an event• Subscriber - an object that subscribe to some type of event in
another object.• Observer object – to decouple an object of interest of its
subscriber.• Publisher – declare it will generate notification of particular types
of an event. can be object of interest or an observer.
1. An object of interest inside the event service without an observer. It send notifications directly to the subscribers.
2. inside the event service with an observer. The object interest send notification via observer.
3. outside the an event service. observer queries the object of interest to discover when event occur and observer sends notification
Distributed event notification