Catálogo de publicaciones - libros

This chapter provided a short introduction to the world of distributed application development and the respective technologies. You now know about the various scenarios in which .NET Remoting can be applied and understand how it differs from other distributed application protocols and techniques.

In this chapter, you read about the basics of .NET Remoting. You now know the difference between MarshalByRefObjects, which allow you to call server-side methods, and ByValue objects, which have to be serializable and will be passed as copies. You read about the general structure of a remoting application and implemented a sample application that relied on shared interfaces.

In this chapter you read about the basics of distributed .NET applications using .NET Remoting. You now know the difference between ByValue objects and MarshalByRefObjects, which can be either server-activated objects (SAO) or client-activated objects (CAO). You can call remote methods asynchronously, and you know about the dangers and benefits of one-way methods. You also learned about the different ways in which a client can receive the necessary metadata to access remote objects, and that you should normally use shared interfaces as a best practices approach.

It seems that the only thing that can keep you from developing your first real-world .NET Remoting application is that you don’t yet know about various issues surrounding configuration and deployment of such applications. These two topics are covered in the following chapter.

In this chapter, you learned about the different settings that can be employed in a configuration file. You now also know why configuration files are important and why you shouldn’t hard code the connection information in your .NET Remoting clients.

You know how to use configuration files to allow for transparent use of configuration files for all types of remote objects. I also demonstrated a possible workaround for some problems that you might encounter when using [Serializable] objects in combination with SoapSuds-generated metadata. In the section “What About Interfaces?” in this chapter I also introduced an approach for using configuration files with an interface-based remote object, which eliminates the need for SoapSuds.exe.

I showed you different deployment scenarios, including managed applications such as a console application or a Windows service. You also read about the benefits of using IIS to host your remote objects and how to debug Windows services and IIS as remoting hosts.

In the next chapter, I show you how to build .NET Remoting clients for various technologies: Windows Forms, ASP.NET Web sites, and Web Services.

In this chapter, I showed you how to leverage IIS’s built-in authentication and encryption feature. You now know how to set up the IIS virtual root to allow certain authentication protocols and how to check a user’s role membership in your components. I also showed you how to encrypt the HTTP traffic using SSL certificates.

You’ve also learned how you can use an additional component from Microsoft to secure and authenticate remoting traffic independently from the chosen transport format.

Last but not least you have had a close look at the new .NET Remoting security infrastructure included with the next version of the .NET Framework, which allows you to authenticate and/or impersonate the client’s identity as well as securing traffic between the client and the server through digital signatures and encryption.

In the next chapter, you’ll learn about some specialties of .NET Remoting. The chapter covers more advanced lifetime management issues, versioning, asynchronous calls, and events.

In this chapter, you took a look into the details for creating different types of .NET Remoting clients. You saw the different ways for configuring clients and also saw that you have to be careful when configuring .NET Remoting in ASP.NET-based client applications.

In the last section of this chapter, you took a closer look at some security concerns-especially how you can flow the identity from the client to the server. In general, a very good strategy for flowing identities is having separate accounts for roles of users to not flow all the end users through all tiers of your distributed applications for easier management. Don’t forget that Kerberos must be configured properly when identities flow across machine borders.

In this chapter you learned about the details of .NET Remoting-based applications. You now know how lifetime is managed and how you can dynamically configure an object’s time to live. If this doesn’t suffice, implementing client- or server-side sponsors gives you the opportunity to manage an object’s lifetime independently of any TTLs.

You also read about versioning, and you can now look at the whole application’s lifecycle over various versions and know what to watch out for in regard to SAOs and CAOs, and know how the ISerializable interface can help you when using [Serializable] objects.

On the last pages of this chapter, you read about how you can use delegates and events, and what to take care of when designing an application that relies on these features. In particular, you learned that using [OneWay] event handlers the intuitive way certainly isn’t the best practice.

You should now be able to solve most challenges that might confront you during design and development of a .NET Remoting application. In the next two chapters, I will share some additional tips, best practices, and troubleshooting guides that you should take into account before designing your .NET Remoting-based solution.

In this chapter, I showed you how to leverage IIS’s built-in authentication and encryption feature. You now know how to set up the IIS virtual root to allow certain authentication protocols and how to check a user’s role membership in your components. I also showed you how to encrypt the HTTP traffic using SSL certificates.

You’ve also learned how you can use an additional component from Microsoft to secure and authenticate remoting traffic independently from the chosen transport format.

Last but not least you have had a close look at the new .NET Remoting security infrastructure included with the next version of the .NET Framework, which allows you to authenticate and/or impersonate the client’s identity as well as securing traffic between the client and the server through digital signatures and encryption.

In the next chapter, you’ll learn about some specialties of .NET Remoting. The chapter covers more advanced lifetime management issues, versioning, asynchronous calls, and events.

In this chapter, you’ve seen some of the most important best practices for developing .NET Remoting applications. This list is, of course, not complete, but it reflects the most common points I have encountered on consulting projects, and in personal e-mail exchanges with several hundred developers who are using .NET Remoting in their daily projects.

Apart from a detailed look at several scenarios for .NET Remoting, you’ve learned that there are also numerous cases for which remoting is not the right solution. I have briefly introduced you to UDP and MSMQ, which can be used for scalable delivery of asynchronous notifications.

At the end of this chapter, you’ve seen how easy it is to configure a Windows Network Load Balancing cluster, which provides your applications with transparent failover and the possibility to scale out.

In the following chapter, I’ll discuss the most common causes—and solutions—for problems and issues when using .NET Remoting.

The .NET Remoting framework offers a big number of features with a relatively small number of “well-known pitfalls.” In this chapter, I’ve illustrated the most common issues that turn up when remoting applications are developed or deployed.

You’ve seen how to debug different kinds of remoting application, and how to make sure that your configuration files are correct. This is especially important because most remoting-related problems stem from incorrect configuration files—a small typo or case mismatch in them can result in several hours of searching for a bug.

In addition, you’ve learned how to enable custom exceptions when hosting in IIS, and how to use client-activated objects behind firewalls.

This chapter is the last of the first part of this book. In the next five chapters, I’ll show you how you can hook into the .NET Remoting framework to intercept remote procedure calls or even implement your own transport protocols.