CS551 - Lecture 161

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

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