1. Remote procedure call (RPC)

2. Outline >Remote procedure calls >Middleware >Distributed objects >CORBA >.Net Remoting

3. Outline >Remote procedure calls (RPC) >Middleware >Distributed objects >CORBA >.Net Remoting

4. Online shop example >Implementing an online shop client and server with just sockets is tedious >Smart approach: >public Receipt order(Book[] books) >public Book[] search(String keyword) >Client calls procedures on the server as if they were local procedures -> RPC

5. RPC – Overall Goal 1/2 >Provide distribution transparency >Programming as if there is no distribution >“Hunt for the holy grail” >We will get quite close, but we will never get hold of the grail >“We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure.” [1] >Degenerated case: Programming as if there is only distribution [1] S. C. Kendall, J. Waldo, A. Wollrath and G. Wyant: A Note on Distributed Computing

6. RPC – Overall Goal 2/2 >Hide expert knowledge in the tool chain >“Sockets” >Session management >Data representation >Data transformation >Service discovery >… you name it …

7. Remote procedure call >RPC sits on top of the transport layer >Hiding network communication from application programmer i.e. building abstraction >Sockets etc. are not visible to the application programmer >Usually a request-reply protocol is specified >Procedure invocation message (Request) >Procedure result message (Reply) >RPC is responsible for >Marshalling & unmarshaling data (parameters and results) >External data representation >Addressing

8. Problems >Heterogeneity >Different data representations (little-endian vs. big-endian, ASCII vs. EBCDIC) >Addressing >How to identify a remote process? >Partial failure >What happens if the server crashes during execution? >Can we guarantee “at least once” semantics? >What happens if the client crashes? >Can we detect and remove orphans? >What happens if a crashed machine is rebooted? >Can addresses survive a reboot?

9. How is it implemented? >Client-side proxy >Implements the interface of the target procedure on the client side >Client calls this interface locally (-> transparency) >Procedure is invoked on a remote machine >Server-side proxy >Implements the interface of the target procedure on the server side >Incoming requests are dispatched to this interface locally >Server does not realize that the call is a remote call >The result is: almost distribution transparency … >… if there is no failure

10. Proxy Generation >We need a tool that generates the proxies >… to be continued …

11. Flow of action 1/3 Client Server wait for requestCall local procedure and return result request reply wait for result time wait for request Call remote procedureReturn from call

12. Flow of action 2/3 1.Client calls procedure on client-side proxy locally 2.Client proxy marshals parameters and sends message to server proxy 3.Server proxy unmarshals parameters and calls procedure locally 4.Procedure does work and returns result to the proxy 5.Server proxy marshals result and sends message to client proxy 6.Client proxy unmarshals result and returns to client

13. Bookstore example ClientServer Client process Client proxyServer proxy Server process receipt order(Book[] books) order, books receipt order(Book[] books) receipt

14. Proxy Generation >We need a tool that generates the proxies >The tool has no know about >The interface >Procedure names >Parameter types >Return types >Exceptions >… to be continued …

15. Calling semantics >Local case >Call-by-value >Call-by-reference >Call-by-reference remotely is difficult >Simulate by call-by-copy/restore >Transmit copy of the data and transmit changed copy back >Slightly different semantics! >Increased overhead for collections (graphs, lists,…)

16. Marshalling / Unmarshalling >Assembling to external format: Marshalling >Disassembling from external format: Unmarshalling >Complex data types must be serialized >Lists, Structs, Graphs, … >When data formats of machines differ >Use agreed common external format >Sender transforms to external >Receiver transforms external to his own >Use sender’s format and “receiver makes it right” >Sender must send indication of format

17. Proxy Generation >We need a tool that generates the proxies >The tool has no know about >The interface >Procedure names >Parameter types >Return types >Exceptions >Data types

18. Interface definition >Interfaces are defined by an Interface Definition Language (IDL) >Language-neutral >Usually C-style syntax >Proxies can be generated from IDL >Different proxies for different programming languages >E.g. client in Java -> client proxy in Java >E.g. server in C -> server proxy in C

