The use of Web services is very important in the next generation of integration between different applications. In this chapter, we have briefly looked at Web services. These services consist of many vendor- and platform-neutral parts, such as XML, SOAP, WSDL, and UDDI, that make Web services powerful for cross-platform interoperability. Even if Web services are really powerful for cross-platform communications and exposing functionality in existing legacy systems in a controlled and programmatic model, Web services should not be used everywhere. You must be aware that in certain scenarios Web services will cost you performance without giving you any benefits. As we mentioned, if you have an application on a single machine, Web services will not benefit the application. But even if the application today is running on a single machine, you should use an application framework that allows you to later change the application's objects to also act as Web services. By using the .NET Framework, the single-machine application can be converted easily into an application exposing Web services for other clients as well.
In this chapter, we have also discussed how to use the new WSE SDK from Microsoft. This is an implementation of the WS-Security, WS-Routing, and WS-Attachment specifications that the WS-I group has written.
Finally, we delved into .NET Remoting and compared .NET Remoting to Web services. Based on our experience, we suggest you use ASP.NET Web services by default. They are easier to implement because they are hosted by IIS and therefore include the security support of IIS. If you need a more traditionally distributed application and are certain that you will only use .NET everywhere, and no other system or user will ever try to access your application from any other platform not supporting the complete .NET Framework, then use .NET Remoting—it offers a more complete object model and more functionality around objects. If you are using a .NET Remoting client, opt for binary formatting, since it is the fastest choice. However, use the HTTPChannel integrated with ASP.NET/IIS to achieve the benefits of security and authentication; otherwise you have to code for those benefits by yourself.
So far, we have followed these guidelines ourselves, and have never had to create an application based totally on .NET Remoting. Instead, we have been even more inclined to stick to Web services, which we think is the first choice for most of the applications being created today—and will remain so tomorrow.