Microsoft Visual C++ .NET Professional Projects - Premier Press

4.The results from the remote object are streamed as the ObjRef object to the client, where it is unmarshaled to produce an instance of the TransparentProxy class, which is returned to the client.

5.During unmarshaling, the method information of the remote object is

extracted from the ObjRef object and the instances of TransparentProxy and RealProxy are created.

Channel Services

In the beginning of the chapter, you learned that a transport mechanism is required for interprocess communication. In case of communication between remote objects across application domains, the transport mechanism is required to transport information, such as the method call and call parameters, across the application domains. This underlying transport mechanism is provided by the

.NET channel service classes in the namespace System::Runtime::Remoting::

Channels.

The channels that the .NET Framework supplies include HTTP, TCP, and SMTP channels. In addition to these channels, third parties can plug in their own channels (using IChannel) to integrate heterogeneous applications.

All channels are derived from IChannel and implement one or both of the interfaces, IChannelReceiver and IChannelSender. The channels that implement both interfaces enable communication in both directions.

Before I tell you how the channels actually work, I’ll first state certain rules that a channel must follow:

Before a client can call a remote object, at least one channel must be registered with the remoting system. Always remember that channels must be registered prior to registering objects.

A process can contain multiple application domains, and channels are registered per application domain. Therefore, all channels that a process registers automatically get destroyed when a process dies.

The same channel that listens to the same port cannot be registered more than once.

Clients communicate with remote objects using registered channels.

882 Project 10 NETWORKING AND REMOTING IN VC++ .NET

Working of Channels

To understand how channels enable communication between application domains, consider a server application that hosts a remote object. Before a client can communicate with the remote object at the server application, the server application must register channels and the remote objects (to be exposed) with the remoting system.

NOTE

Remember that remote objects do not own channels. In fact, they share channels. Also, remember that at least one channel must be registered with the remoting system before a remote object is registered.

Channels are registered with the ChannelServices class and remote objects are registered with the RemotingServices class. When registering a remote object, the following information needs to be supplied:

The name of the assembly in which the class is contained

The Type name of the remote object

The object URI

The type of the object for server activation, which can be SingleCall or

Singleton

To register a remote object, the preceding information is passed as parameters to

the RegisterWellKnownType method of the RemotingServices class. The follow-

ing code shows the registration of an object as a well-known type:

TcpChannel* pChannel2 = new TcpChannel(8085);

ChannelServices::RegisterChannel(pChannel2);

Type* pType = __typeof(nsRemoting::CQuote);

RemotingConfiguration::RegisterWellKnownServiceType(pType, “Quote”,

WellKnownObjectMode::SingleCall);

Another method of registering a remote object is by storing the preceding information in a configuration file and then calling the ConfigureRemoting method, by passing the name of the configuration file as a parameter.

After the server application registers channels and the remote objects with the remoting system, the channel automatically starts listening at the specified port

for any client requests, and the ObjRef object gets created for the registered remote object. When the client sends a request on a channel, the remoting system examines the message to identify the target object reference. If the object reference is found, the system forwards the call to the respective object.

Secured Communication

Channels provide the underlying transport mechanism for communication between application domains. When messages travel to and from the application domains, the security of messages is required, especially when developing business applications. The security issue is taken care of by encoding messages before sending them and then decoding messages at the receiving end. This encoding and decoding of messages between application domains is implemented through the

.NET serialization formatters in the namespace System::Runtime::Serialization:: Formatters.

The .NET formatters include two native formatters:

Binary. TCP channels use binary formatters to serialize all messages in binary format. Then, the TCP channel transports the encoded message to the target URI using the TCP protocol.

SOAP. HTTP and SMTP channels use SOAP to serialize messages in XML format. Then, the encoded messages are transported to the target URI using the SOAP protocol.

NOTE

The Binary formatter belongs to the System::Runtime::Serialization::Formatters::Binary namespace. The SOAP formatter belongs to the System::Runtime::Serialization::Formatters::Soap namespace. By default, the HTTP and SMTP channels use SOAP, whereas TCP channels use binary payload to communicate.

In addition to the two native formatters available with .NET, the serialization formatters are also pluggable. Serialization formatters are pluggable by implementing the IRemotingFormatter interface. Then, you can select a combination of the channel and the formatter depending on the security needs of your application.

884 Project 10 NETWORKING AND REMOTING IN VC++ .NET

Remoting Metadata and Configuration

Files

Remoting metadata is the information about components that enables cross-lan- guage programming. The Remoting system uses the information contained in the metadata to create proxy objects at the client side. Similarly, formatters use metadata to encode and decode method calls.

