Object-Oriented Network Communication (OOMI) Advanced Communication between Distributed Objects Emmerich – Chapter 7. 9.03.2003

Motivation The requests we have seen have Synchronous execution Have at-most-once reliability may or may not succeed -> exception If not Other forms of requests are useful We therefore look at different forms of Synchronization Operation execution Reliability

Outline Request Synchronization 2. Request Reliability Four types: Synchronous Oneway Deferred Synchronous Asynchronous 2. Request Reliability

1. Request Synchronization OO-Middleware: synchronous requests :Client :Server Op() Synchronous requests might block clients unnecessarily Examples: User Interface Components Concurrent Requests from different servers

Oneway Requests Return control to client as soon as request has been taken by middleware Client and server are not synchronized Use if: Server does not produce a result Failures of operation can be ignored by client :Client :Server oneway()

Oneway using Java Threads class PrintSquad { static void main(String[] args) { Team team; Date date; //initializations of team and date omitted ... OnewayReqPrintSquad a= new OnewayReqPrintSquad(team,date); a.start(); //continue to do work while request thread is blocked } // thread that invokes remote method class OnewayReqPrintSquad extends Thread { Team team; Date date; OnewayReqPrintSquad(Team t, Date d) { team=t; date=d;} public void run() { team.print(date); //call remote method and then die } }

Oneway Requests in CORBA Declared statically in the interface definition of the server object IDL compiler validates that operation has a void return type does not have any out or inout parameters does not raise type specific exceptions Example: interface Team { oneway void mail_timetable(in string tt); };

Oneway Requests in CORBA If oneway declarations cannot be used: Use dynamic invocation interface :Server :Client r=create_request() r:Request send() Op() delete()

Deferred Synchronous Requests Return control to client as soon as request has been taken by middleware Client initiates synchronization Use if: Requests take long time Client should not be blocked Clients can bear overhead of synchronization :Server :Client :Request send() op() get_result()

Deferred Synchronous Requests with Threads class PrintSquad { public void print(Team t, Date d) { DefSyncReqPrintSquad a=new DefSyncReqPrintSquad(t,d); // do something else here. a.join(this); // wait for request thread to die. System.out.println(a.getResult()); } // thread that invokes remote method class DefSyncReqPrintSquad extends Thread { String s; Team team; Date date; DefSyncReqPrintSquad(Team t, Date d) {team=t; date=d;} public String getResult() {return s;} public void run() { s=team.asString(date);// call remote method and die

CORBA Deferred Synchronous Requests Determined at run-time using DII By invoking send() from a Request object And using get_response() to obtain result :Server :Client r:Request op() get_response() r=create_request(“op”) send()

Asynchronous Requests Return control to client as soon as request has been taken by middleware Server initiates synchronization Use if: Requests take long time Client should not be blocked Server can bear overhead of synchronization :Client :Server op()

Asynchronous Requests with Threads Client has interface for callback Perform request in a newly created thread Client continues in main thread New thread is blocked Requested operation invokes callback to pass result New thread dies when request is complete

Asynchronous Requests with Threads interface Callback { public void result(String s); } class PrintSquad implements Callback { public void Print(Team team, Date date){ A=new AsyncReqPrintSquad(team,date,this); A.start(); // and then do something else public void result(String s){ System.out.print(s); class AsyncReqPrintSquad extends Thread { Team team; Date date; Callback call; AsyncReqPrintSquad(Team t, Date d, Callback c) { team=t;date=d;call=c; public void run() { String s=team.AsString(date); call.result(s);

Asynchronous Requests using Message Queues Messaging is starting to be provided by object-oriented middleware Microsoft Message Queue CORBA Notification Service Java Messaging Service Request and reply explicitly as messages Using two message queues Asynchronous requests can be achieved

Asynchronous Requests using Message Queues enter Request Queue Reply Queue remove Client Server remove enter

Difference between Thread and MQs Threads Communication is immediate Do not achieve guaranteed delivery of request Can be achieved using language/OS primitives Message Queues Buffer Request and Reply messages Persistent storage may achieve guaranteed delivery Imply additional licensing costs for Messaging

2. Request Reliability How certain can we be that a request has been executed? Extremes: Guaranteed execution Do not know There are different degrees in between Client designers specify how reliably their requests need to be executed Different classification for unicast and multicast

Request Reliability Unicast Multicast Exactly once (1) Atomic (2) At-most-once (3) At-least-once (4) Maybe (5) Multicast

Unicast Reliability: Exactly once (1) Highest degree of reliability for unicast requests Middleware guarantees that requests are executed once and only once Example: CORBA Notification service Occurrence of failures transparent for both client and server designers Requires persistent storage of request data Implies serious performance penalty!

Unicast Reliability: Atomic (2) Atomic requests are either performed completely or not at all Clients know from where to recover Implemented using transactions Still quite expensive

Unicast Reliability: At-least-once (3) Middleware guarantees to execute request once Example: Message-oriented middleware (MQSeries) Request maybe executed more often Achieved by re-sending request or reply messages Difficult to use with requests that modify server object’s state

Unicast Reliability: At-most-once (4) Default reliability in OO Middleware: At-most-once semantics Means that the middleware attempts to execute the request at most once i.e. the requested operation may or may not have been executed the middleware detects failures and informs client the client may then decide what to do e.g. by asking the user Good compromise between complexity and reliability

Unicast Reliability: Maybe (5) Similar to at-most once reliability except that Clients are not notified about failures Example: CORBA oneway requests or if we ignore the exceptions No overhead for error handling