Best Practices for WCF

The general best practice for WCF services would be to have the per-call, single-instance model whenever possible. This gives you the best throughput, the best and simplest behavior in the service instance. So whenever possible, and unless you have a really compelling reason, use this model. Always try to make the actual service instance very lean and lightweight so it can be created and disposed of in a blink of an eye (or less), and then have some background worker processes which you can then call from your actual service instances.
 
But of lately SOA has been a buzz word. That's been a big question surrounding services since their inception. SOA done successfully is SOA planned to the extent you're talking about. Having said that, I've always leaned more toward splitting services out, but using them in a composite manner. That is, several endpoints when you have several contracts, but most of them are only consumed by a few endpoints that are consumed by non-service callers.

Also, I would advise to have as few contracts as possible. Too many contracts can lead to poor manageability. Good contract design will help limit the number of endpoints and service calls. Removing OO concepts from contract design is one way of doing so. Contract design is a massive topic in itself, but suffice it to say that through good contract planning (up front), comes good service design.

Maarten Mullender writes a great blog on WCF design, and is a must read. There are also some great SOA/WCF books emerging as well. Some good books:

• Pro WCF: Practical Microsoft SOA Implementation
• Programming WCF

This has been helpful to me it comes from the idesign.net website and it was authored by Juval Lowy: WCF Coding Standard

For more comprehensive details refer to MSDN: Guidelines and Best Practices in WCF.
Also for security point of view refer to MSDN: Best Practives for Security in WCF.

Do keep sharing any new updates in this regard.

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. For Best Practices in WCF read my another post on the topic. For difference between various types of bindings in WCF read this post.

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!

Comparison of performance between WCF and Web-Services

WCF is 25%—50% faster than ASP.NET Web Services, and approximately 25% faster than .NET Remoting. The following figure would give a clear picture. It's comparison between the two over the throughput time taken for message. The message objects are taken of three samples i.e. 1 , 10 and 100 objects per message. Over here we clearly see that WCF is fast and perform better than Web-Services and thus WCF wins the battle WCF vs Web Services.

Migrating ASP.NET Web Services to WCF

Migration is a key issue in existing applications and many a times we get confused as to what to do and how to in migration related tasks. Some of the key points of the MSDN migration article are as follows:

WCF has several important advantages relative to ASP.NET Web services. While ASP.NET Web services tools are solely for building Web services, WCF provides tools that can be used when software entities must be made to communicate with one another. This will reduce the number of technologies that developers are required to know in order to accommodate different software communication scenarios, which in turn will reduce the cost of software development resources, as well as the time to complete software development projects.

Even for Web service development projects, WCF supports more Web service protocols than ASP.NET Web services support. These additional protocols provide for more sophisticated solutions involving, amongst other things, reliable sessions and transactions.

WCF supports more protocols for transporting messages than ASP.NET Web services. ASP.NET Web services only support sending messages by using the Hypertext Transfer Protocol (HTTP). WCF supports sending messages by using HTTP, as well as the Transmission Control Protocol (TCP), named pipes, and Microsoft Message Queuing (MSMQ). More important, WCF can be extended to support additional transport protocols. Therefore, software developed using WCF can be adapted to work together with a wider variety of other software, thereby increasing the potential return on the investment.

WCF provides much richer facilities for deploying and managing applications than ASP.NET Web services provides. In addition to a configuration system, which ASP.NET also has, WCF offers a configuration editor, activity tracing from senders to receivers and back through any number of intermediaries, a trace viewer, message logging, a vast number of performance counters, and support for Windows Management Instrumentation.

Given these potential benefits of WCF relative to ASP.NET Web services, if you are using, or are considering using ASP.NET Web services you have several options:

• Continue to use ASP.NET Web services, and forego the benefits proffered by WCF.
  
• Keep using ASP.NET Web services with the intention of adopting WCF at some time in the future. The topics in this section explain how to maximize the prospects for being able to use new ASP.NET Web service applications together with future WCF applications. The topics in this section also explain how to build new ASP.NET Web services so as to make it easier to migrate them to WCF. However, if securing the services is important, or reliability or transaction assurances are required, or if custom management facilities will have to be constructed, then it is a better option to adopt WCF. WCF is designed for precisely such scenarios.
  
• Adopt WCF for new development, while continuing to maintain your existing ASP.NET Web service applications. This choice is very likely the optimal one. It yields the benefits of WCF, while sparing the cost of modifying the existing applications to use it. In this scenario, new WCF applications can co-exist with existing ASP.NET applications. New WCF applications will be able to use existing ASP.NET Web services, and WCF can be used to program new operational capabilities into existing ASP.NET applications by virtue of WCF ASP.NET compatibility mode.
  
• Adopt WCF and migrate existing ASP.NET Web service applications to WCF. You may choose this option to enhance the existing applications with features provided by WCF, or to reproduce the functionality of existing ASP.NET Web services within new, more powerful WCF applications.

Description of Bindings in WCF

System-provided bindings are used to specify the transport protocols, encoding, and security details required for clients and services to communicate with each other. The system-provided WCF bindings are listed in the table. More details on the bindings can be found in the WCF documentation. WCF also allows you to define your own custom bindings.

Bindings	Descriptions
BasicHttpBinding	A binding that is suitable for communication with WS-Basic Profile conformant Web Services like ASMX-based services. This binding uses HTTP as the transport and Text/XML as the message encoding.
WSHttpBinding	A secure and interoperable binding that is suitable for non-duplex service contracts.
WSDualHttpBinding	A secure and interoperable binding that is suitable for duplex service contracts or communication through SOAP intermediaries.
WSFederationHttpBinding	A secure and interoperable binding that supports the WS-Federation protocol, enabling organizations that are in a federation to efficiently authenticate and authorize users.
NetTcpBinding	A secure and optimized binding suitable for cross-machine communication between WCF applications
NetNamedPipeBinding	A secure, reliable, optimized binding that is suitable for on-machine communication between WCF applications.
NetMsmqBinding	A queued binding that is suitable for cross-machine communication between WCF applications.
NetPeerTcpBinding	A binding that enables secure, multi-machine communication.
MsmqIntegrationBinding	A binding that is suitable for cross-machine communication between a WCF application and existing MSMQ applications.

Tutorials

For more on how to create a WCF service refer the following:

On how to host WCF service on IIS refer the following:

More Study...

For more study on WCF there's the MSDN WCF Developer Center which has everything from beginner's tutorials to articles and sample code. For further reading on WCF refer to MSDN article on WCF in .net 4.0

The standards supported by ASP.NET Web services are documented in XML Web Services Created Using ASP.NET. The more extensive list of standards supported by WCF are listed at Web Services Protocols Supported by System-Provided Interoperability Bindings.

For difference between various type of bindings in WCF read my another post.

For cloud computing and Microsoft Technologies refer my Cloud Computing and .Net article.

For parallel computing and .net refer my Parallel Computing and .Net article.

For more detailed performance comparison refer to this MSDN article.

If you are considering for migration from Web Services to WCF refer to this MSDN article. Also to avoid migration in future of Asp.Net application refer to this MSDN article.

Also read this very informative MSDN article explaining in details the differences regarding development of web-services and WCF.


Do keep me updated with your views and suggestions on the article....