lecture_wk13_Remote_Module_Invocation.pptxVIP

CPE 545 RMI (Remote Module Invocation) Middleware layersApplications, services RMI and RPCrequest-reply protocol marshalling and external data representation Middleware layersUDP and TCP Distributed objects Compile-time vs run-time objectsObjects can be implemented in many different waysCompile-time objects, i.e. instances of classes written in object-oriented languages like Java, C++ Database objects Procedural languages like C, with a appropriate “wrapper code” that gives it the appearance of an object Systems like Java RMI support compile-time objects Not possible or difficult in language-independent RMI middleware such as CORBA These systems use object adapters Implementations of object interfaces are registered at an object adapter, which acts as an intermediary between the client and object implementation Persistent vs transient objects Persistent objects continue to exist even if they are not contained in the address space of a server process The “state” of a persistent object has to be stored on a persistent store, i.e., secondary storage Invocation requests result in an instance of the object being created in the address space of a running process Transient objects only exist as long as their container server processes are running Static vs dynamic RMI Static invocationTypical way for writing code that uses RMI (similar to the process for writing RPC )Declare the interface in IDL, compile the IDL file to generate client and server stubs, link them with client and server side code to generate the client and the server executables Requires the object interface to be known when the client is being developed Dynamic invocation The method invocation is composed at run-time invoke(object, method, input_parameters, output_parameters) Useful for applications where object interfaces are discovered at run-time, e.g. object browser, batch processing systems for object invocations, “agents”Design Issues for RMITransparency Should remote invocations be transparent to