Asynchronous RPC Abstraction Motivation Strong coupling induces - PowerPoint PPT Presentation

Asynchronous RPC

Abstraction  Motivation  Strong coupling induces strong dependencies in distributed application  Latency of remote invocations different than local ones  Remove flow coupling  (Subtypes of) proxy abstraction  Oneway call: no return value  Explicit future: no inherent waiting for return value  Implicit future: no necessary waiting for return value  From concurrent programming  Usually based on specific compilation

Oneway Call  Abstraction  Proxy  Type  Same as server object  Reply-less calls can have different semantics by default, or  Methods without return value can be marked, e.g, oneway public interface Bob { public void helloBob(); public String howIsBob(); }

 Remote invocation returns without waiting  For termination of the remote method body execution  Or even without awaiting an ack for successful reception  Obviously flow coupling is removed  When anyway not necessary, or by reasoning/designing differently, e.g.,  1 synchronous invocation -> 2 asynchronous invocations public interface BobCallback { oneway public void BobIs(String s); } public interface Bob { oneway public void howIsBob(BobCallback bcb); }

 E.g.,  ABCL, Actalk, Hybrid, PO, CORBA  With or without different semantics for reply-less methods  Anthropomorphism  A hologram which can not talk, only listen  Transmits what initiator says  Replies (if any) must be sent by some other means, e.g., a second hologram which only talks

Explicit Future - Polling  Principle  Return future object instead of return value  Return value can be queried through future object  Abstraction  Future proxy  Type  Original server object type modified/subtyped  Maybe use of keyword to mark methods, e.g., future  E.g.,  ABCL, Act++, CSmalltalk, PO, CORBA AMI

 Each return value type T  Is changed to TFuture , e.g., public interface Bob { public String howIsBob(); }  Becomes public interface BobProxy extends Bob, Proxy { public String howIsBob(); public StringFuture howIsBob(); }

 Basic future type public abstract class Future { public boolean isAvailable() {…} public void wait() {…} … }  Hence StringFuture is something like public class StringFuture extends Future { public String poll() {…} public String pull() {…} … }

Example  Consumer  Producer  Client  Server  Invoker  Invokee Bob bob = public class BobServer implements new BobProxyImpl(…); BobSkeleton {…} Bob bob = new StringFuture how = BobServer(…); bob.howIsBob(); bob.howIsBob(); System.out.println( how.pull());

Explicit Future - Callback  When polling for replies with futures  Flow coupling is reduced, but not entirely avoided  Only callback mechanism can fully remove flow coupling  Abstraction  Callback proxy  Type  Original server object type Is modified/subtyped  Maybe use of keyword to mark methods, e.g., future  E.g.,  ABCL, Act++, CSmalltalk, CORBA AMI

 Each return value type T  Is changed to void , and the operation gets an additional argument, e.g., public interface Bob { public String howIsBob(); }  Becomes (generated by compiler) public interface BobProxy extends Bob, Proxy { public String howIsBob(); public void howIsBob(StringCallback c); }

 Basic callback type public interface Callback { public void exceptionOcc(Exception ex); … }  Hence StringCallback is something like public interface StringCallback extends Callback { public void reply(String s); }  Implemented by application

Example  Consumer  Producer  Client  Server  Invoker  Invokee public class mySCB implements StringCallback { public class BobServer implements BobSkeleton public void reply(String s) {…} { System.out.println(s); } Bob bob = new BobServer(…); … } Bob bob = new BobProxyImpl(…); bob.howIsBob(); bob.howIsBob(new mySCB()); > good

Implicit Future  Principle  Developer ● Use the return value of a remote invocation as late as possible in the code  System ● Return immediately from the call ● Even though the value is not fixed ● « Insert » it as soon as available ● If it is queried before, block

 Abstraction  Proxy  Type  Same as original type  Future by default, or explicitly mark future calls e.g, future public interface Bob { public String howIsBob(); }  E.g.,  Eiffel//, Karos, Meld

 Illustration Bob bob = …; /* lookup */ /* remote call is issued */ String how = bob.howIsBob(); … /* how might still be undefined */ … /* if how is still undef., this will block */ System.out.println(how); …

