.NET Remoting: Difference between revisions

Revision as of 23:03, 24 July 2010

Latest revision as of 19:53, 20 November 2024

(33 intermediate revisions by 30 users not shown)

Line 1:

{{short description|Microsoft application programming interface}}

'''.NET Remoting''' is a [[Microsoft]] [[application programming interface]] (API) for [[Interinter-process communication|interprocess communication]] released in 2002 with the 1.0 version of [[.NET Framework]]. It is one in a series of Microsoft technologies that began in 1990 with the first version of [[Object Linking and Embedding]] (OLE) for 16-bit [[Microsoft Windows|Windows]]. Intermediate steps in the development of these technologies were [[Component Object Model]] (COM) released in 1993 and updated in 1995 as COM-95, [[Distributed Component Object Model]] (DCOM), released in 1997 (and renamed Active X[[ActiveX]]), and COM+ with its [[Microsoft Transaction Server]] (MTS), released in 2000.<ref>{{cite web | title=Component Object Model and Related Capabilities | author=Software Technology Roadmap | publisher=Carnegie-Mellon Software Engineering Institute | year=2001}}</ref> It is now superseded by [[Windows Communication Foundation]] (WCF), which is part of the [[.NET Framework 3.0]].

| title=Component Object Model and Related Capabilities

| url=http://www.sei.cmu.edu/str/descriptions/com_body.html

| archive-url=https://web.archive.org/web/20080515233825/http://www.sei.cmu.edu/str/descriptions/com_body.html

| archive-date=2008-05-15

| author=Software Technology Roadmap

| publisher=Carnegie-Mellon Software Engineering Institute

| year=2001}}</ref> It is now superseded by [[Windows Communication Foundation]] (WCF), which is part of the [[.NET Framework 3.0]].

Like its family members and similar technologies such as [[Common Object Request Broker Architecture]] (CORBA) and [[Java Remote Method Invocation|Java's remote method invocation]] (RMI), .NET Remoting is complex, yet its essence is straightforward. With the assistance of operating system and network agents, a client process sends a message to a server process and receives a reply.<ref>{{cite book |title=Microsoft .NET Remoting|url=https://archive.org/details/microsoftnetremo0000mcle|url-access=registration|author=Scott McLean, James |first1=Scott|last2=Naftel and |first2=James|last3=Kim |first3=Williams | titlepublisher=Microsoft .NET Remoting Press| year = 2002 | publisherisbn=Microsoft Press9780585476445 }}</ref><ref>{{cite book | author=Ingo Rammer and Mario Szpuszta | title=Advanced .NET Remoting | url=https://archive.org/details/advancednetremot00ramm_0|url-access=registration|author=Rammer|first1=Ingo|last2=Szpuszta|first2=Mario|publisher=Apress | year=2005|isbn=9781590594179 }}</ref>

==Overview==

.NET Remoting allows an application to make an [[Object-oriented programming|object]] (termed ''remotable object'') available across ''remoting boundaries'', which includes different [[application ___domain|appdomain]]s, [[process (computing)|processes]] or even different computers connected by a network.<ref name="overview"/> The .NET Remoting runtime hosts the listener for requests to the object in the [[application ___domain|appdomain]] of the server application. AtOn the client end, any requests to the remotable object are proxied by the .NET Remoting runtime over <code>Channel</code> objects, that encapsulate the actual transport mode, including [[Transmission Control Protocol|TCP]] streams, [[HTTP]] streams and [[named pipe]]s. As a result, by instantiating proper <code>Channel</code> objects, a .NET Remoting application can be made to support different communication protocols without recompiling the application. The runtime itself manages the act of [[serialization]] and [[Marshalling (computer science)|marshalling]] of objects across the client and server appdomains.<ref name="overview">{{cite web | url = http://msdn2.microsoft.com/en-us/library/kwdt6w2k(VS.71).aspx | title = .NET Remoting Overview | accessdateaccess-date = 2007-10-23}}</ref>

.NET Remoting makes a reference of a remotable object available to a client application, which then instantiates and uses a remotable object as if it were a local object.<ref name="overview"/> However, the actual code execution happens at the server-side. A remotable object is identified by ''Activation [[Uniform Resource Locator|URL]]s'' and are instantiated by a connection to the URL.<ref name="arch"/> A listener for the object is created by the remoting runtime when the server registers the channel that is used to connect to the remotable object. At the client side, the remoting infrastructure creates a <code>proxy</code> that stands-in as a pseudo-instantiation of the remotable object. It does not implement the functionality of the remotable object, but presents a similar interface. As such, the remoting infrastructure needs to know the public interface of the remotable object before-handbeforehand. Any method calls made against the object, including the identity of the method and any parameters passed, are [[Serial communication|serialized]] to a byte stream and transferred over a communication protocol-dependent <code>Channel</code> to a recipient proxy object at the server side ("[[Marshalling (computer science)|marshalled]]"), by writing to the Channel's transport sink.<ref name="arch"/> At the server side, the proxy reads the stream off the sink and makes the call to the remotable object on the behalf of the client. The results are serialized and transferred over the sink to the client, where the proxy reads the result and hands it over to the calling application.<ref name="arch"/> If the remotable object needs to make a callback to a client object for some services, the client application must mark it as remotable and have a remoting runtime host a listener for it.<ref name="arch"/> The server can connect to it over a different Channel, or over the already existent one if the underlying connection supports bidirectional communication.<ref name="arch"/> A channel can be composed of a number of different Channel objects, possibly with different heterogeneous transports. Thus, remoting can also work across systems separated by an interconnection of heterogeneous networks, including the internetInternet.<ref name="arch">{{cite web | url = http://msdn2.microsoft.com/en-us/library/2e7z38xb(VS.71).aspx | title = .NET Remoting Architecture | accessdateaccess-date = 2007-10-23}}</ref> [[Type safety]] is enforced by the [[Common Type System|CTS]] and the .NET Remoting runtime. Remote method calls are inherently synchronous; asynchronous calls can be implemented using threading libraries. Authentication and access control can be implemented for clients by either using custom Channels or by hosting the remotable objects in [[Internet Information Services|IIS]] and then using the IIS authentication system.<ref>{{cite web | url = http://msdn2.microsoft.com/en-us/library/aa720577(VS.71).aspx | title = Security | date = 12 October 2006 | publisher = [[MSDN]] | accessdateaccess-date = 2007-10-23}}</ref>

== References ==

{{Reflist}}

<references/>

==External links==

{{Wikibooks|.NET Development Foundation}}

*{{Official website|1=https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-1.1/kwdt6w2k(v=vs.71)}}

*[https://docs.microsoft.com/en-us/dotnet/framework/wcf/migrating-from-net-remoting-to-wcf Migrating from .NET Remoting to WCF]

{{DotNET.NET Framework}}

{{Microsoft APIs}}

[[Category:.NET frameworkFramework terminology|Remoting]]

[[Category:Microsoft application programming interfaces]]

[[Category:Windows communication and services]]

[[Category:Inter-processRemote communicationprocedure call]]

[[Category:Object request broker|Net]]

[[de:.NET Remoting]]

[[es:.NET Remoting]]

[[fr:.NET Remoting]]

[[ja:.NET Remoting]]

[[pt:.NET Remoting]]

[[ru:.NET Remoting]]

[[uk:.NET Remoting]]

[[zh:.NET Remoting]]