Understanding Remoting Better

1. Understanding .NET Remoting Better Kumar Gaurav KhannaDeveloper Evangelistgkhanna@microsoft.comMicrosoft Corporation

2. 2 Agenda Understanding the Why and the How… The Fundamentals Understanding the Internals Lifetime Management Security and Remoting Contexts and Dynamic Publication Considerations

3. 3 Understanding the Why and the How…

4. 4 Understanding the Why… Cross-AppDomain Communication Allows objects in different .NET AppDomains access each other directly. Includes communication between Application domains in the same Microsoft Win32® process, in different processes on the same machine, and different machines. The .NET analogy to DCOM but better! No proprietary communication protocol Uses TCP and HTTP transports Possible to control object lifetime

5. 5 Understanding the How…

6. 6 The Fundamentals

7. 7 .NET Remoting vs DCOM Channel based architecture Flexible in activation and deployment options Is customizable (you can add logging or other features) .NET Remoting requires more explicit client and server application configuration. .NET Remoting has no built-in support for security.

8. 8 Development Flow Write the components that you wish to make remotely accessible into a .NET DLL. Configure any managed executable to host those components. Write the client(s) that call the components. Unlike DCOM, the client application must configure the object to be remoted.

9. 9 Writing Remotable Components To make an object remotable, simply derive it from MarshallByRefObject Makes the object externally creatable Allows it to be passed in method/property calls Causes the object to run in the application domain that created it What in an object is remoted? Public methods (non-static) Public properties (non-static) Public fields (non-static)

10. 10 Remotable Object Example

11. 11 Writing Serializable Components To make an object marshall itself by value, make it serializable Use the [Serializable] attribute or implement ISerializable Copy of the object in the client application domain. Member-wise copy of an object’s public and private member variables Member objects in object-graph must be serializable themselves Allows object to be passed in method/property calls Requires that the serialized object assembly be referenced by the client and server

12. 12 Serializable Object Example

13. 13

14. 14 Configuring Remoting Hosts A Remoting host can be any managed .exe To be a host, an .exe file must do two things: Configure a remoting channel Register each of the types it will make available via remoting Can be done programmatically or using config files

15. 15 And we talk using… Channels! A channel is the inter-AppDomain transport mechanism. Can be done programmatically or via a config files. There are two choices: HTTP, or TCP. Which one should you use? TCP is faster than HTTP; Uses binary formatting HTTP channel is required for calling objects hosted in IIS; uses SOAP formatting

16. 16 Registering Remoting Objects Object types can be configured to have several activation behaviors: Singleton SingleCall Client activated Singleton and SingleCall types are known as WellKnown object types

17. 17 SingleCall objects Server's remoting layer creates one SingleCall object per method call Each object services one and only one request Created on-demand as method calls arrive Lifetime limited to method call Useful in stateless applications Best choice for load-balanced applications

18. 18 Singleton objects Server's remoting layer creates one Singleton object Sole object handles method calls from all clients Lifetime equals server lifetime Useful in stateful applications Can only store client-independent state Best choice where overhead of creating and maintaining objects is substantial

19. 19 Client activated objects Server activated is one activation model Client activated is quite different Each client activation creates one object Object's lifetime extends until the earliest event: Client drops reference to object Object's lease expires Similar to COM coclass activation semantics Can store per-client state, receive constructor args

20. 20 Well-known objects Server activated types are "well-known" Server tells remoting Here's a type Here's how and when to instantiate the type Here's the name (end point) a client will use to contact the type Clients tell remoting Connect to this server machine Get the (known) type at this end point (name)

21. 21 Configuring Remoting Clients Client specifies the URL of remotable object Programmatically Config file For WellKnown objects Activator.GetObject() instead of New to create a remote object reference GetObject immediately returns a proxy to the object without creating the object first. This avoids unnecessary network roundtrips. Client activated object factory exists at a URL Client requests factory to instantiate object and return a proxy to it using Activator.CreateInstance Client can also make same request using new

22. 22 Example of Channel and Type Registration For a Remoting Host

23. 23

24. 24 Activator.GetObject GetObject returns a proxy for the well-known type served at the specified location No network traffic until first method call! Proxy built on client from metadata Server activates object on first method call

25. 25 RemotingServices.Connect GetObject is a thin wrapper over System.Runtime.Remoting.RemotingServices.Connect Which calls System.Runtime.Remoting.RemotingServices.Unmarshal

