Remoting Introduction

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

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

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

4. .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-serialization) • .NET Remoting is more flexible (more activation and deployment options) • .NET Remoting is customizable (you can add logging or other features)

5. .Net Remoting Benefits • .Net Remoting enables you to work with stateful objects • Interface description does not have to be manually coded in any way, as metadata can be extracted from running servers, or from any .Net assembly • One of the major benefits is that it’s centralized around well-known and well-defined standards like HTTP and is directly tied to the .Net Framework

6. .NET Remoting “Remote” vs. ”Local” • "Local" are all objects within the same AppDomain • All other objects are "Remote" • Even objects in the same process! • Context-bound objects: • "Local" if they share the same context • "Remote" if they are in different contexts • "Local": Not marshaled, immediate object calls • "Remote": Marshaled, calls through proxies

7. High-level Overview A replacement for DCOM (to a degree). An Ideal solution for use over internal networks.

8. .NET RemotingProxies Illustrated Channel Client Server "Proxy" IMessageSink Transparent Proxy Builds MethodA() MethodB() RealProxyType Invoke() PropertyQ PropertyP FieldX SyncProcessMessage() FieldY

9. .NET RemotingThe Dispatcher Illustrated Client Server Channel Dispatcher Actual method calls Object MethodA() Dispatcher(ChannelServices) MethodB() PropertyQ PropertyP FieldX SyncDispatchMessage() FieldY

10. .NET RemotingExposing Well-Known Objects • .NET's activation model is very unlike COM's • .NET rather resembles CORBA model (!) • If there is no actively listening endpoint: no connection • No surrogates, no registry, no location transparency • EXE servers are not remotely activated • Simplifies remoting greatly • Expose well known object for clients to connect. • Bound to known channels with known name. • Does not use static registration, prog-ids or class-id. • Can only expose "single call" or "singleton" objects

11. .Net Remoting Basics • Different Ways of defining interfaces: • Shared Assembly • Shared Interface or Base Objects • Generated Metadata Assembly (SoapSuds) • Serialization of Data: • Encoding/Decoding of Objects natively supported • Just need to mark such objects with [Serializable] attribute or implement the interface ISerializable • Lifetime Management • Open network connection between client-server • Combined reference counting and pinging mechanisms • Objects get lifetime when created (reset: time-to-live) • Sponsor registered with a server-side object • Multiserver/Multiclient • .Net automatically keeps track of remote object’s origin

12. .Net Remoting • Three types of objects: • Serializable classes---can be sent between processes, applications, and computers. • Remotable classes---inherits System.MarshalByRefObject---have innate ability to be invoked remotely (outside of their application domain) • Ordinary classes---local within an application---not of interest here

13. .Net Remoting Basics • Passed by Reference • These objects live on server • Only ObjRef (a proxy) will be passed around • The client usually may not have compiled objects in one of its assemblies, instead only a interface or Base class is available to client • Proxy Object takes care of all remoting tasks • Does NOT require serialization. • Does not require even sharing details of actual object.

14. .Net Remoting Basics • Passed by Value • Serialized into a string or binary representation and restored as a copy on other side of communication channel • Each one has its own copy and run independently • Client has to have the compiled object in one of its assemblies • Must support Serialization • [Serializable] class-level attribute or ISerializable interface

15. Remotable Classes • It can use stateful and stateless objects • Singleton • Stateful • Server-Activated (Well-known) • SingleCall • Stateless • Server-Activated (Well-known) • Client-Activated • Stateful • Client-Activated • Regular shared objects • Get access to an existing object.

16. MarshalByRefObjects • Categorized into 2 groups: • Server-activated objects (SAOs) • Client-activated objects (CAOs) • SAO: • Comparable to classic stateless Web Services • No message travels to server on reference request by a client • Only when methods are called on this remote reference will the server be notified • Can be either Singleton / SingleCall • How SAO (Singleton/SingleCall) works ? … code helps

