Windows Communication Foundation (WCF) Best Practices

28 July, 2011
Windows Communication Foundation (WCF) Best Practices

Don't build a WCF service !
Unless you have a good reason for it:
Security reasons (business Logic in perimeter network)
Shared business logic (multiple apps or non .NET apps)
Heavy resource consumption (long-running?)
Separate maintainable
Separate scalable
28 July, 2011
2

Know the tools!
Svcutil.exe
SvcConfigEditor.exe
SvcTraceViewer.exe
REST starter kit
AppFabric
Web Services Software Factory (WSSF)
http://servicefactory.codeplex.com/
Enterprise Library (EntLib)
Exception Handling Application Block
Logging Application Block
Validation Application Block
28 July, 2011
3

Additional tools on CodePlex
http://wcfloadtest.codeplex.com
takes a WCF trace file and a WCF client proxy, or a WCF interface contract, and generates a C# unit test that replays the same sequence of calls found in the trace file. The unit test can then be used to load-test the target
http://wcfcontrib.codeplex.com/
library with infrastructure implementations for client and service communications
http://wcfsecurity.codeplex.com/
http://wcfextensions.codeplex.com/
WCF Compression Channel
28 July, 2011
4

Service best practices
Separate contract from implementation
Contract (interface) first (http://wscfblue.codeplex.com/)
Define services in a class library, not directly in a host project
Layering
Separate Service Layer
Instance model
Change to Per Call as default
Session / Singleton – use only when needed
28 July, 2011
5

Exception Handling (I)
For operation specific exceptions
Try/catch, throw FaultException<T>
Favor using FaultException<T>
FaultException can be ambiguous to the client because unhandled exceptions arrive as a FaultException
Include FaultContract in service contract definition
28 July, 2011
6

Exception Handling (II)
If you throw FaultExceptions
Part of the API you are exposing
For global exception handling from services
Use an error handler
Include exception details in debug builds only !!
28 July, 2011
7

Hosting
Favor WAS Hosting when on Windows Server 2008
Multiple protocol support
IIS Hosting model and tools
Use IIS hosting for external HTTP only
Favor self-hosting for stateful services, callbacks, .NET Service Bus, debugging
Have a console-based debug self-host for development time
Can be a Windows Service project that is used for production self-hosting with a mode switch for debugging
28 July, 2011
8

When you self host …
Do not put ServiceHost in a using statement in production code
Dispose can throw an exception that masks the real exception thrown from Open call
Explicitly call Close in try/catch and log/ deal with exception in catch
28 July, 2011
9

Client Proxy Classes (I)
Use static proxy class when possible instead of ChannelFactory
Connection caching in the base class in 3.5
Place for encapsulation of common patterns
Hand-code or generate proxy classes for internal services
Less bloated code
Share service contract and data contracts through libraries
Explicit control over config file
28 July, 2011
10

Client Proxy Classes (II)
Add Service Reference for external services or when you want an async API on the client
Clean up config after it messes it up
Make sure to add references to data contract libraries before adding the service reference to avoid duplicate definitions
Live with the duplicate service contract definition instead of needing to repeatedly clean up the proxy code
28 July, 2011
11

Client Proxy Management
Cache client proxies if frequent calls to avoid session establishment cost
If secure / reliable session enabled
Have to deal more cautiously with faulted proxies
Check proxy state before using
Get rid of proxy after exception
Don’t put proxies in a using statement
Dispose call might throw exception and mask real exception
Explicitly close in a try/catch block, and if Close throws an exception, Abort the proxy to ensure resource clean up
28 July, 2011
12

Client Exception Management
All exceptions thrown from a service call derive from CommunicationException
FaultException<T> always an explicit error returned
from the service
Simple approach:
Any exception from a proxy call, safe close the proxy
Advanced approach:
FaultException<T> - proxy is reusable
28 July, 2011
13

Data Contracts
Avoid XmlSerializer and MessageContracts except for interoperable scenarios and REST services
Favor data contracts over serializable types
More explicit model, better control over what the client sees
Implement IExtensibleDataObject
Avoids dropping data that the service / client does not understand
Avoid passing complex .NET specific types for interoperable services
DataSets and Exception types
28 July, 2011
14

SOAP vs REST
Favor SOAP services when you are writing a service that only your code will consume
Favor REST services for publicly exposed, data oriented services
28 July, 2011
15

Don't forget XmlNamespace settings
By default WCF puts the “http://tempuri.org/” namespace in your wsdl and contracts. Normally you don’t want this. You can control this from three places:
In your config file in the services/service/endpoint/bindingNamespaceattribute
In your servicecontract: [ServiceContract(Namespace="http://myuri.net/")]
In your servicebehavior: [ServiceBehavior(Namespace="http://myuri.net/")]
28 July, 2011
16

More subtle things with WCF
One-way !?
One-way is not always really one-way
even when doing oneway, closing a client can block until the service side is done
this is happening in quite some cases where bindings are configured to maintain sessions.
it happens for example with Message security and or reliable session support (WS-ReliableMessaging).
28 July, 2011
17

The limits of reliable Messaging with WCF (I)
Messages still can get lost with this mechanism if for example
the service is shutdown
IIS reset
If you need end-to-end durable reliable messaging with full support for transactional I/O you need an infrastructure that's in control of both ends of the communication
NetMsmqBinding.
MSMQ messages are limited to 4 MB
28 July, 2011
18

The limits of reliable Messaging with WCF (II)
If you are mostly worried about not losing messages under less-than-optimal networking conditions or require session support
the reliable session support in WCF is the right choice
isn’t very handy with load balancers
Sticky session/session affinity
28 July, 2011
19

20
28 July, 2011

Windows Communication Foundation (WCF) Best Practices

by Orbit One Internet Solutions

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

Windows Communication Foundation (WCF) Best Practices Presentation Transcript