Interprocess Communication - Philadelphia University · – Inter process communication (IPC) ishared variables imessage passing – message passing in concurrent programming languages

4 - 1 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005

1. Foundations and Architecture

distributed system architechtures; network interface

2. Time and Global States

clocks and concepts of time; event ordering; synchronization; global states

3. Coordination

distributed mutual exclusion; multicast; group communication, byzantineproblems (consensus)

4. Inter Process Communication and Middleware

inter process communication; middleware; distributed object models; remote invocation; CORBA; .net; name and directory services

5. Security

cryptographic algorithms; signatures and certificates; authentication

6. Advanced Topics

fault-tolerance; specification and verification


Interprocess Communication♦ Distributed Systems

8 rely on exchanging data and achieving synchronization amongst autonomous distributed processes

– Inter process communication (IPC)

ishared variables

imessage passing

– message passing in concurrent programming languages

ilanguage extensions

iAPI calls

♦ Principles of IPC

(see also [Andrews and Schneider 83] G. Andrews and F. Schneider, Concepts and Notations for Concurrent Programming, ACM Computing Surveys, Vol. 15, No. 1, March 1983)

8Concurrent programs: collections of two or more sequential programsexecuting concurrently

8Concurrent processes: collection of two or more sequential programsin operation, executing concurrently


Interprocess Communication♦ Synchronization8concurrent processes on different computers execute at different

speeds8need for one process to influence computation in another process

– specify constraints on the ordering of events in concurrent processes

– message passingisend message happens before receive message

♦ Message Passing Primitives8send expression_list to destination_designator

– evaluates expression_list– adds a new message instance to channel destination_designator

8receive variable_list from source_designator– assignes received values to variables in variable_list– destroys received message

♦ Central questions8how are destination designators specified?8how is communication synchronized?


Interprocess Communication♦ Destination Designation

8direct naming: source and destination process names serve as designators (a pair of source and destination designators defines a channel)

send cur_status to monitor ormonitor!cur_status

receive message from handler orhandler?message

– easy to implement and use

– allows a process easy control when to receive which messagefrom which other process

– used to implement client/server applications

iwell suited to implement client/server paradigm if there is one client and one server

iotherwise: server should be capable of accepting invocations from any client at any time, and a client should be allowed to invoke many services at a time if more than one server available


Interprocess Communication♦ Destination Designation8global names or mailboxes: process name-independent destination

designator shared by many processes– messages sent to a mailbox can be received by any process that

executes a receive referring to that mailbox name– to implement Client/Server applicationsiclients send requests to mailbox, an available server picks

them up – drawback: costly implementationimessage sent to mailboxirelayed to all other sites that could potentially receive from

that mailboxiif one site decides to receive, inform all other sites that

message is no longer available for receiptimutual exclusion for concurrent access


Interprocess Communication♦ Destination Designation8ports: mailbox, but only one process is permitted to receive from that

mailbox– easy to implement: receives can occur in only one process, no

distribution and coordination necessary– suitable for multiple clients / single server applications

8Message destinations in Internet programming– hybrid direct naming/port scheme

(Internet_address, port_number)

– port corresponds to many sender/one receiver concept

Ahmad1

Rectangle

Ahmad1

Rectangle


Interprocess Communication♦ Channel Naming

8static (at compile time)

– impossible for a program to communicate along a channel not known at compile time

– inflexibility: if a process might ever need to communicate with a recipient, that channel must be available throughout the entire runtime of the sending programme

8dynamic (at runtime)

– administrative overhead at runtime

– more flexible allocation of communication resources


Interprocess Communication♦ Semantics of message passing primitives8Blocking

– non-blocking: the execution will never delay the invoking process – blocking: otherwise

8Synchronization– asynchronous message passing: message passing using buffers

with unbounded capacityisender may race ahead an unbounded number of stepsisender never blocksireceiver blocks on empty queue

– synchronous message passing: no buffering between sender and receiverisender blocks until receiver ready to receiveireceiver blocks until sender ready to send

– buffered message passing: buffers with bounded, finite capacityisender may race ahead a finite, bounded number of stepsisender blocks on full bufferireceiver blocks on empty buffer


Interprocess Communication♦ Non-blocking primitives for asynchronous or buffered message

passing

8 receive

– background variant: process continues, receives interrupt upon arrival

ioverhead for implementation

– ignoring variant: programme polls for availability

8send

– sending process waits for empty buffer or drops message to be sent


Interprocess Communication

♦ Distributed Applications

8availability of a set of pre-implemented application services, like email, ftp, http, etc.

8what if you want to build your own, customized Internet application?

8access to Transport Layer services

♦ Services provided by Internet Transport Layer

8UDP: message passing (datagram)

8TCP: data stream

L7 Application

L6 Presentation

L5 Session

L4 Transport

L3 Network

L2 Data Link Control

L1 Physical

smtpftp

telnethttp

TCP

IPLAN

(M)WANproprietary netwoks

OSI-BRM Internet

© Pearson Education 2001


Interprocess Communication

♦ Sockets8 Internet IPC mechanism of Unix and other operating systems (BSD

Unix, Solaris, Linux, Windows NT, Macintosh OS)8processes in these OS can send and receive messages via a socket8sockets are duplex8sockets need to be bound to a port number and an internet address

in order to be useable for sending and receiving messages8each socket has a transport protocol attribute (TCP or UDP)8messages sent to some internet address and port number can only

be received by a process using a socket that is bound to this address and port number

8UDP socket can be connected to a remote IP address and port number

8processes cannot share ports (exception: TCP multicast)



Interprocess Communication♦ IPC based on UDP datagrams8UDP datagram properties: no guarantee of order preservation,

message loss and duplications are possible8necessary steps

– create socket– bind socket to a port and local Internet addressiclient: arbitrary free portiserver: server port

8 receive method: returns Internet address and port of sender, plus message

8message size: IP allows for messages of up to 216 bytes– most implementations restrict this to around 8 kbytes– larger application messages: application’s responsibility to

perform fragmentation/reassembling– if arriving message is too big for array allocated to receive

message content, truncation occurs


Interprocess Communication♦ IPC based on UDP datagrams8send: non-blocking

– blocks only until message given to UDP/IP– upon arrival placed in per-port queue

8 receive: blocking– pre-emption by timeout possible– if process wishes to continue while waiting for packet, use

separate thread


Interprocess Communication♦ Java API for UDP datagrams8Classes

– DatagramPacket constructor generating message for sending from array of bytesimessage content (byte array)ilength of messageiInternet address and port number (destination)

– similar constructor for receiving a message– DatagramSocket class for sending and receiving of UDP

datagramsione constructor with port number as argument, another

withoutino-argument constructor to use free local portimethods

* send and receive* setSoTimeout

* connect for connecting a socket to a particular remote Internet address and port


Interprocess Communication♦ Java API for UDP datagrams8Example

– process creates socket, sends message to server at port 6789, and waits to receive reply