26. 26 RemotingServices.Unmarshal RemotingServices.Unmarshal does the real work Checks that type is MarshalByRef or Interface Find or creates identity based on URI Creates envoy and channel sink chains Gets or creates transparent and real proxy End results is client gets a proxy

27. 27 Activator.CreateInstance Client activation requires a network round trip Send activation message to server Can include constructor parameters Server creates object using specified constructor Server builds ObjRef about new instance Server sends message with ObjRef to client Client creates proxy from ObjRef

28. 28 Activator.CreateInstance CreateInstance returns a proxy to a new instance of the type served at the specified location

29. 29 Remoting config file All hard-coded remoting information in prior example can reside in external config file Default filename is executable plus ".config" E.g. RuntimeHost.exe is RuntimeHost.exe.config Host must tell remoting to use the config file RemotingConfiguration.Configure (file) Server code simplifies…

30. 30 Example of Type Registration for a Remoting Client

31. 31

32. 32 Client Metadata Deployment Options For a client to use a remoted object, it must have the object’s metadata Object metadata can be deployed to a client application in the following ways: Include the remoted object assembly with client applications. Specify interfaces in a separate assembly and reference that assembly in both client and server applications. Generate metadata-only assemblies using Soapsuds.exe. They use the HTTP remoting channel and the SOAP formatter.

33. 33 Hosting Objects in IIS IIS can be used as a remoting host All remoting object types can be specified Remoting objects can be exposed as Web Services WSDL is returned in response to WSDL queries For WellKnown objects, use: http://<Computer>/<VirtDir>/ObjectURI>?wsdl For Client Activated objects, use: http://<Computer>/<VirtDir>/RemoteApplicationMetadata.rem?wsdl The object is accessible to SOAP clients SOAP clients cannot access Client Activated objects .NET Remoting objects use RPC SOAP encoding

34. 34 Hosting Objects in IIS Clients can use the HTTP channel with either the binary or SOAP formatters When creating IIS hosted .NET objects, you cannot specify constructor parameters

35. 35 Hosting in IIS – The How… Put the DLL containing the remotable objects into the \bin directory of an IIS Web application or put it in the GAC Put the remoting configuration section into the Web.Config file for the Web application Alternatively, the Gobal.asax file can contain an Application_Start() function where you can register your objects in the same way you would in an .exe host. Do not specify a channel. IIS already listens on port 80. Specifying a port for a channel causes exceptions to be thrown when new IIS worker processes are started. WellKnown object URIs must end with .rem or .soap.

36. 36

37. 37 Understanding the Internals

38. 38 How does it work? Client receives a proxy object when activating a remote object Client "thinks" proxy is actual object Proxy is instance of TransparentProxy class Mimics inheritance hierarchy of remote object A call on the proxy: passes control to actual object when in same domain creates an IMessage to object in different domain Passes message to a RealProxy instance

39. 39 How does it work - RealProxy class RealProxy forwards msg to remote object Handles all method calls to remote object RealProxy class can be extended, customized For example, load balancing method calls, client side validation/processing of certain calls TransparentProxy cannot be replaced Internal remoting implementation class

40. 40 How does it work - IsTransparentProxy You can call IsTransparentProxy on any object reference to see if it is a proxy Normally, you don't care How does TransparentProxy know about the remote class?

41. 41 How does it work - ObjRef Runtime creates an ObjRef when you register an object with the remoting services An ObjRef contains all information required to locate and access a remote object the strong name of the class the class's hierarchy (its parents) the names of all interfaces the class implements the object URI details of all available registered channels

42. 42 How does it work - Client-side remoting Client calls method on TransparentProxy TransparentProxy builds message Stack frame to message TransparentProxy passes msg to RealProxy RealProxy forwards msg to envoy sink(s) Last envoy sink forwards msg to context sink(s) Last context sink forwards msg to channel sink(s) Channel sinks turn message into a byte stream Last channel sink sends byte stream to server

43. 43 How does it work - Server-side remoting Channel receives a stream of bytes Channel forwards stream to channel sink(s) Last channel sink converts stream into message Last channel sink forwards msg to context sink(s) Last context sink forwards msg to server sink(s) Last server sink is stack frame sink Stack frame sink builds and issues call to requested method

