ObjectOriented Network Communication OOMI

1
Object-Oriented Network Communication(OOMI)

• Advanced Communication between Distributed
  Objects Emmerich Chapter 7.

9.03.2003
2
Motivation

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

3
Outline

• Request Synchronization
• Four types
• Synchronous
• Oneway
• Deferred Synchronous
• Asynchronous
• 2. Request Reliability

4
1. Request Synchronization
OO-Middleware synchronous requests

• 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

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 methodclass
OnewayReqPrintSquad extends Thread Team team
Date date OnewayReqPrintSquad(Team t, Date d)
teamt dated 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

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

10
Deferred Synchronous Requests with Threads

• class PrintSquad
• public void print(Team t, Date d)
• DefSyncReqPrintSquad anew 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) teamt
  dated
• public String getResult() return s
• public void run()
• String s
• steam.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

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)
• Anew 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)
• teamtdatedcallc
• public void run()
• String steam.AsString(date)

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
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
• 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
  objects 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