19. IDL example module shops{ interface bookshop{ struct Book{ string name; long isbn; }; struct Receipt{ string bank; long accountnumber; int amount; }; Receipt order(in Book[] books); Book[] search(in string keyword); };

20. IDL in the Tool Chain IDL-Compiler C-Compiler #include Linker shop_sproxy.o shop.idl shop_cproxy.cshop_sproxy.c shop_cproxy.oshop.h shop_client.cshop_server.c shop_client.oshop_server.o shop_client.exeshop_server.exe C-Compiler

21. IDL Pros & Cons >Pros >Language neutral >Cons >Generated interface can be ugly >Example: CORBA and C++ >Developers have to master two languages >Requires top-down approach >First IDL, then implementation >Cannot simply use existing code & data structures >Solutions? Yes! >.NET Remoting does not require any IDL

22. RPC failure I >Local call failure >When call fails the whole program fails >What can go wrong with RPC? 1.Client cannot find the server 2.Client crashes after sending request 3.Request gets lost 4.Server crashes after receiving request, before sending response 5.Response gets lost 6.Client crashes before receiving response

23. RPC failure II >Fault detection >Wait for expected response >After timeout  failure >What is a good timeout? >Maybe the network is too slow >Maybe the other computer is too slow >Usually no real-time  Calculation of optimal timeout is impossible >No way to find out what went wrong >Remote machine does not respond. Why? >Machine crashed? >Message loss?

24. Client crash >Processes on servers for non-existing clients (Orphans) >Block resources >Solution >Client sends “heartbeat” >Server pings client >Pings & heartbeats are expensive and subject to failures, too >Client restart >Do not mix new with old messages >E.g. counter for every restart

25. Server crash >Client gets a timeout waiting for the response >Did the server process the request? >Possible semantics: >Maybe >Nothing to be done >At-least-once >Repeat until response received >At-most-once >Serial numbers for requests >Exactly-once >Transactions

26. RPC call variants >Synchronous (blocking) call >Parallelism in distributed system is not exploited >No parallel invocations to multiple servers >Asynchronous RPC >“Fire-and-forget” >Deferred synchronous RPC >Do something while server is executing

27. Reentrance 1/2 Client1Server1 proc(x) Client2 proc(y) The procedure proc is invoked by Client2 while it is working on the request of Client1 Solution: Serialize requests

28. Reentrance 1/2 ClientServer1 proc(x) Server2 proc2(x) proc(y) The procedure proc is invoked by the Server2 while it is working on the request of the Client Serialization is NO solution. It would cause a deadlock

29. Example RPC systems >Sun RPC >Used by the Network File System (NFS) >Distributed Computing Environment (DCE) RPC >Basis for Microsoft's DCOM (Component Object Model) >RPC (i.e. DCOM) has been used in several exploits

30. Outline >Remote procedure calls >Middleware >Distributed objects >CORBA >.Net Remoting

31. Motivation >Implementing a distributed application on top of sockets is tedious >Dealing with challenges of distributed systems on your own: >Distribution transparency >Interoperability (heterogeneity e.g. data representation) >Security >Common services: Naming, Persistency, Events, Transactions, … >Higher level of abstraction: middleware >Deals with challenges of distributed systems (to a certain degree) >Provide additional services (e.g. naming, persistency,…)

32. Definition >“There is no good definition for middleware.” >“The slash between client/server.” >“Middleware is the intersection of the stuff that network engineers don’t want to do with the stuff that application developers don’t want to do.”

33. “Classical” approach Computer A Network services Distributed application Computer B Network services Distributed application Computer C Network services Distributed application

34. Middleware Computer A Network services Computer B Network services Computer C Network services Middleware Distributed application

35. Models ClientServer Message passing send() receive() ClientServer Virtual shared memory write()read() ClientServer Remote procedure call proc() ClientServer Distributed object systems o.operate()

36. Services >Persistency >Security >Naming >Events >Transaction >Trader >Accounting

37. Examples >Distributed object system >OMG CORBA >Remote procedure call >DCE RPC >Message passing >IBM MQSeries >Virtual shared memory >Linda

38. Outline >Remote procedure calls >Middleware >Distributed object systems >CORBA >.Net Remoting

39. Distributed objects >Today’s commonly used programming languages are object-oriented Remote objects >“Remote objects” >Objects that can receive method invocations from objects in other processes >Including processes on a different machine remote interface >Objects get a remote interface >Usually defined in IDL remote object reference remote method invocation >Client needs a remote object reference to perform a remote method invocation

40. Why (distributed) object systems? >Middleware provides a programming abstraction >Programming languages changed >C, Pascal, Basic -> C++, Java, C#, Delphi, VisualBasic.NET >Object-orientation is the most prominent paradigm  Extend it to the remote case >Objects are well suited for proxies >Objects provide a public interface >The implementation is not visible to the outside >A proxy is just an object with a special (remote) implementation

41. Example Machine A Process A1 Machine B Local invocation Remote invocation O1 O2 O3 O4 O5 Process B1

42. How does it work? >Similar to RPC 1.Client calls method on client proxy object 2.Client proxy object & ORB does marshalling 3.Client-side ORB sends message 4.Server-side ORB receives message 5.ORB dispatches message 6.Server proxy receives message and unmarshals parameters 7.Server proxy calls method on remote object locally 8.Server proxy & ORB marshals result 9.Server-side ORB sends message 10.Client-side ORB receives message 11.Proxy receives message, unmarshals result and returns it to client

43. Client Flow schematics order, books receipt Client object Proxy object receipt order(Book[] books) Server Remote object Proxy object receipt order(Book[] books)receipt

44. Difference to RPC  Class A { void foo( int x ); } versus void foo( A* object, int x ) >In the local case there is no difference >In the remote case there is a difference  A* object is a pointer that cannot be marshaled object references >Distributed object systems introduce object references >An object reference is the remote equivalent to a pointer

45. Remote Object References >Similar to local object references >Uniquely identifies an object in the distributed system >Can be passed between processes on different machines >E.g. host, port, object key >Client must bind to an object using the reference >Binding builds a proxy on the client side >Remote methods can be invoked on proxy >Reference must contain enough information to allow binding (E.g. endpoint)

46. Remote Object Activation >Bookstore example: >We treat every book as an object >Every remotely accessible object has a remote object reference >However, books are stored in a database We cannot hold all book objects in memory >Solution  Create object references for virtual objects, for example (www.mybookstore.com, 80, ISBN:1-12345-434-5) >Virtual objects are incarnated (i.e. created from the database) upon invocation >They are garbage collected afterwards

47. Distributed Objects Realization > Language integrated >Definition of remote objects at language level >Easy to use >Language dependent >E.g. Java RMI >Language independent >IDL to specify interface >Objects can be implemented in any language >Even in a procedural language using procedures and data structures as object state >More programming overhead >E.g. CORBA

48. Static vs. dynamic invocation >Static invocation >Interface of the remote objects is known while client is being developed >Client must be recompiled when interface changes >Example: C++, Java >Dynamic invocation >Compose method invocation at runtime >Inspect target object or interface implicit in client implementation >Available methods, parameters,… >any invoke(object, method, parameters[]) >Typically used for interpreted languages & scripting languages >Example: TCL

49. Distributed object system examples >CORBA >.Net Remoting >Java RMI

50. Outline >Remote procedure calls >Middleware >Distributed object systems >CORBA >.Net Remoting

51. CORBA >Common Object Request Broker Architecture >Standard of the Object Management Group (OMG) >www.omg.orgwww.omg.org >Not a specific system >Describes a whole software architecture (OMA) >Programming language-independent >CORBA IDL to define object interfaces >Platform-independent >Object Request Brokers (ORBs) interoperate via specified protocols >GIOP (General Inter-ORB Protocol) & IIOP (Internet Inter-ORB Protocol) >Complete distributed object infrastructure >Lots of additional services

52. CORBA >CORBA‘s goal: „IDL-ize“ client/server middleware by two steps: >Turn everything into nails: CORBA IDLs >Give everyone a hammer: CORBA compliant ORB >Extreme “IDL-ing” >Even the local interfaces of the ORB are specified in IDL >The XML DOM API has been defined using IDL http://www.w3.org/TR/DOM-Level-2-Core/idl-definitions.html >Drawback >Everything is nice on the IDL level, but … >… generated interfaces are often ugly

53. ORB >Core of any CORBA system >ORBs build a “distributed object bus” Object Request Broker(s) Services Application

54. General CORBA system architecture Local OS Server ORB Object adapter ORB interface Skeleton Dynamic skeleton interface Object implementation Local OS Client ORB ORB interface Static IDL proxy Dynamic invocation interface Client application Client machineServer machine

55. Example invocation Local OS Object adapter Local OS Client ORB ORB interface Static IDL proxy Dynamic invocation interface Client application Client machine Client uses naming service to obtain remote object reference for target object Request message is sent as IIOP message Response message is sent as IIOP message Proxy unmarshals result and passes it to the client application Client binds to remote object reference -> proxy is generated Client calls remote method on proxy Client obtains initial reference to naming service from ORB Proxy marshals parameters and sends invocation request to ORB ORB uses OS functions to send GIOP request message to target ORB ORB receives response message and passes result to proxy Server ORB ORB interface Skeleton Dynamic skeleton interface Object implementation Server machine Object implementation executes remote method and returns result to skeleton Skeleton unmarshals parameters and calls object implementation Skeleton marshals result and passes it to the adapter Object adapter passes request to skeleton possibly first activating the object ORB send GIOP response message to client ORB ORB receives request message and looks for matching object adapter Adapter passes response to ORB

56. CORBA features >Static and dynamic invocation >Interface repository holds all interface specifications >Synchronous, asynchronous and deferred synchronous invocations >Interoperability >Programming language >IDL to specify object interfaces >ORB implementations >ORBs communicate via GIOP (General Inter-ORB Protocol) >CORBA services

57. CORBA services I >Collection service >Grouping objects >Query service >Querying objects in a declarative manner >Transaction service >Transactions on method calls over multiple objects >Naming >Naming of objects >Persistence service >Storing objects

58. CORBA services II >Security service >Secure channels,… >Trading service >Advertisements of object capabilities >Life cycle >Moving, creating, deleting objects >Event service >Asynchronous event broadcast

59. CORBA summary >Interoperability >CORBA services >Powerful but not easy-to-use

60. Outline >Remote procedure calls >Middleware >Distributed object systems >CORBA >.Net Remoting

61. .Net Remoting >Distributed objects in.Net >Language independent >As long as it’s a.Net language >No IDL >Highly configurable >Can be integrated with other systems

62. Application domains >Isolated execution space for applications >One process can host multiple application domains Process 1Process 2 Application domain 1 Application domain 3Application domain 2 Object Local invocation Remote invocation

63. Remote versus local objects >Objects in the same application domain >Local objects >Immediate method call >Objects by reference >All other objects >Remote objects >Call via proxy object >Objects are marshalled >Also context-bound objects >Not covered here

64. Marshalling >Objects must be serializable >[Serializable] and [NonSerialized] attribute >Extend ISerializable >Marshal-by-value >Copy of object is transferred >No link between copy and original >Marshal-by-reference >Object reference is transferred >Can be used to build a proxy of the original

65. Object activation >Client activated objects (CAO) >Client requests activation of remote object  Through Activator or using new >Server activated objects (SAO) >Single call >Object created per call >Stateless >Singleton >Object created at registration time >Shared instance for all clients >Can be stateful

66. Relevant namespaces and classes >Remote object  Namespace System.Runtime.Remoting  Inherit from System.MarshalByRefObject >Server side >Configuration, deployment,… >System.Runtime.Remoting.RemotingServices >Client side >Object activation >System.Activator

67. Shop example – server implementation public class Shop : MarshalByRefObject { public Shop { … (initialize shop) } public Book[] search(String keyword) { Book[] result = Databasetools.search(keyword); return result; } [Serializable] public class Book { … }

68. Shop example – server main using System.Runtime.Remoting.RemotingServices; public class server { public static void main(string[] args) { RemotingConfiguration.configure(“server.xml”); Console.ReadLine(); }

69. Shop example – server configuration

70. Shop example – client mainline using System.Activator; public class ShopClient { public static void main(string[] args) { Shop shop = (Shop)Activator.GetObject(typeof(shop), "http://targetHost:2000/myShop"); Book[] result = shop.search("Remoting“); … }

71. Deployment >Standalone application >Object lives as long as creating process lives >IIS >Only SOAP over HTTP (essentially a Web service) >IIS authentication and HTTPs support >Windows service >Can be controlled via service console >System.ServiceProcess.ServiceBase

72. How does it work? >Client side proxy is created automatically >No IDL, IDL-compiler >Uses reflection and reflection-emit >Generic server side proxy >Stackbuilder dispatches method invocations >Uses reflection

73. Messages >Proxies communicate via messages >Method invocation, method response >Constructor invocation, constructor response  Represented by objects implementing IMessage >Dictionary with (name, value) pairs, e.g.  " __Uri "  " __MethodName "  " __Args "

74. Sink chain / A conceptual view Transport Channel Server Object Formatter Sinks Proxy Formatter Sinks Client IMessage

75. Channels >Messages are sent through channels >TcpChannel, HttpChannel >Custom channels (e.g. IPX) >Endpoint-to-endpoint communication between proxies >Can implement channel sinks >Logging >Interception >Message transformations (e.g.  CORBA)

76. Formatters >Serialize objects >Used by channels >Implemented as channel sinks >Association between channels and formatters is configurable >Default: >TcpChannel  BinaryFormatter >HttpChannel  SoapFormatter >Custom: >IIOP, RMI,…

77. TcpChannel >System.Runtime.Remoting.Channels.Tcp >Uses TCP sockets >Permanent connection >Use in LANs >Transfer of compact binary wire format >Default: BinaryFormatter >.Net native format >Fast >Could use other formatters as well

78. HttpChannel >System.Runtime.Remoting.Channels.Http >Uses HTTP 1.1 >Stateless, scales well >Use in Internet environments >Transfers SOAP XML format >Default: SOAPFormatter >Interoperability >Slower >Could use other formatters as well

79. Sink chain / A detailed view Channel Sink* Formatter Channel Sink* Transport Channel Server Object Object Sink* Channel Sink* Formatter Channel Sink* Dispatch Sink Cross Context Sink Dynamic Sink* Lease Sink Stackbuilder Sink Transparent Proxy Envoy Sink* Ctx. Terminator Sink Dynamic Sink* Real Proxy Client Context Sink* Client Highlighted modules can be exchanged or customized. Sinks with * can have multiple instances.

80. Sinks  Implement IMessageSink >Drop-off for messages  Also implemented by Channel >Chain sink >Simple linked list via NextLink property >Message interception, modification, … >Custom sinks

81. Message path Channel Sink* Formatter Channel Sink* Transport Channel Server Object Object Sink* Channel Sink* Formatter Channel Sink* Dispatch Sink Cross Context Sink Dynamic Sink* Lease Sink Stackbuilder Sink Transparent Proxy Envoy Sink* Ctx. Terminator Sink Dynamic Sink* Real Proxy Client Context Sink* Client Message path is implemented as a sink chain.

82. Proxies >Transparent proxy >Looks like remote object >Builds messages  Calls Invoke(IMessage) on real proxy >Real proxy >Communication layer for transparent proxies >Could be used to implement load-balancing for example (first look for remote object with low workload)

83. Stackbuilder sink >Located at channel endpoint >Receives messages >Builds stack frame from message >Invokes method on actual object >Collect result and build response message

84. Object lifetime >How to garbage-collect distributed objects? >DCOM: reference counting + pinging >RMI: reference lists >CORBA: lifetime service (rarely used) >.Net remoting: Leasing >For CAOs >Time to live (lease) associated with each remote object >Increases with each invocation >Lease sponsors can prolong lease >Configurable

85. Advanced features >Asynchronous invocations >Same like local invocations >BeginInvoke, EndInvoke, IAsyncResult >Oneway (fire-and-forget) invocations  Methods with OneWay attribute >Callbacks >Delegate

86. Discussion >Powerful middleware >Application domains >Sink chain can be adapted >Different kinds of object activation >Standalone / IIS >Doesn’t enforce separation of interface and implementation >Conceptual drawback >However, very convenient in practice >Only hard-wired dispatcher