spacer

Webref WebRef   Sitemap · Experts · Tools · Services · Newsletters · About i.com

home / programming / csharp / webservices / chap6 / 2 current pageTo page 2To page 3To page 4To page 5To page 6To page 7To page 8
[next]

Professional C# Web Services

Developer News
OpenOffice 3.2 Lands Amid Critical Changes
Red Hat, IBM Firmly in KVM Virtualization Camp
Red Hat Talks Up Open Source Cloud Plans

Remote Objects

[The following is a continuation of our series of excerpts from chapter 6 of the Wrox Press title, Professional C# Web Services.]

With remote objects we have to differentiate between well-known objects and client-activated objects.

Well-known objects are stateless; client-activated objects hold state.

If we use client-activated objects that hold state we should bear in mind that every call across the network takes time. It is not a good idea to use properties to set some state of the remote object. Instead, it would be much faster to use method calls with more arguments and so use fewer calls that are sent across the network. With COM it was said that a COM object could similarly be used locally, or across the network. The reality showed that if a COM object was implemented with properties to be easy to use from the client, it was not efficient on the network, and if it was efficient on the network it was not easy to use from a scripting client. With .NET we already have the advantage that remote object classes must derive from MarshalByRefObject, and such objects should implemented in a way that is efficient when used across the network. Classes that don't derive from MarshalByRefObject can never be called across the network.

Well-Known Objects

For well-known objects, the client must know the endpoint of the object – that's why they are called well-known. The endpoint is used to identify the remote object. In contrast to that, with client-activated objects the type of the class is used to activate the remote object.

Instead of using a configuration file as we have done earlier to register a channel and define a well-known object, we can do this programmatically. To get the same result as with the configuration file we have to do some more coding steps:

Removing the configuration file and the call to RemotingConfiguration.Configure(), the implementation of the server can look like the following sample. In the configuration file we specified the TCP Server channel in the <channels> section. Here, we create an instance of the class TcpServerChannel programmatically, and define 9000 as listening port in the constructor.

Next we register the channel in the .NET Remoting runtime with the static method ChannelServices.RegisterChannel(). ChannelServices is a utility class to help with channel registration and discovery.

Using the RemotingConfiguration class we register a well-known object on the server by calling RegisterWellKnownServiceType(). The helper class WellKnownServiceTypeEntry can be used to specify all the values that are required for well-known objects that are registered on the server. Calling the constructor of this class we specify the type of the remote object MyRemoteObject, the endpoint name SimpleServer/MyRemoteObject, and the mode that is one value of the enumeration WellKnownObjectMode: SingleCall:

// SimpleServer.cs

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;
namespace Wrox.Samples
{
   class SimpleServer
   {
      static void Main(string[] args)
      {

         // Create and register the server channel

         TcpServerChannel channel = new TcpServerChannel(9000);
         ChannelServices.RegisterChannel(channel);

         // Register the remote object type and endpoint

         WellKnownServiceTypeEntry remObj = new 
            WellKnownServiceTypeEntry(
               typeof(MyRemoteObject), 
               "SimpleServer/MyRemoteObject",
               WellKnownObjectMode.SingleCall);
         RemotingConfiguration.RegisterWellKnownServiceType(remObj);
         Console.WriteLine("Press return to exit");
         Console.ReadLine();
      }
   }
}

With the compilation of the server we now have to reference the assembly of the remote object as the type is used in our code:

csc /target:exe /reference:MyRemoteObject.dll SimpleServer.cs

home / programming / csharp / webservices / chap6 / 2 current pageTo page 2To page 3To page 4To page 5To page 6To page 7To page 8
[next]


The Network for Technology Professionals

Search:

About Internet.com

Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers

webref The latest from WebReference.com Browse >
Search Engine Optimization: Selecting and Embedding Keywords · Are Google's Language Translation Web Services Ready for Prime Time? · Installing and Using Meeplace, the Business Review CMS
Sitemap · Experts · Tools · Services · Email a Colleague · Contact FREE Newsletters 
 The latest from internet.com
IBM DB2 10 for z/OS: Justifying the Upgrade · Living La Vida Colo: Choosing the Right Colocation Facility · FTC Concerns over Social Media Privacy Linger

Created: February 25, 2002
Revised: February 25, 2002


URL: http://webreference.com/programming/csharp/webservices/chap6/2/