Overview of Microsoft .Net Remoting technology
3 likes3,402 views
The document provides an overview of Microsoft's .NET Remoting technology, detailing its architecture, concepts, object types, activation types, lifetime control, and channels. It explains the distinction between remotable and nonremotable types, different activation semantics, and how to manage the lifetime of remote objects. Additionally, it covers configuration options and the use of asynchronous remoting to enhance performance.
![© Peter R. Egli 2015
6/16
Rev. 1.40
Microsoft .Net Remoting indigoo.com
3. Remotable and nonremotable types (2/2)
2. Value objects:
Objects that are serializable can be transferred into a different application domain.
Serializable objects must be „tagged“ with the attribute [Serializable].
Additionally serializable objects may implement the ISerializable interface and
provide a custom serialization (e.g. add some logging info to the serialized object
stream).
ISerializable
MyRemotableClass
The attribute Serializable is attached
to MyRemoteClass marking it
serializable (all members of the
class need to be serializable as well).
Optionally MyRemotableClass may
implement the ISerializable interface
allowing custom serialization.
[Serializable]
Marshal by value:
Object A
.Net remoting
infrastructure
.Net remoting
infrastructure
Copy of
object A
(marshal by
value)
Application domain A
Application domain B
Object A is serialized to
a stream
The stream containing a
serialized copy of object A
is transferred
Object A is deserialized from
the stream to a copy of the
object A](https://image.slidesharecdn.com/dotnet-remoting-130808134041-phpapp02/85/Overview-of-Microsoft-Net-Remoting-technology-6-320.jpg)
Overview of Microsoft .Net Remoting technology
- 1. © Peter R. Egli 2015 1/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com Peter R. Egli INDIGOO.COM OVERVIEW OF MICROSOFTS .NET REMOTING TECHNOLOGY .NET REMOTING
- 2. © Peter R. Egli 2015 2/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com Contents 1. .Net Remoting architecture 2. .Net Remoting concepts 3. Remotable and nonremotable types 4. .Net Remoting Server Object Activation Types 5. .Net remoting object lifetime control 6. .Net remoting channel 7. Assembly with remoting objects 8. Configuration files instead of programmatic creation of objects 9. Asynchronous remoting
- 3. © Peter R. Egli 2015 3/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com 1. .Net Remoting architecture Proxy: Client-side stub object that connects to the (remote) server object. Channel: Transport channel for objects, defined by host + port + endpoint (= remote object service). Dispatcher: Part of the .Net remoting infrastructure; dispatches method call to the server object. Formatter and Transport sink see below. Client Proxy object Dispatcher Server (remote) object Client Server .Net remoting infrastructure Formatter sink Transport sink Formatter sink Transport sink Channel
- 4. © Peter R. Egli 2015 4/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com ChannelServices 2. .Net Remoting concepts Channel: Comprises a server port number and a formatting (=protocol such as HTTP or TCP) Endpoint: Specifies the application that receives the calls (requests) ChannelServices HTTP Client Channel EP http://<host>:<port>/<endpoint> ServerObjectServerObject EP HTTP Server Channel ICalcICalc.dll (common assembly) Contains TCP Server ChannelTCP Client Channel ServerObject Transparent Proxy Client ICalc .Net remoting infrastructure Channel type (formatting, protocol) Channel port number Endpoint (application) <<has>> ICalc.dll (common assembly) .Net remoting infrastructure Register Formatter FormatterFormatter Get object reference Create proxy object as object reference Contains Real Proxy Interface for client Send/receive messages
- 5. © Peter R. Egli 2015 5/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com 3. Remotable and nonremotable types (1/2) Nonremotable types: Objects that neither derive from MarshalByRefObject nor are serializable. Examples: File handles, sockets, window handles (in general objects that can be used only in the local context / application domain). Remotable types: 1. Reference type objects: Objects that derive from MarshalByRefObject are remotable. The remote objects are marshalled by reference. The client obtains a local reference object (proxy) to the remote server object. MarshalByRefObject MyRemotableClass Only a reference to Object B is transferred Application domain A Object A Application domain B .Net remoting infrastructure .Net remoting infrastructure Object B marshal by reference A remote object becomes remotable by reference simply by deriving from the .Net class MarshalByRefObject
- 6. © Peter R. Egli 2015 6/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com 3. Remotable and nonremotable types (2/2) 2. Value objects: Objects that are serializable can be transferred into a different application domain. Serializable objects must be „tagged“ with the attribute [Serializable]. Additionally serializable objects may implement the ISerializable interface and provide a custom serialization (e.g. add some logging info to the serialized object stream). ISerializable MyRemotableClass The attribute Serializable is attached to MyRemoteClass marking it serializable (all members of the class need to be serializable as well). Optionally MyRemotableClass may implement the ISerializable interface allowing custom serialization. [Serializable] Marshal by value: Object A .Net remoting infrastructure .Net remoting infrastructure Copy of object A (marshal by value) Application domain A Application domain B Object A is serialized to a stream The stream containing a serialized copy of object A is transferred Object A is deserialized from the stream to a copy of the object A
- 7. © Peter R. Egli 2015 7/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com 4. .Net Remoting Server Object Activation Types (1/3) Activation = creation and initialization of objects. Activation of marshal by value types (Serializable): Value type objects are activated through the de-serialization on the server side. Activation of MarshalByRefObject types: a. Client activated object (CAO): • Object is activated by the client, transferred to the server and the called method executed on the server side. • Server object may retain state information between successive calls (stateful session). • How it actually works: Client Server 1. Object creation 2. Transfer to server 3. Execution in the appl. domain and process of the server MySrv Proxy MySrv object Client Server Shared assembly with MySrv type Shared assembly with MySrv type Client creates the object locally. The underlying .Net remoting infrastructure actually creates a proxy, creates a server object on the server side and connects these 2 objects. .Net remoting infrastructure .Net remoting infrastructure
- 8. © Peter R. Egli 2015 8/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com 4. .Net Remoting Server Object Activation Types (2/3) b. SAO - Server Activated Object (1/2): • SAO call semantics is stateless (no session semantics between client and server object possible). Called „well-known“ types Published as an URI Server activates the objects and the client „connects“ to these. 2 types of server-activated objects Singleton objects: 1 global instance for all clients and for all remote object calls Created when the first client accesses the server object. Server registration as singleton: RemotingConfiguration.RegisterWellKnownServiceType( typeof( SomeType ), "SomeURI", WellKnownObjectMode.Singleton ); Singleton server object Client proxy object Client proxy object Client proxy object
- 9. © Peter R. Egli 2015 9/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com 4. .Net Remoting Server Object Activation Types (3/3) b. SAO - Server Activated Object (2/2): Single-call objects: Individual object for each client method call. Every method call is executed on a new server object instance, even if the call is made on the same client proxy object. Server registration as single-call object: RemotingConfiguration.RegisterWellKnownServiceType( typeof( SomeType ), "SomeURI", WellKnownObjectMode.SingleCall ); Single server object Client proxy object Single server object Client proxy object Single server object Client proxy object
- 10. © Peter R. Egli 2015 10/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com 5. .Net remoting object lifetime control SAO single-call objects: Server object lives for 1 call only SAO singleton and CAO objects: Lifetime managed by the Lease Manager The Lease Manager decides if a remote object (server object) can be marked for deletion (actual deletion is the job of the GC). The Lease Manager contacts a sponsor in order to determine if a remote object can be marked for deletion or if the lifetime of the object should be extended. • Flexible design where client and server object lifetime are de-coupled. • Lifetime of objects that are costly to create (lots of initialization etc.) can be given long lifetimes. • Objects that hold precious resources may be given short lifetimes (free resources quickly). Server process Server Object Lease Lease Manager App Domain Reference Client process Client Sponsor App Domain
- 11. © Peter R. Egli 2015 11/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com 6. .Net remoting channel .Net remoting channels are complex object-chains with at least 2 so called sinks (message processing objects): a. Formatter sink: Convert the message or object to be transported to the required wire protocol (binary or SOAP) b. Transport sink: Mapping of the serialized message stream into a transport connection (binary formatter: plain TCP, SOAP: HTTP) The programmer may add additional sink objects (e.g. logging or filtering sink object that logs each message passing by). Source: http://msdn.microsoft.com/en-us/library/tdzwhfy3(VS.71).aspx Formatting into wire protocol (binary or SOAP) Additional custom sinks Mapping of serialized stream into transport connection
- 12. © Peter R. Egli 2015 12/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com Assembly mscorlib.dll (.Net system assembly) 7. Assembly with remoting objects (1/2) Both client and server must have the same assembly (.Net library in the form of a DLL or executable) containing the shared interface. Both client and server must be linked with an identical assembly containing the shared interface; only sharing the shared interface on source level does not work (.Net remoting run-time throws an exception). 1. SAO scenario: The shared assembly may only contain the interface (only minimal assembly with the shared interface needs to be deployed). The server implementation (class CalcServer) is completely hidden to the client. Interface ICalc CalcServer remote object MarshalByRefObject Assembly ICalc.dll Client application Assembly CalcServer.exe Link to Assembly CalcClient.exe Link to Calc proxy Connects to
- 13. © Peter R. Egli 2015 13/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com Assembly mscorlib.dll (.Net system assembly) 7. Assembly with remoting objects (2/2) 2. CAO scenario: Remotable object that extends MarshalByRefObject must be in the shared assembly because it is created / activated by the client, but executed on the server; so both client and server need the CalcServer class / object. Interface ICalc CalcServer application MarshalByRefObject Assembly Calc.dll Client application Assembly CalcServer.exe Link to Assembly CalcClient.exe Link to CalcServer Transferred to for execution CalcServer Link to
- 14. © Peter R. Egli 2015 14/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com 8. Configuration files instead of programmatic creation of objects (1/2) .Net remoting allows using XML-files for configuring various settings on the server and client side, e.g. port numbers and formatters. Advantage: Meta-programming without the need to change the code. Disadvantage: If things don‘t work as expected debugging of configuration in XML-files is difficult (Visual Studio does not provide help for creating configuration files). Example server config file: <?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application> <service> <wellknown mode="SingleCall" type="ICalc.CalcServer, ICalc" objectURI="ICalc.CalcServer"/> </service> <channels> <channel ref="tcp" port="60000" bindTo="127.0.0.1"> <serverProviders> <formatter ref="binary" typeFilterLevel="Full"/> </serverProviders> </channel> </channels> </application> </system.runtime.remoting> </configuration>
- 15. © Peter R. Egli 2015 15/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com 8. Configuration files instead of programmatic creation of objects (2/2) Example client config file: <?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application> <client> <wellknown type="ICalc.CalcServer, ICalc“ url="tcp://127.0.0.1:60000/ICalc.CalcServer.soap"/> </client> </application> </system.runtime.remoting> </configuration>
- 16. © Peter R. Egli 2015 16/16 Rev. 1.40 Microsoft .Net Remoting indigoo.com Async delegate 9. Asynchronous remoting Problem: Server method execution may take considerable time during which the client is blocked (waits for the response). Solution: Use of standard asynchronous delegates of .Net Further decoupling of client and server. Similar to asynchronous message oriented interaction between client and server. Client Proxy object Remote object Client passes the proxy object to an async delegate for execution (delegate runs in its own thread) Upon completion the delegate calls a callback method in the client