1. CS551 - Lecture 16 1 CS551 Object Oriented Middleware (V) Advanced Communication between Distributed Objects (Chap. 7 of EDO) Yugi Lee STB #555 (816) 235-5932 yugi@cstp.umkc.edu www.cstp.umkc.edu/~yugi

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

3. 3 CS551 - Lecture 16 Outline 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

4. 4 CS551 - Lecture 16 Request 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. :Server:Server :Client:Client Op()

5. 5 CS551 - Lecture 16 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 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 :Client:Client oneway()

6. 6 CS551 - Lecture 16 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 } 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. 7 CS551 - Lecture 16 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); }; 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. 8 CS551 - Lecture 16 r:Request :Server :Client send() r=create_request() delete() Oneway requests in CORBA If oneway declarations cannot be used: Use dynamic invocation interface Op()

9. 9 CS551 - Lecture 16 :Server:Server:Client:Client:Request:Request 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 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() op() get_result()

10. 10 CS551 - Lecture 16 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 } 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 }

11. 11 CS551 - Lecture 16 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 Determined at run-time with using DII By invoking send() from a Request object And using get_response() to obtain result :Server:Server:Client:Client r:Requestr:Request op() get_response() r=create_request(“op”) send()

12. 12 CS551 - Lecture 16 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 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 :Client:Client op()

13. 13 CS551 - Lecture 16 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 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. 14 CS551 - Lecture 16 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); } 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. 15 CS551 - Lecture 16 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) 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)

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

17. 17 CS551 - Lecture 16 Difference 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

18. 18 CS551 - Lecture 16 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. 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.

19. 19 CS551 - Lecture 16:Trader:Trader:Channel:Channel:Ticker:Ticker:Ticker:Ticker:Ticker:Ticker Group Requests: Stock Exchange Ticker connect() push() disconnect() connect() push()

20. 20 CS551 - Lecture 16 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 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

21. 21 CS551 - Lecture 16 CORBA Event Notification Service Application Objects Application Objects CORBA facilities CORBA facilities CORBAservices Domain Interfaces Domain Interfaces Object Request Broker Event Notification

22. 22 CS551 - Lecture 16 Group Requests with Event Service ca: Consumer Admin ca: Consumer Admin ppc: Proxy Push Consumer sa: Supplier Admin sa: Supplier Admin pps: ProxyPush Supplier pps: ProxyPush Supplier :Client :Event Channel :Event Channel :Ticker ppc=obtain_push_consumer() pps=obtain_push_ supplier() pps=obtain_push_ supplier() connect_push_ consumer() connect_push_ consumer() push() ca=for_consumers() sa=for_suppliers()

23. 23 CS551 - Lecture 16 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(); }; 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(); };

24. 24 CS551 - Lecture 16 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 Triggers n operation executions in one request. Defined at run-time. Advantages: –Smaller overhead on client side –Process results as they become available

25. 25 CS551 - Lecture 16 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 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

26. 26 CS551 - Lecture 16 Multiple Requests in CORBA Dynamic Invocation Interface supports multiple deferred synchronous requests module CORBA { interface ORB { typedef sequence RequestSeq; Status send_multiple_requests ( in RequestSeq targets ) Status get_next_response(in Flags f); }; Dynamic Invocation Interface supports multiple deferred synchronous requests module CORBA { interface ORB { typedef sequence RequestSeq; Status send_multiple_requests ( in RequestSeq targets ) Status get_next_response(in Flags f); };

27. 27 CS551 - Lecture 16 Multiple Request Example: Revenue from a portfolio of assets :Client:Client rs:RequestSeqrs:RequestSeq:ORB:ORB:Share:Share:Bond:Bond r1=create_request(”dividend”) r2=create_request(”interest”) add(r1) add(r2) dividend() send_multiple_requests(rs) interest() get_next_response()

28. 28 CS551 - Lecture 16 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 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

29. 29 CS551 - Lecture 16 Request 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

30. 30 CS551 - Lecture 16 Unicast 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

31. 31 CS551 - Lecture 16 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! 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!

32. 32 CS551 - Lecture 16 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 Atomic requests are either performed completely or not at all Clients know from where to recover Implemented using transactions Still quite expensive

33. 33 CS551 - Lecture 16 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 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

34. 34 CS551 - Lecture 16 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 Similar to at-most once reliability except that Clients are not notified about failures Example: CORBA oneway requests No overhead for error handling

35. 35 CS551 - Lecture 16 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 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

36. 36 CS551 - Lecture 16 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 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

37. 37 CS551 - Lecture 16 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 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

38. 38 CS551 - Lecture 16 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 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

39. 39 CS551 - Lecture 16 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 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