Remoting Overview
The common language runtime Remoting infrastructure provides a rich set
of classes that allow developers to ignore most of the complexities of
deploying and managing remote objects. Even though you are dealing with
applications running against different run-time environments, calling methods
on remote objects is nearly identical to calling local methods. The purpose of
this QuickStart is to provide a brief introduction to Remoting and to describe the principles involved so that you can build more sophisticated applications as needed. A basic understanding of remote objects, HTTP, TCP, and URLs would be helpful for
understanding these examples.
Remoting is a framework built into the common language runtime that can be
used to build sophisticated distributed applications and network services.
Although it has a number of features in common with similar .NET Framework on
other platforms, it offers a unique set of features not available anywhere
else:
- Proxy objects. When a client creates an instance of a remote object, it
receives a proxy to the class instance on the server. All methods called
on the proxy will automatically be forwarded to the remote class and any
results will be returned to the client. From the client's perspective,
this process is no different than making a local call. Any exceptions
thrown by the remote object will automatically be returned to the client.
This enables the client to use normal try and catch blocks around sections
of the code to trap and deal with exceptions.
- Object passing. All objects created remotely are
returned by reference and have to derive from MarshalByRefObject.
Objects passed as parameters to a remote method call can be forwarded by
value or by reference. The default behavior is pass by value provided the
object in question is marked by the custom attribute
[serializable]. Additionally, the object could implement the
ISerializable interface, which provides flexibility in how the object
should be serialized and deserialized. Objects that are not marshal by
reference or marshal by value are not remotable.
- Activation models. Remote objects can easily be created
from a client by calling new. The framework contains
enough "intelligence" to realize you are dealing with a remote object and
will ensure an instance of the object gets created in the relevant remote
application. Creating instances of remote objects is not limited to default
constructors; you can even do this using a constructor that
requires one or more parameters. The Activator class contains two methods,
CreateInstance and GetObject, that can also be used to create an instance of
remote objects. The former can be used in place of new to create an
object instance while the latter is normally used to connect to an object
at a specified URL.
- Stateless and Stateful objects. The framework makes a provision
for creating remote objects as stateless. When an object is configured as
SingleCall, it will be created when a method is called on that
object. The object processes the call, returns an optional result, and
is then collected by the garbage collector. This way the client is
always connected to a fresh object with each call. Configuring an object
as a Singleton ensures that all clients will be connected to the same
object whenever a call is made to that object. ClientActivated objects
allow the client to pass parameters to the constructor of a remote object
when it gets created. Each activation request for a client activated
object (Activator.CreateInstance or new in combination with entries in the
configuration file) on the client results in a new object on the
server.
- Channels and Serialization. When a client calls a method on a
remote object, the remoting framework automatically serializes any data
associated with the request and transports the data to the remote object
using a channel. Some of the more popular channels supported are HTTP, TCP, and
SMTP. In the case of HTTP, the framework uses the SOAP protocol
to transport data in XML format from the client to the server and back.
The default serialization formatter for HTTP is a SOAP formatter. Since programmers can create custom formatters for use
with any channel, the remoting framework can be configured to work with
any external .NET Framework on other platforms. The TCP channel uses plain
sockets and Binary Serialization by default and can be used to communicate
with any object on a remote server.
- Lease based Lifetime. The lifetime of remote objects is
controlled by a leasing mechanism. When an object is first created, it is
given a lease time. When the lease time of the object reaches zero, the
object will be disconnected from the Remoting infrastructure and when all
references to the object has been freed within the AppDomain, it will be
collected by the garbage collector. A number of mechanisms are provided that allow the
client to extend the lease on the object, thereby sustaining its life.
- Hosting objects in IIS. Remote objects can easily be hosted
in IIS. This allows any client to connect to the object using normal
HTTP on port 80. It is also possible to create Web pages that allow a
user to connect to a remote object using Internet Explorer.
The remainder of the QuickStart features practical examples of the above
concepts.
Microsoft .NET Framework SDK QuickStart Tutorials Version 2.0
Copyright � 2004 Microsoft Corporation. All rights reserved.
|