1. .NET Remoting

2. Remoting Introduction The process of programs or components interacting across certain boundaries either different processes or machines Developer Speak - Remoting allows you to pass objects or values across servers in different domains using several different protocols.

3. Remoting Benefits Centralized Business Logic Physical Separation of Layers Secure Third Party Access

4. Why Use.NET Remoting? Objects in different.NET application domains cannot access each other directly –two apps running on same machine even cannot talk to each other without a third party (text files, logs etc) Enables client code in one application domain to call methods/properties of objects running in another application domain..NET analogy to DCOM

5. .NET Remoting Benefits Multiple transfer mechanisms – HTTP/TCP –If there is no web server running – put traffic on port 80 Multiple encodings – SOAP/ Binary (your own-serialise) Somewhat easy configuration

6. .NET Remoting and DCOM Both enable object-oriented communication between processes..NET Remoting has a completely different architecture..NET Remoting is more flexible (more activation and deployment options).NET Remoting is customizable (you can add logging or other features).NET Remoting requires more explicit client and server application configuration. DCOM simply allows you to change a registry entry. DCOM clients do not need to know the object is being remoted..NET Remoting has no built-in support for security.

7. Web Services vs. Remoting Web Services work cross platform..NET Remoting is designed to work within.NET Framework..NET Remoting is faster (TCP is fastest).NET Remoting allows use of Stateful Objects Web Services are simpler (programming-wise)

8. Remoting Channels Transfer mechanism that is used to pass calls between a client and a server There are two choices : 1.HTTP – required choice for making calls to objects hosted in IIS. 2.TCP – much faster (about 5x)

9. Remoting Channels Transport messages between boundaries Can listen for inbound messages or send outbound messages –Or both!.NET framework provides channel classes for TCP and HTTP remoting

10. TCP Remoting System.Runtime.Remoting.Channels.Tcp Uses a binary formatter by default Serializes messages into binary stream for transport

11. HTTP Remoting System.Runtime.Remoting.Channels.Http Serializes messages using the SOAP-XML formatter (ascii based)

12. Message Formatting TCP can be configured to transport using the SOAP formatter HTTP can be configured to use the Binary formatter However, the defaults are: –TCP – Binary –HTTP – SOAP/XML

13. Channel Classes TcpChannel and HttpChannel implement the logic required for client and server sides There are further, more specialised classes –TcpServerChannel, HttpServerChannel –TcpClientChannel, HttpClientChannel

14. Server Activated Objects Is an object whose lifetime is controlled by a server The server application makes information available and assigns it a unique name Clients can therefore use this name to lookup and connect to the server object –This is known as a WKO – Well Known Object

15. Server Activated Objects Example // A sample single call Server Activated Object public class Hello : MarshalByRefObject { public String Greetings(String user) { String ret = String.Format("Hello {0} from {1}:{2}", user, AppDomain.CurrentDomain.FriendlyName, this.GetHashCode()); Console.WriteLine(ret); return ret; } You must inherit from MarshalByRefObject The return string is can be anything – you don’t have to use String.Format either

16. Exposing a Server Activated Objects To register a WKO for remoting, a server application must do the following 1.Register at least one server-side channel 2.Register the identity (type) of remote object that will be called 3.Keep the server running/alive

