windows communication foundation best practices l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Windows Communication Foundation: Best Practices PowerPoint Presentation
Download Presentation
Windows Communication Foundation: Best Practices

Loading in 2 Seconds...

play fullscreen
1 / 21

Windows Communication Foundation: Best Practices - PowerPoint PPT Presentation


  • 178 Views
  • Uploaded on

Windows Communication Foundation: Best Practices. Shy Cohen Program Manager Connected Systems Division Microsoft Corporation. 1. Migration. Best practice = DON’T. RATHER: Identify ideal architecture given today’s tools and ideas. Build an “exemplar”: Not a “pilot”-real solution

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Windows Communication Foundation: Best Practices' - naiya


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
windows communication foundation best practices

Windows Communication Foundation: Best Practices

Shy Cohen

Program Manager

Connected Systems Division

Microsoft Corporation

1 migration
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
2 addresses
2. Addresses

When self-hosting,

  • Define base addresses
  • Use relative endpoint addresses

Then endpoint binding can be modified w/o changing address

3 binding
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
3 binding cont d
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.
3 binding cont d6
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
4 contracts
4. Contracts

Provide explicit Names and Namespaces

  • Do you know what the defaults are?
  • Do you know they will never change?
4a structural contracts
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
4a structural contracts cont d
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.

}

4a structural contracts cont d10
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.
4b behavioral contracts
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
5 service implementation
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()
5 service implementation cont d
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
5 service implementation cont d14
5. Service Implementation cont’d
  • Service Behavior settings:
    • Reduce latency & improve throughput with
      • InstanceContextMode=Single
      • ConcurrencyMode=Multiple
5 service implementation cont d15
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
5 service implementation cont d16
5. Service Implementation cont’d
  • Use ServiceAuthorizationManagerTypes
    • More general
    • More configurable
    • Better path forward to Claims-Based Auth
    • (Consider Workflow Rules for implementation)
6 client implementation
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()
7 management
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.
8 large file transfers
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
slide21

© 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.