44. 44 How does it work - Remoting chain

45. 45 Lifetime Management

46. 46 Object Life Time Management Need to know not-required objects for garbage collection Differs from DCOM pinging that’s not scalable Concept of lease allows Sponsors to control object lifetime Leases apply only to Singleton and Client Activated objects.

47. 47 Object Lifetime Management Default initial lease of five minutes Each call renews the lease by two minutes or the current lease time, whichever is greater Lease times can be controlled through the <lifetime> section of a config file Individual objects can control their own lease times by overriding MarshalByRefObject.InitializeLifetimeService();

48. 48 Object Lifetime Management Clients can explicitly renew leases using the RemotingServices.GetLifetimeService() API and the ILease interface

49. 49 Object Lifetime Management Use a lease sponsor to directly control the life of a lease. The lease manager periodically calls the sponsor requesting it to renew the lease.

50. 50

51. 51 Security and Remoting

52. 52 .NET Remoting Security .NET Remoting has no security built into it! Remoting relies on the remoting host to provide security The only host that provides security for remoted objects at present is IIS; therefore, secured objects must be hosted in IIS The HTTP remoting channel supports the IIS security mechanisms In IIS, standard ASP.NET security mechanisms can be used

53. 53 .NET Remoting Security To secure remoted objects via IIS: Configure the objects in IIS as you normally would. Set the desired security settings for the IIS application. Configure the client to use the correct authentication method For Integrated security, use the HTTP channel and set the useDefaultCredentials property to TRUE. Set the credentials property for a channel to a NetworkCredential to enable Integrated, Basic, and Digest authentication. If IIS security is enabled, only clients using a properly configured HTTP channel can make calls.

54. 54 .NET Remoting Security Configure the Web.config file to allow or deny access to the IIS application using the following tags in Web.Config: <authentication> Determines which identity will be placed in the HttpContext. It must have attribute “mode = Windows”. <authorization> Allows/denies access based on the identity placed in HttpContext. It contains comma-separated lists of users. <identity> This is an optional setting. It determines what identity the thread runs as. If the attribute impersonate=“true” is set, the caller will be impersonated for the call. This is useful for ACL checking.

55. 55 .NET Remoting Security Client-side configuration tags:

56. 56

57. 57 Context and Dynamic Publication

58. 58 Understanding CallContext Set of named objects that flow with the execution code path Flows across local function calls and to remote objects Flowed back to a remoting caller when a call returns. Clients can place items into the context that can be modified Types placed into the context implement ILogicalThreadAffinitive interface and are serializable.

59. 59 Dynamically Publishing a WellKnown Object WellKnown objects cannot have a non-default constructor. Use RemotingServices.Marshal to publish an existing object instance and Remoting Services.Disconnect to disconnect it.

60. 60

61. 61 Considerations

62. 62 Considerations - Server activated object Type identity is determined using the type and assembly name combination Name of assembly containing the type must be identical on client and server Name of type must be identical on client and server SoapSuds builds assembly with correct name

63. 63 Considerations - Client activated object Same requirements as server activated objects Additionally, client assembly must contain an implementation of the types All members must have identical signatures as same members in the server's implementation Implementation need not be the same! Typically stubs throw NotSupportedException SoapSuds creates such stubs for clients using SOAP

64. 64 To sum up… .NET Remoting is future of Distributed communication in Windows Development Highly Flexible Complete control over lifetime, serialization, transport channels Provides variety of object activation mechanisms Hosting in IIS helps scaling and securing Indigo is the future of Remoting

65. 65 For More Information… This PPT and Source Code Download at http://www.microsoft.com/india/msdn/events/presentations.aspx MSDN Web site at msdn.microsoft.com Dot Net Remoting www.dotnetremoting.cc

66. 66 Inspired Community; Inspiring People!! Recognition program – strives to identify budding dedicated individuals who share a passion for community Found active in newsgroups, online forums, usergroups, inventing new ways to help their peers For more information visit:

67. 67 Usergroups Exist to facilitate education and peer to peer knowledge exchange Run by the community, for the community Great place to Learn about new technologies Discuss problems Interact with peers Interested? Join one today!

68. 68 MSDN Expert Chats Talk to experts on the upcoming technologies Get your queries cleared Understand how the technologies should be used optimally

69. Questions?

70. 70