5th. Distributed System mode implement Broker through. NET Remoting using client-activated objects

Building an application in. NET that requires the use of distributed objects, and the lifetime of the distributed objects is controlled by the client. Your requirements include being able to pass objects by value or by reference, whether they reside on the same computer, on different computers residing on the same local area network (LAN), or on different computers residing on a wide area network (WAN).

Implementation strategy

This mode provides two implementations of implementing client-activated objects in. NET Remoting. The main difference between a client-activated object (CAO) and a server-activated object (SAO) is what controls the lifetime of the remote object. In the case of CAO, the client controls the lifetime, and in the case of SAO, the server controls the lifetime. The example used here is functionally similar to the example used in implementing a Broker in. NET using a server-activated object. As described in the. NET documentation and examples, the first implementation uses client-side activation. This implementation demonstrates the ability of the client to activate objects, but they also have some drawbacks. The second implementation, called the hybrid approach, solves these problems.

Client-activated object implementations

The RecordingsManager class has a method called Getrecordings , which retrieves a list of records from the database and returns the results in the DataSet. The class extends the MarshalByRefObject class to ensure that the Broker object is used in remoting situations, rather than copying objects from the server to the client. The functionality described here is exactly the same as the example described in "Using server-activated objects to implement Broker in. NET".

RecordingsManager.cs

The following example shows the RecordingsManager class, which is responsible for retrieving a DataSet from the database:

Using System;

Using System.Data;

Using System.Data.SqlClient;

public class Recordingsmanager:marshalbyrefobject

{

Public DataSet getrecordings ()

{

String selectcmd = "SELECT * from Recording";

SqlConnection myconnection = new SqlConnection (

"Server= (local);d atabase=recordings; Trusted_connection=yes ");

SqlDataAdapter mycommand =

New SqlDataAdapter (Selectcmd, MyConnection);

DataSet ds = new DataSet ();

Mycommand.fill (ds, "Recording");

return DS;

}

}

HttpServer.cs

The following code configures the server to allow the use of the new operator to create client-activated objects. Instead of actually registering an example (as in the SAO example), the code configures the server with the application name and the type of object to be created. The URL of the remote object is http://localhost:8100/RecordingsServer. SAO is automatically created in the background by the framework on the local host. The SAO is responsible for accepting requests from clients and creating those objects when the client requests the objects.

Using System;

Using System.Runtime.Remoting;

Using System.Runtime.Remoting.Channels;

Using System.Runtime.Remoting.Channels.Http;

public class Httpserver

{

static void Main (string[] args)

{

HttpChannel channel = new HttpChannel (8100);

ChannelServices.RegisterChannel (channel);

Remotingconfiguration.applicationname = "Recordingsserver";

Remotingconfiguration.registeractivatedservicetype (

typeof (RecordingsManager));

Console.WriteLine ("Recordings Server Started");

Console.ReadLine ();

}

}

HttpClient.cs

In order to be able to use the new operator and have the remoting framework create a remote object (as opposed to a local object), you must first associate the type of the remote object with the URL specified by the server when the ApplicationName property is set. The example defines applicationname as recordingsserverand uses port 8100 on the local host.

Using System;

Using System.Data;

Using System.Runtime.Remoting;

Using System.Runtime.Remoting.Channels;

Using System.Runtime.Remoting.Channels.Http;

Class HttpClient

{

[STAThread]

static void Main (string[] args)

{

HttpChannel channel = new HttpChannel ();

ChannelServices.RegisterChannel (channel);

Remotingconfiguration.registeractivatedclienttype (

typeof (RecordingsManager),

"Http://localhost:8100/RecordingsServer");

RecordingsManager mgr = new RecordingsManager ();

Console.WriteLine ("Client.main (): Reference acquired");

DataSet ds = Mgr. Getrecordings ();

Console.WriteLine ("Recordings Count: {0}",

Ds. Tables["Recording"]. Rows.Count);

}

}

Registering a remote object will associate the object's type with the URL. After that, a remote object is created on the server by calling new . The object looks like any other object in the code.