Anthropomorphisms  Explicit future - polling  A hologram which does (can) not answer to your question  Instead you get a phone nb etc., where you can get the reply  You might only get « occupied » if the reply is not ready  E.g., hologram of a stupid and lazy assistant who promises to find the answer for you, or tells you where to find it  Explicit future – callback  A hologram which does not reply immediately, still « listens »  When a reply is ready, you will be called  E.g., hologram of a stupid but nice assistant who will find out some details calls you

 Implicit future  A hologram which replies immediately with some « superficial » reply  You think you have understood, yet you have not  If you need more details immediately, you must give the hologram time  Otherwise, you can continue, the hologram will give you more information later anyway, which will help understand - « aha » effect  E.g., hologram of a smart assistant: you ask a question, and she/he does not know the reply, so you are drowned in superficial talk giving him/her more time to find the right reply

Asynchronous RPC CORBA Asynchronous Messaging Interface (AMI)

Asynchr. Invocations in CORBA  CORBA enables  Oneway operations with best-effort semantics  Explicit future with DII  And offers the Asynchronous Messaging Interface (AMI):  Consisting of two parts  Interface for specifying invocation policies (qualities of service for invocations)  Implied IDL: asynchronous variants of IDL defined operations ● Future ● Callback

 For each interface <I> , the IDL compiler generates  An AMI_<I>Poller value type for futures  An AMI_<I>Handler interface for callbacks  An AMI_<I>ExceptionHolder value type for exceptions  Example interface Agenda { void add_appointment(in Time at, in Person p) raises (AlreadyTaken); void remove_appointment(in Time at) raises (NoAppointment); Person get_appointment(in Time at); };

Implied IDL interface Agenda { AMI_AgendaPoller sendp_ add_appointment(in Time at, in Person p); AMI_AgendaPoller sendp_ remove_appointment(in Time at); AMI_AgendaPoller sendp _get_appointment(in Time at); void sendc_ add_appointment(in AMI_AgendaHandler handler, in Time at, in Person p); void sendc_ remove_appointment(in AMI_AgendaHandler handler, in Time at); void sendc_ get_appointment(in AMI_AgendaHandler handler, in Time at); };

Poller interface AMI_AgendaPoller : Messaging::Poller { void add_appointment(in unsigned long timeout) raises(AlreadyTaken, CORBA::WrongTransaction); void remove_appointment(in unsigned long timeout) raises(ToAppointment, CORBA::WrongTransaction); void get_appointment(in unsigned long to, out Person p); };  Only in / inout parameters remain in operation  inout parameters are changed to in  out / inout parameters including any return value are added to corresponding parameters of poller operation  inout parameters are transformed to out

Handler interface AMI_AgendaHandler : Messaging::ReplyHandler { void add_appointment(); void add_appointment _excep (in AMI_AgendaExceptionHolder h); void remove_appointment(); void remove_appointment _excep (in AMI_AgendaExceptionHolder h); void get_appointment(in Person p); void get_appointment _excep (in AMI_AgendaExceptionHolder h); };  xxx_excep() method is called if an exception occurred

ExceptionHolder value AMI_AgendaExceptionHolder : Messaging::ExceptionHolder { void raise_ add_appointment() raises (AlreadyTaken); void raise_ remove_appointment() raises (NoAppointment); void raise_ get_appointment(); };  Additional information, e.g., target can be obtained through supertypes of  ExceptionHolder , ReplyHandler, Poller

Publish/Subscribe

Origins  Group -based systems  Inherently one-to-n  Anonymous Communication  Derived from Generative Communication (Tuple Space)  Targeting at strong decoupling of participants, e.g., for  Very large, long-lasting, scalable applications  Based on Information Bus abstraction, several flavors ● Topic- based : iBus, SmartSockets, TIBCO, Vitria / JMS, CORBA Event & Notification Srvcs, some with a touch of ● Content- based : Gryphon, Siena, Jedi, JavaSpaces, DACs ● Type- based : GDACs, JavaPS

Publish/Subscribe  Model  Producers publish information  Consumers subscribe to information  Usually producers and consumers both in push mode  Decoupling of participants  In time  In space  In flow  Enforces scalability