Catálogo de publicaciones - libros

In this chapter, we’ve covered most of the key concepts involved in .NET Remoting. We’ve looked at where it fits into the long tradition of distributed client-server systems. You learned about the three object types, and how leased lifetimes are managed to keep resources running smoothly. You’ve also seen how channels, formatting, and serialization fit into .NET remoting to facilitate method calls on remote objects. We’ve also discussed marshaling by reference (MBR) and marshaling by value (MBV), and how to use each in the appropriate circumstances. You saw how a client gets ahold of the metadata for the remoting object. Finally, we’ve examined how proxies and channel sinks work together to make remoting work. You’re now ready to try some serious remote programming.

In this chapter, we went on a journey into the interior of .NET Remoting, a journey made possible by the “pluggability” of its architecture. We began by inserting our own custom channel sink into the chain. Then we modified that into a client-side formatter (message) sink, before implementing our own formatter. We also implemented our own serialization on a simple object to use with the formatter sink. Finally, we implemented our own custom TCP/IP socket-based channel.

In this chapter, we’ve looked at two main types of asynchronous .NET applications, and how they can be successfully remoted. We first looked at simple remote asynchronous method calls using delegates and asynchronous callbacks. In this case, a client sends a request to a server; while it waits for the request to be served, the client is still available to handle other processes. Then we turned our attention to situations where the client might expect multiple responses for the server over time. We saw that we could handle this situation by using events, although we noted that remoting an event-oriented .NET application is not as straightforward as we might have hoped; we had to create a remotely delegatable object on the client, which the server will recognize. Finally, we looked at how the call context is useful for passing client information around between remote objects running asynchronous processes.

Debugging and error handling is a thankless task at the best of times, but when you develop remoting applications, you have many more hurdles to overcome. There seems to be an almost endless list of things that can go wrong, such as server unavailability, incorrect configuration at the client or server, user error, or application-specific exceptions. In this chapter, we’ve presented several techniques to help you through the mire. First, you’ve seen the common exceptions that can typically occur in .NET remoting applications. You’ve also seen how to perform error checking at the client application and in the remoting object, to detect anomalous situations at runtime. In addition, you’ve seen how to use debug and trace messages to help you understand whether the application is behaving as expected. At the end of the chapter, we defined custom exception classes to represent application-specific errors in the remoting object. We used the custom exception class as a natural placeholder for centralized error handling in the remoting object, such as logging all exceptions to a flat file, a database, or the Windows event log. In the next chapter, we’ll consider some best practices that, if followed, should make your remoting applications as efficient, maintainable, and reusable as they can be.

In this chapter we discussed how to use reflection in an active way to control class members. We considered the following topics: Reasons you should consider using dynamic invocation techniques on types and their members How to dynamically invoke methods, properties, and fields using Type.InvokeMember() How to dynamically invoke methods using MethodInfo.Invoke() How to dynamically modify fields and properties using the GetValue() and SetValue() methods of the FieldInfo and PropertyInfo classes Why using dynamic invocation via reflection is not always the best choice, and when you should use delegates instead In the next chapter, we’ll consider how to create objects using reflection.

By joining the abstract factory pattern concept, dynamic assembly loading, and object creation in VB .NET, a developer can create a highly flexible and extendable application. Dynamic assembly loading allows new assemblies to be loaded into an application, even after the application has been compiled. The abstract factory pattern centralizes the decision logic for which concrete instance of an object should be created given the parameters sent into the factory class. Although these structures add some complexity to the code, this increase in complexity is often outweighed by the flexibility gained, especially in situations where the system requirements are constantly changing.