Clients also require information stored in metadata to access remote objects. Clients can use the following tools to access the metadata information:

The .NET Assembly. The server object creates a metadata assembly and distributes the same to the clients. Then, when the client is compiled, the client can reference the assembly. This method is used when both the server and client components are managed components.

Web Services Description Language (WSDL). The remote object generates a WSDL file that contains the information about the object and its methods. For a client to be able to communicate to the object using SOAP, the client should be able to read and generate SOAP requests corresponding to the WSDL file.

The SOAPSUDS utility. The .NET clients can use the SOAPSUDS utility to download the XML schema, which is generated at the server, and generate the source files that contain only the metadata and not the source code.

In addition to metadata information, the remoting information is stored in a configuration file (.cfg) for a given object. Each application domain contains a configuration file of its own. The information that a configuration file contains includes the following:

Information pertaining to the host application

Name of objects

URI of objects

Channels being registered

Lease time information for server objects (covered in the next section of this chapter)

The configuration files contain remoting information, which can be generated programmatically. However, keeping a separate configuration file has one main

advantage. Because configuration files contain the remoting information separately, which is transparent to the client code, any future changes can be reflected by modification in the configuration files. However, on the other hand, if the remoting information were generated programmatically, you would have to edit and recompile the source file.

Object Lifetime

Based on the manner in which a remote object is activated, the .NET Framework supports two types of objects:

Client-activated objects. Activated from the client side. The lifetime of these objects is determined by the lease manager; the object dies when the lease expires.

Server-activated object. Activated at the server side. These objects can

be Single Call or Singleton.

Next, you’ll learn how the lease manager controls the lifetime of the client-acti- vated objects.

When a client activates a remote object, the lease is created with a default lease time. The lifetime of the remote object is determined by this lease. When the lease reaches a value 0, the lease is said to expire, and consequently the remote object does not remain connected to the .NET Framework. When the application domain has been freed of all references of the remote object, the object will be collected when the garbage collection (GC) occurs.

The leases for various objects are administered by the lease manager, which is available with each application domain. Leases implement the ILease interface. Each time a lease is created, the lease time is set to the maximum of the current LeaseTime. The lease time also includes the RenewOnCallTime. When the lease is expired, the lease manager looks for sponsors (implementing the ISponsor interface) that are given an opportunity to renew the lease.

Although objects have a default lease time, the default lease time can be extended in several ways so that remote objects have a longer lifetime. The following are the different ways to extend the lease time:

The lease time of the server object can be set to infinity. This prohibits the collection of objects during garbage collection cycles.

886Project 10 NETWORKING AND REMOTING IN VC++ .NET

The client can renew the lease time of the server object. To do so, the

client first calls the RemotingServices.GetLifetimeService method.

This method returns the lease of the server object from the lease manager of the application domain. Then, to renew the lease, the client can call the Lease.Renew method.

The client can register a sponsor for a lease with the lease manager of the application domain. Then, when the lease expires, the client can request the sponsor for renewal of the lease.

If the RenewOnCallTime property of the lease is set, the lease gets renewed by the amount specified in the RenewOnCallTime property, whenever the object is called.

Summary

In this chapter, you were introduced to the .NET remoting architecture and how it works. You have learned the intricacies of how remote objects are created, exposed, and passed at the server side. Then, you learned how remote objects are called at the client side. You also learned about the .NET communication channels that are required for communication between different application domains.

Project initiation

Project execution

Project deployment

In the project-initiation phase, the project plan was prepared and the development team for the project was also identified. The development team further prepared a comprehensive list of tasks involved in the execution and deployment phases of the project’s life cycle.

Now, the team is in the project-execution phase and has analyzed the requirements that the applications should cater to.

Requirements

The application needs to be installed on the NJ Finances network, which is Win- dows-based. The Quiz Application will consist of a server part and a client part. The client part can be executed from the machine of any employee who wants to take the quiz. The server part will run on a central Windows 2000 server using the .NET platform. For networking plumbing, the application will make use of

.NET Remoting.

Eventually, once the scheme of monetary incentives becomes fully applicable, the test items and the results will be stored in a database. For now, the team at NJF has decided to create an application that will simply have a server and a client part. The questions will be hard-coded in the server component.

Design

During this phase, the functionality to be implemented and the technology to be used are determined. It was decided that the application would make use of .NET Remoting for its networking requirement. The client will be a GUI application that will display the test items, allow the user to answer, and in the end display the result.

Construction

During this phase, the NJF team will construct the application. The primary tasks that the team needs to perform are:

Design and create the server application

Design and create the client application