Web Services (Middleware)---a Technical Reference Guide for Designing Mission-Critical Middleware Solutions

Want more guides like this one? Go to Technical Reference Guides for Designing Mission-Critical Solutions.

Web services have become pervasive in the enterprise and consumer space for exchanging messages between applications. The primary Microsoft technology for building web services is WCF. However, many systems in production today still use ASP.NET/ASMX. Web services enjoys major vendor support, but differing vendor implementations, security requirements, and the ever increasing complexity of the WS-I profiles, can lead to extremely complex issues. RESTful services are very different from traditional WS-I web services, and deal explicitly with the HTTP protocol. Both WS-I and REST have benefits and liabilities that the developer or architect must be able to reconcile.

Best Practices



  • Always prefer IIS/WAS to self-hosting, including Windows/NT Service hosting.

  • Use, or upgrade to, Server AppFabric whenever possible to take advantage of hosting, monitoring, and caching capabilities.

  • Define your policies for integrity and privacy early, and choose between transport security and message security, or a combination of the two. Scenarios, considerations, and how-to's can be found in the WCF Security Guidelines.

  • Work out PKI requirements up front, and do not underestimate the time required to get it working: How To - Create and Install Temporary Client Certificates in WCF During Development

Management and Administration


  • When using WCF, prefer Per-Call instancing and durable services for ease of scale out.

  • Disable Keep-Alives on WCF to help prevent server/ip/session affinity and understand High Availability Configuration scenarios.

  • Prefer transport transfer security to message security for performance, but understand transport security limitations when traversing intermediaries. Refer to the WCF Security Guidelines.

  • For WCF, understand binding and channel choices and their trade-offs between performance and interoperability.

  • Whenever possible, use WCF bindings that guarantee maximum performance (NetTcpBinding, NetNamedPipeBinding, and so on).

Case Studies and References

Examples of successful architectures are described in the following case studies and white papers:

Questions and Considerations

This section provides questions and issues to consider when working with your customers.


  • Understand consumers, producers, and interoperability goals with respect to respective client and server stacks.

  • What is your versioning policy? What are the potential breaking changes your consumers might encounter?

  • Consider exception and fault management in your design, and do not confuse the two. Unhandled exceptions will flow to the caller, and under some conditions will fault the channel.

  • Services are not remotable objects; prefer coarsely grained message-oriented contracts to finely grained RPC-oriented contracts.

  • Recognize that the specs are flexible, and that just because svcutil cannot generate a proxy from a particular WSDL does not mean a system is somehow violating a spec.

  • Understand when an intermediary-based approach or a discovery-based approach is more appropriate for your topology, and when to mix them. In general, an intermediary-based approach is more controlled, and a discovery-based approach is more flexible. They can be mixed of course, but be aware of what those choices mean.

  • REST tooling is still maturing and it is easier to work with WS-style web services today than REST-style web services.

  • What identity will your service run as?

  • What kind of security will your service adopt? Transport or Message Security? Are you going to implement a claims architecture based on Windows Identity Foundation (WIF)?

  • What are your authentications and authorization polices and those of the producers you will consume and are there traditional trusts between your clients and services?

  • Do your services require integrity and privacy?

  • Do your services need to be transactional (WS-Transactions) and\or reliable (WS-ReliableMessaging)?

  • Do your services need to virtualize your web service endpoints?

  • Do your services need content-based routing and protocol bridging capabilities?


  • What ports will your service require to serve requests?

  • What protocols/channels will your service require (for example, HTTP, TCP/IP, IPC, and MSMQ)?

  • Will consumers of your service obtain metadata programmatically or out-of-band?

  • Does your service require support for distributed transactions, or will it participate in a distributed transaction?

  • What kind of monitoring, maintenance, quality of service (QoS ), and SOA governance functionality does your web services platform need to provide?

Management and Administration

  • How will you know if the service is down?

  • How will your consumers learn about service exceptions or errors?

  • Who will be responsible for making configuration changes to your service, and how will those changes be made?


  • Is your service designed for scale-up or scale-out?

  • What is the message volume your service is expected to be able to process today, and at what rate will it grow?

  • What resources are good candidates for caching?


< Full URLS for Hyperlinked Text>