DistributedObjectsandRemoteInvocation

ProgrammingModelsforDistributedApplications

ExtendingConventionalTechniques
Theremoteprocedurecallmodelisanextensionofthe
conventionalprocedurecall
Theremotemethodinvocation(RMI)usesanOObased
modeltoallowobjectsinoneprocessspaceinvoke
methodsinanotherprocessspace
Thedistributedeventbasedmodelextendseventdriven
paradigms

RelationshiptoMiddleware

Applications
RMI,RPCandevents
Requestreplyprotocol
Externaldatarepresentation
OperatingSystem

Middleware
layers

Interfaces
Theinterfacespecifiestheproceduresandthevariables
thatcanbeaccessedfromotherprocesses
Solongasitsinterfaceremainsthesame,the
implementationmaybechangedwithoutaffectingtheusers
ofthemodule

InterfacesinDistributedSystems
Modulesruninseparateprocesses
Directaccesstovariablesisnotpossible
Callbyvalueandcallbyreferencearenotsuitablewhen
thecallerandtheprocedureareindifferentprocesses
Pointerscannotbepassedasargumentsnorreturnedas
resultsofcallstoremotemodules

InputandOutputParameters
InputParametersarepassedtotheremotemodule
OutputParametersarereturnedinthereplymessage

MoreonInterfaces
ServiceInterfacesrefertothespecificationofthe
proceduresofferedbyaserver,definingthetypesofthe
inputandoutputargumentsofeachoftheprocedures
RemoteInterfacesspecifythemethodsofanobjectthat
areavailableforinvocationbyobjectsinotherprocesses,
definingthetypesoftheinputandoutputargumentsofeach

KeyPoint

Neitherserviceinterfacesnorremoteinterfacesmay
specifydirectaccesstovariables

InterfaceDefinitionLanguages(IDLs)
Weneedanadequatenotationfordefininginterfaces
IDLsaredesignedtoallowobjectsimplementedindifferent
languagestoinvokeoneanother

ExampleIDLfromCORBA
//InfilePerson.idl
structPerson{
stringname;
stringplace;
longyear;
};
interfacePersonList{
readonlyattributestringlistname;
voidaddPerson(inPersonp);
voidgetPerson(instringname,outPersonp);
longnumber();
};

IDLTechnologies
CORBA'sIDL
Sun'sXDR
WSDL(webservicesdescriptionlanguage)
OSF'sDCE(RPC)
Microsoft'sDCOMIDL

CommunicationBetweenDistributed
Objects
TheObjectModel
DistributedObjects
TheDistributedObjectModel
DesignIssues
Implementation
DistributedGarbageCollection

RequirementsoftheObjectModel
Withinadistributedsystem,anobject'sdatashouldonly
beaccessibleviaitsmethods
Objectscanbeaccessedviaobjectreferences
Interfacesprovideadefinitionofthesignaturesofasetof
methods
Anactionisinitiatedbyanobjectinvokingamethodin
anotherobject

InvokingaMethod
Thestateofthereceivermaybechanged
Anewobjectmaybeinstantiated
Furtherinvocationsonmethodsinotherobjectsmaytake
place(resultinginachainofrelatedmethodinvocations)

MoreontheObjectModel
Exceptionsprovideacleanwaytodealwitherror
conditionswithoutcomplicatingcode
Eachmethodheadingexplicitlylistsasexceptionsthe
errorconditionsitmightencounter
GarbageCollectionautomaticallydetectingwhenan
objectisnolongerneededandfreeingitsspace

DistributedObjects
Thephysicaldistributionofobjectsintodifferentprocesses
orcomputersinadistributedsystemisanaturalextension
ofthelogicalpartitioningofobjectbasedprograms
Thisenforcesencapsulation
Concurrencycontrolsareanimportantconsideration

TheDistributedObjectModel
Thegoalistoextendtheobjectmodeltomakeit
applicabletodistributedobjects
Localmethodinvocationsoccurbetweenobjectsinthe
sameprocess
Remotemethodinvocationsoccurbetweenobjectsin
different(possibleremote)processes

LocalandRemoteMethodInvocations

local

remote
invocation
A

C
local E
invocation
invocation
local
invocation
D

remote
invocation

