2.1.6 .NET Remoting
The following diagram shows the typical architecture of a distributed application that is built by using the .NET remoting framework.
Figure 10: Typical architecture of a distributed application that uses the .NET remoting framework
By using .NET remoting, objects executing within the logical subdivisions of application domains and contexts can interact with one another across .NET remoting boundaries.
With .NET remoting, client applications can be built that use objects in other processes on the same computer or on any other computer that is reachable over its network. The .NET remoting framework can also be used to communicate with other application domains in the same process. The .NET remoting framework provides an approach to interprocess communication that abstracts the remotable object from a specific client or server application domain and from a specific mechanism of communication.
To use .NET remoting to build an application in which two components communicate directly across an application domain boundary, the following components are required:
A remotable object, which is referred to as ServerObject in the typical architecture of a distributed application diagram.
A host application domain to listen for requests for that object (Application Domain 2 in the typical architecture of a distributed application diagram).
A client application domain that makes requests for that object (Application Domain 1 in the typical architecture of a distributed application diagram).
On the client side, the remoting infrastructure creates a proxy that stands in as a pseudo-instantiation of the remotable object and returns to the client object a reference to the proxy. It does not implement the functionality of the remotable object, but instead presents a similar interface. When a client calls a method, the remoting infrastructure handles the call, checks the type information, and sends the call over the channel to the server process. On the server side, the listening channel picks up the request and makes the call to the remotable object on behalf of the client. The results are serialized and transferred by way of the sink to the client, where the proxy reads them and hands them over to the calling application.
The .NET remoting infrastructure manages transferring the required information over the wire. The following diagram shows the protocol stack of the remoting infrastructure.
Figure 11: Protocol stack of the .NET remoting infrastructure
The .NET remoting core protocol ([MS-NRTP]) specifies a mechanism whereby a calling program can invoke a method in a different address space over the network.
The .NET Remote Lifetime Services Extension ([MS-NRLS]) extends the .NET Remoting: Core Protocol [MS-NRTP] to add a mechanism allowing clients to explicitly create Server Objects, and adds another mechanism allowing clients and servers to control the lifetime of Server Objects. The .NET Remote Lifetime Services Extension adds new methods and semantics for activation and lifetime management.
A .NET remoting application can use either a binary encoding for .NET remoting as specified in the .NET Remoting Binary Format ([MS-NRBF]), or SOAP encoding, as specified in [SOAP1.1], with the .NET remoting-specific portions of the mapping specified in SOAP Serialization Format ([MS-NRTP] section 2.2.4).
The .NET remoting framework can be bound to either TCP ([RFC793]) or HTTP ([RFC2616]). The TCP binding for binary encoding is specified in TCP Transport ([MS-NRTP] section 2.1.1), and the HTTP binding is specified in HTTP Transport ([MS-NRTP] section 2.1.2). The TCP binding to SOAP is specified in SOAP on TCP ([MS-NRTP] section 220.127.116.11), and the HTTP binding can be found in [SOAP1.1] section 6, with .NET remoting-specific portions of the mapping specified in SOAP on HTTP ([MS-NRTP] section 18.104.22.168).
Over a TCP connection, optional security can be provided by .NET NegotiateStream Protocol ([MS-NNS]). This protocol enables:
Client and/or server authentication
Data confidentiality and integrity
The .NET NegotiateStream Protocol provides mutually authenticated and confidential communication as specified in [MS-NNS].
A key benefit is that authentication in [MS-NNS] is accomplished without the use of digital certificates. Other protocols, such as Transport Layer Security (TLS, [RFC5246]), require the use of digital certificates.
Over an HTTP connection, NTLM Authentication ([MS-NLMP]) or HTTP authentication ([RFC2617]) can be used. The NTLM Over HTTP Protocol ([MS-NTHT]) specifies how NTLM authentication is used over an HTTP connection.
Interoperability Between CLR and COM
The IManagedObject interface is useful as part of the infrastructure for allowing the CLR to interoperate with COM.
The IRemoteDispatch interface is used for method-call dispatch and deactivation.
The IServicedComponentInfo interface is used for determining Server Object instance identity.
The following diagram shows the relationship among .NET remoting protocols.
Figure 12: .NET remoting protocol relationships