This implementation allows remote objects to be created directly under the control of the client. In addition, this implementation also shows that after the client is configured, the operation to create the object is exactly the same as using the new operator to create the object locally. However, it has a large disadvantage. That is, you cannot use the shared interface method described in SAO mode. This means that the compiled object must be passed to the client. For alternative ways to use SoapSuds, see Advanced . NET Remoting [Ingo02].

Note: the transfer of compiled server objects violates the general principle of distributed objects. Also, because of deployment and versioning issues, this should not be the case.

To solve some of these problems, the following implementation describes how the hybrid method uses SAO to create objects. This approach allows the client to control the lifetime of the object without having to deliver the server code to the client.

Mixing method

The hybrid method requires the use of recordingsfactory SAO, which provides a way to create a recordingsmanager CAO. (If you are unfamiliar with the SAO example, see "Implementing Broker through. NET Remoting using a Server activation object.") The following class diagram describes the overall solution.

Figure 1: structure of the hybrid method

This implementation uses the shared interface method described in the SAO example. Both the IRecordingsManager and irecordingsfactory interfaces are located in the assemblies that are shared between the client and the server. irecordingsfactory has a Create method that can return an object to implement the IRecordingsManager interface. This is an example of the abstractfactory [Gamma95] pattern. Because the client relies only on interfaces, there is no need to transfer server code. When the client needs to irecordingsmanager an object, it invokes the Create method of the irecordingsfactory instance. This allows the client to control the lifetime of the IRecordingsManager object without implementing the object. The two interfaces in a shared assembly are:

IRecordingsManager.cs

The following example shows the IRecordingsManager interface:

Using System;

Using System.Data;

public interface IRecordingsManager

{

DataSet getrecordings ();

}

IRecordingsFactory.cs

The following example shows the irecordingsfactory interface:

Using System;

public interface Irecordingsfactory

{

IRecordingsManager Create ();

}

The server implementations of these objects (recordingsfactory and RecordingsManager) are very simple and are included in their own assembly named server .

RecordingsFactory.cs

This class extends the MarshalByRefObjectand implements the Irecordingsfactory interface:

Using System;

public class Recordingsfactory:marshalbyrefobject, irecordingsfactory

{

Public IRecordingsManager Create ()

{

return new RecordingsManager ();

}

}

The recordingsfactory object is a server-activated object. The implementation simply calls newfor the recordingsmanager type. The RecordingsManager object is created on the server and is not used as a RecordingsManager object, but as a irecordingsmanager Interface returned by the. With this mechanism, the client can rely on interfaces rather than implementations.

RecordingsManager.cs

The only change required by the RecordingsManager class is that it now implements the IRecordingsManager interface.

Using System;

Using System.Reflection;

Using System.Data;

Using System.Data.SqlClient;

public class Recordingsmanager:marshalbyrefobject, IRecordingsManager

{

Public DataSet getrecordings ()

{

Console.WriteLine ("Assembly: {0}-filling a request",

Assembly.getentryassembly (). GetName (). Name);

String selectcmd = "SELECT * from Recording";

SqlConnection myconnection = new SqlConnection (

"Server= (local);d atabase=recordings; Trusted_connection=yes ");

SqlDataAdapter mycommand =

New SqlDataAdapter (Selectcmd, MyConnection);

DataSet ds = new DataSet ();

Mycommand.fill (ds, "Recording");

return DS;

}

}

HttpServer.cs

The server initialization code in the hybrid method configures the remoting framework for server-activated recordingsfactory objects. The activation method is independent of the channel and protocol used, so it is the same as before (HTTP protocol on port 8100).

Using System;

Using System.Runtime.Remoting;

Using System.Runtime.Remoting.Channels;

Using System.Runtime.Remoting.Channels.Http;

public class Httpserver

{

static void Main (string[] args)

{

HttpChannel channel = new HttpChannel (8100);

ChannelServices.RegisterChannel (channel);

RemotingConfiguration.RegisterWellKnownServiceType (

typeof (RecordingsFactory),

"Recordingsfactory.soap",

Wellknownobjectmode.singleton);

Console.ReadLine ();

}

}