FundamentalConcepts
TheRemoteObjectReferenceobjectscaninvokethe
methodsofaremoteobjectiftheyhaveaccesstoits
remoteobjectreference(identifier)
TheRemoteInterfaceafacilitywherebyanobject
specifieswhichofitsmethodscanbeinvokedremotely

TheRemoteObjectReference
Anidentifierthatcanbeusedthroughoutadistributed
systemtorefertoaparticularuniqueremoteobject
Theremoteobjectreferenceisspecifiedbytheinvoker
Remoteobjectreferencescanbepassedasarguments
andreturnedasresults

TheRemoteInterface
Theremoteinterfacespecifiesthemethodsthattheremote
objectimplements
InJava,wecanusepublicinstancemethods
InCORBA,anylanguagecanbeusedaslongasthere's
anIDLcompileravailable

RemoteObjectandInterfaces

remote object

remote
interface

Data

m1
m2
m3

implementation
ofmethods

m4
m5
m6

DesignIssuesforRMI
RMIisanaturalextensionoflocalmethodinvocation
DesignIssuethechoiceofinvocationsemanticslocal
invocationsareexecutedexactlyonce,butthismaynot
holdforremotemethodinvocations
DesignIssuehowmuchtransparencyisdesirable?

InvocationSemanticDesignDecisions
Doweretransmitthemessageuntileitherareplyisreceived,or
istheserverassumedtohavefailed?
Whenretransmissionsareused,areduplicaterequestsfiltered
attheserver?
Isaresultshistorymaintainedontheservertoavoid
duplicatedeffortwheneveraretransmissionisencountered?
Note:localmethodinvocationexactlyoncesemantics

ReliabilityasseenbyInvoker
Faulttolerancemeasures
Retransmitrequest
message

Duplicate
filtering

Invocation
semantics

Reexecuteprocedure
orretransmitreply
Maybe

No

Notapplicable

Notapplicable

Yes

No

Reexecuteprocedure

Atleastonce

Yes

Yes

Retransmitreply

Atmostonce

MaybeInvocationSemantics
Executedonceornotatall
Cansufferfromomissionfailureswithinnetwork
Cansufferfromcrashfailuresonserverside
Usefulonlywhenapplicationscanwithstandoccasional
failedinvocations

AtLeastOnceInvocationSemantics
Executedoneormoretimes
Theinvokereitherreceivesaresultoranexceptionisgenerated
(noresultreceived)
Retransmissionsmasksomissionfailures
Cansufferfromremoteserverfailures(crashes)
Cansufferfromarbitraryfailures(resultinginaretransmission
causingtheservertoexecuteamethodmorethanonce)
Usefulwhenapplicationsaremadeupofexclusivelyidempotent
operations

AtMostOnceSemantics
Executedonceornotatall
Aresultinformstheinvokerthatthemethodwasexecuted
exactlyonce
Anexceptioninformstheinvokerthatthemethodwasnot
executedatall
Atmostoncesemanticsisachievedbyusingallavailable
faulttolerantmechanisms

TransparencyandRPC/RMI
Importantissue
RPCtriestomaketheremoteprocedurecalllookexactlylikea
localone
RPCmarshallingandmessagepassingproceduresarehidden
Thenotionoftransparencyhasbeenextendedtoapplyto
distributedobjects,butitinvolveshidingnotonlymarshalling
andmessagepassingbutalsothetaskoflocatingand
contactingtheremoteobject

RemoteInvocationFailures
Remoteinvocationsaremorevulnerabletofailurethanlocal
ones
Itisimpossibletodistinguishbetweenfailureofthenetwork
andfailureoftheremoteserverprocess
ObjectsusingRMIneedtobeabletorecoverfromsuch
situations
LatencyofanRMIisseveralordersofmagnitudegreater
thanthatofalocalone

TransparencyCurrentThinking

Thecurrentconsensusseemstobethatremoteinvocations
shouldbemadetransparentinthesensethatthesyntax
ofaremoteinvocationisthesameasthatofalocal
invocation,butthatthedifferencesbetweenlocaland
remoteobjectsshouldbeexpressedintheirinterfaces

ConcurrencyKeyPoint

Theknowledgethatanobjectisintendedtobe
accessedbyremoteinvocationhasanotherimplication
foritsdesigneritshouldbeabletokeepitsstate
consistentinthepresenceofconcurrentaccessesfrom
multipleclients

ImplementationofRMI

server

client
object A proxy for B

