XML Web services are more restricted than objects exposed over .NET Remoting.
XML Web services support open standards that target cross-platform use.
XML Web services are generally easier to create and due to the restricted nature of XML Web services, the design issues are simplified.
XML Web services support only SOAP message formatting, which uses larger XML text messages.
Communication with .NET Remoting can be faster than XML Web service communication with a binary formatter.
XML Web services are designed for use between companies and organizations.
XML Web services don't require a dedicated hosting program because they are always hosted by ASP.NET.
Consumers can use XML Web services just as easily as they can download HTML pages from the Internet. Thus there's no need for an administrator to open additional ports on a firewall as they work through MS-IIS and ASP.NET
Both .Net Web services and .Net Remoting are Microsoft solutions for distributed application. Before choosing one of them for application development, let's identify the differences between these technologies.
.Net web services can be accessed only over HTTP whereas .Net remoting can be accessed over any protocol including TCP, HTTP, or SMTP.
In terms of performance, .Net remoting is faster than its counterpart web service when it uses TCP channel with binary formatter. But if you use soap formatter in .net remoting, web services with soap formatter either with TCP or HTTP channel provides faster solution.
.NET Remoting can be hosted either in IIS or in other container. If hosted in IIS, .NET Remoting can benefit all security advantages of IIS. But when hosted other than IIS, the application has to take care security aspect itself.
On the other hand, .Net web services are hosted in IIS, by default. So, it leverages all features of security provided by IIS.
Web services are a stateless in nature like web application. You need to use state mechanism to retain state. You can use session or application object to maintain state. In .Net Remoting, Singleton objects can share state whereas if you don't need to maintain state, you can use Singlecall objects.
Web services support heterogeneous environments which means client and remote object can be built in any platform.
.NET remoting requires the client be built using .NET, enforcing homogenous environment.
Since .Net web services are hosted using IIS, they are reliable whereas .Net remoting application needs to maintain security on its own if not hosted using IIS. When hosted in IIS, .Net remoting is also as reliable as web services.
Ease of development
Create and consuming .Net web services are easier process. To create remoting object, you need create remote object, hosting application to host remoting object and configuration file to specify type of channel and formatter to be used by remoting object.
.Net web services are built on XML-based standards for exchanging data. This means .NET web services can support only those data types that can be recognized by the XML schema standard. There are many proprietary .Net objects such as FileSteam, Eventlog etc. are not supported in the web services. These data types are .Net specific types that are not universally recognized, i.e. .Net specific only.
You can even exchange custom objects using .Net web services. The only limitation is that only public data members are transmitted, and all public members and properties must use one of the other supported data types.
You can use DataSet and DataTable to return information from database but can't use other ADO.NET objects such as DataColumns and DataRows.
.Net offers a distributed technology called .Net remoting that can plays around wide range of .Net specific data type. But unfortunately, .Net remoting doesn't support client other than .Net.
Testing a Web Service
.NET has a test web page that ASP.NET uses automatically when you request the URL of an .asmx file in a browser. This page uses reflection to read and show information about the web services, such as the names of the methods it provides.
Consuming a Web Service
Web services are built on XML standard. So, a client needs to equip itself to understand XML-based message in order to exchange messages. The .Net framework provides proxy component that enable clients to interact with web services. The proxy has all necessary information that can be utilized by the client application to share data with web services.
The proxy class wraps the calls to the web service's methods. It generates SOAP message format and manages the transmission of the messages over the network (using HTTP). When it receives the response message, it converts the results back to the corresponding .NET data types.
You can create a proxy class in .NET in two ways:
By using wsdl.exe command-line tool
By using Visual Studio web reference feature
DISCO, an abbreviation of discovery, is a file that groups together a list of related web services. A company that offers web services publishes a DISCO file on its server that has links of all the web services it provides. The client requests this file to see all the available web services. This standard is useful when client already know about a company that offers web services. You can also use DISCO standard while working in local network. It is not helpful to find all web services over the internet.
UDDI (Universal Description, Discovery, and Integration) offers centralized directory for web services over the internet. It hosts web services from different companies and can be used by the clients to find web services of their specific need. To make web services shared publicly, they have to be published in UDDI.
Following are the standards used by web services:
WSDL is used to create interface definition for a web services. It describes all about methods to the client, i.e. methods available in a web service, their parameters and return values.
SOAP, Simple Object Access Protocol is a communication protocol, a way to structure data, based on XML. The web services use SOAP message format to encode information before sending.
The SOAP message format in web services uses HTTP as communication protocol, i.e. SOAP messages are sent over HTTP channels.
It is used to create discovery documents that provide links to multiple web service endpoints. The DISCO standard creates a single file that groups a list of related web services. A company can publish a DISCO file on its server that contains links to all the web services it provides.
A standard for creating business registries that catalog companies, the web services they provide, and the corresponding URLs for their WSDL contracts.
Web Services are supported on a wide range of platforms.
Web services may extend its interface and add new methods without affecting the clients as long as they still provide the old methods and parameters.
A client makes a request to a web service, the web service returns the result, and the connection is closed. There is no permanent connection. This makes it easy to scale up and support many clients at a time.
Firewalls can pose a challenge for distributed object technologies. The only thing that almost always gets through firewalls is HTTP traffic on ports 80 and 443. Because web services use HTTP, they can pass through firewalls without explicit configuration.
Web services use HTTP protocol for sending and receiving messages between the applications.
The data encoding in web services is based on XML.
Web services are defined using WSDL (Web Services Description Language).
Web services are discovered using UDDI (Universal Description, Discovery and Integration).
Web services are firewalls friendly.
Web services supports interoperability i.e. cross platform integration is possible.
CORBA and DCOM
These technologies use non-standard protocol, i.e. CORBA uses IIOP (Inter Internet Object Protocol), and DCOM uses RPC (Remote Procedure Calls)
CORBA components are defined using CORBA Interface Description Language; DCOM components are defined using Microsoft Interface definition languages
CORBA components are discovered using the CORBA registry, DCOM using the Registry.
DCOM is a proprietary protocol that does not support interoperability and has firewall problems as DCOM transfers data in binary format and it uses many ports to call remote functions.
CORBA uses the IIOP protocol, which is non-Internet friendly.
CORBA and DCOM are fine for building enterprise applications that runs on the same platform and not good enough for applications that span platforms and languages.
The key benefit of having distributed components is that they spread out the load over different machines.
The components can be upgraded without disturbing the clients' code.
The distributed application improves security. For example, a company who has many agents wouldn't like those agents to have direct access to its database. Instead, these agents can be granted access to the components running on the corporate server which can be controlled and restricted.
The need of distributed technologies arises with the requirement of distributed computing applications. The distributed computing allows partitioning of application logic into units and spreading the unit over different computers of a network or across different networks. This helps in spreading out loads over many computers. The components once developed can be reuse by other applications. There are many technologies developed to allow the distribution and reuse of application logic.