In this code, therecordingsfactory type is associated with the URL Http://localhost:8100/RecordingsFactory.soap.

HttpClient.cs

The client code shows the mixed nature of this approach. First, use the Activator.GetObject method to retrieve the irecordingsfactory object from the server. Then, use this server to activate the object to invoke the Create method to instantiate a IRecordingsManager object. This newly instantiated object is created on the server, but it is a remote object.

Using System;

Using System.Data;

Using System.Runtime.Remoting;

Using System.Runtime.Remoting.Channels;

Using System.Runtime.Remoting.Channels.Http;

public class HttpClient

{

[STAThread]

static void Main (string[] args)

{

HttpChannel channel = new HttpChannel ();

ChannelServices.RegisterChannel (channel);

Irecordingsfactory factory = (irecordingsfactory)

Activator.GetObject (typeof (Irecordingsfactory),

"Http://localhost:8100/RecordingsFactory.soap");

Console.WriteLine ("Client.main (): Factory acquired");

IRecordingsManager mgr = Factory. Create ();

DataSet ds = Mgr. Getrecordings ();

Console.WriteLine ("Recordings Count: {0}",

Ds. Tables["Recording"]. Rows.Count);

}

}

Using a client-activated object to implement Broker through. NET Remoting has the following advantages and disadvantages:

Advantages

• distributed object Model. . NET Remoting provides a full-featured distributed object model with full common language runtime semantics that run on both the client and the server. The fidelity of the data passed between the client and the server is unaffected. This example shows how to pass a complex type System.Data.DataSetbetween a client and a server. It is not possible to implement such a pass if there are no common language runtimes at both ends of the connection.
• construction parameters. both the client-side activation implementation and the objects in the hybrid implementation take into account the arguments that pass the constructor when the object is created.

Disadvantages

• The remote object . You must remember that these objects are remote objects. Even if they look like local objects, the overhead is still required to marshal the data back and forth from the server. Remember that remote calls are at least 1000 times times slower than local calls in the common language runtime. Therefore, you should make such a call only when you need it. Because of the need to minimize round-trips, this can cause you to not use the finest granularity when working with interfaces.
• no shared Assemblies . In the CAO mode, the interface cannot be handled by using shared assembly methods. Instead, you must either transfer the implementation to the client or use SoapSuds to extract the metadata.
• the complexity of the deployment . When you use a server-activated object as described in the hybrid method, the object must already be registered before the client requests the object. This makes deployment more complex.
• Limited Interoperability . You can use. NET Remoting to build Web Service. However, you must reduce the endpoint to the simplest data type. For example, if you want to interoperate with other Web Service toolkits, you must limit the parameters to built-in simple types and your own data types (not using. NET Framework types, such as datasets), and use server-activated objects.
• more complex . . NET Remoting is more difficult to learn, implement, and debug than a Web Service.

Safety considerations

To use the security features provided by Microsoft Internet Information Services (IIS) (for example, standard HTTP authentication scenarios, including Basic authentication, Digest authentication, digital certificates, and even Microsoft. NET Passport), you must use an HTTP-based Application, and the application should reside in IIS with an ASP. NET environment. If you want to use any other transport protocol, or use a HttpChannelother than IIS, you are required to provide a security mechanism.

Operational considerations

The following is a performance comparison of the MSDN article "performance Comparison:. NET Remoting vs. asp. NET Web Services" (. asp Remoting) [Dh An overview of performance comparisons in AWAN02]. This article concludes that you can achieve the highest performance by using TCP Channel and binary serialization, as well as the Windows service host. This configuration transmits binary data through the original TCP sockets, which is more efficient than HTTP. Its performance is 60% faster than the slowest method of HttpChannel, which uses SOAP serialization residing in IIS with ASP.

Residing in IIS can cause performance degradation because it involves additional process jumps from IIS (Inetinfo.exe) to aspnet_wp.exe. However, if you choose to host your channel without IIS and ASP, you need to provide your own authentication, authorization, and privacy mechanisms.

5th. Distributed System mode implement Broker through. NET Remoting using client-activated objects