Windows Communication Foundation: Best Practices

1. Windows Communication Foundation: Best Practices Shy Cohen Program Manager Connected Systems Division Microsoft Corporation

2. 1. Migration • Best practice = DON’T. • RATHER: • Identify ideal architecture given today’s tools and ideas. • Build an “exemplar”: • Not a “pilot”-real solution • Covers a small # functional requirements • Covers a large # of non-functional requirements • Built on a FRAMEWORK that implements the ideal architecture. • Then ask, How does the rest of my stuff progress to my ideal w/ my framework? • Rinse & Repeat forever. • Yields continuous progress to an ideal • The “migrate” mindset yields no continuity-just a stop/upgrade cycle

3. 2. Addresses When self-hosting, • Define base addresses • Use relative endpoint addresses Then endpoint binding can be modified w/o changing address

4. 3. Binding • BasicHttp for interop • Queued bindings (MsmqIntegration and NetMsmq) • for managing access to contended resources • simple scaling • no remote receive • not for large messages: 4MB limit • NetTcpBinding • for WCF-to-WCF across a network • Flexible and Fast • NetNamedPipesBinding • for WCF-to-WCF across processes • Flexible and Fast

5. 3. Binding cont’d • NetPeerTcpBinding (PeerChannel) • for exchange of structured data among peers. • Not friggin’ chat apps! Use Win32 RTC API for unstructured data. • Custom Peer Resolver required if a peer is running WS2K3. • WSHttp • a BASIS for WS-* interop. • Remember that WS-* specs have not gone thru’ WS-I process yet. • i.e. No Profiles for those specs • Disable protocols you don’t explicitly need • WSDualHttp • for interesting demos. • No application where there are firewalls, NATs and IPv4.

6. 3. Binding cont’d • Streaming • Use it for file types (like .wmv) that support streaming • For minimum-latency, tiny message pub/sub • Complicated—have to compensate for message size limitations

7. 4. Contracts Provide explicit Names and Namespaces • Do you know what the defaults are? • Do you know they will never change?

8. 4a. Structural Contracts ONLY USE TYPES THAT RESOLVE TO XSD TYPES. • No friggin’ DataSets—including Typed DataSets • Not interoperable in practice • If you don’t care about interop, you do care about stability • DataSets can easily blow limits on nesting

9. 4a. Structural Contracts cont’d • Use DataContracts unless incompatible format is mandated. • More explicit • Better performance • Relieves pointless XML fetishism • Implement DataContracts w/ Partial Classes for readability //MyDataContract.cs [DataContract(Name=“…”,Namespace=“…”)] public partial class MyDataContract { [DataMember(Name=“…”)] //Use properties instead on private XType MyField; //presentation tier for UI binding } //MyDataContractBehavior.cs public partial class MyDataContract { //constructors and other behavior go here. }

10. 4a. Structural Contracts cont’d Avoid putting application data in headers. • More explicitly: use headers only for protocols. • In the few cases where you need a MessageContract to specify headers: • Define the body of the Message using a DataContract.

11. 4b. Behavioral Contracts • Provide a FaultContract for each OperationContract • Provide a default operation: Action=“*” • Aim for asynchronous message exchange patterns first • Explicitly justify synchronous message exchange patterns • Have a standard interface for management

12. 5. Service Implementation • WebHost should be first choice • Provides, • Built-in reliability • Proven throughput and scalability • Proven security (seriously!) • Explicitly justify Self-Hosting • eg: No WebHosting of non-HTTP protocols pre-IIS7 • When self-hosting, explicitly call Close()

13. 5. Service Implementation cont’d • Implement services in DLLs • Test DLL w/o WCF • Then test as self-hosted WCF service • Then test as Web-hosted WCF service

14. 5. Service Implementation cont’d • Service Behavior settings: • Reduce latency & improve throughput with • InstanceContextMode=Single • ConcurrencyMode=Multiple

15. 5. Service Implementation cont’d • Avoid maintaining state • Explicitly justify not using, • Message content • Data store … for all requests. • If you must maintain state, • Store it in Extensions accessible via OpContext • eg. OperationContext.Current.InstanceContext.Extensions • Store bulky state in a database • Consider ASP.NET Compatibility mode

16. 5. Service Implementation cont’d • Use ServiceAuthorizationManagerTypes • More general • More configurable • Better path forward to Claims-Based Auth • (Consider Workflow Rules for implementation)

17. 6. Client Implementation • Always use asynch programming model • (Use in server only for calls w/ asynch options) • Reduce latency on first call by calling Open() • Always explicitly call Close()

18. 7. Management • Turn WMI on. • Provide a comprehensive health model • Leveraging built-in perf counters • Supplemented with custom perf-counters • Monitoring of event log • Have a standard management interface • Implemented by all services • Provide PowerShell CmdLets and batch files • Turn logging on through WMI when anomalies detected • Integrate model into management console • Preferably MOM, Tivoli, OpenView • Otherwise custom console.

19. 8. Large File Transfers • System.Web has FtpWebRequest for that • If you insist on using WCF … • If max file size is known, • & security is required, • Use MTOM • If max file size is not known, • Use chunking channel

20. Related Content

21. © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.