| The first type of messaging we'll consider is fire-and-forget methods, which are supported intrinsically by .NET Remoting and XML Web services. With fire-and-forget methods, the client sends a request message but the server never responds. Therefore, the remote method can't set a ByRef parameter or return a value. In addition, if the remote method throws an unhandled exception, it won't be propagated back to the client. To create a fire-and-forget XML Web service method, you need to apply a SoapDocumentMethod attribute to the appropriate Web method and set the OneWay property to True. Listing 8-1 shows an example. Listing 8-1 A one-way Web method Imports System.Web.Services Imports System.Web.Services.Protocols Public Class Stats Inherits WebService <SoapDocumentMethod(OneWay := True), _ WebMethod()> _ Public Sub DoLongTask() ' Starts a long database task that doesn't return ' information to the client. End Sub End Class To create a fire-and-forget Remoting method, you need to apply the OneWay attribute. Listing 8-2 shows an equivalent example for a remote component. Listing 8-2 A one-way method over .NET Remoting Imports System.Runtime.Remoting.Messaging Public Class Stats Inherits MarshalByRefObject <OneWay()> _ Public Sub DoLongTask() ' Starts a long database task that doesn't return ' information to the client. End Sub End Class Both of these attributes are often overlooked when developers design distributed systems. If you don't need to return information directly to a client, these methods offer a better option than just calling a normal method asynchronously. Why? Here are the reasons: With an asynchronous call, the responsibility falls on the client. If the client neglects to call the method asynchronously, a long wait might be incurred. With one-way methods, client calls are always asynchronous. With an asynchronous call, the client waits for a response, but on a separate thread from the rest of the application. With one-way methods, the connection is completely severed after the request and incurs no additional overhead. With one-way methods, the client won't receive an unhandled exception. This is generally the desired behavior because the client might not understand the significance of a specific low-level exception and will probably not be able to correct it.
Of course, messaging is not suited for all scenarios. For example, a one-way method has no way to inform the client whether the submitted information is invalid. You should also remember that one-way methods don't use a dedicated messaging service. They can solve the problem of long method calls that would otherwise tie up clients, but they can't solve the problems of heavy client loads, where requests are received faster than they can be processed. To deal with this reality, you need Message Queuing. Do One-Way Methods Make Good Event Handlers? Developers are sometimes advised to use one-way methods with applications that receive events or callbacks over .NET Remoting. The idea is that if you use one-way methods, the server can fire the event without worrying that an unhandled exception on the client end might propagate back to the server. The server also won't be tied up waiting for the client method to finish. The reality isn't quite as simple. One-way methods are great event handlers if only two parties (one sender and one recipient) are involved. If you're using a singleton component that fires an event to multiple clients, however, they might not be as well suited. This is because the server won't be notified of an error if it attempts to send an event to a one-way method, even if this error occurs because the client has disconnected. If your singleton runs continuously for several days, it might build up a long list of disconnected clients and it will try to send events to all of them, slowing down the overall system performance. In this case, it is better not to use one-way methods. In fact, it's also better not to use events and to instead communicate with the client through delegates. The server can then store a collection of client delegate references. Every time the singleton component needs to fire an event, it can loop through its collection of delegates and attempt to invoke each one. If an exception is generated, it can just catch the exception and remove the delegate from the collection and thereby clean up disconnected client references. |
|
