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
Slide 2 of 24
© Ingeniørhøjskolen i Århus
Outline
1. Request Synchronization
Four types:
– Synchronous
– Oneway
– Deferred Synchronous
– Asynchronous
2. Request Reliability
Slide 3 of 24
© Ingeniørhøjskolen i Århus
1. Request Synchronization
OO-Middleware: synchronous requests
:Client
Op()
:Server
• Synchronous requests might block clients
unnecessarily
• Examples:
– User Interface Components
– Concurrent Requests from different servers
Slide 4 of 24
© Ingeniørhøjskolen i Århus
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()
Slide 5 of 24
© Ingeniørhøjskolen i Århus
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
}
}
Slide 6 of 24
© Ingeniørhøjskolen i Århus
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);
};
Slide 7 of 24
© Ingeniørhøjskolen i Århus
Oneway Requests in CORBA
• If oneway declarations cannot be used:
Use dynamic invocation interface
:Client
:Server
r=create_request()
r:Request
send()
Op()
delete()
Slide 8 of 24
© Ingeniørhøjskolen i Århus
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
:Client
send()
:Request
op()
:Server
get_result()
Slide 9 of 24
© Ingeniørhøjskolen i Århus
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() {
String s;
s=team.asString(date);// call remote method and die
}
}
Slide 10 of 24
© Ingeniørhøjskolen i Århus
CORBA Deferred Synchronous Requests
• Determined at run-time using DII
• By invoking send() from a Request object
• And using get_response() to obtain result
:Client
r=create_request(“op”)
send()
:Server
r:Request
op()
get_response()
Slide 11 of 24
© Ingeniørhøjskolen i Århus
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
op()
:Server
Slide 12 of 24
© Ingeniørhøjskolen i Århus
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
Slide 13 of 24
© Ingeniørhøjskolen i Århus
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);
}
}
© Ingeniørhøjskolen i Århus
Slide 14 of 24
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
Slide 15 of 24
© Ingeniørhøjskolen i Århus
Asynchronous Requests using Message Queues
enter
remove
Request Queue
Client
Server
remove
enter
Reply Queue
Slide 16 of 24
© Ingeniørhøjskolen i Århus
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
Slide 17 of 24
© Ingeniørhøjskolen i Århus
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
Slide 18 of 24
© Ingeniørhøjskolen i Århus
Request Reliability
• Unicast
– Exactly once (1)
– Atomic (2)
– At-most-once (3)
– At-least-once (4)
– Maybe (5)
• Multicast
Slide 19 of 24
© Ingeniørhøjskolen i Århus
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!
Slide 20 of 24
© Ingeniørhøjskolen i Århus
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
Slide 21 of 24
© Ingeniørhøjskolen i Århus
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
Slide 22 of 24
© Ingeniørhøjskolen i Århus
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
Slide 23 of 24
© Ingeniørhøjskolen i Århus
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
Slide 24 of 24
© Ingeniørhøjskolen i Århus