Overview
Traditionally, distributed application design called for the use of component technologies such as DCOM or CORBA. Although these component technologies work very well within an intranet environment, using them over the Internet often presented two serious problems:
- Current component technologies do not inter-operate. While they all dealt with components and objects, they differed over lifecycle management, constructor details, degree of support for inheritance and so on.
- Current component technologies focus on RPC-style communication. This led to tightly coupled systems built around the invocation of object methods.
Browser-based web applications are loosely coupled and are remarkably inter-operable. They communicate using HTTP to exchange MIME-typed data in a wide range of formats. Web Services adapt the traditional web programming mode for use from all sorts of applications, not just from a browser. Web Services exchange SOAP message using HTTP and other Internet Protocols. And because Web Services rely on industry standards like HTTP, SOAP, and XML to expose application functionality, they are independent of programming language, platform and device. The only requirement for a Web Service to communicate with a client is to agree on the format of the SOAP messages being produced and consumed, as defined in the Web Service's contract definition, commonly known as WSDL.
.NET Remoting provides an infrastructure for distributed objects. It exposes the full-object semantics of .NET to processes using plumbing that is very flexible and extensible. Compared to Web Services which provide a very simple programming model based on passing messages, the .NET Remoting offers much more complex functionality including passing objects around (by-value or by-reference), callbacks, and multiple object invocation and lifecycle management.
In order to use .NET Remoting, the client must be aware of all the above details. In short, the client needs to be built with .NET or with a framework that supports .NET. Not that even .NET Remoting supports SOAP, this does not change the client requirements. If a remoting endpoint exposes .NET object semantics, via SOAP or not, the client must understand them.
The fact that the .NET Framework allows you to easily build Web Services or .NET Remoting applications has caused confusion. Which technology do you use? To really answer this question, you have to understand how both technologies work.
Serialization & Metadata
All distributed communication plumbing, .NET Remoting or Web Services, eventually does two things:
- Marshal instances of programmatic data types into messages that can be sent across the network via data packets. This is usually accomplished via some serialization of marshalling engine.
- Provide a description of what those messages look like. This is usually accomplished through some form of metadata. In the case of COM/DCOM, the serialization engine was the Type Library Marshaler, and the metadata was provided by the type library.
The key difference between ASP.NET Web Services and .NET Remoting is how they serialize data into messages, and the format they choose for metadata. Serialization and metadata for Web Services and .NET Remoting are discussed below.
ASP.NET Web Services: XmlSerializer and XSD
As the title suggests, for Web Services, XmlSerializer is the 'serialization engine' and XSD is the metadata. ASP.NET Web Services rely on theSystem.Xml.Serialization.XmlSerializer class to marshal data to and from SOAP messages at runtime. For metadata, ASP.NET Web Services generate WSDL and XSD definitions that describe that their messages contain.
The reliance of ASP.NET Web Services on WSDL and XSD makes their metadata portable because they express data structures in a way that other Web Services on other platforms and with different programming languages can understand. Note however, that XmlSerializer will only marshal things that can be described by XSD -XmlSerializer will not marshal object graphs and has limited support for container types.
Support for interoperability is augmented by a rich set of custom attributes that allow you to annotate your data types to control the way in which the XmlSerializermarshals them. As a result, you have a fine-grained control over the shape of the XML being generated when an object is serialized.
.NET Remoting: IFormatter and the CLR.
As the title suggests, for .NET Remoting, IFormatter is the 'serialization engine' and the Common Language Runtime (CLR) is the metadata. .NET Remoting depends on the pluggable implementations of the IFormatter interface to marshal data to and from messages. The .NET Framework offers two built-in formatters:System.Runtime.Serialization.Formatters.Binary.BinaryFormatter andSystem.Runtime.Serialization.Formatters.Soap.SoapFormatter. As the names suggest, the BinaryFormatter and the SoapFormatter marshal data types in binary and SOAP formats, respectively. Note that irrespective of the data format, .NET Remoting can send data over either HTTP or TCP channels.
As for metadata, the .NET Runtime relies on the CLR assemblies which contain all the relevant information about the data types they implement, and expose via reflection. The reliance on the assemblies for metadata makes it very easy to preserve the full runtime type-system fidelity. As a result, when the .NET Remoting marshals data, it includes all of a class's public and private members, handles object graphs correctly, and supports all container types (ArrayList, HashTable, etc.) However, the reliance on the runtime metadata also limits the reach of a .NET Remoting system - the client must also be able to understand .NET constructs in order to be able to communicate with a .NET end point.
.NET Remoting and ASP.NET Web Services
.NET Remoting supports two channels, one for raw TCP and another for HTTP. And as noted in the previous section, .NET Remoting also has a built-in SOAP formatter (in addition to the binary one) . So, can .NET Remoting be used to build Web Services?
The standard Web Service technology stack relies not only on SOAP messages, but also on WSDL and XSD-based description of those SOAP messages. .NET Remoting plumbing can actually generate WSDL that describe messages consumed and produced by endpoints, but there are a couple of issues including the fact that the generated WSDL files will include extensions that are .NET Remoting-specific. For example, if a .NET Remoting endpoint (i.e., a remote function) returns a DataSet, then the generated WSDL for this method will also contain a reference to DataSet. For some Web Services that do not find an XSD-schema definition for a DataSet, this WSDL will be useless.
So the answer to whether you can use .NET Remoting to build Web Services is yes and no. You can build Web Services with .NET Remoting but whether anybody who is not using the .NET Remoting will be able to use them will depend if you are able to describe your end point to bare data types and semantics. And if you want inter-operability with other Web Service toolkits, you will need to restrict parameters to the simple built-in types and your own data types (don't use .NET Framework types), and avoid client-activated objects and events. In short, if you care about reach, you need to restrict yourself to the same set of functionality that ASP.NET Web Services use. Better yet, why not use ASP.NET Web Services?
Distributed Application Design
ASP.NET Web Services favor the XML Schema type system, and provide a simple programming model with broad cross-platform reach. .NET Runtime favors the runtime type system, and provides a more complex programming model with a limited reach. This essential difference is the primary factor in determining which technology to use.
However, there are a wide range of other design factors, including transport protocol, host processes, security, performance, state management and support for transactions as well. These concepts are discussed below.
Transport Protocols & Host Processes
Although the SOAP specification does not mandate the use of HTTP as the transfer protocol, a client can access Web Services implemented in ASP.NET only using HTTP as the transport protocol. HTTP is the only transport protocol that ASP.NET supports. The services are invoked via IIS and execute in the ASP.NET worker process -aspnet_wp.exe.
.NET Remoting on the other hand, allows you to host remote objects in any type of application including Windows Forms, Windows Services, Console applications, or even IIS. And as previously noted, .NET Remoting supports two transport channels - HTTP and TCP. The following summarizes these points:
| Technology | Transport Protocols | Host Processes |
| ASP.NET Web Services | HTTP only | IIS only (aspnet_wp.exe) |
| .NET Remoting | HTTP and TCP | IIS, Windows Forms, Windows Services, and console apps. |
Note that the .NET Remoting plumbing does not include a DCOM-style Service Control Manager (SCM) to start remote servers. If you expose remote objects from some process, you must ensure that that process is running before it can server any remote objects. You also have to ensure that they are thread-safe - i.e., thread A cannot create an object after thread B has started to shut down the process. If you expose remote objects from ASP.NET (i.e., remote objects are deployed in IIS), you can take advantage of the fact that the ASP.NET worker process, aspnet_wp.exe is both auto-starting and thread safe. Deploying objects in IIS is also an excellent way to secure a cross-process .NET Remoting call.
Both ASP.NET and .NET Remoting are extensible architectures. You can filter inbound and outbound messages, control aspects of type marshalling, and metadata generation.
Security
Because ASP.NET Web Services rely on HTTP, they integrate well with the standard internet security architecture. ASP.NET uses the security features of IIS to provided strong support for standard HTTP authentication, authorization such as Basic, digest, digital certificates, and even MS Passport. However, even though these standard transport-level techniques to secure Web Services are quite effective, they only go so far. In complex scenarios involving multiple Web Services in different trust domain, you will need to use ad-hoc solutions. Work is currently in-progress on a set of security specification that build on the extensibility of SOAP messages to offer message-level security capabilities.
In the general case, .NET Remoting does not secure cross-process calls. However, a .NET Remoting endpoint deployed in IIS can use the security features of IIS quite easily, including the use of SSL for secure communication across the wire. However, note that if you are using a TCP or HTTP channel in a process outside IIS, then you will need to implement your own authorization and authentication mechanisms. The following table summarizes these points:
| Technology | Security |
| ASP.NET Web Services | Uses the security features of IIS by default |
| .NET Remoting | Cross-process calls are not secured. Will use the security features of IIS only if deployed in IIS. |
State Management
The ASP.NET Web Services model assumes a stateless service architecture by default. It does not inherently relate multiple calls from the same user. Each time a client makes a call to a Web Service page, a new object is created to service the request. The object is destroyed after the method call is complete. To maintain state across calls, you can either use the Application and Session objects, or you can implement your own custom solution.
.NET Remoting supports a wide range of state management options and may or may not correlate multiple calls from the same user depending on what type of object you choose. For example, Server-Activated Objects (SAO) do not correlate calls from the same user: Singleton objects share state for all users, and SingleCall Objects are stateless. Client-Activated Objects (CAO) however, do correlate calls from the same user and they maintain state per client. The following table summarizes these points:
| Technology | State Management |
| ASP.NET Web Services | Stateless by default. State can be managed using standard ASP.NET objects or a custom solution |
| .NET Remoting | Different management options depending on the type of the remote object. |
Performance
In terms of raw performance, the .NET Remoting provides the fastest communication when using the TCP channel with the binary formatter. Tests have shown that ASP.NET Web Services outperform .NET Remoting for endpoints that used the SOAP formatter with either the HTTP or TCP channel.
Choosing an Architecture
You will need to consider all of the issues discussed here before you start designing a distributed application built on .NET. Here are some general assumptions you can make that will simplify the process of choosing between ASP.NET Web Services and .NET Remoting:
- By default, use ASP.NET Web Services. They are simpler to implement and use, and offer the broadest reach to clients.
- Consider .NET Remoting if you need a more traditional distributed object model with full CLR type fidelity, don't need interoperability with other platforms, and have control over client and server configurations.
- If you choose .NET Remoting, prefer the HTTP channel registered with IIS and ASP.NET. Otherwise, you will have to build your own process lifecycle management and security infrastructure.
- Given that .NET Remoting requires .NET client, it makes sense to use the binary formatter instead.
- Use Enterprise Services when you need declarative transactions.
Posts
2 comments:
But Free Soft ware only Preferable practice Purpose Only
Thank Q For Your valuable Sugission
Post a Comment