Creating More Manageable Applications

Now that you understand the basics of .NET Remoting, you are ready to look at some additional topics that will help you create more efficient and manageable applications. First, you will learn about using application configuration files for making common .NET Remoting settings. In the preceding examples you made these settings in source code. Changing a configuration file is much easier than changing source code when you need flexibility at deployment time. Finally, you will look at a technique for using .NET Framework callback delegate objects to make asynchronous calls on remote applications.

Using a Configuration File

.NET Remoting settings are one of the many features that you can specify by using XML configuration files for your application. XML configuration files are used to hold application specific settings. The advantage of making these settings in configuration files rather than directly in your source code is that an administrator can make changes without having to change and recompile the original source code. For example, if a conflict in port numbers becomes a problem after your application is deployed, this setting can easily be changed in the configuration file without a need to change the compiled DLL.

Configuration files can be provided on both the client side and sever side. The .NET Framework defines a common set of tags that can be used inside the configuration file. Refer to the Visual Studio .NET documentation for a complete set of all available application configuration tags. Configuration files are typically placed in the same directory as your application's executable file and follow this naming convention:

ApplicationName.exe.config

Note 

Remember that XML parsing tools expect all XML tag names and attribute names to exactly match uppercase and lowercase characters as defined. Make sure your configuration files follow the examples or you will get an error when you run your application.

The next two code listings give examples of some common settings that can be made in the configuration files. Listing 3.6 shows XML configuration setting that specify a server-activated object. These XML configuration settings are the equivalent of the code shown earlier in this chapter in Listing 3.4 when using the RemotingConfiguration.RegisterWellKnownServiceType method.

Listing 3.6: A Server-Side Configuration File

<configuration>    <system.runtime.remoting>       <application>          <service>            <wellknown              mode = "SingleCall"              type = "RemoteObjectClass, RemoteAssembly"              objectUri = "myUri"            />          </service>       </application>    </system.runtime.remoting> </configuration>

Listing 3.7 shows an example of settings that you would place in a client-side configuration file. These settings provide the same information that was used with the Activator.GetObject method in our earlier examples (see Listing 3.5). When you use a configuration file to specify these settings, you do not need to call Activator.GetObject to instantiate the remote class. Instead, your client code will call a method to access the data in the configuration file and then simply use the New operator to instantiate the object. This is shown in Listing 3.8.

Listing 3.7: Client-Side Configuration Options

<configuration>    <system.runtime.remoting>       <application>             <wellknown                type = "RemoteObjectClass, RemoteAssembly"                url = "http://localhost:8080/MyUri"             />          </client>       </application>    </system.runtime.remoting> </configuration>

Listing 3.8: Instantiating a Remote Object That Uses a Configuration File

Public Shared Sub Main()     RemotingConfiguration.Configure( _       "MyApplication.exe.config")     Dim objRemote As RemoteObjectClass = New _       RemoteObjectClass() End Sub

Making Asynchronous Calls

When implementing a production application that uses remote calls over a network, the time required to complete a method call can take considerably longer than what you have seen so far in your practice code. In cases when a user might have to wait a few seconds for a call to complete, it is preferable to make the remote calls asynchronously-that is, the client code does not block (or wait) while the call is connecting to the remote server and executing. The client application's user interface will be active, and you can give the user an indication, by using status messages or a progress indicator, that the application is working. Without asynchronous calls, a user might think that their computer has locked up and try to reboot if a call to a remote server takes too long.

Asynchronous method calls can be implemented simply by using .NET Framework Delegate objects and an asynchronous callback function. (If you are unfamiliar with using Delegate objects, you should refer to the Visual Studio .NET documentation for more background information.)

Listing 3.9 shows two procedures that use the System.Delegate.BeginInvoke and System.Delegate.EndInvoke methods to make the remote call asynchronously. The first procedure, called asyncExample, starts by using Activator.GetObject to declare and instantiate the remote object, just as you did in the earlier examples (see Listing 3.5). Then we declare and instantiate two Delegate objects. The first delegate represents the method that we are going to call on the remote server, and the second delegate represents the method that will accept a 'call back' from the remote server when the original method call completes. Notice that we have a delegate declaration at the top of the module. The method signature of this declaration must match the method signature of the remote method we want to call. In this example, our remote method takes no arguments and returns a value of type DateTime. The second Delegate object is of type System.AssemblyLoadEventArgs.AsyncCallBack. Both delegates use the Visual Basic .NET AddressOf operator to specify the functions that they represent. Now we can call the remote method by using Delegate.BeginInvoke.

When calling BeginInvoke, you can pass any arguments required by the remote function (in this example, there are none), the name of the callback delegate, and a third parameter that is an object reference that might contain some state information (in this example, there is none, so we use the Visual Basic .NET keyword Nothing).

When the remote method call is complete. the .NET Framework event mechanism will notify the client application by calling back to the designated function, in this example MyCallBack. The MyCallBack function declares some local variables, one to hold the result data, one AsyncResult object to read the results, and a new delegate, declared as the same type as the delegate in the first procedure that called BeginInvoke. Then we can call the Delegate.EndInvoke method and retrieve the results.

Listing 3.9: Asynchronous Calls

Imports System.Runtime.Remoting.Messaging Public Delegate Function MyDelegate() As DateTime Private Sub asyncExample()     'this code is the same as previous examples     Dim timeObject As TimeInterface.ITime = _       CType(Activator.GetObject( _       GetType(TimeInterface.ITime), _       "http://localhost:8080/timeUri"), _        TimeInterface.ITime)     'now declare the delegates     Dim timeDelegate As MyDelegate = New MyDelegate( _       AddressOf timeObject.GetServerTime)     Dim timeCallBack As New AsyncCallback( _       AddressOf MyCallBack)     'invoke the method     timeDelegate.BeginInvoke(timeCallBack, Nothing) End Sub Public Sub MyCallBack(ByVal ar As System.IAsyncResult)     Dim result As DateTime     Dim aResult As AsyncResult = CType(ar, AsyncResult)     Dim tempDelegate As MyDelegate = CType( _       aResult.AsyncDelegate, MyDelegate)     result = tempDelegate.EndInvoke(ar)     txtDisplayTime.Text = result End Sub

Real World Scenario-Distributed Applications

You are a software developer for a large organization. When developing Visual Studio 6 applications in the past, you were used to creating distributed applications that took advantage of the n-tier architecture model to centralize business logic on middle-tier servers. You would like to use this same design in your new .NET applications. Several other members of your team have been to some .NET presentations and they are very excited about using XML Web services. You think that XML Web services are a great idea for offering external clients access to selected functions on your servers, but are not sure whether they are the right choice for your internal applications.

Your primary goal is to simplify ongoing maintenance and support of your business logic components, by having a single installation of the components on a central server. You are not overly concerned about security features because all the users of your application are already logged on and authenticated by the corporate network. You do not have to worry about cross-platform support because all client computers will be upgraded to run the .NET Framework.

You have looked at .NET Remoting and like its simple model that is similar to the distributed computing model that you've used in the past. You like the flexibility of choosing different types of channels and protocols, and expect that this will enable you to optimize performance. You also like the idea of setting options in configuration files, so you will not have to make source code changes and redeploy a component if a simple change, such as a port number or server name, is needed.

It's clear that the .NET Framework provides many options; it's up to you to make the best choices for each application.