Request
Reply

Communication
Remote
reference module
module

skeleton
& dispatcher
for Bs

remote
object B

class
servant
Communication Remote reference
module
module

RMIComponentTerminology
Communicationmodulecarriesouttherequestreply
protocol,providingaspecifiedinvocationsemantics
RemoteReferencemoduletranslatesbetweenlocal
andremoteobjectreferences(aswellascreatingremote
objectreferences)
Servantaninstanceofaclassthathandlestheremote
requests

TheRMISoftwareComponents

Proxymakestheremotemethodinvocationtransparent,marshals
argumentsandunmarshalsresults,andsendsandreceivesmessages
Dispatcherreceivestherequestmessageformthecommunication
moduleandselecttheappropriatemethod
Skeletonimplementstheremoteinterface,unmarshalstheargumentsin
therequestmessageandinvokesthecorrespondingmethodintheservant.
Itthenwaitsforthemethodtocomplete,thenmarshalstheresults(and
maybeanexception)inareplymessagetothesendingproxy'smethod

GeneratingClasses
Theclassesfortheproxy,dispatcherandskeletonare
generatedautomaticallybyaninterfacecompiler
TheOrbixtechnologyworkswithCORBAandinterfaces
aredefinedinCORBAIDL
TheJavaRMIcompilergeneratestheproxy,dispatcher
andskeletonclassesfromtheclassoftheremoteobject

DynamicInvocation
Analternativetoproxies
Aclientprogramreceivesaremotereferencetoanobject
whoseremoteinterfacewasnotavailableatcompiletime
CORBAprovidestheInterfaceRepository
JavaRMIallowsforthedynamicdownloadingofclassesto
clients

TheRMIBinderService
Abinderonadistributedsystemisaseparateprocessthat
maintainsatablecontainingmappingsfromtextualnames
toremoteobjectreferences
Itisusedbyserverstoregistertheirremoteobjectbyname
andbyclientstolookthemup
CORBAhasadedicatedNamingService
JavahasabindercalledRMIregistry

Activators
Processesthatstartserverprocessestohostremoteobjects
arecalledactivators
Registersobjectthatareavailableforactivationbyrecording
thenamesoftheserversagainsttheURLsorfilenamesofthe
correspondingobject
Startsnamedserverprocessesandactivatesremoteobjectin
them
Keepstrackofthelocationsoftheserversforanyremote
objectsthatarealreadyactivated

PersistentObjectStores
Wewantaguaranteethatobjectslivebetweenactivations
ofprocesses
CORBAprovidesthepersistentstateservice
JavaprovidesJavaDataObjectsandPersistentJava
(Re)Activationofpersistentobjectsisgenerallydesigned
tobetransparent

LocatingObjects
Alocationservicehelpsclientstolocateremoteobjects
fromtheirremoteobjectreferences
Itusesadatabasethatmapsremoteobjectreferencesto
theirprobablecurrentlocations
Thelocationsare"probable"becauseanobjectmayhave
migratedsinceitwaslastheardof

DistributedGarbageCollection
Theaimofadistributedgarbagecollectoristoensure
thatifalocalorremotereferencetoanobjectisstill
heldanywhereinasetofdistributedobjects,thenthe
objectitselfwillcontinuetoexist,butassoonasno
objectanylongerholdsareferencetoit,theobjectwill
becollectedandthememoryitusesrecovered

DesigningDistributedGarbage
Collection
Typicallybasedonareferencecountingscheme
Wheneveraremoteobjectreferenceentersaprocess,a
proxywillbecreatedandwillstaythereforaslongasitis
needed
Theservershouldbeinformedofthe(new)proxyatthe
client
Whentheproxyceasestoexistattheclient,theserver
shouldbeinformed

ImplementingDistributedGarbage
Collection

Eachserverprocessmaintainsasetofthenamesoftheprocessesthathold
remoteobjectreferencesforeachofitsremoteobjects
Whenaclientfirstreceivesaremotereferencetoaparticularremoteobject,it
informstheserverofthatremoteobjectandcreatesalocalproxy
Theserveraddstheclienttothelistofreferrerstothatobject
Whentheclient'sgarbagecollectornoticesthattheproxyisnolongerneeded,it
informsthecorrespondingserveranddeletestheproxy
Theserverremovestheclientfromthelistofreferrerstothatobject
Whenthelistofreferrersisempty,theserver'sgarbagecollectiontechnology
reclaimsthespaceusedbytheobject

