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

2. 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

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

4. 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

5. 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()

6. 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 } }

7. 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); };

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

9. 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()

10. 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

11. 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()

12. 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()

13. 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

14. 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);

15. 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

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

17. 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

18. 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

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

20. 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!

21. 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

22. 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

23. 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

24. 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