Yugi Lee STB #555 (816) 235-5932 yugi@cstp.umkc cstp.umkc/~yugi

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

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

3. Outline • Request Synchronization • Synchronous • Oneway • Deferred Synchronous • Asynchronous • Request Multiplicity • Group Requests • Multiple Requests • Request Reliability CS551 - Lecture 16

4. :Client :Server Op() Request Synchronization • OO-Middleware: synchronous requests. • Synchronous requests might block clients unnecessarily. • User Interface Components • Concurrent Requests from different servers CS551 - Lecture 16

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

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

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

8. :Client :Server r=create_request() r:Request send() Op() delete() Oneway requests in CORBA • If oneway declarations cannot be used: Use dynamic invocation interface CS551 - Lecture 16

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

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()); //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

11. :Client :Server r=create_request(“op”) r:Request send() op() get_response() 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 CS551 - Lecture 16

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() CS551 - Lecture 16

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

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

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 (request & reply queues) • Asynchronous requests can be achieved • Message-Oriented Middleware (MOM) • IBM’s MQSeries, DEC Message Queue, Falcon (COM) CS551 - Lecture 16

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

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

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

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

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

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

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

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

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

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

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

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

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

29. Request Reliability • Unicast • Exactly once • Atomic • At-most-once • At-least-once • Maybe • Multicast • k-reliability • totally ordered • best effort CS551 - Lecture 16

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

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

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

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

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

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

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

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

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

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