Yugi Lee STB #555 (816) 235-5932 [email protected] cstp.umkc/~yugi
-
Upload
dalton-herman -
Category
Documents
-
view
32 -
download
0
description
Transcript of Yugi Lee STB #555 (816) 235-5932 [email protected] cstp.umkc/~yugi
CS551 - Lecture 161
CS551 Object Oriented Middleware (V)Advanced Communication between Distributed Objects(Chap. 7 of EDO)
Yugi Lee
STB #555(816) 235-5932
www.cstp.umkc.edu/~yugi
2CS551 - Lecture 16
MotivationMotivation
• 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
• 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
3CS551 - Lecture 16
OutlineOutline
• Request Synchronization– Synchronous– Oneway– Deferred Synchronous– Asynchronous
• Request Multiplicity– Group Requests– Multiple Requests
• Request Reliability
• Request Synchronization– Synchronous– Oneway– Deferred Synchronous– Asynchronous
• Request Multiplicity– Group Requests– Multiple Requests
• Request Reliability
4CS551 - Lecture 16
Request SynchronizationRequest Synchronization
• Synchronous requests might block clients unnecessarily. – User Interface Components– Concurrent Requests from different servers
• Synchronous requests might block clients unnecessarily. – User Interface Components– Concurrent Requests from different servers
• OO-Middleware: synchronous requests.• OO-Middleware: synchronous requests.
:Server:Server:Server:Server:Client:Client:Client:ClientOp()Op()
5CS551 - Lecture 16
Oneway RequestsOneway 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
• 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
:Server:Server:Server:Server:Client:Client:Client:Clientoneway()oneway()
6CS551 - Lecture 16
Oneway using Java ThreadsOneway 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) { team=t; date=d; } public void run() { team.print(date); // call remote method and then die }}
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) { team=t; date=d; } public void run() { team.print(date); // call remote method and then die }}
7CS551 - Lecture 16
Oneway requests in CORBAOneway 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);
};
• 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);
};
8CS551 - Lecture 16
r:Requestr:Request
:Server:Server:Client:Client
send()send()
r=create_request()r=create_request()
delete()delete()
Oneway requests in CORBAOneway requests in CORBA
• If oneway declarations cannot be used: Use dynamic invocation interface
• If oneway declarations cannot be used: Use dynamic invocation interface
Op()Op()
9CS551 - Lecture 16
:Server:Server:Server:Server:Client:Client:Client:Client :Request:Request:Request:Request
Deferred Synchronous RequestsDeferred 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
• 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
send()send() op()op()
get_result()get_result()
10CS551 - Lecture 16
Deferred Synchronous Requests with ThreadsDeferred 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 methodclass 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 }}
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 methodclass 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 }}
11CS551 - Lecture 16
CORBA Deferred Synchronous RequestsCORBA Deferred Synchronous Requests
• Determined at run-time with using DII• By invoking send() from a Request object• And using get_response() to obtain result
• Determined at run-time with using DII• By invoking send() from a Request object• And using get_response() to obtain result
:Server:Server:Server:Server:Client:Client:Client:Client
r:Requestr:Requestr:Requestr:Request
op()op()
get_response()get_response()
r=create_request(“op”)r=create_request(“op”)
send()send()
12CS551 - Lecture 16
Asynchronous RequestsAsynchronous 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
• 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
:Server:Server:Server:Server:Client:Client:Client:Clientop()op()
13CS551 - Lecture 16
Asynchronous Requests with ThreadsAsynchronous 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
• 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
14CS551 - Lecture 16
Asynchronous Requests with ThreadsAsynchronous 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); }}
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); }}
15CS551 - Lecture 16
Asynchronous Requests using Message QueuesAsynchronous 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)
• 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)
16CS551 - Lecture 16
Asynchronous Requests using Message QueuesAsynchronous Requests using Message Queues
ClientClient ServerServer
Request QueueRequest Queue
Reply QueueReply Queue
enterenter removeremove
removeremove enterenter
17CS551 - Lecture 16
Difference between Thread and MQsDifference between Thread and MQs
Threads• Communication is
immediate• Do not achieve
guaranteed delivery of request
• Can be achieved using language/OS primitives
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
Message Queues• Buffer Request and Reply
messages• Persistent storage may
achieve guaranteed delivery
• Imply additional licensing costs for Messaging
18CS551 - Lecture 16
Request MultiplicityRequest 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.
• 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.
19CS551 - Lecture 16
:Trader:Trader:Trader:Trader :Channel:Channel:Channel:Channel :Ticker:Ticker:Ticker:Ticker :Ticker:Ticker:Ticker:Ticker :Ticker:Ticker:Ticker:Ticker
Group Requests: Stock Exchange TickerGroup Requests: Stock Exchange Ticker
connect()connect()
push()push()
push()push()
disconnect()disconnect()connect()connect()
connect()connect()
push()push()
push()push()push()push()
push()push()
20CS551 - Lecture 16
Group Communication PrinciplesGroup 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
• 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
21CS551 - Lecture 16
CORBA Event Notification ServiceCORBA Event Notification Service
Application ObjectsApplication Objects
CORBAfacilitiesCORBAfacilities
CORBAservicesCORBAservices
DomainInterfacesDomain
Interfaces
Object Request BrokerObject Request Broker
EventNotification
22CS551 - Lecture 16
Group Requests with Event ServiceGroup Requests with Event Service
ca:Consumer
Admin
ca:Consumer
Admin
ppc: Proxy Push
Consumer
ppc: Proxy Push
Consumer
sa: SupplierAdmin
sa: SupplierAdmin
pps: ProxyPush
Supplier
pps: ProxyPush
Supplier:Client:Client :Event
Channel:Event
Channel :Ticker:Ticker
ppc=obtain_push_consumer()ppc=obtain_push_consumer()pps=obtain_push_supplier()pps=obtain_push_supplier()
connect_push_consumer()connect_push_consumer()push()push()
push()push()
ca=for_consumers()ca=for_consumers()sa=for_suppliers()sa=for_suppliers()
23CS551 - Lecture 16
Except of Event Service InterfacesExcept 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(); };};
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(); };};
24CS551 - Lecture 16
Multiple RequestsMultiple Requests
• Triggers n operation executions in one request.
• Defined at run-time.
• Advantages:– Smaller overhead on client side– Process results as they become available
• Triggers n operation executions in one request.
• Defined at run-time.
• Advantages:– Smaller overhead on client side– Process results as they become available
25CS551 - Lecture 16
Multiple Requests with ThreadsMultiple 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
• 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
26CS551 - Lecture 16
Multiple Requests in CORBAMultiple Requests in CORBA
• Dynamic Invocation Interface supports multiple deferred synchronous requestsmodule CORBA { interface ORB { typedef sequence<Request> RequestSeq; Status send_multiple_requests (
in RequestSeq targets ) Status get_next_response(in Flags f); };};
• Dynamic Invocation Interface supports multiple deferred synchronous requestsmodule CORBA { interface ORB { typedef sequence<Request> RequestSeq; Status send_multiple_requests (
in RequestSeq targets ) Status get_next_response(in Flags f); };};
27CS551 - Lecture 16
Multiple Request Example: Revenue from a portfolio of assetsMultiple Request Example: Revenue from a portfolio of assets
:Client:Client:Client:Client rs:RequestSeqrs:RequestSeqrs:RequestSeqrs:RequestSeq :ORB:ORB:ORB:ORB :Share:Share:Share:Share :Bond:Bond:Bond:Bond
r1=create_request(”dividend”)r1=create_request(”dividend”)
r2=create_request(”interest”)r2=create_request(”interest”)
add(r1)add(r1)
add(r2)add(r2)
dividend()dividend()send_multiple_requests(rs)send_multiple_requests(rs)
interest()interest()get_next_response()get_next_response()get_next_response()get_next_response()
28CS551 - Lecture 16
Request ReliabilityRequest 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
• 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
29CS551 - Lecture 16
Request ReliabilityRequest Reliability
• Unicast– Exactly once
– Atomic
– At-most-once
– At-least-once
– Maybe
• Multicast– k-reliability
– totally ordered
– best effort
• Unicast– Exactly once
– Atomic
– At-most-once
– At-least-once
– Maybe
• Multicast– k-reliability
– totally ordered
– best effort
30CS551 - Lecture 16
Unicast Reliability: At-most-onceUnicast Reliability: At-most-once
• Default reliability in OO Middleware: At-most-once 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
• Default reliability in OO Middleware: At-most-once 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
31CS551 - Lecture 16
Unicast Reliability: Exactly onceUnicast 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!
• 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!
32CS551 - Lecture 16
Unicast Reliability: AtomicUnicast Reliability: Atomic
• Atomic requests are either performed completely or not at all
• Clients know from where to recover
• Implemented using transactions
• Still quite expensive
• Atomic requests are either performed completely or not at all
• Clients know from where to recover
• Implemented using transactions
• Still quite expensive
33CS551 - Lecture 16
Unicast Reliability: At-least-onceUnicast 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
• 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
34CS551 - Lecture 16
Unicast Reliability: MaybeUnicast 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
• Similar to at-most once reliability except that
• Clients are not notified about failures
• Example: CORBA oneway requests
• No overhead for error handling
35CS551 - Lecture 16
Request Reliability: K-ReliabilityRequest 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
• 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
36CS551 - Lecture 16
Request Reliability: Totally OrderedRequest 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
• 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
37CS551 - Lecture 16
Request Reliability: Best EffortRequest 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
• 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
38CS551 - Lecture 16
Key PointsKey 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
• 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
39CS551 - Lecture 16
Key PointsKey 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
• 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