17. Server-Activated Singleton Objects

18. Server-Activated SingleCall Objects

19. MarshalByRefObjects (CAO) • CAO: • An instance of specified class created when • A creation request on the client is encountered using new operator or Activator.CreateInstance() method • An activation message sent to the server • Are stateful objects • Will store state information from one method call to the other

20. MarshalByRefObjects (CAO) • Cannot use shared interface or assemblies • Have to ship the complied objects to the clients or use SoapSuds to extract metadata out of a running server or a server-side implementation assembly • SoapSuds suggested not be used anymore for .Net to .Net distributed applications • Instead we use a factory design pattern • In this a SAO provides methods to return new instances of the CAO

21. Client-Activated Objects

22. Factory Design Pattern using System; Namespace FactoryDesignPattern { class MyClass {} class MyFactory { public MyClass GetNewInstance() { return new MyClass(); } }

23. Factory Design Pattern class MyClient { static void Main(string[] args) { //creating using “new” MyClass obj1 = new MyClass(); //creating using a factory MyFactory fac = new MyFactory(); MyClass obj2 = fac.GetNewInstance(); } } }

24. Managing Life Time of an Object • Garbage Collection only runs per machine (actually per process or Application Domain). • Lease-based object lifetime • Each server-object is associated with a lease on creation • Lease has time-to-live counter, decremented in certain intervals • In addition, a defined amount of time is added on every method call a client places on remote object • Upon reaching zero time, framework looks for a sponsor registered with the lease.

25. Types of Invocation • Synchronous Calls • Client waits until server finishes processing the request • Asynchronous Calls • Delegates work • One-Way Calls • Framework does not guarantee their execution • Method cannot have return values or out parameters • No exception thrown even if server is down or the method call is malformed • Used in uncritical logging or tracing facilities

26. Isolated execution space for applications Independent of O/S concept of thread, process .NET RemotingApplication Domains Process Process AppDomain AppDomain AppDomain Object Object Object Object Object

27. Derived from COM+ context idea But:Remoting Context != COM+ Context Encloses objects with same functional context Carries shared properties that describe behavior Object Object Object .NET RemotingRemoting Context AppDomain Context Context Remoting boundary Object Object Object Object RqTx Sync Thrd

28. .NET RemotingRemoting Services • System.Runtime.Remoting.RemotingServices class • Provides fundamental remoting infrastructure • Remoting configuration • Connecting to remote object instances • Exposing "well known objects" • System.Runtime.Remoting.ChannelServices • Channel registration and management • System.Runtime.Remoting.LifetimeServices • Lease-based lifecycle management for objects • System.Runtime.Remoting.TrackingServices • Universal hooks for tracking remoting activities

29. Writing a well-known service .NET RemotingBuilding a Remote Application Example using System; namespace HelloService { // Well Known Service public class Hello : MarshalByRefObject { // Return the name prefixed with a string public String HelloMethod(String name) { Console.WriteLine("Hello.HelloMethod : {0} " +, name); return "Hi there " + name; } } }

30. Channels and Objects are AppDomain-Global .NET RemotingServer Setup Example ... HTTPChannel chan = new HTTPChannel(8085); ChannelServices.RegisterChannel(chan); RemotingServices.RegisterWellKnownType("MyAssembleName","MyNamespace.ServerClass", "MyEndpointURI", WellKnownObjectMode.SingleCall); Channel registration Object registration Registers the single-call endpoint:http://myserver:8085/MyEndpointURI

31. .NET RemotingActivation Illustrated tcp://server:8501/uriD TCP8501 HTTP8088 http://server:8088/uriB AppDomain RemotingServices.Connect() IdentityTable uriA uriB uriC uriD Activator.GetObject() Languagebinding Context o = Activator.GetObject("http://...")o.methodCall(); Object Object o = new myClass();o.methodCall(); Object Object