|
|
So far in this chapter we have mostly discussed Web services and how you can use them to tie different applications together. There is, however, another solution for letting remote objects talk with each other: .NET Remoting. .NET Remoting provides an infrastructure for distributed objects, similar to DCOM in old Windows DNA. .NET Remoting exposes the complete .NET Framework to remote objects using plumbing that is both flexible and extensible for the future. Simply speaking, the main differences between Web services a la SOAP and .NET Remoting are that the latter offers access to the complete .NET Framework, whereas Web services do not. By using .NET Remoting, you can pass objects by value or by reference, easily do callbacks, manage multiple object activation and life cycle policies, and more. We will explore .NET Remoting in more detail to make the differences clearer between .NET Remoting and Web services.
.NET Remoting is a way to allow objects to talk to each other from different processes. All kinds of distributed communication have two things in general: marshalling of data and objects to allow their distribution, and a description of what those messages look like. The former is achieved by using a marshaller; the latter is often achieved by using some kind of metadata. The serialization engine for DCOM interfaces is normally the type library marshaller, and the type library itself provides the metadata. The two areas where the Web services and .NET Remoting differ are how they serialize data into messages and the format they use for the metadata.
.NET Remoting relies on the .NET Framework. The .NET Framework contains an interface, IFormatter, that is used by System.Runtime.Serialization to marshal data to and from messages. You can use two formatters found in .NET Framework for serialization: System.Runtime.Serialization.Formatters.Binary.BinaryFormatter and System.Runtime.Serialization.Formatters.Soap.SoapFormatter. .NET Remoting normally uses the BinaryFormatter to format objects and so on into a binary stream, but .NET Remoting can also use the SOAPFormatter and protocols like HTTP.
But where is the metadata stored—and how? .NET Remoting relies on the common language runtime (CLR) assemblies, which contain all relevant information about the objects and data types found in the .NET Framework. By relying on these assemblies, .NET Remoting marshalling can include all of a class's private and public members, handle graphs correctly, and support all kinds of container types like hash tables and sorted lists. This is both the strength and weakness of .NET Remoting. By relying on the .NET Framework, the client using the .NET Remoting object also needs to have the .NET Framework installed to be able to marshal the object and its types back. In a homogenous internal network where you have total control of the configuration of remote clients, this may not be a huge problem. In situations where you do not have complete control (which is the more normal case), this can be a real problem.
| Note |
By using .NET Remoting, the client needs to understand the complete .NET Framework, since .NET Remoting is using the complete scope of data types and the like found in the .NET Framework. You will also have more administration of firewalls when using .NET Remoting than with Web services, since port 80 is normally open in a firewall. |
The Web services used in .NET rely on the System.XML.Serialization.XmlSerializer class to marshal data to and from SOAP messages at runtime. For metadata, Web services employ WSDL and XSD. Both of these rely on XML, which makes Web services better suited for situations where clients and servers are in different environments and where .NET Remoting cannot be used (for example, either the client-side or the server-side system does not have the .NET Framework installed). Since the metadata describes the content in a simpler way to allow Web service toolkits on different platforms and with different programming models to interact with each other, the type definition is not as rich as for .NET Remoting. In other words, the only data types that can be exposed via Web services are those that can be expressed in XSD. For instance, XMLSerializer will not marshal graphs, and it has limited support for container types such as sorted lists and so on.
Now that you have seen the main differences between .NET Remoting and Web services, the question is when to use .NET Remoting and when to use Web services. ASP.NET Web services favor the XML Schema type system and provides a simple programming model with broad cross-platform reach. .NET Remoting, on the other hand, favors the runtime type system and provides a more complex programming model with much more limited reach. Today you need to have the .NET Framework installed or use Intrinsyc's Ja.NET for Java. These differences are the primary factors in determining which technology to use; however, there are many more factors to consider that may force you to choose one of the technologies over the other. We will discuss the five main factors here that are based on the Microsoft's recommendations, which can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetarch16.asp.
The transportation of data back and forth between the client and the server can be done in several ways. The SOAP specification used in your Web services does not explicit say that the only transport protocol that can be used is HTTP or HTTPS. In real world it is, however, more or less a standard to use HTTP for transporting the information, because Web services are hosted by IIS, which only supports HTTP/HTTPS. Another great benefit of using HTTP as a transport protocol is that most firewalls are already configured to allow HTTP traffic on port 80 (the same port you use when surfing the Web). In a large enterprise, a lot of firewalls exist, and it would be a tremendous task for administrators to open up specific ports and set up security for a transport protocol that needs other ports.
You have two choices of transport protocols when using .NET Remoting: TCP or HTTP. The use of HTTP gives you the same benefits as it does for Web Services—there is no need to reconfigure existing firewalls. When using TCP, the firewall needs to be configured to allow traffic on the desired port. The benefit of using TCP over HTTP is that the former is slightly faster.
Hosting .NET Remoting objects in IIS and the ASP.NET worker process (aspnet_wp.exe, which is an ISAPI filter that executes ASP.NET requests) can be done by using the .NET Remoting HTTPChannel and integrating the .NET Remoting object into it. By hosting the .NET Remoting object in IIS, you can automatically start the object by simply requesting it via HTTPChannel; this is actually the only way to automatically start a .NET Remoting object remotely, because you do not have the Service Control Manager (SCM) that DCOM provides. When hosting your .NET Remoting object, you also automatically take advantage of the fact that the ASP.NET worker process is thread-safe, and that you can use the secure support found in IIS for cross-process .NET Remoting calls. This is much easier than coding your own security handling, formatters, and channels.
Advantage: Web services, because administration of firewalls likely does not need to be performed; normally you already allow HTTP traffic on port 80. .NET Remoting does have more flexibility in giving you a choice between TCP and HTTP, but the client needs to have the .NET Framework installed. When you would like to have security support, the use of IIS is a good choice regardless of whether you use Web services or .NET Remoting objects. We advise you to use IIS to avoid having to develop your own security handlers, formatters, and channels for your .NET Remoting object because it normally introduces too much complexity.
When you use IIS as host for your Web services and your .NET Remoting objects, you get full support for secure transport (in the form of HTTPS) and authentication. When a request comes into a Web service, the authentication is done before your actual Web service code is called. This means you do not have to make code changes when switching between different authentication methods. When you need to secure the content of your Web Service calls, you can use the WS-Security, which has functionality to encrypt the content.
.NET Remoting objects hosted by IIS will also be able to leverage full security functionality, but when you have .NET Remoting objects outside IIS and use the TCPChannel or HTTPChannel, you need to handle all the security by yourself.
Advantage: Web services, for the ease of its security functionality and because it is applied outside your Web services.
As you know, HTTP is by default stateless. Most of the Web applications created today are stateless (or developers at least try to keep them stateless) to reduce the resources bound on the server between each call from the user. Web services are therefore by default stateless. State management and its attendant problems are the same as for traditional Web applications. The state can be stored in a state server (which is preferred if you are going to use a Web farm), or directly in cookies.
With .NET Remoting, it is possible to choose what kind of state you want to have. Single call objects are stateless (just like your Web services are by default). Referring back to the Singleton pattern discussion in the section "Design Patterns and Layers" in Chapter 5, recall that Singleton objects share their state between all created Singleton objects and client-activated objects that manage state for the client (the same result as using a state server or storing the state in some other way for a Web service).
Advantage: .NET Remoting, because it takes care of handling the state for you automatically.
If you are looking at raw performance, .NET Remoting with binary formatting over TCPChannel is the faster option. However, in tests carried out to compare the relative performance of Web services and .NET Remoting, Web services outperformed .NET Remoting endpoints that used the SOAPFormatter with either HTTPChannel or TCPChannel. The performance of Web services and .NET Remoting using binary formatting and the HTTPChannel were very similar. Please note that if you are using .NET Remoting with marshal-by-reference objects, a Web service solution may outperform .NET Remoting! Why? Because a marshal-by-reference object in .NET Remoting calls the remote object for almost every call to the proxy object, and can give you long response times if the transport communication is slow. Web services, on the other hand, are more of a service provider, with one chunky call to get the requested data back. Always strive for chunky interfaces instead of chatty interfaces.
Advantage: .NET Remoting, if TCPChannel with binary formatting is used; otherwise the advantage goes to Web services, because of the improved performance and the option to scale out easily. For us, Web services has been our choice even if performance has been a customer criteria; the gain of the small performance boost by using .NET Remoting with TCPChannel and BinaryFormatter has not been worth the loss of simplicity and security support that we get using Web services. We must also make sure the client(s) has the .NET Framework installed to use .NET Remoting over TCPChannel, and this is not always possible.
Traditional two-phase commits are not supported by Web services by default; distributed transactions are expensive due to the communication for all involved transaction objects. However, the new WS-Transaction and WS-Coordination specifications give Web services support for some kinds of transactions (see the section "Web Services and Transactions" earlier in this chapter). When working with a single transaction towards one database, Web services can take advantage of local transaction support found in .NET Enterprise Services.
If you build your solution based on Web services, all systems (.NET based or otherwise—does not matter as long as they can use SOAP) can access your business logic. This way you have the opportunity to reuse business logic anywhere in a large enterprise, without a recompile or rewrite of the code. This saves you money and time.
|
|