1 / 39

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

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. Motivation. The requests we have seen have two parties (client and server object)

Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related