DistributedGarbageCollection
Semantics
Pairwiserequestreplycommunication
Atmostonceinvocationsemantics
Java'sdistributedgarbagecollectioncantolerate
communicationsfailuresbyensuringthattheoperationson
theserverwhichadd/removeareferrerareidempotent
Java's"leases"alsoallowfailuresontheclientsidetobe
tolerated

RemoteProcedureCall(RPC)
LikeRMI,inthattheclientprogramcallsaprocedureinanother
programrunninginaserverprocess
However,itlackstheabilitytocreateanewinstanceofobjectsand
thereforedoesnotsupportremoteobjectreferences(Note:most
RPCsarebasedontheCprogramminglanguage)
Atleastonceandatmostonceinvocationsemanticsarethemost
commonforRPC
Generally,RPCisimplementedoverarequestreplyprotocol

RPCinAction

serverprocess

clientprocess
Request

client
program

clientstub
procedure
Communication
module

Reply

serverstub
procedure
Communication
module

dispatcher

service
procedure

ImplementingRPC
Theclientthataccessesaserviceincludesonestub
procedureforeachprocedureintheserviceinterface(that
is,asprovided"statically"bytheserver)
ThestubprocedureissimilartoRMI'sproxy
Serversimplementstubproceduresandskeletons

CaseStudy:SunRPC
SunRPCwasdesignedintheearly90stosupportclient
servercommunicationwithinSun'sNFStechnology
(networkfilesystem)
SunRPCisessentiallyidenticaltoONCRPC(Open
NetworkComputing)andisdocumentedinRFC1831
ImplementorscanchoosebetweenRPCsoverUDPor
TCP
SunRPCusesatleastoncesemantics

SunRPC'sInterfaces
AninterfacedefinitionlanguagecalledXDRisused(very
Clikeinsyntax)
XDRisratherprimitiveincomparisontoCORBA'sIDLor
Java
TheRPCinterfacecompileriscalledrpcgen

WhenrpcgenGenerates
Clientstubprocedures(tobecalledasiflocalprocedures)
Theserver'smainprocedure,dispatcher,andserverstub
procedures
TheXDRmarshallingandunmarshallingproceduresforuse
bythedispatcherandtheclient/serverstubprocedures

ExampleXDR
constMAX=1000;
structData{
intlength;
charbuffer[MAX];
};
structwriteargs{
intf;
intpos;
Datadata;
};
structreadargs{
intf;
intpos;
intlength;
};
programSAMPLEREADWRITE{
versionVERSION{
voidWRITE(writeargs)=1;
DataREAD(readargs)=2;
}=2;
}=9999;

rpcgenGeneratedHeaderfile

sample.h(seePDFfile)

rpcgenGeneratedClientCode

sample_clnt.c(seePDFfile)

rpcgenGeneratedServerCode

sample_svc.c(seePDFfile)

rpcgenGeneratedXDRCode

sample_xdr.c(seePDFfile)

RPCImplementationDetails
SunRPCrunsalocalbindingservicecalledtheport
mapperatawellknownprotocolportnumberoneach
servercomputer
Whenaserverstartsup,itregisterswiththebindingservice
(portmapper)
Whentheclientstartsup,itrequeststheportnumberofthe
removeservicebyrequestingthenecessarydatafromthe
portmapper

AuthenticationinRPC
Requestandreplymessagesprovideadditionalfieldsto
supportauthentication
Theserverprogramisresponsibleforenforcingaccess
controlbycheckingtheinformationintheauthentication
fields
Severaldifferentauthenticationprotocolsaresupported:
none,UNIXstyle(uid/gid),sharedkeysigningand
Kerberosstyle

EventsandNotifications
Theideabehindtheuseofeventsisthatoneobjectcan
reacttoachangeoccurringinanotherobject
Distributedeventbasedsystemsextendthelocalevent
modelbyallowingmultipleobjectsatdifferentlocationsto
benotifiedofeventstakingplaceatanobject

Publish/SubscribeParadigm
Thepublishsubscribeparadigmisused
Anobjectpublishesthetypeofeventsthatitwillmake
available
Otherobjectscansubscribetothetypesofeventsthatare
ofinteresttothem
Objectsthatrepresenteventsarecallednotifications
Subscribingtoaneventiscalled"registeringinterest"

