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
Development
Many customers still use ASMX. Understand Migration and Interoperabilty scenarios and guidance.
Where interoperability is a goal, choose the simplest common denominator between client and service (often BasicHttpBinding or REST). Where best possible performance is a goal, optimize via channel and encoding options supported by WCF. See WS Support with WCF and WCF Interoperability Guidance.
Channel faulting behavior in WCF depends on the binding, or more precisely, whether a transport session is in use when the unexpected error occurs. Never reuse a proxy after handling a fault, even though a non-session based transport such as HTTP will allow it.
Define a Versioning Policy early that addresses contract, address, and binding changes, and understand the potential for breaking and non-breaking changes.
- Do not use IDisposable when working with WCF proxies: http://geekswithblogs.net/DavidBarrett/archive/2007/11/22/117058.aspx and http://geekswithblogs.net/bcaraway/archive/2008/07/06/123622.aspx
Understand the various serialization methods and their effects: https://msdn.microsoft.com/en-us/library/ms731073.aspx. Also understand the closely related choice of DataContract vs. MessageContract: https://msdn.microsoft.com/en-us/library/ms731073.aspx, https://msdn.microsoft.com/en-us/library/ms730255.aspx
The WCF 4.0 Routing Service and Discovery features can help tremendously in developing an agile SOA. See also: https://msdn.microsoft.com/en-us/magazine/ee335779.aspx
You should select the most appropriate binding based on your needs:
The BasicHttpBinding is designed for interoperability with simple web services that conform to the SOAP 1.1 message version.
The WSHttpBinding is designed for interoperability with more advanced web services that might leverage different WS-* protocols. Both of these bindings use HTTP for the transport and text message encoding because they are designed for maximum interoperability.
NetTcpBinding and NetNamedPipeBinding, on the other hand, are designed for efficient and high performance communication with other WCF applications across machines or on the same machine, respectively.
If you need maximum flexibility, and you need to use one or multiple custom protocol channels at runtime, you can use the CustomBinding that gives you the possibility to decide which binding elements compose your binding.
Consider using the WCF 4.0 Routing Service that provides features for content-based routing, protocol bridging, and error handling. The routing service could also be used as a proxy in a perimeter network to forward incoming calls to the appropriate downstream services in the intranet.
Understand the identity that your service will run under and the implications on downstream resource access. For Authentication and Authorization, choose between a Trusted Subsystem Model and a Delegation/Impersonation model, preferring the former which uses the process identity of the service to authenticate to downstream resources, as opposed to an interactive login. This pushes the burden of authorization on the client application, but is significantly easier to manage.
Claims-based security, including Authentication and Authorization, is becoming more and more important, and can provide for security when crossing geographies, domains, and so on. Consider using WIF in your web services.
Differing Security capabilities can pose a challenge. Understand support in other vendor stacks, such as IBM and Oracle:
Be aware of the timestamp problem when interoperating with systems that do not implement timestamps for security.
WCF is complex but very extensible. Use Custom Bindings when out-of-the-box bindings do not align exactly with your interoperability requirements.
Deployment
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
Use the Windows Server AppFabric Management Pack along with System Center Operations Manager to manage your WCF and WF services running on your AppFabric environment.
Use tools like Netmon, Fiddler, WireShark, and SOAP UI to become familiar with wire representations of your messages.
Determine a Tracing Policy and apply development/debugging and production settings as appropriate.
Administrators must familiarize themselves with PKI security mechanisms they will be responsible for at deployment time, including X.509 Certificate Configuration.
Administrators need to understand the interaction of IIS and WCF environments. Understand IIS Deployment & Hosting Best Practices, considerations for Deploying WCF Services, including new features introduced by AppFabric Hosting.
Performance
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.
Development
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?
Deployment
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?
Performance
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?
Appendix
< Full URLS for Hyperlinked Text>