import java.net.*;import java.io.*;public class UDPClient{

public static void main(String args[]){ // args give message contents and destination hostnametry {

DatagramSocket aSocket = new DatagramSocket(); // create socketbyte [] m = args[0].getBytes();InetAddress aHost = InetAddress.getByName(args[1]); // DNS lookupint serverPort = 6789;DatagramPacket request =

new DatagramPacket(m, args[0].length(), aHost, serverPort);aSocket.send(request); //send nessagebyte[] buffer = new byte[1000];DatagramPacket reply = new DatagramPacket(buffer, buffer.length);aSocket.receive(reply); //wait for replySystem.out.println("Reply: " + new String(reply.getData()));aSocket.close();

}catch (SocketException e){System.out.println("Socket: " + e.getMessage());}catch (IOException e){System.out.println("IO: " + e.getMessage());}} // can be caused by send

}


Interprocess Communication♦ IPC based on TCP streams

8abstract service: stream of bytes to be written to or received from

8 features

– message size: no constraint, TCP decides when to send a transport layer message consisting of multiple application messages, immediate transmission can be forced

– connection oriented

– retransmission to recover from message lost (timeout-bounded)

– queue at destination socket

– blocked on receive

– flow control to block sender when overflow might occur

– need to agree on data sent and received

– server generates new thread for new connection


Interprocess Communication♦ API for streams

8connection establishment using client/server approach, afterwards peer communication

– client: issue connect requests

– server: has listening port to receive connect request messages

– accept of a connection: create new stream socket for new connection

♦ Java API for TCP streams

8Classes

– ServerSocket class: create socket at server side to listen for connect requests

– Socket class: for processes with connections

iconstructor to create a socket and connect it to remote host and port of a server

imethods for accessing input and output stream


Interprocess Communication♦ Example

8TCP-based server for stream communication

import java.net.*;import java.io.*;public class TCPServer {

public static void main (String args[]) {try{

int serverPort = 7896; // the server portServerSocket listenSocket = new ServerSocket(serverPort);

// new server port generatedwhile(true) {

Socket clientSocket = listenSocket.accept();// listen for new connection

Connection c = new Connection(clientSocket);// launch new thread

}} catch(IOException e) {System.out.println("Listen socket:"+e.getMessage());}}

}


Interprocess Communication♦ Example

8TCP-based server for stream communicationclass Connection extends Thread {

DataInputStream in;DataOutputStream out;Socket clientSocket;public Connection (Socket aClientSocket) {

try {clientSocket = aClientSocket;in = new DataInputStream( clientSocket.getInputStream());out =new DataOutputStream( clientSocket.getOutputStream());this.start();

} catch(IOException e){System.out.println("Connection:"+e.getMessage());}}public void run(){

try { // an echo serverString data = in.readUTF();

// read a line of data from the streamout.writeUTF(data);

// write a line to the streamclientSocket.close();

} catch (EOFException e){System.out.println("EOF:"+e.getMessage());} catch (IOException e) {System.out.println("readline:"+e.getMessage());}

}}


Interprocess Communication♦ Data Representation8data representation problem

– use agreed external representation, two conversions necessary– use sender’s or receiver’s format and convert at the other end

8 transmission of structured data types– data types may not change during transmission– usage of a commonly understood “flattened” transfer format

(structured types are reduced to their primitive components)8data representation formats

– SUN Microsystems XDR– CORBA CDR– ASN.1 (OSI layer 6)

8marshalling/unmarshalling– marshalling: assembling a collection of data items in a form

suitable for transmission– unmarshalling: disassembling and recovery of original data items– usually performed automatically by middleware layerihand-programming error-proneiuse of compilers for programs working directly at transport

API


Interprocess Communication♦ CORBA Common Data Represenation (CDR)

8CORBA: Common Object Request Broker Architecture

– middleware architecture standardized by the Object Management Group

– see www.omg.org

8CORBA CDR

– supports types allowed in CORBA remote object invocations

– primitive types

ilittle/big endian according to sender’s representation format

iprimitive values start at indexed byte positions (multiples of 1, 2, 4 or 8)

ifloating point according to IEEE standard

icharacters using an agreed character set


Interprocess Communication♦ CORBA Common Data Represenation (CDR)8structured types

– definitions

– example: struct with value {‘Smith’, ‘London’, 1934}© Pearson Education 2001



Interprocess Communication♦ CORBA Common Data Represenation (CDR)

8CORBA marshalling/unmarshalling

– CORBA Interface Definition Language (IDL)

– IDL compilers will generate marshalling and unmarshallingoperations (“stubs”) that transforms data objects into CDR format


Interprocess Communication♦ Remote Object References8needed when a client invokes an object that is located on a remote

server8 reference needed that is unique over space and time

– space: where is the object located– time: correct version of an undeleted object

8a generic format proposal

– internet address/port number: process which created object– time: creation time– object number: local counter, incremented each time an object is

created in the creating process– interface: how to access the remote object (if object reference is

passed from one client to another)8extension: object references that are location transparent



Interprocess Communication♦ Client-Server Communication8often built over UDP datagrams

– client-server protocol consists of request/response pairs, hence no acknowledgements at transport layer are necessary

– avoidance of connection establishment overhead– no need for flow control due to small amounts of data tranfered

8generic protocol example (for RPC or RMI communication):



Interprocess Communication♦ Client-Server Communication

8 format of protocol messages

– message type (request/reply)

– request ID

isending process identifier (e.g., IP address/port number)

iinteger sequence number incremented by sender with every request

– object reference

– method ID and arguments

Ahmad1

Pencil

Ahmad1

Pencil

Ahmad1

Pencil

Ahmad1

Pencil

Ahmad1

Pencil



8 if implemented over UDP: failure recovery

– omission failures

iuse timeout and resend request when timeout expires and reply hasn’t arrived

iserver receives repeated request

* idempotent operations: same result obtained on every invocation

* non-idempotent operations: re-send result stored from previous request, requires maintenance of a history of replies

iloss of replies: request - reply - ack reply protocol

– message duplication: return request ID with reply


Interprocess Communication♦ Client-Server Communication8example: Hypertext Transfer Protocol (HTTP)

– lightweight request - reply protocol for the exchange of network resources between web clients and web servers

– protocol stepsiconnection establishment between client and server (likely

TCP, but any reliable transport protocol is acceptable)iclient sends requestiserver sends replyiconnection closure

– inefficient scheme, therefore HTTP 1.1 allows “persistent transport connections” (remains open for successive request/reply pairs)

– Resources can have mime-type data types, e.g.itext/plainitext/htmliimage/jpeg

– data is marshalled into ASCII transfer syntax



8example: Hypertext Transfer Protocol (HTTP)

– request

iGET: request of resource, identified by URL, may refer to

* data: server returns data

* program: server runs program and returns output data

iHEAD: request similar like GET, but only meta data on resource is returned (like date of last modification)

iPOST: specifies resource (for instance, a server program) that can deal with the client data provided with previous request

iPUT: supplied data to be stored in given URL