17. Exposing a Server Activated Objects example class MyApplication { static void Main(string[] args) { // STEP 1 ChannelServices.RegisterChannel( new System.Runtime.Remoting.Channels.Tcp.TcpServerChannel(9000)); // STEP 2 RemotingConfiguration.RegisterWellKnownServiceType( typeof(Hello), "GreetingServer", WellKnownObjectMode.SingleCall); // STEP 3 - keep alive Console.WriteLine("Press a key to quit"); Console.Read(); }

18. RemotingConfiguration Namespace Just registering the channels is not enough. –All remoting types must be registered with the.NET framework as well This is achieved via call to RegisterWellKnownServiceType at step 2 The Uniform Resource Locator (URI) is also supplied (“GreetingServer”) Now we have a server object published on a port which is referred to by its URI

19. The Client Side Before activating a remote object – a client must be used. Steps 1.Register the channel to be used via the RegisterChannel method 2.Activate Remote object via Activator.GetObject Specifiy the type of Object required and the URL

20. Activator.GetObject A proxy is generated when this is called Holds information required for communication to foreign resource/object –(Channel, port number, host name etc) Proxy object is treated as if it is the remote object itself Corresponding remote object is actually not created until first method is called

21. The Client Side public class Client { static void Main(string[] args) { // STEP 1 ChannelServices.RegisterChannel( new System.Runtime.Remoting.Channels.Tcp.TcpClientChannel()); // STEP 2 Hello greets = (Hello)Activator.GetObject(typeof(Hello), "tcp://localhost:8085/GreetingServer"); String greeting = greets.Greetings("Trent"); Console.WriteLine(greeting); String greeting2 = greets.Greetings("Janet"); Console.WriteLine(greeting2); Console.WriteLine("End of Client"); }

22. 2 Hash Codes? This means 2 different instances of the remote type were created for each method call – ON THE SAME PROXY

23. Single-Call Objects A new object is created on the server for each method call and then removed from memory after completion What does this do to instance variables or the state of the object on the server Answer – You can’t store anything

24. Singleton Objects A remote object is created and is used for repeated method calls Configure this on the server using RemotingConfiguration.RegisterWellKnow nServiceType

25. Server Code Options Single-Call (No stored state on Server) RemotingConfiguration.RegisterWellKnownServiceType( typeof(Hello), "GreetingServer", WellKnownObjectMode.SingleCall); Singleton (Ability to store state) RemotingConfiguration.RegisterWellKnownServiceType( typeof(Hello), "GreetingServer", WellKnownObjectMode.Singleton);

26. Singleton Result

27. Singleton Considerations Even when you store state, another client or method might change the instance variables –Leaves your object in a invalid state Thus, it is better to implement atomic operations where possible –Client sends parameters required to server method and returns result. No other method calls are required

28. Required Instance Data If you need to store instance variables then Server-Activated objects are not useful and should not really be used Instead, Client-Activated Objects are available for this purpose

29. Client-Activated Objects Lifetime is controlled by the client Does not use GetObject as with a client for a Server Activated object Instead we use Activator.CreateInstance What does this mean? –The remote object is created immediately – NOT when the first method is called –Client controls the creation of the object then

30. Server For A Client Activated Object class ServerForClientActivatedObject { static void Main(string[] args) { ChannelServices.RegisterChannel(new TcpServerChannel(8085)); RemotingConfiguration.RegisterActivatedServiceType(typeof(Hello)); // keep alive Console.Write("Key to quit"); Console.Read(); }

31. Client for Client Activated Objects class ClientForClientActivatedObject { static void Main(string[] args) { ChannelServices.RegisterChannel( new System.Runtime.Remoting.Channels.Tcp.TcpClientChannel()); Hello greets = (Hello)Activator.CreateInstance( typeof(Hello), null, // params new object[] { new UrlAttribute("tcp://localhost:8085")}); String greeting = greets.Greetings("Trent"); Console.WriteLine(greeting); String greeting2 = greets.Greetings("Janet"); Console.WriteLine(greeting2); Console.WriteLine("End of Client"); }

32. Result of Client-Activated Objects Object was created by client, on the server Only one object was created (see hash code value) Server Client

33. Creating Proxy Classes If a client application wants to access a remote one, the metadata (info) of that remote object must be made available – locally at the client So far we have created clients with a local copy of the remote object we used/created Thus, we could not create a “hello” object without having a local copy available Sometime we cannot or should not do this, so we must create a Proxy class from the source

34. Configuration Files Makes changing ports, channels, etc. much easier. Simplifies code. Should be named.exe.config.