MainCharacteristicsofDistributedEvent
basedSystems
Heterogeneouscomponentswithinthedistributedsystem
thatwerenot(initially)designedtointeroperatecanbemadeto
worktogether
Asynchronousnotificationsaresentasynchronouslyby
eventgeneratingobjectstoalltheobjectsthathavesubscribed
tothemtopreventpublishersneedingtosynchronizewith
subscribers
Publishersandsubscribersaredecoupled

TheParticipantsinDistributedEvent
Notification
Eventservice
subscriber

objectofinterest
1.

notification

objectofinterest
2.
objectofinterest
3.

notification

observer

subscriber
notification

observer

subscriber
notification

TheParticipantsExplained

Themaincomponentisaneventservicethatmaintainsadatabaseof
publishedeventsandofsubscribers'interests
Theobjectofinterestanobjectthatexperienceschangesinstateasa
resultofitsoperationsbeinginvoked,resultinginthetransmissionofevent
notifications
Theeventoccursattheresultofthecompletionofamethodexecution
Notificationanobjectthatcontainsinformationaboutanevent
Subscriberreceivesnotificationsabouteventsthatithassubscribedto
Observerobjectsdecouplesanobjectofinterestfromitssubscribers,as
itcanhavemanydifferentsubscriberswithmanydifferentneeds
Publisheranobjectthatdeclaresthatitwillgeneratenotificationsof
particulartypesofevent(anditmaybeanobjectofinterestoranobserver)

CaseStudy:Java'sJini
TheJinidistributedeventspecificationallowsapotential
subscriberinoneJVMtosubscribetoandreceive
notificationsofeventsinanobjectofinterestinanother
JVM(usuallyrunningonanothercomputer)
Achainofobserversmaybeinsertedbetweentheobjectof
interestandthesubscriber

Jini'sObjects
EventGeneratorallowsotherobjectstosubscribetoits
eventsandgeneratesnotifications
RemoteEventListenersanobjectthatreceives
notifications
RemoteEventsanobjectthatispassedbyvalueto
remoteeventlisteners(thisisequivalenttoanotification)
ThirdpartyAgentsmaybeinterposedbetweenanobject
ofinterestandasubscriber(thisisequivalenttoan
observer)

HowJiniWorks
Anobjectsubscribestoeventsbyinformingtheevent
generatoraboutthetypeofeventandspecifyingaremote
eventlistenerasthetargetforthenotifications
Notsurprisingly,JiniisbuiltontopofJava'sRMItechnology

CaseStudy:JavaRMI
ExtendstheJavaobjectmodeltoprovidesupportfor
distributedobjectsintheJavalanguage
Itallowsobjectstoinvokemethodsonremoteobjects
usingthesamesyntaxasforlocalinvocations
Objectsmakeremoteinvocationsareawarethattheobject
isremoteastheyhavetohandleRemoteExceptionevents
Theimplementoroftheremoteobjectmustimplementthe
Remoteinterface

ProgrammingJavaRMI
ProgrammingdistributedapplicationsinJavaisrelatively
simpleduetothefactthatasinglelanguagesystemis
used
However,theprogrammerisresponsibleforconsidering
thebehaviourofthedevelopedobjectwithinaconcurrent
environment

InterfacesandParameters
Typicallyremoteobjectsmustimplementthe
Serializableinterface
Aserializableobjectcanbepassedasanargumentor
resultinJavaRMI
Parametersofamethodareassumedtobeinput
parameters,theresultoftheinvocationofthemethodis
asingleoutputparameter

ClassesandtheRegistry
AsJavaisdesignedtoallowclassestobedownloadedfrom
onevirtualmachinetoanother,thereisnoneedtokeepthe
completesetofclasseswithineveryworkingenvironment(as
theycanbedownloadedondemand)
Bothclientandserverprogramscanmaketransparentuseof
instancesofnewclasseswhenevertheyareadded
TheRMIregistryisthebinderforJavaRMI
AninstanceofRMIregistrymustrunoneveryservercomputer
thathostsremoteobjects
Thisisnotasystemwidebindingserviceclientsmustdirect
theirlookupenquiriestoparticularhosts

Summary

Paradigmsfordistributedprogramming:
RPC,RMIandeventbasedsystems