Creating and Consuming .NET
Remoting Objects
Download CD Content
Overview
About This Chapter
Distributed applications help to establish communication between objects running in different processes
located on the same computer or located on computers at different geographic locations. The .NET
Framework provides a set of classes and methods that allow you to establish a connection and
communicate between objects with ease.
With earlier programming infrastructures, creating a distributed application required an in-depth
knowledge of the transmission protocols used in the communication process. Using the .NET
Framework, you can establish communication between objects without having to know about the
protocols or about the encoding and decoding mechanisms involved in the development of a distributed
application. In this chapter, you will learn to create, configure, and secure .NET Remoting objects by
using the classes that the .NET Framework provides.
Before You Begin
To complete the lessons in this chapter, you
Must have knowledge of basic programming in Microsoft Visual Basic .NET and Microsoft
Visual C#
Must have a basic knowledge of distributed programming
Lesson 1: Understanding .NET Remoting
You can use .NET Remoting to enable communication between different applications regardless of
whether they reside on the same computer or on different computers. These computers can be part of the
same network or part of networks in different geographic locations across the world. In addition, these
computers can run different operating systems and still communicate with each other using .NET
Remoting.
After this lesson, you will be able to
Explain .NET Remoting
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
Identify various methods of accessing objects across remoting boundaries
Describe the .NET Remoting architecture
Identify remotable and nonremotable objects
Estimated lesson time: 35 minutes
can use a copy of the server object in the client application. The client can then call a method on the
local copy of the server object.
When you are copying objects to the client process, make sure that the objects do not contain a large
number of methods, and that the objects are not large in size. Extremely large objects with many
methods can be poor choices for copying or passing by value to other processes because the client
requires only the values returned by one or a few methods of the server object. Copying an entire server
object to the client process is a waste of client resources, which include bandwidth, memory, and
processing time. In addition, many server objects expose public functionality but require private data on
the server for internal execution.
Warning When you copy server objects, you might enable malicious clients to examine internal server
data, creatin
g the potential for security problems.
It is also inadvisable to copy objects, such as a FileInfo object, to the client process because a FileInfo
object contains a reference to an operating system file, which has a unique address in the memory of the
server process. You can copy this address along with the object, but the address is process-specific and
will not work in another process. In this situation, you pass the server object as a reference to the client
application. The client application uses this reference to call methods on the server object. The remoting
system handles the method call and sends it to the server object. After the method is executed, the result
is returned to the client application.
The .NET Remoting Architecture
To communicate between server objects and clients in .NET Remoting, you need to use object
references of the server object in the client application. When you create an instance of the remote object
new
using the keyword, your client receives a reference to the server object. After obtaining the object
reference, the client can call methods on the server object as if the object resides in the client’s process
and does not run on a separate computer.
.NET Remoting uses proxy objects to allow the use of the server object in the client process. When you
create an instance of the remote object type in the client application, .NET Remoting creates a proxy
object and sends it to the client application. This proxy object contains references to all the methods and
properties of the server object. When you call a method that is on that proxy object, the remoting system
receives the call, routes it to the server process, invokes the server object, and returns the return value to
shows how a client
the client proxy, which returns the result to the client application. Figure 4.1
communicates with a remote object.
gure 4.1: Communication between a client and a remote object
Fi
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
To improve performance and reduce processing time, move the complete state of the object and its
functionality to the target application domain. Using marshal-by- value objects reduces time- and
resource-consuming trips across network, process, and application domain boundaries. You also use
marshal-by-value objects directly from within the original application domain of the object. In this case,
access is efficient because marshaling does not take place.
Marshal-by-Reference Objects
Marshal-by-reference objects are remotable objects that extend the System.Marshal-ByRefObject class.
When a client creates an instance of a marshal-by-reference object in its own application domain,
the .NET Remoting infrastructure creates a proxy object in the caller application domain that represents
the marshal-by-reference object and returns a reference of that proxy to the caller. The client then makes
method calls to the proxy object. The remoting system marshals those calls, returns them to the server
application domain, and invokes the call on the actual object.
Note If the client is in the same application domain as the marshal-by-reference object, the infrastructure
returns a direct reference to the marshal-
by-reference object, avoiding the overhead of marshaling.
Before you create a distributed application, you should know the following:
You can call an object created in a specific domain directly from that domain.
If you need to call an object from a process outside its own application domain, you should
publish
publish the object. When you an object, you either copy the object to another application
domain or create a proxy of the object in another application domain.
If the size of the object is large or if it contains a large number of methods, the object can not be
efficiently published or consumed across domain boundaries. Therefore, you must decide which
type of object you want to publish based on the requirement of your application.
In this lesson, you learned about the basics of .NET Remoting, passing objects between processes, and
the .NET Remoting architecture. In addition, you learned about remotable and nonremotable objects.
You also learned about the marshal-by- value and marshal-by-reference objects.
In the next lesson, you will learn to create and activate objects. In addition, you will learn about the
lifetimes of objects. You will also learn to control objects.
Lesson 2: Implementing Server-Activated and Client-Activated
Objects
In the previous lesson, you learned about .NET Remoting and its architecture. As mentioned earlier,
in .NET Remoting, there are server and client processes. To communicate with the server process, you
use references of the server objects in the client application. In this lesson, you will learn how to create
the server and client objects. You will also learn how to activate these objects and control the lease of
these objects.
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
After this lesson, you will be able to
Identify server- and client-activated objects
Perform various modes of activation
Control the lifetime leases of objects
Estimated lesson time: 40 minutes
Understanding Remote Object Activation
When you develop an object, you need not track the creation of the object. You only need to ensure that
the object responds to the method calls. However, when you develop a remote object, you need to track
the creation and initialization of the object because the way a remote object behaves depends on how the
object is created and activated. You have to be aware of how remote objects are activated. You need to
specify to the remoting system what type of activation is required on the objects before the remoting
system provides these objects to the clients.
In the next two sections, you will learn about the two types of activation modes in the .NET Remoting
system: server activation and client activation.
Server Activation
In server activation, objects are created on the server when you call a method in the server class.
new
However, objects are not created when you use the keyword to create an instance of the server
class.
Consider the following example: The Social Security office has a service component that enables
organizations, such as banks and apartment offices, to check the validity of a particular social security
number (SSN). Clients connect to this service and provide the SSN of a person for validation. The
service validates the number and returns the appropriate personal information. In this scenario, clients
are always connected to the server at the Social Security office. The service is activated only when a
method call arrives from the clients asking for the validation of an SSN. This is known as server
activation. The following code displays server activation of objects.
Visual Basic .NET
Imports System.Runtime.Remoting
Public Class SSNServer
Inherits MarshalByRefObject
Public Function ValidateSSN(Byval number as Long) As String
' Return the address
Dim address As String
' Do some work here to validate the SSN
Return address
End Function
End Class
Visual C#
using System;
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
using System.Runtime.Remoting;
namespace SSNComponentCSharp
{
public class SSNServer : MarshalByRefObject
{
public SSNServer()
{
}
public String ValidateSSN(long number)
{
//Return the address
String address;
//Do some work here to validate the SSN
return address;
}
}
}
The preceding code displays a sample server object that takes a value of the long type value as a
parameter and returns the corresponding address. The following code illustrates how to call the
ValidateSSN method. Because this is in server-activation mode, the object is created only when you call
the ValidateSSN method, not when you create an instance of the class.
Visual Basic .NET
Dim serverInstance as New SSNServer()
' Remote Object on the server is created in the next line
Console.WriteLine(serverInstance.ValidateSSN(242990307))
Visual C#
SSNServer serverInstance = new SSNServer();
//Remote Object on the server is created in the next line
Console.WriteLine(serverInstance.ValidateSSN(242990307));
You can create a server-activated object as a Singleton or SingleCall object based on the requirements of
your remote application. Singleton objects can have only one instance regardless of the number of
clients they have. These objects also have a default lifetime. Therefore, if you create a server object as a
Singleton object, a single instance of the server object manages all the clients. When you declare an
object as a SingleCall object, the remoting system creates an object each time a client method invokes a
remote object. To register a server object as a Singleton object, you specify the type of the object as
WellKnownObjectMode.Singleton. The following code shows how to specify an object as
WellKnownObjectMode.Singleton.
Visual Basic .NET
Imports System.Runtime.Remoting
Public Class SSNServer
Inherits MarshalByRefObject
Sub New()
RemotingConfiguration.ApplicationName = "testService"
RemotingConfiguration.RegisterWellKnownServiceType( _
GetType(testService), "MyUri", _
)
WellKnownObjectMode.Singleton
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
Console.WriteLine("Press Enter to Stop")
Console.ReadLine()
End Sub
End Class
Class testService
'Service Component
End Class
Visual C#
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;
namespace SSNComponentCSharp
{
public class SSNServer
{
public SSNServer()
{
RemotingConfiguration.ApplicationName = "testService";
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(testService),
"MyUri",WellKnownObjectMode.Singleton);
Console.WriteLine("Press enter to stop.");
Console.ReadLine();
}
}
}
class testService : MarshalByRefObject
{
//Service Object Registered in the SSNServer class above.
}
Note You need to add a reference to System.Runtime.Remoting to use the classes in the
System.Runtime.Remoting.Channels.Tcp namespace.
To register a server object as a SingleCall object, you specify the type of the object as
WellKnownObjectMode.SingleCall. The following code shows how to specify the type of an object as
WellKnownObjectMode.SingleCall.
Visual Basic .NET
Imports System.Runtime.Remoting
Public Class SSNServer
Inherits MarshalByRefObject
Sub New()
RemotingConfiguration.ApplicationName = "testService"
RemotingConfiguration.RegisterWellKnownServiceType( _
GetType(testService), "MyUri", _
WellKnownObjectMode.SingleCall)
Console.WriteLine("Press Enter to Stop")
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
Console.ReadLine()
End Sub
End Class
Class testService
'Service Component
End Class
Visual C#
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;
namespace SSNComponentCSharp
{
public class SSNServer
{
public SSNServer()
{
RemotingConfiguration.ApplicationName = "testService";
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(testService),
"MyUri",WellKnownObjectMode.SingleCall);
Console.WriteLine("Press enter to stop.");
Console.ReadLine();
}
}
}
class testService : MarshalByRefObject
{
//Service Object Registered in the SSNServer class above.
}
Client Activation
new
Client-activated objects are created on the server when you create an instance using the keyword.
For example, you can create a chat application that allows users to communicate with other users over
an intranet. When a user logs on, a new instance of the chat server object is created. The default
constructor of the chat server object contains the code to locate users who are currently online and
displays it to the user who logs in. In this case, the remote object on the server will be created when you
new
create the instance using the keyword.
The client application domain defines the lifetimes of client-activated objects. These objects are present
in the client application domain. In client activation, when the client tries to create an instance of the
server object, a connection is made to the server, and the client proxy is created. The proxy object is
created using an object reference, which is obtained after the remote object is created on the server.
When a client creates a client-activated instance, the instance of the remote object serves a particular
lease
client until its lease expires and the garbage collector recycles its memory. The controls the time a
remote object remains in memory. If a client creates two new instances of a remote object, each
reference to the remote ob
ject invokes only the particular instance in the server application.
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
In COM, clients hold an object in memory by maintaining a reference to it. When the last COM client
releases its last reference to an object, the object deletes itself. Client activation enables you to control
the lifetime of the server object without maintaining references or constantly pinging to confirm the
continued existence of the server or the client.
Client-activated objects use lifetime leases to determine the duration of their existence. When a client
creates an object, it specifies a default duration for which the object should exist. If the remote object
reaches the end of its default lifetime duration, the object contacts the client and asks whether it should
continue to exist and for how long. If the client is not currently available, a default time limit is specified
for which the server object waits while trying to contact the client before marking itself available for
garbage collection. The client might even request an indefinite default lifetime, preventing the remote
object from being recycled until the server application domain is torn down.
Note The difference between a client-activated indefinite lifetime and a server- activated indefinite
lifetime is that an indefinite server-activated object serves all client requests for that type, whereas
the client-activated instances serve only the client and the references that are responsible for their
creation.
Remoting Tasks
After learning about server- and client-activated objects, you can now turn your attention to the basic
remoting tasks that are essential for establishing communication between a client and a remote object.
You perform the following remoting tasks to publish any service outside the service domain:
Identify the application domain that will host the service
Identify the activation mode: server activation or client activation
Identify and create a channel and a port
Identify how the client application obtains the metadata information about the service
The host application domain can be a Windows Services, console application, Windows Forms
application, or an XML Web service that use ASP.NET. After choosing an application domain for your
service, you identify the activation mode for the service.
Once you have specified the activation mode and other relevant information such as the application
name and the endpoints for the remoting system, you then configure your system using the configuration
file. To configure a remote system, call the Configure method of the RemotingConfiguration class. The
following code shows how to call the Configure method of the RemotingConfiguration class.
Visual Basic .NET
RemotingConfiguration.Configure(“configuration.config”)
Visual C#
RemotingConfiguration.Configure(“configuration.config”);
In the preceding code snippet, the Configuration.config file contains information on configuring the
remotin
g system. You can also configure the remoting system programmatically. When you configure
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
the remoting system programmatically, you do not require the configuration file.
Next, create the appropriate channel, TcpChannel or HttpChannel, and register it using the
RegisterChannel method of the RemotingConfiguration class. If you use the configuration file to
configure the remoting system, you can create the appropriate channel by simply loading the
configuration file using the RemotingConfiguration.Configure method.
Finally, publish the service so that it is accessible from outside the domain. This enables the server
application to function.
Using Lifetime Leases
The lifetime of a marshal-by-reference object is the duration for which the object resides in memory. A
marshal-by-reference object stays in memory forever regardless of the type of the object. In other words,
all marshal-by-reference server- activated and client-activated objects have a lifetime of their own.
These objects are released from memory after the lifetime expires and the object is marked for garbage
collection. The GC then removes the objects from memory.
The .NET Remoting system deletes an object only when it is marked as ready for garbage collection.
The lifetime lease manager of the server application domain is responsible for determining the objects
that are ready for garbage collection. However, a sponsor object can request a new lease for a particular
object by registering itself with the lease manager.
Whenever a marshal-by-reference object is remoted outside an application domain, a lifetime lease is
lease manager
created for that object. Each application domain contains a that administers the leases in
its domain. The lease manager periodically reviews the leases for expiration. If a lease expires, the lease
manager goes through its list of sponsors for that object and asks if any of them want to renew the lease.
If none of the sponsors renew the lease, the lease manager removes the lease. The object is then deleted,
and garbage collection reclaims the object memory. The lifetime of an object can therefore be much
longer than its lifetime lease.
Initializing Lifetime Leases
To initialize a lifetime lease, you override the InitializeLifetimeService function of the
MarshalByRefObject class. The following is the syntax used to override the InitializeLifetimeService
function.
Visual Basic .NET
Imports System.Runtime.Remoting.Lifetime
Public Class MyLifetimeControlObject
Inherits MarshalByRefObject
Public Overrides Function InitializeLifetimeService() As [Object]
Dim lease As ILease = CType(MyBase.InitializeLifetimeService(), _
ILease)
If lease.CurrentState = LeaseState.Initial Then
lease.InitialLeaseTime = TimeSpan.FromMinutes(2)
lease.SponsorshipTimeout = TimeSpan.FromMinutes(3)
lease.RenewOnCallTime = TimeSpan.FromSeconds(3)
End If
Return lease
End Function
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
End Class
Visual C#
using System;
using System.Runtime;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Lifetime;
public class MyLifetimeControlObject: MarshalByRefObject
{
public override object InitializeLifetimeService()
{
ILease lease = (ILease)base.InitializeLifetimeService();
if (lease.CurrentState == LeaseState.Initial)
{
lease.InitialLeaseTime = TimeSpan.FromMinutes(2);
lease.SponsorshipTimeout = TimeSpan.FromMinutes(3);
lease.RenewOnCallTime = TimeSpan.FromSeconds(3);
}
return lease;
}
}
Renewing Lifetime Leases
After you create a lifetime lease for an object, you can only change the CurrentLeaseTime property of
the lease object. The CurrentLeaseTime property returns the amount of time remaining on the lease.
These are the two ways to renew a lease:
A client application calls the ILease.Renew method.
A sponsor renews the lease.
The following code shows how to renew a lease using a client application.
Visual Basic .NET
Dim obj As New RemoteType()
Dim lease As ILease = CType(RemotingServices.GetLifetimeService(obj), _
ILease)
Dim expireTime As TimeSpan = lease.Renew(TimeSpan.FromSeconds(30))
Visual C#
RemoteType obj = new RemoteType();
ILease lease = (ILease)RemotingServices.GetLifetimeService(obj);
TimeSpan expireTime = lease.Renew(TimeSpan.FromSeconds(30));
When you publish remote objects, you should know the members of the remote objects that are
published. Clients can only access those members that the remote object publishes.
Scope of Publication
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
The .NET Remoting system exposes the functionality of server objects to client applications assuming
that the objects are contained locally in the client application. However, there are some exceptions to the
objects that are exported remotely. Table 4.1 provides details about various objects and how the .NET
Remoting system manages these objects.
Table 4.1: Scope of Publication
Objects Description
Static members You cannot export static members, such as fields and methods, remotely.
.NET Remoting needs instance members to enable communication between
the client and server objects.
Instance fields and The .NET Remoting system checks whether the object that you use is
accessors exported as a proxy object. If it is a proxy object, the client can directly
access instance fields through the proxy. If the exported object is not a
proxy, the proxy object provides instance accessors to the client.
Private members You cannot export private members of a remote object.
Delegates Delegates are marshal-by-value objects. The object in delegates can be a
remotable object, such as a serializable object, a MarshalByRef object, or a
ContextBound object.
Overriding methods on an To enhance performance, the virtual methods on an object always execute
object locally in the application domain in which they are called.
In addition to the objects listed in Table 4.1, calls to Equals() and ToString() methods are executed in
the remote object provided that these methods are overridden in the remote object. However, calls to
GetHashCode() and MemberwiseClone() methods are executed locally.
In this lesson, you learned about server- and client-activated objects. You also learned to create
Singleton and SingleCall objects, and to establish a connection between server and client applications.
In addition, you identified the objects that cannot be exported as remote objects. You also learned about
lifetime leases and how to initialize and renew the lifetime leases of objects. Finally, you learned about
the scope of publication.
Lesson 3: Transporting Messages Across Application Domains
Using Channels
Channels are the objects that remote objects use to communicate with each other. In this lesson, you will
learn about the role of channels in transporting messages between remote objects. You will also learn
how to use and configure channels.
After this lesson, you will be able to
Describe channels and their role in transporting messages between remote objects
Describe different types of channels
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
Define the format in which messages are transported over a channel
Estimated lesson time: 60 minutes
Understanding Channels
Channels
enable an application that is running in one application domain, process, or computer to send
messages to an application running in a different application domain, process, or computer. In addition,
channels allow applications to send and receive messages using various protocols, such as TCP and
HTTP.
Channels work as message carriers between remoting boundaries, such as contexts, application domains,
processes, and computers. A channel listens for messages at one remoting boundary and sends messages
to another remoting boundary. The remoting boundaries at the end of channels constitute the channel
endpoints. Before one remote object sends a message to another remote object, a channel converts the
message into an appropriate format such as the XML or binary format. Before sending the message, the
channel performs the necessary conversions.
Channel Interfaces
The .NET Framework provides the System.Runtime.Remoting.Channels name- space, which includes
the interfaces and classes that you use to work with channels. All channels implement the IChannel
interface. The IChannel interface provides properties such as ChannelName and ChannelPriority, which
uniquely identify a channel and define the channel priority, respectively.
Depending on whether you use a channel to receive or send messages, channels are categorized as
receiver or server and sender or client channels. A receiver or server channel implements the
IChannelReceiver interface, and a sender or client channel implements the IChannelSender interface.
The IChannelReceiver interface specifies methods, such as StartListening and StopListening, that must
be implemented by a receiver channel class. The IChannelSender interface specifies a method,
CreateMessageSink, which must be implemented by a sender or client channel class. The
CreateMessageSink method creates and returns a message sink that the channel object uses to deliver
messages to a remote object located at a specific URL. You will learn about sinks later in this lesson.
The HttpServerChannel and TcpServerChannel classes implement the IChannelReceiver interface,
whereas the HttpClientChannel and TcpClientChannel classes implement the IChannelSender interface.
A channel can also implement the IChannelSender and IChannelReceiver interfaces, which enable the
channel to send as well as receive messages. The HttpChannel and TcpChannel classes implement the
IChannelSender and IChannelReceiver interfaces, which enable objects of these classes to send and
shows various interfaces and their members that are implemented by the
receive messages. Table 4.2
channel classes.
Table 4.2: Channel Interfaces
Channel Description
Public properties of IChannel interface
ChannelName This property gets the name of the channel.
ChannelPriority This property gets the priority of the channel. A higher number indicates a
higher priority. The client channel with a higher priority gets the first
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
chance to connect to a remote object. On the other hand, the priority in the
case of server channels indicates the order in which the clients will use
channels while connecting to the server objects.
Public methods of IChannel interface
Parse This method returns the Uniform Resource Identifier (URI) of the current
channel and the object URI as an out parameter.
Public properties of IChannelReceiver interface
ChannelData This property gets the channel-specific data, which includes information
about the object being remoted.
Public methods of IChannelReceiver interface
StartListening This method instructs a channel to start listening for client requests.
StopListening This method instructs a channel to stop listening for client requests.
GetUrlsForUri This method returns an array of all the URLs for a URI.
Public methods of IChannelSender interface
CreateMessageSink This method returns a message sink object that delivers messages to a
specific URL or a channel data object.
Registering a Channel
Before one remote object sends messages to another remote object, you need to register a client channel
with the remoting system. Similarly, to enable a remote component to receive messages, you need to
register a server channel with the remoting infrastructure. To register channels with the remoting
infrastructure, you use the ChannelServices class. The ChannelServices class provides static methods
that enable you to register channels, resolve URLs, and discover remote objects using the object URLs.
The RegisterChannel static method of the ChannelServices class allows you to register a channel with
the remoting infrastructure. The following code shows how to register a TcpServerChannel method to
listen at port 8010.
Visual Basic .NET
Dim channel as New TcpServerChannel(8010)
ChannelServices.RegisterChannel(channel)
Visual C#
TcpServerChannel channel = new TcpServerChannel(8010);
ChannelServices.RegisterChannel(channel);
After you register a channel on the client and server computers, the remote objects can call methods on
explains how remote objects use channels to communicate across remoting
each other. The next section
boundaries.
Selecting Channels for Remoting
When a client object calls a method on a remote object, channels carry the parameters and other call-
related information to the remote object. A client can use any of the channels registered on the client
com
puter to call a method on the remote object. In addition, you can customize an existing channel or
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
create a channel that uses a different transport protocol. You should apply the following rules when
selecting channels for remote objects:
A client cannot call a method on a remote object unless you register at least one client channel,
such as TcpClientChannel or HttpClientChannel, with the remoting system on the client
computer. In addition, you should register a server channel, such as TcpServerChannel or
HttpServerChannel, before registering a remote object.
You must register a server channel on the client computer if a remote object calls back a method
on the client.
Channel names within an application domain cannot be the same. However, an application
domain can contain multiple channels of the same type. For example, an application domain can
have more than one TcpChannel object registered with the remoting system. The ChannelName
property of these channels should uniquely identify these channels.
Two channels registered with the remoting system on a computer cannot listen on the same port.
When a client calls a remote object, the remoting infrastructure creates a message that contains
parameters and other call-related information. The process by which the parameters and call-related
marshaling
. The remoting infrastructure sends the
information are bundled into a message is known as
message to a RealProxy object. The RealProxy object, in turn, forwards the message to a message sink.
message sink
A is an object that allows a client to establish a connection with the channel registered by
the remote object and forwards the messages to the channel. When the channel in the application domain
of the remote object receives the message, the remoting system on the server unmarshals the message
and forwards the call along with parameters and other call-related information to an appropriate remote
object.
Note When the remoting system creates a RealProxy object, the remoting system also creates a message
sink object by calling the IChannelSender.CreateMessageSink method on the selected channel.
During the communication between a client and the remote object, the message payload that contains the
marshaled parameters and call-related information is transported.
The channel that carries the message payload can use various transport protocols, such as HTTP and
TCP. Depending on the transport protocols used, channels are divided into two namespaces:
System.Runtime.Remoting.Channels.Http and System.Runtime.Remoting.Channels.Tcp.
HTTP Channels
The System.Runtime.Remoting.Channels.Http namespace provides channel classes that use the HTTP
protocol to transport messages between remote objects. The System.Runtime.Remoting.Channels.Http
namespace provides classes, such as HttpClientChannel, HttpServerChannel, and HttpChannel. You can
use the HttpClientChannel class to transport messages from a client to a remote object. To create an
HttpClientChannel object and register it with the remoting system, use the following code.
Visual Basic .NET
ChannelServices.RegisterChannel(New HttpClientChannel())
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
Visual C#
ChannelServices.RegisterChannel(new HttpClientChannel());
Note The constructor for the HttpClientChannel object does not require you to pass the port number
because the remoting system automatically allocates an available port to the channel.
The HttpServerChannel allows a remote object to listen to the remote calls from clients. You must
register the HttpServerChannel object at a specific port. The following code shows how to create and
register an HttpServerChannel object to listen at port 8080.
Visual Basic .NET
Dim channel as New HttpServerChannel(8080)
ChannelServices.RegisterChannel(channel)
Visual C#
HttpServerChannel channel=new HttpServerChannel(8080);
ChannelServices.RegisterChannel(channel);
Note You pass the port number as an argument to the HttpServerChannel constructor that determines the
port at which the server channel listens for the remote calls. Specifying a port that is already in use
causes an exception to be thrown. Therefore, if you are not sure which port number to specify, pass
0 as an argument to the constructor. The remoting system allocates an available port to the server
channel.
You can use the HttpChannel class to transport messages to and from remote objects. The following
code shows how to create and register an HttpChannel object to listen at port 8010.
Visual Basic .NET
Dim channel as New HttpChannel(8010)
ChannelServices.RegisterChannel(channel)
Visual C#
HttpChannel channel = new HttpChannel(8010);
ChannelServices.RegisterChannel(channel);
Table 4.3 shows the constructor methods of various HTTP channel classes.
Note The constructor methods in Visual Basic.NET are identified with the New name, whereas in Visual
C# the constructors have the same name as that of the class.
Table 4.3: Constructors of HTTP Channel Classes
Constructor Description
HttpChannel class
New() or HttpChannel() The default constructor initializes all the fields. The
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
HttpChannel class functions as a client channel when you
use the default constructor to create it.
port port
New( ) or HttpChannel( ) This constructor allows the HttpChannel object to function
Port
as a client channel as well as a server channel.
specifies the port at which the HttpChannel object listens
to remote calls.
properties
Properties
New( ,
is an IDictionary object that contains a
clientchannelsinkprovider
,
collection of channel properties in key-value pairs.
serverchannelsinkprovider
Clientchannelsinkprovider
) or
is an IClientChannel-
properties
HttpChannel( ,
SinkProvider object that creates the client channel sinks
clientchannelsinkprovider
Serverchannelsink-
,
through which messages flow.
serverchannelsinkprovider
provider
)
is an IServerChannelSinkProvider object that
creates server channel sinks through which the messages
flow.
(Channel sinks are described in Lesson 3.)
HttpClientChannel class
New() or HttpClientChannel() This constructor initializes a new instance of the
HttpClientChannel class with default values.
properties
New( , This constructor initializes the HttpClientChannel class
clientchannelsinkprovider
) or and sets the properties according to the key-value pairs in
properties properties Clientchannelsinkprovider
HttpClientChannel( , the object. is the
clientchannelsinkprovider
) IClientChannelSinkProvider object that the
HttpClientChannel object uses to create a client channel
sink. The messages sent by the client channel pass through
a chain of client channel sinks.
name,
New( This constructor initializes the HttpClientChannel object
clientchannelsinkprovider name
) or and sets its ChannelName property to .
name, Clientchannelsinkprovider
HttpClientChannel( is the IClientChannel-
clientchannelsinkprovider
) SinkProvider object that the HttpClientChannel object uses
to create a client channel sink. The messages sent by the
client channel pass through a chain of client channel sinks.
HttpServerChannel class
New() or HttpServerChannel() This constructor initializes the HttpServerChannel object
with the default values.
port
New( ) or HttpServerChannel This constructor initializes the HttpServerChannel object
port port
( ) to listen at the specified .
name port
New( , ) or This constructor initializes the HttpServerChannel object
name port name
HttpServerChannel( , ) with the ChannelName property set to and sets the
port
at which the channel listens for the remote method
calls.
properties
New( , This constructor initializes the HttpServerChannel object
serverchannelsinkprovider
) or and sets the properties according to the key-value pairs in
properties properties Serverchannelsinkprovider
HttpServerChannel( , the object. is the
serverchannelsinkprovider
IServerChannelSinkProvider object that the
)
HttpServerChannel object uses to create a server channel
sink. The messages received by the server channel pass
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
through a chain of server channel sinks.
You use HTTP channels when interoperability between remote components is the main objective. HTTP
channels use the SoapFormatter class to serialize messages into the XML format using the SOAP
protocol before sending the message payload across the channel. The interoperability of SOAP messages
allows a client to call methods on a remote object that might not be using the .NET Framework.
However, if performance is the main objective, use channels that allow you to transport messages in the
binary format. The System.Runtime.Remoting.Channels.Tcp namespace provides channel classes that
enable you to transport messages to and from remote objects. The next section
discusses the classes
provided by the System.Runtime.Remoting.Channels.Tcp namespace.
Serialization
Note is a process by which the state of an object is stored on a disk or transported across a
Deserialization
wire. involves recreating an object by reading the persisted state information of the
ob
ject from a disk or across a wire.
TCP Channels
TCP channels allow you to transport messages across application domains using the TCP protocol. The
TCP channels use the BinaryFormatter class to serialize messages into a binary stream before a client
sends them to a remote object. In addition, the BinaryFormatter class deserializes the binary payload
before delivering it to the remote object. The TCP channel classes that you can use include
TcpClientChannel, TcpServerChannel, and TcpChannel. The TcpClientChannel class allows a client to
send messages to a remote object, whereas the TcpServerChannel class allows a remote object to receive
messages from clients. The TcpChannel class allows you to transport messages to and from a remote
object. You register a TCP channel the same way in which you register an HTTP channel. The following
code shows how to register TCP channels.
Visual Basic .NET
ChannelServices.RegisterChannel(New TcpClientChannel())
Dim channel as New TcpServerChannel(8070)
ChannelServices.RegisterChannel(channel)
Dim tcpchannel as New TcpChannel(8010)
ChannelServices.RegisterChannel(tcpchannel)
Visual C#
ChannelServices.RegisterChannel(new TcpClientChannel());
TcpServerChannel channel=new TcpServerChannel(8070);
ChannelServices.RegisterChannel(channel);
TcpChannel tcpchannel = new TcpChannel(8010);
ChannelServices.RegisterChannel(tcpchannel);
Table 4.4 shows the constructor methods of various TCP channel classes.
Table 4.4: Constructors of TCP Channel Classes
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
Constructor Description
TcpChannel class
New() or TcpChannel() The default constructor initializes all the fields. When you use
the default constructor, the TcpChannel class functions as the
client channel.
port port
New( ) or TcpChannel( ) This constructor allows the TcpChannel object to function as a
port
client channel as well as a server channel. The number
specifies the port at which the TcpChannel object listens to
remote calls.
properties Properties
New( , are IDictionary objects that contains a collection of
clientchannelsinkprovider
, channel properties in key-value pairs.
serverchannelsinkprovider Clientchannelsinkprovider
) or is an IClientChannelSink- Provider
properties
TcpChannel( , object that creates the client channel sinks through which
clientchannelsinkprovider Serverchannelsink- provider
messages flow. is an
,
serverchannelsinkprovider
) IServerChannelSinkProvider object that creates server channel
sinks through which messages flow.
TcpClientChannel class
New() or TcpClientChannel() This constructor initializes the TcpClientChannel object with
default values.
properties
New( , This constructor initializes the TcpClientChannel object and
clientchannelsinkprovider
) or sets the properties according to the key-value pairs in the
properties
properties Clientchannelsinkprovider
TcpClientChannel( ,
object. is the
clientchannelsinkprovider
)
IClientChannelSinkProvider object that the TcpClientChannel
object uses to create a client channel sink. The messages sent
by the client channel pass a chain of client channel sinks.
name
New( , This constructor initializes the TcpClientChannel object and
clientchannelsinkprovider name
) or sets its ChannelName property to .
name Clientchannelsinkprovider
TcpClientChannel( , is the IClientChannelSink- Provider
clientchannelsinkprovider
) object that the TcpClientChannel object uses to create a client
channel sink. The messages sent by the client channel pass
through a chain of client channel sinks.
TcpServerChannel class
port port
New( ) or TcpServerChannel( ) This constructor initializes the TcpServerChannel object to
listen to a specified port.
name port
New( , ) or This constructor initializes the TcpServerChannel object with
name port name
TcpServerChannel( , ) the ChannelName property set to and sets the port at
which the channel listens for remote method calls.
properties
New( , This constructor initializes the TcpServerChannel object and
serverchannelsinkprovider
) or sets the properties according to the key-value pairs in the
properties properties Serverchannelsinkprovider
TcpServerChannel( , object. is the
serverchannelsinkprovider
)
IServerChannelSinkProvider object that the TcpServerChannel
object uses to create a server channel sink. The messages that
the server channel receives are routed through a chain of server
channel sinks.
Note There is no default constructor for the TcpServerChannel class.
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
If a remote object uses a TcpChannel or TcpServerChannel object to receive messages from clients, the
clients can call the methods on the remote object only if they use either a TcpChannel or
TcpClientChannel object. If clients use an HttpClientChannel or HttpChannel object to connect to a
remote object that uses a TcpChannel or TcpServerChannel object, an exception is thrown. The client
sees the error message, “The underlying connection was closed: An unexpected error occurred on a
receive.”
The decision of selecting HTTP or TCP channels depends on different features of these two types of
channels. Table 4.5
shows and compares the features of HTTP and TCP channels.
Whether you select HTTP or TCP channels for your remote applications, channels perform tasks that are
independent of the channel type. The messages that channels send to or receive from remote objects pass
through a chain of objects called channel sinks. The channel sink objects perform tasks such as
formatting, transporting, and stack building. In the next section, you will learn about channel sinks and
sink chains and understand their role in remoting.
Table 4.5: Features of HTTP and TCP Channels
HTTP channels TCP channels
Transport messages to and from remote objects Transport messages to and from remote objects
using the HTTP protocol. using the TCP protocol.
Use the SoapFormatter class to serialize and Use the BinaryFormatter class to serialize and
deserialize messages. deserialize messages.
Create two connections by default to connect to Create as many connections as the number of client
a given server. You can configure this channel threads making the requests. The socket connections
by changing the clientConnectionLimit attribute are closed if the connections remain inactive for 15–
in an application configuration file. 20 seconds.
Generate and consume the Channel- DataStore Generate and consume the ChannelDataStore for
for object references. object references.
Sinks and Sink Chains
Channels connect objects across remoting boundaries by allowing them to send messages to each other.
channel sink
performs
The messages carried by channels pass through a chain of channel sinks. A
certain functions on the message before forwarding the message to the next channel sink in the chain.
Figure 4.2: Channel sink chains
You use channel sink providers to create channel sink chains. These include objects that implement the
IClientChannelSinkProvider, IClientFormatterSinkProvider, or IServerChannelSinkProvider interfaces.
When you activate a remote object, the remoting system retrieves the channel sink provider from the
current channel and calls the CreateSink method on the channel sink provider to create the first channel
in the chain. The first channel sink on a client must be a formatter sink that serializes the message into a
stream. The last sink on the channel sink chain should be a transport sink that sends the stream over the
network wire.
The following code shows how to create a channel sink chain.
Visual Basic .NET
private Function CreateSinkChain() As IClientChannelSinkProvider
Dim chain As New FormatterSinkProvider_1
Dim sink As IClientChannelSinkProvider
sink = chain
sink.Next = New FormatterSinkProvider_2
sink = sink.Next
return chain
End Function
Visual C#
private IClientChannelSinkProvider CreateSinkChain()
{
IClientChannelSinkProvider chain = new FormatterSinkProvider_1();
IClientChannelSinkProvider sink = chain;
sink.Next = new FormatterSinkProvider_2();
sink = sink.Next;
return chain;
}
Note The FormatterSinkProvider_1 and FormatterSinkProvider_2 classes in the above code are the
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
classes that you create to create custom formatters.
In this lesson, you learned about channels that enable clients to send messages to remote objects.
Channels also transport information about events that might occur in client or server objects. .NET
Remoting allows you to do event-based programming for your remote applications. In the next lesson,
you will learn how to implement event-based programming for your remoting applications.
Lesson 4: Implementing Events and Delegates
The .NET Framework enables you to implement event handling and delegates in the remoting
applications that you create. This allows you to enhance the functionality of your remoting applications.
After this lesson, you will be able to
Describe events and delegates
Implement events and delegates in remoting applications
Estimated lesson time: 30 minutes
Understanding Events and Delegates
You usually associate event-based programming with applications that provide a graphical user interface
(GUI). In such applications, an event is triggered when an action, such as a mouse click, occurs on an
interface element. The information about the event is sent to another object, which responds to the event
event sender event source
by performing a task. The object that raises an event is called the or . The
event receiver event sink
object that receives and responds to the event is called the or .
You can use the event-based programming model for non-GUI applications, such as .NET Remoting
applications. An event in such an application occurs when the state of the application changes. The
event-based programming model for non-GUI applications also consists of a sender and a receiver.
However, in the communication between the sender and the receiver, the sender does not know which
object or method will receive the event. To ensure smooth communication between two objects,
the .NET Framework provides a special type called delegates.
delegate
is a class that holds a reference to the method that is called when an event is fired. Unlike
A
other classes of the .NET Framework, the delegate class has a signature. The delegate class can hold
references only to the methods that match its signature. The following code shows how to declare an
event delegate.
Visual Basic .NET
Public Delegate Sub RetirementHandler(sender As Object, _
e As RetireEventArgs)
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
Visual C#
public delegate void RetirementHandler(object sender, RetireEventArgs e);
After you declare an event delegate, you can define a method to which the event delegate points. The
signature of that method should match the signature of the event delegate. The following code shows the
method to which the event delegate points.
Visual Basic .NET
Public Class Action
' RetireEvent has the same signature as RetirementHandler.
Public Sub RetireEvent(sender As Object, e As RetireEventArgs)
End Sub
Visual C#
public class Action
{
//RetireEvent has the same signature as RetirementHandler.
public void RetireEvent (object sender, RetireEventArgs e)
{}
}
You then create an instance of the delegate and store the address of the method whose reference the
delegate holds.
Visual Basic .NET
Dim a As New Action()
Dim handler As RetirementHandler = AddressOf a.RetireEvent
Visual C#
Action a = new Action();
NewEventHandler handler = new RetirementHandler(a.RetireEvent);
Event delegates are multicasted. Therefore, you can define an event delegate to hold a reference to
multiple event handling methods. The next section
discusses implementing events and delegates in a
remoting application.
Implementing Events and Delegates in Remoting Applications
Events and delegates enable you to enhance the functionality of your remoting application. You can use
delegates to implement callback functions, event programming, and asynchronous programming in your
remoting applications. Events use delegates to enable callback functions to the client in remoting
applications. This enables the client and the remote application to function as domain servers. Therefore,
you need to design a server/server application instead of designing a client/server application.
callback
Note A function is a reference to a method that you pass to another method. When the second
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
method calls the referenced method, it actually calls back the first method.
When you implement events and delegates in remoting applications, you should ensure that:
The delegates you pass to the server for callback functions are delegates to instance members
because you cannot call static members remotely.
You register a channel to listen for the callback function.
Delegates enable the methods, which handle events, to be abstract. Events invoke all the delegates that
are registered to listen to that type of event. The delegates are similar to callback functions; the only
difference between a delegate and a callback function is that a client must register the delegate with the
event. You must perform the following tasks to enable delegates to listen for events in the remoting
application:
1.Define an event and the extension to the EventArgs class that the event passes to a delegate.
2.Define a delegate that wraps an event-handler method of the signature required by the event.
3.Define a method that handles the event.
4.Initialize a delegate that wraps the event-handler method.
5.Add the delegate to the event.
The following code shows how to implement events and delegates in a remoting application.
Visual Basic .NET
' Implement an EventArgs class
Public Class RetirementEventArgs
Inherits EventArgs
Private ret_age as Integer
Public Sub New(ByVal age as Integer)
ret_age = age
End Sub
Public ReadOnly Property RetirementAge() as Integer
Get
Return ret_age
End Get
End Property
End Class
' Define Delegate to handle the RetirementEvent
Public Delegate Sub RetirementEventHandler(ByVal sender As Object, ByVal _
e as RetirementEventArgs)
' Implement a class that raises the retirement event
Public Class Employee
Inherits MarshalByRefObject
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
Public Event retirement as RetirementEventHandler
Public Sub Retire()
Dim e as New RetirementEventArgs(58)
RaiseEvent retirement(Me, e)
End Sub
End class
' Implement class that handles the retirement event
Public Class HR
Public Shared Sub Main()
Dim emp as New Employee()
Dim hr as New HR()
AddHandler emp.retirement, AddressOf hr.RetirementHandler
End Sub
Public Shared Sub RetirementHandler(ByVal sender as Object, ByVal e as _
RetirementEventArgs)
Console.writeline("Retirement Age is " & Cint(e.RetirementAge))
End Sub
End Class
Visual C#
using System;
//Implement an EventArgs class
public class RetirementEventArgs : EventArgs
{
private int ret_age;
public RetirementEventArgs(int age)
{
ret_age = age;
}
public int RetirementAge
{
get
{
return ret_age;
}
}
}
//Define Delegate to handle the RetirementEvent
public delegate void RetirementEventHandler(Object sender,
RetirementEventArgs e);
//Implement a class that raises the retirement event
public class Employee : MarshalByRefObject
{
public event RetirementEventHandler retirement;
public void Submit()
{
RetirementEventArgs e = new RetirementEventArgs(58);
retirement(this, e);
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
}
}
//Implement class that handles the retirement event
public class HR
{
public static void Main()
{
Employee emp = new Employee();
HR hr = new HR();
emp.retirement+= new RetirementEventHandler(hr.RetirementHandler);
}
public void RetirementHandler(Object sender, RetirementEventArgs e)
{
Console.WriteLine("Retirement Age is " + (int)e.RetirementAge);
}
}
Besides implementing event-based programming in your remoting applications, you can also implement
asynchronous programming.
Lesson 5: Implementing Asynchronous Methods
.NET asynchronous programming enables you to call and execute a method while the program, which
calls the methods, continues to execute. This enables methods to continue executing without waiting for
the called methods to finish execution, which increases the speed of applications. .NET Remoting
supports asynchronous programming. Asynchronous programming in a remoting scenario is similar to
asynchronous programming in a single application domain or context. Therefore, you can make calls to
remote methods on servers while the application continues to execute on the client computer.
After this lesson, you will be able to
Describe asynchronous programming
Implement asynchronous programming in remoting applications
Estimated lesson time: 30 minutes
Asynchronous Methods
In .NET asynchronous programming, a call is made to a class method while the calling program
continues to execute. This happens until either the specified callback is made or until blocking, polling,
or waiting for the call to complete. You can use .NET asynchronous programming to:
Perform file IO, stream IO, and socket IO
Create networking applications (HTTP, TCP)
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
Define remoting channels (HTTP, TCP) and proxies
Develop XML Web services using ASP.NET
Create ASP.NET Web Forms
Create message queues over Microsoft Message Queuing (MSMQ)
Define asynchronous delegates
In .NET asynchronous programming, the server splits an asynchronous operation into two tasks. The
first task takes inputs from the client and starts the asynchronous operation. In addition, this task takes
an AsyncCallback delegate, which is called when the asynchronous operation completes. The second
task supplies the results of the asynchronous operation to the client. The first task returns a waitable
object that implements the IAsyncResult interface. The client uses the IAsyncResult interface to
determine the status of the asynchronous operation. The server uses the waitable object until it is
returned to the client to maintain any state associated with the asynchronous operation. The client then
supplies the waitable object to the second task to obtain the results of the asynchronous operation. You
implement asynchronous programming in the following ways:
You supply the callback delegate when you begin asynchronous calls.
Use callbacks.
You poll the IAsyncResult.IsCompleted property to determine the completion of
Poll completed.
asynchronous calls.
You use these methods when you need to complete the operation
BeginInvoke, EndInvoke.
prematurely.
You use these methods to wait on IAsyncResult.
BeginInvoke, WaitHandle, EndInvoke.
You use asynchronous delegates to call a method asynchronously. The common language runtime uses
multithreading to implement asynchronous method calls. When you call a delegate synchronously, the
Invoke method calls the target method on the thread on which the caller method is running. If the
compiler supports asynchronous delegates, it generates the Invoke method and the BeginInvoke and
EndInvoke methods.
When the BeginInvoke method is called, the common language runtime queues the request and
immediately returns to the called method. The target method is later called on a thread from the thread
pool. The original thread, which submitted the request, continues executing the target method. If a
callback is specified on the BeginInvoke method, it is called when the target method returns. In the
callback, the EndInvoke method obtains the return value and the in/out parameters. If the callback is not
specified on the BeginInvoke method, you can use the EndInvoke method on the original thread that
submitted a request.
Implementing Asynchronous Methods in Remoting Applications
The caller decides whether a particular remote call is asynchronous.
Remote types do not have to support asynchronous behavior by their clients.
You need to complete type safety.
You must use the System.Threading objects appropriately to wait or synchronize your methods.
To implement asynchronous programming in a remoting application, complete the following steps:
1.Create an instance of an object that can receive a remote call to a method.
2.Wrap that instance method with an AsyncDelegate method.
3.Wrap the remote method with another delegate.
4.Call the BeginInvoke method on the second delegate, passing any arguments, the AsyncDelegate
method, and some object to hold the state.
5.Wait for the server object to call your callback method.
The following code shows how to call methods asynchronously in a .NET Remoting application.
Visual Basic .NET
' Create an instance of the class that can receive remote calls
Dim remoteObj as New MyRemoteObject()
' Create delegate to a method that is executed when async method
' finishes execution.
Dim remoteMethod as New AsyncCallback(AddressOf remoteObj.CallBackMethod)
' Define a delegate to a method
Delegate Sub MyAsyncDelegate()
' Create a delegate to the method that will be executed asynchronously
Dim remoteDel As New MyAsyncDelegate(AddressOf obj.LongCall)
' Begin the invocation of the asynchronous method.
remoteDel.BeginInvoke(remoteMethod,nothing)
Visual C#
//Create an instance of the class that can receive remote calls
MyRemoteObject remoteObj = new MyRemoteObject();
//Create delegate to a method that is executed when async method
//finishes execution.
AsyncCallback remoteMethod = new AsyncCallback(remoteObj.CallBackMethod);
//Create a delegate to the method that will be executed asynchronously
MyAsyncDelegate remoteDel = new MyAsyncDelegate(obj.LongCall);
//Begin the invocation of the asynchronous method.
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
remoteDel.BeginInvoke(remoteMethod,nothing);
Lesson 6: Configuring and Securing .NET Remoting Objects
The .NET Framework allows you to configure remote applications programmatically by calling
configuration methods inside the application. In addition, the .NET Framework allows you to configure
the remote application by adding the remoting configuration section in the application configuration file.
You can use role-based security to secure remote applications. In addition, you can secure the remote
components hosted in ASP.NET by using Secure Sockets Layer (SSL) and the security features of
Internet Information Services (IIS).
After this lesson, you will be able to
Describe how to configure remoting applications
Configure secure remote objects
Describe the security options for remote objects
Estimated lesson time: 30 minutes
Remote Object Configuration
The .NET Framework allows you to configure remote objects programmatically or manually. You can
programmatically configure your remote objects when you do not want to change the properties of
remote objects after they are created and compiled. However, to change the properties of remote objects
dynamically without recompiling code, you use the application configuration file. To configure remote
objects programmatically or manually, you have to provide certain information to the remoting system.
This information enables a client to call your objects remotely. The information that you need to provide
includes
The activation type for the remote object
The channels that the remote object will use to receive messages from clients
The URL of the remote object
The type metadata that describes the type of your remote object
The .NET Framework provides the RemotingConfiguration class in the System.Runtime.Remoting
namespace that allows you to configure your remote components programmatically. The following code
shows how you can set the activation type and application name for your remote object.
Visual Basic .NET
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
ChannelServices.RegisterChannel(New TcpChannel(8020))
RemotingConfiguration.Configure(“MyApp.exe.config”);
Table 4.6: Configuration Attributes
Element Description
This element contains information about the remote objects that are exposed or
consumed by an application.
This element contains the objects that are exposed by an application. The
element can occur one or more times in the element.
This element contains information about server-activated objects exposed by the
application. The element can occur one or more times in the
element. The element has three required attributes:
mode, type, and objectUri. Mode can be Singleton or SingleCall. Type specifies
the type name and the name of the assembly that contains the type
implementation. ObjectUri specifies the endpoint for the URI of an object.
This element contains information about the client-activated objects that are
exposed by the application. The element can occur one or more times
in the element. This element consists of one attribute, type, which
specifies the type of the object and the assembly that implements the remote
object type.
Securing .NET Remoting Objects
You can use code-access security to secure remote objects. This enables you to control the resources that
a remote object can access on a computer. When you enable code-access security, a remote object
receives permissions depending on its security group. Table 4.7 shows the permissions of a remote
object in different security zones.
Table 4.7: Code-Access Security for Remote Objects
Security zone Access to channel and type? Access to channel sink
chain?
Everything Yes Yes
Full Trust (Local Machine) Yes Yes
LocalIntranet Yes No
Internet No No
Nothing No No
If you host remote objects in IIS, you can use the security feature of IIS and SSL to secure remote
objects. IIS hosting provides SSL, which allows you to secure messages sent to or received from remote
objects. In addition, you can use Integrated Windows Authentication or Kerberos to secure the remote
objects hosted in IIS. Therefore, whenever you have a choice between using the HttpChannel and the
TcpChannel class, you should use the HttpChannel class and host your remote objects in IIS.
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
Summary
You use .NET Remoting to enable communication between different applications residing on the
same computer or on different computers. These computers can be part of the same network or
part of networks in different geographic locations across the world. In addition, .NET Remoting
enables computers running different operating systems to communicate with each other.
You develop a remoting application by creating client and server objects and activating them. You
then use references of the server objects in the client application to enable communication
between the client and the server.
Channels enable a client object running in an application domain, process, or computer to send
messages to another object running in a different application domain, process, or computer. In
addition, channels allow applications to send and receive messages using various protocols, such
as TCP and HTTP.
Events and delegates enable you to enhance the functionality of your remoting application. You
can use delegates to implement callback functions, event programming, and asynchronous
programming in your remoting applications.
You can implement asynchronous programming to make calls to remote methods on servers while
the application continues to execute on the client computer.
You can configure remoting applications programmatically by calling configuration methods
inside the application or by adding the remoting configuration section into the application
configuration file.
You can secure your remoting application by implementing role-based security. In addition, you
can secure the remote components hosted in ASP.NET by using SSL and the security features of
IIS.
Lab: Creating and Consuming .NET Remoting Objects
In this lab, you will create a chat application that uses .NET Remoting. The chat application allows users
to send messages to all the other users who are currently logged on. The chat application consists of a
ChatCoordinator class, a Server class, and a Client class. The ChatCoordinator class inherits from the
MarshalByRefObject class and is the remotable object in the chat application. The Client objects call
methods on the ChatCoordinator object to send messages to other Client objects. The Server class is a
console application that configures the ChatCoordinator object by using the settings in a .config file. The
ChatCoordinator object and the Client objects use event-based messaging. The chat application consists
of the SubmitEventArgs class, which inherits from the EventArgs class. The ChatCoordinator object is
the source of the SubmitEventArgs event whereas the Client objects are the reciever or the sink of the
SubmitEventArgs event. The solutions to the exercises in this lab can be found in the \Solution folder on
the Su
pplemental Course Materials CD-ROM.
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
Estimated lab time: 90 minutes
Exercise 1: Create the ChatCoordinator.dll Library
In this exercise, you will create the ChatCoordinator.dll library. The ChatCoordinator.dll library
consists of ChatCoordinator and SubmitEventArgs classes. To create the ChatCoordinator.dll library,
perform the following steps:
1.Open Notepad and type the following code.
Visual Basic .NET
Imports System
Imports System.Runtime.Remoting
Imports System.Collections
_
Public Class SubmitEventArgs
Inherits EventArgs
Private message As String = Nothing
Private username As String = Nothing
Public Sub New(ByVal contribution As String, ByVal contributor _
As String)
Me.message = contribution
Me.username = contributor
End Sub 'New
Public ReadOnly Property Contribution() As String
Get
Return message
End Get
End Property
Public ReadOnly Property Contributor() As String
Get
Return username
End Get
End Property
End Class 'SubmitEventArgs
Public Delegate Sub SubmissionEventHandler(ByVal sender As Object, _
ByVal submitArgs As SubmitEventArgs)
Public Class ChatCoordinator
Inherits MarshalByRefObject
Public Sub New()
Console.WriteLine("ChatCoordinator created. Instance: " & _
Me.GetHashCode().ToString())
End Sub 'New
Public Overrides Function InitializeLifetimeService() As Object
Return Nothing
End Function 'InitializeLifetimeService
Public Event Submission As SubmissionEventHandler
Public Sub Submit(ByVal contribution As String, ByVal contributor _
As String)
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
Console.WriteLine("{0} says: {1}.", contributor, contribution)
Dim e As New SubmitEventArgs(contribution, contributor)
RaiseEvent Submission(Me, e)
End Sub 'Submit
End Class 'ChatCoordinator
Visual C#
using System;
using System.Runtime.Remoting;
using System.Collections;
[Serializable]
public class SubmitEventArgs : EventArgs{
private string _string = null;
private string _alias = null;
public SubmitEventArgs(string contribution, string contributor)
{
this._string = contribution;
this._alias = contributor;
}
public string Contribution
{
get{ return _string; }
}
public string Contributor
{
get { return _alias; }
}
}
public delegate void SubmissionEventHandler(object sender,
SubmitEventArgs submitArgs);
public class ChatCoordinator : MarshalByRefObject
{
public ChatCoordinator()
{
Console.WriteLine("ChatCoordinator created. Instance: " +
this.GetHashCode().ToString());
}
public override object InitializeLifetimeService()
{
return null;
}
public event SubmissionEventHandler Submission;
public void Submit(string contribution, string contributor)
{
Console.WriteLine("{0} sent: {1}.", contributor, contribution);
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
SubmitEventArgs e = new SubmitEventArgs(contribution,
contributor);
if (Submission != null)
{
Console.WriteLine("Broadcasting...");
Submission(this, e);
}
}
}
2.Save the file as ChatCoordinator.vb or ChatCoordinator.cs.
3.Open the Visual Studio .NET Command Prompt. Type to
vbc /t: library ChatCoordinator.vb
compile the code in ChatCoordinator.vb or type to
csc /t: library ChatCoordinator.cs
compile the code in ChatCoordinator.cs.
Exercise 2: Create a Configuration File for Configuring the ChatCoordinator Object
In this exercise, you will create a configuration file to specify the settings for the ChatCoordinator
remotable object that you created in the previous exercise. To create the configuration file, perform the
following steps:
1.Open Notepad and type the following code.
XML
mode="Singleton"
type="ChatCoordinator, ChatCoordinator"
objectUri="Chat"
/>
ref="http"
port="8080"
/>
2.Save the file as Central.config.
Exercise 3: Create a Console Application to Activate the ChatCoordinator Object
In this exercise, you will create a console application to activate the ChatCoordinator object by using the
remote configuration settings defined in the Central.config file. To create the console application,
perform the following steps:
file://C:\Documents%20and%20Settings\lddung\Local%20Settings\Temp\~hhE605.htm
1.Open Notepad and type the following code.
Visual Basic .NET
Imports System
Imports System.Diagnostics
Imports System.Runtime.Remoting
Imports System.Runtime.Remoting.Channels
Public Class Server
Public Shared Sub Main()
RemotingConfiguration.Configure("Central.config")
Console.WriteLine("The host application is currently " & _
"running. Press Enter to exit.")
Console.ReadLine()
End Sub 'Main
End Class 'ServerProcess
Visual C#
Imports System.Runtime.Remoting.Channels
Imports Microsoft.VisualBasic
Public Class ChatClient
Inherits MarshalByRefObject
Public Overrides Function InitializeLifetimeService() As Object
Return Nothing
End Function
Private username As String = Nothing
Public Sub New(ByVal [alias] As String)
Me.username = [alias]
End Sub
Public Sub Run()
RemotingConfiguration.Configure("Client.config")
Dim chatcenter As New ChatCoordinator()
AddHandler chatcenter.Submission, AddressOf Me.SubmissionReceiver
Dim userInput As String = ""
While True
Console.WriteLine("Press 0 (zero) and ENTER to Exit:")
userInput = Console.ReadLine()
If userInput = "0" Then Exit While
chatcenter.Submit(userInput, username)
End While
RemoveHandler chatcenter.Submission, AddressOf _
Me.SubmissionReceiver
End Sub
Public Sub SubmissionReceiver(ByVal sender As Object, ByVal args As _
SubmitEventArgs)
If args.Contributor = username Then
Console.WriteLine("Your message was broadcast.")
Else
Console.WriteLine(args.Contributor & " says:" & _
args.Contribution)
End If
End Sub 'SubmissionReceiver
{
private string username = null;
public override object InitializeLifetimeService()
{
return null;
}
public ChatClient(string alias)
{
this.username = alias;
}
public void Run()
{
RemotingConfiguration.Configure("Client.config");
ChatCoordinator chatcenter = new ChatCoordinator();
compile it in Client.cs by typing at the Visual
csc /r: ChatCoordinator.dll Client.cs
Studio .NET Command Prompt.
Exercise 5: Create a Configuration File to Configure the ChatClient Object
In this exercise, you will create a Client.config file to specify the settings to configure the ChatClient
object. To create the Client.config file, perform the following steps:
1.Open Notepad and type the following code.
XML
type="ChatCoordinator, ChatCoordinator"
url="http://localhost:8080/Chat"
/>
ref="http"
port="0"
/>
2.Save the file as Client.config.
