CS551
Object Oriented Middleware (V)
Advanced Communication between Distributed
Objects(Chap. 7 of EDO)
Yugi Lee
STB #555
(816) 235-5932
[email protected]
www.cstp.umkc.edu/~yugi
1
CS551 - Lecture 16
Motivation
• The requests we have seen have
– two parties (client and server object)
– trigger execution of one operation
– have at-most-once reliability
• Other forms of requests are useful
– Synchronization
– Multiplicity
– Reliability
CS551 - Lecture 16
2
Outline
• Request Synchronization
–
–
–
–
Synchronous
Oneway
Deferred Synchronous
Asynchronous
• Request Multiplicity
– Group Requests
– Multiple Requests
• Request Reliability
CS551 - Lecture 16
3
Request Synchronization
• OO-Middleware: synchronous requests.
:Client
Op()
:Server
• Synchronous requests might block clients
unnecessarily.
– User Interface Components
– Concurrent Requests from different servers
CS551 - Lecture 16
4
Oneway Requests
• Return control to client as soon as request has
been taken by middleware
• Client and server are not synchronized if
– Server does not produce a result
– Failures of operation can be ignored by client
:Client
:Server
oneway()
CS551 - Lecture 16
5
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
}
}
CS551 - Lecture 16
6
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);
};
CS551 - Lecture 16
7
Oneway requests in CORBA
• If oneway declarations cannot be used: Use dynamic
invocation interface
:Client
:Server
r=create_request()
r:Request
send()
Op()
delete()
CS551 - Lecture 16
8
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()
get_result()
CS551 - Lecture 16
9
:Server
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()); //get result and print
}
}/ 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
}
}
CS551 - Lecture 16
10
CORBA Deferred Synchronous Requests
• Determined at run-time with using DII
• By invoking send() from a Request object
• And using get_response() to obtain result
:Client
r=create_request(“op”)
send()
r:Request
op()
get_response()
CS551 - Lecture 16
11
:Server
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
CS551 - Lecture 16
12
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
CS551 - Lecture 16
13
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);
}
}
CS551 - Lecture 16
14
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 (request & reply queues)
– Asynchronous requests can be achieved
• Message-Oriented Middleware (MOM)
– IBM’s MQSeries, DEC Message Queue, Falcon (COM)
CS551 - Lecture 16
15
Asynchronous Requests using Message Queues
enter
remove
Request Queue
Client
Server
remove
enter
Reply Queue
CS551 - Lecture 16
16
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
CS551 - Lecture 16
17
Request Multiplicity
• OO Middleware: unicast requests
– Two components: client and server
– One operation execution
– Non-anonymous
• Other forms: multicast requests
– More than two components (group requests)
• A client requests execution of the same operation from
multiple server objects.
– More than one operation (multiple requests)
• A client requests execution of different operations from
different objects.
CS551 - Lecture 16
18
Group Requests: Stock Exchange Ticker
:Trader
:Channel
:Ticker
connect()
connect()
push()
push()
push()
disconnect()
connect()
push()
push()
push()
CS551 - Lecture 16
19
:Ticker :Ticker
Group Communication Principles
• Group communication informs a group of
components about a particular event.
• Two roles:
– Event producer/Event consumer
• Producers and consumers do not know each other
– Event channels: request-posting/registration interesting
event/notification (broadcast)
• Two forms of request:
– push-type: producer initiates communication
– pull-type: consumer initiates communication
CS551 - Lecture 16
20
CORBA Event Notification Service
Application
Objects
Domain
Interfaces
CORBA
facilities
Object Request Broker
Event
Notification
CORBAservices
CS551 - Lecture 16
21
Group Requests with Event Service
sa:
Supplier
Admin
:Client
ppc: Proxy
Push
Consumer
ca:
Consumer
Admin
:Event
Channel
pps:
ProxyPush
Supplier
ca=for_consumers()
sa=for_suppliers()
pps=obtain_push_
supplier()
ppc=obtain_push_consumer()
connect_push_
consumer()
push()
push()
CS551 - Lecture 16
22
:Ticker
Except of Event Service Interfaces
module CosEventComm {
interface PushConsumer {
void push (in any data) raises(...);
};
};
module CosEventChannelAdmin {
interface ProxyPushConsumer: CosEventComm::PushConsumer {
};
interface ProxyPushSupplier: CosEventComm::PushSupplier {
void connect_push_consumer(
in CosEventComm::PushConsumer push_consumer)
raises(...);
};
interface ConsumerAdmin {
ProxyPushSupplier obtain_push_supplier();
};
interface SupplierAdmin {
ProxyPushConsumer obtain_push_consumer();
};
interface EventChannel {
ConsumerAdmin for_consumers();
SupplierAdmin for_suppliers();
};
};
CS551 - Lecture 16
23
Multiple Requests
• Triggers n operation executions in one request.
• Defined at run-time.
• Advantages:
– Smaller overhead on client side
– Process results as they become available
CS551 - Lecture 16
24
Multiple Requests with Threads
• Client requests servers using multiple concurrent threads.
• Client should not have to choose the order for obtaining
results and should not get unduly blocked
• Use tuple spaces for the communication between client
and request threads
– Tuple is a tagged data record
– Tuples are exchanged in tuple spaces using associative
memory
CS551 - Lecture 16
25
Multiple Requests in CORBA
• Dynamic Invocation Interface supports multiple
deferred synchronous requests
module CORBA {
interface ORB {
typedef sequence<Request> RequestSeq;
Status send_multiple_requests (
in RequestSeq targets
)
Status get_next_response(in Flags f);
};
};
CS551 - Lecture 16
26
Multiple Request Example: Revenue from
a portfolio of assets
:Client
rs:RequestSeq
:ORB
:Share
r1=create_request(”dividend”)
r2=create_request(”interest”)
add(r1)
add(r2)
send_multiple_requests(rs)
dividend()
interest()
get_next_response()
get_next_response()
CS551 - Lecture 16
27
:Bond
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
CS551 - Lecture 16
28
Request Reliability
• Unicast
–
–
–
–
–
Exactly once
Atomic
At-most-once
At-least-once
Maybe
• Multicast
– k-reliability
– totally ordered
– best effort
CS551 - Lecture 16
29
Unicast Reliability: At-most-once
• Default reliability in OO Middleware: At-mostonce semantics
• Means that
– the middleware attempts to execute the request at
most once
– the middleware detects failures and informs client
• Good compromise between complexity and
reliability
CS551 - Lecture 16
30
Unicast Reliability: Exactly once
• 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!
CS551 - Lecture 16
31
Unicast Reliability: Atomic
• Atomic requests are either performed completely
or not at all
• Clients know from where to recover
• Implemented using transactions
• Still quite expensive
CS551 - Lecture 16
32
Unicast Reliability: At-least-once
• 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
CS551 - Lecture 16
33
Unicast Reliability: Maybe
•
•
•
•
Similar to at-most once reliability except that
Clients are not notified about failures
Example: CORBA oneway requests
No overhead for error handling
CS551 - Lecture 16
34
Request Reliability: K-Reliability
• Generalization of exactly-once for multicasts
• Guarantees that at-least k requests of the group or
multiple requests will be executed
• Example: CORBA Notification Service
CS551 - Lecture 16
35
Request Reliability: Totally Ordered
• Guarantees that a group of requests from one
multicast does not overtake previous multicasts
• Example: CORBA Event Service achieves totally
ordered requests at expense of using synchronous
requests for each request of a group
CS551 - Lecture 16
36
Request Reliability: Best Effort
• No guarantees are given to as to how requests that
are part of multicasts are executed
• Example: Using CORBA Event service to execute
oneway operations
CS551 - Lecture 16
37
Key Points
• Requests in CORBA, COM and RMI are by default:
synchronous, unicast and executed at-most-once
• Non-functional requirements may demand different
forms of requests
• Non-synchronous requests that can be performed with
CORBA, COM and RMI are
– Oneway
– Deferred Synchronous
– Asynchronous
CS551 - Lecture 16
38
Key Points
• Multicast requests can be group requests or
multiple requests.
• Both perform more than one request at once
• Group requests are anonymous forms of
communications
• Multiple requests are non-anonymous
• Requests can trade off performance against
reliability
CS551 - Lecture 16
39