iDELETE: delete an identified resource on server




8example: Hypertext Transfer Protocol (HTTP)

– reply



Middleware

♦ Functionality in Middleware (Upper Sublayer)

8Remote Procedure Call (RPC)

– client calls a procedure implemented and executing on a remote computer

– call as if it was a local procedure

8Remote Method Invocation (RMI)

– local object invoking methods of an object residing on a remote computer

– invocation as if it was a local method call

8Event-based Distributed Programming

– objects receive asynchronous notifications of events happening on remote computers/processes

Applications

MiddlewarelayersRequest reply protocol

External data representation

Operating System

RMI, RPC and events

© Addison-Wesley Publishers 2000


Middleware

♦ Transparency Features of Middleware (Upper Sublayer)

8 location transparency:

– RMI and RPCs invoked without knowledge of the location of invoked method/procedure

8 transport protocol transparency:

– e.g., request/reply protocol used to implement RPC can use either transport protocol

8 transparency of computer hardware and operating system

– e.g., use of external data representations

8 transparency of programming language used

– e.g., by use of programming language independent Interface Definition Languages, such as CORBA IDL

Applications

MiddlewarelayersRequest reply protocol

External data representation

Operating System

RMI, RPC and events



Middleware♦ Interfaces for RMI and RPC

8 interface defined for each module/object

8provides signatures for a set of methods

8hides all implementation details

8accesses can only occur through methods specified in interface

8specifics for interfaces in distributed systems

– no direct access to remote variables possible

iuse message passing mechanism to transmit data objects and variables

* request-reply protocols

– local parameter passing mechanisms (by value, by reference) not applicable to remote invocations

ispecify input, output as attribute to parameters

* input: transmitted with request message

* output: transmitted with reply message

– pointers are not valid in remote address spaces

icannot be passed as argument along interface


Middleware♦ Interfaces for RMI and RPC

8RPC and RMI interfaces are often seen as a client/server system

– service interface (in client server model)

ispecification of procedures and methods offered by a server

– remote interface (in RMI model)

ispecification of methods of an object that can be invoked by objects in other processes


Middleware♦ Interfaces for RMI and RPC8 Interface Definition Languages

– impossible to specify direct access to variables in remote classes– hence, access only through specified interface– desirable to have language-independent IDL that compiles into

access methods in application programming language– example: CORBA IDL

// In file Person.idlstruct 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();

};© Addison-Wesley Publishers 2000


Distributed Objects♦ Components of an object model

8object references

– refer to objects of a class

– can be assigned, queried

8 interfaces

8actions

– initiated by an object invoking a method in another object

– possible effects

istate of method invocation receiver may change

ican cause further method invocation

8exceptions

– system as well as programmer-defined reactions on unexpected or error situations

8garbage collection

– disposal of resources (memory) that are occupied by objects thatare no longer referenced and will not be needed any more in the future


Distributed Objects♦ Distributed Object Model

8adoption of client-server model

– servers maintain objects and allow remote objects to access the methods of those objects that are specified for remote use in the interface definition

– clients invoke the methods offered by servers using remote method invocation (RMI)

8RMI implemented using a request/reply protocol

– request carries remote method reference and remote object’s in parameters to server

– reply returns out parameters (results of RMI) to client

invocation invocationremote

invocationremote

locallocal

localinvocation

invocationA B

C

D

E

F

request

reply



Remote Method Invocation

♦ Remote Object

8object capable of receiving RMIs (in example at least B and F)

♦ Remote Object Reference

8needed by an object performing a RMI

8 refers to server of RMI

8 typical format

8can be passed as parameter or result

invocation invocationremote

invocationremote

local

local

local

invocation

invocation

A B

C

D

E

F





♦ Remote Interface

8specifies which methods can be invoked remotely

interface

remote

m1m2m3

m4m5m6

Data

implementation

remote object

