NET Remoting Remoting Introduction The process of programs

. NET Remoting

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.

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

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

. 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

. 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.

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)

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 5 x)

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

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

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

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

Channel Classes • Tcp. Channel and Http. Channel implement the logic required for client and server sides • There are further, more specialised classes – Tcp. Server. Channel, Http. Server. Channel – Tcp. Client. Channel, Http. Client. Channel

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

Server Activated Objects Example // A sample single call Server Activated Object public class Hello : Marshal. By. Ref. Object { public String Greetings(String user) { String ret = String. Format("Hello {0} from {1}: {2}", user, App. Domain. Current. Domain. Friendly. Name, this. Get. Hash. Code()); Console. Write. Line(ret); return ret; } } • • You must inherit from Marshal. By. Ref. Object The return string is can be anything – you don’t have to use String. Format either

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

Exposing a Server Activated Objects example class My. Application { static void Main(string[] args) { // STEP 1 Channel. Services. Register. Channel( new System. Runtime. Remoting. Channels. Tcp. Server. Channel(9000)); // STEP 2 Remoting. Configuration. Register. Well. Known. Service. Type( typeof(Hello), "Greeting. Server", Well. Known. Object. Mode. Single. Call); } } // STEP 3 - keep alive Console. Write. Line("Press a key to quit"); Console. Read();

Remoting. Configuration 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 Register. Well. Known. Service. Type at step 2 • The Uniform Resource Locator (URI) is also supplied (“Greeting. Server”) • Now we have a server object published on a port which is referred to by its URI

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

Activator. Get. Object • 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

The Client Side public class Client { static void Main(string[] args) { // STEP 1 Channel. Services. Register. Channel( new System. Runtime. Remoting. Channels. Tcp. Client. Channel()); // STEP 2 Hello greets = (Hello)Activator. Get. Object(typeof(Hello), "tcp: //localhost: 8085/Greeting. Server"); } } String greeting = greets. Greetings("Trent"); Console. Write. Line(greeting); String greeting 2 = greets. Greetings("Janet"); Console. Write. Line(greeting 2); Console. Write. Line("End of Client");

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

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

Singleton Objects • A remote object is created and is used for repeated method calls • Configure this on the server using Remoting. Configuration. Register. Well. Know n. Service. Type

Server Code Options Single-Call (No stored state on Server) Remoting. Configuration. Register. Well. Known. Service. Type( typeof(Hello), "Greeting. Server", Well. Known. Object. Mode. Single. Call); Singleton (Ability to store state) Remoting. Configuration. Register. Well. Known. Service. Type( typeof(Hello), "Greeting. Server", Well. Known. Object. Mode. Singleton);

Singleton Result

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

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

Client-Activated Objects • Lifetime is controlled by the client • Does not use Get. Object as with a client for a Server Activated object • Instead we use Activator. Create. Instance • 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

Server For A Client Activated Object class Server. For. Client. Activated. Object { static void Main(string[] args) { Channel. Services. Register. Channel(new Tcp. Server. Channel(8085)); Remoting. Configuration. Register. Activated. Service. Type(typeof(Hello)); } } // keep alive Console. Write("Key to quit"); Console. Read();

Client for Client Activated Objects class Client. For. Client. Activated. Object { static void Main(string[] args) { Channel. Services. Register. Channel( new System. Runtime. Remoting. Channels. Tcp. Client. Channel()); Hello greets = (Hello)Activator. Create. Instance( typeof(Hello), null, // params new object[] { new Url. Attribute("tcp: //localhost: 8085")}); } } String greeting = greets. Greetings("Trent"); Console. Write. Line(greeting); String greeting 2 = greets. Greetings("Janet"); Console. Write. Line(greeting 2); Console. Write. Line("End of Client");

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

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

Configuration Files • Makes changing ports, channels, etc. much easier. • Simplifies code. • Should be named <assemblyname>. exe. config.