Wednesday 20 July 2011

Difference between web services and WCF

These days all the projects that are upgrading from .net 2.0 to .net 3.5 or to .net 4.0 are facing the issue of choosing between web-services and WCF (Windows Communication Foundation). In this post I am going to discuss the difference between them and look at points which would make clear what to choose and throw light to web-service vs WCF issue. .

WCF Definition

WCF is a part of the .NET Framework that provides a unified programming model for rapidly building service-oriented applications that communicate across the web and the enterprise.

The following figure shows the features that the WCF provides compared to other technology in .net:

ASP.NET Web services was developed for building applications that send and receive messages by using the Simple Object Access Protocol (SOAP) over HTTP. The structure of the messages can be defined using an XML Schema, and a tool is provided to facilitate serializing the messages to and from .NET Framework objects. The technology can automatically generate metadata to describe Web services in the Web Services Description Language (WSDL), and a second tool is provided for generating clients for Web services from the WSDL.

WCF is for enabling .NET Framework applications to exchange messages with other software entities. SOAP is used by default, but the messages can be in any format, and conveyed by using any transport protocol. The structure of the messages can be defined using an XML Schema, and there are various options for serializing the messages to and from .NET Framework objects. WCF can automatically generate metadata to describe applications built using the technology in WSDL, and it also provides a tool for generating clients for those applications from the WSDL.

There are different points to consider for WCF:
1.    WCF is architecturally more robust and promotes best practices.
2.    If you know what you are doing its "silky smooth" if not you are in for a ride.
3.    Do you have enough time to complete the conversion of your services?
Two further aspects:
1) No matter how you decide this for the server-side, you can easily consume Webservices and WCF Services using only WCF on the client-side. This is of value, if you consume multiple services with a single client.
2) If you consider Cloud Computing: It is possible to host WCF Services on Windows Azure.

Finally I would say that, if you have the time, the bling and the muscle to do the upgrade. Its worth it. If asmx is satisfying all the needs, you may persist with web services.

ASMX is great and simple - but it's very limited in many ways:
·         you can only host your web services in IIS
·         you can only reach your web services over HTTP
·         security is very limited

WCF remedies this - and offer much more beyond that. You can host your WCF services in IIS - or self-host in a console app or Win NT Service, as need be. You can connect your WCF services using HTTP, TCP/IP, MSMQ, Peer-to-peer protocols, named pipes for on-machine communications and much more.
I'd definitely recommend you go with WCF. It's a tad more complex than ASMX, but it also offer just sooo much more capabilities and choices!

Major difference between the two is that Web Services use XmlSerializer but WCF uses DataContractSerializer which is better in performance as compared to XmlSerializer. Some key issues with XmlSerializer to serialize .NET types to XML are:
* Only Public fields or Properties of .NET types can be translated into XML.
* Only the classes which implement IEnumerable interface.
* Classes that implement the IDictionary interface, such as Hash table can not be serialized.

Important difference between DataContractSerializer and XMLSerializer:
* A practical benefit of the design of the DataContractSerializer is better performance over Xmlserializer.
* XML Serialization does not indicate the which fields or properties of the type are serialized into XML where as DataCotratSerializer Explicitly shows the which fields or properties are serialized into XML.
* The DataContractSerializer can translate the HashTable into XML.
Quick benefits of WCF over Web-Services (ASMX):
1) For internal (behind firewall) service-to-service calls we use the net:tcp binding, which is much faster than SOAP
2) We enabled both a net:tcp endpoint and a "web" endpoint on the same service with only a configuration file update (no code changes)
3) We were able to create AJAX-supporting RESTful web services with only configuration changes and using the DataContractJsonSerializer that's already built in. To do this otherwise, we would have had to write an HTTP Handler (ashx) and handle most of the Json serialization and url parsing by hand.
4) As our site needs to scale for performance optimization and stability, we are looking at converting to using an MSMQ-based messaging structure that is asynchronous AND guaranteed and participates in transactions; WCF provides an MSMQ bindng that requires little-to-no code change in our services--just reference updates and setting up MSMQ properly with the existing services (and adding attributes for Transactional boundaries).

BUT BE WARNED: Really invest in learning this. There are things like argument-name-changes during development that actually don't break the service references but result in null arguments being passed (built-in version skew handling), hosting models to consider (Windows Service vs. IIS), and instantiation models and FaultExceptions to all REALLY understand. We didn't going in and we had some pains. But we plowed ahead and are VERY happy with our learnings and the flexibility and growth opportunities we have not being tied to ASMX anymore!

Tuesday 12 July 2011

wcf for beginners

The WCF Service

The WCF Interface you expose can not be particularly complex if you want to use the Service Moniker – I’ve found it best to keep top primitive types, and arrays of primitive types.  Data Contracts seem to be a no-go.
Start by creating a new WCF Service using File|New|Project and selecting WCF Service Library:
Double-click on IService1.cs in the Solution Explorer, and replace the default contents with this simple interface:
using System;
using System.ServiceModel;

namespace WcfService1
    public interface IService1
        string GetData(int value);

        object[] GetSomeObjects();
Next replace the contents of the service implementation, Service1.cs, with the following:
using System;

namespace WcfService1
    public class Service1 : IService1
        public string GetData(int value)
            return string.Format("You entered: {0}", value);

        public object[] GetSomeObjects()
            return new object[] { "String", 123, 44.55, DateTime.Now };

Configuring the WCF Service

By default the WCF Service is configured to use HTTP as the transport protocol.  I generally switch it to use TCP, because I am operating within a corporate intranet, and HTTP seems like overkill.
You’ll also find that by default your WCF Service exposes two endpoints.  The first exposes as you’d expect, the IService1 interface you defined above.  The second exposes Metadata about your service, which the Service Moniker uses to know what operations are available on your service.  You’ll need both.
Right-click on the App.config file in the Solution Explorer, and select Edit WCF Configuration:
Switch the first endpoint to use TCP:
Also change the second to use mexTcpBinding:
Change the base address that the service will use, to use a TCP address instead of a HTTP Address by selecting the Host node on the left hand tree, and then selecting the base address and clicking on Edit, and changing the text to be net.tcp://localhost:7891/Test/WcfService1/Service1/
Finally, because you are using TCP instead of HTTP, change the MetataData service to not expect to expose the metadata via HTTP, by changing HttpGetEnabled to False under Advanced|Service Behaviours…
Save the changes and exit the WCF Editor.  Your App.config should look like this:
<?xml version="1.0" encoding="utf-8" ?>
    <compilation debug="true" />
      <service behaviorConfiguration="WcfService1.Service1Behavior"
        <endpoint address="" binding="netTcpBinding" bindingConfiguration=""
            <dns value="localhost" />
        <endpoint address="mex" binding="mexTcpBinding" bindingConfiguration=""
          contract="IMetadataExchange" />
            <add baseAddress="net.tcp://localhost:7891/Test/WcfService1/Service1/" />
        <behavior name="WcfService1.Service1Behavior">
          <serviceMetadata httpGetEnabled="False"/>
          <serviceDebug includeExceptionDetailInFaults="False" />
To start running your service you can hit Ctrl-F5 in Visual Studio.  This will start a test service host, and a test client.  We will ignore the client, but you can check that the service host has started by clicking on the message in the notification area:
Eventually you’ll want to host your service somewhere else, such as a Windows Service.