{ of methods



Remote Method Invocation♦ Actions8caused by method invocations8 if boundary of one process or computer is crossed through

invocation, then RMI will be used to cause the action♦ Garbage Collection8garbage collection for remote objects8determine whether there are remaining references to an object in the

system♦ Exceptions8 recovery from error situations as in non-distributed case8specific problems due to distributed environment

– server may have crashed– server may be too busy to reply within reasonable time bounds

8specific exceptions– timeouts – specific exceptions due to underlying distributed infrastructure

8CORBA IDL– application level exceptions– system generates distribution-specific exceptions


Remote Method Invocation♦ RMI usually implemented via request/reply protocol

8 if implemented over UDP, then the following failures may occur

– message omission

– messages not delivered in send order

– message duplication

8additionally, process failures are possible (crash or arbitrary)

8consequence: cannot be guaranteed, that remote operations are executed exactly once (as it can be guaranteed for local operations)




♦ Invocation Semantics

8choices in the implementation

– retransmit request message until reply or server presumed failed

– filtering of duplicates at server if retransmit is used

– when retransmitted request arrives:

iresult retransmission if retransmitted request arrives (requires keeping of history at server) or

irepeated execution of procedure

8 leads to different 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




♦ Invocation Semantics

8maybe

– invoker knows nothing about whether operation is executed

iany type of communication or process failure may have happened

– no fault tolerance mechanisms used



Duplicate filtering


No

Yes

Yes

Not applicable

No

Yes

Not applicable


Retransmit reply At-most-once

At-least-once

Maybe




♦ Invocation Semantics8at-least-once

– invoker receivesiresult, oriexception, if no result was received

– if result was received, invoker knows that operation was executed at least once, but knows nothing if exception occurs

– achieved through retransmissions of requests and re-executions – remaining failure modesicrash failure of server (when no fairness for this component)iarbitrary failures caused through re-execution of non-

indempotent operation on server



Duplicate filtering


No

Yes

Yes

Not applicable

No

Yes

Not applicable


Retransmit reply At-most-onceAt-least-once

Maybe




♦ Invocation Semantics8at-most-once

– invoker receives iresult, in which case s/he knows that operation was executed

exactly once, oriexception informing that no result was received, in which

case the operation was performed either once, or not at all– requires usage of all fault tolerance measures

8examples– Java RMI and CORBA use at-most-once– CORBA allows maybe semantics for RMIs that do not return

results



Duplicate filtering


No

Yes

Yes

Not applicable

No

Yes

Not applicable


Retransmit reply At-most-onceAt-least-once

Maybe




♦ Implementation of RMI

8communication module

– request/reply messages

– uses message type, requestID and remote object reference

– in server

iselect dispatcher for the class of the object to be invoked

iobtains local reference from remote reference module by providing remote object identifier delivered with request message

ipasses on the local reference to scheduler

object A object BskeletonRequest

proxy for B

Reply

CommunicationRemote Remote referenceCommunicationmodulemodulereference module module

for B’s class& dispatcher

remoteclient server





8 remote reference module

– translation between local and remote object references using remote object tableicontains entries for all remote objects maintained by the

server

iand for all proxies (explained later)

– used when marshalling and unmarshalling remote object references


proxy for B

Reply



remoteclient server




♦ Implementation of RMI8 the RMI sublayer of the middleware architecture consists of

– proxies (in client): local placeholders for remote objects– dispatcher (in server): receives request and uses methodID to

select appropriate message in skeleton– skeleton (in server): implements methods in the remote interfaceiunmarshaling argumentsiinvokes corresponding method in remote objectiwaits for completion of invocationimarshals results, possibly exceptions, and returns them in a

reply to invoking method of proxy


proxy for B

Reply



remoteclient server





8 implementation of RMI layer (proxies, skeletons and dispatchers)

– in some systems they can be automatically compiled, e.g.

iOrbix CORBA, uses IDL descriptions of remote interfaces to compile RMI layer, generates C++ code

iJava RMI

* proxy, skeleton and dispatcher classes are generated from the class of the remote object


proxy for B

Reply



remoteclient server



Remote Method Invocation♦ Some more RMI components

8 factory methods

– remote object interfaces cannot include constructors

– factory methods replace constructors to create remote objects

8binders

– service maintaining mappings from textual object names to remote object references

8 threads in server

– every remote method invocation is usually given an own thread toexecute

iadvantages, if RMI invokes other local or remote methods that cause wait times


Remote Method Invocation♦ Distributed Garbage Collection

8 free resources occupied by objects that have no more reference to it in the system

8Java Distributed Garbage Collection algorithm:

– each server maintains a list of processes that hold remote object references for each of its remote objects

– when client receives a remote reference to particular remote object X, issuing a addRef(X) to the server, server adds X to the list

– when client’s garbage collector notices that a proxy for a remote object X is no longer referenced, it sends removeRef(X) to server, which deletes X from list

– when list is empty, and there are no local references to X, collect resources held by X through server’s local garbage collector


Remote Method Invocation♦ Distributed Garbage Collection

8 fault tolerance of Java Distributed Garbage Collection

– supported by request/reply protocol with at-most-once semantics

– toleration of communication failures

iaddRef and removeRef are indempotent

iif addRef(X) returns exception, then client will not instantiate proxy but will send removeRef(X)

ieffect of removeRef(X) is correct no matter whether addRef(X) succeeded or not

ifailure of removeRef(X) is masked by the use of leases

– leases

iservers lease their objects to clients for limited periods of time, starting with addRef

ihelps tolerate failures of removeRef as well as client failures

iavoids problem of having to maintain lists of remote object references if all object references are handled through leases


SUN Remote Procedure Call

♦ SUN RPC

8developed by SUN Microsystems to support client-server communication for use in SUN’s NFS

8very similar in concept to RMI

8any of the delivery semantics of RMI can be implemented

8only addresses procedure calls

– no object references

8client stub procedure corresponds to proxy

8server stub procedure similar to skeleton

client

Request

Reply

CommunicationCommunicationmodulemodule dispatcher

service

client stub server stubprocedure procedure

client process server process

procedureprogram



Event Based Distributed Programming♦ Event Based Distributed Programming

8event typically caused by method invocation or message delivery

8event changes state of object

8multiple objects at different locations are informed of the occurrence of an event at a particular object, for example:

– in a spontaneous computing environment, that a person’s PDA has entered a hotel room

– a client has entered participation in a collaborative work environment

– an electronic document has been modified


Event Based Distributed Programming♦ Event Based Distributed Programming

8publish-subscribe paradigm

– object generating events publishes list of events for which other objects can receive notifications

– object requiring notifications subscribes to the notification service at an object offering notification for this particular event through its publication list

8characteristics of event based systems

– heterogeneity of hard- and software

– asynchronicityisynchronous notification would be highly inefficient at client

as well as at server endiclient-polling also rather inefficient


Event Based Distributed Programming

♦ Architecture8event service

– maintains database of published events and registered subscriptions

– event service is notified of events at objects of interest– subscribers subscribe for notifications at event service– after occurrence of event, notification is sent to all subscribers

8delivery semantics is implementation dependent– e.g., notifications by IP multicast do not guarantee that any

notification will ever get delivered to subscriber

subscriberobserverobject of interest

Event service

object of interest

object of interest observer

subscriber

subscriber

3.

1.

2. notification

notification

notification

notification



Event Based Distributed Programming

♦ Architecture8observer objects: decoupling of an object of interest from subscriber

– responsible for all subscribers to events in some object– subscribers and the types of events they are interested in may be

rather heterogeneous - hence, better to have observer deal with this (separation of concerns!)

8 three cases– in case 3, the object of interest is outside event service, hence,

the observer needs to poll the object of interest for event occurrences

subscriberobserverobject of interest

Event service

object of interest

object of interest observer

subscriber

subscriber

3.

1.

2. notification

notification

notification

notification



Java RMI♦ Extension of Java object model8allows for invocation of methods on remote objects8single language system8RMI syntactically identical to local method invocations

– should RMI calls be syntactically transparent, or not?ipro: hiding of the implementation of the method invocationicon: the semantics of local and remote invocation differ, and

this should be made explicit in the language8however, object making a remote invocation needs to be able to

handle RemoteExceptions that are thrown in the event of communication subsystem failures

8 remote object must implement Remote interface8example used

– shared whiteboardishared use of drawing surface containing graphical objectsiserver maintains current shape of drawingiclients can poll server about latest shape of a drawingiserver attaches version numbers to new arriving shapes


Java RMI♦ Remote Interface

8GraphicalObject: class representing state of drawing objects

– should implement Serializable - why?

import java.rmi.*;import java.util.Vector;public interface Shape extends Remote {

int getVersion() throws RemoteException;GraphicalObject getAllState() throws RemoteException; 1

}public interface ShapeList extends Remote {

Shape newShape(GraphicalObject g) throws RemoteException; 2Vector allShapes() throws RemoteException;int getVersion() throws RemoteException;

}



Java RMI♦ Remote Interface

8Ordinary and remote objects can appear as input and output arguments

– remote objects: passed by (object) referencei2: newShape returns object with remote interface, i.e., remote

object, as resultiwhen remote object reference is received, an RMI can be

issued on the object refered to by this reference– ordinary objects: passed by valueinew object created locally, with state differing from original

object

import java.rmi.*;import java.util.Vector;public interface Shape extends Remote {

int getVersion() throws RemoteException;GraphicalObject getAllState() throws RemoteException; 1

}public interface ShapeList extends Remote {

Shape newShape(GraphicalObject g) throws RemoteException; 2Vector allShapes() throws RemoteException;int getVersion() throws RemoteException;

}



Insert: Processes and Threads♦ Process

8software in execution

8unit of resource management for operating system

– execution environment

iaddress space

ithread synchronization and communication resources (e.g., semaphores, sockets)

icomputing resources (file systems, windows, etc.)

– threads

ischedulable activities attached to processes

iarise from the need for concurrent activities sharing resources within one process

* concurrent input/output with problem computation

* servers: concurrent processing of client requests, each request handled by one thread


Insert: Processes and Threads♦ Process

8processes vs. threads

– threads are “lightweight” processes

iprocesses expensive to create, threads easier to create and destroy

8process instantiation

– one thread will be instantiated as well, may instantiate offsprings


Thread(ThreadGroup group, Runnable target, String name) Creates a new thread in the SUSPENDED state, which will belong to group and be identified as name; the thread will execute the run() method of target.

setPriority(int newPriority), getPriority()Set and return the thread’s priority.

run()A thread executes the run() method of its target object, if it has one, and otherwise its own run() method (Thread implements Runnable).

start()Change the state of the thread from SUSPENDED to RUNNABLE.

sleep(int millisecs)Cause the thread to enter the SUSPENDED state for the specified time.

yield()Enter the READY state and invoke the scheduler.

destroy()Destroy the thread.

Processes and Threads♦ Java Thread class



Processes and Threads♦ Thread Groups

8every thread belongs to one group, assigned at thread creation time

8 thread groups useful to shield various applications running in parallel on one Java Virtual machine

– thread in one group may not interrupt thread in another group

ie.g., an application may not interrupt the windowing (AWT) thread


Processes and Threads♦ Java Thread Synchronization

8each thread’s local variables and methods are private to it

– thread has own stack

8 thread does not have private copies of static (class) variables or object instance variables

8mutual exclusion via monitor concept

– abstract data type first implemented in Ada– in Java: synchronized keyword

iany object can only be accessed through one invocation of any of its synchronized methods

ian object can have synchronized and non-synchronized methods

– exampleisynchronized addTo() and removeFrom() methods to

serialize requests in worker pool example


Processes and Threads♦ Java Thread Synchronization8 threads can be blocked and woken up

– thread awaiting a certain condition calls an object’s wait()method

– other thread calls notify() or notifyAll() to awake one or all blocked threads

8example– worker thread discovers no requests to be processedicalls wait() on instance of Queue

– when IO thread adds request to queueicalls notify() method of queue to wake up worker

thread.join(int millisecs)Blocks the calling thread for up to the specified time until thread has terminated.

thread.interrupt()Interrupts thread: causes it to return from a blocking method call such as sleep().

object.wait(long millisecs, int nanosecs)Blocks the calling thread until a call made to notify() or notifyAll() on object wakes the thread, or the thread is interrupted, or the specified time has elapsed.

object.notify(), object.notifyAll()Wakes, respectively, one or all of any threads that have called wait() on object.



Java RMI♦ Downloading of Classes

8classes can be transferred from one Java VM to another

8passing of local or remote object references

– if recipient does not yet possess class of object passed by value, or proxy to handle remote object reference, the respective code is transferred automatically from the VM where these are implemented

♦ RMI Registry: binder for Java RMI

8 runs of every server of remote objects

8maps local object names of the form //computerName:port/objNameto object references

8not a global service - clients need to query a particular host to get reference


Java RMI♦ Server with main method

♦ Security Manager

8 implements various security policies for client accesses

♦ Main method

81: create instance of ShapeListServant82: binds name "ShapeList" to newly created instance in RMIRegistry

import java.rmi.*;public class ShapeListServer{

public static void main(String args[]){System.setSecurityManager(new RMISecurityManager());try{

ShapeList aShapeList = new ShapeListServant(); 1Naming.rebind("Shape List", aShapeList ); 2

System.out.println("ShapeList server ready");}catch(Exception e) {System.out.println("ShapeList server main " + e.getMessage());}

}}



Java RMI♦ ShapeListServant implements ShapeList

81: UnicastRemoteObject - objects that live only as long as creating process

82: factory method - client can request creation of a new object

import java.rmi.*;import java.rmi.server.UnicastRemoteObject;import java.util.Vector;public class ShapeListServant extends UnicastRemoteObject implements ShapeList {

private Vector theList; // contains the list of Shapes 1private int version;

public ShapeListServant()throws RemoteException{...}public Shape newShape(GraphicalObject g) throws RemoteException { 2

version++;Shape s = new ShapeServant( g, version); 3

theList.addElement(s); return s;}

public Vector allShapes()throws RemoteException{...}public int getVersion() throws RemoteException { ... }}



Java RMI♦ Client program

8polling loop:

– 1: look up remote reference

– 2: invoke allShapes() in remote object

import java.rmi.*;import java.rmi.server.*;import java.util.Vector;public class ShapeListClient{

public static void main(String args[]){System.setSecurityManager(new RMISecurityManager());ShapeList aShapeList = null;try{

aShapeList = (ShapeList) Naming.lookup("//bruno.ShapeList") ; 1Vector sList = aShapeList.allShapes(); 2

} catch(RemoteException e) {System.out.println(e.getMessage());}catch(Exception e) {System.out.println("Client: " + e.getMessage());}}}



Java RMI♦ Callbacks

8avoid polling: server informs clients whenever an event occurs

– client creates remote object and provides method for server to call

– server allows clients to inform it of remote object references for their callback methods

– server calls clients using these methods whenever an event of interest occurs

8problems

– clients may not revoke the callback requests before they exit, hence the list to be maintained in server may be inaccurate

iuse leases instead

– need to make a series of synchronous RMI invocations for every event of interest may block server progress for some time


CORBA♦ Common Object Request Broker Architecture (CORBA)8standardized by the Object Management Group (OMG)

– www.omg.org8specifications of interfaces for “open distributed object systems”

– heterogeneous ihardwareinetwork infrastructureioperating systemsiprogramming languages

* multi-language system* definition of an Interface Definition Language that will be

compiled into application programming language


CORBA♦ Common Object Request Broker Architecture (CORBA)8object request broker (ORB): support for transparent object

invocation, similar to Java RMIs– locate object– activate object– communicate request– returning reply

8 important: clients and servants do not need to be objects, i.e.,CORBA also works for non-OO languages like C, Cobol, etc.

8numerous commercial and public domain implementations are available

8 remote object is called “CORBA object”


CORBA♦ Common Object Request Broker Architecture (CORBA)

8static invocation: remote interface of the CORBA object is known at compile time

– code can be used to generate client stubs (proxies) and server skeletons

8dynamic invocation: remote interface not known at compile time

– when a client without necessary proxy needs to invoke a CORBA object

– example

iclient wishes to display information about all known CORBA objects in all servers

ican’t be expected that client has proxies for all object, since they are dynamically generated and deleted

– note: CORBA does not allow dynamic loading of proxies as Java RMI would


CORBA

♦ CORBA Architecture

8ORB core

– communications module

– allows ORB to be started and stopped

– remote object references to string conversion, and vice versa

client server

proxy

or dynamic invocation

implementationrepository object

adapter

ORBORB

skeleton

or dynamic skeleton

clientprogram

interfacerepository

Request

Reply corecorefor AServant

A



CORBA


8Object adapter

– mediates between CORBA objects with IDL interfaces and the programming language interfaces

icreates remote object references for CORBA objects

idispatches RMIs via skeleton to servant class

iactivates objects

– maintains object names

igenerated at object activation, automatically or specified by user

client server

proxy



adapter

ORBORB

skeleton

or dynamic skeleton

clientprogram

interfacerepository

Request


A



CORBA


8Skeletons

– generated by IDL compiler

– scheduling

– marshaling/unmarshaling of arguments and exceptions

8Client stubs/proxies

– in application language

– generated by IDL compiler from IDL interface definition

– marshaling/unmarshaling of arguments and exceptions

client server

proxy



adapter

ORBORB

skeleton

or dynamic skeleton

clientprogram

interfacerepository

Request


A



CORBA


8 Implementation repository

– activation of registered servers on demand

– locating of servers currently running

– maintains object adapter names and locations for every CORBA object

client server

proxy



adapter

ORBORB

skeleton

or dynamic skeleton

clientprogram

interfacerepository

Request


A



CORBA


8 Interface Repository

– provide information about registered IDL interfaces to clients

inames of methods

inames and types of method arguments

– can be used to emulate JAVA-type reflection

iuseful if a client has no proxy for a remote reference it receives

client server

proxy



adapter

ORBORB

skeleton

or dynamic skeleton

clientprogram

interfacerepository

Request


A



CORBA

♦ CORBA Architecture - Remote Object References8 Interoperable Object References (IOR)

– IDL Interface Type Nameiname stored in Interface Repository, can be used at runtime

to retrieve IDL definition of interface– protocol and address specificsiInternet Inter-Orb Protocol (IIOP) uses TCP/IP

– Object Identification8Transient IORs

– persist only as long as hosting process – contains address details of server hosting object

8Persistent IORs– survive inactivation periods of CORBA objects– contains address details of implementation repository

IOR format

IDL interface type name Protocol and address details Object key

interface repositoryidentifier

IIOP host domainname

port number adapter name object name



CORBA

♦ CORBA Architecture - Remote Object References8Usage of IOR to locate servant representing CORBA object

– transient IORsiserver ORB core receives request containing adapter nameiuses adapter name to locate adapteriadapter uses object name to locate servant


client server

proxy



adapter

ORBORB

skeleton

or dynamic skeleton

clientprogram

interfacerepository

Request


A



CORBA

♦ CORBA Architecture - Remote Object References8Usage of IOR to locate servant representing CORBA object

– persistent IORsiImlementation Repository receives request and extracts

object adapter nameiif necessary, activates object at specified hostiIR returns address details (including object adapter name and

object name) to the client ORB, which uses them for the RMI request messagesiserver ORB core locates object adapter, adapter uses object

name to locate servant


client server

proxy



adapter

ORBORB

skeleton

or dynamic skeleton

clientprogram

interfacerepository

Request


A



CORBA♦ CORBA Object Model

8object model similar to the generic distributed object model discussed earlier

8CORBA object (remote object)

– implements IDL interface

– has remote object reference

– capable of responding to remote invocations

8CORBA does not know the concepts of object and class

– implementation languages can be non-OO

– impossible to define classes in CORBA IDLiuse of structs instead

* components similar to instance variables of a class

* does not have methods

– impossible to pass classes as arguments or results


CORBA♦ CORBA IDL8 interface specifies names and methods that clients can use (invoke)8extended subset of C++ syntax8 IDL modules

– logical grouping of interface and type definitions– defines naming scope

8 IDL interface– methods that are available in CORBA objects implementing the

interface8 IDL methods

– specify signatures– parameters are labeled as in, out and inoutiin passed with request message from client to serveriout passed with reply message from server to client

– oneway indicates that client will not be blocked when invoking this methodithese methods use maybe invocation semantics

– raises: user-defined exceptions


CORBA♦ CORBA IDL

8 IDL types

– always passed by value

Type Examples Use

sequence typedef sequence <Shape, 100> All;typedef sequence <Shape> Allbounded and unbounded sequencesof Shapes

Defines a type for a variable-lengthsequence of elements of a specifiedIDL type. An upper bound on thelength may be specified.

string String name; typedef string<8> SmallString; unbounded and boundedsequences of characters

Defines a sequences of characters,terminated by the null character. Anupper bound on the length may bespecified.

array typedef octet uniqueId[12];

typedef GraphicalObject GO[10][8]

Defines a type for a multi-dimensionalfixed-length sequence of elements of aspecified IDL type.

continued...



CORBA♦ CORBA IDL

8 IDL types

8special type Object– values are remote object references

Type Examples Use

record struct GraphicalObject {string type;Rectangle enclosing;boolean isFilled;

};

Defines a type for a record containing agroup of related entities. Structs arepassed by value in arguments andresults.

enumerated enum Rand(Exp, Number, Name);

The enumerated type in IDL maps atype name onto a small set of integervalues.

union union Exp switch (Rand) {case Exp: string vote;

case Number: long n;case Name: string s;

The IDL discriminated union allowsone of a given set of types to be passedas an argument. The header isparameterized by an enum, whichspecifies which member is in use.};



CORBA♦ CORBA IDL

8 IDL attributes

– like public class fields in Java

– may be defined as readonly– for each attribute declared, a couple of access methods is

automatically generated by IDL compiler (get/put methods)

8 IDL interface inheritance

– one interface may be the refinement of another interface

8 IDL type names generated by compiler

– IDL prefix

– type name

– prefix number


CORBA♦ Example: IDL definitions for Interfaces Shape and ShapeList

81, 2: parameter types as structs

– GraphicalObject was class in Java RMI example

83: use of GraphicalObject as a result type

84: definition of a sequence type to store object shapes, used in 8

struct Rectangle{ 1long width; long height;long x;long y;

} ;

struct GraphicalObject { 2string type; Rectangle enclosing; boolean isFilled;

};

interface Shape { 3long getVersion() ;GraphicalObject getAllState() ; // returns state of the GraphicalObject

};

typedef sequence <Shape, 100> All; 4interface ShapeList { 5

exception FullException{ }; 6Shape newShape(in GraphicalObject g) raises (FullException); 7All allShapes(); // returns sequence of remote object references 8long getVersion() ;

};© Addison-Wesley Publishers 2000


CORBA♦ Example: IDL definitions for Interfaces Shape and ShapeList

8parameter passing– parameters whose type is specified as an IDL interface refer to a

CORBA object, and remote object reference is passed– primitive and constructed types are copied and passed by value– 8: return value is an array of object referencesiarray passed by valueicontents of array defined as interface (Shape), hence object

references will be passed

struct Rectangle{ 1long width; long height;long x;long y;

} ;

struct GraphicalObject { 2string type; Rectangle enclosing; boolean isFilled;

};

interface Shape { 3long getVersion() ;GraphicalObject getAllState() ; // returns state of the GraphicalObject

};

typedef sequence <Shape, 100> All; 4interface ShapeList { 5

exception FullException{ }; 6Shape newShape(in GraphicalObject g) raises (FullException); 7All allShapes(); // returns sequence of remote object references 8long getVersion() ;

}; © Addison-Wesley Publishers 2000


CORBA♦ Example

8 idltojava: compiles Java code from CORBA definitions

– equivalent Java interfaces

iexample: Java interface for ShapeList

– skeletons for each IDL interface

– proxy classes/client stubs for each IDL interface

public interface ShapeList extends org.omg.CORBA.Object {Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;Shape[] allShapes();int getVersion();

}



CORBA♦ Example: Server

8CORBA objects implemented as servant classes– above: ShapeList servant classi1: newShape is factory method i2: use connect to register an object with the ORB (render it a

CORBA object)

import org.omg.CORBA.*;class ShapeListServant extends _ShapeListImplBase {

ORB theOrb;private Shape theList[];private int version;private static int n=0;public ShapeListServant(ORB orb){

theOrb = orb;// initialize the other instance variables

}public Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException { 1

version++;Shape s = new ShapeServant( g, version);if(n >=100) throw new ShapeListPackage.FullException();theList[n++] = s; 2theOrb.connect(s);return s;

}public Shape[] allShapes(){ ... }public int getVersion() { ... }

}



CORBA♦ Example: Server

8server class - main method– 1: initializes ORB– 2, 3: initialize ShapeListServant and register with ORB– 4, 5, 6, 7: generate a name and register with CORBA naming

service– 8: wait for invocations

import org.omg.CosNaming.*;import org.omg.CosNaming.NamingContextPackage.*;import org.omg.CORBA.*;public class ShapeListServer {

public static void main(String args[]) {try{

ORB orb = ORB.init(args, null); 1ShapeListServant shapeRef = new ShapeListServant(orb); 2orb.connect(shapeRef); 3 org.omg.CORBA.Object objRef =

orb.resolve_initial_references("NameService"); 4NamingContext ncRef = NamingContextHelper.narrow(objRef);NameComponent nc = new NameComponent("ShapeList", ""); 5NameComponent path[] = {nc}; 6ncRef.rebind(path, shapeRef); 7java.lang.Object sync = new java.lang.Object();synchronized (sync) { sync.wait();} 8

} catch (Exception e) { ... }}

} © Addison-Wesley Publishers 2000


CORBA♦ Example: client

81: initialize ORB

82: get reference to remote ShapeList object using CORBA naming service

83, 4: invoke remote operations

8note in 4: class GraphicalObject as a return type?

– while CORBA does not know classes, the implementation languages may well interpret the CORBA structs as classes

import org.omg.CosNaming.*;import org.omg.CosNaming.NamingContextPackage.*;import org.omg.CORBA.*;public class ShapeListClient{

public static void main(String args[]) {try{

ORB orb = ORB.init(args, null); 1org.omg.CORBA.Object objRef =

orb.resolve_initial_references("NameService");NamingContext ncRef = NamingContextHelper.narrow(objRef);NameComponent nc = new NameComponent("ShapeList", "");NameComponent path [] = { nc };ShapeList shapeListRef =

ShapeListHelper.narrow(ncRef.resolve(path)); 2Shape[] sList = shapeListRef.allShapes(); 3GraphicalObject g = sList[0].getAllState(); 4

} catch(org.omg.CORBA.SystemException e) {...}} © Addison-Wesley Publishers 2000


CORBA♦ CORBA services8services specified by CORBA standard that might be helpful to

distributed objects8examples

– Naming Serviceiimplements function of a binder

– Event and Notification servicesisupport event based programming

– Security Serviceiauthentication, access control, and non-repudiation

– Trading Serviceidirectory service that allows objects to be identified by value

of some attribute– Transaction and Concurrency Control Serviceisupport for distributed, concurrent database transactions

– Persistent Object Serviceiimplement persistent objects that can be activated and

deactivated


Microsoft .NET♦ .NET

8a Microsoft component-based solution to distributed applications, a middleware platform integrated with other Microsoft development environments

– Microsoft proprietary

8not a typical open environment for distributed applications, e.g.

– does not always rely on interface definitions (metadata)

– may even modify remote objects directly, no need to obtain remote object references if client and remote object reside in the same machine

8open to other technologies and platforms

– communication through HTTP, SOAP, WSDL

– .NET can be built upon Microsoft Windows or Linux (Mono Project)

– applications written in different programming languages: C#, VC++, VB, Microsoft Java, SmallTalk, COBOL, Phyton, TCL/TK, Perl....


Microsoft .NET♦ .NET

8history:

– a Mircosoft strategic change from product-oriented desktop applications to service-oriented component applications,

– goal: compete with prospering SUN J2EE with Java RMI dominating the middleware market.

– an evolution from previous component-based Microsoft technologies:

iCOM DCOM MTS COM+ .NET


Microsoft .NET♦ .NET Framework

Operating System

COM+ Enterprise Server

.NET Framework (Core)

Class Library

CLR (Runtime Environment)


Microsoft .NET♦ COM (Component Object Model)

8Component

– reusable encapsulated object

8Assembly: logical encapsulation of all the information about several components.

– modules: specification and implementation of a component.

imetadata (specification)

icode (implementation) in Microsoft Intermediate Language (MSIL)

– manifest: assembly version, security, relation among encapsulated components.

iSecurity: digital signature.


Microsoft .NET♦ COM (Component Object Model)8MSIL

– plays the same role as Java bytecode.– programs in high-level language, such as VC++ or C#, will all be

compiled into MSILiCPU-independent set of instructions that can be efficiently

converted to native code iinstructions for loading, storing, initializing, and calling

methods on objects – not a high-level language: binary (unlike bytecode)– but also not a machine language: type system, object-oriented– not executable, needs to be compiled into machine language (not

interpreted as bytecode in Java)



8Common Type System (CTS)

– type abstractions without syntax and semantics

– every language maps a subset of CTS types to its own types

iexample * VB type char* as CTS type System.string

* VC type CString as CTS type System.string

* System.string then used in MSIL for compilation of executable code

– CTS is an object-oriented type system

ican define classes, encapsulation



8 Interfaces

– written in Microsoft Interface Definition Language (MIDL), similar to CORBA IDL.

– a component can have more than one interface, each having a unique ID.

– each component must have an “IUNKNOWN” interface maintaining references to the component itself:iMethod QueryInterface()

* Querys a component for an specific interface and gets a reference if the interface exists.

iMethod AddRef()

* Increments the reference counter.iMethod Release()

* Decrements the reference counter.



8 Interfaces

8Global Unique Identifier (GUID)

– each component is identified with a GUID.

– 128 bits, registered at the residing system.

interface hello

{

void HelloProc([in, string] const unsigned char *pszString);

void Shutdown(void);

}


Microsoft .NET♦ CLR (Common Language Runtime)

8provides similar service as Java environment

– compiles from high level language to MSIL

– high-level language to MSIL compiler produces metadata

itypes in source code, including the definition of each type, thesignatures of each type's members, the members that the source code references, and other data that the runtime uses at execution time.

– CLR brings MSIL code to execution on the target machine

ino interpretation.

ijust-in-time compilation: compile at run time

ipre-compilation at installation time


Microsoft .NET♦ CLR (Common Language Runtime)

8Component Server

– accomodates components

– provides registration service

– provides factory service: generate dynamically components

– component management, such as garbage collection and handling exceptions


Microsoft .NET♦ .NET Framework

8 .NET Remoting Framework

– locate object

– activate object

– send/forward request

– return/forward reply

8amongst others, .NET targets web services

– Web Services Description Language (WSDL)

ian XML format for describing network services

imore recent version: BPEL4WS

– Simple Object Access Protocol (SOAP)

ia lightweight protocol intended for exchanging structured information in a distributed environment

ibuilt on the HTTP protocol


Microsoft .NET♦ Inter-Process Communication

8ASP.NET

– adaption from ASP to be integrated with .NET

– ASP is a dynamic website development technique, like JSP in Java

iinefficient

iuntyped

– only supports HTTP, SOAP, WSDL

8 .NET Remoting

– more versatile and extensible using more protocols than just HTTP, SOAP, WSDL, even custom protocols


Microsoft .NET

♦ .NET Remoting Architecture

8Remote Object

– Client-activated objects

iUnder the control of lease-based lifetime manager

iClient can renew the lease

– Server-activated objects

iSingle-call objects

iSingleton objects: service all clients who share the same data.

Client Server

Clientprogram

TransparentProxy for A

SerializationFormatter


CommunicationChannel

Real ProxyFor A

Remote ObjectA

LeaseManager


Microsoft .NETClient Server

Clientprogram





Real ProxyFor A

Remote ObjectA

LeaseManager

♦ .NET Remoting Architecture8Proxy Objects: dynamically generated when a client activates the

remote object – Transparent Proxy: run at client side as a representativeiProvides same interface as remote objectiIntercepts all remote call from the clientiForwards each invocation as a message to real proxyiHandels return message

– Real Proxy: run at server sideiHidden from clientiForwards invocation message to remote object



Clientprogram





Real ProxyFor A

Remote ObjectA

LeaseManager


8Proxy Objects: dynamically generated when a client activates theremote object

– Compiled dynamically from the metadata

– Unlike CORBA architecture where proxies are compiled statically from the interface (for static invocation)

– reminder: Java RMI does not support dynamic generation of proxies



Clientprogram





Real ProxyFor A

Remote ObjectA

LeaseManager


8Serialization Formatter

– marshalls a message into a stream at client side

– Two default formats

iBinary

iSoap/XML

– unmarshalls


Microsoft .NET♦ Dynamic Invocation

8Type Library-driven Marshalling

– A general real proxy does not contain information about a specific component. Instead, it marshalls a component at run time by getting information from type library.

8Example in C#

Using System;Using System.Reflection;

Assembly *a = Assembly.LoadFrom(“C:/Program Files/…../Something.exe”);

Type[] types = a.GetTypes();Type thistype = types[0];MethodInfo[] methods = thistype.GetMethods();MethodInfo thismethod = methods[0];

…

Thismethod.invoke(this, par1, par2, …, parn);


Microsoft .NET♦ Asynchronous Method Invocation8Delegate

– Object that contains the reference to a remote object and one ofits methods

– Gets a worker thread from the thread pool to invoke the method– Stores result of the method

8Asynchronous Method Invocation– Caller thread generates a delegate d– d.beginInvoke(…) gets a worker thread and returns– d.endInvoke(…) to harvest the result

Caller Delegate d Worker

creates

beginInvoke()obtains

returnsInvokesmethod

Methodreturnsstores result

endInvoke()

returns


Microsoft .NET♦ Remoting Example Using a TCP Channel

8Remote Object

Using System;Using System.Runtime.Remoting;Using System.Runtime.Remoting.Channels;Using System Runtime.Remoting.Channels.Tcp;

namespace RemotingSamples {public class HelloServer : marshalByRefObject { 1

public HelloServer() {Console.WriteLine(“HelloServer activated”);

}

public String HelloMethod(String name) {Console.WriteLine(“Hello.HelloMethod : {0}”, name);return “Hi there” + name;

}}

}

© Microsoft Corporation 2001

1. Any remote object is derived from marshalByRefObject



8Server


namespace RemotingSamples {public class Sample {

public static int Main (String [] arg) {TcpChannel chan = new TcpChannel (8085); 1ChannelServices.RegisterChannel(chan); 2RemotingConfiguration.RegisterWellKnownServiceType 3

(Type.GetType(“RemotingSamples.HelloServer”),“SayHello”, WellKnownObjectMode.SingleCall);

System.Console.WriteLine(“Hit <enter> to exit…”);System.Console.ReadLine();return 0;

}}

}© Microsoft Corporation 2000

1. Creates a new TCP channel that listens on the port 80852. Register the channel for the object3. Register the object as a single-call-object, which serves only one request and dies



8Client


namespace RemotingSamples {public class Client {

public static int Main (String [] arg) {TcpChannel chan = new TcpChannel (); ChannelServices.RegisterChannel(chan);HelloServer obj =

(HelloServer) Activator.GetObject( 1typeof(RemotingSamples.HelloServer),“tcp://localhost:8085/SayHello”); 2

if (obj == null)System.Console.WriteLine(“Could not locate server”);

elsepublic delegate string MethodDelegate(String st); 3MethodDelegate myDelegate = new MethodDelegate(obj.HelloMethod); 4IAsyncResult ar = myDelegate.BeginInvoke(“Wei Wei”, null, null); 5while (!ar.IsCompleted) …Console.WriteLine(myDelegate.EndInvoke(null)); 6

return 0;}

}}


1. Activates a remote object of type “HelloServer”2. Specifies the URL of the remote object that is configured in the configuration file



8Client







return 0;}

}}


3. Creates a new delegate type that has the same parameter types as the remote method.4. Creates the delegate for the remote method.



8Client







return 0;}

}}


5. Invokes the method asynchronously through the delegate6. Harvests the result after being assured of the completion of the remote method


Microsoft .NET♦ Comparison between .NET , Java RMI and CORBA

8With .NET you may modify a remote object directly without need of going through function calls if that remote object is resided in a .NET component server.

– CORBA only generates interfaces, while .NET also generates binaries in common intermediate language.

8Java RMI only supports Java, while CORBA and .NET is cross-language.

8Using .NET good development environments are provided.

8MIDL supports object-oriented interface in contrast to CORBA IDL.

8 .NET and Java RMI support multiple interfaces of an object, while CORBA does not.


Microsoft .NET♦ Comparison between .NET , Java RMI and CORBA

8CORBA and .NET support both static and dynamic invocations.

– .NET uses type library-driven marshalling and reflection.

– CORBA uses dynamic invocation interfaces.

– The reflection in Java is not integrated into Java RMI.

Documents

Interprocess Communication - Philadelphia University · – Inter process communication (IPC) ishared variables imessage passing – message passing in concurrent programming languages